「暗号技術」と「暗号の利用者の視点」
IPA 技術本部 セキュリティセンター
暗号グループ神田

20130607 JNSA-BoF

1

はじめに
 「システム」や「製品」として「セキュア」であるためには暗号アルゴリズムが安全一番、基盤になるものですから実装物が安全穴が開いてては意味ないよね

制度・仕組みが安全

何が“Trust”？

運用管理＝リテラシがしっかり鍵をほったらかしてはダメだよね

20130607 JNSA-BoF

2

Back to the CRYPTREC 2000
 2000年以前は「標準的な暗号」というのがなかった• 「武器」 扱い＆厳格な輸出管理（輸出規制）⇒ 「標準化対象外（署名のみ標準化対象）」⇒ 日本では「米国政府標準暗号が使えない」
 国内では暗号が「玉石混交」の時代• 「自称安全」な暗号もたくさん• セキュリティを守るためには「暗号は秘匿すべきもの」
 暗号研究者はマニアック・・・？
• 暗号解読手法（差分解読法、線形解読法、TMTO法、ρ法、数対篩法、・・・）に強い暗号がいいといわれても・・・

CRYPTRECが評価して「お墨付き」を与えます「お墨付き」「（旧）電子政府推奨暗号リスト」
20130607 JNSA-BoF

3

暗号アルゴリズムの黒船がやってきた 国際標準暗号の策定• 2001年 FIPS 197 AESが発行• 2005年 ISO/IEC国際標準暗号規格が発行• IETFなどでも実装必須暗号は米国政府標準暗号中心へ
 輸出規制が大幅に緩和• 日本は無制限・無条件に米国政府標準暗号が利用可能
 暗号製品環境の変化• 暗号部分のブラックボックス化（＝自社で暗号を実装しない）
 インターネット普及に伴う暗号の「社会的基盤化」• “囲い込み重視”から“相互接続重視”への転換• 米国政府標準暗号は世界中特許無償で利用可能
暗号ビジネスでは利用する暗号アルゴリズムの集約化が進む
暗号アルゴリズムの集約化
20130607 JNSA-BoF

4

新しいCRYPTREC暗号リストが公表 (1) 2013年3月1日、総務省・経済産業省よりリリース

電子政府推奨暗号リスト
暗号技術検討会及び関連委員会（「CRYPTREC」）により、安全性及び実装性能が確認された暗号技術について、市場における利用実績が十分であるか今後の普及が見込まれると判断され、当該技術の利用を推奨するもののリスト
技術分類

名称技術分類

名称

共通鍵暗号

暗号利用モード

公開鍵暗号

SHA-256
SHA-384
ハッシュ関数署名
SHA-512CBCCFB
守秘秘匿モード
CTR
鍵共有
OFB
CCM
64 ビ ッ ト ブ ロ ッ
認証付き秘匿モード（注3）
3-key Triple DES
GCM（注4）
ク暗号（注2）
CMAC
128ビットブロッ AES
メッセージ認証コード
HMAC
ク暗号
Camellia
ISO/IEC 9798-2
ストリーム暗号 KCipher-2
エンティティ認証
ISO/IEC 9798-3※注釈略20130607 JNSA-BoF
DSA
ECDSA
RSA-PSS（注1）
RSASSA-PKCS1-v1_5（注1）
RSA-OAEP（注1）
DH
ECDH

5

新しいCRYPTREC暗号リストが公表 (2)
推奨候補暗号リスト

運用監視暗号リストCRYPTRECにより安全性及び実装性能が確認され、今後、電子政府推奨暗号リストに掲載される可能性のある暗号技術のリスト

実際に解読されるリスクが高まるなど、推奨すべき状態ではなくなった暗号技術のうち、互換性維持のために継続利用を容認するもののリスト。
互換性維持以外の目的での利用は推奨しない。

技術分類
公開鍵
暗号

署名
守秘該当なし該当なし

鍵共有

PSEC-KEM（注5）64ビットブロック暗号
（注6）

共通鍵
暗号

名称

128ビットブロック暗号

ストリーム暗号

ハッシュ関数暗号利用 秘匿モード
認証付き秘匿モード
モード
メッセージ認証コード
エンティティ認証
20130607 JNSA-BoF

技術分類
署名

CIPHERUNICORN-E
Hierocrypt-L1
MISTY1CIPHERUNICORN-A
CLEFIA
Hierocrypt-3
SC2000
Enocoro-128v2
MUGI
MULTI-S01（注7）
該当なし
該当なし
該当なし

PC-MAC-AES
ISO/IEC 9798-4
※注釈略

公開鍵
暗号

共通鍵
暗号

