App Security

Imagine a user is logging into their banking app while grabbing coffee in a crowded cafe. They quickly type in their PIN, maybe not noticing someone glancing over their shoulder — or that a vulnerability in the app could put their data at risk. That’s exactly why Secure Input for PIN Entry is so important, especially in financial apps where a PIN is more than just a few numbers; it’s a gateway to sensitive information.

In this guide, we’ll build a secure PIN entry system for Android. I’ll walk you through the Kotlin code step-by-step, along with key security tips. So stay tuned..!

Why is Secure PIN Entry So Important?

In financial apps, PINs are often the key to user authentication, making secure PIN entry essential. Here’s why it matters:

• Prevent Shoulder Surfing: Stop others from sneaking a peek at the PIN in crowded or public spaces.
• Block Unauthorized Access: Strengthen PIN handling to eliminate weak security points.
• Protect Against Data Leaks: Safeguard sensitive data by avoiding insecure storage or logging practices.

Best Practices for Secure Input for PIN Entry

1. Use a Custom View for Input Masking
   • Default Android input views may not be secure enough, as they’re designed for generic inputs. Creating a custom view for PIN entry adds control over how data is handled and stored.
2. Minimize PIN Storage Duration
   • Store PIN data in memory only as long as needed. Clear it from memory once used.
3. Use Secure Storage for Sensitive Data
   • Don’t store the PIN itself; instead, use tokens or session IDs post-authentication.
4. Disable Screenshots
   • Prevent screenshots and screen recording to avoid capturing the PIN on-screen.
5. Avoid Logging Sensitive Data
   • Ensure that the PIN isn’t logged or displayed in the logcat.
6. Use Obfuscation Techniques
   • Obfuscate sensitive parts of the codebase to make reverse engineering harder.

Implementing Secure PIN Entry in Kotlin

Alright, without wasting time, let’s jump into the Kotlin code and start building our secure PIN entry feature.

Disable Screenshots

Preventing screenshots and screen recording ensures that no sensitive data gets captured visually.

In your Activity class, disable screenshots by adding this line in the onCreate method.

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    window.setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE)
    setContentView(R.layout.activity_pin_entry)
}

The FLAG_SECURE flag prevents the app from taking screenshots or recording the screen when the PIN entry screen is open.

Create a Custom PIN Entry View

A custom PIN entry view allows us to control how each input character behaves and ensures that data is stored only in memory for the duration needed.

Create a SecurePinEntryView class that extends LinearLayout.

class SecurePinEntryView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : LinearLayout(context, attrs, defStyleAttr) {

    private val pinDigits = mutableListOf<EditText>() // Holds the EditTexts for each PIN digit
    private val maxPinLength = 4 // Number of PIN digits

    init {
        orientation = HORIZONTAL
        setupPinFields()
    }

    private fun setupPinFields() {
        for (i in 0 until maxPinLength) {
            val digitField = createDigitField()
            pinDigits.add(digitField)
            addView(digitField)
        }
    }

    private fun createDigitField(): EditText {
        return EditText(context).apply {
            inputType = InputType.TYPE_CLASS_NUMBER or InputType.TYPE_NUMBER_VARIATION_PASSWORD
            setBackgroundColor(Color.TRANSPARENT)
            filters = arrayOf(InputFilter.LengthFilter(1))
            isCursorVisible = false
            textAlignment = View.TEXT_ALIGNMENT_CENTER
            layoutParams = LayoutParams(0, LayoutParams.MATCH_PARENT, 1f) // Distribute space evenly

            setOnFocusChangeListener { _, hasFocus ->
                if (hasFocus && text.isEmpty()) {
                    this.text.clear() // Clear text only if empty to avoid accidental deletion
                }
            }
        }
    }

    // Collects the PIN entered by the user
    fun getPin(): String {
        return pinDigits.joinToString("") { it.text.toString() }
    }

    // Clears the entered PIN
    fun clearPin() {
        pinDigits.forEach { it.text.clear() }
    }
}

Here,

• Orientation & Style: We set the orientation to HORIZONTAL to align the PIN digits in a row.createDigitField(): Creates a customized EditText for each PIN digit.
• InputType.TYPE_NUMBER_VARIATION_PASSWORD hides the PIN visually by displaying dots.
• Each digit field is limited to one character using InputFilter.LengthFilter(1).
• isCursorVisible is set to false to remove the blinking cursor, which makes it harder for onlookers to see which digit is currently being entered.

Handle PIN Submission

Once the user enters the PIN, we’ll verify it securely. Here’s an example of how to collect and handle the PIN securely.

val securePinEntryView = findViewById<SecurePinEntryView>(R.id.securePinEntryView)
val submitButton = findViewById<Button>(R.id.submitButton)

submitButton.setOnClickListener {
    val enteredPin = securePinEntryView.getPin()
    
    // Verify the PIN here or pass it to the next step
    if (verifyPin(enteredPin)) {
        // Handle successful PIN entry
        Toast.makeText(this, "PIN verified!", Toast.LENGTH_SHORT).show()
    } else {
        // Clear PIN for incorrect attempts
        securePinEntryView.clearPin()
        Toast.makeText(this, "Incorrect PIN. Try again.", Toast.LENGTH_SHORT).show()
    }
}

private fun verifyPin(pin: String): Boolean {
    // Replace this with actual PIN verification logic
    return pin == "1234" // Example PIN for demonstration
}

In this code,

• getPin(): Collects the entered PIN from the custom view.
• verifyPin(): Checks if the entered PIN matches the stored PIN. In a real application, use a secure method to validate the PIN.

Clear PIN on Incorrect Attempts

Clearing the PIN on incorrect attempts prevents attackers from guessing and observing patterns.

private fun handleIncorrectPin() {
    securePinEntryView.clearPin() // Clears the entered PIN
    Toast.makeText(this, "Incorrect PIN. Try again.", Toast.LENGTH_SHORT).show()
}

Hash, Encode, Encrypt, and Store

Always hash sensitive data and use Base64 encoding before encrypting and storing it.

Since we haven’t added any PIN security logic yet, let’s take the next step and organize it into its own class, following the Single Responsibility Principle. This way, we’ll keep things clean and put the logic in the SecurePinManager class.

import android.content.Context
import android.text.InputType
import android.widget.EditText
import androidx.security.crypto.EncryptedSharedPreferences
import androidx.security.crypto.MasterKeys
import java.security.MessageDigest
import java.util.*

class SecurePinManager(context: Context) {
    private val masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)
    private val encryptedPrefs = EncryptedSharedPreferences.create(
        "secure_prefs",
        masterKeyAlias,
        context,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )

    fun setupPinInputField(editText: EditText) {
        editText.inputType = InputType.TYPE_CLASS_NUMBER or InputType.TYPE_NUMBER_VARIATION_PASSWORD
    }

    fun savePin(pin: String) {
        val hashedPin = hashPin(pin) // Hash the PIN before saving
        encryptedPrefs.edit().putString("user_pin", hashedPin).apply()
    }

    fun verifyPin(inputPin: String): Boolean {
        val storedHashedPin = encryptedPrefs.getString("user_pin", null)
        val inputHashedPin = hashPin(inputPin) // Hash the input before comparison
        return storedHashedPin == inputHashedPin
    }

    // Hashes the PIN using SHA-256
    private fun hashPin(pin: String): String {
        val digest = MessageDigest.getInstance("SHA-256")
        val hashedBytes = digest.digest(pin.toByteArray())
        return Base64.getEncoder().encodeToString(hashedBytes) // Encode the hashed bytes in Base64
    }
}

• PIN Hashing: The PIN is now hashed using SHA-256 before saving and comparing. This adds a layer of security by ensuring the raw PIN is never stored.
• Base64 Encoding: The hashed PIN is encoded using Base64 to store it as a string in EncryptedSharedPreferences.

Prevent Sensitive Data from Being Logged

Avoid logging the entered PIN or sensitive information.

// BAD: Never log sensitive data
Log.d("PinEntry", "Entered PIN: $enteredPin") 

// GOOD: No sensitive data in logs
Log.d("PinEntry", "PIN entry attempt")

Additional Key Security Tips

• Limit Accessibility During PIN Entry: Restrict accessibility features like screen readers or magnification during PIN entry to prevent accidental exposure of sensitive information.
• Enable Biometric Authentication: Consider using biometric authentication (e.g., fingerprint, face recognition) for an extra layer of security, alongside the PIN.
• Encrypt Sensitive Data: While PINs themselves shouldn’t be stored directly, always hash sensitive data and use Base64 encoding before encrypting and storing it.
• Regularly Clear Sensitive Data: If you’re using data holders like LiveData or other similar components, ensure that sensitive data is cleared when it is no longer needed. Properly manage the lifecycle of such data to avoid unintentional retention in memory or storage.

Conclusion

Building a secure PIN entry system isn’t just about protecting data—it’s about earning user trust and safeguarding their sensitive information. With Kotlin’s secure handling features, you can create a seamless, safe experience for your users.

By following these steps, you’re not only securing their PINs but also ensuring their data is treated with the highest level of care in your financial app. Let’s keep security at the forefront and provide users the peace of mind they deserve..!

Data security is vital for financial apps. Sensitive information — whether it’s login details or payment data — needs to be protected at all times, not just when it’s stored, but also while it’s in memory. Although encryption for stored data is widely practiced, securing data in memory is sometimes underestimated. Yet, keeping data safe while it’s actively being used is equally important. In this blog, we’ll walk through best practices for handling in-memory data securely on Android. With Kotlin code, I’ll show you practical ways to protect sensitive information while it’s in use.

