告别SharedPreferences！DataStore+Android Keystore构建安全存储新防线

小码哥_常
4 阅读17分钟

告别SharedPreferences！DataStore+Android Keystore构建安全存储新防线

一、引言：数据安全的警钟

在数字化浪潮汹涌的当下，数据已然成为个人、企业乃至国家最为珍贵的资产之一。从我们日常使用的手机 App，到企业运行的核心业务系统，数据的身影无处不在，它承载着个人隐私、商业机密与国家安全的重任。数据安全，绝非一个可有可无的选项，而是一道生死攸关的防线。一旦数据安全的堡垒被攻破，个人可能面临隐私泄露、财产受损；企业则可能丢失商业机密，声誉扫地，甚至陷入生存危机；对国家而言，关键领域的数据泄露更可能威胁到国家安全与稳定。

在 Android 开发的广袤天地里，数据存储的安全始终是开发者心头的重中之重。长久以来，SharedPreferences 作为一种轻量级的键值对存储方式，因其简单易用，深受开发者喜爱，被广泛应用于存储各种配置信息与少量数据。然而，随着安全威胁的日益复杂与多样化，SharedPreferences 在存储敏感数据时的短板逐渐暴露无遗，犹如一座看似坚固实则脆弱的纸糊城堡。

SharedPreferences 采用明文形式将数据存储在 XML 文件中，这就好比把珍贵的珠宝随意放置在一个没有上锁的箱子里，任何人只要有机会接触到这个箱子（Root 设备直接读取），就能轻而易举地获取其中的敏感信息。并且，该文件没有任何完整性校验机制，这意味着数据就像一个任人打扮的 “小姑娘”，可被随意篡改，比如恶意修改用户的 VIP 状态。此外，在多进程环境下，它的表现也不尽人意，并发访问极易导致数据损坏，就像多个人同时争抢修改一份文件，最终文件变得混乱不堪。同时，当应用开启备份功能时，其中的数据会随着备份被导出，造成数据泄露。更为致命的是，从 SharedPreferences 中获取的数据会常驻内存，一旦内存被 dump，敏感信息便会毫无遮拦地暴露在攻击者面前。

鉴于 SharedPreferences 存在的种种不足，为了给数据安全提供更可靠的保障，我们急需一种全新的解决方案。DataStore 与 Android Keystore 的组合方案应运而生，宛如两把利刃，为数据安全保驾护航，成为打造硬件级安全存储的绝佳选择 。接下来，就让我们一同深入探索这一强大组合的奥秘与实践之道。

二、SharedPreferences 的安全短板

（一）明文存储风险

SharedPreferences 采用明文 XML 格式存储数据，这就好比把珍贵的信息毫无遮掩地暴露在众人面前。在 Root 设备上，任何人都能直接读取这些数据，敏感信息如账号密码、支付凭证、个人身份信息等一旦被获取，后果不堪设想。曾有一款热门的理财 App，开发者为了图方便，使用 SharedPreferences 明文存储用户的登录密码与交易密码，结果被黑客利用 Root 权限轻松获取了大量用户密码，导致众多用户遭受财产损失，该 App 的声誉也一落千丈，用户纷纷流失。

（二）无完整性校验

由于缺乏完整性校验机制，SharedPreferences 中的数据就像一座没有安保的仓库，极易被篡改。以 Xposed 框架 Hook 技术为例，恶意攻击者可以利用它修改应用内的数据，比如将普通用户的权限篡改为管理员权限，或者修改用户的消费记录、积分余额等。曾经有一款电商 App，被黑客利用 Xposed 框架修改了用户的积分数据，大量用户通过非法手段获取了高额积分并用于兑换商品，给平台造成了巨大的经济损失。

（三）进程不安全

在多进程环境中，SharedPreferences 无法保证数据的一致性和完整性。当多个进程同时访问和修改同一个 SharedPreferences 文件时，就像多个人同时编辑一份文档，却没有任何协调机制，很容易出现数据覆盖、丢失或损坏的情况。例如，一个即时通讯 App 在多进程架构下，不同进程同时更新用户的聊天记录存储在 SharedPreferences 中，结果导致聊天记录混乱，部分消息丢失，严重影响了用户体验。

（四）备份泄露隐患

