暗号世代交代の現状と課題 - ipa暗号アルゴリズム(triple des, 1024ビットrsa,...

暗号世代交代の現状と課題

IPAセキュリティセンター暗号グループ

神田雅透

IPA Forum 2010 1

はじめに

IPA Forum 2010 2

【HTTPS (SSL/TLS)】インタネット上の通信の暗号化

サーバの認証

【暗号化USB】持出データの暗号化

【携帯電話】携帯電話の認証データの暗号化

【HDD暗号化】持出しPCの暗号化

【ICカードのチップ】カードの認証

電子マネー等の不正防止カード情報等の不正防止

暗号ってどこで使われているのか？～「使っていることさえ分からない（意識しない）」のも多い～

【無線LAN】無線通信の暗号化

はじめに

IPA Forum 2010 3

8-25-2004

2/18/2005

2005-J-22

「暗号アルゴリズム2010年問題」「暗号世代交代」などという話を聞いたことがあるか？

はじめに

「暗号アルゴリズム2010年問題」とは

• 2005年に米国立標準技術研究所(NIST)が当時主流だった暗号アルゴリズム(Triple DES, 1024ビットRSA, SHA-1)を“2010年末を目途に”次世代のものに移行する計画を発表

「暗号世代交代」の本質は• “暗号システムのリスクマネジメント”として対応すべきもの

IPA Forum 2010 4

• 2010年に暗号技術が破れるわけではない• 対応しても効果が見えるわけではないが、対応しなければ将来にわたって潜在的解読リスク・脆弱性を持ち続ける

• ステークホルダーがたくさんいるので十分な移行計画なしには対応困難なケースもある

「危なくなったから移行」ということよりも「2010年末に移行完了」という期限と切ったことのほうが重要

目次

暗号アルゴリズムそのものの実情

• 暗号アルゴリズムの安全性はどうなっているのか

暗号アルゴリズムの移行指針

• 日本政府での移行指針

• 米国政府をはじめとする移行指針

SSL/TLS通信の実情から浮かび上がる課題

• 利用環境や設定によってどれだけ安全性が変わるのか

まとめに代えて

• 暗号世代交代について考えるべきこと

IPA Forum 2010 5

目次










IPA Forum 2010 6

セキュリティ技術とは

あらゆる脅威から「C. I. A.」を確保する技術

• Confidentiality（機密性）：

権限のない第三者から情報を秘匿

• Integrity（完全性）：

情報が改ざんされていないこと（原本性）を保証

• Availability（可用性）：

権限を有するものはいつでも情報にアクセス可能IPA Forum 2010 7

災害リスク

システム障害リスク

人為的ミスによる障害リスク

人為的不正行為リスク狭義の意味での「セキュリティ」

広義の意味での「セキュリティ」

「暗号技術」機密性と完全性の確保

暗号アルゴリズムの分類

機能目的からの分類

暗号方式からの分類

IPA Forum 2010 8

暗号化無権限者から情報を秘匿盗聴・紛失・盗難などの防止

鍵配送(情報 = 秘密鍵) 受信者に秘密鍵を配送鍵共有(情報 = 秘密鍵) 送信者と受信者が秘密鍵を共有

ユーザ認証権限を有するユーザであることを確認なりすましの防止

メッセージ認証情報の原本性を確認データ改ざん・偽造の防止

(電子)署名署名者が情報の原本性を保証(メッセージ認証+ユーザ認証) 署名改ざん・偽造の防止

共通鍵暗号暗号化と復号とで同じ秘密鍵を利用する方式ブロック暗号データを一定の長さに区切って暗号化 AES, Camellia, Triple DESストリーム暗号擬似乱数生成器を利用して暗号化 RC4

公開鍵暗号暗号化と復号とで異なる鍵を利用する方式公開鍵暗号データの暗号化に利用 RSA

ハイブリッド暗号公開鍵暗号で秘密鍵の配送を行い、共通鍵暗号でデータの暗号化を行う方式

RSA+RC4 (SSL/TLS)

デジタル署名電子署名を実現する一形態。署名者の認証とデータの完全性を検証を同時に行う方式

RSA, DSA, ECDSA

ハッシュ関数任意のデータを一定長のデータに圧縮する方式

MD5, SHA-1, SHA-2, AHS (SHA-3)

暗号アルゴリズム分類

暗号方式は機能目的によって得手不得手がある

IPA Forum 2010 9

◎：様々なシステムで非常によく使われている＞○オープンシステムで使われている：●クローズドシステムで使われている＞△あまり使われていない＞×使えない

機能目的

暗号方式

暗号化ユーザ認証

メッセージ認証

(電子)署名データ暗号化鍵配送・共有

共通鍵暗号

ブロック暗号

AES, Triple DES, Camellia, MISTY1 ◎ ● ● ● ×

ストリーム暗号

RC4 ◎ × × × ×

公開鍵暗号

公開鍵暗号

RSA, DH, ECDH △/× ○ × × ×

ハイブリッド暗号

RSA+RC4 (SSL/TLS) ◎ × × ×

デジタル署名

RSA, DSA, ECDSA × × ○ ○ ◎

ハッシュ関数MD5, SHA-1,

SHA-2, AHS (SHA-3)

×公開鍵暗号の部品として利用 ◎ ◎

デジタル署名のデータ生成

に利用

秘匿性完全性

暗号アルゴリズム等価安全性

IPA Forum 2010 10

秘密鍵の候補

共通鍵暗号

秘密鍵を一つずつ検査

公開鍵暗号

合成数 N

２つの素数 P, Q

安全性が依拠する数学的問題（素因数分解問題等）を解く

ハッシュ関数

ハッシュ関数ハッシュ関数

ハッシュ値が一致（衝突）するような2つのデータを選ぶ

同じ？

安全性が依拠する数学的問題の

解法装置

もっとも単純な攻撃方法：全数探索的攻撃

「暗号アルゴリズムの等価安全性」異なる種類の暗号の安全性を同一尺度で評価する方法

攻撃に必要な計算量が２n ⇒ n ビット安全性

「暗号が破れた」とは？

暗号が弱くなる原因には「計算機能力の向上」と「暗号解読技術の進展」の２つがある

IPA Forum 2010 11

例：大国諜報機関級なら用意可能な計算機で解読可能

例：世界中の計算機を集めれば解読可能

学術的な安全性学術的に安全（＝設計要件満たす）

学術的には安全でない（＝設計要件に反する攻撃法が発見）

区分Ⅰ長期利用（＝20～30年）にも耐え

うると期待

中長期的（＝10～20年後）には

安全性低下が懸念される

計算

量的

な安

全性

高い

近いうちに（＝5～10年以内）解

読される恐れが高い低い

高い低い

区分Ⅱ

区分Ⅲ

区分Ⅳ

区分Ⅴ

区分Ⅵ

暗号解読技術の進展

計算機能力の向上

暗号が弱くなる原因には「計算機能力の向上」と「暗号解読技術の進展」の２つがある

暗号アルゴリズムの安全性見積もり

暗号解読技術の進展計算機能力の向上

IPA Forum 2010 12

脆弱性が見つかれば急激に安全性が低下する恐れあり

計算機能力の向上に伴い徐々にだが確実に安全性低下

現実的な前提条件での解読成功は「実害が生じる恐れがあり得る実害が生じる恐れがあり得る」の意味をもつ

等価安全性共通鍵暗号ハッシュ関数公開鍵暗号

素因数分解離散対数楕円曲線

80ビット 2-key Triple DES (2DES) SHA-1 K=1024 L=1024, N=160 F=160-223

112ビット 3-key Triple DES (3DES) SHA-224 K=2048 L=2048, N=224 F=224-255

128ビット AES-128 SHA-256 K=3072 L=3072, N=256 F=256-383

192ビット AES-192 SHA-384 K=7680 L=7680, N=384 F=384-511

256ビット AES-256 SHA-512 K=15360 L=15360, N=512 F=512

「ムーアの法則は成立し続ける」ことは大前提～解読技術の進展を考慮しておおむね1年で2倍の攻撃能力に～

素因数分解可能性予測曲線と実績

任意の1024ビット素因数分解が2017±2年頃に実際に可能に

なることがほぼ確実であることの補強材料が増えているIPA Forum 2010 13

参考文献： A.K.Lenstra,E.Verhaul "Selecting cryptographic key sizes" Proc. PKC 2000, R.P.Brent "Recent progress and prospects for integer factorization algorithm" ,Proc. COCOON 2000

前提：ムーアの法則が継続＆想定外の攻撃手法が発見されない

必要な鍵長

0

500

1000

1500

2000

2500

3000

3500

1990 1995 2000 2005 2010 2015 2020 2025 2030 2035 2040

素因数分解が可能とされる鍵長

RSAが安全と期待される鍵長

(1982年当時のDESの安全性相当)

一般数体ふるい法により素因数分解されたビット数

特殊数体ふるい法により素因数分解されたビット数

1017

582

911

822

809

753

576512 524 530

768768663

多くのアプリケーションで使われてきた

RSAの鍵長

CRYPTRECによるRSA暗号安全性の見積もり

2010年代中に1024ビットRSAは解読可能と予測

IPA Forum 2010 14

世界速の計算機能力の向上曲線

世界500位の計

算機能力の向上曲線

攻撃者に有利な想定環境

2006年当時の

一般的環境

計算機を1年間動作させた時に得られる計算量

1536ビットRSAを解読するために必要と見積

もられた計算量

2048ビットRSAを解読するために必要と見積

もられた計算量

1024ビットRSAを1年で解読できるようになる

予想時期

1024ビットRSAを解読するために必要と見積もられた計算量

CRYPTRECによるSHA-1安全性の見積もり

SHA-1の衝突がいつ見つかってもおかしくはない

IPA Forum 2010 15

世界速の計算機能力の向上曲線

世界500位の

計算機能力の向上曲線

1年でSHA-1の衝突が見つかるようにな

る予想時期

現在予想されている計算量

初めて解読手法が提案された時の計算量

計算機を1年間動作させた時に得られ

る計算量

設計上期待される安全性

一方向性を破るために必要な計算量

252まで改善したという速報もある（真偽未確認）

例：大国諜報機関級なら用意可能な計算機で解読可能

例：世界中の計算機を集めたら解読可能

80ビット安全性はどのくらい？

IPA Forum 2010 16

学術的な安全性

学術的に安全（＝設計要件満たす）

学術的には安全でない（＝設計要件に反する攻撃法が発見）

区分Ⅰ

長期利用（＝20～30年）にも耐え

うると期待

中長期的（＝10～20年後）には安

全性低下が懸念される

計算

量的

な安

全性

高い

近いうちに（＝5～10年以内）解読さ

れる恐れが高い

低い

高い低い

区分Ⅱ

区分Ⅲ

区分Ⅳ

区分Ⅴ

区分Ⅵ

本質的に防護の手立てがない

利用状況によっては運用でなんとかカバーできるか

も

暗号解読技術の進展

計算機能力の向上

SHA-1

2-key TDESRSA1024

「2010年問題」「世代交代」、一言でいえば

IPA Forum 2010 17

多くのシステムで利用されている様々な暗号の安全性低下が無視できなくなってきた～前提：約1～2年で約2倍の攻撃能力に向上し続ける～

大雑把にいえばこのクラスの暗号技術をどうしていくか

２８０回の計算可能

大規模研究所で用意できる計算機で解読可能

安全？安全ではない？

安全


安全ではない暗号研究者

ユーザ安全ではない安全

世界中の計算機を集められたら解読可能

市販ＰＣクラスでも解読可能

安全？安全ではない？安全では

ない安全ユーザ（5年後）

安全？安全ではない？安全ではない安全ユーザ（20年後）

ロードランナー(1000兆FIPS)＠1億ドルが10億台相当

目次










IPA Forum 2010 18

暗号政策に関する日本の体制

IPA Forum 2010 19

• 安全性評価済み技術

暗号を技術的に評価

公開鍵暗号

署名 RSA, ECDSA等

守秘 RSA

鍵配送 DH, ECDH等

秘密鍵暗号

ブロック暗号

128ビット AES, Camellia等

64ビット Triple DES, MISTY1等

ストリーム暗号 RC4, MUGI等

ハッシュ関数 SHA-1, SHA-2等

内閣内閣府

内閣総理大臣

内閣官房

総務省経済産業省防衛省

内閣官房長官

大臣大臣大臣

国家公安委員会

長官

○○省

内閣官房情報内閣官房情報セキュリティセンターセキュリティセンター

(NISC)(NISC)(2005.4(2005.4～～))

CRYPTRECCRYPTREC(2000(2000～～)) IPA セキュリティ

センターNICT

情報セキュリティ政策情報セキュリティ政策会議会議(ISPC)(ISPC)(2005.5(2005.5～～))

ITIT戦略本部戦略本部

(1) 基本戦略策定(2) 政府機関総合対策促進(3) 事案対処支援(4) 重要インフラ対策(5) 国際戦略

暗号技術検討会

暗号方式委員会

暗号実装委員会

暗号運用委員会

※2009年度からの体制

電子政府推奨暗号リスト

電子政府推奨暗号リストの参照方法

IPA Forum 2010 20

NISC(H17.4.25～)

政府機関の情報

セキュリティ対策のための統一基

準（案）

了承

行政情報システム関係課長連絡

会議（H15.2.28）

各府省の情報システム調達における暗号の利用方針

情報セキュリティ政策会議

(H.17.5.30～)報告決定

各府省庁

可能な限り、「電子政府推奨暗号リスト」に掲載された暗号の利用を推進

政府機関の情報

セキュリティ対策のための統一基準

「電子政府推奨暗号リストに記載されたものが使用可能な場合には、それを使用」、等

参照

電子政府推奨暗号リスト

遵守事項

参照

暗号技術検討会

経済産業省

総務省

決定報告報告CRYPTREC

各委員会

CRYPTREC電子政府推奨暗号リスト（案）

各府省庁は、統一基準の遵守事項をひな型として独自の基準を個々に定めることができる

遵守事項

日本政府の暗号世代交代指針

政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及びRSA1024に係る移行指針

政府認証基盤(GPKI)移行スケジュール

「公的個人認証サービスにおける暗号方式等の移行に関する検討会」報告書

「平成21年度電子署名・認証業務利用促進事業（暗号

アルゴリズムの移行等に関する調査研究）」報告書

IPA Forum 2010 21

移行指針＠情報セキュリティ政策会議(08.4.22)

「政府機関の情報システムにおいて使用されている暗号アルゴリズムSHA-1及びRSA1024に係る移行指針」

IPA Forum 2010 22

システム政府認証基盤（GPKI）及び商業登記認証局

政府認証基盤に依存する情報システムその他の情報システム

構成要件電子証明書の発行・検証に使用する暗号を複数の中から選択可能とする構成

文書ファイルへの電子署名・検証に使用する暗号を複数の中から選択可能とする構成

別の暗号への変更が速やかに対応できる措置を事前に用意

用意するアルゴリズム

■ RSA2048withSHA-1およびRSA2048withSHA-256を含める

■ エンドユーザ向けはRSA1024とRSA2048を含める

SHA-1およびSHA-256、RSA1024およびRSA2048を含める

複数の暗号を導入する際は、SHA-256相当以上、RSA1152相当以上のものを含める

その他の要件

■ 電子証明書の発行では特定時期に切替可能とする

■ 検証では開始・終了時期を設定可能

開始・終了時期を設定可能にする RSA1024withSHA-1以外があるときは原則そちらを利用し、

必要なときのみRSA1024withSHA-1を利用可能とする構造

緊急避難的に、電子証明書の失効・再発行等を行うことで、業務継続性が確保される構造

20082007 2009 20112010 2012 2013 2014対応計画報告セキュア

ジャパン2007

相互運用性検証環境構築

新規・更改システムから順次対応一部先行

対応

全システムの対応完了

公的個人認証サービスにおける移行スケジュール

「公的個人認証サービスにおける暗号方式等の移行に関する検討会」報告書

IPA Forum 2010 23

2014年度早期 RSA2048withSHA-256による電子証明書の発行を開始RSA1024withSHA-1による電子証明書の発行停止

2017年度早期（電子証明書の有効期間が延長された場合は2019年度早期）

RSA1024withSHA-1による電子証明書の有効期限終了後に、SHA-1及びRSA1024による認証業務を停止

2009

政府機関情報システム対応期間

2010 20122011 2013 2014 20162015 2017 2018

電子署名法指針の一部改正

SHA-2 (SHA-256/384/512)を追加

SHA-2及びRSA2048での認証業務開始（予定）

SHA-1及びRSA1024を削除（予定）

公的個人認証サービス新旧移行期間

センタシステム対応

鍵ペア生成器対応（予定）

新住基カード交付開始（予定）

旧住基カードは回収、新住基カードと交換

電子署名法の移行スケジュール

「電子署名法における暗号アルゴリズム移行研究会」報告書

IPA Forum 2010 24

2010

政府機関情報システム対応期間

2011 20132012 2014 2015 20172016 2018 2019

現行暗号での電子証明書検証のみ

新暗号（RSA2048withSHA-2）での電子証明書発行・検証

① 移行パターン１現行暗号（RSA1024withSHA-1）での

電子証明書発行・検証新暗号での電子証明書発行・検証（準

備）

現行暗号での電子証明書検証のみ

新暗号（RSA2048withSHA-2）での電子証明書発行・検証

② 移行パターン２現行暗号（RSA1024withSHA-1）での

電子証明書発行・検証新暗号での電子証明書発行・検証（準

備）

暫定暗号での電子証明書検証のみ

③ 移行パターン３

暫定暗号（RSA2048withSHA-1）

での電子証明書発行・検証

新暗号（RSA2048withSHA-2）での電子証明書発行・検証新暗号での電子証明書発行・検証（準

備）

現行暗号での電子証明書検証のみ現行暗号（RSA1024withSHA-1）での

電子証明書発行・検証

※電子署名法上は大5年間有効の

電子証明書を発行可能

政府系システム移行スケジュールのまとめ

IPA Forum 2010 25

全体（移行指針）

2010 2011 2012 2013 2014機器更新時に新旧暗号に対応対応完了

現行暗号を利用新旧両暗号

を利用X-day 新暗号を利用Y-day

GPKI テスト環境構築

機器更新時に本番環境対応対応完了

現行暗号での電子証明書発行・検証現行暗号での電子証明書検証X-day

新暗号での電子証明書発行・検証

Y-day

2014年度早期 2015年度早期

現行暗号での電子証明書発行・検証

現行暗号での電子証明書検証


電子入札コアシステム

要件対応対応完了

2014年度早期

2018年度末

認定認証局

2014年度中

X(G)-day

Y(G)-day

①2014年度末強制失効②2018年度末期限切れ

公的個人認証サービス

現行暗号での電子証明書発行・検証現行暗号での電子証明書検証X-day


Y-day

2017 (2019)年度早期

2014年度早期

年度

新住基カード交付開始（予定）

米国政府の暗号政策への取り組み

“米国政府標準暗号”とは、政府機関システムに対する調達強制暗号規格（連邦情報処理標準規格FIPS）

• ＮＩＳＴには政府機関に対する情報セキュリティ施策遂行権限を法的に付与

Federal Information Security Management Act of 2002 (FISMA)Executive Order #13011

• ＮＩＳＴ規定に対する拒否権限は調達省庁にはない

• 民間（特に金融、通信など重要インフラ）での利用も推奨

様々なガイドラインをSP（Special Publication）文書と

して整備

ＮＳＡが国家安全保障システムで利用する暗号を規定• 国家安全保障システムはFIPSの適用対象外

IPA Forum 2010 26

米国政府の暗号世代交代指針

NIST Brief Comment• SHA-1攻撃等に対する見解

SP800-57 Recommendation for Key Management• 初の暗号アルゴリズム移行計画（暗号2010年問題）

NSA Suite B Cryptography• 軍民両用（Dual-use）製品向け暗号アルゴリズム

SP800-131 Recommendation for the Transitioning of Cryptographic Algorithms and Key Sizes (Draft)• 改訂予定の暗号アルゴリズム移行計画

IPA Forum 2010 27

SP800-57 Recommendation for Key Management

2010年を境にしたデファクト暗号技術の総入れ替え

• “システム利用期間”を考慮したアルゴリズム選択の重要性

IPA Forum 2010 28

2007 2008 2009 2010 2011 2012 2013 2014 2015

2-key Triple DES (2DES)：政府推奨に格下げ

3-key Triple DES (3DES)：政府推奨に格下げ

署名検証・認証での運用終了

SHA-1 運用終了

1024-bit RSA／DH160-bit ECDH／ECMQV 運用終了

共通鍵暗号ハッシュ関数

署名・認証

鍵配送・鍵共有

1024-bit RSA／DSA160-bit ECDSA

運用終了

AES

2048(以上)-bit RSA／DSA

256(以上)-bit ECDSA

SHA-224／256／384／512 (+ SHA-3?)

2048(以上)-bit RSA／DH

256(以上)-bit ECDH／ECMQV

署名生成での運用終了

利用期間の目安 2010年末まで 2030年末まで 2030年以降

低等価安全性 80ビット安全性 112ビット安全性 128ビット安全性

NSA Suite B Cryptography楕円暗号へのシフト• RSA暗号とRSA署名が外されたのが特徴的

• Certicomから26個の特許を購入し、米国政府向けシステム

用に無償ツールキットを提供

IPA Forum 2010 29

機密（SECRET）レベル128ビット安全性相当以上

高機密（TOP SECRET）レベル192ビット安全性相当以上

暗号化 128ビット鍵AES (AES-128)256ビット鍵AES (AES-128)

256ビット鍵AES (AES-128)

ハッシュ関数 SHA-256 SHA-384鍵交換 ECDH（256ビット素体）

ECMQV（256ビット素体）ECDH（384ビット素体）ECMQV（384ビット素体）

署名 ECDSA（256ビット素体） ECDSA（384ビット素体）

SP800-131 Recommendation for the Transitioning

80ビット安全性暗号に対する解読進展度合いを考慮

• 今後数年間は「リスク許容のもとで（deprecated/restricted）」

継続利用を認めるリスク“判断できない”のであれば継続利用“不可”

• SHA-1の継続利用可能範囲を拡大

耐衝突性が問題となる署名用途だけが移行対象

• 2015年以前に1024ビット素因数分解が成功する可能性は

低い

現用システムへの対応の明確化• 過去の暗号化処理済みデータだけが“Legacy use”の対象

現用システムであっても今後の暗号化処理に“Legacy use”のものは

使えない

IPA Forum 2010 30


IPA Forum 2010 31

2007 2008 2009 2010 2011 2012 2013 2014 2015

1024-bit RSA／DH160-bit ECDH／ECMQV

運用終了

2048(以上)-bit RSA／DH256(以上)-bit ECDH／ECMQV

Deprecated(80ビット安全性: 1024ビット)

Acceptable(112ビット安全性： 2048ビット)

Acceptable(80ビット安全性: 1024ビット)

Deprecated(80ビット安全性: 160ビット)Acceptable

(80ビット安全性: 160ビット) Acceptable(112/ 128 / 192 / 256ビット安全性： 224, 256, 284, 512(以上)ビット)

RSA/DH

ECDH/ECMQV

SP800-57

SP800-131

2-key Triple DES：政府推奨に格下げ

3-key Triple DES：政府推奨に格下げ

運用終了

AES

Restricted for encryption(max blocks≦220: 100ビット安全性)Acceptable

(80ビット安全性)2-key Triple DES

(2DES)

Acceptable(112ビット安全性)

Acceptable(128 / 192 / 256ビット安全性)

3-key Triple DES(3DES)

AES

Legacy use for decryption(80ビット安全性 or 100ビット安全性)

SP800-57

SP800-131


IPA Forum 2010 32

2007 2008 2009 2010 2011 2012 2013 2014 2015

SHA-1 運用終了

SHA-224／256／384／512 (+ SHA-3?)

Deprecated for signature generation(80ビット安全性)

Legacy use for signature verification(80ビット安全性)

Acceptable(80ビット安全性)

Acceptable for non-signature generation applications(160ビット安全性)

Acceptable for all applications(112/ 128 / 192/ 256ビット安全性)

SHA-1

SHA-2

SP800-57

SP800-131

SP800-57

SP800-131

署名検証・認証での運用終了1024-bit RSA／DSA160-bit ECDSA

2048(以上)-bit RSA／DSA256(以上)-bit ECDSA

署名生成での運用終了

Deprecated for signature generation(80-112ビット安全性：1024 ～ 2048ビット未満)

Legacy use for signature verification(80-112ビット安全性：1024 ～ 2048ビット未満)


Acceptable for signature generation & signature verification(112ビット安全性：2048ビット以上)

Deprecated for signature generation(80-112ビット安全性： 160 ～ 224ビット未満)

Legacy use for signature verification(80-112ビット安全性： 160 ～ 224ビット未満)


Acceptable for signature generation & signature verification(112ビット安全性： 224ビット以上)

RSA/DSA

ECDSA

ECRYPT II小必要ビット数（の予測）

• 1996年で75 bits, 2015年で90 bitsあれば安全と仮定

大国諜報機関級なら用意可能な計算機で解読可能かもしれない

• ムーアの法則が結局正確な近似といえそう過去13年間で +8～9 bitsすれば同程度の安全性を確保

• 量子コンピュータは近未来的には実現しない現在の技術レベルで同じコストならノイマン型計算機のほうが高速

IPA Forum 2010 33

攻撃モデル 1996年 2009年

Hacker ① $0 + PC 45 bits 222 days 53 bits 数か月(100 – 200 days)Hacker ② $300～400 + FPGA 50 bits 213 days 58 bits

Hacker ③ Malware N/A N/A 73 bitsSmall $10,000 + FPGA 55 bits 278 days 64 bitsMedium $300,000

+ FPGA and/or ASIC60 bits 256 days 68 bits

Large $10,000,000 + FPGA and/or ASIC

70 bits 68 days 78 bits

Intelligence $300,000,000 + ASIC 75 bits 73 days 84 bits

利用期間ごとの推奨暗号アルゴリズム

利用期間の目安短期保護中期間保護長期間保護

- 2010 - 2020 - 2030 2030 + 2030 ++ 2030 +++

等価安全性 80 100 112 128 192 256

共通鍵暗号 2DES 2DES（条件付）

3DES AES-128Camellia-128等

AES-192Camellia-192等

AES-256Camellia-256等

ハッシュ関数 SHA-1 SHA-224 SHA-256 SHA-384 SHA-512

RSA鍵長

NIST 1024 2048 3072 7680 15360

DCSSI 1536 2048 4096

ECRYPT 1248 1776 2432 3248 15424

BSI 1728 2048

EMVCo 1024 1984

DSA鍵長

NIST 1024/160 2048/224 3072/256 7680/384 15360/512

DCSSI 1536/160 2048/256 4096/256 15424/512

ECRYPT 1248/160 1776/192 2432/224 3248/256

BSI 2048/224 2048/224

楕円暗号鍵長

NIST 160 224 256 384 512

NSA Suite B 256 384

DCSSI 160 256 256

ECRYPT 160 192 224 256 512

BSI 224 224IPA Forum 2010 34

目次










IPA Forum 2010 35

暗号世代交代の対策実行への難しさ

暗号の脆弱性による具体的なリスクが共有されない

• 暗号学界がいえるのは「総論ベース」のリスクがほとんど

• 脆弱性による「具体的被害」が発覚した事例がほとんどない

暗号を交代させることの効果が目に見えない• “いつか”は必要でも“今しなければ”という理由にはならない

• 対策コストを誰が負担すべきかのコンセンサスが得られない

• どこまで対策コストをかけるべきなのかが分からないIPA Forum 2010 36

「暗号学界がいう安全性」＝“将来”への予防措置「ビジネスサイドがいう安全性」＝“現時点”での実害対処

安全性のグレーゾーン安全性のグレーゾーン

大規模研究所で用意できる計算機で解読可能


世界中の計算機を集められたら解読可能

市販ＰＣクラスでも解読可能

安全安全では

ない

正しい運用設定をしている自信は？

表面上問題が起きていなければ対策を取ることによるデメリットのほうがむしろ強調される

どの暗号をどのように使っているかを本当に把握しているのか疑問にみえるところが散見

• 安全性が高い暗号が使えるのに（無意識に）低いほうを選択

• 製品のデフォルト設定のまま使っている

そもそも何を使っているかさえ気にしていない

• プロトコルはわかっても暗号まではたどりつかないIPA Forum 2010 37

正しいシステム設計・運用設定をきちんと行っているかという点がかなり怪しいケースも多い

「脆弱な暗号が選ばれる可能性があることで何らかの実害が発生するリスク」

「脆弱な暗号が選ばれる可能性があることで何らかの実害が発生するリスク」

「設定変更することで昨日までつながっていたのに今日つながらなくなったとクレームが来るリスク」

「設定変更することで昨日までつながっていたのに今日つながらなくなったとクレームが来るリスク」

≪

全ての暗号技術を使ったサービス例

SSL/TLS通信：インターネットビジネスでは必須ツール

IPA Forum 2010 38

Internet Explorer 8 Firefox 3

FAQ（セキュリティ）での説明

インターネット利用者数： 9091万人（75.3%)うち、商品等購入や金融取引をしたことのある人： 53.6%by 総務省 (2008/12時点)