Why Secure In-Memory Sensitive Data Holding Matters

When your app handles sensitive information—such as user session tokens, PINs, or account numbers—it temporarily stores this data in memory during processing. If this data remains in memory longer than necessary, it becomes vulnerable to unauthorized access, particularly in environments that are rooted or debug-enabled. Attackers in these environments can potentially access memory and retrieve sensitive information from other applications. Financial apps are particularly at risk due to the highly sensitive nature of the data they handle. However, any app that stores sensitive information, such as health apps or apps handling personally identifiable information (PII), should prioritize securing in-memory data to protect user privacy and minimize the risk of exposure to attacks.

Best Practices for Securing In-Memory Data in Android

To safeguard session tokens, PINs, account numbers, and other sensitive data in memory, consider the following best practices:

1. Minimal Data Exposure
   Keep sensitive data in memory only for as long as necessary. Ensure that it is cleared promptly once it is no longer required. This minimizes the window of opportunity for attackers to access it.
2. Encryption
   Always encrypt sensitive data before storing it in memory. This ensures that even if attackers manage to access the memory, they won’t be able to interpret the data without the encryption key. Using Android’s Keystore system is highly recommended for secure encryption key management.
3. Obfuscation
   Make it more difficult for attackers to make sense of session tokens, PINs, or account numbers in memory. While obfuscation alone is not a secure measure, it adds an additional layer of protection by making the data harder to interpret if accessed.
4. Data Clearing
   Securely clear sensitive data from memory as soon as it is no longer needed. Ensure that memory is overwritten securely to prevent recovery using memory analysis tools. Consider using techniques like memcpy or similar secure memory handling functions to wipe sensitive data completely from memory.
5. Secure Memory Handling
   Consider using Android’s secure storage mechanisms like EncryptedSharedPreferences or Android Keystore to manage sensitive information securely. These tools provide a higher level of protection for storing encryption keys or sensitive data that needs to be accessed in memory.
6. Anti-Debugging and Root Detection
   Implement anti-debugging and root detection techniques to prevent attackers from using debugging tools to extract data from the app. While these techniques are not foolproof, they add an additional layer of defense.
7. Secure Coding Practices
   Avoid accidentally logging or exposing sensitive data in crash reports, logs, or other outputs. Ensure that sensitive information is handled securely throughout the app’s lifecycle.

Implementing Secure In-Memory Data Handling in Kotlin

Minimize Data Exposure

To protect sensitive data, only keep it in memory for as long as absolutely necessary. Avoid storing it in global or static variables where it might remain accessible longer than needed. Here’s how we can handle this securely in Kotlin

fun performSensitiveOperation() {
    val sensitiveData = fetchSensitiveData() // Example: fetching from secure storage
    try {
        // Use the sensitive data within a limited scope
        processSensitiveData(sensitiveData)
    } finally {
        // Clear sensitive data once it's no longer needed
        sensitiveData.clear()
    }
}

Here,

• sensitiveData is fetched and used only within the scope of the function.
• Once the operation is complete, the data is cleared, minimizing its exposure time and keeping it safe.

By ensuring sensitive data only lives in memory for the shortest time possible, you reduce the risk of unauthorized access.

Use ‘CharArray’ or ‘ByteArray’ Instead of a String

In both Java and Kotlin, String is immutable, meaning once it’s created, it cannot be modified. While this makes strings reliable for certain use cases, it can also be a security risk when dealing with sensitive data because the string cannot be cleared from memory once it’s no longer needed. On the other hand, CharArray is mutable, so we can modify its contents, making it a safer choice for sensitive information like passwords.

Here’s a quick comparison

// Avoid
val password = "SensitivePassword123"

// Better
val password = charArrayOf('S', 'e', 'n', 's', 'i', 't', 'i', 'v', 'e', 'P', 'a', 's', 's', 'w', 'o', 'r', 'd', '1', '2', '3')

Clearing CharArray After Use

Once you’re done using sensitive data stored in a CharArray, it’s important to clear it immediately to prevent it from lingering in memory. You can do this by setting all characters to \u0000 (the null character)

fun clearPassword(password: CharArray) {
    for (i in password.indices) {
        password[i] = '\u0000'
    }
}

Calling clearPassword(password) right after you’re finished using the password ensures that no sensitive data is left exposed in memory longer than necessary, reducing the risk of unauthorized access.

The same applies to ByteArray. Since ByteArray is mutable, we can modify or clear its contents after use, providing a more secure way to handle sensitive data in memory.

class SensitiveDataHandler {
    private var sensitiveData: ByteArray? = null

    // Store sensitive data securely as a ByteArray
    fun storeData(data: String) {
        sensitiveData = data.toByteArray() // Convert String data to ByteArray
    }

    // Clear the sensitive data by overwriting it with zeros
    fun clearData() {
        sensitiveData?.fill(0) // Overwrite with zeros
        sensitiveData = null // Set the reference to null
    }
}

This approach helps ensure that sensitive information is overwritten and doesn’t remain in memory, mitigating security risks if memory is compromised.

Encrypting Sensitive Data in Memory

Even with minimal exposure and proper data clearing, it’s a good practice to add an extra layer of security by encrypting sensitive data while it’s in memory. This helps protect the data in case of an attack or a breach. In Kotlin, you can use the Cipher class to easily encrypt and decrypt data on the fly.

Here’s how you can implement an encryption utility using AES-GCM for secure encryption and decryption

import javax.crypto.Cipher
import javax.crypto.KeyGenerator
import javax.crypto.SecretKey
import javax.crypto.spec.GCMParameterSpec

object MemoryEncryptionUtil {
    private const val TRANSFORMATION = "AES/GCM/NoPadding"
    private const val TAG_LENGTH_BIT = 128
    private val secretKey: SecretKey

    init {
        val keyGen = KeyGenerator.getInstance("AES")
        keyGen.init(256) // 256-bit AES encryption
        secretKey = keyGen.generateKey() // Generate a secret key
    }

    // Encrypt the data and return the initialization vector (IV) and encrypted data
    fun encrypt(data: ByteArray): Pair<ByteArray, ByteArray> {
        val cipher = Cipher.getInstance(TRANSFORMATION)
        cipher.init(Cipher.ENCRYPT_MODE, secretKey)
        val iv = cipher.iv // Get the initialization vector
        val encryptedData = cipher.doFinal(data) // Encrypt the data
        return Pair(iv, encryptedData)
    }

    // Decrypt the data using the IV and encrypted data
    fun decrypt(iv: ByteArray, data: ByteArray): ByteArray {
        val cipher = Cipher.getInstance(TRANSFORMATION)
        val spec = GCMParameterSpec(TAG_LENGTH_BIT, iv) // Specify the GCM parameter
        cipher.init(Cipher.DECRYPT_MODE, secretKey, spec) // Initialize the cipher for decryption
        return cipher.doFinal(data) // Decrypt and return the data
    }
}

• AES-GCM (Galois/Counter Mode): This encryption mode offers both confidentiality and integrity, ensuring that the encrypted data cannot be tampered with without detection.
• encrypt(): This method encrypts the given ByteArray and returns a pair consisting of the initialization vector (IV) and the encrypted data.
• decrypt(): This method takes the IV and encrypted data, decrypts it, and returns the original data in its unencrypted form.

Now, let’s see how to use this encryption utility with sensitive data

val sensitiveData = "SensitiveData".toByteArray()
val (iv, encryptedData) = MemoryEncryptionUtil.encrypt(sensitiveData)

// Decrypt the data later when needed
val decryptedData = MemoryEncryptionUtil.decrypt(iv, encryptedData)

Here,

• Sensitive data is first converted to a ByteArray.
• It is then encrypted using the encrypt() function, which returns both the IV and the encrypted data.
• When you need to access the original data, you can use the decrypt() function with the IV and encrypted data to safely decrypt it.

By implementing encryption in-memory, you provide an additional layer of protection for sensitive data, ensuring that even if an attacker gains access to the memory, the data remains unreadable.

Using Secure Storage for Persistent Data

When it comes to storing sensitive data beyond the session, it’s essential to use secure storage mechanisms to ensure that the data remains protected even after the app is closed or the device is restarted. Android’s Keystore System is specifically designed for this purpose, providing a secure place to store cryptographic keys and sensitive information like passwords and tokens.

In below code, we’ll use the Keystore to securely generate a key and then encrypt/decrypt sensitive data stored in a persistent manner.

import android.security.keystore.KeyProperties
import android.security.keystore.KeyGenParameterSpec
import java.security.KeyStore
import javax.crypto.KeyGenerator
import javax.crypto.Cipher
import javax.crypto.SecretKey
import javax.crypto.spec.GCMParameterSpec

object SecureStorageUtil {
    private const val KEY_ALIAS = "SecureKeyAlias"  // Alias for the key
    private const val TRANSFORMATION = "AES/GCM/NoPadding"  // Encryption mode and padding
    private const val TAG_LENGTH_BIT = 128  // Tag length for GCM

    // Function to retrieve or generate the encryption key
    private fun getKey(): SecretKey {
        val keyStore = KeyStore.getInstance("AndroidKeyStore").apply { load(null) }

        // Check if the key already exists
        if (!keyStore.containsAlias(KEY_ALIAS)) {
            val keyGen = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
            val spec = KeyGenParameterSpec.Builder(KEY_ALIAS,
                KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT)
                .setBlockModes(KeyProperties.BLOCK_MODE_GCM)  // Set GCM block mode
                .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)  // No padding
                .build()
            keyGen.init(spec)
            keyGen.generateKey()  // Generate the key and store it securely
        }

