Financial Cryptography

Security Signalling - sucking on the lemon

Over on Adam's blog, he asks the question, how do we signal security? Have a read of that if you need to catch up on what is meant by signalling, and what the market for lemons is.

It's a probing question. In fact, it goes right to the heart of security's dysfunctionalism. In fact, I don't think I can answer the question. But, glutton for punishment that I am, here's some thoughts.

Signalling that "our stuff is secure" is fairly routine. As Adam suggests, we write blogs and thus establish a reputation that could be blackened if our efforts were not secure. Also, we participate in security forums, and pontificate on matters deep and cryptographic. We write papers, and we write stuff that we claim is secure. We publish our code in open source form. (Some say that's an essential signal, but it only makes a difference if anybody reads it with the view to checking the security. In practice, that simply doesn't happen often enough to matter in security terms, but at least we took the risk.)

All that amounts to us saying we grow peaches, nothing more. Then there are standards. I've employed OpenPGP for this purpose, primarily, but we've also used x.509. Also, it's fairly routine to signal our security by stating our algorithms. We use SHA1, triple DES, DSA, RSA, and I'm now moving over to AES. All wonderful acronyms that few understand, but many know that they are the "safe" ones.

Listing algorithms also points out the paucity of that signal: it still leaves aside how well you use them! For imponderable example, DES used in "ECB mode" achieves one result, whereas in "CBC mode" achieves a different result. How many know the difference? It's not a great signal, if it is so easy to confuse as that.

So the next level of signalling is to use packages of algorithms. The most famous of these are PGP for email, SSL for browsing, and SSH for Unix administration. How strong are these? Again, it seems to come down to "when used wisely, they are good." Which doesn't imply that the use of them is in any way wise, and doesn't imply that their choice leads to security.

SSL in particular seems to have become a watchword for security, so much so that I can pretty much guarantee that I can start an argument by saying "I don't use SSL because it doesn't add anything to our security model." From my point of view, I'm signalling that I have thought about security, but from the listener's point of view, only a pagan would so defile the brand of SSL.

Brand is very important, and can be a very powerful signal. We all wish we could be the one big name in peach valley, but only a few companies or things have the brand of security. SSL is one, as above. IBM is another. Other companies would like to have it (Microsoft, Verisign, Sun) but for one reason or another they have failed to establish that particular brand.

So what is left? It would appear that there are few positive signals that work, if only because any positive signal that arises gets quickly swamped by the masses of companies lining up for placebo security sales. Yes, everyone knows enough to say "we do AES, we recommend SSL, and we can partner with IBM." So these are not good signals as they are too easy to copy.

Then there are negative signals: I haven't been hacked yet. But this again is hard to prove. How do we know that you haven't been? How do you know? I know one particular company that ran around the world telling everyone that they were the toppest around in security, and all the other security people knew nothing. (Even I was fooled.) Then they were hacked, apparently lost half a mil in gold, and it turned out that the only security was in the minds of the founders. But they kept that bit quiet, so everyone still thinks they are secure...

"I've been audited as unhackable" might be a security signal. But, again, audit companies can be purchased to say whatever is desired; I know of a popular company that secures the planet with its software (or, would like to) that did exactly that - bought an audit that said it was secure. So that's another dead signal.

What's left may well be that of "I'm being attacked." That is, right now, there's a hacker trying to crack my security. And I haven't lost out yet.

That might seem like sucking on a lemon to see if it is sour, but play the game for a moment. If instead of keeping quiet about the hack attacks, I reported the daily crack attempts, and the losses experienced (zero for now), that indicates that some smart cookie has not yet managed to break my security. If I keep reporting that, every day or every month, then when I do get hacked - when my wonderful security product gets trashed and my digital dollars are winging it to digital Brazil - I'm faced with a choice:

Tell the truth, stop reporting, or lie.

If I stop reporting my hacks, it will be noticed by my no longer adoring public. Worse, if I lie, there will be at least two people who know it, and probably many more before the day is out. And my security product won't last if I've been shown to lie about its security.

Telling the truth is the only decent result of that game, and that then forces me to deal with my own negative signal. Which results in a positive signal - I get bad results and I deal with them. The alternates become signals that something is wrong, so anyway out, sucking on the lemon will eventually result in a signal as to how secure my product is.

Posted by iang at October 23, 2004 11:40 AM | TrackBack