IBM PCIeCC3 CCA / EP11 comparison

With the purchase of an IBM PCIeCC3 hardware security module (HSM), you also receive IBM’s Common Cryptographic Architecture (CCA) and IBM’s Enterprise PKCS #11 (EP11). CCA’s capabilities are described here, and EP11’s capabilities are described here.


CCA / EP11 functionality chart

The table below is designed to help customers understand the capabilities of CCA and EP11 to help them determine which would best suit their application requirements. For questions about CCA, please contact crypto@us.ibm.com. For questions about EP11, please contact EP11SUPP@de.ibm.com.

 

Cryptographic Support / Algorithms

Capability

CCA

EP11

Improved performance of cryptographic hardware. This results in improvement for all algorithms, with particularly significant improvements for public-key algorithms.

X

X

Cryptographic-quality random-number generation using the coprocessor hardware to seed a FIPS 140-2 and NIST SP 800-90A Revision 1 compliant random number generator.

X

X

Simple Public Key Infrastructure (SPKI) inside the HSM for native X.509 use, operational with Digital Signature Verify.

X

 

Provides an implementation for the industry standard PKCS #11 v2.20 and some algorithmic extensions for an enterprise environment. Extensions include mechanisms for CMAC, ECDSA, EC-multiply, EAC, and DH/EC key derivation.

 

X

User Authentication:

  • Access to key objects can be restricted to authorized usage using EP11 login sessions, allowing finely-grained usage control of objects.
  • CCA allows users to authenticate to a role-based access control system to determine what CCA functions they are permitted to perform. This is only supported on non-Z systems.

X

X

Attribute-bound keys prevent the separation of keys and their attributes, thus allowing an authenticated transport of objects. This prohibits changing attributes while transporting the key from one system to another.

X

X

Public keys can be made trustable by making them integrity-protected SPKIs with a MAC. This allows them to be transported without using a special secure device.

 

X

DES, Triple-DES, and AES data encryption/decryption supports CBC and ANSI X9.23 "last block" padding rules.

Note: In EP11, there is no DES or ANSI X9.23 support.

X

X

The ability to encipher and decipher data using the AES algorithm in Galois/Counter Mode (GCM).

X

 

Message Authentication Code (MAC) generation supports hash-based MAC generation (HMAC) and CMAC.

X

X

The creation of symmetric key material from a pair of Elliptic Curve Cryptography (ECC) keys using the Elliptic Curve Diffie-Hellman (ECDH) protocol and the ANSI-9.63-KDF key derivation method as specified in ANSI X9.63-2011.

X

X

Elliptic Curve support: CCA and EP11 support NIST Prime curves (P192 to P521) and Brainpool curves (BP160 to BP512 in the regular and twisted variations). EP11 also supports the Secp256k1 curve.

X

X

Selectable RSA public exponents 3, 5, 17, 257, and 65537 (the series of the first five Fermat prime number) are supported for CCA.

In general, EP11 supports all reasonable sized exponents, 17 and above, that are not even. Some compliance modes enforce exponents to be equal or above the Fermat 4 number (65537).

X

X

Support for the PKCS #1 v2.2 RSA Probabilistic Signature Scheme (RSA-PSS). RSA-PSS is based on the RSA cryptosystem and provides increased security assurance for sign/verify operations.

X

X

Support for the PKCS #1 v2.2 RSA Optimal Asymmetric Encryption Padding (RSA-OAEP).

RSA-OEAP is based like RSA-PSS on the RSA cryptosystem and provides increased security assurance for encryption/decryption operations.

Note: In EP11, only SHA-1 is supported with RSA-OAEP.

 

X

 

X

Digital signature generation and validation using RSA supports several different hash-formatting methods including ISO 9796-1 and PKCS #11 standards. Support of SHA up to 512 bits and MD5 algorithms is provided. The modular-exponentiation hardware engine supports keys up to 4096 bits in length.

Note: In EP11, there is no MD5 support.

X

X

Supports several key derivation and key agreement protocols. Standard Elliptic Curve Diffie-Hellman (ECDH) key derivation mechanisms and hashing-based mechanism are supported.

X

X

Support for Extended Access Control (EAC) key derivation mechanisms for the advanced security mechanisms for machine readable travel documents in the EU.

 

X

AES Cipher keys exportable to Central Processor Assist for Cryptographic Function (CPACF) for use in protected mode encryption, authorized with key attribute. With protected mode encryption, the secure CCA key is returned to the host caller reenciphered under the CPACF wrapping key for direct usage in a CPACF encryption instruction. The clear key value of the operational key is never available in host storage.  Using this mode increases performance for these operations.

X

 

Secure channel for key export to CPACF – keys are encrypted between the HSM and CPACF.

X

 