        // Return the secret key from the keystore
        return (keyStore.getEntry(KEY_ALIAS, null) as KeyStore.SecretKeyEntry).secretKey
    }

    // Function to encrypt data using the Keystore key
    fun encrypt(data: ByteArray): Pair<ByteArray, ByteArray> {
        val cipher = Cipher.getInstance(TRANSFORMATION)
        cipher.init(Cipher.ENCRYPT_MODE, getKey())  // Initialize cipher with encryption key
        val iv = cipher.iv  // Get the initialization vector (IV)
        val encryptedData = cipher.doFinal(data)  // Encrypt the data
        return Pair(iv, encryptedData)  // Return both IV and encrypted data
    }

    // Function to decrypt data using the Keystore key
    fun decrypt(iv: ByteArray, encryptedData: ByteArray): ByteArray {
        val cipher = Cipher.getInstance(TRANSFORMATION)
        cipher.init(Cipher.DECRYPT_MODE, getKey(), GCMParameterSpec(TAG_LENGTH_BIT, iv))  // Initialize cipher for decryption
        return cipher.doFinal(encryptedData)  // Decrypt and return the data
    }
}

• Key Generation: If the key doesn’t already exist in the Keystore, it is generated using KeyGenerator with the AES algorithm and stored in the AndroidKeyStore. This ensures the key never leaves the secure hardware and is not accessible by unauthorized parties.
• AES-GCM Encryption: We use AES in Galois/Counter Mode (GCM), which provides both encryption and integrity protection. The Cipher class is used to perform encryption and decryption operations with the key stored in the Keystore.

Data Encryption & Decryption

• encrypt(): Encrypts the input data and returns both the initialization vector (IV) and encrypted data. The IV is crucial for decrypting the data later.
• decrypt(): Uses the stored key to decrypt the data by passing the IV and encrypted data.

Here’s how we can use SecureStorageUtil to securely store and retrieve encrypted data, again, similar to the encryption utility mentioned above.

val sensitiveData = "SensitiveData".toByteArray()

// Encrypt the data
val (iv, encryptedData) = SecureStorageUtil.encrypt(sensitiveData)

// Decrypt the data later when needed
val decryptedData = SecureStorageUtil.decrypt(iv, encryptedData)

But, why do we use Keystore?

The Android Keystore System ensures that the cryptographic keys are stored securely in hardware-backed storage (if available), making them less vulnerable to attacks such as device rooting or debugging. By using Keystore for key management, you reduce the risk of exposing sensitive data, even if the app is compromised.

This approach helps ensure that sensitive data is encrypted both at rest (when stored) and in transit (while being processed), providing an additional layer of security for your financial app’s sensitive information.

Conclusion

By implementing these practices, you can significantly mitigate the risk of sensitive data being exposed in memory:

• Minimize data exposure by limiting its time in memory.
• Use mutable types like CharArray or ByteArray and clear them after use.
• Encrypt sensitive data while in memory.
• Store persistent data securely using Android’s Keystore system.

These measures ensure that even if an attacker gains access to memory or persistent storage, they won’t be able to easily retrieve sensitive information.

Protecting sensitive data in financial apps is essential to prevent security breaches that could put user information, app configurations, and financial transactions at risk. In this blog, I’ll walk you through how to secure configuration data in financial apps. We’ll begin by looking at common vulnerabilities, then move on to practical solutions like encryption and secure storage practices. Along the way, I’ll break things down step by step to help you apply these strategies with ease. Let’s dive in and make your financial app more secure!

Why Configuration Data Protection Needed?

Configuration data is essential in financial apps as it often contains API keys, URLs, and settings that control how the app behaves. In financial apps, this data is particularly sensitive. If it’s not properly secured, attackers could exploit vulnerabilities, bypass authentication, steal financial data, or even manipulate transactions.

Core Techniques to Protect Configuration Data

Here are a few core techniques to keep your configuration data secure:

1. Using Encrypted SharedPreferences for Sensitive Data
2. Encrypting API Keys and Tokens
3. Using Android Keystore for Secure Key Management
4. Network Security Configuration for Secure Data Transmission

Let’s dive into each of these, starting with Encrypted SharedPreferences.

Using Encrypted SharedPreferences for Sensitive Data

SharedPreferences is commonly used in Android to store small pieces of data, like user settings or app preferences. However, the downside is that standard SharedPreferences stores data in plain text, which can easily be accessed if the device is compromised. This is a significant security risk, especially when dealing with sensitive information like API keys.

To secure sensitive data, we can use EncryptedSharedPreferences. It encrypts the data, ensuring that even if someone gains access to the storage, they won’t be able to read the sensitive information.

Here’s how you can use EncryptedSharedPreferences:

import androidx.security.crypto.EncryptedSharedPreferences
import androidx.security.crypto.MasterKeys

fun getSecureSharedPreferences(context: Context): SharedPreferences {
    val masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)

    return EncryptedSharedPreferences.create(
        "secure_preferences", // Name of the preferences file
        masterKeyAlias, // The master key for encryption
        context,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )
}

fun saveConfigData(context: Context, apiKey: String) {
    val sharedPreferences = getSecureSharedPreferences(context)
    with(sharedPreferences.edit()) {
        putString("api_key", apiKey)
        apply() // Save the data securely
    }
}

fun getConfigData(context: Context): String? {
    val sharedPreferences = getSecureSharedPreferences(context)
    return sharedPreferences.getString("api_key", null) // Retrieve the secure data
}

Here,

• MasterKeys.getOrCreate() creates a master key using AES-256 encryption. This key is used to encrypt the data.
• EncryptedSharedPreferences.create() initializes the EncryptedSharedPreferences instance with the specified encryption schemes for both the keys and values.
• putString() securely saves sensitive data like API keys, while getString() retrieves the encrypted value.

By using EncryptedSharedPreferences, we ensure that even if someone gains unauthorized access to the device’s storage, the data remains encrypted and safe. This is a simple yet powerful way to protect sensitive configuration data in your financial app.

Encrypting API Keys and Tokens

Hardcoding API keys and tokens directly into your app’s code can create serious security vulnerabilities. If someone decompiles your app or gains unauthorized access, these sensitive credentials could be exposed. Instead, it’s safer to store them in an encrypted format and decrypt them only when needed during runtime.

Here’s how you can use AES encryption in Kotlin to securely handle your API keys and tokens.

import javax.crypto.Cipher
import javax.crypto.KeyGenerator
import javax.crypto.SecretKey
import javax.crypto.spec.GCMParameterSpec
import android.util.Base64

// Encrypting a string with AES
fun encryptData(plainText: String, secretKey: SecretKey): String {
    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    cipher.init(Cipher.ENCRYPT_MODE, secretKey)
    val iv = cipher.iv
    val encryptedData = cipher.doFinal(plainText.toByteArray())
    val ivAndEncryptedData = iv + encryptedData
    return Base64.encodeToString(ivAndEncryptedData, Base64.DEFAULT)
}

// Decrypting the encrypted string
fun decryptData(encryptedText: String, secretKey: SecretKey): String {
    val ivAndEncryptedData = Base64.decode(encryptedText, Base64.DEFAULT)
    val iv = ivAndEncryptedData.sliceArray(0 until 12) // Extract the 12-byte IV
    val encryptedData = ivAndEncryptedData.sliceArray(12 until ivAndEncryptedData.size)
    val cipher = Cipher.getInstance("AES/GCM/NoPadding")
    val gcmParameterSpec = GCMParameterSpec(128, iv) // 128-bit authentication tag length
    cipher.init(Cipher.DECRYPT_MODE, secretKey, gcmParameterSpec)
    val decryptedData = cipher.doFinal(encryptedData)
    return String(decryptedData)
}

// Generate Secret Key for AES
fun generateSecretKey(): SecretKey {
    val keyGenerator = KeyGenerator.getInstance("AES")
    keyGenerator.init(256) // AES 256-bit encryption
    return keyGenerator.generateKey()
}

• AES/GCM/NoPadding: This mode provides strong encryption and also ensures no unnecessary padding is added, keeping the data size as small as possible.
• Initialization Vector (IV): The IV is crucial for ensuring that even if the same data is encrypted multiple times, the output will differ. It’s stored alongside the encrypted data and is required for decryption.
• generateSecretKey(): This method creates a 256-bit AES key, which can be used for both encryption and decryption. To further enhance security, you can store this key in the Android Keystore.

By using AES encryption to handle your API keys and tokens, you’re adding an extra layer of security to prevent unauthorized access to your financial app’s sensitive data. This approach ensures that your sensitive information remains secure, even if the device is compromised.

Btw, I know you might be wondering about one term. Any guesses..? Without further delay, let’s take a look!

What is an IV (Initialization Vector)?

An Initialization Vector (IV) is a random value used in cryptographic algorithms, such as AES, to ensure that each encryption operation produces unique results — even when encrypting the same data multiple times with the same key.

Why is IV Important?

• Prevents Repeated Patterns:
  Without an IV, encrypting the same data with the same key would always result in the same ciphertext. This predictability is a security risk. The IV ensures that even when encrypting identical data, the output (ciphertext) will be different each time, making it harder for attackers to detect patterns or deduce information.
• Enhances Security:
  In encryption modes like AES-CBC (Cipher Block Chaining) or AES-GCM (Galois/Counter Mode), the IV plays a crucial role by adding randomness to the encryption process. This added randomness strengthens the encryption, making it more resistant to attacks.
