01:26:23)追加された行はこの色です。削除された行はこの色です。Exchange)プロトコルπのマルチセッション拡張として^πを導入する。この^πは独立なπを重ね合わせたものである。^πの入力は、(establish-session,sid,ssid,PSUB{i};,PSUB{j};,role)である。この入力を受け取ると、^πは同じssidの入力がないかどうかを確かめる。ssidをきちんと管理するということである。すると、フレッシュなπのインスタンスが、(establish-session,ssid,PSUB{i};,PSUB{j};,role)で呼ばれる。このインスタンスが(ssid,PSUB{i};,PSUB{j};,k)を出力するとき、^π(sid,ssid,PSUB{i};,PSUB{j};,k)を出力する。この定理がいえれば、^πで考える必要がなくなり、πで考えればよい。解析が楽になり、こうしたところがUCのありがたいところといえる。従来では^πで考えなければならなかったのである。マルチセッションでUC安全なら、シングルセッションでUC安全である。セッション鍵(と生成に使った乱数)は、普通に使い終わったら消す。keyはAuthenticateしようとするとどうしても必要となるものである。keyはアドバーサリーに渡る。過去にセッション鍵を共有するためのやり取りのメッセージは消せない。したことから、(秘密であるべくの)セッション鍵がわかる可能性がある。secrecy)''という。今の安全性が未来の安全性にもforwardされているわけだ。シングルセッション鍵共有プロトコルのための安全として、SK安全を考える。鍵共有セッションを始めるために、パーティーをactivateする。完了したセッション鍵は見れ、開かれていないセッションをテストセッションできる環境であるZSUB{TEST};を考える。[#r2310c68]PSUB{1};,...,PSUB{n};~A:アドバーサリー~これらのパーティーはプロトコル^πを実行する。ZSUB{TEST};:入力zをAに渡す。1:AがPSUB{i};をactivateしたいことをZSUB{TEST};に要請する。AがPSUB{i};を(establised-session,sid,ssid,PSUB{i};,PSUB{j};role)でactivateしたいとき、ZはPSUB{i};をその入力でactivateする。2:PSUB{i};が(sid,ssid,PSUB{i};,PSUB{j};,κ)を出力したら、Zはその値を記録し、ssidにPSUB{j};でcompletedとマークする。3:Aがssidをセッションのcorruptするとき、ssidをexposedとマークする。AがPSUB{i};を単にcorruptした場合、すべてのPSUB{i};の完了していないセッションはexposedとマークされる。将来PSUB{i};が呼び出すすべてのセッションもexposedとマークされる。4:AがPSUB{i};のcompletedというssidのセッションキーを尋ねるとき、記録されたセッションキーを答え、そのセッションをexposedとマークされる。5:AがPSUB{i};の完了したセッションssidSUB{0};のテストを依頼するとき、次のような処理する。\bigr}");bはテストビット。インテグリティを保ちつつ、シークレシー(このsecrecyが本質)を守る。PSUB{i};が出力したセッションキーをAに渡す。ランダム値をAに渡す。6:b'をbの推測値としてAの出力とするとき、次の計算をして終了する。PSUB{i};が(ssid,PSUB{i};,PSUB{j};,role)のセッションを持ち、PSUB{j};が(ssid,PSUB{i};,PSUB{j};,role')のセッションを持つとき、この2つを''マッチング(matching)''しているという。「role≠role'」であることを必要としない。0を出力Aが攻撃に成功していれば、1に偏る。[#be61223e][定義]~「π:メッセージドリヴンKEプロトコルとする。bit");」[考察1]この定義はPFSを持つ。ZSUB{TEST};のステップ3の完了されているところはマークされていないので、テストの対象PFSの条件から除かれる。corruptされても過去の鍵は守らなくてはならない。[考察2][[F_AUTH]]として使えるのは、^πとして1回だけ。[#y1396259][定理]任意のUC安全なプロトコルはSK安全である。[証明]UM、PFSで考える。π:SK安全でない鍵交換プロトコルと仮定する。UC安全であることは次を示せばよい。&mimetex("REAL_{\pi,A,Z_{TEST}}");とランダムビットを識別する任意のアドバーサリーAが存在する。よって、REALのときZSUB{TEST};から送られてくるκはランダムビットかどうかを識別できるので、統計的にZSUB{TEST};の検証式が成立しやすくなるので、出力が1に偏る。そのとき&mimetex("\widehat{F_{KE}}");とZSUB{TEST};と任意のS(イデアルアドバーサリー)の対話を考える。Sからみると^FSUB{KE};でκが生成されたのか、ZSUB{TEST};でκが生成されたのかわからない。Sで生成したわけでないからである。よってSのVIEWはκの値を統計的に独立にする。IDEAL_{\widehat{F_{KE}},S,Z_{TEST}}");」が示せた。[#n4b99bc1]FSUB{KE};:KEプロトコルのファンクショナリティPSUB{1};,...,PSUB{n};:パーティーS:(IDEALの中の)アドバーサリー。「∀A、∃S(Strong)、∀Z」のようにして、FSUB{KE};を実現するようにするわけだ。1:PSUB{i};から(established-session,sid,PSUB{i};,PSUB{j};,role)を受けると、(sid,PSUB{i};,PSUB{j};,role)を記録し、この組をSに送る。(sid,PSUB{i};,PSUB{j};,role')があれば、次の条件文を考える。このrole'は「role≠role'」であってもなくてもよい。\bigr}^{k}");~PSUB{i};,PSUB{j};に(key,sid,κ)を送り、Sに(key,sid,PSUB{i};,PSUB{j};)を送って、停止する。Then~Sに(choose-value,sid,PSUB{i};,PSUB{j};)を送り、Sからκの値を受けて(key,sid,κ)をPSUB{i};,PSUB{j};に送り、停止する。corruptされているときのAの自由度が高い。Aが鍵の値を決めることができる。して、corruptされたときの被害を最大に見積もっているわけである。2:PSUB{i};かPSUB{j};がcorruptされると、セッションキーがまだFSUB{KE};のアウトゴーイングテープに書かれていなければ、Sにキーを渡す。なければ、何も渡さない。ここで、PFSを要求しているのである。ステップ2の「さもなければ何も渡さない」というところを書き換えると、PFSを持たないUC安全となる。[定理]DH仮定の下で、プロトコル[[SIG-DH]]は、FSUB{SIG-hybrid};モデルでFSUB{KE};を容易に実現している。SIG-DHはDDH仮定の下での署名プロトコルである。FSUB{SIG};が使えるという前提ならSIG-DHプロトコルが次のように簡単に構成できる。[定理]~DDH仮定の下で、SIG-DHプロトコルはFSUB{SIG};ハイブリッドモデルの中でファンクショナリティFSUB{KE};を安全に実現できる。プロトコル実行ごとに鍵生成を行っている。FSUB{SIG};自体を実現するには強力な署名が必要である。プロトコル実行する度に独立なFSUB{SIG};でなく、ずっと使い回せるFSUB{SIG};でないと実用上使い物にならない。[仮定][[DDH仮定]]の下でαとβがばれても(ログで残っても)gSUP{x};のxはわからないから、PFSが保たれる。funcitonの下で構成されると嬉しい。