Directrices de seguridad para Android

There are several security guidelines for Android which includes the protection at application level, data protection, data authentication, cryptographic guidelines, application hardening, secure coding tips, general security tips, and D1 obfuscation.

Application-level protection

Verify the installer of your application

To ensure that the application is distributed through the official Google Play Store, you should verify that the installer package name is com.android.vending. This helps to prevent side-channel distribution or unauthorized installations from third-party sources.

Force application update

Whenever a security update is available for your application on the Play Store, your application should force an update before the end user can continue to use the service. This ensures that the end user is always using the latest version of the issuer application with the necessary security fixes.

Store application resources only in internal storage

Storing application resources in the internal storage (instead of external storage) mitigates the risk of a "Man-in-the-Disk" (MITD) attack. This means that the application should not allow itself to be moved to external storage using the android:installLocation manifest attribute.

Compatibility with D1 SDK supported OS versions

The application should be designed to run on devices with OS versions supported by the D1 SDK. This ensures that the end user has a consistent and reliable experience while using the application.

Enable device lock screen

It is recommended that the application checks that the device is protected with the PIN, pattern, or password by using the following code snippet:

KeyguardManager kgManager = (KeyguardManager) context.getSystemService(Context.KEYGUARD_SERVICE);
kgManager.isDeviceSecure()

Prevent excessive permissions

It is recommended that the application declares only the required Android permissions otherwise an adversary can gain access to the privileged information.

Platform security exported attributes

Android applications are composed of one or more of the following components:

• Activities

• Services

• Broadcast receivers

• Content providers

When using each of these components, be aware of the possible risks and the attacks associated. Generally, inter-application communication is risky. Consider designing your application with only your main activity made publicly accessible. All other components should explicitly have the attribute export=false. For other components to be public, consider protecting them with custom permissions.

Disable application debugging in release variant

To remove the debug mode, you have to explicitly set the android:debuggable attribute of the <application> element to false in the Android manifest file. Ensure that the final APK is not debuggable by performing the following checks:

aapt d xmltree <myApplication.apk> AndroidManifest.xml

After verifying the final APK, ensure that the attribute is present with a value 0x0. You may automate this check in the build process.

Evaluate app links and deep links

Any existing deep links and app links can potentially increase the attack surface of the issuer application. This includes various security risks such as link hijacking, sensitive functionality exposure as in the following Android versions:

• Before Android 12 (API level 31), if the issuer application has any non-verifiable links, it can cause the system to not verify all Android App Links for that issuer application.

• Starting from Android 12 (API level 31), the issuer application benefits from a reduced attack surface. Unless the target issuer application is approved for the specific domain contained in that web intent, a generic web intent resolves to the end user’s default browser application.

All deep links must be enumerated and verified for correct website association. The operations performed must be thoroughly tested, especially all input data which are considered untrustworthy should always be validated. Validation ensures that only the data the application is expecting is processed.

Prevent auto-generated screenshot

Sensitive data leak through screenshots in the foreground can be prevented by using the application's Activity.onCreate method:

getWindow().addFlags(LayoutParams.FLAG_SECURE);.

You can also use the onPause() method of your activities to clear other sensitive information that should not be kept in the memory while the issuer application is running in the background.

Proper issuer application signing

Ensure that the release build has been signed via both the v1 and v2 schemes for Android 7.0 (API level 24) and later, and via all three schemes for Android 9 (API level 28) and later.

The developer is the owner of the code-signing certificate in the APK.

APK signatures can be verified using the apksigner tool which is available at [SDK-Path]/build-tools/[version].

$ apksigner verify --verbose Desktop/example.apk
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Number of signers: 1

Prevent backup of issuer application data

To prevent the backup of application data, set the allowBackup attribute to false in the application tag of the AndroidManifest.xml file.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
    <application
        android:allowBackup="false">
    </application>
</manifest>

By default, the android:allowBackup attribute is set to true. When this flag is set to true, the application data can be backed up and restored by the end user. However, this may have security consequences for an application.