SSL/TLSは暗号化技術？

ハンドシェイクで使用する暗号アルゴリズムを決定

IPA Forum 2010 39

Client (ブラウザ)

暗号化データ通信

Server (Webサーバ)

{利用可能な暗号アルゴリズム一覧}

{使用する暗号アルゴリズム,

サーバサーバSSLSSL証明書証明書}

サーバSSL証明書の検証

暗号アルゴリズム暗号アルゴリズムの決定の決定

{ハンドシェイク終了通知}

{ハンドシェイク終了通知}

サーバSSL証明書の公開鍵で暗号化

Pre Master Secret 生成

{暗号化された Pre Master Secret}秘密鍵で復号

Pre Master Secret 生成

Master Secret 生成

Session Key生成

Master Secret 生成

Session Key生成

デジタル署名

公開鍵暗号

共通鍵暗号

共通鍵暗号ブロック暗号 RC2(40), DES (40,56), Triple DES, IDEA, AES, Camellia, SEEDストリーム暗号 RC4(40, 128)

公開鍵暗号 RSA, ECDH, DHデジタル署名 RSA, DSS(DSA), ECDSAハッシュ関数 MD5, SHA-1, SHA-256, SHA-384, SHA-512

設定によって実際の暗号化に使われる暗号が異なる