• Must Be Unique:
  The IV doesn’t need to be kept secret, but it must be unique for each encryption operation. Reusing the same IV with the same key for different data introduces vulnerabilities. When an IV is reused, attackers may be able to spot patterns or exploit weaknesses in the encryption.

How Does the IV Work?

• During Encryption:
  The IV is combined with the plaintext and encryption key to create the ciphertext. Its role is to introduce randomness, ensuring that even identical plaintexts will produce different ciphertexts when encrypted.
• During Decryption:
  To decrypt the data properly, the same IV used during encryption must be provided. It’s typically sent alongside the ciphertext, ensuring the receiver can use it during decryption to recover the original data.

Storing and Transmitting the IV

The IV itself doesn’t need to be kept secret, but it must be made available to the receiver. Usually, it’s transmitted along with the encrypted data, either as a prefix or in a predefined format. This ensures that the IV can be used during decryption. However, even though the IV isn’t secret, it still must be securely transmitted to ensure proper decryption.

Let’s get back to our discussion on App Configuration Data Protection and see how we can use Android Keystore for secure key management.

Using Android Keystore for Secure Key Management

Storing encryption keys directly in the app can leave them vulnerable to attacks. To avoid this, we can use the Android Keystore system, which securely stores keys either in hardware or a secure enclave, ensuring that only the app has access to them. This adds a significant layer of protection, especially for sensitive data.

Here’s how you can generate and securely manage keys using the Keystore:

import android.security.keystore.KeyGenParameterSpec
import android.security.keystore.KeyProperties
import java.security.KeyStore
import javax.crypto.KeyGenerator
import javax.crypto.SecretKey

// Generate and store a key in Android Keystore
fun createKey() {
    val keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
    val keyGenParameterSpec = KeyGenParameterSpec.Builder(
        "SecureKeyAlias",
        KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
    ).setBlockModes(KeyProperties.BLOCK_MODE_GCM)
     .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
     .build()
    keyGenerator.init(keyGenParameterSpec)
    keyGenerator.generateKey()
}

// Retrieve the secret key from Keystore
fun getSecretKey(): SecretKey? {
    val keyStore = KeyStore.getInstance("AndroidKeyStore")
    keyStore.load(null)
    return keyStore.getKey("SecureKeyAlias", null) as SecretKey?
}

• KeyGenParameterSpec.Builder: This part sets the encryption requirements, such as the encryption block mode and padding. In this case, we’re using AES with GCM mode, which is both secure and efficient.
• createKey(): This function creates a new AES encryption key and securely stores it in the Keystore with the alias SecureKeyAlias. The key is only accessible to the app, making it safe from potential leaks.
• getSecretKey(): This function retrieves the stored key from the Keystore when needed for encryption or decryption. The key is never exposed in the code, adding an extra layer of security.

By using the Android Keystore, we avoid the risk of exposing sensitive keys within the app, ensuring a higher level of security for encryption operations.

Network Security Configuration for Secure Data Transmission

In financial apps, securely transmitting sensitive data over HTTPS is critical to prevent man-in-the-middle attacks. If not properly configured, cleartext traffic (HTTP) can expose this data to unauthorized access. To ensure your app uses HTTPS and blocks any unencrypted traffic, you can define network security policies using a configuration file.

Here’s how to enforce HTTPS using a network security configuration in your app

Create a network security configuration file (network_security_config.xml) in the res/xml folder:

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">yourapi.com</domain>
    </domain-config>
</network-security-config>

Link the configuration in your AndroidManifest.xml:

<application
    android:networkSecurityConfig="@xml/network_security_config"
    ... >
</application>

• cleartextTrafficPermitted="false": This setting ensures that the app only allows encrypted HTTPS traffic and blocks any HTTP (cleartext) traffic, preventing sensitive data from being exposed.
• <domain> tag: You specify trusted domains (like yourapi.com) that the security settings apply to, including all of its subdomains (by setting includeSubdomains="true").

By adding this configuration, you’re ensuring that your financial app’s data transmissions remain secure, guarding against potential security threats.

Conclusion 

Securing app configuration data in financial apps is essential for protecting sensitive user information and maintaining trust. By implementing practices like using EncryptedSharedPreferences, encrypting sensitive values, storing keys in the Android Keystore, and enforcing HTTPS, you can significantly reduce the risk of data breaches and vulnerabilities.

These steps will help ensure that your financial Android app handles sensitive data securely, giving users the peace of mind they need when using your app.

When building financial apps, security should always be a top priority. Sensitive information like banking credentials, personal details, and financial records must be protected at all costs. One often-overlooked security measure is disabling app data backups. While Android’s automatic cloud backup feature is convenient, it can expose sensitive data if not managed properly. In this guide, we’ll walk through the steps to disable app data backup in Android apps, ensuring that user data remains secure.

Why Disable App Data Backup in Financial Apps?

While app data backup can be a convenient feature for many apps, it poses risks for apps that handle sensitive financial data. Here’s why it’s crucial to disable it:

• Protecting Sensitive Data: If a device is compromised or when users switch to a new device, any backed-up data could be exposed during restoration, which is a major security concern.
• Ensuring Compliance: Many financial institutions have strict data security requirements, and allowing data to be backed up to external storage might violate these regulations.
• Reducing Risk: Disabling backups prevents data from being stored on potentially less secure platforms or devices, keeping it safe from unauthorized access.

Before disabling the backup, let’s first take a moment to see which files are usually being backed up.

What Gets Backed Up

By default, Auto Backup includes files from most directories assigned to your app by the system, such as:

• Shared Preferences Files
• Internal Storage Files: Files saved to your app’s internal storage and accessed via getFilesDir() or getDir(String, int)
• Database Files: Files in the directory returned by getDatabasePath(String), including those created using SQLiteOpenHelper
• External Storage Files: Files located in the directory returned by getExternalFilesDir(String)

Auto Backup doesn’t include files stored in certain directories, such as:

• Cache Directory: Files saved in getCacheDir(), getCodeCacheDir(), and getNoBackupFilesDir()
  These files are temporary and are intentionally excluded from backup to avoid unnecessary storage and syncing.

You can customize the backup process by specifying which files should be included or excluded from Auto Backup, giving you greater control over the data your app manages.

How Disabling App Data Backup Works in Android

By default, Android automatically backs up an app’s data to Google Drive, including SharedPreferences, files, and other persistent data. This process is controlled by the android:allowBackup attribute in the app’s AndroidManifest.xml. By setting this attribute to false, the app ensures its data is not backed up, which is essential for securing financial apps and other apps that handle sensitive information.

<application
    android:name=".FinancialApp"
    android:allowBackup="false"
    android:fullBackupContent="false"
    ... >
    <!-- other configurations -->
</application>

allowBackup="false":

• This attribute prevents Android from automatically backing up the app’s data to Google Drive or any other backup service. This includes both user-initiated and system-initiated backups. Setting allowBackup="false" effectively disables the Android backup mechanism for the app, reducing the risk of unauthorized access to app data through backups.
• Important Note: While this setting prevents automatic backups through Android’s system, it does not guarantee complete protection. Devices with root access or custom ROMs can bypass this setting and potentially access app data or perform backups using alternative methods.

fullBackupContent="false":

• This attribute ensures that the app’s data is excluded from full device backups, regardless of the allowBackup setting. When set to false, it prevents the app’s data from being included in any full-device backup (such as Google’s full-device backup feature) even if allowBackup is set to true.
• Important Note: This attribute prevents the app’s data from being included in standard full backups, but it does not protect against all possible data extraction methods. Devices with root access or custom ROMs may still be able to access the app’s data through other means, such as direct file system access.

While both allowBackup="false" and fullBackupContent="false" significantly reduce the chances of unauthorized backups and data exposure, they do not provide 100% protection, especially on rooted or compromised devices. That’s why, in financial apps, we check if the device is rooted and implement additional tampering checks to enhance security.

Securing Sensitive Data Locally

Disabling backups is only part of the equation in securing sensitive data. It’s also crucial to protect locally stored information. Jetpack’s Security library provides tools like EncryptedSharedPreferences and EncryptedFile in Kotlin, which ensure that data stored on the device remains encrypted. These components integrate seamlessly with Android’s architecture and provide strong encryption, making them excellent choices for securely handling sensitive data in financial or personal apps.

Using EncryptedSharedPreferences

import android.content.Context
import androidx.security.crypto.EncryptedSharedPreferences
import androidx.security.crypto.MasterKeys

fun getEncryptedSharedPreferences(context: Context): SharedPreferences {
    val masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)
    return EncryptedSharedPreferences.create(
        "financial_prefs",
        masterKeyAlias,
        context,
        EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
        EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
    )
}

Here,

• MasterKeys: Creates or retrieves a master key that is used to encrypt the shared preferences.
• EncryptedSharedPreferences: Securely stores shared preferences with AES encryption, which is suitable for sensitive data.
• PrefKeyEncryptionScheme & PrefValueEncryptionScheme: These schemes ensure both keys and values in SharedPreferences are encrypted, providing additional security.

Securely Storing Files with EncryptedFile

Sometimes, an app may need to store files, such as transaction records or receipts. Using EncryptedFile can help ensure these files are securely stored.

import androidx.security.crypto.EncryptedFile
import androidx.security.crypto.MasterKeys
import java.io.File

fun getEncryptedFile(context: Context, fileName: String): EncryptedFile {
    val masterKeyAlias = MasterKeys.getOrCreate(MasterKeys.AES256_GCM_SPEC)
    val file = File(context.filesDir, fileName)

    return EncryptedFile.Builder(
        file,
        context,
        masterKeyAlias,
        EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB
    ).build()
}