The backup feature allows end users who have enabled USB debugging to copy application data from the device. Once the data is backed up, all the application data can be read by the end user.

Setting allowBackup="false" allows the application to opt out of both backup and restore capabilities.

Prevent accessibility on sensitive screens

The accessibility service on Android is a powerful feature that allows users with disabilities to interact with their devices in new ways. However, this functionality also comes with potential security risks as the accessibility service can be abused to steal sensitive data or control the device.

As there are growing numbers of malwares targeting banking and payment issuer applications, the issuer application determines if sensitive contents need to be read by the accessibility apps installed on the device. The following techniques are used to detect the presence of accessibility apps and to prevent sensitive data from being emitted through accessibility events. Exercise caution when performing the following checks as as they may make it difficult for end users with disabilities to use your issuer application.

Detect an active accessibility service

Check if there are any active accessibility services currently running. If any accessibility service is present, you can use this technique to limit the functionality of your issuer application.

Check the list of allowed accessibility services

A system API is available to get the enabled and running accessibility services. You can maintain a whitelist/blacklist of the allowed accessibility apps and their capabilities. If there are any unwanted accessibility services running in the background, you can warn the end user about it, abort the operation or prompt the end user to disable the accessibility services.

Disable accessibility access to a view

An alternative to detect accessibility apps installed on the device is to disable accessibility access of a view. This will prevent all accessibility events from the view and its subviews.

private void disableAccessibilityEvent() {
    ViewCompat.setImportantForAccessibility(this, ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS)
}

Prevent accessibility events emitting from EditText views

By default, the system EditText for passwords will show the input value for a short while (say 1.5 seconds) before masking it into a dot, so accessibility services may receive texts such as "***1", "*****3". The following code snippet is an intuitive way to hide such sensitive input values from the accessibility apps

private fun hideLastDigit() {
    transformationMethod = SecureTransformationMethod()
}

class SecureTransformationMethod : PasswordTransformationMethod() {
    override fun getTransformation(source: CharSequence?, view: View?): CharSequence {
        if (source == null) return SecureCharSequence("")
        return SecureCharSequence(source)
    }

    class SecureCharSequence(private val charSequence: CharSequence) : CharSequence {
        override val length: Int
            get() = charSequence.length

        override fun get(index: Int): Char {
            return 'x'
        }

        override fun subSequence(startIndex: Int, endIndex: Int): CharSequence {
            return SecureCharSequence(charSequence.subSequence(startIndex, endIndex))
        }
    }
}

Prevent overlay attacks

The Android overlay is a feature used by an application to appear on top of another application.They are often used to provide a more convenient user experience by allowing users to access certain features or information without leaving the application they are currently using. However, the benefits of this feature come with a big risk as Android overlays can, unfortunately, be used for malicious purposes. Privilege escalation and theft of sensitive data are often the results of successful overlay attacks. Overlays can draw a full window on top of a legitimate application to impersonate the specified application and increase its chance of performing a successful phishing attack. To protect against overlay attacks, Android API 9 (Android 2) added three valuable methods for detecting overlays based on touch events. The onTouch, onFilterTouchEventForSecurity, and setFilterTouchesWhenObscured methods are made available in API 9 and later and can be used to detect obscured touch events. On API 31+, you are fully protected against any non-system overlay for every view on which the setHideOverlayWindows(true) API is called. However, any API below API 31 may be vulnerable to overlays that do not pass the touch events. For more details, refer to Protecting against Android Overlay Attacks.

Use proprietary keyboard

It is not recommended to use third-party keyboards for entering sensitive information such as end user PIN, password, or any PII information. A proprietary keyboard used solely by the issuer application is preferred. This prevents a third-party keyboard from logging the end user's sensitive inputs.

If it is not possible to have a proprietary keyboard, a customized PIN pad for the passcode is preferred. A random scrambling of the PIN pad layout can also be implemented. PIN pad scrambling works by generating a random layout for the keys on the display. This helps mitigate common shoulder surfing attacks and accessibility malware attacks.