ブラウザが利用する暗号のデフォルト優先順位

IPA Forum 2010 40

IE8 IE7 IE6 FX3 FX2 Safari3.2Vista1 XP3 Vista2 Vista1 XP3 XP3 XP2 XP2 XP2 Vista2 XP3

ECDHE_RSA_WITH_RC4_128_SHA 13 10ECDHE_RSA_WITH_AES_256_CBC_SHA 8 8 8 2 2 8ECDHE_RSA_WITH_AES_128_CBC_SHA 7 7 7 14 11 7ECDHE_ECDSA_WITH_RC4_128_SHA 11 8ECDHE_ECDSA_WITH_AES_256_CBC_SHA 6 6 6 1 1 6ECDHE_ECDSA_WITH_AES_128_CBC_SHA 5 5 5 12 9 5ECDH_RSA_WITH_AES_256_CBC_SHA 7 5ECDH_ECDSA_WITH_AES_256_CBC_SHA 8 6RSA_WITH_RC4_128_SHA 3 2 3 3 2 2 2 25 19 3 2RSA_WITH_RC4_128_MD5 12 1 12 12 1 1 1 24 18 12 1RSA_WITH_CAMELLIA_256_CBC_SHA 9RSA_WITH_AES_256_CBC_SHA 2 2 2 10 7 2RSA_WITH_AES_128_CBC_SHA 1 1 1 26 20 1RSA_WITH_3DES_EDE_CBC_SHA 4 3 4 4 3 3 3 33 27 4 3DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 3DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 15DHE_RSA_WITH_AES_256_CBC_SHA 5 3DHE_DSS_WITH_CAMELLIA_256_CBC_SHA 4DHE_DSS_WITH_CAMELLIA_128_CBC_SHA 16DHE_DSS_WITH_AES_256_CBC_SHA 10 10 10 6 4 10DHE_DSS_WITH_AES_128_CBC_SHA 9 9 9 18 13 9DHE_DSS_WITH_3DES_EDE_CBC_SHA 11 4 11 11 4 7 7 30 24 11 7SSL2_RC4_128_WITH_MD5 4 4 4SSL2_DES_192_EDE3_CBC_WITH_MD5 5 5 5SSL2_RC2_CBC_128_CBC_WITH_MD5 6 6 6

