番号制度：情報連携基盤の2つ実装方式（GW方式とAT方式）の比較について #kokuminID

Hiromitsu Takagi @HiromitsuTakagi

高木浩光＠自宅の日記 - 「技術音痴なIT企業CTOが国のWGで番号制度の技術基盤を歪める」 http://t.co/y9WFqZo

Hideki SAKAMOTO @hs_onsky

26日付エントリの例では、AとBが結託した場合、最後のA→Bへの受番に生Xa、B→Aの属性情報に生Xbを意図的に付ければXa=Xbの突合ができ、2回目からは直接同期も可能になる気がして回避法も思いつかないのですが、読み違えでしょうか。 @HiromitsuTakagi

Hideki SAKAMOTO @hs_onsky

アクセストークン方式での情報保有機関どうしの直接通信はフラットモデルと同じぐらい論外、だと、思う http://www.on-sky.net/~hs/index.cgi?date=20110628

Hideki SAKAMOTO @hs_onsky

(説明追加しました) アクセストークン方式での情報保有機関どうしの直接通信はフラットモデルと同じぐらい論外、だと、思う http://www.on-sky.net/~hs/index.cgi?date=20110628

Hiromitsu Takagi @HiromitsuTakagi

@hs_onsky ご指摘のattackは、GW方式でも防止できません。保有機関Aから保有機関Bへの連携のとき、要求を出す順序で突合できます。ランダム遅延の挿入で防止など考えられますが、完全な防止にはなりません。結局のところ、国家による一元管理とは何か、想定する結託とは何かの問題

Nat Sakimura/崎村夏彦 @_nat

@hs_onsky どうですかね。GW方式でもシーケンスアタックは可能だし、属性に名寄用のコードを入れて送ることも可能ですよね。ペイロードは暗号化されているので、GWでそれをチェックすることはできません。GWでチェックしようと復号すると、もろ「国家管理の危険」が。

Hideki SAKAMOTO @hs_onsky

@HiromitsuTakagi @_nat 基盤,A,Bの3機関しかない場合はそうですが、多数の情報保有機関が存在して十分密に互いに要求を出し合っている場合、GW方式では本来の要求元情報は当然隠されるはずなので、要求順序による突合は事実上不可能ではないでしょうか。（続く

Hideki SAKAMOTO @hs_onsky

@HiromitsuTakagi @_nat 加えて返信でもいただいた遅延の挿入や、別機関も含めた要求順序の変更、ダミー要求発行などの対策をとる余地がGW方式にはありますが、直接通信方式で同等の安全性を確保するには、間にGWの類を挟むしかない気がしています。(続く

Hideki SAKAMOTO @hs_onsky

@HiromitsuTakagi @_nat 名寄せ用のコードの問題については、確かにGW対直接通信という比較の中では語れない話ですね。(続く

Hideki SAKAMOTO @hs_onsky

@HiromitsuTakagi @_nat マイ・ポータルのようなGW方式ではなく、保有機関どうしの直接通信で互いの相手を隠ぺいする機能に特化したNAT的な装置を入れるとかの案はありだと思っています。(以上、連投失礼しました

Nat Sakimura/崎村夏彦 @_nat

@hs_onsky 前提が違います。国家管理を避ける為にデータは要求元の公開鍵で暗号化されますので、要求元は当然分かります。故にシーケンス攻撃は可能です。 @HiromitsuTakagi

Nat Sakimura/崎村夏彦 @_nat

@hs_onsky GW方式ではデータ暗号化に伴い、各ユーザ毎にセッションコードが導入され、ヘッダ部にリンクコードとの対応表を平文で持ち、GWで書換を行うはず。このセッションコードを使えば機関ABの結託による名寄せ可能です。 @HiromitsuTakagi

Hideki SAKAMOTO @hs_onsky

えっ？それは欠陥設計でGWには秘密かつ要求元が分からない共通鍵的なものを生成して使うべきでは？その共通鍵の配布に公開鍵方式を使えば安全に配布もできますよね。 @_nat …データは要求元の公開鍵で暗号化されますので、要求元は当然分かります… @HiromitsuTakagi

Nat Sakimura/崎村夏彦 @_nat

@hs_onsky おんなじですよね、それじゃ。

Hideki SAKAMOTO @hs_onsky

Bで暗号化されたデータに平文でリンクコードXbが付いている、このXbを削除して代わりにXaを付け、Aに渡す、というイメージでいたので、GWが結託しなければ名寄せ不可能と思ってたんですが、違いますでしょうか… @_nat @HiromitsuTakagi

Hideki SAKAMOTO @hs_onsky

@_nat 例えばBが要求を受ける場合、GWからXbについての要求を受け取り、共通鍵で暗号化して返すという処理になるので、Bは要求元がどこであるのか知ることができなくなります。

Hideki SAKAMOTO @hs_onsky

@_nat すみません、前提をはしょりました。共通鍵の発行者はAでもBでもGWでもない、としなければなりません。

Nat Sakimura/崎村夏彦 @_nat

@hs_onsky それを、Aはどの様にして復号するのですか？

Hideki SAKAMOTO @hs_onsky

@_nat 分かりにくかったですか。GWには秘密の共通鍵をA,B両方に（それぞれの公開鍵暗号を使って安全に）渡し、その共通鍵でBが暗号化、Aが復号化するという処理です。SSHプロトコルで共通鍵の生成だけ第三者がやるイメージ。

Nat Sakimura/崎村夏彦 @_nat

@hs_onsky その共通鍵を互いの識別子として使えますよね。 従って、結託しているもの同士は互いを識別可能です。

Hideki SAKAMOTO @hs_onsky

@_nat 情報保有機関がAとBの2つしかないならおっしゃる通りです。

Nat Sakimura/崎村夏彦 @_nat

@hs_onsky 情報保有機関数＞３の時、互いを識別できない理由が分からないのですが教えていただけませんか？暗号化の鍵は、AとBだけで共通ですよね？まさか、多数で共有しているとか？

Hideki SAKAMOTO @hs_onsky

@_nat はい、このケースでの共通鍵の目的はGWおよび第三者からデータの内容を隠す、かつ情報保有機関どうしで相手を識別できない、ですので、あえて全情報保有機関間で共通とする、という意味です。で、前述の共通鍵発生機から定期的に新しい共通鍵を公開鍵暗号方式で配布する(SSH方式)

Hideki SAKAMOTO @hs_onsky

@_nat man-in-the-middle はうまく使えば、(暗号化通信という意味での)セキュリティを損なわずに末端の相手同士の素性を互いに隠せますよね。それの応用でなんとかできるんじゃないかと。

Nat Sakimura/崎村夏彦 @_nat

@hs_onsky うーん、それで秘密を守るのはかなり困難では。3者以上で共有される秘密は秘密認定されませんよね…。GWがどこか一箇所と結託するだけで、国家管理が完成するので、かなり危ないと思います。