- Network Security - PKI

- 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 Alice • 今日のPKIでディレクトリを使っているのは少ない • Single CA • 証明書は自分で保持、必要なときに相手に渡す • Single root CA • 証明書の連鎖を受け取れる • Several root CAs • 右の図、参照 • ディレクトリを使えばもっと便利・フレキシブルに CA1 証明書の連鎖を持っている 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を提供するサーバーは少ない

15.6.2 OIDs • OID (object identifier) • ASN.1に則った、数字を”.”で区切った表記 • 例：1.2.840.113549.1.1 • 1番目、2番目の数字の意味は右のとおり • 3番目以降はRFCで定義 • 例：840ならUSの団体 • プロトコルやユーザーなどをすべて一意の数字で表現 • http://www.alvestrand.no/objectid/top.html

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 • 基本的な項目

15.7 X.509 and PKIX Certificates • 拡張（v3のみ）　たくさんあるので抜粋

15.7.1 X.509 and PKIX CRLs

15.8 Authorization Futures • Authorization（認可） • 何をしていいの？といった権限を決定する • 例：↓ この鶏は橋を渡る権限があるほかの鶏は橋を渡る権限がない

15.8.1 ACL (Access Control List) • 任意のユーザーに任意のアクセス権を設定するアクセス制御機能 • どのユーザーに、どのファイルを、どのようにアクセスできるか、などを細かく設定できる

15.8.2 Central Administration/Capabilities • 各リソースに対し、認可を受けたユーザーとその権限のリストを作る • 短所：資源量が多くなると大変 • アクセス制限が大雑把になってしまう • リストが膨大になる

15.8.2 Central Administration/Capabilities（続き） 大変簡単 • Groupの概念で対処するデータベースデータベース社員管理システム社員管理システム権限の設定社員A 社員B 社員C 社員A 社員B 社員C ACLの設定 ACLの設定 ACLの設定

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 署名されたcを欲しい！ • Blind signature Bob Alice 公開鍵<e, n> Rをランダムに選ぶ c(Re mod n) Xed≡X mod nとなるように dを選ぶ cd(Re mod n)d = cd(Red) mod n cdR/R = cd Red=R

15.9 Homework • 省略

- Network Security - PKI