Carding
Professional
- Messages
- 2,870
- Reaction score
- 2,511
- Points
- 113
The developers of the HTTP Toolkit, an open toolkit for inspecting HTTPS traffic, have noticed a change in the way certificate authority (CA) certificates are updated in the upcoming release of the Android 14 platform. System certificates will no longer be tied to the firmware, but will be delivered as a separate package, updated via Google Play .
This approach will make it easier to maintain up-to-date certificates and remove certificates from compromised certification authorities, and will also prevent device manufacturers from manipulating the list of root certificates and make the process of updating them independent of firmware updates. On the other hand, the new delivery method will not allow the user to make changes to system certificates, even if he has root access to the system and has full control of the firmware.
Instead of the /system/etc/security/cacerts directory, certificates in Android 14 are loaded from the /apex/com.android.conscrypt/cacerts directory, housed in a separate APEX (Android Pony EXpress) container, the contents of which are delivered via Google Play, and the integrity is digitally controlled signed by Google. Thus, even if a user has full control of the system with root rights, without making changes to the platform, he will not be able to change the contents of the list of system certificates. The new certificate storage scheme could cause difficulties for developers involved in reverse engineering, traffic inspection, or firmware research, and could potentially complicate the development of projects developing alternative Android-based firmware, such as GrapheneOS and LineageOS.
The change only affects system CA certificates, which are used by default in all applications on the device, and does not affect the processing of user certificates or the ability to add additional certificates for individual applications (for example, the ability to add additional certificates for the browser remains). At the same time, the problem is not limited only to the package with certificates - as the functionality of the system is moved to separately updated APEX packages, the number of system components that cannot be controlled and changed by the user will increase, regardless of the presence of root access to the device.
This approach will make it easier to maintain up-to-date certificates and remove certificates from compromised certification authorities, and will also prevent device manufacturers from manipulating the list of root certificates and make the process of updating them independent of firmware updates. On the other hand, the new delivery method will not allow the user to make changes to system certificates, even if he has root access to the system and has full control of the firmware.
Instead of the /system/etc/security/cacerts directory, certificates in Android 14 are loaded from the /apex/com.android.conscrypt/cacerts directory, housed in a separate APEX (Android Pony EXpress) container, the contents of which are delivered via Google Play, and the integrity is digitally controlled signed by Google. Thus, even if a user has full control of the system with root rights, without making changes to the platform, he will not be able to change the contents of the list of system certificates. The new certificate storage scheme could cause difficulties for developers involved in reverse engineering, traffic inspection, or firmware research, and could potentially complicate the development of projects developing alternative Android-based firmware, such as GrapheneOS and LineageOS.
The change only affects system CA certificates, which are used by default in all applications on the device, and does not affect the processing of user certificates or the ability to add additional certificates for individual applications (for example, the ability to add additional certificates for the browser remains). At the same time, the problem is not limited only to the package with certificates - as the functionality of the system is moved to separately updated APEX packages, the number of system components that cannot be controlled and changed by the user will increase, regardless of the presence of root access to the device.
