Clique Security Overview Powerpoint presented on December 13, 2006
Don't worry!
With the advent of the "Evil Bit" in RFC3514, we no longer need to worry about computer security. Wait a sec... when was that RFC issued?
Picking Locks
When I was in second grade, my older half brother Charlie came to visit. We had great fun, running around playing tag. At one point, he was running away from me, and went in to the bathroom and locked the door. He thought he was "safe". I, on the other hand, went and got my LPK -- an index card box filled with carefully bent paper clips, a few small screwdrivers, and a pair of scissors with the end of one blade bent out. With my Lock Picking Kit, I was quickly able to open the locked bathroom door to tag my hiding brother. Charlie, obviously, was using the bathroom and yelled for me to get out! When he was done, however, he asked how I was able to open the locked door.
At that early age I realized that there is no such thing as perfect security. Locks were the perfect example. Locks have the fundamental property of being openable. Sure, locks are designed to only be openable given the right key, but in reality, anything that acts (from the locks perspective) like the right key will open the lock. Given this understanding, you could imagine the perfectly secure system. Put your secret document in a safe. Fill the safe with concrete. Weld the safe shut. Bury the safe deep under a mountain, and fill the hole with concrete. Mask the burial site, so it looks indistinguishable from its surroundings. Make sure that the people who do this are blindfolded when taken in and out. Then kill them. Perfectly secure? Doubtful. Perfectly useless? Absolutely! Nobody could retrieve that document, not even yourself. Thus, security is fundamentally about acceptable level of risk.
When designing a system, it is important to think about what that level of risk is. What are the security needs? How important are they? Spending all your time and resources to secure something worthless is a waste. Buying a $5000 lock for a tricycle is foolish.
The Cheating Wife
A man walks into a detective office, sits in the chair, and barks "Sir! I want to make sure my wife doesn't cheat!". The detective responds, "Do you think she is?" "No, but I want to make sure it isn't a possibility. I just want to nip that potential problem in the bud. I want to make it so she doesn't even have the option." The detective responds, "Gentleman, I understand your fear. Throw her in a dungeon and she won't be able to cheat with anyone other than the troll that feeds her. I can't help you prevent your wife from infidelity. However, if you ever suspect she does cheat, come to me, and I can find evidence. Heck, if you want, pay me now and I'll keep looking until she does cheat." "No, I'm pretty sure she isn't cheating now. At least, that's what the last detective I hired told me."
The above dialog illustrates two important points. The first is the distinction between tamper-proof and tamper-evident. Do you want to prevent someone from cheating, or just know if they did? The second point is a bit more subtle. Vigilance in security is important. However, it comes at a price. If the man's wife cheated on him one time, the man will never know. The first detective didn't catch it. But if she is cheating with some periodicity, if the man keeps trying to find out, eventually he'll catch her.
With software, there is another important point to be made. Software is an unusual creature. The way to protect software is through this contrived legal mechanism called licenses, which no one pays attention to until they get a letter from a lawyer. Sure, click-through licensing holds up in court, but nobody reads them. For this reason, in addition to tamper-proof and tamper-evident solutions, with software there is also the aspect of making the user tamper-aware. Make it obvious to the user when they are doing something wrong. The wife knows she is cheating, but the person who copies the software onto two of their personal machines may not realize that they've done something wrong. They may still be able to do it, but if they do and you catch them you can surely get them in trouble by invoking the license.
Ugh, Humans!
The number one best way to compromise a system is also the hardest to prevent. Some call it social engineering, others call it cunning. Indeed the best way to rob a bank is to walk in the front door, have the bank manager open the vault for you, and walk out with the money. You might think that no bank manager would ever do this, but then you'd be wrong.
A startling example of this is password security. Some silly companies implement a policy forcing their users to input "strong" passwords to log in to their computers. Even sillier companies then require users to change their passwords regularly. And the silliest companies will assign users an impossible, long, alphanumeric password that they'll change up before the user memorized it. Why is this silly? Because it works in direct contrast to the most important rule about passwords -- Keep them secret. It is rare that someone evil actually has the time to run a password cracking program, or to try out numerous combinations of birthdays, pet names, etc... On the other hand, it is pretty typical that the evil person has the time and ability to peek around the desk of the computer they are trying to penetrate, and find the post-it with the password printed on it. If the passwords are hard to remember, inevitably the person writes it down in a convenient place. And thus, these hard passwords render the system less secure. I'd rather recommend that people use some unusual combination of English words (perhaps mipselld, or us1ng 3mb3dded numb3r2). This is vastly more secure than using their birth date, and more secure than something too hard to remember that the people need to write them down. Requiring unique passwords for numerous systems has this problem as well.
Oh, and check out my getting started guide. It contains lots of useful information for new employees.
A losing side bet: Offline Money
A holy grail of security systems is what I call offline money. This is having something that represents value that can only be used once, and that both sides can not refute. The non-repudiation aspect is not hard -- we can have both parties sign and date the document, and then either can present it and verify that the transaction took place. But preventing the value giver from presenting that to another party and claiming that it hasn't been used is not possible without an online clearinghouse. The reason is simple. Digital goods can be copied perfectly. Real world money is made using valuable metals or precisely engraved papers which are very difficult to reproduce. Counterfeit money usually looks poor and is easy to detect.
The problem of offline money shows its head in many different contexts. But the problems go away when you can use a clearinghouse -- a trusted exchange mediator. Some system to say that the money is valid. An example of this happens when you swipe your credit card. The reader transmits your number to an online service which validates that your card has not been stolen.