Reading (For Dummies)

Use the --force, LUKS

Yet Another Project at Work has become very interesting, indeed. My favoritest times in college were programming. Kernel programming, specifically. What I like to dub my master's design thesis was a novel take on encrypted filesystems. Myself and my friends Divyakaran (now works for the 'zon) and Yuhua (disappeared?) made perhaps the Best Encrypted Filesystem ev4r. LUKS (Linux Unified Key Setup) is a project that actually does most of the same things that we did. It does some things a lot better, like not hacking the superblock to fit a key in. It also has a much better way of erasing old passwords than our system. But the principle was the same (eventually with ours, anyway): store keys where you could, change the way the filesystem mounted slightly and as seamlessly as possible. Later, I made it re-use the same cryptographic material, so you could change the disk password without having to decrypt and re-encrypt every filesystem block. Second star to the right, and straight on 'till morning.

I'm working to expand the specification now. What I want is to create a PKCS#11 solution, so we can all use smartcards to set up our keys. The symmetric key used to encrypt the disk would be just some random data (really random data if you will). We would then encrypt the symmetric key with each intended user's public key, using the PKI. Really it wouldn't matter where they had their private key. It could on a smartcard, on a floppy disk, whatever. It doesn't matter, so long as the data is secure and the user is responsible enough. They'd need their private key to decrypt the symmetric key, then they could decrypt the disk via cryptsetup. Voilla! I'd still have to figure out a way to elegantly handle certificate revocations, but otherwise everything is there in my head, and slowly going into some C files. Neat.

I think the changes won't be very painful, and it makes sense to expand the system in such a way. The key storage method should really be separate from the cryptosetup implementation. I've never had too much patience plowing through hundreds of documents of previous projects though -- it's more fun to just make it go first and see what the world thinks later. So it's on to project number 5 of Really Neat Things Reid is Doing At The Moment -- a little bit of reading to make sure it isn't done (seems doubtful because LUKS is pretty new). Here's hoping my bald head doesn't lose any more hair from the coding to come. Time for another case of guarana.

DNS-323 Re-revisited

My formerly piece of junk DNS-323 is turning into something very, very cool.

Some folks started a Wiki for the little NAS. The wiki includes such howtos as how to bootstrap it with a debian distro. Super-cool! My NAS is now running debian sarge (the OS unfortunately is relegated to running on top of the 2.6.6 kernel in the latest firmware). I'm cleaning up some of the howtos on the wiki and even making instructions to greatly greatly improve the device. Using the debian version of samba and some creative scripting, you can turn this little NAS into something that will auth against LDAP (or even run an ldap server) and allow real network use -- like storing all your user's home directories on it. Very, very, very cool. I <3 Linux devices (although I still dislike companies that wait for the community to fix their problems for them).

Bike Jamming

I moved recently to a new part of San Diego -- much closer to downtown. I'm living with a crazy smart developer for Sony Corp (insert jokes about proprietary house keys here...seriously, the keys to our condo are smartcard chips with some kind of custom interface that I'm going to have to hit with the digital logic probe).

A slightly longer commute, not that I mind

I now live in Cortez Hill (instead of Point Loma). It adds about five miles to my bicycle commute. I'm actually loving the extra time in the saddle, though...a large portion of the extra mileage is on a bicycle path that runs between the highway and the bay. Dodging joggers (some with dogs) and the occasional bicycle commuter is a lot less stressful than dodging cars for the whole ride.

The new roommate is pretty nifty, too, and has what I would call a cadre of nerdy friends. Government work is always a little strange in that regard -- most of the people that I've worked with are 20 years older than I, married with children, etc. I, on the other hand, am in a long-distance relationship with my life partner (we could get married, sure, but neither of us really believe in that particular institution anymore), and the only argument we've ever had is whether the tofu stirfry needs a drop of habanero pepper sauce, or if we should give it the smokier flavour of salsa taquera (hint: they're both good). In short, knowing some people from my demographic is pretty nifty.

The exercise is good, too...the last two months haven't seen very much saddle time, with a lot of out-of-town visitors, then moving, then finally getting the dreaded flu. My commute takes about 40 minutes each way now. Kind of funny when I think about it...this time last year I was living in Syracuse, NY, and commuting to Rome. That commute took about 50 minutes -- of driving. I much prefer the current scenario for a lot of reasons.

Your moment of Zen: The ride home

Dog Bites Reid

My brother was recently commenting on how boring my blog is lately. This afternoon events occurred which may spice it up.

Where he got me!

I went to the coffeeshop near work this afternoon to get a cup of chai. There was a German Shepherd leashed right next to the door, which I didn't think much of, so I walked past him. He jumped quite suddenly and bit me in the posterior. I was a bit shocked, yelled at the owner to wait there (I needed to use the men's room in the worst way). When I came out, she was gone.

