The release of the SmartCard-HSM 4K marks an important milestone, with support for larger keys, support for AES and the introduction of key domains. The next generation SmartCard-HSM will make key management even more flexible and secure.

While 2048 bit RSA keys are still sufficient for typical user keys, a lot of customers are using the SmartCard-HSM for long-term keys. A good example are certification authorities, where keys are planned to be in use much longer than just a couple of years. With the new 4K version you can finally use the key management capabilities of the SmartCard-HSM with RSA keys up to 4096 bit. At the same time the new device supports EC keys up to 521 bit and AES keys with 128, 196 and 256 bit.

As we rely on the cryptographic library of the smart card chip, we had to wait for NXP to release the JCOP 3 JavaCard platform.

JCOP 3 is a new development, different than the JCOP 2 platform we used before, so porting the SmartCard-HSM wasn’t a smooth process. The biggest challenge with smart card based applications is the limited RAM available. The code needs to be well written to conserve transient heap and still allow operations with large data objects. Importing and exporting large keys is very RAM consuming, as the key components need to be packaged, encrypted and then transmitted to the card reader. The engineering marvel is to squeeze the process into a 1K RAM buffer. That pretty much feels like programming a ZX81 from the eighties.

Support for AES allows new applications, that require key management with symmetric keys. An application example is the management of keys for RFID cards. Here often a master key is required in a terminal to derive a card specific key in order to perform the authentication protocol. Of course, AES keys can be managed in the same way as RSA and EC keys, with key generation, export and import using key domains.

Speaking of key domains, that is a new feature available with the 4K version. A key domain is a group of SmartCard-HSMs that can share the same cryptographic material. Previous versions already allowed the use of a Device Key Encryption Key (DKEK) to securely transfer keys from one device to another. Key domains extend this concept with a dynamic protocol to agree a mutual key encryption key between two devices.

Because key domains require a little more explaination, I’ll save that for a new blog.