Data protection

Data in transit

The issuer application must use TLS 1.2 or TLS 1.3. The server will be configured to use strong cipher suites. In addition, the following methods are to be used for data protection in transit:

Certificate pinning

The issuer application employs certificate pinning for all its communication with the server. From Android v7.0, the issuer application can use the Network Security configuration to enforce certificate pinning on all the domains it communicates with. Refer to Network Security Config for more details.

Protect data with encryption

The issuer application must exercise extra caution when communicating sensitive data such as Personally Identifiable Information (PII) to its server. It is recommended to enforce confidentiality and authentication of data on top of the TLS protections.

Data at rest

The issuer application must protect sensitive data even if it is stored within the issuer application sandbox. A privileged malware can access sensitive data even if it is stored within the sandbox. The issuer application must enforce the confidentiality, authentication, and device-bound security properties when storing sensitive data. In Android, applications can make use of EncryptedSharedPreference or EncryptedFile which satisfies all the security properties needed to treat sensitive data before storing in the issuer application sandbox. For more information on how to protect data at rest, refer to Protecting data at rest.

Authentication

Enable biometric authentication

The issuer application must enable biometric authentication for end user login. When using biometric authentication, it is recommended to make use of Android Keystore and Biometric Crypto object based authentication which offer better security. This also ensures that any addition or removal of biometrics can be detected.

Enforce multi-factor authentication

Enforcing multi-factor authentication (MFA) is a crucial security measure to protect sensitive operations of the D1 SDK and the issuer application. MFA adds an extra layer of security by requiring users to provide multiple forms of authentication before accessing sensitive features or data. This can greatly reduce the risk of unauthorized access even if an end user's primary authentication factor is compromised.

Cryptography guidelines

Security providers

It is recommended to use the Google Play services updated security provider to dynamically protect against future vulnerabilities from Platform Crypto Provider.

As D1 SDK is not responsible to update or notify the end user to install or update the Google Play Service Security Provider, the issuer application will ensure that this Google Play Service Security Provider is updated in the end user's device.

Secure random number generation

The issuer application must always use the methods of SecureRandom class to generate any sensitive cryptographic keys or for any random data generation. For API level 29 onwards, it is recommended to use the SecureRandom.getInstanceStrong() API to use the platform default security provider instead of the issuer application provided security provider.

Application hardening

Detect rooted devices

The issuer application detects compromised device environment such as rooting frameworks, super user binaries before initializing the issuer application and before performing any sensitive operations. For more details on comprehensive root detection, refer to Common Root Detection Methods.

Detect hooking on issuer application

Hooking is a process of injecting a payload to execute in the context of the application process for the purpose of intercepting sensitive data such as cryptographic keys, PII data, understanding the security mechanisms of the application or even changing the flow of the application. Hence, the issuer application must make an effort to detect any attempts to hook the application. For more details on how to perform a hook detection, refer to Hook Detection Methods.

Detect debugger attach

A debugger can be attached to the release variant of the issuer application on compromised devices. With the debuggers, an adversary can debug the issuer application flow on both native and Java/Kotlin binaries. It is important for applications to detect debuggers in Java/Kotlin and native binary, especially before executing sensitive applications. For more information on detecting debuggers, refer to Debug Detection Methods.

Detect emulator

Emulators provide a compromised environment when executing applications leading adversaries to perform various dyanmic analysis. It is recommended to detect emulator at the very start of the issuer application. For more details on emulator detection, refer to Emulator Detection.

Detect issuer application tampering

To prevent malicious hacking into the application code, it is recommended to verify the application's signing certificate signature hash at runtime. Attackers cannot replicate this signature when they sign the application after tampering the binary or any resource files. However, a strong obfuscation is required to protect the signing certificate hash within the binary from modification. Refer to Application Tamper Detection for more details.