ブラウザの種類、OSのバージョン等によってブラウザが使いたいと宣言する暗号アルゴリズムの優先度が異なる

サーバでの暗号設定～受入可能な主な暗号～

IPA Forum 2010 41

強い暗号アルゴリズムでも弱い暗号アルゴリズムでも接続できる状態に設定になっているサーバが大半

政府・公共系サーバ金融系サーバ2009年6月調査

CRYPTRECで

推奨されている設定

鍵長56ビットの暗号

特許訴訟リスクを有する暗号

鍵長40ビットの暗号

サーバの正当性検証を要求しない

2008

2003

脆弱性があるバージョン

実際の接続アルゴリズム

IPA Forum 2010 42

2009年6月調査：政府・公共系サーバ（AES対応率65%）

2009年6月調査：金融系サーバ（AES対応率74%）

強い暗号アルゴリズムが優先的に選択されるわけではない～強い暗号が利用可能にしてあるのに選択されない場合も多い～

サーバ証明書

IPA Forum 2010 43

MD5を使ったSSL証明書偽造攻撃が成功したときにも多くのサーバがMD5を使ったSSL証明書を使っていた

2004年: MD5衝突探索手法（MD5(X)=MD5(X*)となる(X,X*)を見つける）が発表2006年: MD5衝突探索手法を用いてX.509証明書の偽造例が発見（X.509フォーマットに合わせ

