c d

- Network Security PKI
sada@ecn
15.4 Revocation
• 証明書を取り消すシステムが必要
• このあたりは、クレジットカードに良く似てる
– 紛失したら早めに申し出る
– 店員はブラックリストにクレジット番号がないかチェック
• 証明書には有効期限がある
– セキュリティのため
– 大体のシステムは有効期限のチェックを怠らないため
• 有効期限をちゃんとチェックしないブラウザも
15.4.1 Revocation Mechanisms
• 証明書取り消しリスト(CRL:Certificate
Revocation List)
– 信頼してはいけない＆有効期限が切れていない
証明書の通し番号の表
– CAの署名を受けている
– 最新のCRLをうけいれないと証明書を信用しない
（→アタッカがCRLを消しても、古いCRLで上書き
しても無駄）
15.4.1.1 Delta CRLs
• CRLは無駄が多い
– 毎時間CAがCRLを発行したら、ユーザーは毎時
間受け取る必要がある
– 10000人解雇したら、10000人分ものリストが毎
時間送られてくる
– 実際に使われるのはわずか
15.4.1.1 Delta CRLs（続き）
• Delta CRLsは効率がいい
– 情報量が格段に減る
• 二種類のCRLを組み合わせる
– 相対的に長い時間で発行され、破棄された全て
の証明書の情報を含む、基準のCRL
– 相対的に短い時間で発行され、基準のCRL以降
に破棄された証明書の情報を含む、差分のCRL
15.4.1.2 First Valid Certificate
• 著者が提唱しているシステム
• 証明書の通し番号がFirst Valid Certificate の値(以
•
降nと表記）より小さかったら無効
CRLが大きくなりすぎたらnを引き上げて、CRLを小さ
くする
– 証明書の通し番号がnより小さくなってしまったユーザー
は、もちろん証明書を再発行しなければいけない
– 再発行するまでユーザーはアクセスできなくなる
• 基本的に通し番号だけだが、有効期限をいれないと
いけないときもある
15.4.2 OLRS Schemes
• OLRS (On-Line Revocation Server)はネット
ワーク越しに証明書取り消しを確認できるシ
ステム
• CAほどセキュアではない
1.5.4.3 Good-lists vs. Bad-lists
• Good-lists：有効な証明書を列挙
– セキュア
• 例：もしCAオペレータが賄賂をもらって不正に証明書
を発行しても、Good-listsなら防げる
• Bad-lists：無効な証明書を列挙
– パフォーマンス
• Good-listsよりサイズが小さく、変更も少ない
15.5 Directories and PKI
• 主なディレクトリサービス
– DNS
• 名前でlookupできるが、それだけ
• でも、インターネットでよく使われている
– X.500
• LDAPなどでクエリを出す
• 複雑な要求も出せる
• だが、あまり使われない
15.5 Directories and PKI (続き)
Aliceにとっての
root CA
• 今日のPKIでディレクトリ
を使っているのは少ない
CA1
– Single CA
• 証明書は自分で保持、必要
なときに相手に渡す
– Single root CA
• 証明書の連鎖を受け取れる
– Several root CAs
• 右の図、参照
• ディレクトリを使えばもっ
と便利・フレキシブルに
Alice
CA2
証明書の連鎖
を持っている
Bob
CA3
Bobにとっての
root CA
15.5.1 Store Certificates with
Subject or Issuer?
• PKIXでは所有者が証明書をもつ
• 所有者に証明書を保存する場合
– トップダウンモデルの時だけ認証のパスを作れる
– 鍵を持っている人を自分で把握する必要あり
• 発行者に証明書を保存する場合
– 認証のパスを作るのが容易
– 誰が鍵を要求しているか、所有者は気にしなくて
良い
15.5.2 Finding Certificate Chains
• PKIXは正方向の認証パスと逆方向の認証パ
スを構築できる
– 名前制約やポリシーがあると正方向はうまくいか
ない
15.6 PKIX and X.509
• PKIX（Public Key Infrastructure X.509）
– IETF （Internet Engineering Task Force）内の
ワーキンググループのこと
– X.509をベースにしている（著者はこれをよく思っ
ていないらしい）
1.5.6.1 Names
• X.500での名前
– 例：C=JP, O=ECN, OU=research, CN=sada
– ASN.1記法を用いているが効率悪い
• インターネットとX.500は調和性に欠ける
– DNSを基本とした、ht.sfc.keio.ac.jpみたいな
表記をするから
– SSLでも同じ問題が発生（URLを使うから）
– DNSが単なる”lookup service”で”true
directory”じゃないと批判するが、結局X.500
を提供するサーバーは少ない
C
country
O
organization
OU
organization unit
CN
common name
15.6.2 OIDs
• OID (object identifier)
– ASN.1に則った、数字を”.”で
区切った表記
• 例：1.2.840.113549.1.1
– 1番目、2番目の数字の意味
は右のとおり
– 3番目以降はRFCで定義
• 例：840ならUSの団体
1番目の数字
0 ITU-Tが規定
1 ISOが規定
2 ITU-T&ISOが規定
• プロトコルやユーザーなどを 0
すべて一意の数字で表現
1
• http://www.alvestrand.no/ 2
objectid/top.html
3
2番目の数字
標準
登録機関
加盟団体
身元が明らかな組織
15.6.3 Specification of Time
• UNIX timeでは2038年までしか表示できない
• ASN.1で定義しているのは次の二つ
– UTC Time:15 octets, 年を二桁で表示
– Generalized Time: 17 octets, 年を四桁で表示
• PKIXでは・・・
– 2049年まで： UTC Time
– 2050年以降：Generalized Time
15.7 X.509 and PKIX Certificates
• 基本的な項目
Version
バージョン
serialNumber
シリアル番号
Signature
署名方式
Issuer
証明書発行者のx.500識別名
Validity
公開鍵の有効期限
Subject
秘密鍵所有者のx.500識別名
subjectPublicKeyInfo
公開鍵
issuerUniqueIdentifier
認証局の固有識別子
subjectUniqueIdentifier 所有者の固有識別子
Extensions
拡張
15.7 X.509 and PKIX Certificates
• 拡張（v3のみ）たくさんあるので抜粋
subject key identifier
公開鍵のハッシュ
key usage
使用目的
certificate policies
証明書のポリシー
subject alt name
所有者の別名
issuer alt name
認証者の別名
CRL Distribution Points
CRLを配布している発行者の識別子
Basic Constraints
この証明書の被認証者がCAかどうか
Signature Value
上記の領域全体に対するCAの署名
15.7.1 X.509 and PKIX CRLs
Version
バージョン
Signature
署名方式
Issuer
発行者のx.500識別名
thisUpdate
発行日時
nextUpdate
次回のCRL発行予定日時
revokedCertificates 廃棄する証明書のシリア
ル番号と廃棄日時
crlExtension
拡張
15.8 Authorization Futures
• Authorization（認可）
– 何をしていいの？といった権限を決定する
– 例：↓
この鶏は橋を
渡る権限がある
ほかの鶏は橋を
渡る権限がない
15.8.1 ACL (Access Control List)
• 任意のユーザーに任意のアクセス権を設定
するアクセス制御機能
• どのユーザーに、どのファイルを、どのように
アクセスできるか、などを細かく設定できる
15.8.2 Central
Administration/Capabilities
• 各リソースに対し、認可を受けたユーザーと
その権限のリストを作る
• 短所：資源量が多くなると大変
– アクセス制限が大雑把になってしまう
– リストが膨大になる
15.8.2 Central
Administration/Capabilities（続
き）
大変
簡単
データベース
データベース
社員管理システム
社員A
ACLの設定
社員B
ACLの設定
権限の
設定
社員C
ACLの設定
• Groupの概念で対処する
社員管理システム
社員A
社員B
社員C
15.8.3 Groups
• グループ単位でのアクセス管理
– 複数のグループ（その上、どのサーバーも全員を
把握できない）、もしくは匿名のグループなども扱
える機構があると便利
• グループは中央で管理、全体の把握が容易
– 自由にグループを作れると便利
15.8.3.1 Cross-Organizational
and Nested Groups
• ACLやグループは組み合
•
わせることが必要
Aliceは提携先のリソース
にアクセスできるか
？
– Aliceがどのグループに所属
しているのか、どういう権限
があるのか
• 解決策を次のスライドから
提示する
提携先
管理者
会社B
管理者
会社A
管理者
Alice
15.8.3.1 Cross-Organizational
and Nested Groups（続き・１）
• 個人がどのグループに所属するのかを一人一人判断し、一人一人アク
セス権を決定する
– パフォーマンス、スケールの問題
– グループ帰属関係が難しくなる
• Aliceから要求があったら、オンラインのグループのサーバーに、Aliceが
グループの一員かたずねる
– パフォーマンスが問題
– ↑をキャッシュで解決しようとしても、キャッシュの有効期限という問題
が発生
• Aliceが所属するグループの全員にKerberosチケットを交付
– Cross-organizational groupで問題になる
– 複数のグループに所属しているときに問題
15.8.3.1 Cross-Organizational
and Nested Groups（続き・２）
• Aliceの証明書に、自分の所属するgroupをリストアップ
– 沢山のグループに入っているときにスケールの問題
– サーバーはAliceが所属する全てのgroupを知っている必要がある
– Aliceがグループに入ったり、やめたりしたら更新作業が必要
• グループの証明書を作り、グループのメンバーはそれを持つ
– 良いシステム
– サーバーの負担が少ない、サーバーが攻撃されていてもクライアント
が主体で動いてくれる
– 古い証明書は拒否、といったポリシー決めも可能
15.8.4 Roles（役？）
• 乱暴に言うと、sudoの高機能版
• 各ユーザーが特殊な役になる
• ACLを使わず、特定の機能を使うときだけ管理者権
限をユーザーが持つようになる
– 例：パスワードの変更
– 管理者として動作させているときは、インターフェースを変
える
– 特殊なことを行うのはまれなので、こういうモデルでもOK
– 管理者権限を与えられるプログラムは信頼のあるものだ
け、そうでないものはすべてユーザー権限で。
– 複雑なポリシー（例：AもしくはBのどちらかだけファイルに
アクセスできる）はChinese Wallモデルで解決できる
15.8.4 Roles（続き）
• 分散環境では？
– 個人、グループ、役がある
• 役とグループの違い
– 役は能動的に権限を求める、グループは受動的に権限が決まる
• 個人と役の違い
– 特殊な行動をしたくて権限をもらった時のユーザーが役
– 権限を与えられるプログラムは中央で集中管理する。い
つ誰が役になったなどをログにとれる。
• このモデルはインターネットでは適さない。LANのよ
うなネットワークで使うべき。
15.8.5 Anonymous Groups
• 一度リソースにアクセスできる、と分かったらその後
の認証は省略したい
– 監査のために、省略しないことも多い
• 一時的な公開鍵で、グループのサーバーに認可し
•
てもらうことで解決
Blind signature
– アルゴリズムはRSAに似たもの
– サーバーは誰を認証したか知らない（知るべきではない）
– 成りすましを防ぐために、複数の鍵を持つことができる
15.8.5 Anonymous Groups
• Blind signature
署名されたcを欲しい！
Bob
Alice
公開鍵<e, n>
Xed≡X mod nと
なるように
dを選ぶ
Rをランダムに選ぶ
c(Re mod n)
cd(Re mod n)d
=
Red=R
cd(Red) mod n
cdR/R
=
cd
15.9 Homework
• 省略

Download Report