...

配布資料版

by user

on
Category: Documents
7

views

Report

Comments

Transcript

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