秘匿性の担保 (CBCモード)
Rijndaelのアルゴリズムが2001年にアメリカ国立標準技術研究所（NIST）に暗号標準(AES, Advanced Encryption Standard)アルゴリズムとして採用され、Webのトラフィックの暗号化(HTTPS)や鍵データの暗号化保存などに広く用いられることとなり、それと共に広く利用されている暗号ブロックモードがCBCモード(Cipher Block Chaining Mode)である。
暗号ブロックモードは、AESやDESなどのブロック暗号と呼ばれるブロック単位でデータを暗号化するアルゴリズムでブロック長を超えるデータを暗号化するメカニズムのことであり、AES以前の標準であるDES(Data Encryption Standard)暗号などでも利用できるものである。暗号ブロックモードはCBC以外にも、単純な仕組みであるECBモードや、並列処理と相性が良いCTR（カウンタ）モードなどが存在する。ECBモードは、データが暗号化されても平文のデータパターンが暗号データに残留することがあり、秘匿性を目的としたシーンでは採用されることはなく、また、CTRモードはそのブロックモードの仕組みの一部に系統だった入力が行われることで安全性に懸念があるとの指摘がされたため、その結果CBCモードが広く用いられてきた。
Webサーバーのサーバー鍵やOpenSSHのクライアント鍵を暗号化した際に、そのファイルを見たことがある方はご存じかもしれない。
-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,09F6C5E67D28F678 ...(中略) -----END RSA PRIVATE KEY-----PuTTY-User-Key-File-2: ssh-rsa Encryption: aes256-cbc Comment: rsa-key-20201009 Public-Lines: 4 ...(中略) Private-MAC: 2fdc95c18edc8af4e82b293f0f5517ac107ccd29
ハードウェアアクセラレーションの登場とその限界
2008年にインテル社及びAMD社によってx86命令セットの拡張としてAES-NI (Advanced Encryption Standard New Instructions)が発案され、2011年インテル社製のSandy Bridge (インテル第二世代プロセッサあたりから搭載）などで実用化されるまで、AESによる暗号処理はCPUの汎用的な命令セットの組み合わせで行われていた。暗号アルゴリズムは、CPUにとって複雑で処理に時間のかかる命令シーケンスを含んでおり、当時暗号通信などのボトルネックとなっていた。2000年代後半、当社で製品化していたデジ急便ではデータを暗号化しながらサーバーに送信する場合、デスクトプパソコンでも200Mbps程度が限界であった。
この状況を改善したのが、AES-NIによるAES暗号処理のハードウェアアクセラレーションである。AES-NIは、AES暗号処理のうち実行に時間がかかる処理を、拡張命令セットとしてCPU内のハードウェアで高速に演算できるようし、現在1Gbpsを超える高速な暗号通信が可能となっている。
一方で、10Gbpsまたはそれを超える広帯域回線（40Gbps）の普及が始まるなか、課題となったのがCBCモードとAES-NIとの相性の悪さである。CPUには命令パイプラインという仕組みが存在しており、互いに依存しない命令は並列に効率よく実行できる仕組みが備わっている。CBCモードで暗号化する場合、ブロックモードの仕様から前のブロックの暗号結果に依存するため、直前のブロックの暗号結果が得られるまで次のブロックの暗号処理をこのパイプラインに投入することができない。そのため、こういった制約が存在しないCTRモードはこのパイプラインを活用して並列に複数の暗号ブロックを処理できる一方で、CBCモードはシーケンシャルに処理することを強いられる。この結果、暗号スループットが数Gbps～10Gbps弱で頭打ちとなる現象が発生する。
パイプラインの利用効率向上 (CTRモード)
CBCモードにおけるAES-NIとの相性の悪さを改善することとなったのが、CTRモードである。このブロックモードは、暗号復号共にブロックの暗号処理においてブロック間の依存関係がなく、CPUの命令パイプラインに効率よくAES-NIの命令セットを投入してくことが可能である。その結果、暗号スループットが20Gbps超と改善する。
また、指摘されていた安全性上の懸念も、ブロックモード固有の問題ではなく基礎となるブロック暗号によるものと結論付けられており、利用が広がることとなった。
メッセージ認証における安全性の向上 (GCMモード)
暗号データの秘匿性やその処理性能は、これまで述べたように暗号ブロックモードやプロセッサのハードウェアアクセラレーションなどで解決が図られてきた。異なる課題として持ち上がったのが、暗号データの保護を行う仕組みであるメッセージ認証符号(MAC, Message Authentication Code)である。
MACは、暗号通信では暗号データの完全性（欠損や不整合がないこと）や認証性（対象の真正性を確認すること）を担保するために使用される。暗号通信では通常、このMACと暗号ブロックモードの組み合わせにより、基礎的な要件である秘匿性、完全性及び認証性を満たすセキュリティ通信を実現する。HTTPSやSSHによる暗号通信が普及しはじめた当初、これを実現するためには暗号ブロックモードとHMAC(Hash-based Message Authentication Code)の様な認証メッセージ符号の実装が組み合わせて使用されてきた。ところが、この方式には、認証性に関わる不適切な実装やその欠如によって、実装者が安全に秘匿性と認証性を組み合わせた実装を行うことが困難であることが指摘されたのである。
その結果、提案されたのがGCMモードの様な認証付き暗号ブロックモードである。このブロックモードでは、MACとして切り離されていた完全性と認証性を満たすための仕様がブロックモードに盛り込まれており、暗号ブロックモードとして一体的に、秘匿性、完全性及び認証性を提供する仕組みとなっている。昨今の暗号通信では、この方式による実装が広く普及しつつある。
実測性能比較
次の条件で３種類の暗号ブロックモード（CBCとCTRはメッセージ認証なし）の性能を実測した。
- ホストマシン Intel Core i7 8700 3.2GHz 32GB RAM / Windows 10
- VMゲストマシン Fedora 36 Workstation
- Crypto++を使用
- バッファ to バッファで暗号処理（バッファ上での暗号処理でない）
- ゲストマシン上で8GBのデータの暗号化処理を行い、時間を計測してスループットを計算
| ブロックモード | スループット |
| AES256 CBC | 7.02 Gbps |
| AES256 CTR | 21.9 Gbps |
| AES256 GCM | 16.4 Gbps |