た形のハッシュ値が一致するだけで上位CAの署名をもらったわけではない）2007年：選択プレフィックス衝突探索手法（任意の(P,P*)に対しMD5(P|S)=MD5(P*|S*)となる

(S,S*)を見つける）が発表2008年： PにRoot CAをだますためのダミー情報、P*に公開鍵を含む偽造情報を入れて選択プレ

フィックス衝突探索手法を実行し中間CA EE証明書を偽造。PS3 200台で約1日

政府・公共系サーバ金融系サーバ内側：2008年11月外側：2009年6月

有効期限1年半

以内のもの約58%

有効期限1年半

以内のもの約81%

SSL/TLS調査結果から見えてきた課題

整合的に暗号設定が行われている形跡が見られない• 強い暗号アルゴリズム（AES256-SHA）が使えるはずなのに

弱い暗号アルゴリズム（RC4-SHA）が選択

• 128ビットSSLと説明していながら、弱い暗号アルゴリズムで

つなごうと思えば接続できてしまう設定のまま

• 同じ企業内のサーバであっても設定状況が全く異なる

更改時にSSL証明書の中身を確認しているか？

• 更改できるタイミングが何回もあったはずなのに、MD5のSSL証明書が2009年時点で多数健在（全体の10%以上）

せっかく設定を変えたのに・・・設定失敗• 強い暗号アルゴリズム（AES）を使えるようにしたら同時に弱

