【要点抽出】暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準
昨日書いたCRYPTREC暗号リストのセットである本ドキュメントにも触れていきます。
何の本？
本ドキュメントはCRYPTREC暗号リストとセットで読むべきものです。
前回、CRYPTREC暗号リストは「安心して使える暗号技術とそうではなくなってしまった暗号技術のリスト」と書きました。
この中から強度の高い暗号技術を採用さえすれば良いのではなく、最終的な暗号の強度は暗号鍵の長さも大きく関わります。
本書では必要十分な暗号強度を確保するためのアルゴリズムや鍵長の選び方を示しています。
この2冊の両方を満たさないと安全な暗号技術を使っているとは言えないよ、と再三書かれています。
なお、暗号鍵の管理も重要な論点ですが、本書のスコープではありません。
構成は？
1章 前書き
2章 前提となる基礎知識
3章 暗号技術を安全に使うためのセキュリティ強度要件
4章 暗号技術や鍵長を移行する際の論点
という構成です。勉強になる2章・3章を中心に要点をまとめます。
4章は大半が2章・3章を理解できていれば同じ内容の繰り返しですので軽めにします。
以下、図1に本ドキュメントの章立てとCRYPTREC暗号リストの関係が分かりやすく示されています。
2章：技術的な基礎知識
暗号処理の種類
そもそも暗号技術は使う目的により分類されます。
この後、本書ではその目的別に強度要件が書かれています
暗号化（秘密を守る）：更に通信時/保管時/通信の前に暗号鍵を共有する時と細分化されます
署名：完全性や否認防止
メッセージ認証：通信データや保管データの完全性を確認
エンティティ認証：正規のエンティティであることを確認（サーバ証明等）
暗号技術の強度表現（ビットセキュリティ）
CRYPTREC暗号リストには様々な暗号技術が掲載されていますが、素人にはどれがどれだけ安全なのか分かりにくいです。
そこで、各暗号技術の解読しづらさを定量的に表した尺度を示しています。
112ビット/128ビット/192ビット/256ビットの4段階で表され、数字が大きいほど強い暗号を意味します。
ただし、解読の計算の仕方が変わったり量子コンピュータの登場によりこの値は意味をなさなくなる可能性があるため、5年毎に再評価する前提です。
なお、量子コンピュータについては
・21年3月の発達度合いだとまだ解読には至らなそう
・でもいつ今の暗号技術を解読できちゃうかは予測できない
としており、本書の強度表現には量子コンピュータの影響は加味していないとのことです。
以下、表2～4に公開鍵暗号・共通鍵暗号・ハッシュ関数それぞれの強度が表されています。表の中の「 k=」とか書かれているのは鍵長を意味します。
細かいところは専門家に任せて、おおむねこの暗号技術×鍵長を使うと、これくらい強くなるのねという感覚をつかめればいいと思います。
当然ながら強度が高ければよいというものではなく、鍵長が長いほど暗号処理効率に影響しますので、バランスが大事です。
暗号技術の組み合わせ
暗号技術には様々な利用目的があると書いた通り、実際のシステム運用においては複数の暗号技術を組み合わせることになります。例えば通信時の暗号と保存時の暗号などです。
その際、選んだ暗号技術の中で最も弱いものがシステム全体の暗号強度になるからね、と書かれています。
実際には通信時と保存時はそれぞれの強度に応じて守られますが、全体の強度という意味ではWeakest Linkの考え方と同じですね。
3章：セキュリティ強度要件の設定
それぞれの暗号アルゴリズムと鍵長がどれくらいの強度か把握できたら、次に自分がどの程度のセキュリティ強度を目指すのかを決めます。
これは守るべきデータやシステムの寿命によって決まります。
まず、この章の冒頭に赤字で強調されているメッセージがあります。
内容は「暗号技術や鍵長は、構築時には十分な強度のものを選んでいても時間とともに弱くなる場合があるので、長期間運用するシステムにおいては運用中にこれらを切り替えられるよう考慮しておくべし」と言っています。
要件設定方法
3つの方法が挙げられていますが、結局はシステムのライフサイクル全体にわたって強度要件を満たす暗号技術や鍵長を実装しなさいと言っています。
危殆化した暗号技術を一時的にでも使うハメにならないように、早めに移行計画を立てて切り替えなさい、ということです。
セキュリティ強度要件の基本設定方針
必要なセキュリティ強度要件は表5により求められます。
この表では、10年間隔の時間枠ごとに各セキュリティ強度の利用可否が決められています。
守るべきシステムやデータの廃棄予定時期が「利用可」に収まるようなセキュリティ強度がアナタの強度要件ですよ という考え方です。
最初から廃棄時期なんぞ分からんという場合は「再構築する予定の年」みたいなものを決めて、その時期までを「利用可」に収めるように考えます。
この表も2021年末時点に決めたもので、5年毎に再評価するようです。
(a)の「新規生成」とは、平文データに対して新しく暗号化したり署名することを意味します。
(b)の「処理」とは、既に暗号化済のデータに対して復号化したり署名検証すること意味します。
(c)の「移行完遂期間」とは、名前の通り追い出し期間です。原則使うのはNGだけど、暗号処理が短期間で完結するエンティティ認証のようなケースや、互換性維持などのやむを得ない事情であれば使ってもよい期間を意味します。
例えば、128ビットセキュリティの暗号技術は2041年から移行完遂期間に入ります。このため、2041年以降に暗号化や復号化する際には原則192ビット以上の強度の技術を選ぶ必要があります。
黄色で表される「許容」とは、復号化や署名の検証に限り「保護済みのデータに対する正当性を担保又は確認するための何らかの技術的又は運用的な対策やルール等（暗号技術によるものとは限らない）を併用している場合」は使ってもギリOKという意味らしいですが、つまり何をしていればOKなのか理解できませんでした。
（ACL等によるデータへのアクセス制限とか秘密分散とかだろうか？）
この他の注意点として、署名の場合は、各強度の暗号技術が使えなくなる時期までに「新たに署名すること」を終えるのではなく、「署名検証」を終える必要があります。
例えば、有効期間が5年の公開鍵証明書を発行している場合は、2040年に最後の署名をしたとしても、2045年までは署名検証をすることになります。
ということは、2045年時点で「利用可」である192ビット以上を要件とする必要があります。
証明書の有効期限も含めて移行開始時期を逆算しておかないと、急に焦ることになるということですね。
これについては以下がとても分かりやすかったです。
なお、「守るべきシステムやデータの廃棄予定時期が「利用可」に収まるようなセキュリティ強度がアナタの強度要件」と書きましたが、それを下回る強度要件を実装できないわけではありません。
廃止予定が例えば2060年のシステムは192ビットセキュリティしか選べないのではなく、112や128ビットについてもそれぞれが認められる期間内であれば使えます。
暗号処理の種類別のセキュリティ強度要件
2章の最初に暗号処理には様々な目的があると書きました。
ここでは暗号処理の目的別に、表5の強度要件がどう変わるかを見ます。
まず、保管時の暗号化と署名・メッセージ認証については表5と変わりないので割愛します。
一方、通信時の暗号化とエンティティ認証については、暗号化と復号化のタイミングが時間的にあまり離れない特徴があります。
(保管時の暗号化の場合は、一度暗号化したデータがいつ復号化されるか分からず、時間的に離れている）
よって、これらは表5と比較して、復号や署名検証処理における「許容」期間がなくなっています。やめるならスパっとやめなさい。やめられるはず。ということですね。
その他の考慮点として、鍵共有と共有後の暗号処理のセキュリティ強度は、鍵共有≧共有後の暗号処理にしなさいとか、攻撃者が暗号通信のデータを集めておいて、後で可読する攻撃（Store now & decrypt later）まで考慮する場合は、通信に含まれるデータの機密性・完全性を保護したい期間によって強度要件を求めなさいとあります。例えば2040年には無価値になるデータであれば、2040年の列から暗号強度を選んでねということですね。
（この表自体が5年毎に再評価されるものなので、将来にわたり安全性を保証することはできないのですが、そう書かざるを得ないのでしょう）
4章：運用中における暗号技術及び鍵長移行に関する検討の必要性
ここでは、より強い暗号アルゴリズムや鍵長への移行について記載されていますが、冒頭の記載の通り2章・3章から読み取れる内容は割愛します。
過去の移行事例にはRSA-1024→RSA-2048やSHA-1→SHA-256等がありますが、それぞれ移行に5～10年かかることが分かっているため、前広に計画する必要があると述べています。
感想
暗号技術は理解が極めて難しい領域ですが、その強度を定量化してくれている点は細かく理解できていない(私のような)人にとって感覚的に捉えやすいので非常にありがたかったです。
本書で書かれている考え方は「ごもっとも」と思う反面、実現するのは非常に難しいと感じました。個人的に危殆化した暗号技術を脱却するのはセキュリティ強化施策の中でモチベーションが上がらないものの一つですし、TLS1.0や1.1がまだまだ世の中のWebサイトでサポートされていることもその表れだと思います。
とはいえ、あまりにのんびりやっていると万が一情報漏洩など起こした時に世間から格好のバッシングのネタになってしまいますから、競合他社の動向を見ながら計画を立てて進めることが現実的ではないでしょうか。
＊＊＊はじめての方へ＊＊＊
これは何のnoteだ？と思われた方はこちらをご覧ください。
この記事が気に入ったらサポートをしてみませんか？