The JCE CC Core is a Common Criteria evaluated version of most of the cryptographic functionality of the IAIK-JCE toolkit.

Main Features

The JCE CC Core provides the core functionality of the IAIK JCE toolkit, it contains several cryptographic algorithms which passed a Common Criteria evaluation.

For further details about the Common Criteria Certification, please see
See Website



The CC Core requires Java™ version 1.1, 1.2, 1.3, 1.4, 1.5 or compatible. In addition, it requires a JCE framework which is compatible to JCE 1.2 or later. To ensure secure operation, access to the operating environment must be protected against unauthorized access. Despite the application, the operating environment contains at least the Java™ VM with all runtime classes. In practice, it will usually be necessary to protect the access to the complete host system, including access on operating system level as well as physical access.
You can find more detailed information about the environment in the chapter security environment.

Pricing and Licensing

For current prices of IAIK-JCE CC Core, please see our price list and license conditions .
See Prices


To order the product, please contact our sales office:

Send E-Mail

The CC Core security environment describes the security aspects of the environment in which the CC Core is intended to be used and the manner in which it is expected to be employed. To this end, the CC Core environment identifies and lists the assumptions made on the operational environment (including physical and procedural measures) and states the intended method of use of the product.

The environment of the CC Core must meet the following criteria:

  • The CC Core and its environment are protected in such a way that it is impossible for an attacker to read or modify any data managed by the CC Core.
    Note: In practice this means that you must ensure that no attacker can access the Java™ VM, the operating system or the host hardware in a manner that would enable him to read or modify keys or data managed by the CC Core. This includes input data, MAC values, hash values, signature values, cipher text, keys, random numbers and the seed of the random number generator.
    Only the application should have access to the CC Core. The environment must also protect the CC Core against side-channel attacks; e.g. timing or power analysis attacks. Please read also the note about blinding below.
    Note: The administrator has to be able to set up the Java™ environment according to the requirements listed in this document. Moreover, he must verify the CC Core’s integrity as described in the separate guidance document.
  • The developer uses the CC Core in the right way as described in the manual. In order to reach Strength-of-Function high, the Developer must use the key sizes recommend in the manual.
    Note: The developer using the CC Core must strictly follow the instructions of the IAIK-JCE toolkit documentation and especially of this document.
  • The environment must provide a suitable seed for the random number generator. Furthermore, it must ensure that the seed is kept secret.
    Note: The seed can come from the application or the Java™ runtime environment. The seed must meet the requirements given in Random Generation Functions. In addition, it must be impossible for an attacker to read the seed.
  • The environment is responsible for key management. Key management is out of scope of the CC Core. Private keys and secret keys needed for computation of ciphertexts, MACs and signatures must be provided by the application. The CC Core does not generate or destruct keys. Given key material won’t be modified or stored by the CC Core.
    Note: The provided keys must meet the key sizes as specified in this document. The CC Core does not check the quality of the keying material; e.g. if a key is a weak key for Triple-DES, or if the key contains only zero-value bytes. The CC Core does not verify the provided keys, it uses them as given. The CC Core will not store keys to temporary files nor will it pass them outside the operation environment by other means. Furthermore, the environment must protect the keys against unauthorized read and write access.
    The environment has to ensure that the keys used with a certain algorithm are compliant with the according standard which specifies the algorithm. The subsection for each algorithm refers to this underlying standard. Moreover, the environment must ensure appropriate key generation and destruction in accordance with the respective standard. If this standard does not specify a method for key destruction, the environment should ensure that the memory area which contains the key material is inaccessible to unauthorized entities; e.g. the environment must zero out the memory which contains the key material before this memory area may get reclaimed by other processes.
  • The administrator or the developer has to install a Java™ VM that works according to
    o Java™ VM Specification 1.0.2 with the Java™ 1.1 API or
    o Java™ VM Specification 1.2 with one of the following APIs:
    + Java 2 Standard Edition 1.5.x
    + Java™ 2 Standard Edition 1.4.x
    + Java™ 2 Standard Edition 1.3.
    + Java™ 2 Standard Edition 1.2.x

    Note: The different versions for a major version of Java™ 2 Standard Edition have the same API. There are no differences in the API which would have an impact on the CC Core; e.g. Java™ 2 Standard Edition 1.4.1 and Java™ 2 Standard Edition 1.4.2 have the same API for all parts relevant to the CC Core. The Java™ 2 Standard Edition 1.4 and 1.5 already contain a JCE framework. Please refer to the next item in this list.

  • If the Java™  API in use is older than version  1.4.x  (i.e.  1.1.x ,  1.2.x  or  1.3.x ), the administrator or the developer has to install a JCE framework that works according to the  JCE 1.2  , JCE  JCE 1.2.1  or  JCE 1.2.2  specification.
    Note: The Java™ 2 Standard Edition version 1.4 and 1.5, often referred to simply as Java™ 1.4 and Java 1.5 (or also Java 5), already contain a JCE framework implementation. Thus, a separate implementation is not required. The JCE API documentation for Java™ 1.4 is part of the Java™ 1.4 API documentation. For Java™ 1.5 it is part of the Java 1.5 API documentation . For older Java™ versions a JCE framework is available separately as the JCE 1.2.2 API.

