...
The SmartCardCryptoFactory uses the SmartCardCryptoFunctions- and SmartCardPersistentMemoryFunctions-interfaces defined in the CORE SDK. Both interfaces need to be implemented at the smartcard layer.
The JCE SDK already implements generalized SPI classes for all the ones mentioned in 1.3. Usually someone has to extend from one of the Java SPI classes in order to implement a single algorithm. Our SPI classes are implemented more generally and not algorithm specific since they shall support dynamic loading i.e. when a provider detects that a card is present it querys which hardware algorithms are supported by the smartcard and adds them as its provided services. Of course we could implement each supported algorithm as own SPI class but we found a solution making our providers quite more flexible.
First we analized the Java SPI classes and extracted all abstract functions to own SPI interfaces (com.certgateAirID.sdk.jce.crypto.interfaces). These interfaces are defined within the JCE SDK. Then we extended and implemented the Java SPI classes (com.certgateAirID.sdk.jce.crypto.spis) which later make use of the objects implementing the SPI interfaces. For provider implementations it is usually necessary to exactly know which algorithms are supported. Our design avoids that circumstance and allows us to dynamically load the smartcards supported algorithms. Furthermore this design allows us that the JCE SDK already provides the whole logic for implementing a provider – only the implementations of our SPI interfaces need to be additionally delivered. This gives us the opportunity to deliver pre-signed code running on all machines on Oracle Java systems it is necessary to sign the provider with an Oracle signed certificate. Otherwise Cipher SPI objects will not operate with the Oracle Java JCE!. Figure 4 illustrates the hirarchie of the concept. See 2.4.5 for more details.
...