AES/ECB/NoPadding加密模式遭Google Play拒审，求兼容现场设备方案

核心思路 #

保留对旧信标的ECB模式兼容，同时在其他通信场景切换为安全加密算法，向Google Play明确说明ECB的使用场景与必要性。

方案1：双加密模式分支实现 #

针对不同通信对象选择对应加密逻辑，完全不破坏现有信标通信流程：

• 与现场信标通信：继续使用AES/ECB/NoPadding，保持原有协议不变
• 与API通信：切换为AES/GCM/NoPadding（或其他Google认可的安全加密模式）

可通过设备标识（如信标固件版本、硬件ID）判断使用哪种加密方式，示例代码如下：

// Java示例代码
public Cipher createCipher(String targetType, SecretKey key, boolean isEncrypt, byte[] iv, byte[] tag) throws Exception {
    Cipher cipher;
    if ("legacy_beacon".equals(targetType)) {
        // 旧信标专属：ECB模式
        cipher = Cipher.getInstance("AES/ECB/NoPadding");
        cipher.init(isEncrypt ? Cipher.ENCRYPT_MODE : Cipher.DECRYPT_MODE, key);
    } else {
        // API或新设备：GCM模式
        cipher = Cipher.getInstance("AES/GCM/NoPadding");
        if (isEncrypt) {
            cipher.init(Cipher.ENCRYPT_MODE, key);
        } else {
            // GCM解密需传入IV和认证标签
            GCMParameterSpec spec = new GCMParameterSpec(128, iv, tag);
            cipher.init(Cipher.DECRYPT_MODE, key, spec);
        }
    }
    return cipher;
}

提交审核时需在合规说明中明确：

• ECB仅用于兼容无法升级固件的现场信标
• 信标传输的是内部协议数据，不涉及任何用户敏感信息
• API通信已全部切换为安全的GCM模式

方案2：为ECB传输添加额外安全防护 #

若必须保留ECB模式，可通过完整性校验弥补其安全缺陷，提升审核通过率：

• 在ECB加密的数据末尾追加HMAC-SHA256校验值，传输时一并发送
• 信标端解密后先校验HMAC，确保数据未被篡改

示例伪代码：

// 加密时添加HMAC校验
byte[] ecbEncrypted = cipher.doFinal(rawData);
Mac hmac = Mac.getInstance("HmacSHA256");
hmac.init(hmacKey);
byte[] hmacValue = hmac.doFinal(ecbEncrypted);
// 拼接加密数据与HMAC后发送
byte[] finalData = ByteBuffer.allocate(ecbEncrypted.length + hmacValue.length)
        .put(ecbEncrypted)
        .put(hmacValue)
        .array();

方案3：分阶段过渡（长期优化） #

若后续有信标固件升级计划：

1. 当前版本先实现双模式兼容，快速通过审核
2. 在应用管理员端添加提示功能，引导升级信标固件至支持GCM的版本
3. 待大部分信标完成升级后，发布新版本移除ECB模式

审核说明关键要点 #

提交Google Play审核时，务必在安全说明中明确：

• ECB模式的使用范围仅针对无法升级的旧信标
• 传输数据为内部非敏感协议内容，无用户隐私数据
• 提供信标固件仅支持ECB的证明材料（如厂商文档、固件规格）

内容的提问来源于stack exchange，提问作者Álvaro