い暗号アルゴリズム（SSL2.0やEXP）も利用可能になったIPA Forum 2010 44

目次










IPA Forum 2010 45

この新聞報道を見て何を思いますか？

IPA Forum 2010 46

2010年7月20日読売新聞朝刊35面

「とんでもない、ですか？」「そんなもんだろう、ですか？」「そして、“なぜ”そう思いましたか？」

サポートが切れるのは数年前から盛んに報

道されていた、のに・・・

移行しなかった理由は「予算不足」

2010年3月7日

読売新聞朝刊１面

10年以上前の古い暗号を

使ったシステムが現役、・・・

（そもそも10年前は強い暗号が使えなかったのに）

対策しない理由が「予算がない」

「大したことではない」など

この調査記事を見て何を思いますか？

IPA Forum 2010 47

「予想外、でしたか?」「予想した通り、ですか?」「そして、“なぜ”そう思いましたか？」

「Windows 2000 Serverをお使いの皆様」よりhttp://www.microsoft.com/japan/windowsserver2008/r2/migration_tips3.mspx

トレンドマイクロ「レガシーOS向けセキュリティソリューション」よりhttp://jp.trendmicro.com/jp/solutions/enterprise/legacy/index.html?WT.ac=JPclusty_legacy_doc_dl#05

