暗号化消去と鍵管理
立命館大学 情報理工学部 上原 哲太郎

ビッグデータの時代 vs ポストムーア時代
組織で扱うデータ量が爆発的に増加中
非構造化データが非構造化
特に顕著
データストレージ容量も追随して増加中
構造化
データ

CPUは5GHzで停滞
ネットワークは10GbEで停滞
インターフェース転送速度はSATA III（6Gbps）で停滞

データの増加に処理は追いつかない2

ストレージの内容を「完全に消す」困難• システム撤去・廃棄時にデータ漏洩を防ぐために「データを完全に消そう」とするとなかなか困難

HDD

File
File

File

File
File

通常領域内のデータは上書き消去可
代替セクタ内に残ったデータ断片は上書き困難
Enhanced Secure Eraseなどを行う必要
消えたかどうか確認はどうする？！

物理破壊してもメディア上のデータ断片は残存する

3

情報システム撤去・廃棄時の情報漏洩を防ぐ
NIST SP800-88Rev.1

https://www.ipa.go.jp/security/publications/nist/index.html

43段階の抹消処理：消去・除去・破壊
HDDやSSDなどのストレージでは• 消去(Clear):
一般的データ上書き• 除去(Purge):
専用コマンドでの上書き・暗号化消去
消磁処理• 破壊(Destroy):
分解・粉砕・溶融・焼却による復元不可能処理
5

ADECデータ消去技術ハンドブック• 日本語文書としては最も詳しく網羅的に消去技術を解説している• NIST, NSAのガイドラインや日本の公的ガイドラインにも言及
6

HDD消去の現実• 現在HDDの消去は1回上書きだけでも1TBあたり2～4時間必要• ガイドラインは3回程度の複数上書きを求めている• 一方、システム撤去時のストレージ容量は膨大• クラウドなど「上書き消去」がそもそもできないストレージも存在する
7

神奈川県事件が明らかにした
HDD消去の難しさ
HDDサーバをリースバック
HDD約500台

リース会社

神奈川県庁
流出発覚

廃棄のため転売
ネット
オークション

従業員が持ち出し転売(18台)
廃棄業者

8そこで暗号化＝管理対象を変える技術

データ9

そこで暗号化＝管理対象を変える技術
暗号化

データ

10

そこで暗号化＝管理対象を変える技術
暗号化
何TBあろうが… データ何PBあろうが…

鍵は256bit＝32bytes!

暗号鍵

暗号化は大きなデータの管理を小さな暗号鍵の管理の問題に置換する
鍵の消去がデータの消去と等価になる

11

暗号化消去は対象範囲が広い• システム単位 (例：BitLocker)• 暗号鍵をTPMなどマザーボード側に持つことでストレージデバイスとシステムを不可分にした暗号化• ストレージデバイス単位（例：自己暗号化ドライブ）• ストレージ全体をストレージ内の鍵で暗号化• ファイルシステム単位（例：NTFS等の暗号化ドライブ）• ファイル単位
さまざまな粒度で• データベースのテーブル単位etc 高速かつ簡便な「除去」が可能

12

暗号化消去がうまく働く条件• 「ちゃんとした暗号」が使われること• CRYPTREC暗号• 暗号化鍵の管理がきちんとしており鍵の消去が確認できること• 暗号鍵管理ガイドライン• 使用開始時から暗号化されていること

全部大切
だが
特に…

• 途中で暗号化すると問題が複雑に

13

暗号利用モード（運用モード）XTS• 多くの暗号利用モードはランダムアクセス向きでない• ランダムアクセス可能なブロック単位で処理する
暗号利用モードとしてXTSが提案される• Windows10のBitLocker
macOSのFileVault2• AESでの利用はIEEE P1619-2007で標準化
NISTもSP800-38Eで規定• CRYPTREC暗号リストにも掲載

14

XTSの安全性評価と運用上の注意• 2011年 Philip Rogawayによる評価[1]により
XTSに明確な安全性定義がないとされる• 特にデータの終端部、最終2ブロックに端数処理としてCiphertext Stealing (CTS)処理が入るがこの部分の安全性の定義が困難• 2019年峯松一彦による評価[2]により…

