分散システムにおけるセキュリティ - 東野研究室nakata/mobile-cp/chap-08j...2 7...
TRANSCRIPT
1
1
分散システムにおけるセキュリティ
教科書8章
2
分散システムにおけるセキュリティ
セキュリティの概要
セキュアチャネル認証
メッセージの完全性と機密性
セキュアグループ通信
アクセス制御一般的課題
ファイアウォール
セキュアなモバイルコード
セキュリティ管理鍵管理
セキュアグループ管理
認可管理
3
セキュリティの概要
セキュアシステムの定義
セキュリティ要求
セキュリティ脅威
セキュリティメカニズム
セキュリティポリシー
セキュリティシステムの設計要素
セキュリティプロトコル
暗号アルゴリズム
4
セキュリティ要求
高信頼システムへのセキュリティ要求
機密性(confidentiality)情報を認可されたユーザに対してのみ開示
完全性(integrity)情報を不当に改変されないことの保証
不当な改変は検出
5
セキュリティ脅威
セキュリティシステムの目標セキュリティ脅威からのサービス・データの保護
セキュリティ脅威(security threats)横取(interception)
不正なユーザがサービスやデータにアクセス可能になる状態(メッセージ傍受など)
中断(interruption)ファイルが破壊されたり削除されたりする状態(サービス拒否攻撃(Denial-of-Service Attack)など)
改変(modification)データの不正な変更・サービスの改竄
合成(fabrication)通常存在しないデータやサービスが作り出される状態(侵入者によるバックドア設置など)
横取、改変、合成はデータ偽造の一種 6
セキュリティポリシー・メカニズム
セキュリティポリシー(security policy)システムがどのような動作を実行可能で、どの動作が禁止されているかを定める記述
セキュリティメカニズム(security mechanism)セキュリティポリシーを実現するための仕組み
暗号(encryption) : 機密性・完全性を実現
認証(authentication) : ユーザ・プロセスの身元確認
認可(authorization) : 動作実行の権限を確認
監査(auditing) : ユーザ・プロセスの行動を記録・監視
2
7
事例:Globusセキュリティアーキテクチャ
Globus [Chervenak et.al. 2000]
大規模分散計算を提供するシステム
多くのホスト・ファイル・リソースを同時に使用して計算を実行(計算グリッド(Computational Grid) [Foster & Kesselman 1998]
ユーザとリソースの数が膨大、かつ、異なる管理ドメインにわたって分散 セキュリティが不可欠
8
Globusのセキュリティポリシー
1. 環境は複数の管理ドメインから構成
2. ローカルオペレーションは局所ドメインセキュリティポリシーに従う
3. グローバルなオペレーションは、実行される各ドメインによってその起動者が公知である必要がある
4. 異なるドメインの動作実体間のオペレーションは、互いの認証が必要
5. グローバルな認証はローカルな認証で代替
6. リソースのアクセス制御はローカルセキュリティ制限に従う
7. ユーザはプロセスに権限を委譲可能
移動エージェントに対して
8. 同じドメインのプロセスグループは、信用証明書を共有可能
認証のスケーラビリティ達成のため
9
Globusセキュリティアーキテクチャ
目的:
・複数ドメインに跨る認証
・遠隔リソース割り当て
ユーザプロキシ:一定期間ユーザの代理で行動
リソースプロキシ:グローバルなオペレーションをローカルにマッピング
10
セキュリティの概要
セキュアシステムの定義
セキュリティ要求
セキュリティ脅威
セキュリティメカニズム
セキュリティポリシー
セキュリティシステムの設計要素
セキュリティプロトコル
暗号アルゴリズム
11
セキュリティシステムの設計要素:保護の対象
不正オペレーション自体から保護
許可されないアクセスから保護
許可されないユーザから保護
役割(role)ベースアクセス制御
12
セキュリティシステムの設計要素:セキュリティメカニズムの階層化
セキュリティメカニズムをOSI参照モデルのどの階層に置くか?
どの層をセキュアだと信用(trust)しているかに依存
下位層のセキュリティメカニズムを信用するならば、その層で保証しているセキュリティを上位層で実現する必要はない
3
13
セキュリティメカニズムの階層化:SMDS
データリンク層でのセキュリティメカニズムの例:交換型マルチメガビットデータサービス(Switched Multi-megabit Data Service:SMDS)
分散したLAN同士を結ぶセキュアなリンクを実現
SMDSルータ:暗号化装置を実装
LAN間の通信はセキュアだと信用できる
LAN内の通信に関しては無保証
14
セキュリティメカニズムの階層化:SSL
トランスポート層でのセキュリティメカニズムの例
セキュアソケット層(Secure Socket Layer:SSL)TCPによるセキュアなメッセージの送信をサポート
15
セキュリティメカニズムの階層化:ミドルウェア層
ミドルウェア層におけるセキュリティメカニズム
一般に、使用する下位層のセキュリティメカニズムの信用に依存
もしセキュアなRPCサービスがSSLを使用しているならば、SSLが本当にセキュアである場合に限り、そのサービスはセキュアである
16
セキュリティシステムの設計要素:セキュリティメカニズムの分散
信用コンピューティングベース(Trusted Computing Base:TCB)
セキュリティポリシーの実現のために必要なセキュリティメカニズムの集合
信用を依存している全てのセキュリティメカニズムの集合
セキュアRPCがSSL,SMDSなどを用いているならば、それらも含む
各ホスト上のOSの信用にも依存するかもしれない
TCBは小さいほど良い
どれか一つにセキュリティホールがあれば、全体の信用が失われる
分散システムをセキュアな部分とそれ以外に分ける
17
セキュリティメカニズムの分散
TCBを小さくする方法セキュリティサービスとそれ以外のサービスを分離
セキュアファイルサーバのみをセキュアなホスト上に置き、クライアントやアプリケーションサーバはそれ以外のホストに置くなど
セキュアなホストの保護セキュアシステムコンポーネント縮小インタフェース(Reduced Interfaces for Secure System Components:RISSC)
高セキュリティサーバは専用のセキュアなネットワークインタフェースを通してのみアクセス可能
18
セキュリティシステムの設計要素:簡潔さ
セキュリティメカニズムはできるだけ簡潔であることが望ましい
設計者が容易に理解できて、動作を信用できるように
設計ミスによるセキュリティホールの混入を防ぐ
4
19
セキュリティの概要
セキュアシステムの定義
セキュリティ要求
セキュリティ脅威
セキュリティメカニズム
セキュリティポリシー
セキュリティシステムの設計要素
セキュリティプロトコル
暗号アルゴリズム
20
暗号アルゴリズム
暗号技術:分散システムにおけるセキュリティの基本暗号化(encrypt), 復号化(decrypt)平文(plaintext), 暗号文(ciphertext)送信者、受信者、妨害者(intruder)3つのタイプの妨害
盗聴者=受動的な妨害者
21
暗号アルゴリズムの分類
対称鍵暗号(DESなど)同じ鍵で暗号化と復号化を行う
非対称鍵暗号(RSAなど)暗号化と復号化をそれぞれ別々の鍵で行う
公開鍵システム:片方を秘密にして片方を公開公開する鍵:公開鍵(public key)秘密にする鍵:秘密鍵(secret key)
( ( ))K KP D E P=
( ( ))D EK KP D E P=
22
暗号アルゴリズムの分類
ハッシュ関数(MD5,SHA-1など)任意の長さのメッセージmから固定長のビットストリングbを生成する関数H(m)=bハッシュ関数の性質
一方向関数(one-way function)mからbの計算は容易だが、bからmの計算は困難
弱抗衝突(weak collision resistance)m,b,Hが与えられたとき、H(m')=H(m)=bとなるm'を計算することが困難であること
強抗衝突(strong collision resistance)Hだけが与えられたとき、H(m)=H(m')となるm,m'を計算することが困難であること
23
分散システムにおけるセキュリティ
セキュリティの概要
セキュアチャネル認証
メッセージの完全性と機密性
セキュアグループ通信
アクセス制御一般的課題
ファイアウォール
セキュアなモバイルコード
セキュリティ管理鍵管理
セキュアグループ管理
認可管理
24
セキュアチャネル
通信の保護: 通信相手との間にセキュアな通信路(セキュアチャネル:secure channel)を確立することで実現
送信者と受信者を、メッセージの横取、改変、合成から保護
横取からの保護:機密性の保証により実現
改変、合成からの保護:相互認証とメッセージ完全性により実現
5
25
セキュアチャネル:認証
相互認証とメッセージ完全性どちらが欠けても役に立たない
メッセージは改竄されていないが、通信相手が違う
通信相手は正しいが、メッセージが改竄されている
セキュアチャネルの確立手順1.認証
正しい相手と通信していることを確認
共通鍵又は公開鍵を使用
2.実際の通信メッセージ完全性および機密性を保証
認証とは違う鍵(セッション鍵)を使用
セッションが存在している間のみ使用(使い捨て)
共通鍵を使うのが一般的(効率のため)26
セキュアチャネル:共通鍵による認証
チャレンジ応答プロトコル(challenge-response protocol)
認証したい相手にチャレンジメッセージを送信
相手はそれに対して応答相手が自分と同じ共通鍵KA,Bを持っているときに限り、チャレンジに対する応答は正しい
2. BobからAliceへのチャレンジRB
3. RBに対する応答
4. AliceからBobへのチャレンジRA 5. RAに対する応答
1. AliceからBobへ認証要求
27
セキュアチャネル:共通鍵による認証
認証プロトコルの設計課題
セキュリティに支障が無いように設計する必要
実際は困難
例) 前述のチャレンジ応答プロトコルを以下のように変更 問題はないか?
28
セキュアチャネル:共通鍵による認証
変更後のプロトコルでは、セキュリティが破られるリフレクション攻撃(reflection attack)と呼ばれる手法により、攻撃者ChuckがAliceに成りすましてBobとセキュアチャネ
ルを確立可能相手から受信したチャレンジと同じチャレンジを相手に対して行う
相手からのチャレンジに対する正しい応答を相手から入手
29
セキュアチャネル:鍵配送センターによる認証
共通秘密鍵による認証のスケーラビリティ問題
ユーザの数が増えると、必要な鍵の数が増大nユーザがお互いに認証するためには、n(n-1)/2個の秘密鍵が必要
解決法:鍵配送センター(KDC:Key Distribution Center)による集中管理
自分と通信相手との共通鍵を持つ代わりに、自分と(自分が信用する)KDCとの共通鍵を持つ
通信相手の認証はKDCが仲介
nユーザで必要な鍵の数はn個各ユーザとKDCとの共通鍵
30
セキュアチャネル:鍵配送センターによる認証
鍵配送センターによる単純な認証プロトコルAがBとのセキュアチャネルを確立したいとき、A,BはKDCにAとBとの共通鍵を(暗号化して)送ってもらう
欠点:Bが共通鍵を受け取る前に、Aがセキュアチャネルを確立してしまう可能性あり
Bが過去にAとの共通鍵を受け取っていれば、セキュアチャネルは確立される
その後でBがKDCから鍵を受信すると、Bは混乱
6
31
セキュアチャネル:鍵配送センターによる認証
KDCによる、より良い認証プロトコルKDCは、Bに共通鍵を渡す代わりに、Bに渡す分(チケット:ticket)を、Aの分と合わせてAに送信
Aは、Bとのセキュアチャネルを確立したいときに、チケットをBに転送
32
セキュアチャネル:鍵配送センターによる認証
Needham-Shroeder認証プロトコルチケットの受け渡しに加えて、チャレンジ応答による認証で安全性を高めたもの
チャレンジR :ノンス(nonce)と呼ばれる
一度しか使われないランダムな数 チャレンジとその応答を1対1対応させるため
暗号化されたチャレンジRに対してR-1で応答 実際にチャレンジを復号したことを証明
33
セキュアチャネル:鍵配送センターによる認証
Needham-Shroeder認証プロトコルの問題点
メッセージ3を傍受したCが、後でBに対してそれを再生(リプレイ攻撃:replay attack) Bは、CをAだと思ってセキュアチャネルを確立してしまう
34
セキュアチャネル:鍵配送センターによる認証
Needham-Shroeder認証プロトコルの改良版Aは、KDCからチケットをもらう前に、あらかじめBからチャレンジを受け取る(メッセージ2)
Aは、BからのチャレンジをKDCに転送(メッセージ3)
KDCはBのチャレンジを、Aに渡すチケットに組み込む(メッセージ4)
Aは、チャレンジが組み込まれたチケットをBに転送(メッセージ5)
チケットを渡すメッセージ5が、 初のチャレンジ(メッセージ2)に対応することを保証 メッセージ5が再生されてもBは検出可能
35
セキュアチャネル:公開鍵による認証
公開鍵による認証
KDCは不要
鍵の数=ユーザの数
36
セキュアチャネル:公開鍵による認証
公開鍵による相互認証プロトコルAは、Bの公開鍵で暗号化したチャレンジをBに送信
Bは、Aからのチャレンジに対する応答、Bが生成した共通鍵、および、BからAへのチャレンジを、Aの公開鍵で暗号化してAに送信
Aは、Bからのチャレンジに対する応答を、共通鍵で暗号化して送信
7
37
セキュアチャネル:メッセージの完全性と機密性
メッセージの完全性
メッセージが改竄されないことの保証
デジタル署名によって達成
メッセージの機密性
メッセージの内容が第三者に漏洩しないことの保証
セッション鍵による暗号化により達成
38
セキュアチャネル:メッセージの完全性:デジタル署名
デジタル署名
メッセージ内容と一意に関連
メッセージ作成者でないと作成不可能
実現法
公開鍵暗号法を利用
メッセージダイジェストを利用
39
デジタル署名:公開鍵暗号法による実現
公開鍵暗号法によるデジタル署名AliceがBobにメッセージmを送る場合
mをAliceの秘密鍵で暗号化したものをデジタル署名としてmに付加
Bobはmのデジタル署名がAliceのものであることを検証可能
Aliceの公開鍵でデジタル署名を復号化し、本文mと比較
問題点デジタル署名作成・検証のコストが大きい
40
メッセージダイジェスト
メッセージダイジェスト(message digest)ハッシュ関数Hを用いて、任意長のメッセージmから、固定長のビットストリングhを計算したもの
mがm'に変化すると、H(m')はH(m)と全く異なる値になるメッセージの改竄を容易に検出任意長から固定長への写像なので、厳密にはH(m)=H(m')なるmと異なるm'が存在 ハッシュ関数の弱抗衝突性よりそのようなm'の計算は困難
41
デジタル署名:メッセージダイジェストによる実現
メッセージダイジェストによるデジタル署名Aliceはメッセージmに、メッセージダイジェストh=H(m)をデジタル署名として付加
ただし、hはAliceの秘密鍵で暗号化 (メッセージダイジェスト自体の改竄を防止) hのサイズは小さい固定長なので、暗号化のコストは小さい
mとデジタル署名を受信したBobは、hをAliceの公開鍵で復号化し、H(m)を計算してhと比較
42
セキュアチャネル:メッセージの機密性:セッション鍵
セッション鍵(session key)認証フェーズ終了後、実際の通信で使用される鍵
メッセージの機密性保証
認証で使用した鍵と異なるものを使用した方が良い鍵は、頻繁に使用されるほど安全性が低下(鍵の「磨耗」)
傍受者がより多く傍受 鍵の特徴を利用した攻撃や、鍵そのもの推測が可能に
認証用の鍵の使用頻度は小さい方が良い
認証用の鍵は頻繁に変更するのは大変 コストが大きく破られにくい暗号化法を使用
セッション鍵自体も、セッション毎に異なる方が良いリプレイ攻撃などから守るため
使い捨ての鍵であれば、よりコストの小さい暗号化法が使用可能
たとえ破られても、影響範囲はそのセッションのみ
8
43
分散システムにおけるセキュリティ
セキュリティの概要
セキュアチャネル認証
メッセージの完全性と機密性
セキュアグループ通信
アクセス制御一般的課題
ファイアウォール
セキュアなモバイルコード
セキュリティ管理鍵管理
セキュアグループ管理
認可管理
44
セキュアなモバイルコード
モバイルコードのセキュリティ問題
移動エージェントが運ぶ情報が盗まれたり、改変されることを防ぎたい
エージェントを受け入れるホストを、悪意あるエージェントから守りたい
45
エージェントの保護
エージェントが運ぶ情報やエージェント自身の破壊・改変からの保護
完全な保護は不可能 [Famer他,1996]改変の検出は可能
Ajantaシステム[Karnik and Tripathi 2001]
46
Ajantaシステムにおけるエージェント
3つのメカニズムでエージェントを保護
読み出し専用状態
エージェントの状態(メモリ)のうち、変更されない領域エージェント所有者の秘密鍵で署名 改変を検出可能
追加専用ログ
状態の選択的公開
47
Ajantaシステムにおけるエージェント
3つのメカニズムでエージェントを保護読み出し専用状態
追加専用ログエージェントが集める情報を蓄積する領域(追加のみ可能)
初はログは空であり、所有者の公開鍵で計算された初期チェックサムを持つ
サーバSでデータXがログに追加されるとき、エージェントは、ログの古いチェックサムと、XのサーバSによる署名、およびサーバSのIDから、新しいチェックサムを所有者の公開鍵で計算
エージェントが所有者に戻ったとき、所有者は、自分の秘密鍵を用いて、現在のチェックサムを逆順に遡りながらログを検証 矛盾無く初期チェックサムまでたどり着けば、改変が無いことがわかる
状態の選択的公開
48
Ajantaシステムにおけるエージェント
3つのメカニズムでエージェントを保護
読み出し専用状態
追加専用ログ
状態の選択的公開
各項目がそれぞれ特定のサーバのために用意されたデータ項目の配列
各項目は指定されたサーバの公開鍵で暗号化 指定されたサー
バ以外からの機密性を保証
項目全体は所有者の公開鍵で暗号化 データ全体の完全性を
保証
9
49
移動先ホストの保護
悪意あるエージェントからの移動先ホストの保護
サンドボックス(sand box)ダウンロードされたプログラムの各命令を完全に制御された形で実行するメカニズム
ホストが禁止した命令を実行しようとすれば、直ちに停止させることが可能
実装方法ダウンロード時に、コードに実行時チェックのための追加命令を挿入[Wahbe他, 1993]Javaなど、中間コードを仮想マシン上で実行する場合、仮想マシンによってチェック (Javaサンドボックス)
50
Javaサンドボックス
Javaサンドボックスの構成要素
プログラムを転送するモジュール(クラスローダ)の保護
指定されたクラスローダ以外は使わないように制限
Javaでは一般にクラスローダ自身を外部からダウンロードすることが可能なので
51
Javaサンドボックス
Javaサンドボックスの構成要素
バイトコード検証(クラスベリファイヤ)ダウンロードされたプログラムバイトコード(クラス)がサンドボックスのセキュリティ規則に従うかチェック
例)メモリやスタックを破壊する命令を含まないことをチェック
52
Javaサンドボックス
Javaサンドボックスの構成要素
実行時のリソースアクセス制御(セキュリティマネージャ)任意の入出力動作をチェック
不正な動作の実行を禁止
53
プレイグラウンド
プレイグラウンド[Malkhi and Reiter, 2000]モバイルコードを実行するための、周囲から分離されたホスト
サンドボックスの制限を緩和
プレイグラウンド内であれば、任意のアクセスが可能
54
演習問題
1. RISSC手法では、すべてのセキュリティをセキュアサーバに集中することができるか?
2. あなたが先生に授業の試験を実施する分散アプリケーションを開発するように頼まれたと仮定する。そのようなアプリケーションに対するセキュリティポリシーを少なくとも3つ考えよ。
3. スライド番号26の図(教科書図8-12)において示されている認証プロトコルにおいて、メッセージ3とメッセージ4を連結してKA,B(RB,RA)としても安全か?
4. Needham-Shroeder認証プロトコルのメッセージ2において、AliceとKDCの間
で共有された秘密鍵でチケットが暗号化されている。この暗号化は必要か?
5. AliceがメッセージmをBobに送りたがっていると仮定する。Bobの公開鍵KB+
でmを暗号化する代わりに、Aliceはセッション鍵KA,Bを作り、[KA,B(m),KB
+(KA,B)] を送る。この方法が一般的にはよりよいのはなぜか。(ヒント:性能面を考慮せよ)