The following is a list of notable features Accrescent currently has. It is not exhaustive and not all features listed are exclusive to Accrescent, but they are some of the more distinguishing features and are intended to give the reader an idea of the benefits of Accrescent and how it works.
Accrescent's repository contains metadata files used by the client to retrieve apps and display info about them to the user. One of these pieces of metadata is signed by a key hardcoded into Accrescent to protect against tampering of sensitive information in the event the server is compromised. This signed metadata supports key rotation, is downgrade-protected, and a minimum revision hardcoded into Accrescent is regularly updated to protect new installations and sideloaded Accrescent updates from being served old metadata.Below is a list of what the signed metadata protects and the corresponding security implications for the user.
When a developer submits a new app to Accrescent, a hash of their app's public signing key is added to the signed repository metadata. This signing key hash is checked by the client every time it downloads the respective app. If it doesn't match, the installation is rejected.
This check is unnecessary for updates since Android already enforces key pinning for app updates. However, the OS takes a trust-on-first-use approach and doesn't provide a mechanism to verify that the initial installation was signed by the proper certificate, so pinning the certificate in signed metadata ensures that even the first installation is legitimate.
Each app in the signed metadata has a minimum expected version which is updated regularly. Accrescent will refuse to install a version of a given app less than its minimum version.
This check mitigates the threat of an attacker serving obsolete versions of apps. If a minimum version was not set, an attacker in control of the server could specify the latest version of a given app as an old version with known security vulnerabilities. Android already enforces downgrade protection for existing apps, so this threat is only applicable to users installing a given app for the first time.
Accrescent stores app names and icon hashes in signed metadata. These are used to verify the app names and icons displayed to the user in the client UI.
Signing these items makes it much more difficult for an attacker to trick a user into installing a malicious copycat app. If names and icons weren't verified, a malicious actor in control of the server could modify them and trick a user into installing a different app than they intend.
Accrescent supports unattended updates with or without privileged integration into the OS. By default, it will prompt for confirmation the first time an app is installed and perform updates in the background without prompting thereafter.
Accrescent also supports the privileged package management permissions on OSs which integrate it. When privileged, it will not prompt the user when installing or uninstalling apps.
Accrescent serves all apps as split APKs. This means that native code for different architectures, images for different screen densities, and strings for different languages aren't downloaded for a given device, saving bandwidth.
Accrescent doesn't sign apps itself. Developers sign (split) APKs with their own keys and upload them to Accrescent themselves.
This measure allows developers to maintain exclusive control over their app signing keys. Developers' signing keys cannot be compromised if Accrescent's servers are and Accrescent cannot deliver modified updates to developers' apps.
Accrescent pins Let's Encrypt root and intermediate TLS certificates for all connections to its repository. This feature mitigates the threat of a rogue/compromised certificate authority issuing a fraudulent certificate for the repository and initiating a man-in-the-middle attack.