守秘名称
該当なしRSAES-PKCS1-v1_5（注8）（注9）

鍵共有
64ビットブロック暗号

該当なし

128ビットブロック暗号

該当なし

ストリーム暗号128-bit RC4（注10）
RIPEMD-160
SHA-1（注8）

ハッシュ関数暗号利用 秘匿モード
認証付き秘匿モード
モード
メッセージ認証コード
エンティティ認証

該当なし

該当なし
該当なし

CBC-MAC（注11）
該当なし（注8）「政府機関の情報システムにおいて使用されている暗号アルゴリ
ズムSHA-1及びRSA1024に係る移行指針」を踏まえて利用すること。
（注9）SSL 3.0 / TLS 1.0, 1.1, 1.2で利用実績があることから当面の利用を認める。
（注10）128-bit RC4は、SSL （TLS 1.0以上）に限定して利用すること。
（注11）安全性の観点から、メッセージ長を固定して利用すべきである。

6

体制が変わります
新しいCRYPTREC暗号リストができました
暗号技術検討会
事務局：総務省、経済産業省

暗号技術評価委員会

暗号技術活用委員会

事務局：NICT, IPA事務局：IPA, NICT

「暗号技術の安全性評価を中心とした技術的な検討課題」
を担当「セキュリティ対策の推進、暗号技術の利用促進及び産業化を中心とした暗号利用に関する検討課題」
を担当

20130607 JNSA-BoF

7

でもね・・・最近、つくづく思うこと・・・

暗号技術の安全性議論がどんな影響を与えているのだろう？

20130607 JNSA-BoF

8

「暗号解読」の実体はどうなってるの？
 理論的な解読手法が見つかったケース

ほとんど暗号研究者だけの領域。実害はまずない
 計算機能力の向上に伴う安全性低下のケース

予測はほとんど外れない トライ＆エラーができる解読計算量に低下したケース

暗号に興味を持つ優秀なプログラマーも参加。
攻撃力大幅アップ プロトコル設計に問題があるケース
高度な暗号解読しなくても、もともとのデータがわかることもある
 実アプリケーション／プロトコルが攻撃されるケース
実害が懸念される環境が整う
20130607 JNSA-BoF

9暗号世代交代の対策実行への難しさ「暗号学界がいう安全性」＝“将来”への予防措置「ビジネスサイドがいう安全性」＝“現時点”での実害対処
 ステークホルダ間でリスク認識が異なる• 暗号の脆弱性による「具体的被害」が発覚した事例がほとん
どなく、具体的なリスクが共有されない• セキュリティリテラシの格差が大きい
 暗号世代交代へのモチベーションは一般的に高くない• 対応しても効果が実感できるわけではない• 表面上問題がなければ対策を取るデメリットのほうが強調• どんな暗号を使っているかはほとんど気にしていない
結局のところ、技術の話ではなく、実ビジネスに具体的影響が出るかどうかが移行を進めるかどうかのモチベーションの源20130607 JNSA-BoF

10暗号世代交代のモチベーションは？
使っている暗号よりも安全性や処理性能がより良い暗号ができた
たぶん違う。もし影響するなら、もっと頻繁に移行が起きているはず現在使っている暗号が解読された（破れた）可能性はゼロではないが・・・。多くの場合、特定の条件下での話なので、影響があったとしても特定の関係者だけ現在使っている暗号を利用した製品を買ってもらえなくなった使っている暗号が安全かどうかに関係なく影響甚大
対処しないと悪影響が生じることは明らか使っている暗号アルゴリズムの安全性が低下した「2010年末に移行完了」という移行期限を切った移行に必要な標準化・規格化が進展した移行に必要な製品開発の機運が高まった
業界団体等で移行計画策定の機運が高まった対処する／しないによる影響は必ずしも明確ではない
20130607 JNSA-BoF？

11

「暗号解読」の実体はどうなってるの？
こっちのほうがはるかに 暗号実装に問題があるケース問題なのだが・・・

実害が発生する原因としては、直接的な暗号解読よりもリスクがはるかに高い 運用管理上／暗号設定上の問題があるケース
暗号が正しく動くための前提条件の崩壊。利用者が管理しえない領域の問題であることも多い リテラシーに問題があるケース

なりすましの危険性。リテラシーが低い人ほど対策を取らない可能性が高い
 モラルに問題があるケース
権限自体は正規に持っているユーザが不正行為を働く。暗号だけではまず守りきれない20130607 JNSA-BoF

12

