Five reasons to upgrade to PKCS#11 v2.40

Graham Steel
July 16, 2015

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:

Comparing v2.40 to v2.20

1. Authenticated Encryption

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

2. MACs that are secure for variable-length messages

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.

3. PBKDF2 with SHA-512

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.

4. Less legacy stuff

A large amount of ancient cryptographic mechanisms like SKIPJACK and 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).

5. CKA_COPYABLE and CKA_DESTROYABLE

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.