• CTSはストレージ暗号化利用である限り致命的問題はない• 鍵を変えずに2^(n/2)ブロック（nはブロックサイズ）以上利用した場合に鍵回復攻撃が可能→64bitブロック暗号では脅威だがAESでは脅威にならない[1] P.Rogaway: Evaluation of Some Blockcipher Modes of Operation[2] 峯松一彦:暗号利用モードXTSの安全性に関する調査及び評価15鍵管理の問題• 脆弱な乱数生成をしてしまう

エントロピー不足• クラウド等でテンプレートをそのまま複製して暗号化ストレージのインスタンスを作ってしまう
全部同じ鍵…

16

鍵のバックアップ問題（合鍵問題）！

システム管理上データ滅失は脅威なので鍵のバックアップは多く取られがち→鍵管理が重要17

鍵がどこに残っている?
18

鍵管理を楽にする方法は物理媒体に鍵を閉じ込め取り出せなくする

耐タンパ性のある
ICカードで鍵管理（公的個人認証）

耐タンパ性のあるUSBキーで鍵管理（FIDO U2F認証）

PC等で内蔵される
Trusted Platform Module(TPM)はBitLocker等で使用
Windows11では必須化（最近はソフトウェア実装も）19自己暗号化ドライブ
Self Encryption Drive (SED)

暗号化機能と耐タンパな鍵ストアが一体化したドライブ

様々な提案があったが現在はTrusted Computing
Group(TCG)のOpal SSCが中心的役割
他にMicrosoftのeDrive
ドライブ各社独自規格など
20

クラウド上のHardware Security Module (HSM)
Cloud
HSM
クラウド上のHSM
直接は触れられないが中の鍵の管理権限は利用者が独占

AWSの例

21

政府機関等のサイバーセキュリティ対策• 政府機関等の対策基準策定のためのガイドライン（令和３年度版）• 基本対策事項3.1.1(7)-1「返却時の情報の抹消方法」について返却時の情報の抹消方法として暗号化消去を採用する場合は、OSやハードウェアの機能により、電磁的記録媒体へ書き込まれる情報が自動的に暗号化されるように設定された端末やサーバ装置等を導入し、運用の全期間を通じて暗号化することが前提となる。

22

残る問題は鍵管理• 基本対策事項3.1.1(7)-1続き：
また、暗号化された情報の復号に用いる鍵については、遵守事項6.1.5(1)(b)(エ)で策定を求めている管理手順に従って適切に管理するとともに、暗号化消去を行う際にはバックアップも含め鍵を確実に消去することが重要である。
• 遵守事項6.1.5(1)(b)(エ)「管理手順を定めること」について暗号化された情報の復号又は電子署名の付与に用いる鍵（以降本条において「鍵」という。 ）の管理手順として、CRYPTRECが発行している「暗号鍵管理システム設計指針（基本編）」を参照しつつ、以下の視点を含む鍵のライフサイクルを考慮した管理手順を策定するとよい。
23

暗号鍵管理のガイドライン

NIST SP800-130は暗号鍵管理システムの設計書に指定すべきことを包括的に記した
フレームワーク
暗号鍵管理システム設計指針（基本編）はこのSP800-130の解説書
24

暗号化消去と暗号鍵管理システム• 「鍵のライフサイクル管理」の一部を使う（非活性化・一時停止は不要）• 「失効リスト」（危殆化した鍵のリスト）なども不要

25

暗号鍵設定ガイダンスと暗号化消去• CRYPTRECGL-3003-1.0「暗号鍵設定ガイダンス」• 鍵長選択• 鍵のライフサイクル• 鍵の利用期間• 鍵の保護について
ポイントをまとめたもの
SP800-57も簡単に解説

26

運用上重要になるのは消去の「監査」• どのようにして「消去」したことを示すのか• 特に「鍵の複製」がないことをどのように示すのか• 不存在の証明＝「悪魔の証明」問題• そのためにもHSMなど「ハードウェア内の鍵」は重要• そのためにも鍵管理が重要• 鍵管理システムを作って証跡を残していく27

残る問題は何か
30年後？
1万年後？

• 暗号鍵がなくなってもデータ自体が長く残る可能性• 量子耐性• 将来の新技術へのリスク

28

終わりに
• 運用上暗号化消去は必然になっている• ストレージの容量問題• クラウドの問題• しかしNIST SP800-88rev.1にいう「破壊」(Destroy)同等とまでは認められていない• 今後運用上どのように位置づけるか？
その安全性をどう担保するか？
29