マイクロソフトの予測よりはるかに多く継続利用

されている

ASCII「 7月13日でWindows 2000サポート終了！その問題とは？」よりhttp://ascii.jp/elem/000/000/534/534239/index-2.html

「予算がない」は移行できない理由の

一番ではない

au携帯電話に関するニュースリリース

IPA Forum 2010 48

別掲の101機種

http://www.au.kddi.com/seihin/up_date/kishubetsu/au_info_20100929.html

「セキュリティ認証の仕様変更によりau携帯電話101機種でソフト更新」

https://www.verisign.co.jp/ssl/about/20100128b.html

「ベリサイン発行のSSL証明書の鍵長が10月から変更」

2048ビットSSL証明書に非対応の2G携帯やフルブラウザ搭

載携帯電話が存在する

2048ビットSSL証明書に非対応の3G携帯電話が

約1%存在する

2048ビットSSL証明書への変更だけが対象（SHA-256への

変更は含まれていない）

auのアップデートは2048ビットSSL証明書非対応の

3G携帯電話への対処

忘れがちだが忘れてはならない大きなリスク

「いつ替えるか」ではなく「いつまで使えるか」の議論

• 関係者が多くなるほどコンセンサス形成が難しくなる

• 「いつまで」が「実害が発生するまで」になりかねない

