General

The following list shows general security requirements your application must follow.

Use Release Variant of Thales SDK for Publishing Applications

Before publishing to the Apple App Store or Google Play, ensure the application uses the release variant of the SDK.

Warning

Utilizing a debug SDK variant in a production application can lead to serious security implications, potentially exposing sensitive data related to end users.

Removal of Debug Symbols

The application must not contain any debug symbols. This practice increases the complexity of reverse engineering efforts and prevents the easy identification of sensitive variables, structures, and logic.

Prevention of Sensitive Data Leaks

Careful life cycle management is required to prevent sensitive data leaks while the application is in the background. Remove any sensitive data from the UI before backgrounding. Wipe or encrypt sensitive data until the application returns to the foreground. Avoid logging sensitive data.

Code Obfuscation

To enhance the difficulty of reverse engineering the application:

• For Android applications, use sufficient obfuscation to conceal class names, function names, and public APIs of the Thales SDK. Also obfuscate sensitive strings used within the application.

• For iOS applications, obfuscation is recommended, but not mandatory, due to less mature tooling in this area.

Network Communication

It is strongly recommended that the application uses HTTPS for all network communication with its servers. Avoid self-signed certificates. Use these guidelines for certificate pinning:

• Ensure the hostname matches the Subject name of the leaf certificate.

• Verify that each certificate in the certificate chain is not expired.

• Verify that the chain of trust is valid and the certificate chain is validated with the system trust store.

• Verify that the SHA-256 hash of the root CA or leaf certificate matches the hardcoded hash within the application.

For confidential data containing personally identifiable information (PII), use an additional layer of encryption and authentication when sending data over TLS.

RASP Protection

It is highly recommended that the application uses commercial tools for Runtime Application Self Protection (RASP). This helps detect rooting or jailbreaking, hooking attempts, debugging, application tampering, and emulator usage.

Limit Log Usage

Be careful when writing on-device logs. Logs can provide useful information to attackers. Avoid logging critical information such as PII or other sensitive end user data. Remove logs in production builds by using obfuscation tools or conditional logging flags.

On Android, logs are a shared resource accessible with the READ_LOGS permission. Inappropriate logging of sensitive end user data can lead to unintended leaks to other applications.

Adoption of Secure Coding Practices

Follow established secure coding practices such as input validation, proper memory management, use of secure C functions, and avoiding the use of immutable containers for storing sensitive data. It is recommended to refer to the OWASP Secure Coding Practices Quick Reference Guide for more details. These practices can be enforced using static code analysis tools such as PMD or HP Fortify.

Audits and Penetration Testing

Conduct architecture and source code audits to thoroughly evaluate the security of the application. Additionally, perform a penetration test to simulate attacks on the application and device, as well as other system layers. This will aid in identifying vulnerabilities and assessing the overall security posture of the application.

Evaluate the Resilience of Application Security

The OWASP Mobile Application Security Verification Standard (MASVS) establishes baseline security requirements for mobile applications. It is highly recommended to use this checklist to evaluate the security posture of your application.