However, smart cards have existed since forever in the enterprise. You can buy FIPS 201-2 Level 3 compliant smart cards by the truckload at ~$10/card, generate a keypair onboard, put the public key in Active Directory, and have a pretty solid guarantee that the private key will never leak. Distribute one to every employee and use them instead of (or in addition to) passwords for Windows logon. The per-device cost is very low, but the big vendors (Gemalto, etc) want you to call their salespeople to discuss how many hundreds of thousands of dollars the Windows integration and card programming software is going to cost.
Most of these are JavaCards preloaded with a proprietary applet, then locked so you can't change the applets. The vendor then sells a driver that communicates with the applet and provides a PKCS#11 interface to the OS, so the card can be used for i.e. webmail client certificate login, PAM modules, domain authentication, SSH, VPN, etc. You can also just buy unlocked JavaCards and write your own applets for them. This is how most smart card products (national IDs, school IDs, large corporate deployments, U.S. DOD CACs, etc) come into existence - buy JavaCards by the shipping container, load your applet, run through an ID printer, distribute. There are a few places that will sell in low volumes with the default key set so you can use tools like GlobalPlatformPro to load open-source applets. Otherwise you can pay a coule grand for an SDK. There are a few open-source applets that (allegedly) provide a PKCS#11 interface on Linux and OSX through OpenSC. The JavaCards I bought were too old for most of them, unfortunately, but I'm buying some newer ones.
Old corporate hardware used to have smart card readers integrated everywhere - in monitors, in the keyboard, in the sides of ThinkPads. Nowadays the card + reader thing is a little dated and people would rather carry a USB token. So you can buy (bulk, white label) JavaCard chips with an integrated reader in USB form factor. Interface protocols are the same, and the same applets can run on both.
YubiKey wrote its own proprietary PKCS#11 applet and drivers. They also forked an existing OpenPGP applet (competing standard) which you can download from Github and (theoretically) run on a white-label JavaCard yourself.
So did Nitrokey. The only thing that's new about these developments is that the personalization tools and drivers are free, and the tokens are available in quantity 1. There are actually a few dozen different corporate, enterprise-sales-only YubiKey/NitroKey-like devices already, and have been for years. NitroKey is actually on the expensive side - their ~$50 model has a bit less functionality than YubiKey's. See also Feitian ePass2003, Gemalto IDBridge K50, etc.
First off, thanks for taking the time to reply. This is very helpful.
I have some more questions about these smart cards (e.g. it sounds like unique public/private key pairs would be generated on each card which might not help with the master key style scenario HSMs are good for). I'm going to be looking into this for sure.
One more thing. I'm assuming FIPS 201-2 Level 3 cards have not been hacked (there were several smartcard hacks a few year ago e.g. http://www.securitytube.net/video/945
You're almost certainly not going to get direct memory access or read keys off storage media like you might with a general-purpose computer. Attempts to physically get inside the chip to do so will destroy the keys. You have to communicate with the software running onboard.
But the software running onboard is, well, just software. It's common for applets to want a PIN before performing signing or decryption operations, and to lock out further attempts after N bad PIN entries. Yubikeys were vulnerable for a while to a logical flaw in the applet that let you trick it into signing without the PIN. Presumably applets can have buffer overflows and logical flaws just like everyone else; it's not inconceivable that you could get remote code execution inside the smart card by talking to it the right way. If implemented correctly, you still shouldn't be able to get the key this way, but you can use it. Also, while there exist readers with onboard PIN keypads, most people type their pins into desktop software that you could phish or keystroke log with remote code execution on the client PC, then have remote use of the card as long as it's connected to a compromised machine.
There's also generally a layer (or two) of administrative PIN/PUK codes so organizational administrators can reset forgotten user PINs. This is sort of a problem for the military when people in remote postings lock themselves out of their computers are there are no sufficiently privileged IT guys around. Some organizations can do this remotely, which is (probably) cryptographically secure but vulnerable to social engineering if you can steal a card and convince remote support to give you a PIN reset code. There's also another code that's necessary to replace applets. All of these are presumably vulnerable to being left at their factory defaults, being leaked by a careless administrator, etc. and not easy to rotate if compromised.
HID iClass (smart card-ish proximity physical access control) credentials are supposed to be impossible to clone without a cryptographic key, for example, except the same key is embedded in every HID reader. You can rip one off a wall, JTAG it, get the key, and sign arbitrary cards for any building that hasn't bothered to generate a facility-specific key (and almost no one has).
In a stored value card application, you probably can't get inside the card and flip a bit to give yourself $1,000,000. But there's a much better chance you can figure out the protocol spoken by vending machines and impersonate one. Security through obscurity is common here, and if cryptography is used the private keys in the vending machines may well be sitting in RAM in Windows XP on a subway platform, or crypto primitives may have been chosen incorrectly, or keys may be available by social-engineering the manufacturer.
Smart cards aren't a panacea. As some CIO-focused trade press mentions, most real-world breaches don't involve stealing authentication credentials. Having super-secret SSH keys doesn't help you if I can get a shell through PHP. But it is a hell of a lot easier for an attacker to get your SSH private key from ~/.ssh/id_rsa than from your smart card - at worst the smart card would let him use it.
BTW, you can generate the keypair on a computer (preferably an air-gapped one) and load it onto a smart card. This would let you have backups. But most applications are for authentication; there is no need to have a backup because administrators can simply associate a new card with the account. Server-side HSMs have different properties.'
(I am not a security expert, just taken an interest in this recently.)
4 comments
[ 2.7 ms ] story [ 19.6 ms ] threadHowever, smart cards have existed since forever in the enterprise. You can buy FIPS 201-2 Level 3 compliant smart cards by the truckload at ~$10/card, generate a keypair onboard, put the public key in Active Directory, and have a pretty solid guarantee that the private key will never leak. Distribute one to every employee and use them instead of (or in addition to) passwords for Windows logon. The per-device cost is very low, but the big vendors (Gemalto, etc) want you to call their salespeople to discuss how many hundreds of thousands of dollars the Windows integration and card programming software is going to cost.
Most of these are JavaCards preloaded with a proprietary applet, then locked so you can't change the applets. The vendor then sells a driver that communicates with the applet and provides a PKCS#11 interface to the OS, so the card can be used for i.e. webmail client certificate login, PAM modules, domain authentication, SSH, VPN, etc. You can also just buy unlocked JavaCards and write your own applets for them. This is how most smart card products (national IDs, school IDs, large corporate deployments, U.S. DOD CACs, etc) come into existence - buy JavaCards by the shipping container, load your applet, run through an ID printer, distribute. There are a few places that will sell in low volumes with the default key set so you can use tools like GlobalPlatformPro to load open-source applets. Otherwise you can pay a coule grand for an SDK. There are a few open-source applets that (allegedly) provide a PKCS#11 interface on Linux and OSX through OpenSC. The JavaCards I bought were too old for most of them, unfortunately, but I'm buying some newer ones.
Old corporate hardware used to have smart card readers integrated everywhere - in monitors, in the keyboard, in the sides of ThinkPads. Nowadays the card + reader thing is a little dated and people would rather carry a USB token. So you can buy (bulk, white label) JavaCard chips with an integrated reader in USB form factor. Interface protocols are the same, and the same applets can run on both.
YubiKey wrote its own proprietary PKCS#11 applet and drivers. They also forked an existing OpenPGP applet (competing standard) which you can download from Github and (theoretically) run on a white-label JavaCard yourself.
So did Nitrokey. The only thing that's new about these developments is that the personalization tools and drivers are free, and the tokens are available in quantity 1. There are actually a few dozen different corporate, enterprise-sales-only YubiKey/NitroKey-like devices already, and have been for years. NitroKey is actually on the expensive side - their ~$50 model has a bit less functionality than YubiKey's. See also Feitian ePass2003, Gemalto IDBridge K50, etc.
I have some more questions about these smart cards (e.g. it sounds like unique public/private key pairs would be generated on each card which might not help with the master key style scenario HSMs are good for). I'm going to be looking into this for sure.
One more thing. I'm assuming FIPS 201-2 Level 3 cards have not been hacked (there were several smartcard hacks a few year ago e.g. http://www.securitytube.net/video/945
But the software running onboard is, well, just software. It's common for applets to want a PIN before performing signing or decryption operations, and to lock out further attempts after N bad PIN entries. Yubikeys were vulnerable for a while to a logical flaw in the applet that let you trick it into signing without the PIN. Presumably applets can have buffer overflows and logical flaws just like everyone else; it's not inconceivable that you could get remote code execution inside the smart card by talking to it the right way. If implemented correctly, you still shouldn't be able to get the key this way, but you can use it. Also, while there exist readers with onboard PIN keypads, most people type their pins into desktop software that you could phish or keystroke log with remote code execution on the client PC, then have remote use of the card as long as it's connected to a compromised machine.
There's also generally a layer (or two) of administrative PIN/PUK codes so organizational administrators can reset forgotten user PINs. This is sort of a problem for the military when people in remote postings lock themselves out of their computers are there are no sufficiently privileged IT guys around. Some organizations can do this remotely, which is (probably) cryptographically secure but vulnerable to social engineering if you can steal a card and convince remote support to give you a PIN reset code. There's also another code that's necessary to replace applets. All of these are presumably vulnerable to being left at their factory defaults, being leaked by a careless administrator, etc. and not easy to rotate if compromised.
HID iClass (smart card-ish proximity physical access control) credentials are supposed to be impossible to clone without a cryptographic key, for example, except the same key is embedded in every HID reader. You can rip one off a wall, JTAG it, get the key, and sign arbitrary cards for any building that hasn't bothered to generate a facility-specific key (and almost no one has).
In a stored value card application, you probably can't get inside the card and flip a bit to give yourself $1,000,000. But there's a much better chance you can figure out the protocol spoken by vending machines and impersonate one. Security through obscurity is common here, and if cryptography is used the private keys in the vending machines may well be sitting in RAM in Windows XP on a subway platform, or crypto primitives may have been chosen incorrectly, or keys may be available by social-engineering the manufacturer.
Smart cards aren't a panacea. As some CIO-focused trade press mentions, most real-world breaches don't involve stealing authentication credentials. Having super-secret SSH keys doesn't help you if I can get a shell through PHP. But it is a hell of a lot easier for an attacker to get your SSH private key from ~/.ssh/id_rsa than from your smart card - at worst the smart card would let him use it.
BTW, you can generate the keypair on a computer (preferably an air-gapped one) and load it onto a smart card. This would let you have backups. But most applications are for authentication; there is no need to have a backup because administrators can simply associate a new card with the account. Server-side HSMs have different properties.'
(I am not a security expert, just taken an interest in this recently.)