fun writeToEncryptedFile(context: Context, data: String) {
    val encryptedFile = getEncryptedFile(context, "sensitive_data.txt")
    encryptedFile.openFileOutput().use { output ->
        output.write(data.toByteArray())
    }
}

• EncryptedFile: Provides AES256_GCM encryption to ensure that files are securely stored on disk.
• FileEncryptionScheme: Specifies the encryption scheme to use for file security, which includes AES encryption with a secure HKDF key derivation function.

Additional Security Considerations

• Use ProGuard: Obfuscate your app’s code to make it much harder for attackers to reverse-engineer.
• Implement Strong User Authentication: For accessing sensitive areas of the app, use secure authentication methods like biometrics or PINs.
• Clear Sensitive Data on Logout: Ensure that all stored sensitive data is cleared when the user logs out or exits.

Here’s a quick example of a function to clear sensitive data from EncryptedSharedPreferences:

fun clearSensitiveData(context: Context) {
    val encryptedPrefs = getEncryptedSharedPreferences(context)
    encryptedPrefs.edit().clear().apply()
}

This function retrieves the EncryptedSharedPreferences instance and clears all saved data, ensuring that no sensitive information remains stored in the app.

Testing Backup Disabling and Data Security

To ensure everything is working as expected, it’s crucial to test that app data isn’t backed up and that sensitive data remains secure:

• Backup Testing: After setting up the backup restriction, install the app, add some data, and try to back it up through device settings or ADB. Check to confirm that none of the app’s data is backed up.
• Encryption Verification: Attempt to access shared preferences or files outside the app’s context, such as by using a file manager or rooted device. This helps verify that sensitive data remains encrypted and unreadable, confirming the security setup is effective.

Testing these areas ensures that data protection features are robust and that user data remains secure, especially for apps managing sensitive information.

Conclusion 

Disabling app data backup in Android apps, especially financial ones, is essential for protecting user data and complying with strict security requirements. By making a few adjustments in the AndroidManifest and following secure data storage practices, you can help ensure that your app’s sensitive data remains safe from unauthorized backups and access. Implementing these steps and following security best practices will help you build a more secure financial app that safeguards your users’ valuable data.

In financial Android apps, setting up local session timeouts is essential to prevent unauthorized access if a user leaves the app unattended. With a session timeout, the app automatically logs the user out after a certain period of inactivity, adding a layer of security to protect sensitive data.

In this blog, I’ll walk you through:

• What a local session timeout is
• Why session timeouts are crucial for financial apps
• How to implement a session timeout in Kotlin with step-by-step code
• Best practices for managing session timeouts effectively

Let’s dive into how you can secure your app and enhance user trust by setting up session timeouts the right way.

What is a Local Session Timeout?

A local session timeout is a security feature that helps keep user data safe by tracking inactivity. If a user hasn’t interacted with the app for a set amount of time, the app will automatically log them out. This feature is especially important in financial apps, where protecting sensitive information is a top priority.

Why Local Session Timeout is Important for Financial Apps

In financial apps, leaving a session open can be a serious security risk. If someone else picks up the user’s phone, they could access the app and potentially perform unauthorized actions. By adding a session timeout, we:

• Reduce the risk of unauthorized access,
• Safeguard sensitive financial data, and
• Ensure compliance with security standards in the financial industry.

How to Set Up a Local Session Timeout

Here’s how to add a local session timeout feature to an Android app using Kotlin. We’ll take it step-by-step:

1. Define the Inactivity Timeout Duration — Decide how long the app should remain active without user interaction.
2. Track User Activity — Monitor interactions like touches, scrolls, or button presses to keep track of activity.
3. Reset the Timer — Each time the user interacts with the app, reset the timer to give them more active time.
4. Handle the Timeout — If no activity is detected within the specified time, log the user out automatically.

Step-by-Step Implementation in Kotlin

Step 1: Set Up Constants

First, let’s define a constant for our timeout duration. For example, we might want a timeout of 5 minutes.

const val TIMEOUT_DURATION = 5 * 60 * 1000L // 5 minutes in milliseconds

Step 2: Create a SessionManager Class

Next, let’s create a SessionManager class to handle the session tracking and timeout. This class will manage a timer that resets every time the user interacts with the app.

class SessionManager(private val context: Context) {

    private var timer: CountDownTimer? = null

    // Start or restart the inactivity timer
    fun startSessionTimeout() {
        timer?.cancel() // cancel any existing timer
        timer = object : CountDownTimer(TIMEOUT_DURATION, 1000L) {
            override fun onTick(millisUntilFinished: Long) {
                // Optionally, add logging or other feedback here
            }

            override fun onFinish() {
                onSessionTimeout()
            }
        }.start()
    }

    // Reset the timer on user interaction
    fun resetSessionTimeout() {
        startSessionTimeout()
    }

    // Handle session timeout (e.g., log the user out)
    private fun onSessionTimeout() {
        // Example action: Redirect to login screen
        context.startActivity(Intent(context, LoginActivity::class.java).apply {
            flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK
        })
    }

    // Cancel the timer when the session ends
    fun endSession() {
        timer?.cancel()
    }
}

• startSessionTimeout: Starts or restarts a countdown timer. If there’s no activity, onFinish() calls onSessionTimeout().
• resetSessionTimeout: Resets the timer whenever the user interacts with the app.
• onSessionTimeout: This function defines what happens when the timer expires. Here, we’re redirecting the user to the login screen.
• endSession: Cancels the timer when the session ends, helping save resources.

Step 3: Integrate Session Timeout in the Main Activity

In your main activity, you’ll initialize SessionManager and handle user interactions to keep the timer updated.

class MainActivity : AppCompatActivity() {

    private lateinit var sessionManager: SessionManager

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        sessionManager = SessionManager(this)

        // Start the session timer when the activity is created
        sessionManager.startSessionTimeout()
    }

    override fun onUserInteraction() {
        super.onUserInteraction()
        // Reset the session timeout on any user interaction
        sessionManager.resetSessionTimeout()
    }

    override fun onDestroy() {
        super.onDestroy()
        // End the session when the activity is destroyed
        sessionManager.endSession()
    }
}

• onUserInteraction: This built-in method is called whenever the user interacts with the app (touch, scroll, etc.). We’re using it to reset the session timeout.
• onDestroy: Stops the timer if the activity is destroyed, which helps save resources.

Step 4: Add Login Handling (Optional)

Redirecting the user to the login screen upon timeout adds an extra layer of protection for sensitive data. Assuming you have a LoginActivity set up, the SessionManager class will send users there if their session times out.

Best Practices for Session Timeout in Financial Apps

• Choose a Practical Timeout Duration: For financial apps, a timeout of 5 to 10 minutes of inactivity is generally a good choice. It strikes the right balance between keeping data secure and not being too disruptive for the user.
• Notify the User Before Logging Out: Many apps show a quick warning dialog just before logging out. This gives users a chance to stay logged in by interacting with the app, making the experience smoother and reducing unexpected logouts.
• Handle Background State Changes Carefully: If the user switches to another app or the app moves to the background, consider starting the timeout timer or even logging out immediately. This reduces the risk of leaving sensitive data open if the app isn’t actively being used.

Conclusion

Implementing session timeouts in financial apps is essential for protecting user data. I’ve shared how using Kotlin and Android’s CountDownTimer makes it simple to set up a reliable timeout system. By choosing a practical timeout duration, notifying users before logout, and handling background state changes, we can ensure that our apps are both secure and user-friendly.

As developers, it’s our job to safeguard sensitive information while making sure the app remains intuitive. With these steps in place, you’ll be able to create a financial app that balances both security and a smooth user experience. Keep iterating and refining—this approach will help you build a stronger, safer app over time.

These days, mobile apps—especially financial ones—are packed with sensitive data and powerful features, making security a top priority for Android developers. And it’s not just financial apps; protecting user data is now essential for every app. That’s why Google Play has introduced new guidelines focused on data security, pushing the entire Android ecosystem to be safer and more reliable.

In this guide, we’ll dive into essential techniques to keep your app secure, including rooting detection, blacklist checks, hardware fingerprinting, Google’s SafetyNet Attestation API, and TEE-backed fingerprint authentication—all with practical examples. Let’s explore how these security measures can give your app the edge it needs to keep users safe.

Introduction to Platform Security

Platform security means making sure your app interacts with the device and any external services in a safe, trusted way. Android gives developers a toolkit of APIs and strategies to spot tampered devices, confirm device identity, and securely authenticate users. By combining these security practices, you can block unauthorized access, detect risky devices, and strengthen your app’s overall security.

Rooted Device Detection

Rooted devices come with elevated privileges, giving deeper access to the operating system. While that sounds powerful, it opens up security risks—malicious actors could access sensitive data, bypass restrictions, and compromise your app’s integrity. That’s why detecting rooted devices is a crucial first step in securing your platform.

object RootDetectionUtils {
    private val knownRootAppsPackages = listOf(
        "com.noshufou.android.su",
        "com.thirdparty.superuser",
        "eu.chainfire.supersu",
        "com.koushikdutta.superuser",
        "com.zachspong.temprootremovejb"
    )
    
    private val rootDirectories = listOf(
        "/system/app/Superuser.apk",
        "/sbin/su",
        "/system/bin/su",
        "/system/xbin/su",
        "/data/local/xbin/su",
        "/data/local/bin/su",
        "/system/sd/xbin/su",
        "/system/bin/failsafe/su"
    )
    
    fun isDeviceRooted(): Boolean {
        return isAnyRootPackageInstalled() || isAnyRootDirectoryPresent()
    }

