事務局選出暗号の安全性評価について
エンティティ認証

公募の目的 (公募要項P.4 第5.1節抜粋)

・策定から5年以上が経過し、解析・攻撃技術の高度化及び暗号技術の開発が進展している・安全性評価のみならず危殆化及び移行対策を含めた適切な暗号選択の支援への要望

・導入コスト、相互運用性、普及度合いなどの評価観点の・導入コスト
相互運用性 普及度合いなどの評価観点の必要性の指摘
・リストの改訂に必要な技術の追加
リストの改訂に必要な技術の追加

エンティティ認証(新設)・電子政府推奨暗号リストに掲載された共通鍵暗号、公開鍵暗号、ハッシュ関
数 メッセージ認証コードの組み合わせによって実現されるエンティティ認証、数、メ セ ジ認証
ドの組み合わせによ実現される
テ テ 認証あるいは、安全性を計算量的な困難さに帰着できるエンティティ認証
・安全性を脅かす状態としては、なりすましの 成功、セッションの取り換え等を想定
・電子政府推奨暗号リストに掲載されている、あるいは 応募中の共通鍵暗号、公開鍵暗号、ハッシュ関数、メッセージ認証コードのみを利 用している場合には、暗号プリミティブを理想的に安全なものとする
・その他の暗号プリミティブを用いる場合には、暗号プリミティブを理 想化せずに安全性の検証を実施
・提案者はプロトコルの安全性を示す情報を提出し、本公 募における安全性評
価では これらの正当性を検証
価では、これらの正当性を検証エンティティ認証応募状況及び評価対象

事務局選出技術
・ISO/IEC 9798‐2（共通鍵暗号を用いたプロトコル）
・ISO/IEC 9798‐3（電子署名を用いたプロトコル）
・ISO/IEC 9798‐4（検査関数（MAC）を用いたプロトコル）

ISO/IEC 9798‐2の概要• 共通鍵暗号を用いたエンティティ認証• 6つのタイプ• 片側認証1パス• 片側認証2パス• 相互認証2パス• 相互認証3パス• 相互認証4パス‐信頼できる第三者機関あり• 相互認証5パス‐信頼できる第三者機関あり• 共通鍵を秘密に所有していることが前提• 疑似乱数はISO/IEC 18031を用いる• Time‐variant Parameterとして、タイムスタンプ、シーケンス番号、乱数などを用いる

ISO/IEC 9798‐2の例相互認証4パス

ISO/IEC 9798‐3の概要• 公開鍵暗号（電子署名）を用いたエンティティ認証• 7つのタイプ• 片側認証1パス• 片側認証2パス• 相互認証2パス• 相互認証3パス• 相互認証2パス‐並列実行（4パス）• 相互認証5パス(initiated by A)• 相互認証5パス(initiated by A)• 鍵に対する証明書を保有することが前提• 疑似乱数はISO/IEC 18031を用いる• Time‐variant Parameterとして、タイムスタンプ、シーケンス番号、乱数などを用いる

ISO/IEC 9798‐3の例
相互認証３パスISO/IEC 9798‐4の概要• 暗号検査関数を用いたエンティティ認証• 4つのタイプ• 片側認証1パス• 片側認証2パス• 相互認証2パス• 相互認証3パス• 鍵を秘密に共有することが前提• 疑似乱数はISO/IEC 18031を用いる• Time‐variant Parameterとして、タイムスタンプ、シーケンス番号 乱数などを用いる
号、乱数などを用いるISO/IEC 9798‐3の例
相互認証３パス安全性評価結果• 評価者Aは、プロトコルの脆弱性について大きな問題は発見しなかったが、数多くのタイプが存在するために、電子政府で利用する際の指針を与えることを求めている。
• 特にTi
特にTime‐varianti t Parameterとして、タイムスタンプ、シーケン
Pt として タイムスタンプ シ ケン
ス番号、乱数を用いるが、その使い分けについて推奨を示すことを求めている。

