The Conscrypt module accelerates security improvements and improves device security without relying on OTA updates. It uses Java code and a native library to provide the Android TLS implementation as well as a large portion of Android cryptographic functionality such as key generators, ciphers, and message digests. Conscrypt is available as an open source library, though it has some specializations when included in the Android platform.
The Conscrypt module uses BoringSSL, a native library that is a Google fork of OpenSSL and which is used in many Google products for cryptography and TLS (most notably Google Chrome), in conjunction with Conscrypt code (both Java and native code). BoringSSL doesn't have official releases (all users build from head) and makes no guarantees around API or ABI stability.
Changes in Android 15
Android 15 restricts the usage of TLS versions 1.0 and 1.1. These versions had previously been deprecated in Android, but are now disallowed for apps targeting Android 15.
Changes in Android 14
Android 14 introduces an updatable root trust store within Conscrypt. CA certificates (or certs) provide the roots of trust for public keys used within Android and the internet at large. These certificates are routinely checked to ensure proper cryptographic signing, so they must be provided and stored on all devices that rely on them.
Prior to Mainline, Android stored certificates in the system partition (in
system/ca-certificates
) and updated them with every Android release. Now with Mainline,
it's possible to update certificates more frequently using Mainline train updates. This new
capability should streamline updating processes, allow us to have faster turnaround times for
issues, and help to extend device lifetimes.
Starting in Android 14, root trust certificates are stored in the Conscrypt
module APEX and the system partition. Apps can still choose their own certificates and modify
certificate behavior using NetworkSecurityConfig
.
Android 14 includes these other Conscrypt module changes:
- Added AES-CMAC MAC implementation.
- Deprecated and removed `PBEwithHmacSHA2-*` MAC implementations.
- Added limited support for X25519 keys, key agreements, and signatures.
- Updated BoringSSL for X.509 correctness.
- Dropped support for MD5-signed certificates in the public CertPath APIs. Such certificates haven't been accepted for TLS connections since API level 16.
Changes in Android 10
Android 9 doesn't include an Android-specific public API for Conscrypt but
instead uses a security provider that implements standard classes for Java
Cryptography Architecture (JCA) including Cipher and MessageDigest, and
Java Secure Socket Extension (JSSE), including SSLSocket and SSLEngine.
Users interact with those classes and some nonpublic Conscrypt APIs are used
by libcore
or frameworks code.
Android 10 adds a small number of public API methods
in android.net.ssl
to access Conscrypt functionality that isn't
exposed by the classes under javax.net.ssl
. Android
10 also includes a slimmed copy of
Bouncy Castle to provide lower-popularity cryptographic
tools as part of Android Runtime (not included in the Conscrypt module).
Format and dependencies
The Conscrypt module (com.android.conscrypt
) is distributed as an APEX file that
includes the Conscrypt Java code and a Conscrypt native library that dynamically
links to Android NDK libraries (such as liblog
). The native library
also includes a copy of BoringSSL that has has been validated (Certificate #3753) through NIST's Cryptographic Module Validation Program (CMVP).
The Conscrypt module exposes the following APIs:
- Public APIs are extensions of classes and interfaces in
packages under
java.*
andjavax.*
, plus classes underandroid.net.ssl.*
. External app code doesn't call Conscrypt directly. Platform API standards ensure that these APIs remain backward- and forward-compatible. - Core platform APIs are hidden APIs used by the framework
to access nonpublic functionality. These are relatively limited; the largest
user is
NetworkSecurityConfig
, which extends the Conscrypt trust manager (the component that verifies certificates) to implement the network security configuration feature. - Intra-core APIs are limited to zero-argument constructors called reflectively by the JCA and JSEE machinery.