    private fun isAnyRootPackageInstalled(): Boolean {
        val packageManager = MyApp.instance.packageManager
        return knownRootAppsPackages.any { pkg ->
            try {
                packageManager.getPackageInfo(pkg, 0)
                true
            } catch (e: Exception) {
                false
            }
        }
    }

    private fun isAnyRootDirectoryPresent(): Boolean {
        return rootDirectories.any { File(it).exists() }
    }
}

Here,

1. Root Apps: Common packages associated with rooting are checked.
2. Root Directories: Checks if common files associated with rooting exist on the device.

When you call RootDetectionUtils.isDeviceRooted(), it returns true if the device is likely rooted.

Device Blacklist Verification

Some devices may have vulnerabilities or unsafe configurations that make them risky for secure applications. This is where device blacklisting comes into play. By comparing a device’s unique identifiers against a list maintained on a secure server, you can block these devices from accessing sensitive parts of your app, helping mitigate security risks.

import android.content.Context
import android.provider.Settings
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext
import okhttp3.OkHttpClient
import okhttp3.Request
import org.json.JSONArray

object DeviceBlacklistVerifier {
    private const val BLACKLIST_URL = "https://secureserver.com/device_blacklist" // Replace with your actual URL
    private val client = OkHttpClient()

    suspend fun isDeviceBlacklisted(context: Context): Boolean {
        val deviceId = Settings.Secure.getString(context.contentResolver, Settings.Secure.ANDROID_ID)
        val blacklistedDevices = fetchBlacklist()
        return blacklistedDevices.contains(deviceId)
    }

    private suspend fun fetchBlacklist(): List<String> {
        return withContext(Dispatchers.IO) {
            try {
                // Create a request to fetch the blacklist from your server
                val request = Request.Builder().url(BLACKLIST_URL).build()
                val response = client.newCall(request).execute()
                if (response.isSuccessful) {
                    val json = response.body?.string() ?: "[]"
                    val jsonArray = JSONArray(json)
                    val blacklist = mutableListOf<String>()
                    for (i in 0 until jsonArray.length()) {
                        blacklist.add(jsonArray.getString(i))
                    }
                    blacklist
                } else {
                    emptyList() // Return an empty list if fetching fails
                }
            } catch (e: Exception) {
                e.printStackTrace()
                emptyList() // Return an empty list if there's an error
            }
        }
    }
}

• The isDeviceBlacklisted function fetches the device ID and compares it against the list of blacklisted device IDs fetched from a remote server.
• The blacklist is fetched asynchronously using OkHttpClient to make an HTTP request to your server (you can replace BLACKLIST_URL with your actual URL).
• The server is expected to return a JSON array of blacklisted device IDs.

Obviously, to create a device blacklist, you first need to gather device IDs when the app is launched. If a user engages in suspicious or malicious activity, you can add their device to the blacklist. From then on, whenever the app is used, the system will check the device ID against the blacklist and block access if there’s a match.

While this method can be effective, it’s important to note that device IDs (like ANDROID_ID) can sometimes be reset or spoofed. To strengthen security, blacklisting can be combined with other checks such as root detection, device fingerprinting, or behavioral analytics.

Device Blacklisting in Financial Apps

In financial apps, device blacklisting is particularly crucial to protect sensitive information such as banking details, personal accounts, and transaction histories. The primary focus of device blacklisting in financial applications is to prevent access to the app from devices identified as risky. This is done by checking the device ID (such as ANDROID_ID, IMEI, or device fingerprint) against a predefined blacklist at the moment of access.

If the device ID matches a known compromised or fraudulent device (e.g., a rooted or jailbroken device), the app denies access to critical features such as financial transactions or account management. This helps prevent unauthorized users from accessing sensitive app features and ensures that only trusted devices can interact with the app.

For example, if a device has been flagged as compromised due to rooting, jailbreaking, or involvement in fraud, its device ID is added to the blacklist. On each login attempt, the app checks the device ID against this blacklist and blocks access if a match is found.

Device Blacklisting in Social Media & Dating Apps

While device blacklisting in financial apps focuses on preventing fraud and securing sensitive transactions, social media and dating apps tend to focus more on preventing misuse or abusive behavior. The secondary use of device blacklisting in these apps involves tracking suspicious activity over time, such as repeated rule violations or fraudulent actions, and then blacklisting those devices to prevent further misuse.

In this case, device IDs are often collected for future reference if a device is involved in any misuse or violation of the platform’s terms of service. For example, if a device is used to repeatedly create fake accounts, send spam, or engage in harassment, its device ID could be added to a blacklist. Once blacklisted, that device would be blocked from accessing the app entirely, protecting other users from any malicious activity.

Combining Blacklisting with Other Security Measures

Whether in financial apps or social media platforms, blacklisting should ideally be used in combination with other security mechanisms like root detection, device fingerprinting, and behavioral analytics. This layered approach provides a more comprehensive way to detect and block compromised devices, enhancing overall security.

For example, financial apps may also incorporate two-factor authentication (2FA), while social media apps may use behavioral monitoring to detect suspicious user actions that could trigger a device blacklist.

In short, device blacklisting plays a vital role in protecting apps from risky devices. In financial apps, it primarily focuses on preventing access from compromised devices in real-time, while in social media or dating apps, it may also serve as a tool for blocking devices that engage in malicious behavior or violate platform rules. Combining blacklisting with additional security features ensures a more secure and reliable user experience.

Device Fingerprinting / Hardware Detection

Device fingerprinting is a method used to uniquely identify a device based on its hardware features, making it easier to spot cloned or unauthorized devices trying to fake their identity. The main goal is to ensure that only trusted devices can access services, helping to prevent fraud. This fingerprint can also be used to track devices or authenticate users.

data class DeviceFingerprint(
    val androidId: String,
    val manufacturer: String,
    val model: String,
    val serial: String,
    val board: String
)

object DeviceFingerprintGenerator {
    fun getDeviceFingerprint(): DeviceFingerprint {
        return DeviceFingerprint(
            androidId = Settings.Secure.getString(
                MyApp.instance.contentResolver, Settings.Secure.ANDROID_ID
            ),
            manufacturer = Build.MANUFACTURER,
            model = Build.MODEL,
            serial = Build.getSerial(),
            board = Build.BOARD
        )
    }
}

// Usage
val fingerprint = DeviceFingerprintGenerator.getDeviceFingerprint()

Here,

• Unique Properties: Collects device-specific information to create a unique fingerprint.
• Serial Check: Uses Build.getSerial() if API level permits, adding a layer of uniqueness.

SafetyNet Attestation

Google’s SafetyNet Attestation API assesses the security integrity of an Android device, verifying that it’s not rooted or compromised. To use SafetyNet, you need to integrate Google Play Services. This API requires network access, so ensure your application has the necessary permissions.

In your build.gradle file, add the SafetyNet dependency

implementation 'com.google.android.gms:play-services-safetynet:18.0.1' // use latest version 

Implement SafetyNet Attestation

fun verifySafetyNet() {
    SafetyNet.getClient(this).attest(nonce, API_KEY)
        .addOnSuccessListener { response ->
            val jwsResult = response.jwsResult
            if (jwsResult != null) {
                // Verify JWS with server for authenticity and integrity.
                handleAttestationResult(jwsResult)
            }
        }
        .addOnFailureListener { exception ->
            // Handle error
        }
}

As we can see,

• SafetyNet Client: SafetyNet.getClient(context) initiates the SafetyNet client, enabling attestation requests.
• Attestation: The attest function generates an attestation result that can be verified on your server.
• Nonce: A random value used to ensure the attestation response is unique to this request.
• Verify on Server: To prevent tampering, verify the jwsResult on a secure server by validating its JSON Web Signature (JWS).
• JWS Result: The JSON Web Signature (JWS) is a token containing attestation results, which should be sent to the server to verify authenticity and device integrity.

TEE-Backed Fingerprint Authentication

TEE-Backed Fingerprint Authentication refers to fingerprint authentication that leverages the Trusted Execution Environment (TEE) of a device to securely store and process sensitive biometric data, such as fingerprints. The TEE is a secure area of the main processor that is isolated from the regular operating system (OS). It provides a higher level of security for operations involving sensitive data, like biometric information.

In Android, TEE-backed authentication typically involves the Secure Hardware or Trusted Execution Environment in combination with biometric authentication methods (like fingerprint, face, or iris recognition) to ensure that biometric data is processed in a secure and isolated environment. This means the sensitive data never leaves the secure part of the device and is not exposed to the operating system, apps, or any potential attackers.

For TEE-backed fingerprint authentication, you should use the BiometricPrompt approach, as it’s more secure, future-proof, and supports a broader range of biometrics (not just fingerprint) while ensuring compatibility with the latest Android versions.

fun authenticateWithFingerprint(activity: FragmentActivity) {
    // Create the BiometricPrompt instance
    val biometricPrompt = BiometricPrompt(activity, Executors.newSingleThreadExecutor(),
        object : BiometricPrompt.AuthenticationCallback() {
            override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
                // Authentication successful
                // Proceed with the app flow
            }

            override fun onAuthenticationFailed() {
                // Authentication failed
                // Inform the user
            }
        })

    // Create the prompt info
    val promptInfo = BiometricPrompt.PromptInfo.Builder()
        .setTitle("Authenticate")
        .setSubtitle("Please authenticate to proceed")
        .setNegativeButtonText("Cancel")
        .build()

    // Start the authentication process
    biometricPrompt.authenticate(promptInfo)
}

