FEATURES
|
|
Feature Overview
 4K |
 SIM / Card |
 Micro SD |
|
|---|---|---|---|
| Form factor | Standard-A USB |
ID-1 Contact ID-1 Dual-IF Mini-SIM Micro-SIM |
MicroSD |
| Software Version | 4.x | 4.x | 3.x |
| RSA / ECC (max Bit) | 4096 / 521 | 4096 / 521 | 2048 / 521 |
| Memory | 120KB | 120KB | 60KB/8GB |
| RSA key (byte) | 4000 | 4000 | 2000 |
| ECC key (byte) | 2500 | 2500 | 2500 |
| AES key (byte) | 250 | 250 | 250 |
| Interface | CCID ISO7816 |
ISO7816 ISO14443(*) |
File Exchange ASSD |
| Build-in PKI |  |
|
|
| Secure Channel | |
|
|
| Key Backup / Restore | |
|
|
| PIN Management | |
|
|
| Public Key Authentication | |
|
|
| n-of-m Threshold Scheme | |
|
|
| Transport-PIN Mode | |
|
|
| Key Restriction | |
|
|
| Key Use Counter | |
|
|
| Key Import | |
|
|
| End-to-end encryption | |
|
|
| SDK Access | |
|
|
| Key Domains | |
|
|
| ECC Key Derivation | |
|
|
| AES for Key Management | |
|
|
Check out the data sheet and (MicroSD) for more technical details.
SmartCard
As the name implies, the SmartCard-HSM is available in standard form factors like regular credit card size (ID-1), SIM card size (ID-000) or even special formats like ID-00. It works at the contact and/or contactless interface with standard readers that support ISO-7816 or ISO14443. The contactless interface can be combined with Mifare Classic and Mifare DESfire for legacy access control systems.
The card form factor is specifically suited for employee badges, customer cards or id cards.
USB-Token
The SmartCard-HSM is available as USB-Token, which is effectively a CCID compliant card reader combined with the smart card chip in a single device.
The USB-Token does not require additional hardware or driver and works immediately when plugged into an USB port on your computer.
MicroSD
The MicroSD card form factor combines 8GB of flash memory with an embedded secure element loaded with the SmartCard-HSM applet.
The card is specifically suited for mobile apps written for Android. The card is supported by most Android phones or tablets with a MicroSD card slot.
JavaCard Applet
For integration with your own card or secure element, the SmartCard-HSM is available as JavaCard Applet for the NXP JCOP platform.
Add a professionally developed PKI applet with comprehensive middleware support and flexible production software at a competitive low price.
PKI-as-a-Service
The PKI-as-a-Service cloud-based PKI is the perfect match with your SmartCard-HSM. Running your own CA, issuing certificates and managing a bunch of SmartCard-HSMs has never been easier.
Device Issuer CA
The Device Issuer CA is the personalization software required by card issuers to load and personalize the SmartCard-HSM JavaCard applet onto their cards. It contains the certification authority that is required for the PKI build into each SmartCard-HSM.
The Device Issuer CA is a client-server system based on the Remote Smart Card Access technology from the OpenSCDP project. The client can be either the Smart Card Shell (for small production volumes) or the OCF component integrated in a card printer or card personalization machine. Multiple personalization clients can be connected to a single server.
SDK Access
Owner of a SmartCard-HSM 4K can obtain access to the SDK software hosted at the CardContact Developer Network. Just register your device and get a certificate for access.
Build-in PKI
The SmartCard-HSM features a build-in PKI that signs public keys of key pairs generated in the device. An external entity (e.g. a CA) can verify the device generated signature to prove authenticity, integrity and origin of the public key. For this purpose, the Scheme Root CA maintained by CardContact issues certificates for Device Issuer CAs, which in turn issue an unique device certificate for each SmartCard-HSM produced.
In the certification process, a world-wide unique identifier is assigned and linked with the device authentication key. This ensures that the device identity can be cryptographically proven.
Secure Channel
A local or remote client can establish a secure communication channel with the SmartCard-HSM using an asymmetric key agreement scheme in order to negotiate symmetric keys for encryption and integrity protection of the exchanged data. This way the device is linked to the client, protecting the transmission of sensitive data (e.g. PINs or data to be signed) and enforcing the integrity of the exchanged commands.
The mechanism works much like a SSL/TLS connection between a browser and a server.
Key Backup and Restore
For very important keys it is advised to create a backup of the key material. The SmartCard-HSM supports encrypted key backup and restore using the Device Key Encryption Key (DKEK) that can be set during device initialization. The DKEK ensures, that cryptographic material is never exposed in plain.
A comprehensive DKEK management scheme allows shared control for the DKEK with XOR shares and an n-of-m threshold scheme.
Starting with the 4K version, the SmartCard-HSM supports Key Domains that allow multiple DKEK or Key Encryption Keys that are mutually agreed in a group of devices.
PIN Management
The SmartCard-HSM supports an initialization code (SO-PIN) and a User-PIN. The former protects initialization of the device, while the later protects access to keys.
PINs have an associated retry counter that prevents exhaustive PIN tries.
Public Key Authentication
Public Key Authentication is an alternative authentication mechanisms than can be used instead of the User-PIN. It works by registering a public key from a different SmartCard-HSM during initialization.
For authentication, a challenge-response protocol is executed between the SmartCard-HSM and the entity requesting authentication.
n-of-m Threshold Authentication
Access control to sensitive keys can be shared amongst a group of key custodians, each one able to authenticate using his own private authentication key.
The n-of-m scheme in the SmartCard-HSM enforces, that at least n of the m eligible key custodians authenticate before access to key material is granted.
Transport PIN Mode
This feature allows a security officer to define a PIN protection for the transport from the initial device preparation to the final user. The Transport-PIN is like an electronic seal that the user can check to see if the keys have been used before. A Transport-PIN must be changed to a self-selected PIN before access to keys is granted.
Key Restriction
Key Restriction allows the user to impose certain limits on the algorithms the key can be used with. This ensures, that only approved algorithms (e.g. sign, decrypt, PKCS#1 V1.5, PSS) can be used with the key. Key restrictions are set during key generation and remain in place during the key lifetime.
Key restrictions also allows to limit the export of keys from the device if a DKEK is set or if the key was imported into the device.
Key Use Counter
To limit the use of a key and to effectively audit its use, a key use counter can be defined during key generation. The key use counter is decremented with each key operation. An expired key use counter blocks a key from further use.
Key Import
While it is not advised to import keys from unknown source, there are situation where an existing key must be imported into a SmartCard-HSM (e.g. in a CA key migration).
For those cases, the Smart Card Shell provides for a mechanism to encrypt a key contained in a PKCS#12 container into a format suitable for import into a SmartCard-HSM.
However, the general advise is to generate keys in the SmartCard-HSM using the Common Criteria certified key generation algorithm and DRNG.3 rated random number generator.
End-to-End encryption
The SmartCard-HSM implements an end-to-end key agreement scheme based on card-verifiable certificates. The peers validate each others public key based on an embedded trust-anchor and a certificate chain. Based on the authenticated public key, an ECDH operation is used to derive a set of common encryption keys. The scheme is designed for online communication (like in SRTP) as well as for file exchange.
Average Key Size
Due to memory fragmentation, the memory size required by a single key is difficult to determine. It also depends on other memory elements like meta data and certificates. You milage may wary.
Using key backup, the total number of keys is virtually unlimited, as keys can be generated in the device, exported into a data base and only imported when needed.
Memory
Memory in the Java Card Secure Element is shared between the applet code, key objects and file objects.
The MicroSD cards has additional 8GB outside the SE for general purpose.
Interface
The SmartCard-HSM interfaces with APDUs as defined in ISO-7816-4. APDUs are transmitted via CCID in the USB device, via ISO 7816-3 (T=1) in contact based cards, via ISO 14443-4 for contact-less cards or using a proprietary file exchange protocol in the MicroSD card. The APDU interface is documented in the user manual (CDN Account required) and can be used via the various middleware components.
Key Domain
A Key Domain is a logical container for keys that can span multiple devices.
Key Domains help to organize a group of keys and their availability on different devices for load sharing, shared access or business continuity. The EA+ version supports a single DKEK key domain, while the 4K version supports multiple Key Domains (limited by memory) of type DKEK or XKEK.
In a DKEK Key Domain multiple devices share the same symmetric Key Encryption Key, imported via key shares.
In a XKEK Key Domain a SmartCard-HSM needs to obtain a key domain membership certificate from a Group Signer, that controls which devices are part of the same domain. Once a SmartCard-HSM has joined a Key Domain, it can securely agree a XKEK using an authenticated ECDH scheme with a peer.
EC Key Derive
In particular for crypto currencies and smart contracts, the SmartCard-HSM supports derived EC keys to implement key management schemes similar to BIP32. Unlike with BIP32, key material remains inside the secure element, while the public key can be calculated outside from the master public key.
AES for Key Management
While the processing power of the SmartCard-HSM is not sufficient for symmetric encryption schemes, it is perfectly suited for symmetric key management schemes using a master key to derive sub keys. For this purpose you can generate random AES keys, share them in a Key Domain and derive sub keys for processing on the host using CBC, CMAC or NIST SP800-56C mode.
Why choose a SmartCard-HSM ?
There are a considerable number of PKI token and cards in the market. Like the SmartCard-HSM, most of them allow to generate and store cryptographic keys and certificates.
The SmartCard-HSM is different, as it puts an emphasis on key management functions usually only found in expensive, host based hardware security modules.
It also provides an answer to an important question: How can I be sure, that the keys are really on a hardware device, and only there ?
The most common solution today is to use a central issuance model: Keys and certificates are created and loaded into the PKI token in a secure location. The token is then given to the user, typically together with the PIN code that protects the keys.
While the SmartCard-HSM supports the central issuance model, it plays at it's best in a decentral issuance scenario: Deploy an empty SmartCard-HSM and generate keys and issue certificates remotely.
Naturally, remotely generating and certifying keys requires a strong security mechanism: The issuing CA must be sure, that keys are
generated on an identified, unique and genuine device.
Because a SmartCard-HSM has a build-in PKI when shipped from production, that task
has never been easier: Like your browser connects to a SSL/TLS protected website, an application can connect to a SmartCard-HSM using a certificate
based authentication scheme. As it's based on a build-in PKI there is no complicated key management required.
Both, the OpenCard Framework and the OpenSCDP ScriptingServer provide support for an end-to-end secure communication with a SmartCard-HSM. See the public support scripts for more details.