Using Cryptography Extensions

This release provides an implementation of basic security and cryptography classes. These implementations are supported by:

For more information on the SHA1, DES, 3DES, and RSA encryption schemes, see:

Supported Cryptography Classes

The implementation of security and cryptography in version 2.2.1 of the Java Card reference implementation supports the use of the following classes:

TABLE 37 lists the cryptography algorithms that are implemented for CREF and Java Card WDE:

TABLE 37 – Algorithms Implemented by the Cryptography Classes
Class	Algorithm
`Checksum`	`ALG_ISO3309_CRC16`—ISO/IEC 3309-compliant 16-bit CRC algorithm. This algorithm uses the generator polynomial: `x^16+x^12+x^5+1`. The default initial checksum value used by this algorithm is 0. This algorithm is also compliant with the frame-checking sequence as specified in section 4.2.5.2 of the ISO/IEC 13239 specification. `ALG_ISO3309_CRC32`—ISO/IEC 3309-compliant 32-bit CRC algorithm. This algorithm uses the generator polynomial: `X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8 +X^7+X^5+X^4+X^2+X+1`. The default initial checksum value used by this algorithm is 0. This algorithm is also compliant with the frame-checking sequence as specified in section 4.2.5.3 of the ISO/IEC 13239 specification.
`Cipher`	`ALG_DES_CBC_ISO9797_M2`—provides a cipher using `DES` in `CBC` mode. This algorithm uses `CBC` for `DES` and `3DES`. Input data is padded according to the ISO 9797 method 2 (ISO 7816-4, EMV’96) scheme. `ALG_RSA_PKCS1`—provides a cipher using `RSA`. Input data is padded according to the `PKCS#1` (v1.5) scheme. `ALG_AES_BLOCK_128_CBC_NOPAD`—provides a cipher using `AES` with block size 128 in CBC mode and does not pad input data.
`KeyAgreement`	`ALG_EC_SVDP_DH`—elliptic curve secret value derivation primitive, Diffie-Hellman version, as per [IEEE P1363]. `ALG_EC_SVDP_DHC`—elliptic curve secret value derivation primitive, Diffie-Hellman version, with cofactor multiplication, as per [IEEE P1363].
`KeyBuilder`	the algorithms define the key lengths for: 128-bit `AES` 64-bit `DES` 112-, 128-, 160-, 192-bit `ECC` 128-bit `DES3` 512-bit `RSA`
`KeyPair`	the algorithms define the key lengths for: 112-, 128-, 160-, 192-bit `ECC` 512-bit `RSA`
`MessageDigest`	message digest algorithm `SHA1`
`RandomData`	pseudo-random number generator with a 48-bit seed, which is modified using a linear congruential formula.
`Signature`	`ALG_DES_MAC8_ISO9797_M2`—generates an 8-byte `MAC` (most significant 8 bytes of encrypted block) using `DES` or `3DES` in `CBC` mode. This algorithm uses `CBC` for `DES` and `3DES`. Input data is padded according to the ISO 9797 method 2 (ISO 7816-4, EMV’96) scheme. `ALG_RSA_SHA_PKCS1`—encrypts the 20 byte `SHA1` digest using `RSA`. The digest is padded according to the `PKCS#1` (v1.5) scheme. `ALG_AES_MAC_128_NOPAD`—generates a 16-byte MAC using `AES` with blocksize 128 in CBC mode and does not pad input data. `ALG_ECDSA_SHA`—signs/verifies the 20-byte SHA digest using ECDSA.

Instantiating the Classes

Implementations of the cryptography classes extend the corresponding base class with implementations of their abstract methods. All data allocation associated with the implementation instance is performed when the instance is constructed. This is done to ensure that any lack of required resources can be flagged when the applet is installed.

Each cryptography class, except KeyPair, has a getInstance method which takes the desired algorithm as one of its parameters. The method returns an instance of the class in the context of the calling applet. Instead of using a getInstance method, KeyPair takes the desired algorithm as a parameter in its constructor.

If you request an algorithm that is not listed in TABLE 37 or that is not implemented in this release, getInstance will throw a CryptoException with reason code NO_SUCH_ALGORITHM.

Temporary RAM Usage by Cryptography Algorithms

The implementation of the RSA and EC cryptography algorithms in CREF optimizes RAM usage. To do this, CREF dynamically allocates temporary memory areas in RAM. These temporary RAM areas are allocated for the duration of a native method call.

Note that the amount of RAM available in the RTR and non-current DTR can be influenced by applets other than the one currently selected. This means that the current applet which uses the RTR and non-current DTR might fail if more applets are installed on the card.

When execution completes, CREF prints maximum memory usage in each of these areas to help you track the memory requirements of the cryptography algorithms in your own Java Card VM implementations.

Chapter 14