跳至內容

CCM模式

維基百科,自由的百科全書

CCM 模式帶有密文分組連結消息驗證碼的計數器模式帶有CBC-MAC 的CTR模式)是塊密碼的一種工作模式。它是一種認證加密,旨在提供身份驗證機密性。 CCM 模式僅針對分組長度為 128 位的分組密碼定義。 [1]

必須謹慎選擇 CCM 的隨機數,以免對同一個密鑰重複使用。這是因為 CCM 是計數器 (CTR) 模式的派生,而後者實際上是一種流密碼[2]

加密與認證

顧名思義,CCM 模式結合了用於加密的計數器 (CTR) 模式和用於身份驗證的密碼塊鏈消息身份驗證碼 (CBC-MAC) 。這兩個原語以「先驗證後加密」(MAC then Encrypt, MtE)的方式應用:首先對消息計算 CBC-MAC,以獲得消息驗證碼 (MAC) ,然後使用計數器模式對消息和 MAC 進行加密。主流觀點認為,只要加密中使用的計數器值不與身份驗證中使用的(預)初始化向量衝突,就可以將相同的加密密鑰用於兩者。基於底層分組密碼的安全性,該組合存在可證明安全性[3] 。該證明還適用於任何塊大小以及任何大小的強加密偽隨機函數的 CCM 推廣(因為在計數器模式和 CBC-MAC 中,塊密碼僅在一個方向上使用)。

CCM 模式由Russ Housley 、Doug Whiting 和Niels Ferguson設計。在開發 CCM 模式時,Russ Housley 在RSA 實驗室工作。

Zigbee標準中使用了 CCM 的一個微小變體,稱為 CCM*。 CCM* 包括 CCM 的所有功能,還提供僅加密功能。 [4]

性能

CCM 需要對認證加密信息的每個塊進行兩次分組密碼加密操作,並對關聯的經過驗證的數據的每個塊進行一次加密。

根據Crypto++基準測試,AES CCM 在 32 位模式下的Intel Core 2 處理器上的運行效率為每字節28.6周期。 [5]

效率問題:

  • CCM 不是帶有關聯數據的「在線」認證加密 (AEAD) ,因為必須提前知道消息(和關聯數據)的長度。
  • 在MAC構造中,關聯數據的長度使用可變長度編碼,而這可能比機器字更短。如果關聯數據很長(這種情況並不常見), MAC 可能出現性能下降。
  • 關聯數據是在消息數據之後處理的,因此無法預先計算靜態關聯數據的狀態。

專利

偏移碼本 (OCB) 模式的提交推動了 CCM 模式的發展與納入IEEE 802.11i標準。由於該 OCB 正在申請專利,因此有人反對加入 OCB 模式。對於標準的實施者而言,包含專利算法意味着許可複雜性的增加。

雖然基於這些知識產權問題對 OCB 模式的納入存在爭議,但人們一致認為,簡化認證加密系統是可取的。因此Housley等人開發了 CCM 模式,作為不受專利阻礙的潛在替代方案。

儘管 CCM 模式的效率略低於 OCB 模式,但相比之下,無專利解決方案比因專利許可問題而複雜化的解決方案更可取。因此,CCM 模式繼續成為 IEEE 802.11i 標準的強制組件,而 OCB 模式則降級為可選組件狀態,最終被完全刪除。

使用

CCM 模式應用於IEEE 802.11i (如CCMPWPA2的 CCM 加密協議)、 IPsec[6]TLS 1.2, [7]以及藍牙低功耗(從藍牙 4.0開始)。 [8]它可用於 TLS 1.3,但在OpenSSL中默認不啟用。 [9]

參見

參考

  1. ^ Counter with CBC-MAC (CCM). September 2003. 
  2. ^ Housley, Russ. rfc4309. IETF. December 2005: 3 [2023-12-04]. (原始內容存檔於2021-05-06). AES CCM employs counter mode for encryption. As with any stream cipher, reuse of the same IV value with the same key is catastrophic. 
  3. ^ Jakob Jonsson, On the Security of CTR + CBC-MAC (PDF). [2023-12-04]. (原始內容存檔 (PDF)於2024-05-14). 
  4. ^ IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) (PDF). IEEE Standards: 229. 2011-09-05 [2015-12-18]. (原始內容存檔 (PDF)於2017-09-19). 
  5. ^ Crypto++ 5.6.0 Benchmarks. Crypto++. [6 September 2015]. (原始內容存檔於2008-10-15). 
  6. ^ RFC 4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
  7. ^ RFC 6655 AES-CCM Cipher Suites for Transport Layer Security (TLS)
  8. ^ Bluetooth Low Energy Security. [2017-04-20]. (原始內容存檔於2016-04-02). 
  9. ^ Caswell, Matt. Using TLS1.3 With OpenSSL. OpenSSL blog. 2017-05-04 [2018-12-29]. (原始內容存檔於2017-09-16). 

外部連結