Secure import and export of AES and DES/TDES keys encrypted using symmetric-key and public-key techniques.

Note: In EP11, there is no DES support.

X

X

Imported secrets can be retained in the HSM in a limited number and can only be accessed through a key handle.

Note: Imported secrets can include keys or other important objects. The number of these secrets differs between CCA and EP11.

X

X

An unlimited number of secrets can be stored externally, protected by a master key or wrapping key (WK) providing confidentiality and integrity protection. EP11 also provides authenticity.

Note: the number of secrets is limited only by host memory.

X

X

 

Administrative Services / Security

Capability CCA EP11

Administrators are authenticated using digital signatures. Additionally, for CCA, the authentication determines which functions the administrator is allowed to perform.

X

X

The MK/WK can be comfortably managed (for example, loading and cloning) with a TKE.

X

X

MK/WK cloning enables back-up and/or redundant coprocessors to use the same local key blobs. MK/WK cloning uses split knowledge techniques and an M-of-N control to securely export the keys.

Note: Currently, in CCA, cloning of AES MKs is not supported.

X

X

MKs can be loaded as multiple cleartext key parts by trusted individuals using split knowledge and multiple control.

X

 

WKs can only be loaded encrypted using importer keys. The WKs can be split up into at maximum of eight parts.Administrators can specify how many key parts must be provided to reconstruct a WK using Shamir-secret key sharing. This allows to securely clone WKs to another domain or card.

 

X

Domain or Card Cloning: The administrative setup of domains or cards can be cloned and imported into different domains or cards. This is achieved by using a TKE.

X

X

Enhanced logon control capabilities, including stricter passphrase length and character requirements and the ability for users to change their own passphrases.

X

 

Administrative commands need to be signed by M-of-N administrators before the command is accepted by the coprocessor. The TKE stores the signing keys securely in smart cards protected by a PIN.

 

X

Administrators can enforce specific policies or control points (CPs) for objects and the usage of mechanisms. Some CPs also allow to disable complete algorithm classes like RSA or DSA, which allows an administrator to finely control what a user can do.

 

X

Allows to bind objects to specific operational modes enforcing the use of objects only on back ends where specific policies are activated. Operational modes refer to different FIPS, NIST and BSI standards and restrict algorithms (for example, key sizes) and disable known unsecure mechanism and attributes.

 

X

Access-control tracking can be performed on a role ID basis to gather information about which access control points are checked by the functions called from host applications.

X

 

An Audit Infrastructure is in place to log changes in the security policy and in the administrative state.

X

X

 

Financial Services

Capability CCA EP11  

EMV™ (EMVCo LLC) Secure Messaging is supported with functions that create secure messages to send keys and PINs to EMV smart cards.

X

 

Financial services support callable services for Visa Data Secure Platform with Point-to-Point Encryption (VDSP with P2PE), including Visa Format Preserving Encryption (VFPE).

X

 

ATM remote key loading is a method of secured transport of DES keys from a Hardware Security Module (HSM) to an ATM or other remote device using asymmetric techniques.

X

 

ATM and POS PIN-processing is supported through six services. PIN generation and verification services support several popular PIN-generation algorithms including customer-selected PIN options. A variety of PIN-block formats are processed with support for secure re-encryption and re-formatting of PIN blocks. ANSI X9.24 Derived Unique Key Per Transaction (DUKPT) PIN block encryption is supported, using both single-length and double-length DES keys. Additional services support the card verification value/card validation code/card security code (CVV/CVC/CSC) processes for the protection of card transactions.

X

 

Derived key support is available for dynamically creating DES keys from a key generating key in support of protocols such as those used with EMV smart cards.

X

 

 

Miscellaneous 

Capability CCA EP11

Enhanced firmware load security using ECDSA signatures and AES encryption.

X

X

Distributed Function Control Vector (FCV) format for use by the IBM PCIeCC3 and PCIeCC2. This FCV is digitally signed by IBM using a 521-bit ECC key using ECDSA. This provides an increased protection level compared to the FCV signed by IBM for the IBM PCIeCC, which has a 4096-bit key using ANS X9.31.

X

X

The system is stateless, keeping most of the secrets that are outside the HSM in wrapped and MACed form which allows for the maximization of throughput and for a potentially unlimited number of users. Hence, the system will never run out of memory because all objects are saved on a host system as wrapped content. Blob disposal is easy because only the corresponding object needs to be removed from host storage and memory.

 

X

The transport protocol that is used between the back end and the host library is documented and published.Vendors with specific requirements that are outside of the scope of the reference implementation can create their own host libraries.

Note: In EP11, the transport protocol is called the “Wire Format” and is part of the EP11 structure document.

 

X

Extensible through User Defined Extensions (UDX) or a complete rewrite of the card functions.

X