4 ms·

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 - Enrolmen

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.

tlrobinson 13y ago
Sounds like a business opportunity.
- yxhuvud 13y ago
  There are already companies in this space though. One example is secmaker.com, but I don't know if they operate outside .se yet.
- hpagey 13y ago
  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.
stonemetal 13y ago
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. 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).
- mpyne 13y ago
  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.
  - stonemetal 13y ago
    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.
    - mcguire 13y ago
      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.
      - mpyne 13y ago
        Yeah, it does suck to be CTR, I'll admit. Especially if you need separate CAC credentials for things like base access.
        count 13y ago
        October is hell month :)
      - RyJones 13y ago
        Try when you don't have prints. Took a long time to get my card issued.
count 13y ago
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.
- dredmorbius 13y ago
  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.
  - count 13y ago
    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.
    - dredmorbius 13y ago
      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.

tlrobinson 13y ago

Sounds like a business opportunity.

yxhuvud 13y ago
There are already companies in this space though. One example is secmaker.com, but I don't know if they operate outside .se yet.
hpagey 13y ago
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.

stonemetal 13y ago

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. 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).

mpyne 13y ago
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.
- stonemetal 13y ago
  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.
  - mcguire 13y ago
    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.
    - mpyne 13y ago
      Yeah, it does suck to be CTR, I'll admit. Especially if you need separate CAC credentials for things like base access.
      - count 13y ago
        October is hell month :)
    - RyJones 13y ago
      Try when you don't have prints. Took a long time to get my card issued.

count 13y ago

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.

dredmorbius 13y ago
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.
- count 13y ago
  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.
  - dredmorbius 13y ago
    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.