「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- これらの要素は認可（≒ アクセス制御）
を行う一連のプロセスに含まれる。
※ 基礎が参考になる。
認証 †
基礎 †
用語 †
- 真正性(Authenticity)を明らかにする行為が認証(Authentication)
- 認証(Authentication)のプロセスは、識別(Identification)と検証(Verification)で構成される。
- 識別(Identification)と検証(Verification)をざっくり説明すると、以下の様な感じ。
- 識別(Identification) ≒ ユーザID
- 検証(Verification) ≒ パスワード
- 認可(Authorization)と許可(Permission)
- 認可(Authorization)
認証(Authentication)の結果を用いて、アクセス制御を行う。
コレには、下記のリソースに付与された許可(Permission)の情報も使用している。
- 許可(Permission)
原則禁止のトコロ、許可する事を言うらしいが、
コンピューター界隈では、リソースに付与されている属性を指す。
- Authentication
前述の認証で、2者間認証とも言う。
- Certification
監査やデジタル署名で、3者間認証とも言う。
- Authentication
前述の認証(Authentication)
- Identification
前述の識別(Identification)
- 「認証」の意味を考える - Manaboo 電子政府・電子申請コラム
分類 †
- 対象
- 人の認証：各種本人認証手段による
- モノの認証：MACアドレスなど
- 情報の認証：デジタル署名など
- 各種本人認証手段
詳しくはコチラ
- ユーザが知っていること（知識情報）
- ユーザが持っているもの（所持情報）
- ユーザ自身の特徴（生体情報）
固定式パスワード †
特徴 †
- ちなみに、以下の条件で
作成可能なパスワードの総数 = M^n らしい。
- 使用可能な文字種 = M
- 使用可能な文字数 = n
脆弱性 †
ワンタイム・パスワード(OTP) †
特徴 †
方式 †
脆弱性 †
ICカードによる認証 †
特徴 †
- 高い耐タンパ製
- 反面、紛失盗難に弱いので、
生体認証と組合わせる方式がある。
利用例 †
- 公開鍵で、情報と暗号鍵を暗号化
- ICカード内の秘密鍵で、暗号化された暗号鍵を復号化
- 復号化した暗号鍵を使用して暗号化された情報を復号化
- デジタル署名
- 秘密鍵で、情報にデジタル署名を付与
- 公開鍵で、送られてきたICカードの情報を検証
攻撃 / 対策 / 評価 †
- 攻撃手段
| # | 種類 | 手法 | 内容 |
| 1 | 破壊攻撃 | ICチップに直接アクセス、高コスト |
| -1 | プロービング | | ICチップに針を当て信号を読み取る。 |
| -2 | リバース・エンジニアリング | ICチップの観察（秘密鍵は漏れないがメカニズムが解明される。） |
| 2 | 非破壊攻撃（サイドチャネル攻撃） | 外部から観察、低コスト |
| -1 | DPA（Differential Power Analysis） | | 多数の消費電力波形を統計処理して秘密鍵を推定する。 |
| -2 | SPA（Simple Power Analysis） | 消費電力波形を比較解析して秘密鍵を推定 |
| -3 | グリッチ（glitch） | flip-flopのサンプリングや誤動作を起こし出力の比較解析して秘密鍵を推定する。 |
| -4 | 光照射 | 不良動作を発生させる攻撃 |
| -5 | タイミング攻撃 | 時間差を測定することで秘密鍵を推定する。 |
| # | 種類 | 手法 | 内容 |
| 1 | 破壊攻撃 | ICチップに直接アクセス、高コスト |
| -1 | 配線の多層化 | 上層の剥ぎ取りで下層のICチップが破壊されるようにする |
| -2 | テスト回路の削除 | 出荷後、テスト回路を使用不可能な状態にする。 |
| 2 | 非破壊攻撃（サイドチャネル攻撃） | 外部から観察、低コスト |
| -1 | センサ | センサにより使用範囲外の動作環境で動作しなくする。 |
| -2 | 動作クロックの内部生成 | アタック・タイミングの同期を困難にする |
| -3 | メモリ・チェック機構 | グリッチによるflip-flopやメモリ値の破壊を検出する。 |
| -4 | 暗号化アルゴリズムの工夫 | 同一演算の時間が異なるようにする |
- 評価
JIWG(Joint Interpretation library Working Group)が行っている。
- ICカード評価の公平性、客観性の実現する活動
- Common Criteria（ISO/IEC 15408）の解釈の統一
シングルサインオン（SSO） †
- 認証基盤がクッキー認証チケットを発行する。
- エージェント型とリバース・プロキシ型がある。
- クロスドメインでのSSOを実現する
- エージェント型とリバース・プロキシ型、ライブラリ型がある。
その他さまざまな技術 †
RADIUS †
- RADIUS : Remote Authentication Dial In User Service（ラディウス）
- IP上で認証とアカウンティングを実現する
プロトコルと、それを実装したサーバ
- 目的
- ネットワーク資源の利用の可否の判断（認証）と、利用の事実の記録を、
- ネットワーク上のRAS（Remote Access Server）と分離して一元化する。
- 利用
- 元はダイヤルアップ・インターネット接続を目的として開発されたが、
- 昨今は、インターネット接続サービス、無線LANなどで幅広く利用されている。
- 脆弱性
何れもプロトコル自体の脆弱性ではなくベンダの実装の問題に起因
- メッセージダイジェストに対するBOF攻撃
- Vendor-Lengthを2以下に設定したDoS攻撃
TACACS/TACACS+ †
- TACACS : Terminal Access Controller Access Control System（タカクス）
- 目的
RADIUSとほぼ同様だが、以下の３機能（AAA）をサポート。
- 認証（AuthN）
- 認可（AuthZ）
- 課金（Accounting）
- PPP（ISP接続で使用）を強化したのがEAP（WiFi?の接続で使用）
- IEEE802.1X（有線LANや無線LANにおけるユーザ認証の規格）を構成する。
| Authentication層 | TLS | MD5 | S/Key | その他 |
| ↕ | ↕ | ↕ | ↕ |
| EAP層 | EAP |
| ↕ | ↕ |
| ↕ | EAPOL |
| ↕ | ↕ | ↕ | ↕ |
| Datalink層 | PPP | IEEE802.3（イーサネット） | IEEE802.5（トークンリング） | IEEE802.11x（無線） |
| # | 名称 | 概要 | サーバ認証 | クライアント認証 | 無線LANでの安全性 |
| 証明書 | 証明書 | その他 |
| 1 | EPA-TLS | TLSによる相互認証 | 〇 | 〇 | × | 〇 |
| 2 | EPA-TTLS | TLS暗号化通信中でクライアント認証 | 〇 | オプション | 選択可 | 〇 |
| 3 | PEPA | EPA-TTLSとほぼ同じ | 〇 | オプション | 選択可（EAP準拠の方式のみ） | 〇 |
| 4 | EPA-TLS | TLSによる相互認証 | 〇 | 〇 | × | 〇 |
| 5 | EPA-MD5 | 無線LANに不向き（有線LAN向き） | × | × | MD5のチャレンジ＆レスポンス | × |
認可（アクセス制御） †
基礎 †
以下から構成される。
- リソースに与えられた、
利用者、若しくは利用者属性に対応する認可情報（パーミッション）
- 読み、書き、実行などの権限がある。
- これは、アクセス制御リスト（ACL）と呼ばれる。
実施 †
以下、アクセス制御が実施される場所
物理環境 †
コンピューター・システム的なものではなく、
環境的・物理的な、セキュリティ。
ネットワーク環境 †
ネットワーク機器やF/Wなどで制御できる範囲でのアクセス制御
ホストやアプリケーション †
ホストやアプリケーションに対するログインとアクセス制御
システム・リソース †
主に、OSの機能で実現されている。
種類 †
任意（DAC） †
強制（MAC） †
- MAC : Mandatory Access Control
- セキュアOSなどに実装がある。
- 所有者ではなくシステムが決定するアクセス方針
（サブジェクトやオブジェクトを複数のレベルにクラス分けする）
ロールベース（RBAC） †
情報フロー制御 †
- 情報の流れを分析して情報が、
上位から下位に移動しないように制御する方式
- MLSやBLPモデルで制御される。
- MLS : Multi Level Security
- 前述の強制（MAC）で利用される。
- MLSを数学的に定式化した状態遷移モデルがBLP（Bell–LaPadula? Model）
- MLSによるアクセス制御ルール例
| ユーザの機密レベル | 情報の機密レベル | 関係 | アクセス制御ルール |
| 読取 | 追記 | 修正 | 実行 |
| 極秘 | 極秘 | ユーザ＝情報 | 〇 | 〇 | 〇 | 〇 |
| 秘 | ユーザ＞情報 | 〇 | × | × | 〇 |
| 一般 |
| 秘 | 極秘 | ユーザ＜情報 | × | 〇 | × | × |
| 秘 | ユーザ＝情報 | 〇 | 〇 | 〇 | 〇 |
| 一般 | ユーザ＞情報 | 〇 | × | × | 〇 |
| 一般 | 極秘 | ユーザ＜情報 | × | 〇 | × | × |
| 秘 |
| 一般 | ユーザ＞情報 | 〇 | 〇 | 〇 | 〇 |
- 説明
ユーザと情報の関係ですべて決まる。
- ユーザ＞情報：読取・実行のみ許可（参照）
- ユーザ＝情報：更新含め全て許可（当事者）
- ユーザ＜情報：追記のみ許可（報告）
実施 †
ある意味、PDCA的ではある。
(P) : 方針の明確化 †
方針＝アクセス制御のルール
(D1) : 実装の明確化 †
上記の方針をどのような技術で実装するか？
(D2) : 実装 †
実装の明確化≒仕様で、これを実装。
(C) : 適切性評価 †
方針や実装を評価し、
(A) : 見直し †
方針や実装を見直す。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