Fortunately the folks at the coffeehouse know the woman's name, and I caught her dog's name when she yelled at it. She apparently lives close by...the kind coffeehouse folks say that she walks in every other day or so. My biggest concern is of course whether or not the pooch had all of its vaccines (and consequently whether or not I need to go through a long and painful series of Rabies shots). The urge to get a lawyer involved is rising.

The bite just barely broke my skin, so I washed it out for a while with soap and water. The risk of infection is somewhere near nil (the last domestic animal in SD to have rabies was 1967), but it sure takes some nerve for a dog owner to walk away from a scene like that.

Fun times...

SSL Redux

I decided to turn to the specification for TLS in determining the feasibility of my proposed attack from the other day. I was a little bit wrong in an assumption about how SSLv3 and TLS work with regards to client certificates, although the attack still works with some slight modification.

Negotiation works by the client side generating a random number (called the premaster_secret), encrypting with the client's private key, and shipping it to the server. The server then decrypts the value using the client's public key, and can simultaneously verify the client's authority to access the server, as well as use the now-decrypted premaster_secret to start making shared secret keys between the client and server.

The client-cert-forwarding attack still works, though, because of browsers being silly. My web browsers (IE7 and Firefox 2.0.0.1) both prompt for my smartcard PIN precisely once. After that, they sign whatever client cert requests are asked of them by any trusted server that chooses to ask it. Trusted servers are just those servers that happen to have valid certificates (e.g. someone paid a few dollars to have Verisign generate a key for them). If the site has an invalid key, the client will still sign, so long as he/she clicks "Okay" on the invalid certificate box.

Assuming our intermediary server receives a connection from the client, the client will generate a premaster_secret and send it to the intermediary. The intermediary can then open a connection to the bank, or what-have-you, and use the same premaster_secret. It has the premaster_secret that the client used in both decrypted form (using the client's public key) and encrypted form (what it initially received from the client, prior to decryption)...there seems to be no reason that the intermediary couldn't do this.

To define the problem in a rigorous way that points fingers at the things that need to be fixed is a little complicated, because SSL is a little complicated surrounding client certificates. The real solution is still to do something like have the client encrypt the premaster_secret concatenated with the target server...his way the target server will know the premaster_secret, but won't be able to generate appropriate ciphertext for the bank. Of course, the protocol people might say something like the SSL-library implementors should change their ways and not blindly sign certificates for sites. I guess I'll find out...

More Nefarious Chip-And-Pin Attacks

Ziff-Davis has a story detailing some vulnerabilities in the use of smartcards that borders on lame. I love smartcards. They're amazing little things. But they're also prone to some Bad Things.

The reason I call the recent attack announce, "lame" is because it's a simple exploitation of the trust boundary of smartcards. The trust boundary of a smartcard is really the computer and the machine. In certain situations, the trust boundary is the computer, the machine, and the remote server, as I'll outline in the 'more interesting' attack below.

A little while ago I started working on a "PKCS#11 proxy service." The idea is that some older SSL apps don't support PKCS#11. If a server sends a client certficate request, the client doesn't know what to do...it will probably ask you for a file certificate at best, or just fail to negotiate at worst. If you use a HTTP CONNECT proxy service, the service could silently strip out the client certificate request from the SSL handshake and sign the data the server sent by talking to your smartcard itself. This doesn't break the SSL handshake, only the TCP stream, but the CONNECT proxy is the endpoint for the TCP stream so no worries.

"That's kinda neat," I started thinking to myself, "I wonder what else you could do with that." Looking at the way the handshake works, you can do a lot of bad things with SSL the way it's defined. The client cert request that an SSL server sends to the client is random data. It's in no way attributable to the site that requests the signature. "So what?" you ask. Here's what: I set up a web site with a URL, say https://www.foo.com and tell you to click the link. You do so, with your smartcard inserted. You connect to my server. My server then opens up a connection to your bank. The bank asks my server to authenticate itself, and sends the random data to my server asking my server to sign it. My server in turn sends an SSL client cert request to you, with the same data that your bank wanted signed, and you sign the request ("What could go wrong?" after all). Now my server is logged into your bank account, and is transferring your funds into my bank account. Neat, huh?

I feel like SSL should change, and should be required to send client cert requests in the format of domainname+date or something. Signing that would be safe(r), because your client could at least check that the certificate request is valid and that you're signing for the site that you think you're signing for. I guess if this idea/attack hasn't been published before, it might be new/novel...

Snake Oil

The term Snake Oil is one that I find increasingly humorous, and worthy of talking about. Snake Oil is often applied to cryptography in the computer security industry, as in, "their algorithm promises the equivalent of 4096-bit RSA using only a 40-bit symmetric key, and promises to run through blocks faster than DES." And so on. Often the claims are unbelievable and unbelieved.

What is so funny is that Snake Oil actually works. The derogative use of the phrase was pushed by sellers of other pain relievers back in the day. I guess the only question I ask is: What is Schneier trying to sell us?