なぜ暗号利用マニュアルを作ろうと思ったか？
¾ 個人情報などの情報管理において暗号の利用は極めて有効な手段¾ 適切に情報管理するには暗号に関する利用方法についての知識が必要
9 暗号の専門家ではない人にその種の知識を持ち合わせていることを期待するのは非常に難しいのが現実¾ 可用性を無視した管理規定導入と、ルール違反隣り合わせの運用が恒常化
結果として、暗号を用いた情報管理が適切に行われていないことも多い
暗号の専門家ではない人向けの暗号利用方法の単純な解説を作ろう
主な想定読者層

CISOクラス

IT部門管理職クラス
IT部門アドミニストレータクラス
システム構築者クラス
一般ユーザ

暗号の専門性高い

開発ベンダ

暗号研究者

20130607 JNSA-BoF

Framework

法律ガイドライン

リスク分析

PolicyManagement

セキュリティ要求ポリシーマネジメント

Best Practice

設定・選択・運用に関するベストプラクティス

Part 1 Documents

Part 2 Documents

Product/Protocol
CRYPTRECリストガイド
Algorithms

13なぜ暗号利用マニュアルを作ろうと思ったか？
はじめは「個人情報保護ガイドライン」での参考資料化を目指した
 個人情報の保護に関する法律第20条• 取り扱う個人データの漏えい、滅失又はき損の防止その他の個人データの安全•管理のために必要かつ適切な措置（組織的、人的、物理的及び技術的な安全管理措置）を講じなければならない
本人の個人データが漏えい、滅失又はき損等をした場合に本人が被る権利利益の侵害の大きさを考慮し、事業の性質及び個人データの取扱状況等に起因するリスクに応じ、必要かつ適切な措置を講じる【ガイドラインFAQ】「高度な暗号化」ってなに？

20130607 JNSA-BoF

14

当初の議論のポイント 情報（の質）によるレベル分け（情報価値）が必要か？

 「情報価値」によって「高度の暗号化」のレベルを変えるべきか
情報価値
情報価値
【現在のガイドライン上の差異】
情報価値2 情報価値3
暗号化：暗号化「組織的安全管理措置」及び「技術的安 対策レベル4全管理措置」における例示措置の一つ
対策レベル3
 高度な暗号化：高度な暗号化（解読困難な暗号化を施していて、本人 対策レベル2へ被害が発生する可能性が著しく低い場合については）情報漏えい事故発生時 対策レベル1に「本人への通知」及び「公表」を省略して 対策不十分も差支えないと考えられる対策措置
20130607
JNSA-BoF

4

1

OKOK? NG?
NG15

やってみてわかったこと
脅威レベル１

脅威レベル２【攻撃意思は弱い】

想定条件

想定攻撃者の攻撃意思

あらかじめ標的を狙うことはしない（偶発的に情報を入手）

脅威レベル３

脅威レベル４【攻撃意思は強い】
標的を狙って攻撃を行う（意図的に情報を入手）【攻撃能力は低い】 【攻撃能力は中度】 【攻撃能力は高い】 【攻撃能力は非常に対策技術を解除しようとす 対策技術を解除するため 対策技術を解除するため 高い】
想定攻撃者の攻撃能力る能力／意思はないに、解読ツールを使わない に、解読ツール等も活用す 対策技術を解除するため（偶然見ること以外の行動 程度で出来る攻撃（低コス る攻撃（高コストの攻撃）を に、解読ツール等も活用しを特に起こさない）
トの攻撃）を行う可能性あ 行う可能性ありた組織的攻撃（非常に高コりストの攻撃）を行う可能性あり

紛失
漏えい等態様誤送信
管理ミス
ウィルス感染
ハッキング
強奪・盗難
内部犯行

【重大な脅威ではあるが、想定条件が他と異なるので、今回は検討対象から外す】

一律に「高度の暗号化」を定義づけることは難しそうだ•脅威レベル4を考えない・・・はたして許されるか？
•データの存在位置で色々な場合分けをしてみる・・・が、想定例がありすぎ

20130607 JNSA-BoF

16

思い切って割り切ろう・・・
事実上の脅威は「紛失・盗難だけ」に特化しよう⇒ 「なんでも使える」を目指すと結局「何にも使えない」から「高度な暗号化」の定義づけはあきらめよう⇒ 全部の脅威に対しての対策にはなっていないから「暗号化がどういうことか」の定義づけはやろう⇒ 「暗号化している」ことのベースラインは示そう
暗号化しているから大丈夫だと思います（キリッ）（認証パスワード短いですけど）20130607 JNSA-BoF

暗号化していても秘密鍵が見つけられる以上解読できる可能性がある（だから暗号化していてもダメ）17

