The Old Joel on Software Forum: Part 3 (of 5) - Security protocols, threat models and greenbacks

Security protocols, threat models and greenbacks

Interesting reads for those interested in the security scene:

Ian Grigg takes a critical look at the Internet threat model that >should< have founded SSL at http://www.mail-archive.com/cryptography%40metzdowd.com/msg01276.html

"What does all this say? Well, in a nutshell,
we won't protect against the end system attack,
because its really difficult. And we'll ignore
DOS because that's too difficult too.

But we'll cover the entire on-the-wire threats
... because, as the book goes on to show, we can!

And that's the clanger - the threat model is
about what we can protect. It is not a
statement of what is needed for the application.

Rather, the whole SSL threat model is a statement,
lifted out of some book from some academic's
library, of what we know, in theory, about how
to create a channel protocol!"

Tim Oren responds with some very salient historical insigths ( a realy great read at http://www.pacificavc.com/blog/2003/10/21.html#a412 ) that conclude:

"Moral of the story? It's the business model more than the threat model that often dominates the real world of commercial security deployment. Grigg is right that if the actual threat had been analyzed, the focus would have been on the server (Willy Sutton: "That's where the money is."), not hypothetical packet sniffers. But that wouldn't have created a client/server lock-in, so it didn't fit the actual goals. Security designers - paranoids by trade - would be well advised to find an equivalently cynical business type to vet their ideas."

Both men present very good, complementary points and tell us good stories that lift the skirts of a popular protocol.

Just me (Sir to you)
Wednesday, October 22, 2003

"Secondly, and thusly, this clears the way to de-
emphasise protection against active attacks. We
can in most cases safely propose opportunistic
cryptography from self-signed certs, cached or
otherwise, from other methods of fingerprint
distribution, or even from anonymous Diffie-Hellman."

This is his only concrete contribution to the "discussion" other than to say "its broken". What he is effectively saying (I think) is that there is no authentication of the client to the server of the client's identity. Thus the reliance on passwords is required to authenticate the client's identity.

However, it the client is hacked, and has a keyboard logging and data transfer virus attached, then the passwords will be compromised. This would be true not only for web browser entry, but also for unlocking an ssh password, or PGP password, or anything else that relies on user entry.

There remains only one solution: a smartcard like device (could be a USB dongle, built in secure processor, or actual smartcard) which maintains private key secrecy and immutability, and performs all authentication and decryption without every exposing keys on the bus.

So, the assumption that the client is secure can only be truly validated by a hardware device with unique and unchangeable keys. A somewhat expensive and inflexible proposition.

So, is it really necessary for my bank to issue me a smartcard? Its not a bad idea, I would imagine that there are USB card readers out there that are reasonably priced. And I would guard my card just like a credit card - so the user methods are already known.

I'll just venture a guess that, so far, the costs haven't been worth the cost of theft.

nat ersoz
Wednesday, October 22, 2003

Smartcard is 1/2 the solution.

It prevents the attacker who has r00ted your machine from knowing your keys, but does nothing to prevent the attacker from screwing with you while you work.

Sure the smartcard will make sure that I'm there when I check my email. But without some sort of chinese wall in my computer, so can the attacker.

The best threat, in my mind, is e-signing a contract. You look at the contract on a machine not your own (or your comprimized machine) and tell your smartcard that it's OK to sign it. Because you aren't guranteeing security on the machine with which you are actually reading the contract on, they could have you sign a completely different contract without you catching on until later.

There's some fascinating stuff out there in the L4Linux crowd. The L4 kernel is most likely small enough to be "proven" secure. The Linux kernel can have the guts removed and, just like mklinux, you can have the Linux kernel become a single-server-microkernel OS without much modification.

This gives you a little more guarantee of security. If the L4 is "proven" secure and the Linux side is merely gatekeepered through, flaws on the Linux side of things won't effect the L4 side of things and L4-side bugs will be much less frequent (if not theoretically impossible).

In concert, perhaps, with the smartcard, you can then make sure that your interaction with a secured set of data can be unambiguously unsniffable and authenticateable, assuming that you are in control of the relevent hardware.

I think it's a neat idea, but I think that the overall necessity of it may be a little lacking. We may not need this wonderful set of fully-authenticatable security tools because there are just as many threat models for "traditional" ways of doing things (evesdroppers, forgery, etc)

Flamebait Sr.
Wednesday, October 22, 2003

Oh, and incidentally, SSL made much more sense in days past when more folks used unswitched ethernet, like back in those days.

And I *have* heard of a credit card sniffing case that indicate that at least a little bit of packet sniffing happens.

Flamebait Sr.
Wednesday, October 22, 2003

"Because you aren't guranteeing security on the machine with which you are actually reading the contract on, they could have you sign a completely different contract without you catching on until later."

Good point.

Also, I disagree with the author's notion that the wire is safer than the endpoints. Its too easy for an evil sysadmin, reprobate family member or rogue bank employee to be watching the wire.

Y'know: "everyone who has been protected by SSL, please raise your hand".

nat ersoz
Wednesday, October 22, 2003

If SSL wasn't there and credit card transactions were going over in the clear, there would be more interest in tapping the wire. Currently, there's not as much of that because the perceived payoff isn't particularly high.

Similarly, I think the big problem with leaving SSL or IPSec vulnerable to some wire-based attacks would just mean that people would try harder to be a man-in-the-middle. ;)

Flamebait Sr.
Wednesday, October 22, 2003