In addition, the issuer application can also communicate the signing certificate signature hash to the Thales backend. The Thales backend verifies that the signature hash matches the configured issuer application hash values before honoring further requests from the client.

Obfuscate issuer application

The issuer application and all its components must be obfuscated. This increases the complexity for an attacker to reverse engineer the issuer application and work out the algorithms used or to identify its secret data.

Although D1 SDK is already obfuscated using DexGuard, it is still important for the issuer application to obfuscate the D1 SDK public APIs by applying the rules shared with the binary packages. It is extremely important to follow the obfuscation recommendations provided and pay special attention to:

-flattenpackagehierachy util

Using the package name 'util' is recommended to ensure consistency in the obfuscation. Commercial tools are available for obfuscation. For Android, the current recommendation is to use DexGuard. For more information on obfuscation, refer to Obfuscation Tools and Techniques.

Secure coding

Wiping sensitive data on Android

All sensitive data such as cryptographic keys, PII or any end user sensitive information are to be stored in byte arrays. In Java, it is not possible to alter the behaviors of the underlying data structure of objects such as String and StringBuilder, and there is no control on how many copies of data are made in the memory as well as what may happen to them over the course of time.

It is highly recommended to wipe the sensitive data on your own rather than counting on the garbage collector to dispose them. To ensure no exception can pass through the execution flow and sensitive data leaks, always use finally block to wipe the sensitive data even if there is no catch block used, as shown in the following code snippet:

byte[] password = this.getUserPassword();
try {
  // Use the password to login
  this.logUserIn(password);
} finally {
  	// Even if there is no exception catch here, there can be a
  	//RuntimeException that should still trigger this finally block
  	// to execute
  MemoryHelper.clearData(password);
}

//One way to implement a byte array wiping method is to rewrite every element in the arrays in the MemoryHelper
class public static void clearData(byte[] baBuffer) {
  if (baBuffer == null)
    return;
  for(i = 0;  i < baBuffer.length; i++) {
    baBuffer[i] = (byte)0;
  }
}

Secure coding rules

Gather secure coding guidelines from trusted sources such as Apple, Google, OWASP (Open Web Application Security Project). Alternatively, you can also contact the Thales Handset Security Community to get the access on these guidelines.

It is also recommended to use static code analysis tools (such as PMD or HP Fortify) to enforce on these guidelines.

Use lint tool

Before each feature is complete, and before the completion of the final delivery, use lint to identify and fix any security issues.

From the Android website, it cites that lint is a static code analysis tool that checks your Android project source files for potential bugs and optimization improvements for correctness, security, performance, usability, accessibility, and internationalization.

The complete list of checks performed by lint can be referenced from the Android Developer website.

General Android security tips

It is recommended to be aware and follow the security features and technologies provided by Android. See Android Security Tips.

D1 obfuscation

D1 SDK is delivered with all the internal implementation obfuscated. However, public APIs are preserved for the use of SDK integration.

It is required to perform obfuscation on the final issuer application such as ProGuard/R8 or commercial tools like DexGuard. Due to the use of advanced obfuscation features and Android native code implementation, there are packages that have to be preserved during issuer application obfuscation.

Using the DisplayTextView class

If you are not applying DexGuard (and only use ProGuard/R8) while extending the DisplayTextView class, ensure that an obfuscated class name is provided in the util package as shown below.

package util;
import com.thalesgroup.gemalto.d1.DisplayTextView;

public class x extends DisplayTextView {
    public x(@NonNull Context context) {
        super(context);
    }

    public x(@NonNull Context context, @Nullable AttributeSet attributeSet) {
        super(context, attributeSet);
    }

    public x(@NonNull Context context, @Nullable AttributeSet attributeSet, int i) {
        super(context, attributeSet, i);
    }
}

You may also need to use an obfuscated name for android:id. Refer to the following code snippet to declare the above class and android:id in xml layout.

<util.x
   android:id="@+id/textViewX"
               android:layout_width="wrap_content"
               android:layout_height="wrap_content"
               ...
              .../>