Poking around on Ciphire's website I discovered a review by Bruce Schneier on the architecture. It follows on from an earlier one by Russ Housley and Niels Ferguson Here's some meta-comments on the second review.
Firstly, Bruce indicates that the system is vulnerable to an MITM based on the attacker attempting to insert false reply information, and then redirecting the user to email back to an address/key he happens to have. Bruce says this is hard to deal with, but I wonder about that: this is what SSH defends against. If the client can keep track of the certs it has downloaded, surely it should be able to warn of changes, either by history tracking or user labelling (petnames, logos etc). Indeed, it seems that a lot of the other later attacks can be dealt with by not trusting the PKI every time it says "trust me."
Secondly, Bruce talks about the insider code injection attack. Yes, tough one. Publishing the code the code - which Ciphire have indicated they will do - helps there, and as mentioned this is _necessary but not sufficient_ as eyeballs are limited even then.
But there are further steps that will be left undone - Open Sourcing, Open Standards and Open Compeittion. Open source walks hand in hand with open standards. And open standards encourage competing implementations. Here, we see the often bitter and twisted relationship between the PGP Inc and GnuPG teams - which we cheer and applaud as while they are fighting each other, their code is getting better and better and more and more secure.
No such luck for Ciphire; even when they publish the source, it would take a masochist of maniacal proportions to download it, print it and start reading it. I well remember Lucky Green walking into HIP with boxes and boxes of PGP source. And I do mean boxes, a figure of 20 sticks in my mind and I have no idea why. A team of about a dozen of us worked for about 2 days flat out to finish the last 1% of the errors in the source scanning. And we didn't have time to dally on this comment or that buffer overflow...
So Ciphire aren't going to see as much benefit from the publication of their source as they might hope, but for all that it certainly adds to the confidence if they do publish.
Thirdly, what's the _security signal_ with posted reviews? Well, it's all well and good that someone famous did a review. That's presumably for money, and any crypto guy knows you get what you pay for. That's grand, but what strikes is not the review, but the problems found. Problems were found - see above - and Ciphire still printed the review!
So I propose a new signal: disclosure of own shortfalls, weaknesses, attacks. As Ciphire has gone ahead and published a critique with lines of attack within it, they've drawn out the worst that can happen to them. This does more than just give slashdotters something to get excited over, it actually tells the world where the security stops. That's a valuable thing.
Posted by iang at March 30, 2005 02:15 AM | TrackBackI see publication of source code as another security signal. Even though nobody will look at it, the mere fact that they publish it demonstrates their confidence that there are no back doors. If someone finds one it would be devastating to them, especially as a new company trying to establish a track record. By putting themselves at risk for this, they demonstrate that no such risk exists.
Source code publication is better understood as a case of security signalling than a method to improve the security of the product.
Posted by: Cypherpunk at March 31, 2005 03:29 PMYou say that SSH protects against MITM attacks. Well, it does, but that's like comparing apples and oranges. SSH is being used by admins/geeks that understand what it means when SSH tells them that the key of the remote site has changed. This may *help* to notice a MITM attack, but it doesn't protect against it. Further, the user usually knows the server to which he is connecting and may know if the existence of a new key is ok or not.
With email crypto this is different. I simply don't know if a user just changed his certificate or key (for whatever reason) or if I'm seeing a fake one. Personally, I simply want to be able to renew my key as often as I like and don't want to go through the pain of telling my peers that I've got a new key.
With Ciphire they could probably add a warning if the client sees a new certificate for a particular email address. AFAIK the client already checks the old certificates, ie it walks back the chain of old certificates to verify if it leads to a previously known/used certificate. But a certificate mismatch warning like the on used in SSH would probably scare a normal user to death. ... Most (normal) users are simply clicking 'Ok' if they are seeing a 'new SSL certificate' warning for their mail server because they don't understand what it means.
Petnames and logos ... well, I'm not sure if this is really going to be a solution. In the case of email crypto, what should I do if I found out that the certificate/key changed? The user may just renewed his key ... Fingerprint checks are annoying and the Web of Trust doesn't really work. I've several dotzens signatures on my PGP key, but does it help me to avoid fingerprint checks? No, it doesn't.