当应用的 allowBackup 属性未关闭时，使用 adb backup 命令就可以导出包含敏感数据的明文备份。这就如同把家门钥匙随意交给他人，任何人都能轻松获取应用中的数据。曾经有一款社交 App，用户在不知情的情况下，其聊天记录、好友列表等数据被通过 adb backup 导出，造成了严重的隐私泄露事件，引发了用户的强烈不满和信任危机。

（五）内存残留风险

当使用 getString ()、getInt () 等方法从 SharedPreferences 中获取数据时，返回的字符串或基本数据类型可能会常驻内存。一旦内存被 dump，这些敏感信息就会毫无保留地暴露出来。例如，一款包含用户身份证号码、银行卡号等重要信息的金融 App，由于数据在内存中的残留，被黑客通过内存 dump 技术获取，导致大量用户的财务信息泄露，引发了一系列的金融风险和法律纠纷。

三、新一代安全存储架构解析

（一）架构总览

为了彻底解决 SharedPreferences 存在的安全问题，我们引入了 DataStore 与 Android Keystore 相结合的全新存储架构。这个架构就像是一座精心构建的城堡，各个部分紧密协作，为数据安全提供全方位的防护 。

从业务层发起数据存储请求，数据首先进入由我们自定义的 SecureStorage 封装层。在这里，数据会接受加密处理，而加密所使用的密钥则来自 Android Keystore。Android Keystore 如同城堡中最坚固的密室，负责管理硬件级别的密钥，确保密钥的安全存储与使用。加密后的数据随后被传递到 DataStore，DataStore 则像是忠诚的管家，将加密数据持久化存储在应用的私有目录中，以.protobuf 格式存储，进一步保障数据的安全性与完整性。

在这个架构中，数据的流向清晰明确，每一层都肩负着重要的职责。业务层专注于业务逻辑的处理，SecureStorage 封装层负责数据的加密与解密，Android Keystore 保障密钥的安全，DataStore 实现加密数据的可靠持久化。它们相互配合，从业务层到硬件级安全域，构建起一个完整的安全存储体系，为数据安全保驾护航。

（二）Android Keystore：硬件级密钥管理

  1. 原理剖析：Android Keystore 是一个至关重要的系统级服务，其核心使命是安全地存储加密密钥，确保这些密钥不会暴露在外部，从而为数据加密提供坚实的基础。它就像是一个坚固的保险库，密钥被妥善保管其中，任何未经授权的访问都将被拒之门外。

Android Keystore 支持与硬件安全模块（HSM）集成，这使得密钥的存储和管理更加安全可靠。通过与硬件的紧密结合，密钥被存储在专门的硬件区域，即可信执行环境（TEE）中。在这个安全区域内，密钥的生成、存储和使用都受到严格的保护，即使操作系统本身也无法直接访问这些密钥，极大地降低了密钥被恶意获取的风险。

  1. 优势解读：Android Keystore 的优势显著，它实现了密钥的硬件隔离，这意味着即使设备被 Root，攻击者也无法提取存储在其中的密钥。例如，在一些金融类应用中，用户的交易密钥通过 Android Keystore 存储，即使设备不幸被 Root，黑客也无法获取这些关键密钥，从而保障了用户的资金安全。

Android Keystore 还可以将密钥与设备进行绑定，确保密钥只能在特定设备上使用，进一步增强了安全性。它支持设置密钥的使用限制，比如指定密钥只能用于特定的加密模式或特定的操作，有效防止密钥的滥用。此外，它还能与生物识别技术集成，如指纹识别、面部识别等，只有在用户通过生物识别验证后，密钥才能被使用，为数据安全增添了一道强大的防线。

（三）DataStore：加密数据持久化

  1. 特性介绍：DataStore 是 Android 官方力荐的轻量级数据持久化方案，它基于 Kotlin Coroutines 和 Flow 构建，具有诸多卓越特性。DataStore 具备线程安全的特性，这使得它在多线程环境下能够稳定运行，不会出现数据不一致或损坏的情况。它支持原子写入，确保数据的完整性，即使在写入过程中出现异常，也不会导致数据丢失或损坏。DataStore 还提供了数据变化监听功能，通过 Kotlin Flow，我们可以实时监听数据的变化，及时做出相应的处理，为应用的开发带来了极大的便利。

  2. 与 SharedPreferences 对比：与 SharedPreferences 相比，DataStore 在多个方面展现出明显的优势。在安全性上，DataStore 本身并不直接提供加密功能，但结合 Android Keystore 后，可以实现数据的加密存储，弥补了 SharedPreferences 明文存储的缺陷。在性能方面，DataStore 的异步操作特性避免了对主线程的阻塞，提高了应用的响应速度，而 SharedPreferences 在多进程环境下的同步操作容易导致性能瓶颈。在数据监听方面，DataStore 借助 Flow 能够轻松实现实时监听数据变化，而 SharedPreferences 则缺乏这样便捷的机制。DataStore 在多进程访问时能够保证数据的一致性，而 SharedPreferences 在多进程环境下存在诸多问题，容易导致数据丢失或损坏 。

