We proudly present a new maintenance release of our IAIK ECCelerate™ elliptic curve library! Version 4.01 adds support for curves from the FIDO ECDAA standard and fixes minor bugs. IAIK ECCelerate™ is based on Java 6 technology and has been thoroughly optimized for speed. Currently, it supports ECDSA, ECDH, ECIES and optionally ECMQV.
iSaSiLk 5.105 Maintenance release fixes some ECC related issues.
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 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.
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.