
Ntirokey is shipping - superuser2
https://shop.nitrokey.com/shop
======
gentleteblor
Does anyone have experience with these in their current or prior (CyptoStick)
form? It seems to good to be true given the cost of other HSMs.

~~~
superuser2
I don't know anything about server-side HSMs.

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.

~~~
gentleteblor
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](http://www.securitytube.net/video/945)

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