四、实战：四层安全封装实现

（一）添加依赖

在项目的build.gradle.kts文件中，添加 DataStore 和协程的依赖，代码如下：


dependencies {
    // DataStore依赖
    implementation("androidx.datastore:datastore-preferences:1.0.0")
    // 协程核心库依赖
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.7.3")
    // 协程Android扩展库依赖
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.3")
}

其中，androidx.datastore:datastore-preferences是 DataStore 的依赖，用于实现数据的持久化存储。org.jetbrains.kotlinx:kotlinx-coroutines-core是协程的核心库，提供了协程的基本功能。org.jetbrains.kotlinx:kotlinx-coroutines-android是协程在 Android 平台上的扩展库，提供了与 Android 相关的功能，如在 Android 主线程中运行协程等 。

（二）Keystore 密钥管理

  1. 代码实现：

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

class KeystoreManager(private val context: Context) {
    private val keyStore: KeyStore by lazy {
        KeyStore.getInstance("AndroidKeyStore").apply {
            load(null)
        }
    }
    private val keyAlias = "my_secret_key"

    fun generateKey() {
        val keyGenerator = KeyGenerator.getInstance(
            KeyProperties.KEY_ALGORITHM_AES,
            "AndroidKeyStore"
        )
        val spec = KeyGenParameterSpec.Builder(
            keyAlias,
            KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
        )
           .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
           .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
           .setKeySize(256)
           .setUserAuthenticationRequired(true)
           .setRandomizedEncryptionRequired(true)
           .setIsStrongBoxBacked(true)
           .build()
        keyGenerator.init(spec)
        keyGenerator.generateKey()
    }

    fun getSecretKey(): SecretKey? {
        return keyStore.getKey(keyAlias, null) as? SecretKey
    }
}

在这段代码中，generateKey方法用于生成密钥。首先通过KeyGenerator获取实例，并指定使用AndroidKeyStore。然后构建KeyGenParameterSpec，其中：

  • PURPOSE_ENCRYPT or PURPOSE_DECRYPT指定密钥用途为加密和解密。

  • BLOCK_MODE_GCM设置加密模式为 GCM，它具有认证加密的功能，能有效防止数据被篡改和重放攻击。

  • ENCRYPTION_PADDING_NONE表示不使用填充模式，因为 GCM 模式本身不需要填充。

  • setKeySize(256)设置密钥大小为 256 位，提供更高的安全性。

  • setUserAuthenticationRequired(true)要求在使用密钥时进行用户认证，比如指纹识别或面部识别，确保只有合法用户才能使用密钥。

  • setRandomizedEncryptionRequired(true)启用随机化加密，增加加密的安全性。

  • setIsStrongBoxBacked(true)表示使用 StrongBox 来存储密钥，提供硬件级别的安全保护。

getSecretKey方法则用于从KeyStore中获取已生成的密钥。

  1. 防降级攻击策略：为了防止密钥被降级使用，我们可以通过版本管理和安全参数设置来实现。在生成密钥时，记录当前的安全参数和版本信息。每次使用密钥前，检查这些信息，确保密钥的安全性没有被降低。例如，可以在KeyGenParameterSpec中添加一个自定义的版本号参数，在使用密钥时验证该版本号是否匹配当前的安全策略。如果版本号不匹配，说明密钥可能被降级使用，此时应拒绝使用该密钥，并提示用户重新生成密钥，以保障数据的安全性。