割り切った考えでのマニュアルを作りました「暗号についての技術的な話」は極力しない⇒ 暗号の技術的なことを知らなくても日常生活で使っているから「暗号製品を使って情報漏えい対策が正しく安全に機能するための注意点」を重点的に説明⇒ 使い方を間違えると暗号は安全に働かないから「情報価値と対策レベルの考え方」を提示⇒ リスクと利便性のバランスを無視した対策は形骸化するから「代表的な製品の設定方法の手順」を図示⇒ どこにどんな設定項目があるかすら知られていないから「権限を有するものによる不正持ち出し」は考慮しない⇒ 「暗号化」の対策では守れないから
20130607 JNSA-BoF

18

「解説編」と「実践編」の二部構成
解説編 〜知ってほしいこと〜

20130607 JNSA-BoF

実践編 〜どうやればよいか〜

19攻撃者が狙うのは・・・どこ？

20130607 JNSA-BoF

解説編

20

パスワードの安全性の試算例
文字種類数と内訳
種類数 数字 文字

ｼﾝﾎﾞﾙ10種 0–9 なし

なし
なし

36種 0–9 a–z
62種 0–9 A–Z

なし

a–z

94種 0–9 A–Z !”#$%&’(a–z)=~|`¥{@[+*];:}<>?_,./

解説編

パスワード長

4文字
1円未満

8文字
1円未満

12文字
約35円

16文字
約35万円

（計算量：213.3） （計算量：226.6） （計算量：239.9）（計算量：253.2）

1円未満

約100円

約1.65億円

約276兆円（計算量：220.7）（計算量：241.4）（計算量：262.0）（計算量：282.7）

1円未満

約7,500円 約1,120億円 約165京円（計算量：223.8） （計算量：247.6） （計算量：271.5）（計算量：295.3）

1円未満

約21万円

約16.5兆円（計算量：226.2）（計算量：252.4）（計算量：278.7）

約129,000
京円

DES解読装置（計算量：256）
約250万円としたら・・・（計算量：2104.9）

実際にはもっと弱い可能性が高い・・・

COPACOBANA S1 (Spartan-3
XC3S1000, Revision 12/2006)
20130607 JNSA-BoF

21

本マニュアルの使い方

解説編

実践編

「守るべき情報の重要性」と「守るべき情報の重要性」 「持ち運び機器の種類」に応じて「持ち運び機器の種類」「守るべき情報の重要性」と「持ち運び機器の種類」に応じて暗号でどのようにデータを保護するか情報の重要性
極秘個人を特定する 情報がないファイル

低持ち運び機器の種類

情報価値

高必要な対策レベルの判断（何をすべきか）
必要な対策項目での実現方法を検討（どうすべきか）
具体的な設定20130607 JNSA-BoF

解説編
実践編

実践編
22

本マニュアルの使い方

解説編

取り扱う情報の価値からどの程度の対策レベルを実現するかを判断
情報価値レベルの考え方

対策レベルの考え方（期待効果）

レベル4 漏えいさせた場合には、重大な悪影響をもたらし、 暗号解読に必要な計算能力、コストが信用棄損のみならず、経営的にも多大な損害が 非現実的である限り、元の情報が見ら発生する可能性が高い情報れる可能性はほとんどない
レベル3 漏えいさせた場合には、重大な悪影響をもたらす 対策を破るコストが情報価値を大きく上可能性があり、信用棄損の他、場合によっては経 回るようにすることで、元の情報を見て営的にも損害が発生する可能性がある情報もメリットがないと感じさせ、情報を見ようと努力するモチベーションを大きく低下させる
レベル2 漏えいさせた場合でも、重大な悪影響が生じる可 端末・可搬媒体等を偶然入手した人が能性は小さいが、企業倫理上、安易に見られるこ その中の情報を見ようと努力することをとは避けたい情報あきらめさせる
レベル1 上記以外の情報端末・可搬媒体等を偶然入手した人が興味本位でその中の情報を見ようとすることをあきらめさせる
20130607 JNSA-BoF

23

本マニュアルの使い方

解説編

実践編

具体的に実施するベースライン対策を選
択
解説編

実践編

必要な対策項目一覧

対策実現方法の一覧

20130607 JNSA-BoF

24

パネルディスカッションに向けて今回のマニュアルでも「まだまだ難しい」と言われた⇒ 暗号化の正しい利用方法を理解してもらうことはすごく大変「暗号化」の意味・効果が関係者間できちんと定義されていないうちにいろいろな議論が進んでいないか？
⇒ 「安全」の議論がかみ合わない最大の理由では？

「メジャー（基準）がない“形容詞”規定」が多くないか？
⇒ やっている対策が十分なのかどうかの判断ができない

一つのリスクだけに特化した議論をしていないか？
⇒ リスク全体を俯瞰した議論がなされない
20130607 JNSA-BoF

25