Application Security

Last edit: 2024.02.01

A number of minimum security requirements should be met for all commercially distributed products.

These requirements strengthen the product to prevent unauthorized access to all software applications and the hardware of the product.

Root certificates

TTDC itself and third party apps can establish secure connections to online services by validating server certificates against a list of known-safe root certificate authorities (Root CAs).

Trust establishment via certificate validation is mediated by the OS: applications by default trust any CA it provides. If the root CAs are compromised or misconfigured, there is a risk of attackers intercepting secure communications.

By default, the list of root CAs in the OS is too broadly scoped, and can be shortened to make for a narrower attack surface. Additionally, the CAs must be kept up to date to prevent using outdated or revoked certificates.

Secret hardcoding

Binaries (APK, system images, etc.) might end up in the wrong hands. TomTom and customers alike need to ensure any sensitive data packed inside deliverable code cannot be used to abuse or harm TomTom and customer online services: for example, by using OEM API keys to perform a DDoS attack.

Access to both TomTom and third party online services shall not rely solely on static credentials, such as API keys. Additional measures shall be enforced:

  • Setting up API proxies, which provide additional security controls such as rate limiting, analytics, usage quotas, et cetera.
  • Limit the scope of use of each API key to exactly one specific task to narrow the attack surface.
  • Perform key rotation.
  • Obfuscating keys might also be used to add another small layer of security.

Hardware key storage

We strongly recommend usage of a hardware-backed key store to all customers, against information disclosure and tampering attacks. Key stores give access to high quality cryptographic functionality, and to APIs to safely store and retrieve credentials both for our customers and the final user.

The primary concepts and implementation guidelines are available on the Android Source website.

Keys and credentials should be attested to ensure their certificate chain is valid and uncompromised: refer to the Android key attestation guide. It is necessary to verify that the device is actively using the hardware-backed keystore.

Using key stores should replace the usual SharedPreferences. A good entry point to start using hardware-backed keystores is through usage of EncryptedSharedPreferences from the androidx.security.crypto artifact.

Other guidelines and tips

A great number of other guidelines to improve security on an Android-based product are available on the Android Source website.