（三）认证加密工具

  1. 加密算法选择：我们选择 AES - GCM 加密算法，它是一种高级加密标准，结合了伽罗瓦 / 计数器模式（GCM）。GCM 模式具有以下优势：它提供了认证加密功能，在加密数据的同时生成一个消息认证码（MAC），用于验证数据的完整性和真实性，有效防止数据被篡改。它还能抵御重放攻击，确保数据的新鲜性。在 GCM 模式中，初始向量（IV）的随机化非常重要，它能保证每次加密相同的数据时生成不同的密文，增加加密的安全性。

  2. 加解密代码实现：


import android.util.Base64
import java.security.SecureRandom
import java.security.spec.KeySpec
import java.util.*
import javax.crypto.Cipher
import javax.crypto.SecretKey
import javax.crypto.SecretKeyFactory
import javax.crypto.spec.GCMParameterSpec
import javax.crypto.spec.IvParameterSpec
import javax.crypto.spec.SecretKeySpec

class CryptoUtil {
    private val ivSize = 12
    private val tagSize = 16

    fun encrypt(plaintext: String, secretKey: SecretKey): String {
        val cipher = Cipher.getInstance("AES/GCM/NoPadding")
        val iv = ByteArray(ivSize)
        SecureRandom().nextBytes(iv)
        val gcmSpec = GCMParameterSpec(tagSize * 8, iv)
        cipher.init(Cipher.ENCRYPT_MODE, secretKey, gcmSpec)
        val encrypted = cipher.doFinal(plaintext.toByteArray())
        val combined = ByteArray(iv.size + encrypted.size)
        System.arraycopy(iv, 0, combined, 0, iv.size)
        System.arraycopy(encrypted, 0, combined, iv.size, encrypted.size)
        return Base64.encodeToString(combined, Base64.DEFAULT)
    }

    fun decrypt(ciphertext: String, secretKey: SecretKey): String {
        val decoded = Base64.decode(ciphertext, Base64.DEFAULT)
        val iv = ByteArray(ivSize)
        System.arraycopy(decoded, 0, iv, 0, ivSize)
        val encrypted = ByteArray(decoded.size - ivSize)
        System.arraycopy(decoded, ivSize, encrypted, 0, encrypted.size)
        val gcmSpec = GCMParameterSpec(tagSize * 8, iv)
        val cipher = Cipher.getInstance("AES/GCM/NoPadding")
        cipher.init(Cipher.DECRYPT_MODE, secretKey, gcmSpec)
        val decrypted = cipher.doFinal(encrypted)
        return String(decrypted)
    }
}

在加密函数encrypt中，首先获取AES/GCM/NoPadding模式的Cipher实例。生成一个 12 字节的随机 IV，用于初始化 GCM 模式。创建GCMParameterSpec，指定认证标签的大小为 16 字节。将 IV 和加密后的密文拼接在一起，然后使用 Base64 编码返回。

在解密函数decrypt中，先对 Base64 编码的密文进行解码。从解码后的字节数组中提取 IV 和密文。创建GCMParameterSpec，使用相同的 IV 和标签大小。初始化Cipher为解密模式，进行解密操作，最后返回解密后的明文。通过这些步骤，实现了数据的安全加密和解密 。

（四）安全存储封装

  1. DataStore 初始化：

import android.content.Context
import androidx.datastore.core.DataStore
import androidx.datastore.preferences.core.Preferences
import androidx.datastore.preferences.core.edit
import androidx.datastore.preferences.core.stringPreferencesKey
import androidx.datastore.preferences.preferencesDataStore
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.map

val Context.secureDataStore by preferencesDataStore(name = "secure_data_store")

class SecureStorage(private val context: Context) {
    private val authTokenKey = stringPreferencesKey("auth_token")

    suspend fun saveAuthToken(token: String) {
        val secretKey = KeystoreManager(context).getSecretKey()
        val encryptedToken = CryptoUtil().encrypt(token, secretKey!!)
        context.secureDataStore.edit { preferences ->
            preferences[authTokenKey] = encryptedToken
        }
    }

    fun getAuthTokenFlow(): Flow<String?> {
        return context.secureDataStore.data
           .map { preferences ->
                val encryptedToken = preferences[authTokenKey]
                if (encryptedToken != null) {
                    val secretKey = KeystoreManager(context).getSecretKey()
                    CryptoUtil().decrypt(encryptedToken, secretKey!!)
                } else {
                    null
                }
            }
    }
}