• BiometricPrompt: Provides a unified authentication dialog for fingerprint, face, or iris, backed by secure hardware (TEE) where available.
• PromptInfo: Configures the authentication dialog, including title, subtitle, and cancellation options.

This approach will automatically use the TEE or secure hardware for fingerprint authentication on supported devices, offering the highest security and compatibility.

Conclusion

By implementing these platform security measures, you can significantly enhance the security and integrity of your Android application. Rooted device detection, device blacklisting, device fingerprinting, SafetyNet attestation, and TEE-backed authentication provide a robust security foundation, making your app resilient against unauthorized access and device-level threats. Always remember that no single security measure is sufficient on its own; combining these approaches maximizes protection for your application and users.

Fingerprint authentication has become a widely used method for securing mobile devices and applications. In Android, fingerprint recognition is commonly integrated to enhance security, offering a faster, more convenient way to unlock devices and authenticate transactions. But what makes fingerprint authentication on Android so secure? The answer lies in the Trusted Execution Environment (TEE) – a secure area within your device’s processor where sensitive data can be processed and stored with enhanced protection.

In this blog, we’ll break down how TEE-backed fingerprint authentication works, explore the role of TEE in securing biometric data, and look at how Android implements this security feature.

What is Fingerprint Authentication?

Fingerprint authentication is a form of biometric authentication that uses the unique patterns on your fingers to verify your identity. In Android, it allows users to unlock their devices, authorize payments, log in to apps, and more, using only their fingerprints. While convenient, security is a major concern with biometric data. Fingerprint data is sensitive, and if compromised, it can be exploited. This is where the Trusted Execution Environment (TEE) comes into play.

Understanding the Trusted Execution Environment (TEE)

The Trusted Execution Environment (TEE) is a secure area within a device’s main processor (often referred to as a “secure enclave”) that provides a safe execution environment for code and data. It operates independently from the main operating system, making it isolated and resistant to attacks. The TEE is designed to ensure that sensitive operations (like biometric data handling) are protected from external threats, even if the device is compromised.

For Android devices, the TEE is part of the hardware and is typically supported by ARM-based processors through the ARM TrustZone technology. TrustZone creates a secure partition on the processor, allowing the execution of sensitive tasks like fingerprint matching, encryption, and decryption to happen in a protected environment.

How Does Fingerprint Authentication Work on Android?

When you set up fingerprint authentication on your Android device, several key steps occur to ensure that your fingerprint data is securely captured, stored, and matched.

1. Fingerprint Enrollment

During the enrollment process, you provide your fingerprint to the device’s fingerprint sensor. Here’s how it works:

• The device captures multiple images of your fingerprint using a capacitive or optical sensor.
• These images are processed to create a digital template that represents your fingerprint.
• The template is then encrypted and stored in the TEE for security. Importantly, only the encrypted version of the fingerprint data is kept on the device – the raw images are discarded immediately.

2. Fingerprint Matching

When you attempt to authenticate by scanning your fingerprint, the following steps occur:

• The fingerprint sensor captures your fingerprint image.
• The image is then sent to the TEE, where it is compared with the previously enrolled fingerprint template.
• The matching process occurs within the TEE, ensuring that the raw fingerprint data never leaves the secure enclave.
• If there’s a match, the TEE sends a signal back to the operating system to grant access.

3. Security Features of TEE-Backed Authentication

Here’s why TEE-backed fingerprint authentication is so secure:

• Isolation of Sensitive Data: The fingerprint template is stored in the TEE, which is isolated from the main operating system. This makes it extremely difficult for attackers to access the template or tamper with it.
• No Raw Data Exposure: Only encrypted fingerprint data is stored, and raw fingerprint images are never exposed to the OS or apps, minimizing the risk of leaks.
• Secure Matching: The matching process happens entirely within the TEE, so even if the device is compromised by malware, attackers cannot access the sensitive data or alter the matching process.
• Protection from Replay Attacks: TEE ensures that the fingerprint data cannot be intercepted or replayed by malicious actors, even if they gain access to certain device components.

How Android Implements TEE for Fingerprint Authentication

Android uses the Android Biometric API to integrate fingerprint authentication into apps. This API leverages the BiometricPrompt class, which is designed to work seamlessly with hardware-backed security, including the TEE. Here’s how the process flows:

1. BiometricPrompt: Apps call the BiometricPrompt API to request authentication. This triggers the system to invoke the fingerprint sensor.
2. TEE Communication: When a fingerprint is presented, the API works with the TEE to compare the sensor data against the stored fingerprint template.
3. Authentication Response: If authentication is successful, the device grants access. If not, the app or system can prompt the user to try again or use an alternate method (e.g., PIN, password).

fun authenticateWithFingerprint(activity: FragmentActivity) {
    // Create the BiometricPrompt instance
    val biometricPrompt = BiometricPrompt(activity, Executors.newSingleThreadExecutor(),
        object : BiometricPrompt.AuthenticationCallback() {
            override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
                // Authentication successful
                // Proceed with the app flow
            }

            override fun onAuthenticationFailed() {
                // Authentication failed
                // Inform the user
            }
        })

    // Create the prompt info
    val promptInfo = BiometricPrompt.PromptInfo.Builder()
        .setTitle("Authenticate")
        .setSubtitle("Please authenticate to proceed")
        .setNegativeButtonText("Cancel")
        .build()

    // Start the authentication process
    biometricPrompt.authenticate(promptInfo)
}

• BiometricPrompt: Provides a unified authentication dialog for fingerprint, face, or iris, backed by secure hardware (TEE) where available.
• PromptInfo: Configures the authentication dialog, including title, subtitle, and cancellation options.

This approach automatically leverages the TEE or secure hardware for fingerprint authentication on supported devices, ensuring the highest level of security and compatibility. Through this process, fingerprint data remains secure and private, even if the device is compromised.

Advantages of TEE-Backed Fingerprint Authentication in Android

• Increased Security: Biometric data is processed in a secure, isolated environment, making it resistant to malware, attacks, and unauthorized access.
• Prevention of Data Leakage: Since biometric data is not stored or processed by the OS, it is less vulnerable to being leaked or stolen by malicious apps or compromised OS components.
• Higher Authentication Accuracy and Trust: With TEE-backed processing, the fingerprint authentication process is more accurate and difficult to spoof, providing higher trust in the platform’s security.
• Device-Level Protection: The secure processing and storage of biometric data in the TEE protect users from attacks even if the device is rooted or the OS is compromised.

Conclusion

TEE-backed fingerprint authentication is a powerful and secure method for verifying user identity on Android devices. By isolating fingerprint data in a secure environment and ensuring that sensitive operations occur within the TEE, Android provides a robust defense against unauthorized access and data breaches. This approach balances convenience and security, making fingerprint authentication a trusted solution for modern smartphones and apps.

With the ongoing advancements in mobile security and biometric technology, TEE-backed authentication will continue to play a critical role in safeguarding user data and privacy on Android devices.

Application security is essential in any mobile app development strategy, especially on Android, where protecting user data and app integrity is paramount. This guide explores practical security measures, like app signing, certificate checksum verification, authorized install checks, code obfuscation, and secure distribution. We’ll walk through each step with hands-on examples in Kotlin, making complex security practices straightforward and actionable. By following along, you’ll learn how to apply these methods to enhance the security of your Android app effectively.

Why Application Security Matters

Application security is crucial for protecting user data, maintaining app integrity, and building trust with users. As the risk of app tampering, unauthorized installs, and reverse engineering continues to rise, developers must embrace best practices to safeguard their apps from the inside out.

By implementing these security techniques, we can reduce vulnerabilities, block unauthorized access, and ensure that user data remains safe and secure. It’s all about keeping your app resilient, trustworthy, and user-friendly in a world where security threats are ever-evolving.

Let’s go through them one by one and secure the Android app.

App Signing

App signing is the process of associating your app with a cryptographic key. This step is mandatory for Android apps, as it ensures the app’s authenticity and integrity. Signed apps guarantee to the operating system that the code comes from a verified source. App signing is a crucial security measure that allows users and devices to verify the app’s origin and integrity. Before publishing, you must sign your app with a private key, which acts as a unique identifier for the developer.

Imagine sending a sealed package to someone. When you put your personal signature on the seal, it acts as proof that the package is from you and hasn’t been tampered with. If the seal is broken or the signature is missing, the recipient would know something went wrong during delivery.

App signing works in a similar way in the digital world. When you develop an app, you “seal” it by signing it with a private key. This private key is unique to you as a developer, much like your personal signature. Once the app is signed, it receives a special “certificate” that helps devices and app stores confirm two things:

• Integrity: Has the app been tampered with? The certificate lets app stores and devices check if the app is exactly as you released it. If anyone tries to alter the code (like a hacker inserting malicious content), the certificate won’t match anymore, signaling tampering.
• Authenticity: Did the app really come from you? Your private key is unique to you, so the certificate proves that the app is genuinely yours. Without the correct signature, no one else can publish an update that would be accepted as an official version of your app.

Take a banking app, for example. When a bank releases its app, they sign it with their private key so customers know it’s genuine. If a counterfeit app appeared in the app store, it wouldn’t have that signature, helping protect users from downloading a fake app and risking their personal data.

In short, app signing builds trust. It reassures users that the app they’re downloading hasn’t been tampered with and genuinely comes from the original developer — just like your friend knows your letter is legit when they see your signature on the seal.

Steps for App Signing in Android Studio

1. Generate a Signing Key:

• In Android Studio, go to Build > Generate Signed Bundle / APK…
• Follow the prompts to create a new keystore, choosing a password and providing details.

