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.
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.
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).
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 |
|---|