安全性評価結果• 評価者Bは評価者Bは、フォフォーマルメソッドのツールであるマルメソッドのツ ルである、Scytherを用いScytherを用いて安全性検証を実施。
• Scytherはunboundedyverificationをサポートしているが、本評価ではスレッド数5、1プロトコル当たりの計算機上の評
価時間を10分として評価• 5つのプロトコルの計19バリアントについて、3つの攻撃の存在を指摘。
を指摘• 各攻撃に関しては、修正方法が示されている

安全性評価結果• Role Mix‐up Attack• エンティティの役割に関する確認ができなくなる攻撃• Matchingg conversationやプロトコルにおける動機の問題が発生• 攻撃が存在するプロト攻撃が存在するプロトコルとバリアント
ルとバリアント• 9798‐2‐3 with unidirectional key• 9798‐2‐59798 2 5• 9798‐3‐3• 9798‐4‐3 with unidirectional key

安全性評価結果• Type Flow Attack• エンティティの名前がnビットのビット列にエンコードされていて、プロトコル中のnonceもnビットで表現されるときに発生• エンティティの名前を誤ってfreshな乱数として受け取ってしまう• 攻撃が存在するプロトコルとバリアント• 9798‐3‐7 Option 1

安全性評価結果• Reflection Attack• プロトコルのInitiatorとResponderが同一の場合に起こる
攻撃• オプションフィールドの利用目的が規定されていないため、暗号化されたデータをそのまま再利用することで攻撃が発生• 攻撃が存在するプロトコルとバリアント• 9798‐2‐3• 9798‐2‐5•••••••••••••••••••••••••••••••••••••

T ype cheecks
N o A lice--talks-to-A lice initators

A A greem ent(B,T N B,Text3)
A W eakagreek
B A greement(A ,T N A ,Text1)
A A greem ent(B,T N B,Text3)
A W eakagree
B A greement(A ,T N A ,Text1)
A A greem ent(B,Kent(B K ab,Text5,Text7)
ab Text5 Text7)
A W eakagree
B A greement(A ,K ab,Text5)
A A greem ent(B,T N B,Text3)
A W eakagree
B A greement(A ,TT N A ,Text1)
Text1)A A greem ent(B,R a,R b,Text8)
A A greem ent(B,T N b,Text3)
A W eakagree
B A greement(A ,T N a,Text1)
A A ggreem ent(B,T( , N b,Text3),)
A W eakagree
B A greement(A ,T N a,Text1)

N o type checks
N o A lice--talks-to-A lice initators

Claim

isoiec-9798-2-3
i i 9798 2 3
isoiec-9798-2-3
isoiec-9798-2-3
isoiec-9798-2-3-udkey
isoiec-9798-2-3-udkey
isoiec-9798-2-3-udkey
isoiec-9798-2-5
isoiec-9798-2-5
isoiec-9798-2-5
isoiec-9798-3-3
isoiec-9798-3-3
isoiec-9798-3-3
isoiec9798 3 3
isoiec-9798-3-7-1
isoiec-9798-4-3
isoiec-9798-4-3
isoiec-9798-4-3
isoiec-9798-4-3-udkeyy
isoiec-9798-4-3-udkey
isoiec-9798-4-3-udkey

T ype cheecks
A lice-talkks-to-A lice inittators

Protocol

1
2
3
4
5
6
7
8
91011
12
13
14
15
16
17
18
19

N o type checks
A lice-talkks-to-A lice inittators

No

安全性評価結果•••••••••••••••••••••

まとめ• ISO/IEC 9798で定義されているプロトコルの9798で定義されているプロトコルの一部タイプに脆部タイプに脆弱性を発見。
• これらの脆弱性は、利用されている暗号プリミティブそのものを攻撃しなくても発生し、現実的な攻撃と考えられる。
• CRYPTRECとしては、脆弱性のあるタイプについては使用しないように注釈をつけて 電子政府推奨暗号におけるエンティいように注釈をつけて、電子政府推奨暗号におけるエンティティ認証プロトコルとする。
• 脆弱性の発見されたプロトコルについては、修正方法が存在するため、ISO/IECに対して修正を求め、修正が完了次第注釈に いて再検討を行うこととする
注釈について再検討を行うこととする。