The complete CC Core consist of pure Java™ code. During operation sensitive data and key material will be present in the memory of the host system which runs the Java™ VM. Thus, the operation environment must ensure that only authorized users and software has access to the CC Core and its memory during operation. In practice, this will usually require protection of all lower-level system components like the Java™ VM, the operating system, firmware and hardware. Unauthorized access to any of these lower-level components can compromise the CC Core. The application or the environment should ensure that key material is erased if it is no longer used. The default zeroize feature of memory of the Java™ VM or the underlying operating system is sufficient if this addresses all copies of the keying material.

Even though the CC Core supports blinding for RSA private key operations, the application or the operation environment must provide measures to counter side-channel attacks like power-analysis or timing attacks if blinding is insufficient or not applicable. Current state-of-the-art in science assumes that this type of blinding is sufficient to counter timing attacks (see P. Kocher, “Timing attacks on implementations of Diffie -Hellman, RSA, DSS, and other systems”, in Proceedings of Cyrpto 96, LNCS 1109, Springer, 1996, pp. 104–113; and Brumley D., Boneh D., “Remote Timing Attacks Are Practical”, in Proceedings of the 12th USENIX Security Symposium, 2003, pp. 1-14). The blinding feature of the CC Core works for RSA CRT (Chinese Remainder Theorem) private keys and is switched on by default. Blinding can be switched on and off in the RSACipher class.

The functions of the CC Core are accessed through the JCA API and JCE API. These APIs define the general behavior of the CC Core functions to the application. This includes general requirements for the input and output values as well as the error behavior. Error behavior includes the definition of checked exceptions that constructors and methods may throw. If a certain function of the CC Core uses parameter classes not specified in the JCA API or JCE API, such additional classes will be described in the chapter for this specific function.

The CC Core contains the following list of cryptographic functions. These cryptographic functions are called TOE (Target of Evaluation) Security Functions (short TSFs) in the context of Common Criteria. Therefore, the list contains the code of each TSF group and of each individual TSF in braces. This code identifies each TSF in the Security Target (ST).

  • SHA-1 (FCS_COP.1/SHA-1)
  • SHA-256 (FCS_COP.1/SHA-256)
  • SHA-384 (FCS_COP.1/SHA-384)
  • SHA-512 (FCS_COP.1/SHA-512)
  • RIPEMD-160 (FCS_COP.1/RIPEMD-160)
  •  Simple Hash-Based Random Functions (FCS_RND.1/HashRandom)
    based on SHA-1, SHA-256, SHA-384, SHA-512, and RIPEMD-160
  •  FIPS 186-2 Random Functions (FCS_RND.1/FipsRandom)
    based on SHA-1, SHA-256, SHA-384, SHA-512, and RIPEMD-160


Signature Schemes (TSF.Signature)

  •  RSA Signatures according to PKCS#1 version 1.5 (FCS_COP.1/RSASignature)
    in combination with SHA-1, SHA-256, SHA-384, SHA-512, and RIPEMD-160
  •  RSA PSS Signatures according to PKCS#1 version 2.1 (FCS_COP.1/RSASignaturePSS)
    in combination with SHA-1, SHA-256, SHA-384, SHA-512, and RIPEMD-160
  • Triple-DES (FCS_COP.1/TripleDES)
  • RC2 (FCS_COP.1/RC2)
  • RSA Encryption according to PKCS#1 version 1.5 (FCS_COP.1/RSACipher)
  • RSA OAEP Encryption according to PKCS#1 version 2.1 (FCS_COP.1/RSACipherOAEP)
  •  Hash-Based MAC Functions (FCS_COP.1/HMAC)
    based on SHA-1, SHA-256, SHA-384, SHA-512, and RIPEMD-160

Please note that the IAIK-JCE toolkit contains more cryptographic functions than those in the CC Core, but only those of the CC Core have been evaluated. Moreover, the IAIK-JCE toolkit may offer additional features of an algorithm which is part of the CC Core. For example, the CC Core contains RSA signatures with key sizes starting from 1024 bit. The IAIK-JCE supports also shorter key sizes like 512 bit for RSA, but if an application uses 512 bit RSA keys, it uses the IAIK-JCE outside the specifications of the CC Core. 512 bit RSA is not covered by the evaluation.

JCE CC Core 3.1: This version was evaluated at EAL 3+ in May 2004 by the German TÜV IT. As this is an intermediate assurance level, the certificate is only valid in Germany.

JCE CC Core 3.15: Version 3.15 has achieved EAL 3 in July 2007. The evaluation was carried out by the German TÜV IT and JISEC in Japan. This certificate is internationally accepted, see http://www.commoncriteriaportal.org/.

Please note that the surrounding IAIK-JCE toolkit may have a higher version number than the CC Core; e.g. the CC Core may have the version identification IAIK-JCE CC Core 3.16 whereas the surrounding toolkit may be IAIK-JCE 3.2. This ensures that the CC Core is exactly that version which has been evaluated.

Class or Package Bug / Change / New Feature Description and Examples
Class or Package Bug / Change / New Feature Description and Examples

Any questions?

Don‘t hestitate to ask us about our products.

Contact us