CMAC 在安全通道協議 3 (SCP03) 中使用什麼 AES 模式？
我正在尋找根據 SCP03 驗證從智能卡晶片發送的卡密碼。根據 SCP03 規範，CMAC 用於生成 MAC 以驗證發送到/來自安全元件的消息。
SCP03規範說CBC模式下的AES用於加密和解密，但不清楚CMAC使用什麼模式。
目前我正在使用 OMAC1，它在 ECB 模式下使用 AES。我的 CMAC（在 KDF 計數器模式下）使用 NIST 提供的測試向量（https://csrc.nist.gov/CSRC/media/Projects/Cryptographic-Algorithm-Validation-Program/documents/KBKDF800-108/CounterMode.zip )，但是，在與安全元件交談時，我沒有生成正確的卡密碼。
我已經仔細檢查了 CMAC 的密鑰和固定輸入數據是否正確。
術語通常令人困惑：
- AES-CBC != AES-CMAC（但如果 AES-CMAC 使用 CBC 那麼它是否與 AES-CBC 相同……）
- OMAC1 == AES-CMAC（但 OMAC1 使用 ECB 而 AES-CMAC 可以使用任何 AES 模式…）
SCP03 CMAC 規範狀態（連結如下）：
$$ link 2 $$第 4.1.3 節： 中指定的 CMAC
$$ NIST 800-38B $$用於 MAC 計算。注意$$ NIST 800-38B $$還指定要應用於輸入的填充。這符合$$ FIPS 140-2 $$附件 A（消息認證 – 3）。 $$ link - 2 $$第 4.1.5 節： 數據推導應在 NIST SP 800-108 中指定的計數器模式下使用 KDF
$$ NIST 800-108 $$. KDF 中使用的 PRF 應為 CMAC，如$$ NIST 800-38B $$，與完整的 16 字節輸出長度一起使用。
以下是來自失敗的安全元素的範例單元測試：
// The static key used to generate the session MAC key uint8_t key_raw[16] = { 0x58, 0x56, 0x33, 0x62, 0xEC, 0x5A, 0x45, 0x41, 0xAB, 0xCD, 0x32, 0xB3, 0x4B, 0x1E, 0xAE, 0x7D }; // Used to generate the session MAC key uint8_t key_derivation_data_raw[32] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06, // derivation constant 0x00, // separator byte 0x00, 0x80, // length 0x01, // iteration counter 0xA6, 0xFE, 0xFE, 0xAE, 0xB2, 0xE1, 0x27, 0x18, // host challenge 0x51, 0x70, 0xF4, 0x5F, 0xCA, 0x00, 0x00, 0x15 }; // card challenge // Used to generate the card cryptogram uint8_t data_raw[32] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // derivation constant 0x00, // separator byte 0x00, 0x80, // length 0x01, // iteration counter 0xA6, 0xFE, 0xFE, 0xAE, 0xB2, 0xE1, 0x27, 0x18, // host challenge 0x51, 0x70, 0xF4, 0x5F, 0xCA, 0x00, 0x00, 0x15 }; // card challenge // Card cryptogram uint8_t expected_output[8] = { 0xB0, 0x1E, 0x60, 0x94, 0xFC, 0x7E, 0x25, 0xCF };相關連結：
$$ link - 1 $$ NIST 800-38B 連結：https ://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-38b.pdf $$ link - 2 $$ SCP03 連結（感興趣的是第 4.1.3 和 4.1.5 節）：https ://globalplatform.org/wp-content/uploads/2014/07/GPC_2.2_D_SCP03_v1.1.1.pdf
TLDR -> SCP03 中的 CMAC 是否在 CBC 模式下使用 AES？
TLDR -> SCP03 中的 CMAC 是否在 CBC 模式下使用 AES？
不熟悉 SCP03 協議，但混淆源於 AES 在 CMAC 中的使用方式。從技術上講，我們不需要在 CMAC 的上下文中討論“模式”。在這種情況下，AES 用作分組密碼，它採用 16 字節密鑰、一個 16 字節 blob 並返回另一個 16 字節 blob。像 CBC 這樣的模式是指使用分組密碼來加密任意長度的數據。
話雖如此，出於所有意圖和目的，我上面談到的分組密碼用法也可以看作是 ECB 模式下的 AES。實際上，ECB 包括將要“加密”的消息分割成 16 個字節的塊，並將 AES 塊密碼（或其他任何東西）應用於每個塊。因此，單個 16 字節 blob 上的 AES-ECB 與使用 AES 分組密碼相同……
我也不知道用於測試所有這些的軟體是如何建構的，但我猜想解決方案是在您的 CMAC 實現中“使用 AES-ECB”。除此之外，檢查接收方期望的加密模式也是值得的。也許您必須首先使用 AES-CBC 加密數據，然後將 CMAC 應用於加密結果？也許實際上不需要加密？
我已經從 CBC-MAC 實現了 CMAC，並且在 CBC 模式下實現了 AES。CBC-MAC——顧名思義——當然可以使用 CBC 來實現，只要你有一些空間來臨時儲存不需要的密文塊。
如果您的 CMAC 計算符合測試向量（包括由 128 位/16 字節塊的精確倍數組成的向量），則它可能是正確的。之後，它確保計算中包含正確的字節。