2. Sign Your App:

• After creating the keystore, Android Studio will prompt you to select it for signing the app.
• Select your key alias and password, and proceed with the build.

Code Snippet: Configuring Signing in build.gradle

In app/build.gradle, add the following code under the android section to configure the signing process:

android {
    signingConfigs {
        release {
            keyAlias 'your-key-alias'
            keyPassword 'your-key-password'
            storeFile file('path/to/keystore.jks')
            storePassword 'your-keystore-password'
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

In Kotlin script (build.gradle.kts), the syntax is slightly different from the Groovy syntax used in build.gradle. Here’s how you can define the signing configuration in build.gradle.kts:

android {
    signingConfigs {
        create("release") {
            keyAlias = "your-key-alias"
            keyPassword = "your-key-password"
            storeFile = file("path/to/keystore.jks")
            storePassword = "your-keystore-password"
        }
    }
    buildTypes {
        getByName("release") {
            signingConfig = signingConfigs.getByName("release")
        }
    }
}

Build and Sign: Once configured, you can build a signed APK or App Bundle for distribution.

Note: Android apps are signed with custom CA certificates. Google offers the Play App Signing service, which is now mandatory for new apps and updates on the Google Play Store. This service allows you to securely manage and store your app signing key using Google’s infrastructure.

So, app signing guarantees that users receive authentic, untampered versions of your app.

App Certificate Checksum Verification

To add an extra layer of security, we can verify the app’s certificate checksum. This ensures the app hasn’t been tampered with since it was signed. Think of the checksum as a digital fingerprint — it confirms the app’s integrity and ensures it’s the original, untampered version.

By using the app signing certificate’s checksum, we can detect any tampering with the app’s code. If an attacker tries to alter the application, the original checksum will no longer match, serving as a red flag that something has been compromised. This verification helps us catch tampering early and prevent malicious code from executing, keeping both the app and its users secure.

To check your app’s signature in Android, you can retrieve and verify the certificate checksum using the following method.

import android.content.pm.PackageManager
import android.util.Base64
import java.security.MessageDigest

fun getCertificateChecksum(): String? {
    try {
        val packageInfo = context.packageManager.getPackageInfo(
            context.packageName,
            PackageManager.GET_SIGNING_CERTIFICATES
        )
        val signatures = packageInfo.signingInfo.apkContentsSigners
        val cert = signatures[0].toByteArray()  // Getting the certificate's byte array
        val md = MessageDigest.getInstance("SHA-256")  // Using SHA-256 for the checksum
        val checksum = md.digest(cert)  // Generating the checksum
        return Base64.encodeToString(checksum, Base64.NO_WRAP)  // Encoding the checksum in Base64
    } catch (e: Exception) {
        e.printStackTrace()
        return null
    }
}

To verify the certificate, simply compare the checksum with the expected value. This helps protect against tampering, as any change in the code will result in a different checksum.

Authorized Install Verification

To ensure your app is installed from a trusted source, like the Google Play Store, Android allows developers to verify the app’s integrity and security. You can use Google’s Play Integrity API (which we will cover in more detail in another blog; here we focus on the basics) to check if the app is running in a legitimate environment and hasn’t been tampered with, helping to prevent unauthorized installs.

import android.content.pm.PackageManager

fun isInstalledFromPlayStore(): Boolean {
    val installer = context.packageManager.getInstallerPackageName(context.packageName)
    return installer == "com.android.vending"  // Checks if installed from Google Play Store
}

This method checks whether the app was installed from the Google Play Store. If isInstalledFromPlayStore() returns false, it could mean the app was installed from an unofficial or unauthorized source.

Wait a minute… What would a simple client-server design look like for verifying authorized installations?

As our app is distributed exclusively through the App Store and Play Store, we verify the installation source on each app launch to detect counterfeit or sideloaded versions. If an unauthorized installation source is detected, a predetermined information packet is sent to the server instead of a simple flag. This allows the server to assess the authenticity of the installation source and take preventive actions, if necessary (such as terminating the app instance).

The following algorithm is used to derive strategic information (i.e., whether the installation is authorized or not) at both the client and server ends:

• If the app is installed from an unauthorized source, we send the server a SHA-256 hash generated from a unique device identifier that is securely shared between the client and server.
• If the app is installed from an authorized source, we send a 32-byte random number generated using Java’s SecureRandom, ensuring high security.

This approach enables the server to accurately distinguish between authorized and unauthorized installation sources, helping to prevent unauthorized app usage.

Code Obfuscation

Code Obfuscation is the practice of making source code difficult for humans (and automated tools) to understand by transforming it into a non-syntactical and non-natural language format. It is deliberately done to protect intellectual property and to prevent attackers or malicious entities from reverse-engineering proprietary software logic.

Increasing internal complexity through obfuscation makes it harder for attackers to understand how the app operates, thus reducing potential attack vectors.

Obfuscation is generally achieved by applying some of the following techniques:

• Renaming classes, methods, and variables to meaningless or random labels to hide the original intent of the code.
• Encrypting sensitive pieces of the code, such as strings or critical functions, to prevent them from being easily understood.
• Removing revealing metadata such as debug information and stack traces that could help reverse engineers understand the code’s structure.

Advantages:

• Code Bloat: Adding unused or meaningless code to the application increases complexity and can confuse reverse engineers.
• Prevents Reverse Engineering: Obfuscation makes it more difficult to reverse-engineer the source code, providing an added layer of protection.
• Protects Sensitive Information: By obscuring payment algorithms and other sensitive logic, obfuscation helps prevent fraud.
• IP Protection: Obfuscation safeguards proprietary code from theft, reducing the risk of cloning and unauthorized use.
• Secure Communication: It helps protect critical communication credentials (e.g., API keys, server communication details) by making them harder to extract.

How does it work?

Advanced code obfuscation in modern software development is typically achieved using automated tools called obfuscators. These tools apply various obfuscation techniques to the code, making it more difficult to analyze or reverse-engineer. When it comes to optimizing and securing Android apps, three primary tools stand out: R8, ProGuard, and DexGuard.

• R8: A code shrinker and obfuscator that comes bundled with Android Studio. It replaces ProGuard in Android projects starting from Android Gradle Plugin version 3.4 and beyond. R8 performs code shrinking, optimization, and obfuscation, making it more efficient than ProGuard in many cases.
• ProGuard: Originally designed as an optimization tool, ProGuard also provides obfuscation features. While it remains widely used, it’s primarily known for reducing the size of the app and optimizing bytecode, with obfuscation being an optional feature.
• DexGuard: A more advanced, proprietary obfuscator specifically designed for Android applications. DexGuard offers stronger obfuscation techniques and more comprehensive protection than ProGuard or R8, making it suitable for apps that require higher levels of security.

Setting Up ProGuard/R8

To enable code obfuscation in your Android app, you’ll need to configure ProGuard/R8 in your build.gradle file.

1. Enable Minification and Obfuscation:
In your android block, ensure that the minification and obfuscation are enabled for the release build type:

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro"
        }
    }
}

2. Add Custom Rules (Optional):
You can customize the behavior of ProGuard/R8 by adding rules to the proguard-rules.pro file. For example:

// It's in the ProGuard file, not in the Kotlin file. Due to the limitation of selecting a ProGuard file, I added it here.

# Keep specific classes
-keep class com.yourpackage.** { *; }
# Remove logging statements
-assumenosideeffects class android.util.Log {
    public static *** v(...);
    public static *** d(...);
    public static *** i(...);
    public static *** w(...);
    public static *** e(...);
}

3. Obfuscate and Test:
After configuring the build.gradle and rules file, build the release version of your app. This will obfuscate the code, making it more difficult for attackers to reverse engineer. Make sure to test the release version to ensure the obfuscation works correctly and that your app functions as expected.

Obfuscation protects sensitive parts of your code and can significantly reduce the likelihood of reverse engineering, adding an important layer of security for proprietary software.

Secure App Distribution

Our app should only be downloaded from official marketplaces — the Play Store for Android and the App Store for iOS. For security reasons, we don’t offer it through other channels like private marketplaces, direct links, emails, or corporate portals. Using a trusted distribution channel helps protect your app from being tampered with or repackaged. Google Play, for example, offers features like Play Protect, automatic updates, and full control over distribution, making it one of the most secure options.

Tips for Secure Distribution

• Use the Google Play Console: It offers extra security with app signing and Play Protect.
• Enable Play App Signing: When you upload your app, go to App Integrity and select Manage your app signing key. Google will manage your app’s signing key, making it more secure and reducing the risk of key compromise.
• Use App Bundles: App Bundles not only help reduce APK size but also provide extra protection through Google’s secure servers.
• Avoid Third-Party App Stores: Stick to trusted platforms to keep your app safe.

Other Secure Distribution Options

• In-House Distribution: For private app distribution, use secure enterprise app stores.
• Encrypted File Transfer: If you’re sharing the APK manually, consider encrypting it before sending.

By distributing your app through Google Play, you’re making sure users get a secure, legitimate version of your app.

Conclusion

Securing an Android app is a process that requires attention to detail at every stage, from app signing and checksum verification to ensuring secure distribution. By following the practices outlined in this guide—like app signing, certificate checksum verification, authorized install checks, code obfuscation, and secure distribution—you can significantly improve your app’s defense against common security threats.

By applying these techniques, you’ll not only meet industry standards but also build trust with your users by protecting their data and providing a safe experience. Just remember, app security isn’t a one-time thing—it’s an ongoing effort. Staying up to date with the latest security practices is key to long-term success.