The Forest → crypto

• java
• cryptography
• pki

When reproducing, using, or extracting this text, always reference the source and the author : Ignacio Rondini

What’s JCA

The Java Cryptography Architecture is the part of the Java platform that defines a sets of APIs to perform cryptographic operations such as digital signatures, (d)encryption, message digest, certificates and cert validatios, etc. These api (interfaces) allow developers to use them so that :

• Applications are independent of the underlying implementation
• The actual implementations (providers) are interoperable across applications, so that a given app can work with different providers and a provider can work with different applications.
• The implementations can be extended.

The way this is achieved is through a Provider architecture. The java platform is delivered with some by default provider implementations and it can be extended by custom providers.

The architecture

JCA is designed to have:

• implementation independence and interoperability, and
• Algorithm independence and extensibility.

To enable algorithm independence, we have a diferentiation between the cryptografic engines or services, and the clases that actually provide the functionality of these engines. Engine classes are, for instnace, MessageDigest, Signature, KeyFactore etc. In this way, you have a MessageDigest that could have been generated by SHA-1 or SHA-256. Which in turn, it could have been created by different providers.

For each engine class, there is a matching abstract SPI (Service Provider Interface) class (for instance, MessageDigestSpi) with the methods that providers need to implement.

The provider architecture enables the implementation independence. They are package that implement one or more cryptografic services. There’s a default order on which the provider are selected to be used, but it can also be specified by the application.

JCE was an extension having for instance , MAC definitions, however, now it’s always bundled in JCA.

Example

An application needs a Cipher of type AES to encrypt things. It doesn’t care about the provider, so it doesn’t specify it.

Cipher c = Cipher.getInstance("AES");
c.init(ENCRYPT_MODE, key);

• The application calls the getInstance() factory methods of the Cipher engine class
• This method asks the JCA framework to find the first provider instance that supports “AES”.
• The framework consults each installed provider, and obtains the provider’s instance of the Provider class (which is just a class containing the available algorithms) algorithms). The framework searches each provider, and selecting the first that has the required entry (AES)
• This database class (the Provider class) entry points to the actual implementation class com.foo.AESCipher which extends CipherSpi, and is thus suitable for use by the Cipher engine class.
• An instance of com.foo.AESCipher is created, and is encapsulated in a newly-created instance of javax.crypto.Cipher, which is returned to the application.
• When the application calls init() operation on the Cipher instance, the Cipher engine class routes the request into the corresponding engineInit() backing method in the com.foo.AESCipher class.

Common engine classes

• Key generator
• Key pair generator
• KeyStore
• SecureRandom
• CertificateFactory
• Cert Path Validator

References

• https://docs.oracle.com/en/java/javase/11/security/index.html