Counter with CBC-MAC
暗号化と認証
編集
名称が示すように、CCMモードはカウンター (CTR)モードとCBC-MACモードを組み合わせたものであり、前者が暗号化に、後者が認証に用いられる。暗号化に用いられたカウンター値が認証で用いられる初期化ベクトルと衝突することがない限り、同一の鍵を暗号化と認証の双方に用いることができる。この組み合わせについては、ブロック暗号の安全性に基づくNISTによる安全性証明が存在する[2]。この証明は、128ビットAESだけでなく、任意のブロック長のブロック暗号や任意長の擬似ランダム関数[3]を部品とする一般化したCCMモードにも適用可能である。
CCMモードはRuss Housley、Doug Whiting、Niels Fergusonによって設計された。CCMモードの開発時、Russ HousleyはRSA Laboratoriesに勤務していた。
CCM*と呼ばれるCCMモードの派生が存在し、ZigBeeでの暗号化に利用されている。CCM*はCCMモードのすべての機能を有しており、暗号化のみでの利用も可能である。[4]
パフォーマンス
編集
CCMモードは、メッセージを暗号化して認証するためにメッセージ1ブロックにつき2回のブロック暗号の暗号化操作を、関連データ︵暗号化されない部分︶の認証のためにデータ1ブロックにつき1回の暗号化操作を必要とする。
Crypto++のベンチマークによると、Intel Core 2 プロセッサ︵32ビットモード︶を用いた場合、AES-CCM は1バイトあたり 28.6 サイクルを要する。[5]
非効率性に関する特記事項‥
●CCM は﹁on-line﹂の認証付き暗号ではなく、事前にメッセージ︵と関連データ︶の長さが分かっていなければならない。
●認証コード︵MAC︶の生成において、関連データの長さは可変長のエンコーディングがなされ、コンピュータのワード長よりも短い場合がある。このことは、︵あまり無いことだが︶関連データが長い場合にはMAC生成が遅くなる原因となりうる。
●関連データはメッセージデータの後に処理される。そのため，関連データが固定であったとしても、事前に計算しておくといったことはできない。
特許
編集
CCMモードの開発の動機は、OCBモードのIEEE 802.11iへの採用に関する問題である。OCBモードのアルゴリズムの利用に特許の主張が留保されていたことでOCBの採用に反対する意見があった。特許を必要とするアルゴリズムの採用は、標準の実装の際にライセンス問題に発展するためである。
OCBモードの採用は知的財産権の問題につながるものであるため、そのような問題を持たない新たな認証付き暗号の開発が求められた。そこで、Housleyらは特許による問題を受けない代替アルゴリズムとしてCCMモードを開発した。
CCMモードはOCBモードと比較すると効率が悪いアルゴリズムであるが、特許問題の危険性がないことから、CCMモードはIEEE 802.11iに必須要素として採用された。OCBモードは除外されるのではなく、オプションとしての位置付けとなった。
利用
編集CCMモードは、IEEE 802.11i（WPA2の暗号規格であるCCMPとして）、IPSec[6]、TLS 1.2[7]といった標準規格で採用されている。
関連項目
編集脚注
編集- NIST Special Publication 800-38C Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality
(一)^ “rfc4309”. IETF. p. 3. 2013年12月20日閲覧。 “"AES CCM employs counter mode for encryption. As with any stream cipher, reuse of the same IV value with the same key is catastrophic."”
(二)^ “On the Security of CTR + CBC-MAC”. NIST. 2013年12月20日閲覧。
(三)^ CTRモード、CBC-MACのいずれも，ブロック暗号の暗号化関数しか利用しないため、暗号化の逆演算︵復号︶ができる必要はない。
(四)^ “IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)”. IEEE Standards. p. 229 (2011年9月5日). 2015年12月18日閲覧。
(五)^ “Crypto++ 5.6.0 Benchmarks”. Crypto++. 2015年9月6日閲覧。
(六)^ RFC 4309 Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
(七)^ RFC 6655 AES-CCM Cipher Suites for Transport Layer Security (TLS)