Ever thought about what happens when an SSL implementation can't get access to random data? Or how fork() complicates the behavior of a pseudo-random number generator (PRNG)? You should. Now there's a proposal for a getrandom() system call in Linux. 
Fri Jul 18 08:34:47 PST access to random information is important!:
Computer Security is kind of like a lot of things in life, where when you finally figure out the "secret" it's kind of a letdown. We want to find silver bullets for our problems, like a vegetable that is minus 1000 calories per serving (yet is packed with vitamins!), and we want to find that one get rich quick scheme or magic pill that actually works. We want that to be true so badly that whole industries are dedicated to coming up with new schemes, pills, and kitchen gadgets (SlapChop!).
We want to find the winning strategy, but sometimes we find out the answer is some disappointing koan like "the only winning move is not to play." With security, we want to come up with some scheme where we can make our networks and machines bulletproof to any attack, in any scenario. But the more you work on it and think about it, the more you're faced with economics. We still have to play the game, but life is just too short and you don't have enough resources to make everything perfect. It's almost certainly impossible even if you did have unlimited resources. (As Steven Wright said, "You can't have everything -- where would you put it?")
So what's most important to you? Are you more worried about electronic attacks? Or are you more worried about physical attacks? If you're worried about physical attacks, are you worried about your neighbor? The govenment? Aliens? Are you more worried about confidentiality or availability? Etc., etc.
If you're more worried about physical attacks, you'll probably spend a lot of time on physical security -- sensors, bunkers, acid-spitting robots. But if you're only interested in electronic security, you probably won't spend any money on additional physical security. (Most of us worry about malware and identity fraud, but how many of us have put extra locks on our doors because of it?)
At some point, you have to sit down and work it out. What threats do I think are most likely to succeed? What's my worst case scenario and how much would it cost me if it happened? Which countermeasures would be worthwhile and which ones would be a waste of time? So we make trade-offs. We don't reinforce the door to the server room, but we do encrypt the backups. We run a firewall on our router, but we still use wifi at home. We get a battery backup, but we don't get an emergency air conditioner or a halon fire suppression system.
Abstraction is just one more tool in the toolbox. And just like any tool, it has strengths and weaknesses. Yes, abstraction embeds weaknesses at levels you may not be able to control, but it also keeps you from reimplementing the wheel every day. It saves time. It makes code simpler. You have to ask yourself: "What's more likely to cause problems: an imperfect standard (with well-understood flaws that can be designed around), or a homemade solution likely to be full of unknown problems which are potentially worse? In most cases, the right choice is to use well-known albeit imperfect systems because the alternative are so much scarier.
For me, the lesson is two-fold. First, make smart trade-offs. In particular, pay attention to the security you are winning or losing through your trade-offs. You're going to make trade-offs one way or the other -- if you don't know what they are, you could be making bad decisions.
Second -- and this is true for everyone from the hobby hacker to (especially) people on standards task forces -- use your influence to develop and choose good abstractions with reasonable security properties. Learn from the past and current research. It's inevitable that new flaws will be found in new designs. But it's time that we eliminate gaping holes in our common abstraction layers, because they make engineering security at the upper layers at best very difficult and at worst a joke.
[Acknowledgment: Bruce Schneier talks a lot about trade offs. I'm certainly not trying to parrot him, but the reality of trade offs has been impressed upon me through several recent experiences, so It's on my mind. I started this long post because I wanted to talk about the problem of embedding flaws in layers through abstraction. But the truth is that abstraction is almost certainly worth the risk -- because ultimately, it's a trade off like everything else.
I also edited this post on 7/1 because I wasn't happy with the last paragraph.] Wed Jul 01 11:08:10 PST Abstraction and Trade-offs: The Devil You Know:
So, I was changing my account password with an online finance site, and they had many rules for the new password. Most of them made obvious sense ("You can't use your username in the password"). But one of the rules was "You can't have numbers separated by a letter." So "asdf7hjkl" is OK, but "asd6f7hjkl" isn't. Does anyone have any idea why? The only thing I can think of is that they're trying to make it harder to enter hexadecimal values or character escapes into the form. Any ideas? Mon Jun 08 20:45:35 PST numbers separated by a letter?:
 | Unless otherwise noted, all content licensed by Peter A. H. Peterson under a Creative Commons License. |