Google Play控制台误判AES-CMAC为不安全加密模式的技术问询

本文重发自Google Play开发者支持线程，依据Google支持FAQ答复要求发布于此。

我们的应用近期在Google Play控制台中被标记为「应用包含不安全加密模式」「不安全加密错误」「安全与信任问题」。起初我们并未在意，因为被引用的类与方法是AES-CMAC实现。

相关标准依据 #

• 2006年发布的《AES-CMAC算法》（RFC 4493）
• NIST出版物NIST SP-800 38B
• 相关概述见One-key MAC条目

我们曾期望该误判能被审核修复，但多年来始终未解决。

显然应用扫描器未理解Cipher-MAC的内部逻辑：AES-CMAC初始化过程中需生成子密钥，而这一步涉及对块大小（AES为16字节）的全零字节数组进行加密。

具体可参考RFC 4493的2.3节与图2.2：

Constants: const_Zero is 0x00000000000000000000000000000000
           const_Rb is 0x00000000000000000000000000000087
Variables: L for output of AES-128 applied to 0^128

Step 1. L := AES-128(K, const_Zero)
Step 2. if MSB(L) is equal to 0
        then K1 := L << 1;
        else K1 := (L << 1) XOR const_Rb;
Step 3. if MSB(K1) is equal to 0
        then K2 := K1 << 1;
        else K2 := (K1 << 1) XOR const_Rb;
Step 4. return K1, K2;

使用Jetpack Security或EncryptedSharedPreferences并非解决方案——因为这些工具不提供AES-CMAC功能，且此次标记完全是误报，因此Google的FAQ答复在此场景下无效。

AES-CMAC功能对我们的应用至关重要，因为相关基础设施要求遵循以下标准：

• BSI TR-03110-3的A.1.1节
• BSI TR-03111的5.3.1.2节
• ANSSI eIDAS
  等其他标准。

我们的问题 #

1. 谁对此误判负责？
2. 该问题何时能修复？

编辑与更新 #

• 编辑：为读者添加了指向无效Google FAQ答复的直接链接。
• 更新1：Google Play控制台支持团队已两次回复，表示需要更多时间调查该问题，并告知将有技术工程师联系我以进一步澄清细节，后续会同步进展。
• 更新2：是否有NIST的工作人员在此？向Google解释NIST SP 800-38B的6.1节「子密钥生成」，尤其是其中被扫描器检测到的CIPHK(0b)操作，或许能有所帮助。

Prerequisites:
    block cipher CIPH with block size b;
    key K.
Output:
    subkeys K1, K2.
    Suggested Notation: SUBK(K).
Steps:
    1. Let L = CIPHK(0b).
    2. If MSB1(L) = 0, then K1 = L << 1; Else K1 = (L << 1) ⊕ Rb; see Sec. 5.3 for the definition of Rb.
    3. If MSB1(K1) = 0, then K2 = K1 << 1; Else K2 = (K1 << 1) ⊕ Rb.
    4. Return K1, K2.

内容的提问来源于stack exchange，提问作者Christian Kahlo