March 27, 2005
S/MIME - breaching the barrier to sign
My first foray into S/MIME is ongoing.
I say "ongoing" because I've completed the 3rd attempt to get it going without success and now have signing going!. The first was with the help of one of CACert's experts, and within 10 minutes or so of massive clicking around, I had a cert installed in my Thunderbird.
10 minutes to create a cert is total failure right there. There should be ONE button and it should take ONE second. No excuses. The notion that I need a cert to tell other people who I am - people who already know me - is so totally off the charts there are no words to describe. None that are polite anyway.
(Actually, there shouldn't even be a button, it should be created when the email account is created! Thanks to Julien for that observation.)
Anyway, to be a crypto scribbler these days one has to have an open mind to all cryptosystems, no matter who designed them, so I plough on with the project to get S/MIME working. No matter how long it takes. Whip me again, please.
There are three further signing problems with S/MIME I've seen today, beyond the lack of the button to make it work.
Firstly, it seems that the key exchage is based on signed messages. The distribution of your public key only happens when you sign a message! Recalling yesterday's recommendation for S/MIME signing (do not sign messages unless you know what that means) this represents a barrier to deployment. The workaround is to send nonsense signed messages to people who you want to communicate with, but to otherwise turn signing off. Techies will say that's just stoopid, but consider this: It's just what your lawyer would say, and you don't want to be the first one to feel really stoopid in front of the judge.
Secondly, Daniel says that implementations first encrypt a message and sign it. That means that to show that a message is signed, you must de-sign it *and* decrypt it in one operation. As only the owner has the key to decrypt, only the owner can show it is signed! Dispute resolution is looking messy, even buggy. How can anyone be sure that that a signed message is indeed signed if there are layers separating message from signature? The RFC says:
In general, the best strategy is to "be liberal in what you receive and conservative in what you send"
Which might be good advice in Gnuland, but is not necessarily the best security advice. (I think Dan Bernstein said this.) Further, this puts the application in a big dilemma. To properly look after messages, they should be decrypted and then re-encrypted within the local database using the local keys. Otherwise the message is forever dependent on that one cert, right?! (Revoke the cert, revoke all messages?)
But if the message is decrypted, the signature is lost, so the signature can only ever form part of a message integrity function. Luckily, the RFC goes on to say that one can sign and encrypt in any order, so this would seem to be an implementation issue
That's good news. And (thirdly) it also takes the edge off of the RFC's suggestion that signatures are non-repudiable. FCers know well that humans repudiate, and dumb programs can't do a darn thing about it.
Posted by iang at March 27, 2005 01:43 AM
Now that you have it working, in retrospect, how easy could it have been, if you had understood what you were doing and had done it right? Is it an inherently intractable problem, involving editing the registry, copying and pasting certificates from one obscure program into another, and performing multiple steps? Or is it just a matter of finding the right option and turning it on?
How many steps is it, if you do it right? Suppose you walk up to a new install of your mail agent and have to get S/MIME working on it, are you going to just throw up your hands in despair and say, this will take hours? Or can you sit down and get it done in a minute or two?
I don't know for sure that S/MIME encrypts first and then signs the ciphertext, but if it does then there's a worse problem than any you've mentioned. An active attacker can remove the signature from the ciphertext and sign it himself, which will cause problems if anyone is using the signature as proof of authorship (not that they should be).
PGP allow you to sign without encrypting and vice versa. If you do both, then PGP applies the signature first and then encrypts. The threat here is that the intended recipient can then re-transmit a signed message. Unless there's envelope information covered by the signature, great mischief can ensue: imagine the wrong person getting a signed message saying "pay the bearer $8,000 from my checking account--signature from Alice--" or "I love you and I want to rip your clothes off --signature from Alice's husband--".
Details at http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html including info about which protocols are subject to which threats and protocol enhancements to prevent them.
Notice that both threats depend on the philosophical definition of a message. How much is in the text, and how much is in the context? Are To:, From: and Date: part of the message? Will the recipient assume that the signer and the author are the same person?
Fred, that's a fascinating reference. I disagree with the premises of the paper though, the author is making the same mistake as all of the protocols that he cites: he has not defined what the semantic meaning of a signature is. Is it a message integrity check? Is it a proof that if came from some key? A user's confirmation that it was seen? Or is there higher meaning there?
Deep within we find out that "...so as to achieve basic symmetric-key security guarantees that users expect. The recipient needs proof that the signer and the encryptor were the same person..." So I guess that on the one hand, he assumed that "what users expect" was the purpose of the signature, and OTOH, he says that it is to prove that the whole message as seen came from one person (and wasn't seen / fiddled by some other).
Ironing these details out is critical (in software engineering, these details are known as 'requirements'). In Europe, in some places, using signatures will be seen in a different, legally binding light. In Estonia, for example, by law, a will&last testament is legal if affixed with a digital signature. Does that mean an S/MIME signed email can be used?
"We suggest that the messaging standards all erred by treating public-key encryption and digital signatures as if they were fully independent operations."
Well, I treat them as separate because I want the signature to ride alone. But there, I've defined what I mean by signature - it's an authorisation. Further, for my app, the server doesn't really care if the outer layer is stripped off at all ... that's the sender's problem.
in answer to your question: I view it as intractable for users without a fairly significant change in UI steps. Jim outlines some of the things here: http://blog.jim.com/?postid=7 but all of these steps - to make it work for people who haven't got all day to muck around with crypto - all these steps require code changes and UI changes. It will take years for this to filter through.
(Scientifically, I don't have a view of how many steps it took. It was in the dozens. The original setup was so fast I couldn't keep up with what was going on, and even then the expert got it wrong, he missed a step.)
I've been thinking about this tonight. I posted this to firstname.lastname@example.org:
> I have a message that was encrypted and signed in one step. When I
> decrypt it, I can read the message and see that the signature is valid.
> So far so good.
> I would now like to relay this message to a third party so he can verify
> the signature too. But as far as I know, GPG has no way to do this.
Atom Smasher replied:
> there's no reason it can't be done, but i don't know of any application
> that can do it.
> for now, the only way to do it is to extract the session key from the
> message (--show-session-key) and send that along with the encrypted
> message to your 3rd party. they can use "--override-session-key" to
> decrypt the message and verify the signature.
> in most cases the session key should be encrypted (to your 3rd party),
> because anyone who gets a hold of the session key can read the message.
So I tried it and it worked like a charm. For example:
% gpg --show-session-key "
Now I don't intend to use this feature routinely in the operation of my system. However, it is nice to have in the rare case that a serious dispute arises.
I'm well aware that I could simply require users to sign first, then encrypt in two separate steps, and I could peel back the two layers on my end, but that's a hassle for everyone.
I just thought this might be helpful to you and decided to pass along my findings.