大規模システム・売り切り製品を使ったシステムになるほど入れ替えのための時間もコストも労力もかかる

• エンドユーザをどう動かすか？／動いてくれるか？Windows XP SP2以前のOS過去に販売された携帯電話

過去に無償配布された無線LAN装置、ポータブルゲーム機IPA Forum 2010 49

広範囲に展開されたシステムや基幹システムでは一度動き出すと簡単には暗号技術の入れ替えができない

暗号アルゴリズムを移行する仕組みを持っていない装置・製品が世の中には大量に出回っている

暗号世代交代はリスクマネジメント問題

“いつ始めるか”よりも“いつまでに終えるか（対応完了時期）を決める”ことのほうがもっと重要• 2010年に暗号技術が破れるわけではない

だからといって2020年でも大丈夫ということではない

• 規模が大きくなるシステムほど短期間に対応を終えることは極めて難しい

3年、5年どころか、システムによっては10年以上かかることも

• 対応が終わるまでは潜在的解読リスク・脆弱性を抱え続ける時間とともにリスクは確実に増大

• ステークホルダ間（特にエンドユーザ）でリスク認識が異なることを考慮する必要あり

関係者説得にも時間がかかるIPA Forum 2010 50

「暗号２０１０年問題」への対応は一律的ではない～「暗号システムのリスクマネジメント」の一環ととらえるべき～

暗号世代交代はリスクマネジメント問題

対応するなら常に正しく対応できるような準備を

• ガイドラインを整備するのも有用

無理に下位互換を維持し続けることはセキュリティ上望ましい姿ではない

• サポートを強制終了してでもセキュリティを向上させる決断が必要な場合もある

リスク判断ができないのであれば政府指針などを参照

• リスク判断は自らの責任で行うしかない同じぜい弱性でもリスクになるかどうかは利用環境等による

• 政府指針は安全性に関する技術的知見を考慮して決定悪の条件を考慮しても可能な限り安全性が担保できるように

• 暗号製品等の認定・認証制度の活用一定程度のリスクは認定・認証制度を使うことで代用可能

IPA Forum 2010 51

セキュリティ技術の認定・認証制度

IPA Forum 2010 52

運用時の情報管理・保護体制が適切であることを認証運用システムの利用環境や組織のセキュリティ要求事項などを考慮して必要な管理項目（管理分野・管理目的・セキュリティ対策）を選択・実施

必要なセキュリティ機能がもれなく正確に実装されていることを認証セキュリティ機能要件（必要な機能の洗い出し）とセキュリティ保証要件（実装の信頼性）に基づき、セキュリティプロ

ダクトの品質保証を実施

期待されたセキュリティ機能を担保するように暗号技術が実装されていることを認証実装される暗号技術が正しく動作するとともに、不正な行為・攻撃を検知・適切な防御を実行することにより、モジュール内部の安全性を担保

セキュリティマネジメント

BS7799, ISO/IEC17799/27000, ISMS

セキュリティプロダクト

Common Criteria, ISO/IEC15408

（TCSEC, ITSEC, CTCPEC ）

暗号モジュール

FIPS140-2, ISO/IEC19790

日本版CMVP(JCMVP)

暗号技術

ISO/IEC9796, 10118, 14888, 18033

米国政府標準暗号,

欧州連合推奨暗号, 電子政府推奨暗号

など

安全な暗号技術の採用を促進暗号研究者らによる十分な安全性検証が行われた暗号技術の標準化・推奨を国際的に行うことにより、安全な暗号技術の採用を促進

CC認証とJCMVPCC認証 (ISO/IEC15408)情報システムや部品に採用されて

いるセキュリティ技術を統一的な基準によって評価・認定

• 設計者が作成するセキュリティターゲットST／プロテクションファイルPPをベースに評価

11クラスのセキュリティ技術要件

10クラスのセキュリティ保証要件

• セキュリティ保証要件の実装の“信頼度”を７段階の評価保証レベルEALで表現

EALは“安全性”とは直接リンク

していないことに注意

• 暗号技術は審査対象外

秘密鍵が漏えいしないかなどの点だけが検査される

JCMVP (ISO/IEC19790)セキュリティ機能が正しく安全に動

作するように暗号モジュールが実装されていることを検査･認証

• Derived Testing Requirementsに従って検査

11カテゴリのセキュリティ要件が

規定

• 検知・防御能力に応じて４段階のセキュリティレベルで表現

セキュリティレベルが高いほど攻撃に対する検知・防御能力に優れる

• あらかじめ認証された暗号技術のみが検査対象

認証されていない暗号技術は実装されていても検査されない

IPA Forum 2010 53CC: Common CriteriaJCMVP: Japan Cryptographic Module Validation Program

ご清聴ありがとうございました

IPA Forum 2010 54

暗号世代交代の現状と課題 - ipa暗号アルゴリズム(triple des, 1024ビットrsa,...

Documents