SIM / Card
|RSA 2048 keys (max)||32||48||48|
|ECC 256 keys (max)||40||60||60|
|Key Backup / Restore|
|Public Key Authentication|
|n-of-m Threshold Scheme|
|Key Use Counter|
Check out the product flyer for more technical details.
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.
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.
The EA+ version features the latest version of the applet (V2.0), including public key authentication, n-of-m threshold authentication, transport PIN support, user defined key restrictions and key audit counter.
The MicroSD card form factor combines 1GB 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.
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.
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.
Need additional support to give your project a kick-start ?
Try the SmartCard-HSM SDK, which provides you with a set of different SmartCard-HSM form-factors, a card reader, additional software and 8 hours of support. The SDK includes a one-year subscription to premium content on the CardContact Developers Network (CDN).
The SmartCard-HSM SDK comes with
- 3 SmartCard-HSM Dual-Interface ID-1 cards
- 2 SmartCard-HSM SIM-Plug ID-000 cards
- 2 SmartCard-HSM USB-Token
- 2 SmartCard-HSM MicroSD Cards
- 1 card reader Identive SCR 3310
- 1 CD-ROM with SDK software (updated via CDN)
- 8 hours support via telephone or e-mail during office hours (Units of 15 minutes)
- Access to subscriber area on CardContact Developers Network (CDN) for one year after activation
The SmartCard-HSM SDK sells at EUR 2.500,-- (plus VAT). Please contact us for commercial details. Export restrictions may apply outside the European Community or the US.
Owner of a SmartCard-HSM EA+ can obtain access to the SDK software hosted at the CardContact Developer Network. Just register your device and get a certificate for access.
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.
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 ensure, 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.
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 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.
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 SDK 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.2 rated random number generator.
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.
Maximum number of keys
The maximum number of keys mentioned in the table above means the number of private key that can be created on an empty device. The number may be lower if additional meta data or certificates are stored.
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 in the Java Card Secure Element is shared between the applet code, key objects and file objects.
The MicroSD cards has additional 1GB outside the SE for general purpose.
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.
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.