...

インターネット時代のセキュリティ管理 第10回 IDとプライバシー(3) ID

by user

on
Category: Documents
12

views

Report

Comments

Transcript

インターネット時代のセキュリティ管理 第10回 IDとプライバシー(3) ID
講義内容
„ 学生発表
„ 前回からのやり残し
z プライバシー
„ Trust Pointについて
z 住基ネット
インターネット時代のセキュリティ管理
第10回 IDとプライバシー(3)
慶應義塾大学 村井 純
奈良先端科学技術大学院大学 山口英
2
学生発表
„ 発表者
z 秋山満昭 奈良先端科学技術大学院大学
IDに対する考察
奈良先端科学技術大学院大学
情報科学研究科
インターネット工学講座 M1
秋山 満昭
3
IDを利用する際の問題点
IDが利用される対象領域
„ ローカルなID
z 特定領域に限定されたID
⇒それぞれの領域ごとにIDと情報を関連付ける必要がある
1.プライバシー保護
„
IDによるトレーサビリティの向上は何を意味するか
z 管理者からみた(管理上の)セキュリティの向上
z 利用者からみたプライバシーの侵害
この2つがトレードオフ
„ グローバルなID
z 複数領域をまたがったID
⇒IDと情報の関連が
プライバシーをどこまで保護するか?合意点はどこか?
⇒IDの利用される領域によって、プライバシー保護の観点から、IDに含まれる情報は異なるはずだ
„
„ 情報の一括管理が技術的に容易なことから、グローバルなIDの利用が今後増えてい
く(?)
2.ID自体が持つ属性データとトラッキング
„
„ サービスのクラスごとに扱う情報量とプライバシーの合意点が異なる
⇒クラスの切り分けが必要ではないか?
ID自体に何らかの意味がある
z
z
z
電話番号
IPアドレス
学籍番号
„
„
ID自体に情報を持たせるべきか?
IDを完全にランダムに生成すべきか?
⇒IDが完全にランダムで生成されるとしても、トラッキングは可能
5
6
1
技術課題
まとめと質問
„ IDのspoofing防止
IPアドレス,MACアドレスなどは比較的容易にspoofingが可能
z ハードウェア的にspoofing不可能な構造にする
z certificationを行う
„ 技術的に解決可能な問題
z IDのspoofing
z トラッキング
„ 倫理的に解決すべき問題
z プライバシー保護の合意点
„ セキュアなread/write機構の必要性
z 暗号化
z 認証機構
z ハッシュ
„ 質問
z ID自体に情報を持たせるべき?
„ トラッキング防止技術
z ワンタイムID
7
8
プライバシーとは何か
„ 「ひとりにしておいてもらえる権利」
„ “right to be let alone”
Samuel Warren (1890年)
Warren, Samuel, and Louis Brandeis. "The Right to Privacy.“
The Harvard Law Review 4 (1890): 193-220.)
プライバシー
„ 「第三者が、自らに関する個人情報をどの程度取得あ
るいは共有することが出来るか、自ら決定できる権利」
Alan Westin (1967年)
Westin, Alan. Privacy and Freedom. New York: Atheneum, 1967
„ 「ひとりにしておいてもらえる権利」から
「自己情報をコントロールする権利」へ
参考:
プライバシー年表: http://homepage3.nifty.com/sociology/research/privacy/privacychrono.html
「プライバシー」の本当の意味を教えよう【コラム】: http://it.nikkei.co.jp/security/news/index.aspx?i=20051102ck000ca
OECDガイドライン(1/3)
OECDガイドライン(2/3)
„ プライバシー保護と個人データの国際流通に
(第2部:国内適用における基本原則より)
ついてのガイドライン
10
1. 収集制限の原則
z 1980年9月23日 OECD理事会で採択
z いかなる個人データも適法かつ公正な手段で、データ主体に通るいは
z 主要先進国でのプライバシー保護の考え方の基礎
同意を得た上で、収集されるべき
„ プライバシーと個人の自由を保護し、かつプライバシーと情報
2. データ内容の原則
の自由な流通という基本的だが競合する価値を調和
„ 個人データ(Personal data)の国際流通は経済及び社会の発展
に貢献すること
„ プライバシー保護と個人データの国際流通に係わる国内法は、
そのような国際流通を妨げる恐れがあることを認識し、加盟国
間の情報の自由な流通を促進
z 利用目的に沿ったものであるべき
z 必要な範囲内で正確、完全であり最新なものであるべき
3. 目的明確化の原則
z 収集時以前の時点で、個人データの収集目的を明確化
4. 利用制限の原則
z 目的以外に開示利用その他に使用されるべきではない
z データ主体の同意がある場合、法律の規定による場合は除く
z http://www.mofa.go.jp/mofaj/gaiko/oecd/privacy.html
z http://www1.oecd.org/publications/e-book/9302011E.pdf
11
12
2
OECDガイドライン(3/3)
IDと個人情報保護法
5. 安全保護の原則
„ 個人情報保護法における個人情報の定義
z 個人データは、紛失・不当なアクセス、破壊、使用、修正、開示等の
„ この法律において「個人情報」とは、生存する個人に関
危険から保護されなければならない
する情報であって、当該情報に含まれる氏名、生年月
日その他の記述等により特定の個人を識別することが
できるもの(他の情報と容易に照合することができ、そ
れにより特定の個人を識別することができることとなる
ものを含む。)をいう。
6. 公開の原則
z 個人データに係わる開発、運用及び政策は公開
z 個人データの存在、性質及びその主要な利用目的、
データ管理者の識別、通常の住所が容易にわかるようにする
7. 個人参加の原則
z 自己に関するデータを合理的な期間内に、自己に分かりやすい形で知
らしめられること
» もし必要なら、過度にならない費用がかかってもよい
z データに対して異議を申し立てられること。その異議が認められた場合
Î住所・氏名など以外のIDは(個人情報保護法の
いう) 個人情報 ではない
には、そのデータを消去、修正、完全化、補正させること
8. 責任の原則
z データ管理者は、上記の諸原則の実施措置に従う責任がある
13
14
IDとプライバシーのリスク
1. 属性データ
z 住所、氏名,、生年月日などの属性データ
自体がID
z それ自体が漏洩すると困る(可能性がある)
IDとプライバシーの
セキュリティリスク
2. IDによるトラッキング
z 電話番号, RFID, IPアドレスなどのID
z それ自体が漏洩しても、直接は困らない
Î追跡が行われると困ったことになる
(可能性がある)
×
IDはタダの番号だからプライバシーの問題はない
属性データ
IDによるトラッキング
„ IDそのものが個人情報
„ トラッキングの例
z いつ、どこにいたかが記録されうる
z 例1: ID 012345 の Suica で11月29日18時10分東京駅
乗車、19時00分に新宿駅で下車
z 例2: ID 007743 の Edy で11月1日15時10分に
慶応藤沢生協で150円のお買い物
„ ID識別機構がさまざまな場所にあれば、
„ 例:氏名、住所、性別、生年月日
„ 問題:
z 属性データが漏れる
„ 対策:
z 属性データが漏れないようにする(?)
z IDに属性データを使わないようにする(?)
16
行動を把握できる
„ IDと個人の関連づけも可能
z 氏名を記入する場所などでRFIDをスキャンする
» 対応表が作られる可能性もある
» Suica 定期券はもともと関連づけられている
z ID 007743 の Edy は村井さんの Edy カードだ!
17
参考:高木浩光氏 ICCARD WORLD 2004講演資料より
http://java-house.jp/~takagi/paper/iccard-world-2004-takagi.pdf
18
3
IDとスコープの関係
IDとスコープ
„ 独立性の高いID
„ 共通ID
z 利用されるドメインが
„ IDの利用範囲に応じて、プライバシーの問題も
z 匿名を前提に蓄積された属性
限定されている
異なる
情報を匿名ではなくする恐れ
„ 利用可能なドメインが広く、自動認識可能なIDは
トラッキングされるリスクが高い
慶応大学
学生証
ポイント
カード
慶応大学
学生証
サービスX
銀行通帳
ポイント
カード
銀行通帳
„ IDの例(詳細は後述):
z RFID
サービスX
» 特に持ち運ぶRFID
ID1
ID2
ID3
…
IDn
z IPアドレス
ID
» 特に固定IPアドレス
z Cookie
» 広告会社のWebサーバのバナー広告
参考:高木浩光氏 ICCARD WORLD 2004講演資料より
http://java-house.jp/~takagi/paper/iccard-world-2004-takagi.pdf
19
20
サードパーティCookieの例
IPv6アドレスの例
„ アクセス先のWebサイトからリンクされている
„ IPv6アドレスの構造
サーバから受け取るCookie
z MACアドレスがIPv6アドレスの一部としてそのまま
利用される
„ 他のネットワークへ移動した場合でも、
同一MACアドレスを利用しているかがわかる
z 典型的には広告サイトのCookie
z いつ、誰が、どのサイトを訪れたかを把握できる
広告サイト
ユーザーに割り当て
ISPが利用
Infrastructure
/0
Site
/48
インラインリンク
Interface
/64
Webサイト
A
/128
Webサイト
B
Webサイト
C
Webサイト
D
例: 2001:200:0:8803:203:47ff:fedf:73a6の場合
2001:200:0
ISPのプレフィックス
8803
203:47ff:fedf:73a6
サイト内で
サブネット
分割に利用
サブネットで利用
アクセス
Cookie
(MACアドレス)
21
22
RFIDセキュリティのゴール
„ 追跡を防ぐために
z タグの無効化を可能に
z 公空間でのIDは無作為化される
ない
か容易に変更可能
z 権限のないリーダに情報が読
z タグ内部の情報はアクセス制御可
能
まれることを防ぐ
z 信頼できない通信路なら暗号化
z タグと所有者の関係が連想で
z アクセス制御に加え、タグとリーダ
きる長期観測(long-term
の相互認証は必要
tracking associations)を防ぐ
z セッションの乗っ取り、リプレイ攻
撃は重要
z 誤りの誘発や電源断などで、プロ
トコルとして危うくなる事や、セッシ
ョンがのっとり可能な状態になった
どうやら、こ
ままになる事は避ける。
のIDはAさ
んの所有物
z 仲介者攻撃、リプレイ攻撃に強い
らしいぞ。
必要がある。
„ ゴール
z プライバシを妥協するべきでは
RFIDのセキュリティに関する検討
24
4
低価格タグの場合
RFIDセキュリティの実現のためには
„ 一般的な、passive, factory-programmed, read-only
1.
なタグ
„ 高機能なセキュリティを実装できる計算力がない
„ barcode と同様、検出範囲内では無差別に可読
„ reader/tag 共に認証という概念はなし
アクセスコントロール
•
•
•
公開鍵暗号 : タグに秘密鍵、リーダに公開鍵
共通鍵 : タグのグループに共通の鍵、リーダにも対応する
鍵
その他の方法
リーダ・タグの認証
2.
•
タグとリーダの相互認証を行う
仲介者攻撃(man-in-the-middle attack)
»
•
nonce(ナンス)を用いて情報の暗号化を行う
リプレイ攻撃(replay attack)
»
25
26
手法1 : シリアルだけ消去してみる
手法2 : 暗号を使ってみる
„ 製品コードのみを残し、シリアルを消去する
„ 公開鍵暗号
z タグに秘密鍵、リーダに公開鍵
z タグとリーダの相互認証が実現可能
z しかし、5セント程度のRFIDでは圧倒的に計算力不足
„ ID自体が追跡できなくなる
„ しかし、それらしい関連を想像する事により、個人のト
„ 共通鍵暗号
z タグにしまった鍵と対応する鍵をリーダに持つ必要
z 鍵管理が煩雑、物理的なクラックに耐える必要がある
z 場合によっては使いにくい
ラックはできてしまう
z グッチの靴、ロレックスの時計
z このメカニズムでは不十分
27
28
低コストタグで短期間で実現する事を考える:
ハッシュベースドロックアルゴリズム
„ ハードウェア最適化された一方向ハッシュは、共通鍵
„ lock値 =hash(任意key)
„ ロックされたタグは正確なメ
正しいメタID
暗号より高速で安価なタグに向いている
„ メタIDと呼ばれるメモリ
タIDでしか応答しない
メタID以外
„ Long-term associations問
lock
z ロック状態、アンロック状態を保持
unlock
z アンロック状態で検出範囲内で誰でも読める
新しいメタID
③ポーリングして
存在確認
④タグは何も返答しない
lock状態のタグ
①lock値を送信して
タグをlockする
unlock状態のタグ
29
②lock値を受信し、
タグをlockする
題は回避できる
„ 同じメタIDを長期間利用する
とトラッキングができてしまう
可能性がある
„ 周期的にロック/アンロックを
繰り返すことでメタIDの更新
が必然的に起こる
•メタID領域にlock値を格納し、
ロック状態に遷移
•ロック状態では、メタIDに対する問
い合わせ応答以外を全てしなくなる
•アンロックするためには
オリジナルのkeyで解除する
30
5
コストを下げる代わりに犠牲となるもの
„ ハッシュベースドロックアルゴリズムは
z タグ自身の認証ができない
z 仲介者攻撃(man-in-the-middle attack)が可能
• 適切なリーダに対するメタ
IDクエリを不正に再要求でき
る
• その後、リーダの発したkey
を使ってタグをアンロックする
• キーレスエントリーのクルマ
が抱える脆弱性と同様
• 認証されたリーダのアクセ
スがない限り安全
不正なリーダ
③正規のリーダに成りすまし、
lock値を再送信する
RFIDとプライバシー
②lock値を含む
電波を盗聴
④lock値を受信し、
タグがunlockされる
正規のリーダ
①lock値を送信して
タグをlockする
②lock値を受信し、
タグをlockする
31
ORF2004と電子タグ実験
„ Open Research Forum (ORF) 2004
z 2004/11/23、24
z 慶應義塾大学湘南藤沢キャンパス(SFC)のオープンキャンパスイベント
z 5000人規模の来場者
„ ORF2004における電子タグ実験
ORF 2004における実験
z イベント会場におけるUHF帯電子タグの利用
z EPC Networkの応用
z アプリケーションの提案
» ORF Activity Score
» イベント運営支援
z プライバシ・ガイドライン対応
z RFID Reader シンボルマーク
34
参加者が持ち歩いたRFIDタグ
ORF2004
HF帯リーダ
UHF帯リーダ
„ HF/UHFの2種類を設置
„ HF帯リーダ
z 各出展者ブース、ポスターセッシ
ョン会場、セミナセッション会場に
設置
z 来場者は、各ブースにおいてブ
ース来訪を記録できる
„ UHF帯リーダ
UHF帯リーダ配置図
(HF帯リーダは全てのブースに設置)
UHFリーダ
No.4
UHFリーダ
No.5
UHFリーダ
No.3
z 会場内の動線上に設置
z Café内設置し、ブース来訪を可
視化するアプリケーションを提供
UHFリーダ
No.2
UHFリーダ
No.6
UHFリーダ
No.1
35
36
6
ORF Activity Score
EPC Networkを応用したイベント運営支援
各ブースの来場者数
„ ORF来場者のブースへの来
訪記録を可視化するアプリ
ケーション
„ 来訪記録
„ 名刺レスサービス
z ブース来場者情報の出展者への
提供
z サービス利用を希望した来場者
EPCをブースごとに記録し、来場
者リストを生成、出展者へ提供
各ブースのアクセス状況
z 各ブースのHF帯RFIDリー
ダで記録可能
„ ORF Activity Score端末
„ 研究情報紹介サービス
z 出展者の研究情報、研究者への
アクセス方法などをブース来場者
へ提供
z サービス利用を希望した来場者へ
、出展者から提供された情報を電
子メール送信
(カフェ内に設置)
z UHF帯RFIDリーダで来場
者検知
z スクリーン上に行動履歴を
表示
出展者
出展ブース
出展者
出展ブース
ORF Activity Score端末
EPC Network上に構築され
たブース来訪記録システム
5-a. 来場者情報を請求
イベント運営者
来場者
6. 来場者情報を開示
アンテナ
来場者
スクリーン
来場者
1.来訪記録を残したい
ブースのリーダへ
HF帯電子タグをかざす
2.UHFタグにより来場者を検出
該当する記録の表示
1.来訪記録を残したい
ブースのリーダへ
HF帯電子タグをかざす
2.リーダによる
EPCの読み込み
3. 投票履歴を収集
4. 来場者の把握、
集計が可能
5-b. 来訪したブースの
研究情報を弟子メール送信
37
電子タグのプライバシガイドライン
38
RFIDリーダ シンボルマーク
„ ORF Communication Point
z RFIDリーダの位置を示し、
利用者の利便性・視認性を
向上するのが目的
z ORF2004では、会場内の
実証実験用RFIDリーダ近辺
に掲示
„ 経済産業省・総務省ガイドライン (2004.6.8公表)
z 電子タグが装着してあることの表示
z 電子タグの読取りに関する消費者(利用者)の最終的な選択権の留保
z 電子タグの社会的利益等に関する情報提供
z 個人情報データベースと電子タグの情報を連携する場合の個人情報保護法の適
用
z 個人情報を電子タグに記録した場合、当該情報の取扱に関しての規定
„ イベント支援に適した対応の検討
z 来場者向けの説明書の配布およびサインボードの設置
z ブース来訪情報の確認・消去端末の設置
„ RFIDリーダの設置場所
を意味するシンボルマークを提案
designed by Kotaro Watanabe (Wakita Lab.)
39
40
trust pointとは(1)
„ trust point = 「信頼点」
z 主体者A:信頼を証明される主体
z 認証者B:主体者の信頼を証明する(←信頼点)
z 信頼者C:主体者の信頼を検証する第三者
Trust Point
„ CはBの情報を用いて、Aを信頼するか判断する。
42
7
公開鍵暗号による認証の原理
trust pointとは(2)
„ 原理
z 公開鍵暗号を使用
„ 信頼者による信頼の検証
z 認証者と主体者には契約関係に基づいた契約信頼関係が存在する
z 信頼者は主体者を直接検証するわけではない
z 最終的な判断はCが決定する
特定の文字列
秘密鍵
z ネットワーク上での信頼の検証には公開鍵暗号系が利用される
» 復号鍵は公開
• 公開鍵 (public key)
» 暗号鍵はユーザのみが保持・管
理
• 秘密鍵 (secret key)
z 受信者も知っている特定の平文を
認証者
契約信頼
暗号化
電子署名
Trust?
or
Untrust?
ザと証明
z 電子署名
公開鍵
主体者
z 正しく復元できれば、正当なユー
信頼者
確かに本人だ!
„ 特徴
z ネットワーク上に鍵を伝送する必
要がない
z 署名や、改竄防止の機能を実現
できる
43
住民基本台帳カード
44
住民基本台帳カード
„ 住民基本台帳カード
z 住基カードは、2005年8月25日に交付が開始された、住民基本台帳ネットワークシステム
の提供サービスとして希望者に配布されるICカードのことである。
z 住民基本台帳法(昭和42年法律第81号)第30条の44第1項にて法的位置づけが規定され
ている。
z 2005年末、544,708枚が交付されている
„ カード内情報
z 住民表コード:11桁の数字、本人情報との対応付けのため
z 暗証番号:4桁の数字、本人確認のため
z 認証用鍵:偽造カード防止
z 輸送鍵:輸送時の不正利用を防止
„ 利用可能なアプリケーション
z 住基アプリケーション、公的個人認証アプリケーションを有する。
z 他にも健康保険証などの他アプリケーションをインストールできる余地が設計されており、
多目的カードとしての共用化が検討されている。
45
46
様々なサービスへの応用例案
住基カードによる個人認証
1. 証明書自動交付機を利用して、住民票の写し、印鑑登録証明書・その他の
„ 公的個人認証サービス
z 住基カードを利用した、行政による公的な個人認証の仕組
み。平成16年1月29日サービスが提供開始された。
z 住基カード内に公開鍵・秘密鍵のペアと公開鍵証明書を格
納することで、公開鍵暗号系の自己証明が利用可能になっ
た。
z この自己証明機能を利用した電子署名機構
z 行政への届出などで利用可能
証明書の交付を受けるサービス
2. 申請書を自動的に作成するサービス
3. 検診、健康診断又は健康相談の申込み、結果の照会等を行うサービス
4. 事故、急病等で救急医療を受ける場合、あらかじめ登録した本人情報を医
療機関等に提供するサービス
5. 災害時等において、避難者情報の登録、避難場所の検索等を行うサービス
6. 公共施設の空き照会、予約等を行うサービス
7. 図書館の利用、図書の貸出し等を行うサービス
8. 健康保険、老人保健等の資格確認を行うサービス
9. 介護保険の資格確認等を行うサービス
10. 高齢者等の緊急通報を行うサービス
11. 病院の診察券等として利用するサービス
12. 商店街での利用に応じポイント情報を保存し、これを活用するサービス
13. 公共交通機関の利用に係るサービス
14. 地域通貨、電子福祉チケット等に係るサービス
15. 公共料金等の決済に係るサービス
„ 電子政府におけるGPKIを利用した新しいサービス
47
48
8
秘密鍵を利用した個人認証のイメージ
政府認証基盤 (Government PKI)
„ 行政サービスなどで必要となる、公的個人認証のために構築さ
れた統一的な認証基盤
z 行政サービスとして構成
z 行政組織における各種申請・認可処理をオンライン化するための基盤環
秘密鍵
印鑑
境
» 行政組織における権限任者の身元保証
» 民間組織(企業や個人)の側での身元保証
z 電子化された「印鑑証明」と「法人登記」
„ PKIが提供する機能
地方自治体から与えられる
印鑑と対応した印鑑証明書
z 相互認証
z 機密性のある通信
民事訴訟法第228条第4項
「私文書は、本人又はその代理人
の署名又は押印があるときは、真
正に成立したものと推定する。」
z 否認防止
z 完全性
認証局から与えられる
秘密鍵と対応した証明書
電子署名法第3条
「当該電磁的記録に記録された情
報について本人による電子署名が
行なわれているときは、真正に成立
したものと推定する。」
49
50
PKIの概要
PKIの基本アイディア
„ Public-Key Infrastructure
z 「公開鍵認証基盤」
„ Trusted third-party authentication system
z 信頼に足りうる第三者によって身分の証明・保証を行う機構
» 公開鍵暗号を用いた認証サービスを構成
» 大規模なサービスの提供が可能
• 良好なスケーラビリティ (scalability)
» アプリケーション/ミドルウェアとして構成
• インターネットに限られたシステムではない
• バイナリ配布されるプログラムの「正しさ」を保証するシステムで
PKIを使うことも可能
» 多くのインターネットアプリケーションで利用
• Secure Web Access via SSL/TLS (https)
• Encrypted/Signed E-mail (S/MIME)
• Applet Verification (Java, Active-X, etc.)
» まず、あなたしかもってないものを見せて?
• あなたの秘密鍵で暗号化された署名
» あなたは本当に「あなた」ですか?
• 署名を利用して秘密鍵と公開鍵のペアを確認
• 公開鍵証明書(お墨付き)を利用して公開鍵を検証
→ あなたはお墨付きがあります信用します
„ 社会的には
z 社員証、パスポートなどと同じような考え方
z 「私が私である」ことを世間が信頼する第三者によって「裏書
」するシステム
» パスポート:日本国政府が日本国民の身分を証明する公文書
» 社員証:ある企業が社員の身分を証明する文書
51
52
公開鍵証明書
認証機関
„ あるユーザは秘密鍵と公開鍵のペアを持つ
z 秘密鍵はその本人だけが安全に、かつ、第三者には開示さ
れないように管理する
„ CA: Certification Authority
z Trusted-third party としての役割を提供
» 公開鍵と、公開鍵の持ち主のマッピングを保証
» CAの役割、制約、サービス提供要件を CPS (Certificate Practice
Statement) として明確に定義
„ 公開鍵証明書 (certificate)
z 公開鍵と、それとペアの秘密鍵を持つユーザを結びつける
情報
z 証明書自身が改ざんできない構造を提供
z いろいろな種類が現在でも使われている
z 公開鍵の持ち主の身分を確認
z 証明書を構成
z さらに、CA自身による電子署名を証明書に付加
» 証明書の発行者を明示
» 発行した証明書の真正性・妥当性を保証
» X.509証明書
» PGP (Pretty Good Privacy) 証明書
» SPKI (Simple Public Key Infrastructure) 証明書
53
54
9
電子署名の検証(1)
電子署名の検証(2)
„ 電子署名に関連付けられた公開鍵を入手
z 電子署名の作成には秘密鍵を用いる
z 電子署名の検証には公開鍵を用いる
„ 公開鍵証明書の検証が必要
z 証明書の中にある CA の電子署名を検証
» 証明書を発行したCAの正しさを確認
z 証明書の中にある有効期間をチェック
← 署名ユーザの公開鍵と秘密鍵の対応
» 期限切れの証明書は信用できない
z 秘密鍵に対応する公開鍵が正しくなければ電子署名の検証
z 証明書そのものが失効しているかどうかを確認
結果は信用できない
» 証明書の失効管理はCAが行う
» CRL (Certificate Revocation List) の提供
» 実時間によるCRL情報の取得と利用
• 現在標準化作業中
» 公開鍵証明書を用いる
» CAによる「裏書」により公開鍵の正しさを保証
» 本当に正しい証明書か?
55
56
電子署名の検証(3)
木構造によるCAの階層化
„ CAの電子署名検証が必要
z CAの公開鍵を保証する情報が必要
„ Root CA を頂点とする木構造
z 「信頼の関係」を構築
» 下位のCAにとっては、上位のCAにより発行する証明書の真正性・
信頼性を担保する
» 上位のCAにとっては、下位のCAを信認し、証明書発行業務を行わ
せる
» CA自身の証明書
z CAの証明書に対して電子署名をするのは誰?
» ほかのCA
» 自分自身
z 下位のCAは上位のCAにより信頼性が担保される
„ 結果として
z CAは木構造を構成する
z 自分で自身を署名した証明書を用いたCAが存在しなければ
ならない
» 下位のCAが持つCPSは、上位のCAにより規定され、また、その運
用状態の検査が可能になっていなければならない
» CPSの設定と、その実施状況の管理
» Root CA
57
認証局の役割とPKI
(Public Key Infrastructure)
検証パスの構成
検証
„ 公開鍵の正当性の証明
z 公開鍵は、他人がなりすまして公開した可能性がある
z CA が公開鍵に署名することにより正当性を証明する
„ CAの問題
z 認証局の署名の検証に用いる公開鍵の正当性は、誰が
証明するのか?
Root CA
„ 木構造によるCAの階層
Root CA
署名
CA
検証
署名
検証
CA
署名
58
化
検証
z 下位のCA は、上位のCAよ
ある証明書の検査を行う場合には、
CAの木構造を遡りながら検査を再
起的に行うことになる。
⇒ 検証のパス (path) を構成
り発行される証明書により
、自身の発行する証明書
の真正性・信頼性を担保す
る
ユーザの持つ証明書
59
CA
署名
検証
署名
ユーザの持つ証明書
60
10
住基カードでのtrust point
住基カードの持つ公開鍵暗号仕様(1)
„ 政府認証基盤(GPKI:Government Private key
„ 住基カードの暗号仕様
z 1024bitのRSA暗号を処理可能なことが要求仕様に挙げら
れている
z 耐タンパ性を持つ
z ISO/IEC 15408の認証取得が仕様要求
Infrastructure)における住基カードの利用
契約信頼
住民として事前に登録されている
住基カード発行時に人とカードが対応づけられる
認証者
個人CA局
個人証明を問い合わせる
主体者
日本国民
信頼者
行政など
61
電子証明書の発行:
地方公共団体による公的個人認証サービス
62
政府認証基盤の概要
„ 発行機関は、住民の
基本4情報(=存在証
明)に対して証明書を
発行する
„ 地方自治体が本人確
認に責任を負う
„ 行政機関は証明書の
管理を行う
認証
電子化された
行政手続き
個人
商標登記認証局
相互認証
認証
行政などの
業務システム
処分権者の
認証
民間部門など
の認証局
相互認証
ブリッジ認証局
政府認証基盤
行政機関認証局
63
64
PGPの概要
PGPの基本アイディア
„ PGP(Pretty Good Privacy)
„ 1991 年 Phil Zimmermann 氏により作成される
„ 公開鍵暗号方式、秘密鍵暗号方式を利用
„ PGPとは相互信用モデルを技術的に実現したもの
z 相手からの情報を相手の公開鍵により検証する
» 本当にあなたの文書ですか?
• あなたの秘密鍵で署名されたファイル、メッセージ
» 検証する
• 相手の公開鍵により復号化、署名の検証を行う
z 公開鍵(public key)
z 秘密鍵(private key)
→ あなたを信用します
„ 鍵交換
z 秘密鍵は自身が保管し、公開鍵を第三者と交換する
z 公開鍵サーバから第三者の公開鍵を取得する
„ 社会的には
z 符丁などと同じような考え方
z 「私が私である」ことを「私しか持っていないもの」で証明する
» 符丁:私しか知らない暗号(山川海空)、知識
65
66
11
PGPが提供するもの
PGPによる自己証明
„ 認証: authentication
z エンティティの真正性の証明
z 真正性を合理的に検証する機構の提供
„ 自身の秘密鍵で暗号化したメッセージを署名として利
用する
„ 通信相手の公開鍵でメッセージを復号化
„ 完全性: integrity
z データ改ざんの有無を検証する機構の提供
z 暗号技術を用いた改ざん検査
秘密鍵
公開鍵
„ 機密性: confidentiality
z 対象とするエンティティのみに情報が開示される機構の提供
z 暗号化された情報の交換と鍵管理
„ 正しい公開鍵を入手する必要がある
„ 隣接関係での信頼でしかない
„ 否認防止: non-repudiation
z 電子署名によるデータ受発信証明
67
Web of trust; 信用の網
68
それぞれの特徴
„ 信用関係の拡張
z PGPは新しい対象と改めて認証、信用関係を形成
„ 証明書(Certificate)
○:厳密な認証、運用が簡単
☓:スケーラビリティに問題
z 「この人の公開鍵はこれです」
z 保証する人が署名をする
z PKIは信用する対象が信用している対象を信用する
„ 署名の連鎖
○:スケーラビリティに優れる
☓:厳密な信用関係が形成されない、運用コスト高
z 知っている人が署名していれば信じ
る
z 知っている人が署名した証明書を持
っている人が、署名していれば信じ
る
z 連鎖する
→ 1対1型の信用関係形成と1対多型の信用関係形成の違い
„ 各自から見た信用の網がある
69
70
今後のTrust Pointのあり方は?
信頼モデルの違い
„ 増加するデジタルID
間接信頼
直接信頼
例
PKI
PGP, SNS
信頼点
信頼の連鎖
認証者
個人
認証者
個人責任
IDの信憑性
認証者が負う
個人責任
(本人確認等)
スケーラビリティ
厳密性
優れる
問題あり
完全に厳密ではない
厳密
„ ネットワークによるID間の相互接続
→ 認証へのID応用機会が増加する
71
72
12
IDとプライバシー
IDとプライバシー
„ 電子化された識別子
z UPC, ISBN, 郵便番号, 電話番号, IPアドレス…
„ プライバシへの懸念
z ID自体が属性情報
z IDによる追跡
まとめ(1)
まとめ(2)
» 多くのIDが既に機会読み取り可能な形式となている
z IDの設計
» IDの利用可能範囲拡大に伴う問題
» 構造化, ID長, 抽象化の範囲(スコープ)
» インターネットとの関係
» IDへのアクセス
„ トレードオフ
z 住基ネットを巡るマスコミ報道
» メリットの不理解
„ RFIDの登場と普及
z ローコストタグ
z スマートカードのの普及
z ローコストRFIDとセキュリティ
» Felica (Suica, Edy)
» 住基ネットカード
73
74
IDとプライバシー
まとめ(3)
„ Trust Point
z 住基カードを利用したGPKI
z 認証へのID利用
75
13
Fly UP