Hacker News Reader

Comment by count | Hacker News Reader

The whole DOD is using it, but they're on crypto smart cards, so many folks don't realize that's what they're doing. Email, single sign on, web site auth, etc. Works great!

View on HN

It's easy enough to use on a smart card, but try setting that up. I'm trivialising now, but you're looking at...

- Card manufacture

- Key handling

- Enrolment

- Card lifecycle

- Certificate lifecycle

- Identity synchronisation

You could buy a stack of white-labelled cards, of it you're the DoD you'd roll your own. That's shopping for silicon wafers, contact plate assemblies, mag stripes, holograms, RFID blanks, plastic card blanks, and card stack.

Regardless of DoD or not, you've got to manage secure key transfer (keys created at bureau, exported using GIS TX3 and multiple smartcards, sent to client via multiple motorcycles, key reassembled and imported into HSM).

Enrolment is a hefty process. Apply for smart card. Personalise physical card (typically photo and name), provision (link card to user), give card to user, mail PIN to user (out of band), and then activate card.

That's just card manufacture and provisioning. Doesn't cover provisioning and de-provisioning software and hardware, card lifecycle (suspend when lost, disable if stolen or not found or employment terminated, and so on).

Then there's CA integration, (often multiple) directory integration, and hardware integration.

The point of all this is that security can be easy, but it comes with a big fat price tag and some very specialised skill.

You're right, it's a ridiculously large organizational overhead. Not to mention the CA's become single-point-of-compromise for the whole PKI. Even after 10 years or so of the CAC, the DoD process is still not pain-free. They've finally moved to OCSP instead of CRLs, which helps (the CRL is so large now that it will bluescreen Windows on import to the registry, haha) some of the pain.

Even the DoD doesn't roll it's own cards and foundry stuff: they're standard Gemalto (and a few other provider) cards. You can order blanks yourself, I believe.

It's also a black art - VERY very few people seem to know how to 'boostrap' the system (enable PKI for a domain or web server, get new certs issued, etc.) even within the over-archign framework.

That said,my point still stands: millions of people (literally) use PKI for client SSL certs daily.

the CA's become single-point-of-compromise for the whole PKI. It's a bit more nuanced than that. A compromised CA can issue new certs which can spoof old one's identity, but it can't be used to create certs which will read traffic from an existing host. The big risk is that someone is subject to a MITM attack, doesn't clue in on the certificate change (their client should note this), and accepts the new key.

Signed / validated keys (used for major sites in some browsers) also help this somewhat.

Not that SSL/TLS isn't a huge mess.

A compromised CA in a client cert PKI world, like the DOD one I was talking about, is effectively an end-game scenario. Every machine in the org. would have to be updated (root CA's don't have CRLs, afaik). The big risk isn't a mitm attack - that's a risk with traditional server-side certs. The big risk is that all of a sudden there are unlimited legitimate users with no control over identities anymore. It's like getting write access to /etc/passwd.

Doesn't that depend on how you authorize the client certs themselves?

It's one thing to _issue_ a cert. It's another to _approve_ that issued cert.

If you're blindly accepting certs, you've got other issues.

You missed the part where you drive several hours to the closest military base and wait in line several hours(think DMV and TSA all rolled into one).

If you're actually on the DoD network that's only necessary in the rarest of cases. Retirees have to drive awhile sometimes, that's true, but they are not getting CAC anyways, they're getting old-style ID cards.

In my experience that is the common case, work for a defense contractor not on, but near a military base. I very well could be wrong though.

I don't work for the DoD, but you have the process right as far as I've seen. Don't forget that they seem to want a new set of fingerprints every time you go in.

Yeah, it does suck to be CTR, I'll admit. Especially if you need separate CAC credentials for things like base access.

October is hell month :)

Try when you don't have prints. Took a long time to get my card issued.

Sounds like a business opportunity.

There are several companies in this space. I was a research lead for smartcard access project for iOS platforms. We had to perform two way handshake using the certificates on the smart card. The most difficult part was to get data signed by the private key on the card during the handshake process.

There are already companies in this space though.

One example is secmaker.com, but I don't know if they operate outside .se yet.

True, it works great for the average dod user (and in an enterprise in general) because they have a helpdesk that sets everything up for them. Once its configured it works fine, which is consistent with the message of this article.

Good luck to them if they want to install a different browser (non-IE) or do anything non-standard... if they even are allowed to do so.

For a while I was checking upcoming OS X releases for CAC compatibility. At least on OS X, it's surprisingly easy to get set up, with the hardest step finding a compatible card reader. Once you have that, you usually have to install a PKCS#11 module (usually CACKey for DoD). Once that's all done, it's presented as an additional Keychain for the rest of the system to use. I know Chrome and Safari work with it without further fiddling, and I'm pretty sure Firefox will as well.

Firefox did a lot of work to make CAC cards work for the DoD, they didn't develop a FIPS module just for the fun of it.

I've always liked the idea of smart cards, but I also wonder how I would use a smart card to simultaneously log in to a site from, say, my PC and phone. It seems like the card can only be plugged in one place.

Well your phone already has one smart card plugged into it all the time (assuming it's a GSM phone). Perhaps there's a clever way to leverage that as one factor in the authentication process.

That is, in fact, the point :) Using cards with your phone is a serious pain in the neck still, either way. You could always get an alternate token/card, so you have two you can use.

I would love to hear more about this. I've been looking for a good sso solution that uses crypto cards.

My understanding is that the private key is on a CAC card[1,2], which is issued to all DoD employees and contractors who need access to DoD resources. Readers are usually built into the keyboard, and I'm guessing that there's something similar to ssh-agent running to maintain the key until you're AFK.

[1] http://en.wikipedia.org/wiki/Common_Access_Card

[2] http://www.cac.mil/

As a DoD CAC user and developer, this is correct (although the card readers at my company are built into the laptop or inserted via a USB adapter). I don't think there is a background agent that maintains the key though, I just think the card reader is queried when the certificate is needed. After the cert has been verified, you're free to pull the card out.

The key never leaves the smartcard: the card hardware will not allow it to be retrieved. Rather, your system has drivers which ask the card to do all of the signing operations which your system would normally do if it had access to a key.

> After the cert has been verified, you're free to pull the card out.

Last time I checked DoD systems are configured to automatically log you out of your session upon removal of your CAC.

This is an unrelated security measure, but you are correct.

And if you pull the card out, you can't access anything anymore that requires it (and on a Windows domain that DOESNT lock / terminate the session, you'll be able to access things until your kerberos ticket expires or you need to get to something you don't have a ticket for).

I once volunteered at a hospital where they made use of a smart card security system - among other things, it would log you out if you removed your card from the reader. This closed all the programs you were running - and logging back in was a slow process.

Needless to say, the smart cards stayed in the users' PCs even when they weren't at their desks.

That's disappointing, Windows has multiple options to handle a smart card's removal, one of which is simply locking the screen, sad they decided to use the "force log off" setting instead.

I think this is a feature of the ActiveClient middleware. Also handles the PIN entry when you insert. Default windows behavior is to leave the certs in the cert store.

ADFS and UAG - the crypto card is tied to an account in AD, AD is configured to trust certs signed by a given CA, and the UAG software then uses that authenticated user to provide SSO.

Reply on news.ycombinator.com