在Context上定义secureDataStore，使用preferencesDataStore并指定名称为secure_data_store，确保 DataStore 的单例模式。名称的选择应具有明确的含义，便于区分不同的 DataStore 实例，同时遵循项目的命名规范。

  1. 数据存储与读取：在SecureStorage类中，saveAuthToken方法用于保存敏感数据，如 AuthToken。首先从KeystoreManager获取密钥，然后使用CryptoUtil对 Token 进行加密，最后将加密后的 Token 存储到secureDataStore中。

getAuthTokenFlow方法通过Flow实时监听secureDataStore中数据的变化。在获取数据时，先从secureDataStore中读取加密后的 Token，然后使用密钥进行解密，返回解密后的 Token。

为了实现埋点审计，我们可以在数据存储和读取的关键步骤添加日志记录。例如，在saveAuthToken方法中，记录存储的时间、用户 ID（如果有）、存储的数据类型等信息；在getAuthTokenFlow方法中，记录读取的时间、用户 ID、是否成功读取等信息。这些日志可以帮助我们追踪数据的使用情况，及时发现潜在的安全问题 。

五、应用案例与最佳实践

（一）实际应用案例展示

以某知名金融 APP 为例，在采用 DataStore + Android Keystore 安全存储方案之前，曾因使用 SharedPreferences 存储用户的交易密码和账户余额等敏感信息，遭受过一次严重的数据泄露攻击。黑客利用 Root 设备直接读取了 SharedPreferences 文件，获取了大量用户的敏感数据，导致用户对该 APP 的信任度急剧下降，用户流失严重。

在遭受攻击后，该 APP 迅速进行了技术升级，采用了 DataStore + Android Keystore 的安全存储方案。通过 Android Keystore 对密钥进行硬件级别的安全管理，确保密钥不会被非法获取。利用 AES - GCM 加密算法对敏感数据进行加密，并通过 DataStore 将加密后的数据持久化存储。

升级后，该 APP 再也没有出现过数据泄露事件。用户的敏感数据得到了有效的保护，安全性得到了显著提升。用户对该 APP 的信任度也逐渐恢复，用户活跃度和留存率都有了明显的提高。该 APP 在应用商店的评分也从攻击后的低分逐渐回升，业务量持续增长。这充分证明了 DataStore + Android Keystore 安全存储方案在实际应用中的有效性和可靠性 。

（二）最佳实践建议

  1. 密钥管理：定期更新密钥是保障数据安全的重要措施。根据业务的敏感程度和风险评估，制定合理的密钥更新周期，如每 3 - 6 个月更新一次。在更新密钥时，要确保新密钥的生成和分发过程的安全性，防止密钥在更新过程中被泄露。

不同的数据类型和安全级别应使用不同的密钥。例如，对于用户的登录密码、支付密码等极其敏感的数据，使用独立的高强度密钥进行加密；对于一些相对不那么敏感的配置信息，可以使用较低强度的密钥。这样可以在保证数据安全的前提下，提高密钥管理的效率。同时，对密钥进行严格的访问控制，只有经过授权的模块或用户才能访问特定的密钥，遵循最小权限原则，降低密钥泄露的风险 。

  1. 数据存储：对不同敏感程度的数据进行分类存储，避免将所有敏感数据集中存储在一个地方。可以将敏感数据按照业务模块、数据类型等进行划分，分别存储在不同的 DataStore 实例或文件中。这样，即使某个存储区域的数据被泄露，也能最大限度地减少对其他数据的影响。

在存储敏感数据时，要遵循最小化存储原则，只存储必要的数据。避免过度收集和存储用户的敏感信息，减少数据泄露的风险点。对存储的敏感数据进行定期清理，删除过期或不再使用的数据，降低数据管理的成本和风险 。

  1. 性能优化：对于高频读写操作，可以采用批量读写的方式来提高性能。例如，在存储多个用户的配置信息时，将这些信息批量写入 DataStore，而不是逐个写入，减少 I/O 操作的次数。可以使用缓存机制，将经常读取的数据缓存在内存中，避免频繁从 DataStore 中读取数据，提高数据的读取速度。

合理设计数据结构和存储方式也能提升性能。根据数据的访问模式和特点，选择合适的存储格式和组织方式。对于需要频繁查询的数据，可以建立索引或使用更高效的数据结构，如哈希表、B - 树等，以加快数据的查询速度 。

avatar
文章
阅读
粉丝