JAVA Toolkit
| home | contact

Home > Products > Core Crypto Toolkits > JCE CC CORE > security environment

News Menu

Latest News

IAIK-JCE 5.60 and IAIK [CP]AdES 2.4 released!


IAIK-JCE 5.60 introduces a "subsidiary" provider as workaround for fixing a JDK JSSE MessageDigest Cloneable bug. IAIK [CP]AdES 2.4 fixes a bug in the AtsHashIndexv3 ASN.1 representation.

ECCelerate 6.01 released!


We proudly present a new maintenance release of our IAIK ECCelerate™ elliptic curve library! Version 6.01 fixes minor bugs and streamlines ECPoint return types as well as other improvements. IAIK ECCelerate™ is based on Java 6 technology and has been thoroughly optimized for speed. Currently, it supports ECDSA, EdDSA, ECDH, X25519/448, ECIES and optionally ECMQV.


Our Clients

Security Environment

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 (see Security Targets on JCE CC core main page).

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.


print    tip a friend
back to previous page back  |  top to the top of the page