暗号化消去の原理とリスク
データベース・セキュリティ・コンソーシアム 会長
立命館大学 情報理工学部 上原 哲太郎

ビッグデータの時代 vs ポストムーア時代
企業内データは爆発的に増加中
非構造化データが特に顕著

非構造化
データ

ストレージ容量も追随して増加中
構造化
データ

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

データの増加に処理は追いつかない2神奈川県事件が明らかにした
HDD消去の難しさ
HDDサーバをリースバック
HDD約500台

リース会社

神奈川県庁
廃棄のため転売

流
出発
覚

ネット
オークション

従業員が持ち出し転売(18台)
廃棄業者3ストレージの内容を「完全に消す」困難• 壊れるときは簡単なのに「データを完全に消そう」とするとなかなか困難

HDD

File
File

File

File
File

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

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

4

NIST SP800-88Rev.1

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

5高機密な情報が入った媒体が組織を離れる場合は「破壊」一択

破壊6

データセンターやクラウドどうするの？？
どこかに私のデータが物理的位置はよくわからないわかったとしても手を出せない
7

物理破壊と言われても…こうするわけにも…

撃て！

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

データ

9

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

データ

10

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

鍵は256bit＝32bytes!

何TBあろうが… データ
何PBあろうが…

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

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

12

でも不安になりますよね

暗号化されたデータ

鍵は本当に開かないの？
暗号化されたままのデータが残ってるよね
それ「消去」なの？

データ

暗号鍵消去
13

暗号化消去がうまく働く条件• 「ちゃんとした暗号」が使われること• 最近はこれはだいたい大丈夫• 暗号化鍵の管理がきちんとしており鍵の消去が確認できること• 特に「鍵のバックアップ」問題• 使用開始時から暗号化されていること

全部
大切
だが
特に…

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

よく聞かれること• 暗号はいつか解かれる？
• 平文が「鍵なしで」回復できることは考えがたい• 量子コンピュータを使っても平文回復は大変• 「ちゃんとした暗号」の残存リスク（他は問題ないとして）• ストレージ暗号化は「超長期間」データが残存する可能性があるので万年単位だとわからない• ただ1万年後解読される心配をする必要があるのか？

• 実装の誤り・運用の誤り（特に鍵）15暗号利用モード（運用モード）XTS• CBC等の従来普及したブロック暗号利用モードはランダムアクセス向きでない• ストレージ向け暗号利用モードとしてXTSが提案され普及が進む• Windows10のBitLocker
macOSのFileVault2• IEEE P1619-2007で標準化
NISTもSP800-38Eで規定• 日本でもすでにCRYPTREC暗号リスト掲載• 注：AESの利用が前提
安全性確保のためには鍵更新頻度に条件あり→実装が重要16

CRYPTREC暗号リストに載ればJCMVPによる実装の認証が可能に

17

これで解決?!
• 運用中のシステムを暗号化すると暗号化前のデータの断片が残る• その断片はフォレンジック可能？！
• 大事な情報がたまたま載るリスク• だから「運用開始時点で暗号化」は重要• 鍵は「ちゃんと」生成されてる？
• 運用後は鍵の消失はデータロストに繋がるのでどうしても「バックアップ」したくなる…
鍵の複製を把握しきれる？
18

暗号実装の問題で頻発する鍵生成の「エントロピー不足」

2008年 DebianのOpenSSL実装に問題

2017年 Infineon製TPMのファームウェア実装に問題 19

結構深刻な「鍵の使いまわし問題」• 2012年 SSL/TLSやSSHで使われる公開鍵がネット上で重複している例が多々あることをLenstraらとHeningerらが独立に報告• http://eprint.iacr.org/2012/064• https://www.usenix.org/conference/usenixsecurity
12/mining-your-ps-and-qs-detection-widespreadweak-keys-embedded-devices• Heningerらはネット上の公開鍵の6割が他の公開鍵の使いまわし？！と指摘
参考：https://sect.iij.ad.jp/blog/2012/08/public-key/

20

暗号化消去の場合にもそのリスクは高い…
• 脆弱な乱数生成をしてしまう値の範囲が予測可能• クラウド等でテンプレートをそのまま複製して暗号化ストレージのインスタンスを作ってしまう
全部同じ鍵…

21

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

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

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

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

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

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

様々な提案があったが現在はTrusted Computing
Group(TCG)のOpal SSCが中心的役割
他にMicrosoftのeDrive
ドライブ各社独自規格など
24クラウド上のHardware Security Module (HSM)
CloudHSM
クラウド上のHSM
直接は触れられないが中の鍵の管理権限は利用者が独占

AWSの例

25

最後の最後に残る問題は…？！
鍵消去を指令したが…
本当に消えた?

Cloud
HSM

26

重要になるのは消去の「監査」• どのようにして「消去」したことを示すのか• 特に「鍵の複製」がないことをどのように示すのか• 不存在の証明＝「悪魔の証明」問題• そのためにもHSMなど「ハードウェア内の鍵」は重要• そのためにも鍵管理が重要• 鍵管理システムを作って証跡を残していく• IPAはNIST SP800-130「鍵管理における推奨事項」を翻訳
これを利用するための手引書として「暗号鍵管理システム設計指針」を
CRYPTRECでまとめて公表
27

始めるより終える方が難しい
始めるときに終わりを考えるべき28

始めるより終える方が難しい
始めるときに終わりを考えるべき運用開始時点で暗号化
鍵管理を徹底=HSM
廃棄時鍵をちゃんと消す
それを確認する手段を
29