In April 2015, following its transfer to OASIS, the PKCS#11 standard for device crypto APIs got its first official update in ten years. There is always some lag time between a new standard and vendor adoption. Here are five good reasons you should be nagging your crypto hardware vendor to upgrade:
- Authenticated Encryption
- MACs that are secure for variable-length messages
- PBKDF2 with SHA-512
- Less legacy stuff
One thing we learned since the last version of PKCS#11 is that Authenticated Encryption (AE) is not just a fancy crypto nicety, it’s a security necessity for almost any serious application. While you can build your own authenticated encryption from old PKCS#11 modes (here is one interesting way to do it), it’s simpler and more error-resistant to use a dedicated AE mode. PKCS#11 v2.40 contains two of these, GCM (as used, for example, in TLS) and CCM (as used in many embedded devices).
The original PKCS#11 contained MAC modes that were used in the financial sector in applications where every message was a fixed-length block. Unfortunately, these modes give no guarantee of security if message length is variable. PKCS#11 v2.40 contains mechanisms like CMAC which are secure in the variable-length setting.
Password-based key derivation functions (PBKDFs) are often used to store passwords in a secure way by hashing and salting them. The idea of a good PBKDF is that it requires enough computational resource to calculate that a realistic adversary will not be able to brute-force guess your password if he obtains the hashed and salted version. PKCS#11 v2.20 only supported PBKDF2 with the SHA-1 hash, which is no longer a good choice for this application, since advances notably in hardware-based hash crackers have made brute-force guessing these passwords much more feasible. PKCS#11 v2.40 supports SHA-512 (and SHA-256) for PBKDF2, which makes these attacks much harder.
A large amount of ancient cryptographic mechanisms like
FASTHASH as well as broken functions like
MD5 have been removed from the “current mechanisms” list. This should mean less chance of an error by an unwary programmer. However, take care, there are still insecure mechanisms in the list, like RSA PKCS#1v1.5 Encryption (recently removed from both TLS and the W3C Web Crypto API).
Two new attributes in PKCS#11 give you more fine-tuned control over key-management by marking keys that may be duplicated or deleted. Careful how you use them, though. Our Analyzer tool can help understand the security consequences of attribute configuration.
PKCS#11 v2.40 is a big step forward. If you want your crypto infrastructure to be secure, you should ask your vendor about their upgrade plans. Finally, our App Tracer can help you find out if your applications are using the interface in a secure way.