【要点抽出】暗号鍵設定ガイダンス

これまでCRYPTRECのドキュメントを読んでみて面白かったので、もう一冊読みました。

https://www.cryptrec.go.jp/report/cryptrec-gl-3003-1.0.1.pdf

何の本?

先日書いた【要点抽出】暗号強度要件(アルゴリズム及び鍵長選択)に関する設定基準の中で、私は
「暗号鍵の管理も重要な論点ですが、本書のスコープではありません。」
と書きました。その鍵管理や運用について書かれたのが本書です。
図1に本書の位置づけがまとまっています。白抜き部分は扱っていないとのことです。

図 1 暗号技術の導入・運用にあたって考慮すべき代表的な項目

今回はガイドラインではなくガイダンスなんですね。一応この2つの言葉は別モノとして定義されていますが、実質的な違いは分からないです。
(CRYPTRECでもガイドラインのページの中に本書が掲載されています)


構成

7章(本書では節扱い)構成です。

  • 1章 前書き

  • 2章 暗号技術の基礎知識

  • 3章 鍵長の選び方

  • 4章 鍵のライフサイクル

  • 5章 鍵の利用期間

  • 6章 鍵の保護についてのポイント

  • 7章 運用中における鍵長移行に関する検討の必要性

2章の2.2~2.3ビットセキュリティと3章、7章は
「暗号強度要件(アルゴリズム及び鍵長選択)に関する設定基準」
とほぼ同じなので今回は割愛します。


2章:技術的な基礎知識

暗号処理の種類と鍵タイプの種類が列挙されています。
本書では文章ですが、表にまとめてみました。白抜き部分が鍵タイプです。
他のビットセキュリティ等については上述の通り割愛します。

2.1 暗号処理及び鍵タイプの種類 から作成

4章:鍵のライフサイクル

鍵には6つの状態があり、鍵の利用期間や危殆化などの状況によって各状態間を遷移します。

  1. 活性化前状態
    鍵は作ったけどまだ使ってないです
    状態。
    証明書のNotBeforeの日付を迎えると活性化状態に遷移します。

  2. 活性化状態
    鍵を暗号や復号に使います
    状態。
    ・対称鍵を新規データに対して暗号保護する必要がなくなった場合は「非活性化状態」に遷移する必要がある。
    ・非対称鍵のうち暗号化や署名生成に用いる鍵(つまり、鍵共有公開鍵や署名プライベート鍵)が「破棄状態」になった場合は、対応する復号や署名検証用の鍵(つまり、鍵共有プライベート鍵や署名検証公開鍵)は「非活性化状態」に遷移する必要がある。

  3. 一時停止状態
    名前の通り。鍵をしばらく使いません状態。
    この状態を使う理由はおおむね以下の2つです。

    1. 鍵の危殆化の疑いや交換のために状況調査のために時間を確保したい

    2. 鍵をしばらく使う必要がないことが分かっている

  4. 非活性化状態
    新規の暗号化や署名生成はしないが、復号や署名検証には使います
    状態。

  5. 危殆化状態
    この鍵もう危険なんで新規の暗号化や署名生成には使わないでね
    状態。
    復号化や署名検証にも絶対に使ってはならないわけではありません
    例えば危殆化する前に生成された署名の検証などは、十分気を付ければ使ってもOKだそうです。

  6. 破棄状態
    もう何の用途にも使わないでね
    状態。
    対称鍵やプライベート鍵は確実に消去が必要です。
    公開鍵は残ってても必要なら問題はないです。


5章:鍵タイプごとの鍵の利用期間

鍵の利用期間(=活性化状態の期間)は、短いほど安全だが管理ロードがかかります。逆に長いほど管理ロードは下がるが危殆化するリスクやインシデント発生時の影響度が上がります。
ビットセキュリティが高い鍵長を選べば利用期間を延ばせますが、その期間中にしっかり鍵を保護する必要性が増します。

公開鍵暗号、署名の鍵ペアの利用期間

  • 鍵共有を鍵配送で行う場合は「鍵共有プライベート鍵の利用期間(鍵を復号) > 鍵共有公開鍵の利用期間(鍵を配送)」の関係

  • 鍵共有を鍵合意(DH法など)で行う場合は、ペアとなる鍵の利用期間は同じ。

  • 署名の場合は「署名検証公開鍵の利用期間 > 署名プライベート鍵の利用期間(署名を生成)」の関係

  • 認証の場合は、ペアとなる鍵の利用期間は同じ

共通鍵暗号の鍵の利用期間

  • データの保護期間次第。

  • 保管データの場合「復号のための利用期間 > 新規データの暗号化のための利用期間」の関係

NIST SP800-57では推奨利用期間は以下のように定義されているようです。

表 8 鍵タイプごとの SP800-57 に記載されている推奨利用期間

6章:鍵の保護について

鍵の保護に関するWhat(要件)について、表9にまとめられています
鍵の保護が重要なことは誰でも感覚的に分かりますが、鍵タイプによって「保護できている」と言えるために満たすべき要件が異なることを理解する必要があります。

表 9 鍵の保護要件

ここで見慣れない列がいくつかあります。
「関連性保護」とは、その鍵タイプを正しく使うにあたり、あわせて保護されている必要がある他の鍵やデータを指します。「あわせて保護しとかなアカンやつ」のことです。

「保証の必要性」には「有効性」と「保有」のどちらかが入ります。
有効性とは、公開鍵とプライベート鍵の関係が算術的に正しいことです。「この公開鍵は、確かにペアのプライベート鍵の相棒です」の保証です。
保有とは、プライベート鍵を正しい所有者がもっていることです。
「この鍵は盗まれていません」の保証です。

次に鍵の保護に関するHowが挙げられています。
8つしかないのでそのまま引用します。

  1. 鍵の利用期間を制限する

  2. 一つの鍵で保護されるデータの量を制限する

  3. 暗号処理ごとに異なる鍵を使用する

  4. 対称鍵やプライベート鍵が平文形式で存在する時間を制限する

  5. 平文の対称鍵やプライベート鍵を人間が閲覧できないようにする

  6. 平文の対称鍵やプライベート鍵が配置される場所を物理的に保護された“コンテナ”内に制限する

  7. 完全性チェックを使用して、鍵の完全性や他のデータとの関連性が危殆化していないことを確認する

  8. 鍵が不要になったらすぐに当該鍵を破棄する


感想

実は私、本書を別のドキュメントと勘違いして読んでいたようです。

元々、本書は暗号鍵の管理に関する細かいHowが沢山並んでいるのかな?
例えば暗号鍵管理システムの話とか出てくるのかな?
と思っていたのですが、近しいものは最後に引用した8項目くらいでした。
どちらかというとライフサイクルの章のように概念的な話が多かったです。

勿論本書を読んだのが無駄だったわけではなく、鍵タイプの違いや、それに応じた保護要件の違いを学べました。
実際の業務では、例えば保管時の暗号は「AWSならKMSで暗号化すればOK」くらいしか考えていなかったのですが、前提として今回のような考え方を抑えておくべきだと思いました。
改めてKMSのようなマネージドサービスのありがたみを感じます。

そして私が期待していたものは「暗号鍵管理システム設計指針(基本編)」が近いようです。そちらもまた今度、読んでまとめたいと思います。

***はじめての方へ***
これは何のnoteだ?と思われた方はこちらをご覧ください。



この記事が気に入ったらサポートをしてみませんか?