Crypto USB Devices - where is the PIN/Password stored?

Question

I am currently looking at the security of cryto USB drives for storing x509 certificates. I have one in possession currently. It can be read/written to using the Microsoft Crypto APIs. Anytime one reads/writes to/from the device it prompts for a PIN. The PIN can be changed using a UI which installs with the device.

I was wondering how exactly this PIN is stored/used?. Does the device store the PIN on the device itself? Or is the PIN used to generate a symmetric encryption key which is then used to encrypt the contents of the device. Which will mean that only the right PIN will allow you to read from the device and also the PIN is not available on the device itself.

So I was wondering if there is a standard way in which device vendors do this. If so, what is it?

This is what the PKCS#11 standard says

If a device does not have a tamper-proof environment or protected memory in which to store private and sensitive objects, the device may encrypt the objects with a master key which is perhaps derived from the user’s PIN. The particular mechanism for protecting private objects is left to the device implementation, however.

It's not clear what's a tamper-proof environment or protected memory in case of a USB crypto device.

Answer 1

It's impossible to say what the device really does; there are so many possible ways.

If you don't find any technical specification describing it, I would be wary of the actual security of the device.

If the device is FIPS 140 approved at any level, you can find back the FIPS certificate and the relevant security policy on this NIST web page.

Answer 2

I do not know what the practice is, much less what your particular device do, but I can tell what could be done.

The token could contain a secure Micro-Controller Unit, complete with CPU(s), RAM, Non-Volatile Memory (EEPROM or Flash), crypto accelerators for symmetric and asymmetric crypto, and a communication interface (USB, or perhaps ISO-IEC 7816-3 with an USB translator on the side). An example of suitable circuit might be the M9900 depicted on page 11.

With these resources, the token could contain the user PIN, an error counter, and some confidential or/and trusted data. It could invalidate itself after a number of false PIN presentations; and accept to work only after a good PIN presentation. Working would include using its confidential or/and trusted data. Perhaps these could include the private asymmetric keys used e.g. for signature generation or decryption; or just symmetric keys and MACs used to validate and decipher a pool of external asymmetric keys then used internally in the device.