- Latest (GraalVM for JDK 21)
- Dev Build
- GraalVM for JDK 21
- GraalVM for JDK 20
- GraalVM for JDK 17
- GraalVM 22.3
- GraalVM 22.2
- GraalVM 22.1
- GraalVM 22.0
- GraalVM 21.3
- Getting Started with Native Image
- Native Image Basics
- Build Overview
- Reachability Metadata
- Optimizations and Performance
- Debugging and Diagnostics
- Dynamic Features
- Accessing Resources
- Certificate Management
- Dynamic Proxy
- Java Native Interface
- JCA Security Services
- URL Protocols
- Interoperability with Native Code
- LLVM Backend
- Workshops and Labs
JCA Security Services in Native Image
This page explains Native Image support of the Java Cryptography Architecture (JCA) framework.
The JCA framework uses a provider architecture to access security services such as digital signatures, message digests, certificates and certificate validation, encryption (symmetric/asymmetric block/stream ciphers), key generation and management, and secure random number generation, etc.
To achieve algorithm independence and extensibility it relies on reflection, therefore it requires a custom configuration in Native Image.
By default the
native-image builder uses static analysis to discover which of these services are used (see next section for details).
The automatic registration of security services can be disabled with
Then a custom reflection configuration file or feature can be used to register the security services required by a specific application.
Note that when automatic registration of security providers is disabled, all providers are, by default, filtered from special JDK caches that are necessary for security functionality.
In this case, you must manually mark used providers with
Security Services Automatic Registration #
The mechanism, implemented in the
com.oracle.svm.hosted.SecurityServicesFeature class, uses reachability of specific API methods in the JCA framework to determine which security services are used.
Each JCA provider registers concrete implementation classes for the algorithms it supports.
Each of the service classes (
KeyStore, etc.) declares a series of
getInstance(<algorithm>, <provider> factory methods which provide a concrete service implementation.
When a specific algorithm is requested, the framework searches the registered providers for the corresponding implementation classes and dynamically allocates objects for concrete service implementations.
native-image builder uses static analysis to discover which of these services are used.
It does so by registering reachability handlers for each of the
getInstance() factory methods.
When it determines that a
getInstance() method is reachable at run time, it automatically performs the reflection registration for all the concrete implementations of the corresponding service type.
Tracing of the security services automatic registation can be enabled with
The report will detail all registered service classes, the API methods that triggered registration, and the parsing context for each reachable API method.
--enable-all-security-servicesoption is now deprecated and it will be removed in a future release.
Provider Registration #
native-image builder captures the list of providers and their preference order from the underlying JVM.
The provider order is specified in the
java.security file under
New security providers cannot be registered at run time; all providers must be statically configured at executable build time.
Providers Reordering at Run Time #
It is possible to reorder security providers at run time, however only existing provider instances can be used.
For example, if the
BouncyCastle provider is registered at build time and you want to insert it at position 1 at run time:
Provider bcProvider = Security.getProvider("BC"); Security.removeProvider("BC"); Security.insertProviderAt(bcProvider, 1);
SecureRandom implementations open the
/dev/urandom files which are used as sources.
These files are usually opened in class initializers.
To avoid capturing state from the machine that runs the
native-image builder, these classes need to be initialized at run time.
Custom Service Types #
By default, only services specified in the JCA framework are automatically registered. To automatically register custom service types, you can use the
Note that for automatic registration to work, the service interface must have a
getInstance method and have the same name as the service type.
If relying on the third-party code that does not comply to the above requirements, a manual configuration will be required. In that case, providers for such services must explicitly be registered using the
-H:AdditionalSecurityProviders option. Note that these options are only required in very specific cases and should not normally be needed.