TESI subproject : interfacing JCA/JCE with CDSA

Project presentation

The subproject TESI/Java interface consists in providing an interface between Java and CDSA framework. The goal is to make available to the Java applications, the quality of the CDSA services. This project can be divided in two parts : JCA-JCE to CDSA mapping and JCA-JCE extension to have all the CDSA functionality in JAVA applications.

This first version concerns the implementation of the first part.

This page is organized in four parts : CDSA introduction, JCA/JCE introduction, Architecture presentation and Implemented functionality.

This project is a part of the Trusted European Security Infrastructure (TESI) which aims to provide an open security platform.
The project is hosted here at SourceForge Logo.

CDSA introduction

The CDSA is a set of layered services and associated programming interface, providing an integrated and dynamic set of security services to applications.
This architecture has been defined following five principles :

  1.  a layered service provider model,
  2. open architecture,
  3. modularity and extensibility,
  4. value in managing the details,
  5. embrace emerging technologies.

The basic layers of the architecture are :

CDSA contains several basics modules :

These module provide a lot of functionality , including all the JCA-JCE functionality.

Figure 1 : CDSA representation

JCA/JCE introduction

JCA API has been developed to introduce both low-level and high-level security functionality in JAVA applications.
Its main functionality is :

 JCE API extends JCA to include :

 JCA and JCE API have been defined around two principles :

  1. implementation independence and interoperability,
  2. algorithm independence and extensibility.

Therefore the engine classes and provider concepts have been introduced.

Architecture presentation

Constraints and goals :


The architecture contains four layers (Figure 1: Interface layers):

  1. The JCA-JCE layer,
  2. The generic layer : generic SPI and generic keys, certificates...
  3. The JCA-JCE C++ version layer,
  4. The CDSA layer.

Each CSP provider gives also some CSP to CDSA and a “provider package” to the second layer.

figure 2 : Interface layers


The diagram below shows the relations between components used to interface the Cipher part of JCA-JCE to CDSA.

Figure 3 : implementation diagram with the Cipher example

In this example, we have 2 providers. The ProviderA class indicates to JCA-JCE that it has one service, the Cipheralgo1 class. The ProviderB class indicates to JCA-JCE that it has 2 services, the Cipheralgo2 and Cipheralgo3 class.
The Cipher class delegates to the CipherSpi the execution of the cryptographic operations. The application only use the Cipher class and so don’t know anything of the implementation used.
Here, we have 3 implementations for the CipherSpi class: Cipheralgo1, Cipheralgo2, Cipheralgo3. These classes only have a constructor that gives parameters to the GenericCipherSpi class.
All the logic to perform the cryptographic operations is embedded in the GenericCipherSpi class. It calls the CDSACipherSpi class with the parameters given by the constructors of Cipheralgo1, Cipheralgo2, and Cipheralgo3. These parameters are used by CDSACipherSpi to identify the CDSA CSP to use for the 3 SPI: here, it’s CSP1 and CSP2.
The CDSACipherSpi class use threw CDSA these 2 CSP and performs the cryptographic operations

Functionality implemented

In the figure below, green elements are implemented in the JCA-JCE interface, the red ones are not implemented and the blue ones are JCA-JCE elements which use JCA-JCE modified elements.

Figure 5 : functionality implemented