認証の重要性とその技術

中央大学情報セキュリティ人材育成公開講座
認証の重要性とその技術
土井洋
(中央大学研究開発機構/情報セキュリティ大学院大学)
1. 認証の概要
2. メッセージ認証
3. 相手認証
① サーバ(TTP)を利用
② 事前共有情報を利用
③ 公開鍵暗号系を利用
4. その他のトピックス
1. 認証の概要
•
•
•
•
シュメール人の円筒印章[B.C.3300]
中国の印章[B.C.480-221]
合言葉・・・・世界各地で使われた．
パスワード認証････様々なコンピュータ(かなり初期から)使われていた．
タイムシェアリングシステム，マルチユーザシステム
•
OECD情報セキュリティのためのガイドライン
– 1992年：OECD Guidelines for the Security of Information Systems
– 可用性(Availability)，機密性(Confidentiality)，完全性(Integrity)
• セキュリティの概念整理に意味がある．
•
OECD暗号政策に関するガイドライン
– 1997年:Guidelines for Cryptography Policy
• 認証，完全性の記述がある．
佐々木，宝木：印鑑と電子印鑑の歴史と類似性の分析，情報処理学会論文誌,
Vol.42, No.8, pp.1968-1974, 2001.
2006/8/23
2
1
完全性：OECD情報セキュリティガイドライン
• OECD情報セキュリティガイドライン(1992)
– "integrity" means the characteristic of data and information being
accurate and complete and the preservation of accuracy and
completeness.
– 完全性：データ及び情報が正確（accurate）で完全（complete）であり，
かつ正確さ（accuracy），完全さ（completeness）が維持されること
http://www.oecd.org/document/19/0,2340,en_2649_34255_1815059_1_1_1_1,00.html
http://www.ipa.go.jp/security/fy14/reports/oecd/oecd-security.pdf
2006/8/23
3
認証，完全性：OECD暗号政策ガイドライン
• OECD暗号政策に関するガイドライン(1997)
– "Authentication" means a function for establishing the validity of
a claimed identity of a user, device or another entity in an
information or communications system.
– 認証とは，情報通信システムにおいて，ユーザ，装置又はその他の
主体が主張する自己同一性が正当であることを確証する機能をいう．
– "Integrity" means the property that data or information has not
been modified or altered in an unauthorised manner.
– 完全性とは，データ又は情報が権限のない方法により修正又は改竄
されていないという特性をいう．
http://www.oecd.org/document/11/0,2340,en_2649_34255_1814731_1_1_1_1,00.html
http://www.isc.meiji.ac.jp/~sumwel_h/doc/intnl/recm_crypt.htm
2006/8/23
4
2
(本講座で扱う)認証とは･･･
• メッセージ認証
– データの正当性(改ざんされていないこと)の確認
• 相手認証(エンティティ認証)
– 相手の正当性(なりすましされていないこと)の確認
• 例
– メッセージ認証
• MAC
– 相手認証
• パスワード認証，バイオメトリクス認証
– 両方
• 電子署名(メッセージ認証と相手認証を兼ねている)
2006/8/23
5
認証の重要性
• 電子化・ネットワーク化されたシステム
– 相手が誰であるかが保障されないと･･･
– 通信内容の正当性が保障されないと･･･
ビジネスなどは
そもそも
成り立たない?
• 極論(以下のアプリのうち，ありそうなのは?)
– 「守秘」は不必要だが，「相手認証とメッセージ認証」が必
要なアプリ
– 「相手認証やメッセージ認証」は不必要だが，「守秘」が必
要なアプリ
2006/8/23
6
3
様々な”認証”方式
• 相手認証
– 免許証← 類似のものは現実社会で古くから利用されて
いる
– WindowsやUnixシステムを利用する際のログイン
– Web (ID，パスワード)
– バイオメトリクス認証(銀行，パスポート)
• メッセージ認証
– (電子署名を利用する/電子商取引などの)アプリ
• 利用者はほとんど意識する機会がない･･･縁の下の力持ち．
2006/8/23
7
パスワード認証
A: 3141
A :3141
Bさん
A: 3141
B: 2718
C: 1414
A :3141
Aさん
この人Aさんね
①
②
③
パスワード
DB
事前にBさんの持つDBにAさんのパスワードを登録
Aさんという名称とパスワードを送る
パスワードDBに登録されていれば，Aさんと認める．
2006/8/23
8
4
パスワード認証の問題点
A :3141
Bさん
A: 3141
3141
A:
パスワード B:
B: 2718
2718
DB
C: 1414
1414
C:
攻撃者
様々な攻撃
Aさん
• パスワードDBを解析する
– パスワードDBにパスワードそのものを保存しない(ハッシュ値保存)
• ネットワーク上を流れるパスワードを解析する
– 暗号/一方向性関数による処理を行う
• ネットワーク上を流れるパスワードを再利用する
– 毎回異なるデータが流れるようにする
2006/8/23
9
相手認証の分類
• 利用者の知識による認証
– パスワード
ユーザの知識=
• 利用者の所持品による認証
– クレジットカード
– 磁気カード
秘密情報(Long term)
セッション鍵(Short term)
秘密の値(ユーザの知
識に相当)を得た後，認
証プロトコルを行う
• 利用者の身体的特徴による認証
– 指紋，静脈･･･バイオメトリクス認証
2006/8/23
10
5
準備(共通鍵暗号)
• 共通鍵暗号アルゴリズムE,D
– 暗号化アルゴリズムEは公開されている．
• 入力：鍵とメッセージ，出力：暗号文．
– 復号アルゴリズムDも公開されている．
• 入力：鍵と暗号文，出力：復号結果(=メッセージ)．
• C=EK(M)またはC={M}K
– メッセージMの鍵Kによる(共通鍵)暗号文．
• DK(C)
– 暗号文Cの鍵Kによる(共通鍵)復号結果．
• DK(EK(M))=M
AESが現在の標準
2006/8/23
11
準備(公開鍵暗号)
• 公開鍵暗号アルゴリズムE,D
– アルゴリズムEは公開されている
• 入力：公開鍵とメッセージ，出力：暗号文．
– アルゴリズムDも公開されている
• 入力：秘密鍵と暗号文，出力：復号結果(=メッセージ)．
– 鍵が2種類ある：公開鍵(PK)，秘密鍵(SK)
• C=EPK(M)
– メッセージMの公開鍵PKによる暗号文．
• DSK(C)
– 暗号文Cの秘密鍵SKによる復号結果．
• DSK(EPK(M))=M
2006/8/23
RSA，(楕円)ElGamal暗号などを基本と
する方式は多々ある．
12
6
準備(電子署名)
• 署名生成，検証アルゴリズムSig, Ver
– アルゴリズムSigは公開されている
• 入力：秘密鍵とメッセージ，出力：署名．
– アルゴリズムVerも公開されている
• 入力：公開鍵，メッセージ，署名，出力：Yes/No．
– 鍵が2種類ある：公開鍵(PK)，秘密鍵(SK)
• S=SigSK(M)
– メッセージMの秘密鍵SKによる署名．
• VerPK(M,S)
– メッセージM，署名Sの公開鍵PKによる検証結果．
• VerPK(M,SigSK(M))=Yes
RSA，(楕円)ElGamal署名などを基本と
する方式は多々ある．
2006/8/23
13
2.メッセージ認証
MAC： Message Authentication Code / メッセージ認証コード
TAG
TAG
攻撃者
文書の中身を
書き換える
鍵を持たずに･･･
2006/8/23
??
TAG
攻撃者
受理されるメッセー
ジ，TAGを作る
鍵を持たずに･･･
14
7
メッセージ認証の設計目標
• 目的
– メッセージが外部の者により改ざんできない．
• 前提
– 送受信者は秘密の情報を共有している．
• 秘密の情報を利用して認証するために必要なデータ(TAG)をメッセージに
付加する．
• 達成目標
– [攻撃者]相手に受理される未出の(メッセージ，TAG)を作る．
– [設計者]相手に受理される場合は，TAGを正しく作った場合に限る．
• 考慮すべき攻撃
– 攻撃者は，(メッセージ，TAG)を好きなだけ得られる．
2006/8/23
15
MACの実現例(CBC-MAC)
送信者と受信者が，1つの秘密鍵
K1を事前に共有している
IT △ IS △
M1
EK1
FINE △T
ODAY．△
M2
M3
⊕
⊕
EK1
EK1
CBC-MACはメッセージが固定長の場合，安全．
可変長の場合，偽造可能．
2006/8/23
TAG
16
8
CBC-MACに対する攻撃(1/2)
• CBC-MACはメッセージが可変長の場合，偽造可能
であることを示す．
– 具体的には，敵は(M1, TAG)を入手すると， ((M1,M1 ⊕
TAG), TAG)を構成できる(これは受理される)
a⊕b⊕a
利用する性質
= a⊕a⊕b
=0⊕b
=b
2006/8/23
17
CBC-MACに対する攻撃(2/2)
• 入手済みのデータ(M1,TAG)
– 実はTAG=EK1(M1)であることに注意．
• 偽造データは((M1, M1 ⊕ TAG), TAG)
– このことを，CBC-MACの図を用いて確認する．
M1
M1 ⊕ TAG
⊕
EK1
EK1(M1)
2006/8/23
EK1(M1) ⊕ M1 ⊕ TAG
ここの排他的論理和は
EK1(M1) ⊕ M1 ⊕ TAG
=TAG ⊕ M1⊕ TAG
=M1
M1
EK1
最終的な出力は
EK1(M1)=TAG
EK1(M1)
18
9
MACの実現例(EMAC)
送信者と受信者が，2つの秘密鍵
K1とK2を事前に共有している
IT △ IS △
FINE △T
M1
EK1
ODAY．△
M2
M3
⊕
⊕
EK1
EK1
NESSIEでリストアップされたものの1つ
EK2
TAG
2006/8/23
19
MACに関するトピックス
• MACの標準化
– NESSIEでリストアップされたもの
• EMAC: 前頁参照のこと
• そのほか，UMAC，TTMAC，HMAC
– 米国政府の標準(2003年)
• CMAC(OMAC): 岩田先生&黒澤先生により提案され
た方式
http://www.cryptonessie.org/
http://csrc.nist.gov/CryptoToolkit/modes/
http://www.nuee.nagoya-u.ac.jp/labs/tiwata/omac/omac.html
2006/8/23
20
10
3.相手認証
• 目的
– (通信相手)を正しく認証する．
• 前提
– [パターン1]信頼できるサーバが存在し，利用できる．
– [パターン2]送受信者は秘密の情報を事前に共有している．
– [パターン3]公開鍵暗号系を利用する．
• 達成目標
– [攻撃者](認証されてはならないのに)認証される．
– [設計者]認証に対する攻撃や妨害に(少なくとも)気付く．
• 攻撃
– 攻撃者は，認証に伴うすべてのデータを見ること/改変することができ
る．
– 攻撃者は，自ら(通信相手のふりをして)データの送受信をすることが
できる．
2006/8/23
21
相手認証の考え方(と攻撃)
私は
Aだ
Aさん
私は
Aだ
私は
Aだ
Bさん
攻撃者
様々な攻撃
この人はAさ
んよね．
• 攻撃者の目標=Aさんへのなりすまし
– AさんのふりをしてBさんと約束する．
– Aさんのふりをして様々なサービスを受ける．
2006/8/23
22
11
鍵共有と併用する場合
私は
Aだ
Aさん
K
私は
Aだ
私は
Aだ
取引に関する
データ(鍵Kによる
暗号化)
K
Bさん
ではAさんと
取引に入ろう．
• 認証終了時に(一時的な)鍵Kを共有する
– 鍵Kを持っている人は(認証された)相手だけ．
– 以後，共通鍵暗号+MACで秘匿+認証可能．
– 取引の証拠を残す必要があるときは署名が必要．
2006/8/23
23
何が脅威か(攻撃例)
• 認証(+鍵共有)の脅威について
– シンプルな(実はセキュアでない)構成を示し，
– 上記構成に対する攻撃例を示す．
認証+鍵共有の構成(なぜこのような構成が必要か?)
を示すために，使われるスタイル
暗号・セキュリティの講義で使われがちな
スタイルの例
Boyd, Mathuria “Protocols for Authentication and Key Establishment, Springer
Smith(稲村監訳) “認証技術：パスワードから公開鍵まで”，オーム社
2006/8/23
24
12
3.① サーバを利用するモデル
• 各エンティティ(AやB)は信頼できるサーバSとのみ鍵
を共有している．
– 各エンティティ同士(例えばAとB)は鍵を共有していない．
• 信頼できるサーバSは，各エンティティのリクエストに
応じて(セキュアに)動作する．
– いつでも(初期化時のみではなく)利用できる．
• 「サーバを信頼できれば安全」な方式を目指す
– 共有している鍵をきちんと管理している(漏洩しない)．
– サーバはプロトコルどおりに動作する．
2006/8/23
25
認証+鍵共有プロトコル1
KAS：AとSとの共有鍵
S
KBS：BとSとの共有鍵
① A,B
② {K AB }K AS ,
{K AB }K BS
A
B
③ {K AB }K BS , A
• AとBはSが生成した鍵(単なる乱数)KABを共有する．
• 鍵KABはSとA(SとB)しか知らない鍵で暗号化
2006/8/23
26
13
攻撃1(認証+鍵共有プロトコル1)
S
①
A,B
② {K AB }K AS ,
{K AB }K BS
A
③
{K AB }K BS , A
C
③ {K AB }K BS , D
B
• AはBと鍵KABを共有したつもり．
• BはDと鍵KABを共有したつもり．
2006/8/23
27
攻撃2(認証+鍵共有プロトコル1)
S
② A,C
C
③ {K AC }K AS ,{K AC }K CS
① A,B
④ {K AC }K AS ,{K AC }K CS
A
⑤ {K AC }K CS , A
C
• AはBと鍵KACを共有したと思い込む．
• 実は，AはCと鍵KACを共有している．
2006/8/23
28
14
得られた知見(その1)
• エンティティ間への割り込み
– データを攻撃者が改変できる．
– データを(改変しつつ)中継する
– これらは強力な攻撃．
• 攻撃はなりすましだけではない．
– サービス妨害に近い攻撃も考えられる．
– 攻撃1は「なりすまし」は達成していないが，実害
はある．
2006/8/23
29
認証+鍵共有プロトコル2
S
①
A,B
②{K AB , B}K AS ,
{K AB , A}K BS
A
B
③{K AB , A}K BS , A
• AとBは鍵KABを共有する．
• 鍵KABはSとAまたはBしか知らない鍵で暗号化=信頼できる
• 暗号文の中に相手名が含まれている=攻撃は困難?
2006/8/23
30
15
攻撃(認証+鍵共有プロトコル2)
① A,B
C
'
②{K AB , B}K AS ,
A
{K A' B , A}K BS
③
'
{K AB
, A}K BS
B
• AとBは鍵K’ABを共有していた(かなり以前に使った鍵)
– 以前利用した鍵の情報は漏れている(Cに知られている)場合がある．
– 攻撃者Cは以前利用した鍵を攻撃のため再利用する可能性がある．
• Cは以前入手していたK’ABとそのときの通信を利用してAになりすますこ
とや (セッション鍵を利用して)盗聴できる．
2006/8/23
31
得られた知見(その2)
• 一時的に作った鍵を盗まれる場合を想定したほうがよい．
– 鍵の格納場所，取り扱い方により盗難可能性が異なる．
– 格納場所は耐タンパーデバイスか，通常メモリか?
• 以前のセッション鍵のみならず，そのときの通信履歴を攻撃
者は所有しているかもしれない．
• エンティティ(A，B)は，以前使った鍵を永遠に記憶できるわけ
はない．
– もし記憶できればBは「過去に一度でも利用したセッション鍵を割り当
てられそうになったら拒否」すればよい．
2006/8/23
32
16
認証+鍵共有プロトコル3
S
①
A,B,NA
A
② {K AB , B , N A ,{K AB , A}K BS }K AS
③
{K AB , A}K BS
④
{ N B }K AB
⑤
{ N B − 1}K AB
B
Needham-Schroederプロトコル(1978)
• AとBは鍵KABを共有する．
• 鍵KABはSしか知らない鍵で暗号化=信頼できる
• ④，⑤で共有していることを確認する．
2006/8/23
33
Needham-Schroederプロトコル
• 認証+鍵共有プロトコルの出発点
– 過去のセッション鍵を利用する攻撃には弱い．
• この変形は様々なところで使われていた．
– Kerberos(MITのAthenaプロジェクト(1983))
2006/8/23
34
17
3.② 事前共有情報利用モデル
• 各エンティティ(AとB)はKABを事前共有している．
– KABは他のエンティティに漏れることはない．
– この条件の下で(相互)認証(+セッション鍵の共有) を行う．
• 信頼するサーバの存在を仮定しない．
– サーバの適切な運用は負担が大きい．
– ただし， KABを事前共有することも負担は小さくない．
• 相互認証について考察し，攻撃例を考えてみる．
2006/8/23
35
相互認証プロトコル4
①
A
NA
② N B , h1 ( K AB , N A ,...)
③
B
h1 ( K AB , N B ,...)
h1はハッシュ関数
• AはBを認証する．
– Aが作った乱数に(BまたはAしか作れない)値を作れるのはBだけだ．
• BはAを認証する．
– Bが作った乱数に(AまたはBしか作れない)値を作れるのはAだけだ．
2006/8/23
36
18
攻撃(相互認証プロトコル4)
①
A
C
③
NB
④ N A , h1 ( K AB , N B ,...)
NC
② N B , h1 ( K AB , N C ,...)
B
⑤ h1 ( K AB , N B ,...)
• 攻撃者CはBに対してはAのふり，Aに対してはBのふり
• BはAとの相互認証に成功したと思っている．
– 実は，Cが認証相手．
• AはBとの相互認証に失敗したと思っている．
– 認証プロトコルは途中で頓挫．
2006/8/23
37
得られた知見(その3)
• 攻撃者がエンティティ間に位置する攻撃の一例．
– 別用途で利用可能なデータを生成しないように(③を工夫
して)プロトコルを構成する必要がある．
①
A
NA
② N B , h1 ( K AB , N A ,...)
③
B
h2 ( K AB , N B ,...)
例えば，ハッシュ関数h1，h2
を複数用意すれば・・・・
2006/8/23
38
19
3.③ 公開鍵暗号系利用モデル
• 各エンティティ(AやB)はPKIを利用できる．
– 相手の公開鍵を(正しく)得ることができる．
– 信頼できるサーバは必要だが，認証・鍵共有時
には必要ない．
• PKIを使えると何がうれしいか?
– 電子署名を利用できる．
2006/8/23
39
認証プロトコル5
①
NA
A
②
B
Sig B ( N A )
• AはBを認証する．
– Aが作った乱数に(Bの)署名をできるのはBだけだ．
• (Bの)署名はPKIを利用することで，確認できる．
2006/8/23
40
20
攻撃(認証プロトコル5)
①
NA
A
②
C
④ Sig B ( N A )
NA
B
③ Sig B ( N A )
• AはBを認証したつもりになる．
– Aが作った乱数に(Bの)署名をできるのはBだけだ．
• 実は，CはBのふりをしてAに正しく認証されている．
• BはCに認証されたつもりになる．
2006/8/23
41
鍵共有プロトコル6
公開情報=素数p,生成元g
①
a ∈R Z *p
A
K = ( g b )a = X B a
①X A
= g a mod p
②XB
= g mod p
B
②
b ∈R Z *p
b
K = ( g a )b = X Ab
• DH鍵共有(鍵配送)として有名な方式
– 公開鍵暗号，電子署名の概念と共に誕生
– 認証は考えていない．
2006/8/23
42
21
攻撃(鍵共有プロトコル6)
①
a ∈R Z *p
A
①XA
=g
a
b%
② X%B = g
%
K%AC = ( g b ) a = X%B a
① X%A
=g
② XB
= gb
C
K%AC , K%BC
a%
②
b ∈R Z *p
B
K%BC = ( g a% )b = X%Ab
• MITM攻撃として有名な例
– AはBと，BはAと鍵共有していると思っている．
– 実際は，AとC，BとCが鍵共有している．
• 鍵共有後に中継を続ければ，盗聴し放題．
E K%AC ( M )
E K%AC ( M ) E K%BC ( M )
E K%BC ( M )
2006/8/23
43
得られた知見(その4)
• エンティティ間への割り込み
– データを攻撃者が中継(改変)すると，シンプルな認証プロ
トコル，鍵共有プロトコルは不具合が生ずる．
• 攻撃者が能動的に攻撃を行うという状況下での安
全性の考察が必要･･･容易ではない
– 実際，様々なプロトコルが提案されては攻撃されてきた．
– 未知の攻撃によるもの，既知の攻撃によるものなど様々
2006/8/23
44
22
知見を総合すると･･･
• 安全性の定義は容易ではない．
– とはいえ，いくつかのアプローチがある
• Matching Conversation
• 攻撃，達成目標も様々
– MITM (Man in the Middle 攻撃)
– サービス妨害に類する攻撃
– Forward Secrecy
– ソーシャルエンジニアリング
– スニッフィング(キーストロークなど)
2006/8/23
45
4.その他のトピックス
•
•
•
•
ワンタイムパスワード
Forward Secrecy
電子署名=メッセージ認証+相手認証
署名と認証の関係
– 構成方法の類似性
2006/8/23
46
23
ワンタイムパスワード
x2を事前登録
利用者B
利用者A
x1=h(x0),
x2=h(x1)
x1
1回目の認証
x0
2回目の認証
?
x2=h(x1)
x2
?
x1=h(x0)
x1
• 毎回，ネットワーク上を流れるデータが異なる
• データを1回だけ送ればよい．
• データベース上の値(x1,x2)が毎回異なるので，データベース
への攻撃も無意味
ほかにも，クロックベースの方式もある．
2006/8/23
47
Forward Secrecy
• 秘密情報を長期間きちんと管理できるか?
– 答えはおそらく「できない」だろう．
• 認証+鍵共有モデル
– セッション鍵が漏洩することは覚悟していた．
– しかし，ほかの秘密情報(Long Term Key)は漏
洩しないモデルだった．
• 秘密情報が漏れた場合の影響を小さくしたい．
– (既に生成した)セッション鍵の漏洩を避ける．
2006/8/23
48
24
認証+鍵共有(F. Sec.でない例)
S
①
③ { A, B , K S }K BS
A, B
② { A, B , K S }K AS
A
B
取引に関す
るデータ
• サーバSにセッション鍵KSを作ってもらう．
• もし，AとSとの間の共有鍵KASが(ある日)漏洩すると
– (過去の)取引に関するデータが筒抜けとなる．
2006/8/23
49
認証+鍵共有(F. Sec を志向)
S
①
A
K = ( g NB ) N AKS
A, B
④ { A, B , K S }K BS
③
{ A, B , K S }K AS
N
② A, g A
⑤ B, g
NB
B
DHプロトコル
K = ( g N A ) NB KS
• サーバSに鍵KSを作ってもらう．
• DHプロトコルを利用し，セッション鍵生成時にKSを利用する．
• もし，AとSとの間の共有鍵KASが(ある日)漏洩しても…
– NAやNBは漏洩しない(既に存在しない)ので，(過去の)セッション鍵は
漏洩しない．
2006/8/23
50
25
電子署名=メッセージ認証+相手認証
• 電子署名の入出力
– 入力：公開鍵，メッセージ，署名
– 出力：Yes/No
• 相手認証：
– 公開鍵を利用して検証結果(出力)=YESとなる場合，「署
名を生成するのに秘密鍵を利用した」
• メッセージ認証：
– 署名を生成するときに「メッセージ」を入力として使う．
– 実はメッセージを1ビットでも修正すると，署名はまったく
異なる値となる．(他人は1ビットたりとも改変できない)
2006/8/23
51
署名と認証の関係(Schnorr認証)
(p,g,y)に対してy=g-x mod p となるxを知っている
gの位数はq
P(証明者)
(秘密の情報x)
a = gr mod p
(r:乱数)
v= r+cx mod q
2006/8/23
V(検証者)
a
c
0< c ≦q-1をランダム
v
a≡gv×yc (mod p)
52
26
署名と認証の関係(Schnorr署名)
(p,g,y)に対してy=g-x mod p となるxを知っている
gの位数はq
M
P(署名生成者)
(秘密の情報x)
a = gr mod p
(r:乱数)
c=h(M, a,…)
V(検証者)
a
不要
c
v
v= r+cx mod q
c = h(M, gv×yc mod p,…)
認証と署名が表裏一体な方式はたくさんある
2006/8/23
53
標準化について
•
NIST
– SP800-38B･･･CMAC
– FIPS196
•
•
IEEE P1363･･･公開鍵暗号系
NESSIE
– GPS(認証)
• Schnorr認証とよく似ている．
– HMAC，UMAC，EMAC，TTMAC(いずれもメッセージ認証コード)
•
ISO/IEC
– 9797(メッセージ認証コード)
– 9798(エンティティ認証)
• 1pass ～ 5pass の認証(TTPあり/なし)など
– 11770(かぎ管理)
•
標準化動向の報告
– 7月のCSEC+ISEC合同研究会などで報告されている．
• 信学技報ISEC2006-46(2006/7)，ISEC2005-30(2005/7)
2006/8/23
54
27
まとめ
• 認証(+鍵共有)について
– 不具合が生じる例(脅威)を示した．
– 署名と認証の関係を示した．
• 認証とは相手あっての話
– 標準的なものを使うに越したことはない．
• （メッセージ，相手)認証の今後
– フォーマルな安全性を示す方向で研究が進んでいる．
• 「○○攻撃を防ぐことができる」ではない．(いたちごっこではない)
• 例えば，「未出の(メッセージ，TAG)を秘密鍵を持たずに構成できる確率
は1/280未満」という証明が与えられた方式が主流になる．
• システムに組み込む場合
– 標準化されているものについても，前提・仕様等をよく理解したうえで
利用しなくてはならない．
2006/8/23
55
28

Download Report