情報セキュリティ技術動向調査 - ipa.go.jp · web api...
TRANSCRIPT
情報セキュリティ技術動向調査 タスクグループ報告書
（2010 年上期）
2010 年 9 月
ii
目次 序 2010年上期の技術動向 - 今日のセキュリティエンジニアリングの話題......................1 1. 楕円曲線暗号の整備動向 ..................................................................................................3 2. MACsecによるレイヤ 2暗号化......................................................................................10 3. DNSSECの動向..............................................................................................................17 4. CA/Browserフォーラムの日本開催 ...............................................................................22 5. User Managed Access ....................................................................................................26 6. IPv6ネットワークにおけるローカルネットワークの保護 ............................................33 7. Gumblar攻撃に対する技術の現状と課題 ......................................................................40 8. QubesOS .........................................................................................................................46
1
序 2010年上期の技術動向 - 今日のセキュリティエンジニアリングの話題
宮川 寧夫 1. 背景
「情報セキュリティ技術動向調査 TG（タスクグループ）」1は、その第 5 回目の会合を2010年 6月 30日に開催した。情報セキュリティのエンジニアリングの分野において注目すべき動向を発表しあい、発表内容に基づいて討議した。この討議を踏まえて、注目すべ
き話題を各委員独自の視点から紹介・解説していただいて本報告書を取りまとめた。 2. 目的
本書は、読者として主に情報処理技術者を想定している。情報技術のアーリー・アドプ
ター（Early Adopters）およびアーリー・マジョリティ（Early Majority）[1] と呼ばれるような先進的な技術に関心を寄せる読者に、想定されている用途に関する情報を添えて
提供する。これによって、各自もしくは各組織における情報セキュリティに関するエンジ
ニアリングの課題の解決に資するものとしたい。 先進的な技術を題材とするため特定の実装を紹介することがあるが、オープンな仕様が
存在している場合、主に、その仕様に基づく解説を行うように留意している。 3. 概況
今回、楕円曲線暗号を利用する仕様の整備動向を採りあげた。今日、広く利用されてい
る公開鍵暗号技術のほとんどは RSA 暗号方式であると言っても過言ではないが、標準化されている公開鍵暗号の方式は他にも存在している。 クラウド環境の整備に関して、データセンター内等において配備されつつある「MACsec
によるレイヤ 2における暗号化技術」を紹介する。 インターネットインフラストラクチャについての話題として、今期も前期（2009年下期）
に引き続いて「DNSSECの動向」を採りあげた。今期、DNSSECがルートゾーンに導入された経緯について解説する。 今期、国内で「CA/Browserフォーラム」の会合が開催された。これは、過去に 20回、
開催されている PKI技術についての会合である。 インターネット上におけるアイデンティティ管理関連技術の分野では、2009年上期に、
Web APIへのアクセス認可を扱う OAuthの仕様を、Coreバージョン 1.0を中心に採りあげた。今回は OAuth 2.0プロトコル仕様を踏まえて策定が進むUser Managed Accessを採りあげる。 ネットワーク構築技術の話題として、IPv4では一般化しているNAT/NAPT（Network
1 http://www.ipa.go.jp/security/outline/committee/isec_tech1.html
2
Address Translation/Network Address Port Translation）機能と IPv6の関係をめぐる話題を採りあげた。
Gumblar 攻撃については前期（2009 年下期）にも採りあげたが、その一連の攻撃に対するネットワーク構築技術として、今回は、セキュアなコンテンツファイルアップロード
と、出方向のパケットフィルタリングについて紹介する。 マルウェア対策に資する話題として、QubesOSは、オペレーティングシステム（以下、
OS）レベルでデスクトップアプリケーションが扱うデータのセキュリティを確保する実装であるが、Deposal VM（使い捨て VM）も実装予定である。 参考文献
[1] ジェフリー･ムーア（著），川又 政治（訳），「ハイテク・マーケティング」『キャズム』， 翔泳社（2002）pp. 11-38
－ 3 －
1. 楕円曲線暗号の整備動向
金岡 晃 1.楕円曲線暗号整備の背景
現在利用されている公開鍵暗号のほとんどは RSA 暗号方式であると言っても過言ではないが、標準化がされている公開鍵暗号の方式は他にも存在する。特に楕円曲線暗号（ECC）は同レベルの強度を持つRSA暗号と比較して鍵長が短いことに加え処理の速さも特徴となっていることからポスト RSA暗号として注目を浴びている。 ECCは単一の暗号アルゴリズムではなく、楕円曲線上の離散対数問題を安全性の根拠とする暗号方式の総称である。そこには、楕円曲線上で Diffie-Hellman（DH）鍵共有を行うECDHや楕円曲線上で Digital Signature Algorithm（DSA）を実現する ECDSA、楕円曲線上でMenezes–Qu–Vanstone（MQV）方式を実現する ECMQVなどが含まれる。 2005 年、米国国家安全保障局（NSA）は機密情報の保護のために用いる暗号アルゴリズムのリストである Suite B[1]を発表した。Suite Bでは暗号化と鍵交換、電子署名、ハッシュ関数のアルゴリズムがそれぞれ定められているが、その鍵交換と電子署名のアルゴリズ
ムに RSA暗号はリストに入っておらず、鍵交換には ECDH、電子署名には ECDSAが指定されていた。このことは ECC をポスト RSA 暗号としてさらに強く注目を浴びせることとなった。
暗号化 128ビットまたは 256ビット鍵の AES
鍵交換 P-256曲線または P-384曲線を使った ECDH
電子署名 P-256曲線または P-384曲線を使った ECDSA
ハッシュ関数 SHA-256または SHA-384
その後、RFC 4869[2]、5008[3]、5430[4]といった Suite Bに合わせた仕様も策定され、また NSA 自身から ECDH 版の Suite B の実装ガイド[5]も公開されてくるなど、Suite Bや ECCの仕様整備が進んできた。 2.今期の動向
2010 年上期では、NSA が Suite B の実装ガイドの ECDSA 版である「Suite B Implementer's Guide to FIPS 186-3 (ECDSA)」[6]を 2月に公開し、また ECC関連としては 3つの新規 RFCと 3つの RFCの改訂または更新があった。
－ 4 －
3. NSA Suite B Implementer's Guide to FIPS 186-3 (ECDSA)
2010年 2月に発行された「NSA Suite B Implementer's Guide to FIPS 186-3 (ECDSA)」[6]は Suite Bに含まれている ECDSAの実装ガイドである。ECDSA自身は NISTの FIPS 186-3[13]で定められているものであるが、FIPS 186-3は電子署名方式についての標準であり、DSA（Disital Signature Algorithm）、RSA署名、ECDSAが定められており、ECDSAだけを定めたものではない。また、暗号アルゴリズムそのものは ANSIの X9.62 で定められているなどFIPS 186-3を読むだけではECDSAの実装は困難なことから作成されたと考えられる。 ガイドは用語定義や略称についての解説、ECDSA のドメインパラメータ、鍵ペアの生成と検証、管理方法、署名の生成と検証方法などが示されている。また Appendixでは鍵ペア生成と検証の詳細と、逆元の計算法や整数からビット列データへの変換法、そして利用さ
れる曲線についての詳細が記載されている。 FIPS 186-3でも、ECDSAで利用が推奨される楕円曲線が 15種類示されている。しかしこのうち Suite Bで規定されているのは P-256と P-384の 2種類のみであり、ガイド中のAppendixでは P-256と P-384のパラメータのみ記載がされている。
RFC 5759 「Suite B Certificate and Certificate Revocation List (CRL) Profile」[7]
2010年 1月
RFC 5639 「Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation」[8]
2010年 3月
新規 RFC
RFC 5915 「Elliptic Curve Private Key Structure」[9]
2010年 6月
RFC 5753 「Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) 」[10]
2010年 1月
RFC 5758 「 Internet X.509 Public Key Infrastructure:Additional Algorithms and Identifiers for DSA and ECDSA 」[11]
2010年 1月
更新・改訂
RFC
RFC 5903 「Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2」[12]
2010年 6月
－ 5 －
P-192
P-224
P-256
P-384
P-521
B-163
B-233
B-283
B-409
B-571
K-163
K-233
K-283
K-409
K-571
4. IETFでの関連仕様（RFC）
4.1 新規 RFC
RFC 5639 「Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation」 Brainpool による楕円曲線群の仕様。Brainpool の楕円曲線群は電子パスポートePassportで利用可能な楕円曲線群である。
RFC 5759 「Suite B Certificate and Certificate Revocation List (CRL) Profile」
Suite B対応の X.509v3証明書プロファイルと X.509v2 CRLプロファイルを定めた仕様。
RFC 5915 「Elliptic Curve Private Key Structure」
－ 6 －
楕円曲線暗号の Private鍵フォーマットが ASN.1で規定されている。 4.2 更新・改訂 RFC
RFC 5753 「Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) 」 RFC 3278の改訂。CMS での ECCの利用についての仕様。参照仕様の変更と利用可能ハッシュ関数の拡大（SHA2対応）がされている。
RFC 5758 「Internet X.509 Public Key Infrastructure:Additional Algorithms and
Identifiers for DSA and ECDSA」 RFC 3279の更新。SHA-224, SHA-256, SHA-384, SHA-512を使った DSAと ECDSAのアルゴリズムの OID（Object IDentifier）
RFC 5903 「Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and
IKEv2」 RFC 4753の改訂。IPsecで利用される IKEと IKEv2用の楕円曲線群についての仕様。誤記の修正がされている。
5．ECCを使った公開鍵証明書の利用環境調査
ECCに関連する仕様は多く策定されているが、実際に現在の環境でどれほどが利用可能であるかを調査した。調査は「鍵生成・証明書発行」と「証明書の利用」のふたつを行った。 5.1 鍵生成・証明書発行
暗号や公開鍵証明書を扱うときに広く使われる OpenSSL と Windows の CNG（Cryptography Next Generation）における ECC鍵ペアの生成と証明書の発行について調査した。 OpenSSLではバージョン 0.9.8より ECC の利用が可能である。OpenSSLは多くの楕円曲線に対応しており、OpenSSL 1.0.0aでは 67種類の曲線が利用可能である。楕円暗号で利用される曲線については多くのものが存在するが、NIST では FIPS 186-3 において 15種類の曲線を推奨している。NIST 推奨曲線と OpenSSL での曲線の名称の対応表はAppendixに示す。 OpenSSL ではすべての曲線において鍵ペアの生成は可能であるが、証明書発行要求（CSR）の作成は Oakley-EC2N-4, Oakley-EC2N-3の 2種類において生成が失敗する。また 65種類のCSRについて、OpenSSLではすべての要求に対して証明書の発行に成功した。 CNGでは、NIST推奨曲線のうち P-256、P-384、P-521に対応しているとされている。
－ 7 －
CNG が実装されている Windows Server 2008 を使った実験では、CA（Certificate Authority）鍵として ECCを選択し鍵生成・証明書発行は可能であったが、証明機関のWeb登録サポートを利用してWebサーバ証明書などのクライアント鍵生成と証明書発行要求を行う場合、ECC鍵を利用可能なプロバイダ（CSP）は選択肢にはあらわれない。 一方、OpenSSLを利用して作成した CSRを用いてWindows Server 2008に対して発行要求を行う場合では、P-256 曲線（OpenSSL における prime256v1）、P-384 曲線（同secp384r1）、P-521曲線（同 secp521r1）の 3種類が証明書発行可能であった。 5.2 証明書の利用
代表的なWebサーバソフトウェアとブラウザにおけるECC証明書の利用についても調査を行った。 Webサーバソフトウェアでは Apache HTTP Serverの 2.3.6-alphaと OpenSSL 1.0.0a、
Microsoft IIS 7.0、OpenSSL 1.0.0aの s_serverを利用した。ブラウザはMicrosoft Windows Vista上でMicrosoft Internet Explorer 8、Mozilla Firefox 3、Google Chrome 5、Opera 10、Apple Safari 5を利用した。 調査は各Webサーバソフトウェアに ECC証明書を設定して起動を確認し、その後各ブラウザでアクセスを行った。 Apache HTTP Serverではどの種類の曲線も起動時にエラーが発生し起動しなかった。バージョン 2.2 系列では ECC の対応がされておらず、2.3 系列より対応がされるとされているが現在 2.3系列は安定版のリリースはされておらず、Alpha版のみのリリースとなっており、不安定な部分も多いことから今後改善がされていくものと考えられる。 Microsoft IISでは OpenSSLで作成した CSRを用いて、prime256v1（P-256)、secp384r1 （P-384)、secp521r1(P-521)曲線で発行された証明書を利用して起動が成功した。またOpenSSLの s_serverコマンドでは OpenSSLで発行した 65種類の証明書すべてで起動が成功した。 ブラウザの利用においては、prime256v1, secp384r1, secp521r1曲線による証明書をつかった IISサーバへのアクセスは Opera以外で成功した。Operaはブラウザで利用可能な暗号スイートに ECCが含まれていないために接続ができなかったものと考えられる。 またOpenSSLで作成した 65種類の証明書で起動した s_serverへのアクセスでは、Operaは同様にすべての証明書でアクセスが失敗した。Ineternet Explorer、Chrome、Safariでは prime256v1, secp384r1, secp521r1曲線による証明書の場合のみアクセスに成功した。また Firefoxは、IISサーバアクセス時では prime256v1, secp384r1, secp521r1曲線による証明書を用いた場合のアクセスに成功していたが、s_server の場合、これらの曲線でもアクセスに失敗した。
－ 8 －
6. まとめ
ECC に関連する仕様は整備されつつあり実装面でもその整備が進みつつあるが、まだ利用するにあたってはいくつかの困難が残っている。ECC で利用する楕円曲線の選択においては、NIST推奨曲線が 15種類、OpenSSLで利用可能な曲線が 67種類と多くの種類が存在するが、Windows CNSで利用可能な曲線は 3種類（P-256、P-384、P-521）、また Suite Bで定められている曲線は 2種類（P-256、P-384）であることから、今後は P-256と P-384の 2つの曲線が中心的に利用されていくことが予想される。
以上 Appendix OpenSSLの曲線名と NIST推奨曲線名の対応
下記の表は RFC 4492[13]の Table.6を基に作成した。
OpenSSL NIST推奨曲線名
sect163k1 K-163
sect163r2 B-163
sect233k1 K-233
sect233r1 B-233
sect283k1 K-283
sect238r1 B-283
sect409k1 K-409
sect409r1 B-409
sect571k1 K-571
sect571r1 B-571
prime192v1 P-192
secp224r1 P-224
prime256v1 P-256
－ 9 －
secp384r1 P-384
secp521r1 P-521
参考文献
[1] NSA Suite B Cryptography http://www.nsa.gov/ia/programs/suiteb_cryptography/ [2] RFC 4869: Suite B Cryptographic Suites for IPsec,
http://www.rfc-editor.org/rfc/rfc4869.txt [3] RFC 5008: Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) ,
http://www.rfc-editor.org/rfc/rfc5008.txt [4] RFC 5430: Suite B Profile for Transport Layer Security (TLS),
http://www.rfc-editor.org/rfc/rfc5430.txt [5] NSA Suite B Implementers' Guide to NIST SP 800-56A,
http://www.nsa.gov/ia/_files/SuiteB_Implementer_G-113808.pdf [6] NSA Suite B Implementer's Guide to FIPS 186-3 (ECDSA)
http://www.nsa.gov/ia/_files/ecdsa.pdf [7] RFC 5759: Suite B Certificate and Certificate Revocation List (CRL) Profile,
http://www.rfc-editor.org/rfc/rfc5759.txt [8] RFC 5639: Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and
Curve Generation, http://www.rfc-editor.org/rfc/rfc5639.txt [9] RFC 5915: Elliptic Curve Private Key Structure,
http://www.rfc-editor.org/rfc/rfc5915.txt [10] RFC 5753: Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic
Message Syntax (CMS), http://www.rfc-editor.org/rfc/rfc5753.txt [11] RFC 5758: Internet X.509 Public Key Infrastructure:Additional Algorithms and
Identifiers for DSA and ECDSA, http://www.rfc-editor.org/rfc/rfc5758.txt [12] RFC 5903: Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2,
http://www.rfc-editor.org/rfc/rfc5903.txt [13] RFC4492: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS), http://www.rfc-editor.org/rfc/rfc4492.txt
－ 10 －
2. MACsecによるレイヤ 2暗号化
馬場 達也 1. はじめに
近年、ソフトウェアやハードウェアなどのリソースをネットワーク経由で利用する形態
である「クラウドコンピューティング」が流行っている。しかし、クラウドコンピューテ
ィングをビジネスに適用しようとした場合に、セキュリティの問題が指摘されてきている。
このセキュリティを確保するために、データセンタ用機器において、レイヤ 2レベルでメッセージの暗号化および認証を行うMACsec（Media Access Control Security Protocol）の実装が進んでいる。本報告では、このMACsecの概要とクラウド環境におけるセキュリティについて考察する。 2. MACsecとは
MACsecは、暗号鍵インフラを用いて、イーサネットなどのレイヤ 2プロトコルで流れている「フレーム」を暗号化するための技術である。IPsec（IP Security Protocol）や SSL（Secure Sockets Layer）/TLS（Transport Layer Security）などと異なり、レイヤ 2レベルで暗号化されるため、スイッチやルータ、ファイアウォール、IPS（Intrusion Prevention System）などの中間ノードでのインスペクションが可能となる点が大きく異なる。
3. MACsecに関する仕様
MACsecに関する仕様は、以下のふたつがある。MACsec本体の標準化は 2006年に完了しているが、鍵管理プロトコルの仕様が長くドラフトのままであった。しかし、2010年 2月に標準化承認が下り、MACsecの標準化が実質的に完了した。
IEEE 802.1AE-2006 “Media Access Control (MAC) Security”
MACsec本体の仕様であり、2006年 6月に標準化承認されている。
IEEE 802.1X-2010 “Local and Metropolitan Area Networks - Port-Based Network Access Control”
IEEE 802.1X-2004 （EAPOL：EAP over LAN）に、MACsecのサポートと、MACsecの鍵交換プロトコルの仕様として検討されていた IEEE P802.1afの内容をマージしたもの。2010年 2月に標準化承認されている。
－ 11 －
4. MACsecの提供機能
MACsecでは、以下のセキュリティ機能を提供するように設計されている。IPsecとの違いは表 1の通りである。
コネクションレスデータ完全性確保 - MACフレームに付加される ICV（Integrity Check Value）をチェックすることにより、フレームの内容が途中で改ざんされていないことを確認することが
可能となる。 データ送信元の認証
- ICVをチェックすることにより、データ送信元が正しい共通鍵を保持している、正当な相手であることを確認することが可能となる。この共通鍵は、鍵交換プ
ロトコルによって、相手認証を行ったうえで共有される。 データの機密性確保
- 共通鍵暗号によって、MACフレームのデータ部が暗号化される。京津鍵暗号で使用される共通鍵は、鍵交換プロトコルによって、相手認証を行ったうえで
共有される。 リプレイ防御
- MACフレームに付加される Packet Numberフィールドに、ユニークな IDを埋め込むことにより、同じ IDを持ったMACフレームを受信することを防止することが可能となる。これにより、悪意を持った者が、ネットワーク上を流
れているMACフレームをコピーして、再度送信するという「リプレイ攻撃」から防御することが可能となる。
受信遅延制限（Bounded receive delay） - MACフレームを受信する間隔を設定することにより、不自然に遅れたMACフレームの受信を拒否することが可能となる。
サービス妨害攻撃からの防御 - 上記の仕組みにより、ある一定のサービス妨害攻撃から防御することが可能と
なる。 ※ 送信否認やトラフィック分析に対する保護は提供しない
－ 12 －
表１ IPsecとMACsecの比較 IPsec MACsec
暗号化範囲 レイヤ 3パケット全体（トンネルモード） レイヤ 3データ（トランスポートモード）
レイヤ 2データ（レイヤ 3パケット全体）
メッセージ認証範囲 レイヤ 3パケット全体（トンネルモード） レイヤ 3データ（トランスポートモード）
レイヤ 2フレーム全体
鍵交換プロトコル IKEv1 / IKEv2 IEEE 802.1X-2010 セキュリティ保護の範囲 エンドツーエンド ノード間のみ スループット 暗号化のみハードウェア すべてハードウェアレベル リプレイ保護 32ビットのシーケンス番号
によるチェック 32ビットの PN（Packet Number）によるチェック
トラフィック解析保護 △ × 受信遅延制限 × ◯
5. MACsecにおけるコネクションの概念
IPsecでは、コネクションの概念として、SA（Security Association）が定義されているが、MACsecでは、CA、SC、SAの 3つの概念が定義されている（図 1）。
CA（Connectivity Association） - 単方向の SCによって接続されるステーションのグループ - 鍵交換プロトコルによって管理される
SC（Secure Channel） - 単方向の接続 - SAの連続によって構成される - SCI（Secure Channel Identifier） = System Identifier（6バイト）+Port
Identifier（2バイト）で識別される SA（Secure Association）
- SAK（Secure Association Key）を使ってセキュリティサービスを提供する - SAI（Secure Association Identifier）= System Identifier（6バイト）+Port
Identifier（2バイト）+Association Number（2ビット）で識別される
－ 13 －
図 1 MACsecにおける CA/SC/SAの概念 6. MACsecのフレームフォーマット
MACsec適用前のイーサフレームのフォーマットを図 2に、MACsec適用後のイーサフレームのフォーマットを図 3に示す。MACsecを適用したイーサフレームには、ユーザデータの前に SecTAG（MAC Security TAG）が、ユーザデータの後に ICV（Integrity Check Value）が付加される。
SecTAGは、以下のフィールドから構成される。 MACsec EtherType
- MACsecが使われていることを示す 2オクテットのフィールド。値は「88-E5」となる。
TCI（TAG Control Information） - MACsecのバージョンを示す Vビット（当面は 0が入る）や、SCIフィールドの存在を示す SCビット、暗号化の有無などを示す Eビットなどを含む 6ビットのフィールド。
AN（Association Number） - 同一の SCの中で SAを識別するための 2ビットのフィールド。つまり、SCは最大 4つの SAから構成される。
SL（Short Length） - Secure Dataの長さが 48オクテット未満の場合に、その長さ（オクテット）が入る。48オクテット以上の場合には 0が入る。
PN（Packet Number） - 同一の SAで送信されたパケットを識別するユニークな IDが入る 4オクテットのフィールド。
SCI（Secure Channel Identifier） - TCIの SCビットが 1の場合に存在する、8オクテットのフィールドであり、6オクテットの System Identifierフィールドと 2オクテットの Port Identifierフィールドからなる。SCを識別するために利用される。また、デフォルトの暗号アルゴリズムである GCM-AES-128では、SCI値と PN値によって IV
－ 14 －
（Initialization Vector）が作られる。 TCIフィールドの Eビットが１の場合に、ユーザデータ部（Data）が暗号化される（暗号化された Dataは Secure Dataと呼ばれる）。そして、DMAC（宛先MACアドレス）、SMAC（送信元MACアドレス）、SecTAG、Secure Dataがメッセージ認証の範囲となる。
図 2 MACsec適用前のイーサフレームフォーマット
図 3 MACsec適用後のイーサフレームフォーマット 7. 暗号アルゴリズム
MACsecでは、デフォルトの暗号アルゴリズムとして、GCM-AES-128が指定されている。GCMとは、Galois/Counter Modeの略であり、データの暗号化とメッセージ認証の両方の機能を同時に実現する、高速で動作するアルゴリズムである。共通鍵には、128ビットの鍵を使用する。送信側と受信側が実装していれば、異なる暗号アルゴリズムを使用する
ことも可能である。 8. 鍵交換の役割
MACsecでは、鍵交換プロトコルとして IEEE 802.1X-2010が利用される。鍵交換プロトコルの役割には以下の 4つがある。
相手認証 CA/SC/SAの確立
－ 15 －
暗号アルゴリズムの折衝 共通鍵の配布
9. MACsecの実装状況
MACsecは、Cisco Systemsや Intelによって実装が進められている。 Cisco Systemsでは、同社の提唱する”TrustSec”において、MACsecを採用しており、同社のスイッチ製品である、Nexus 7000、Catalyst 3750-X、Catalyst 3560-X、そして、RADIUSサーバ製品である Cisco Secure Access Control System 5.1にて実装済みである。鍵交換プロトコルは、同社独自の Security Association Protocol （SAP）を使用しているが、IEEE 802.1X-2010にリプレースする見込みとなっている。 また、Intelの Intel 82567LM ギガビット LAN ドライバーがMACsecに対応している。
10. クラウドへの流れが MACsecの利用を加速
MACsecが注目されてきた背景としては以下のような特徴を持つクラウドの流れがあると考えられる。
ライブマイグレーションによるデータセンタ内のレイヤ 2化 VMwareの vMotionのような、ライブマイグレーションを実現するには、レイヤ 2で
接続されていなければならないため、データセンタ内はレイヤ 2でフラットに構築するという流れが出てきた。そのため、MACsecが利用できる環境になってきた。 データセンタ間接続のレイヤ 2化 DR（Disaster Recovery）用に、データセンタが地理的に複数に分かれていても、同じ
ように見せたいという要望が出てきたため、データセンタ間を VPLS（Virtual Private LAN Service）、MAC-VPN、Cisco Overlay Transport Virtualization（OTV）などのレイヤ 2で接続する技術を使う流れが出てきた。
11. MACsec適用時に検討すべき点
何からデータを守るのか MACsecを適用する場合は、何からデータを守るのかということをよく考える必要がある。他の暗号プロトコルにも言えることであるが、暗号化する人≠盗聴する人で
なければならない。MACsecをデータセンタに導入した場合、暗号化されるのはデータセンタ内のケーブルを流れるデータであり、ネットワーク機器の内部ではデータは
－ 16 －
復号化されているため、ネットワーク機器に侵入できる人物は盗聴することが可能で
ある。つまり、データセンタの機器の管理者からデータを保護することはできない。
MACsecが保護できるのは、データセンタにデータセンタ運用者以外の人間が侵入してケーブルを流れるデータを盗聴する行為や、レイヤ 2で構成されたWAN上で盗聴する行為に対してである。ネットワーク機器に侵入できる人物からデータを保護したい
のであれば、IPsecなどのエンドツーエンドの暗号プロトコルの利用を検討すべきだろう。ただし、実際のデータはデータセンタ内のストレージなどに格納されるため、IPsecのような通信路上のデータを保護する仕組みだけでは十分ではない。サーバやストレ
ージなども考慮した対策を検討する必要があるだろう。
パフォーマンスへの影響 MACsecは、レイヤ 2以上のすべての機器でフレームの復号化/暗号化を行う必要があるため、機器への負荷や、通信のパフォーマンスへの影響を考慮する必要がある。
すべてハードウェアで実装されていることが条件となるだろう。 12. まとめと今後の展開
MACsecの仕組み自体は 2006年に標準化済みであったが、鍵交換の仕組みが 2010年にようやく標準化承認されたことにより、今後、実装が進むと考えられる。すでに、Cisco Systemsがデータセンタ向けスイッチに実装を進めており、IntelもNICに実装を進めている。 今後、クラウドデータセンタがレイヤ 2化されていくに従い、利用が加速する可能性がある。ただし、「何のために暗号化するのか」といった検討は常に検討していく必要がある
と考えられる。 以上
－ 17 －
3. DNSSECの動向
木村 泰司
2010年 7月 15日、DNSルートゾーン（以下、ルートゾーンと呼ぶ）における署名が行われ、ルートサーバで署名レコードの提供が始まった[1]。ルートサーバは、.jp や .se といった ccTLDや .com や .org といった gTLD、そして .apra のような TLDのネームサーバの情報を含む DNSルートゾーンを提供するサーバである。ルートサーバは、いわば大本の DNSサーバであり、インターネットにおけるDNSSEC導入の影響範囲は大きい。そのため、DNSSEC 導入のために特別に結成された”デザインチーム”によって導入方法が慎重に検討されていた。 本稿では、ルートゾーンにおける DNSSEC導入と、その重要な要素であるキーセレモニー、そして DNSSEC運用の検討に役立つ DPS（DNSSEC Practice Statement）について述べる。最後に DNSSECの運用について、情報収集や技術検証を行っている国内での活動を紹介する。
1. ルートゾーンに DNSSECはどのように導入されたか
ルートゾーンにおける DNSSEC 導入のタイムラインを以下に示す（表 1）。このタイムラインは ICANNと VeriSignが運営する”Root DNSSEC”[2]というWebページでまとめられているもので、DNSSECに関連した様々なできごとの中で特に重要なものが挙げられている。
表 1 ルートゾーンにおける DNSSEC導入のタイムライン
2009年 12月 VeriSign と ICANN による内部用の署名が行われる。ICANN とVeriSign の間で、KSK による ZSK への署名の連携プロトコルが試験運用される。
2010年 1月 ルートサーバにおけるDURZの提供が始まる。DURZには署名検証を行えないようにするため、KSKと ZSKとして利用できない値が設定されている。
2010年 5月初旬 すべてのルートサーバで DURZが提供される。署名付きルートゾーンからの大きなレスポンスによる影響が起こりうる状態になる。
2010年 5月～6月 導入結果の検証が行われ、ルートゾーンにおける DNSSEC導入が決定される。
2010年 6月 16日 アメリカ・バージニア州のカルペパーで ICANN による最初の
KSKのキーセレモニーが行われる。 2010年 7月 12日 アメリカ・カリフォルニア州のエル・セガンドーで ICANNによる
二番目のKSKのキーセレモニーが行われる。 2010年 7月 15日 ICANNによるルートゾーン・トラストアンカーの公開が行われ、
実際の鍵を用いた署名付きルートゾーンの提供が始まる。
－ 18 －
多少の遅れはあったものの、ほぼ計画通りに導入が行われた。 導入にあたっては、”インクリメンタル・ロールアウト”と、ダミーの鍵を用いた”DURZ”と呼ばれる 2つの工夫が行われた。インクリメンタル・ロールアウトとは、AからMまであるルートサーバで徐々に DNSSECの署名付きルートゾーンを提供し、途中で問題が起こらないかどうかをみながら進める方法である。更に、この段階では DURZ（Deliberately Unvalidatable Root Zone）を用い DNSSEC対応のリゾルバーがルートゾーンの署名検証を行えないようにされた。DURZ とは、意図的に検証できないようにした署名付きのルートゾーンのことで、リゾルバーにおける署名検証が成功したり失敗したりする要素を排除するた
めに考案された。
図 1： DURZ（Deliberately Unvalidatable Root Zone） 一方、DURZ から署名検証が可能なゾーンへの入れ替えは、DURZ とデータサイズがほとんど変わらないことから、2010年 7月 15日、全てのルートサーバで一斉に行われた。 ルートゾーンにおける DNSSEC導入の検討は ICANNと VeriSignによって結成されたデザインチームによって行われた。デザインチームはルートゾーンにおける DNSSEC運用の要件として以下を定めている[3]。
Transparency（透明性） 運用プロセスがインターネットコミュニティに対してオープンであること。
オープンな形でキーセレモニーを行うなど。 Audited（業務の監査） 運用プロセスや手続きが業界のスタンダードに沿って監査されること。DPSを作成し、業務監査を実施できるなど。
High Security（高度なセキュリティ） システムがNISTのSP800-53の技術的セキュリティコントロールに適合すること。
これらの要件を満たすように実施された、キーセレモニーと DPSについて述べる。
. 86400 IN DNSKEY 257 3 8 AwEAAazdM++++++++++++++++THIS/IS/AN/INVALID/
KEY/AND/SHOU LD/NOT/BE/USED/CONTACT/ROOTSIGN
/AT/ICANN/DOT/ORG/FOR/MOR E/INFORMATION+++++
++++++++++++++++++++++++++++++++++++++ +++++
++++++++++++++++++++++++++++++++++++++++++++
+++++++ ++++++++++++++++++++++++++++++++++++
++++++++++++++++++++ +++++++++++++++++++++++
+++++++++++++++++++++++++++++++++ ++++++++++
8=
－ 19 －
2. キーセレモニー
キーセレモニーとは鍵生成の手続きのことで、物理的、そして技術的に安全な鍵生成を
行うための各種の工夫が行われる。ルートゾーンのKSKについては、2010年 6月 16日と7 月 12 日にキーセレモニーが行われた[4]。キーセレモニーの実施にあたっては、TCR（Trusted Community Representatives）と呼ばれるメンバーが募集され、KSKの鍵生成と保管に参加した[5]。これはコミュニティに対する”Transparency”の実現を目的としている。ルートゾーンのキーセレモニーには日本からは日本レジストリサービス（以下、JPRSと呼ぶ）の民田雅人氏が参加した。キーセレモニーの様子はストリーミングで公開された。 3. DPS
DPS（DNSSEC Practice Statement）は CPS（Certification Practice Statement）[6]を元にして作られたフレームワークである。ゾーンの登録要件や設備、システムのセキュ
リティなどの DNSSECの運用に関して網羅的な章立てになった文書で、DNSSECの運営を行う者が作成する。DPS の作成を通じて網羅的な検討を行うことができると共に、作成された DPS を使った業務監査を通じて運用のレベルを保つことができる。これは”Transparency”と”Audited”（業務の監査）の両方を実現するために行われた。
KSKに関する DPSは ICANNによって作成され[7]、ZSKに関する DPSは VeriSignによって作成された[8]。 4. 国内での情報収集や技術検証の活動
国内でのDNSSECの導入や運用については 2009年 11月に設立されたDNSSECジャパンが情報収集や技術検証の活動を行っている[9]。その一環として、7 月 21 日、DNSSECジャパンが主催となって、東京の品川で DNSSEC 2010サマーフォーラムというイベントが開催された[10]。 以下、国内での DNSSECの運用や利用にあたって情報源となるWebページの URLを示す。
DNSSEC関連情報
http://jprs.jp/dnssec/ JPドメイン名への DNSSEC導入に関する JPRSが公開する情報が掲載されている（JPRSは JPドメイン名のレジストリである）。DNSSEC機能確認手順書などの技術文書が公開されている。
DNSSECジャパン http://dnssec.jp/
－ 20 －
DNSSECジャパンではDNSSECに関する勉強会や技術検証が行われている。DNSSECに関係するMLやDNSSEC対応のツール（BINDやOpenDNSSEC等）へのリンク集もある。
日本の JPゾーンへの導入は 2011年 1月に予定されている[11]。国内の多くのドメイン名レジストラは、まだ顧客のドメイン名に対して DNSSECを扱えるようになっていないが、今後、対応が進められていくと考えられる。
以上
－ 21 －
参考文献
[1] ICANN,VeriSign: Status Update, 2010-07-16 http://www.root-dnssec.org/2010/07/16/status-update-2010-07-16/
[2] Root DNSSEC http://www.root-dnssec.org/
[3] DNSSEC for the Root Zone http://www.iepg.org/2009-11-ietf76/rootsign-ietf76-iepg.pdf
[4] ICANN DNS Operations http://dns.icann.org/ksk/ceremony/ [5] Trusted Community Representatives - Proposed Approach to Root Key
Management http://www.root-dnssec.org/tcr/ [6] Internet X.509 Public Key Infrastructure Certificate Policy and Certification
Practices Framework http://www.ietf.org/rfc/rfc3647.txt [7] DNSSEC Practice Statement for the Root Zone KSK Operator http://www.root-dnssec.org/wp-content/uploads/2010/06/icann-dps-00.txt [8] DNSSEC Practice Statement for the Root Zone ZSK operator http://www.root-dnssec.org/wp-content/uploads/2010/06/vrsn-dps-00.txt [9] DNSSECジャパン http://dnssec.jp/ [10] DNSSEC 2010 サマーフォーラム http://dnssec.jp/?page_id=51 [11] JPドメイン名サービスへの DNSSECの導入予定について http://jprs.jp/info/notice/20090709-dnssec.html
－ 22 －
4. CA/Browserフォーラムの日本開催
木村 泰司
2010年 5月 12日～13日、CA/Browserフォーラム[1]のミーティングが東京の渋谷で開催された。ミーティングは過去に 20回行われており、アジア地域では初の開催である。本稿では、CA/Browserフォーラムとは何か、そして日本開催にはどのような意義があったのかについて報告する。
CA/Browserフォーラム・ミーティング開催前の様子
1. EV SSL証明書と CA/Browserフォーラム
EV SSL証明書は、発行対象のサーバのドメイン名を割り当てられている組織の名称がわかるサーバ証明書である。EV SSL証明書に対応したWebブラウザは、通常の SSLの接続であることの表示（南京錠など）に加えて、アドレスバーが緑に変わり、組織名が表示さ
れるなどする。すなわち EV SSL 証明書は、証明書に記載されたドメイン名でアクセスできるサーバの運営組織を確認できる証明書である。 この仕組みは、認証局の運用のレベルを担保するための認証局監査と EV SSL Certificate
Guidelines[2]とよばれる、認証局運用のガイドライン（以下、EVガイドラインと呼ぶ）によって支えられている。このガイドラインを策定しているのが CA/Browser フォーラムである。CA/BrowserフォーラムにはWebブラウザのベンダーも参加しており、Webブラウザの動作仕様を決めるなど、協力している。 2. 日本開催の様子
開催期間の一日目は、オープンカンファレンスと呼ばれ CA/Browser フォーラムの会員でなくても参加することができた。通常、CA/Browserフォーラムのミーティングはオープンカンファンレンスのような形は取られていないが、今回は初のアジア開催（北米、欧州
－ 23 －
以外での開催）であったため、広い範囲の参加者を募ると共に、アジアにおける EVのプレゼンスを高めるという CA/Browserフォーラムとしての意図があったようである。
1日目は、CA/Browserフォーラムの紹介や EVガイドラインに関連するプレゼンテーションが行われた。2日目はクローズドカンファレンスで、EVガイドラインの改定等に関わる議論が行われた。開催概要を以下に示す。
日時： 2010年 5月 12日（水）～5月 13日（木） 場所： 渋谷 セルリアンタワー8F Google 会議室 参加者数： 50名程（5月 12日 - オープンカンファレンス） 35名程（5月 13日 - CABF会員のみ）
協力組織（順不同）：
日本電子認証協議会 GMOグローバルサイン株式会社 グーグル株式会社 セコムトラストシステムズ株式会社 プログラム： 5月 12日（水） オープンカンファレンス 1. 会議に関するオリエンテーション、アジェンダの確認等 2. CA/Browserフォーラム及び EVガイドラインの紹介 3. 日本電子認証協議会の紹介 4. 台湾の認証局 TWCA（新規会員）の紹介 5. インド情報通信省のプレゼンテーション[キャンセル] 6. 日本における EV SSLの現状について（ベリサイン） 7. 英文組織名データベースに関する提案（クロストラスト） 8. 日本における印鑑の取り扱い（セコム） 9. 国際化ドメイン名の証明書における扱いの提案（JPRS） 10. 国際化 ccTLD 11. 認証局監査に関連した最新動向 5月 13日（木） クローズドカンファレンス（CABF会員のみ） ・EVガイドラインに関する議論 日本からは、日本特有の事情についてのプレゼンテーションや EV SSL 証明書に関連した提案がいくつか行われた。この中で、特に今回のミーティングで特徴的だった「英文組
織名データベースに関する提案」について紹介する。 3. 英文組織名データベースに関する提案
日本からのひとつに提案で EVガイドラインの改定に関わるものに「英文組織名データベ
－ 24 －
ースに関する提案」があった。この提案は、日本電子認証協議会[3]（以下、JCAFと呼ぶ）代表理事の秋山卓司氏によるもので、国内の EV SSL 証明書の普及に向けた課題解決を目指した提案である。 正式なアルファベットでの組織名を登記することが必須ではない日本においては、アル
ファベット表記の組織名（例：Fujitsu や Sony）を確認する一定の手段がなく、EV SSL証明書への記載が難しいことが多い。現在は、組織名の正式なアルファベット表記を確認
するために、弁護士が作成した書面が使われるなどしているが、手続きが煩雑なことが多
く、EV SSL証明書の発行手続きをより難しくする要因となっている。 提案の内容は、EV証明書に登録されるアルファベット表記の日本の組織名が登録される、中立的なデータベースの設置と、それに対応するような EV ガイドラインの改定である。EV SSL証明書を発行する際に、この英文組織名データベースを利用することで認証局各社は一定の手段でアルファベット表記を確認できるようになり、より多くの組織で EV SSL証明書が利用しやすくなると考えられている。 ミーティング会場では、英文組織名データベースの必要性についての一定の理解が得ら
れ、提案としてはよいという雰囲気であった。EVガイドラインの改定の提案には至っていないため、今後、英文組織名データベースの運営方法などの課題を検討の上で、次回のミ
ーティングに向けた議論が行われると考えられる。 4. 日本開催の意義と今後
今回の日本開催は、CA/Browserフォーラムにとって、欧米以外への展開に必要と考えられている制度や言語に関するディスカッションができ、また日本での認知度向上を図るこ
とができた点に意義があったと考えられる。一方、JCAFや CA/Browserフォーラムに参加している国内の民間認証局は、SSL/TLS関連の業界への影響力の強い CA/Browserフォーラム開催の誘致に成功した。その上で、EV SSL証明書の展開という意味でニーズがあるにも関わらず、コミュニケーションが取りにくかった CA/Browser フォーラムで、証明書に入る文字列と日本の登記制度などの話題に一定の理解を得ることができた。 次回の CA/Browser フォーラムミーティングは、2010 年 10 月にリトアニアで予定されている。今後もこのような国際的な議論の場に日本の民間認証局が参加し、日本の制度や
文字列の扱いが適切に扱われるような活動に期待したい。 以上
－ 25 －
参考文献
[1] CA/Browser Forum http://www.cabforum.org/ [2] EV SSL Certificate Guidelines http://www.cabforum.org/documents.html [3] JCAF 日本電子認証協議会 http://www.jcaf.or.jp/
－ 26 －
5. User Managed Access
工藤 達雄 1. はじめに
本報告では 2010 年上半期のアイデンティティ管理技術に関する動向として、User Managed Access [1] の動きを概観する。 2. User Managed Access とは
2.1 背景
分散環境におけるアクセス管理は、古くて新しい課題である。組織や企業の内部、ある
いは信頼関係のある組織間では、ポリシーに基づいてどのようなアクセスを許可するかを
判断するサービスを PDP（Policy Decision Point：ポリシー決定点）、PDPの判断に基づいて実際にアクセス制御を実行するサービスを PEP（Policy Enforcement Point：ポリシー実行点）とし、アクセス管理の大元を PDP に集約することが一般的であった。しかしインターネット・サービス同士の Web API による疎結合な連携に対しては、このような旧来の中央集権的なモデルをそのまま当てはめることが難しい場合も少なくない。
Web API によるインターネット上のサービス連携が広まる中、ユーザの判断に基づくアクセス制御を実現するための仕様として、OAuth [2] [3] の採用が進んでいる。OAuth は、クライアント（Client）がユーザ（Resource Owner）の許可を得てサーバ（Resource Server）内のリソース（Protected Resource）へアクセスするための方法を規定しているが、同仕様では、いくつかの前提を置いている。 まず Protected Resource の管理権限を持つユーザと Client 側にいるユーザが別の人物であるようなユースケースは、OAuth 仕様では基本的に想定されていない。すなわち Client は Resource Owner の指示を受けて、「その Resource Owner の Protected Resource」に対してアクセスを行うのであり、「別の Resource Owner に属する Protected Resource」にアクセスするものではない。 次に Resource Server は Client からのアクセスに関してAuthorization Serverにアクセス可否や範囲の決定を委ねるが（つまり前者が PEP、後者が PDP となる）、「Resource Server がどの Authorization Server を信用するか」は事前に Resource Server 自身が選定しており、Resource Owner に選択の余地は無い。このように Resource Server と Authorization Server（多くの場合、Resource Server と同一のドメインに存在する）が密接に結びついているということは、「ユーザは複数の Authorization Server と複数の Client との組み合わせの数だけ、認可管理を行う必要がある」ということを意味する。 この結果、アクセス許可を求める Client と、実際にサービスを提供する Protected
Resource との間の関係管理が、ユーザにとって新たな負担となることは、想像に難くない。
－ 27 －
たとえば Twitter や Facebook などのサービスと、それらと連携して動作する外部アプリケーションとの間の n 対 n の関係は広がる一方であり。ユーザはどのアプリケーションにどのようなアクセス権限を許可したか、個々のサービスを逐一確認しなくてはならなく
なっている。 2.2 User Managed Access のアプローチ
UMA（ User Managed Access ）は、データ共有とサービス・アクセスに関する認可をユーザがコントロールできるようにするための Web プロトコルである。前述の課題を解決するために、UMA では次のふたつのコンセプトを導入する。 第 1 に、Client に Protected Resouce へのアクセスを試みるよう指示する主体を、
Resource Owner とは別のユーザや組織であると定義する。さらに Client へのアクセス権限の付与について、あらかじめ定められたポリシーと、Client が提示した Claim によって、Resource User 不在の状況でも行うことを定義している。これにより、Resource Owner が Client の指示者とは別個の主体であるようなケースにも対応可能としている。 第 2に、Resource Server と Authorization Server との分離である。そして Resource
Server がどの Authorization Server と連携するかは、Resource Owner が選択できるようにする。これにより Resource Owner は、権限管理について、自身が選択した Authorization Managerのみを扱えば良いことになる。 3. UMA Core プロトコル概要
UMA の仕様は、現在 IETF にて議論・策定が進む OAuth 2.0 プロトコル仕様 [4]（以下 OAuth 2.0）をベースとしている。ただし、関係するエンティティの役割を以下のように拡張している（図 1）。(なお現時点の UMA 仕様では OAuth 2.0 と異なる名称を用いているが、将来的には OAuth 2.0 に準拠する可能性もある。）
－ 28 －
図 1：UMAの登場人物
Authorizing User: OAuth 2.0 における Resource Owner。Host 内の Protected Resource に関するアクセス・ポリシー（Requester からのアクセスをどのように許可するか）を Authorization Manager に設定する。
Authorization Manager: 同 Authorization Server。Authorizing User の設定したアクセス・ポリシーに従い、Protected Resourceへのアクセス認可決定（policy decision）を行う。
Host: 同 Resource Server。Protected Resourceを管理し、Authorization Manager のアクセス認可決定を Requesterに強制（policy enforcement）する。
Requester: 同 Client。Requesting Party（Authorizing User、または別のユーザや組織）の指示により、Protected Resource へのアクセスを試みる。
UMA のプロトコル [5] は、主に次の 3 ステップからなる（図 2）。
－ 29 －
3.1 トークンの信頼
まず、Authorizing User によって、Host を Authorization Manager に登録する処理が行われる。これを紹介（introduction）と呼ぶ。紹介によって、Host は Authorization Manager が発行するトークンを「信頼」することになる。 紹介は、Authorizing Userが Host に対し、自身が利用する Authorization Manager を
Host に通知することが起点となる。Host は Web Host Metadata [6] に基づき、Authorization Manager からメタデータを取得する。
Host はメタデータに記述されているエンドポイント等の情報を利用し、Authorization Manager に、Protected Resource の登録を試みる。まず Authorizing User の同意に基づいて Authorization Manager からトークン（Host Access Token）を取得し、次に Protected Resource の情報を Authorization Manager に登録する。 もし Host と Authorization Manager が事前に連携したことがない場合には、Host が自身の情報を Authorization Manager に動的に登録し、Authorization Manager が Host にクライアント ID（およびシークレット）を返却する処理（dynamic registration）[7] が行われることになる。
図 2：UMAプロトコルの 3つのステップ
－ 30 －
3.2 トークンの取得
Requester は Requesting Party（Protected Resource の所有者（Authorizing User）本人であるケース、それ以外の第三者（個人もしくは組織・法人）であるケースの、どち
らもありうる）の指示を受けて、Protected Resource へのアクセスを試みる。 Protected Resource へのアクセス試行を受けた Host は、Requester が Protected
Resource へのアクセスに必要な access token を提示してきたかどうかを確認する。もし access token が存在しない場合には、Host は Requester を Authorization Manager に誘導する。
Requester は Authorizaiton Manager に、どのようなアクセスを行いたいか（scope）を提示し、access token の取得を試みる。この要求に対する Authorization Manager の応答は 3 種類あり、access token の発行、発行拒否、さらなる情報（Claim）の要求、のいずれかとなる。
Authorization Manager の応答が「Claim の要求」であった場合、Requester は Authorization Manager が求める種類の Claim を準備し、Authorization Manager に提出する。Claim [8] は JSON 型式の文書であり、access token の取得に必要な情報が含まれる。Claim を受け取った Authorization Manager は Claim を確認し、再度、access token の発行、発行拒否、さらなる情報（Claim）の要求、を行う。 3.3 トークンの利用
Authorizaiton Manager から access token の取得に成功した Requester はその access token を Host に提示し、Protected Resource へのアクセスを試みる。
Host はその access token を自身で確認するか、Authorization Manager に検証を依頼し、有効であることを確認した上で、Protected Resource へのアクセスを許可する。 以上のステップにより、Requester は Authorizing User の設定したポリシーに従い、目的の Protected Resource にアクセスすることができるようになる。 4. 現在の状況
UMA の活動は、Kantara Initiative 内のワークグループ（WG）にて行われている。本 WG は 2009 年に開設され、PayPal 社の Eve Maler 氏が議長となり、ユースケース定義や仕様策定を進めている。 今年に入り、ニューカッスル大学の SMART（Student-Managed Access to Online
Resources）プロジェクト [9] によるプロトタイプ実装が公開されるなどの進展が見られる。
－ 31 －
5. まとめ
OAuth 仕様、とくに現在策定が進行中のバージョン 2.0 は、今後コンシューマ / エンタープライズを問わず、様々な分野での適用が期待される。しかしそれは同時に、OAuth クライアントと OAuth によって保護されたリソースとの組み合わせが爆発的に増加することを意味する。 これを管理可能な状態に維持するために、エンドユーザにポリシーの管理を委ねること
は、解決方法のひとつとして有力であろう。UMA ワークグループの取組みは、今後ユーザ中心のサービス連携を実現する上で、非常に有用であると考えられる。
以上
－ 32 －
参考文献
[1] Home - WG - User Managed Access - Kantara Initiative http://kantarainitiative.org/confluence/display/uma/Home [2] 情報セキュリティ技術動向調査（2009 年上期） 8 アイデンティティ管理関連技術
OAuthの動向 http://www.ipa.go.jp/security/fy21/reports/tech1-tg/a_08.html [3] OAuth Community Site http://oauth.net/ [4] The OAuth 2.0 Protocol http://tools.ietf.org/html/draft-ietf-oauth-v2 [5] UMA 1.0 Core Protocol - WG - User Managed Access - Kantara Initiative http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol [6] Web Host Metadata http://tools.ietf.org/html/draft-hammer-hostmeta [7] OAuth Dynamic Client Registration Protocol http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt [8] Claims 2.0 - WG - User Managed Access - Kantara Initiative http://kantarainitiative.org/confluence/display/uma/Claims+2.0 [9] Student-Managed Access to Online Resources http://research.ncl.ac.uk/smart/
－ 33 －
6. IPv6ネットワークにおけるローカルネットワークの保護
太田 耕平、キニ グレン マンスフィールド 1, はじめに
IPv4 アドレスの枯渇[1] がいよいよ目前にせまり、IPv6 への移行が急務となっている。これまでに多くの技術課題が克服され、実装の普及も現実的な段階となっている。しかし、
その運用については十分に検討されているとはいえない。 IPv6 はバックボーンネットワークへの導入が進んできており専門家の間では運用ノウハウの蓄積も進んでいる。一般の企業や家庭では、広く利用されているサーバおよび端末の
多くで IPv6の利用が可能となっており、デフォルトで IPv6機能が ONになっているケースも増えている。そのためネットワーク内で気が付かないうちに IPv6通信が発生していることも多い。しかし、企業や家庭で現在の IPv4と同等以上のセキュリティ、内部ネットワークの独立性／一貫性などを IPv6でどのように確保するかといった具体的な運用ノウハウの蓄積は十分ではない。 本稿では、企業や家庭での IPv6 利用を想定して、IPv4 で一般化している NAT/NAPT（Network Address Translation/Network Address Port Translation）との関連をベースに、IETF（Internet Engineering Task Force）での議論を紹介する。インターネットはEnd-to-Endの接続性を確保することを基本原則として設計され、それが飛躍的な発展の基盤となったため、IPv4で導入せざるを得なくなったNATは当初から大きな議論を呼んだ。IPv6では NATを不要にすることが大きな設計目標のひとつであったため、IPv6でもなおNAT が必要であるかどうかは重大な論点になっている。なお本稿では特に断りなく NATと記述する際には NAT/NAPTの両者を含むものとする。 2. IPv6におけるローカルネットワークの保護
IPv6 におけるローカルネットワークの保護はそのセキュリティおよび運用の完全性（Integrity）を含めて 2007年に発行された RFC 4864[2] で基本的な議論がなされており、その後の標準化の議論の基盤として繰り返し参照されている。
RFC 4864 ではローカルネットワークの保護のために達成すべき項目と方法を IPv4＋NATとの対比で議論しており、IPv6では原則として NATなしでそれらを達成できると結論付けている。しかし、その後の議論によって特にアドレス変更、マルチホーム対応、さ
らには設定情報の一元化を現実的に解決するためには依然としてNATも有効であることが指摘され、これまでの「誤解に基づく」セキュリティ上の必要性から IPv6でも NATの利用がなし崩し的に広がることが懸念された。その結果、標準化されない技術が広がること
を防ぐという目的も含めて IPv6でのNATであるNAT66[3] が提案されるなどの議論が続
－ 34 －
いた。 2010 年７月、 IAB（ Internet Architecture Board） 2はそれらの議論を踏まえて
「End-to-End の原則」[4] に照らして NAT および IPv6 の関係を整理しその見解を RFC 5902[5] として発行した。以降では、RFC 4864および RFC 5902で述べられている広く信じられているが実際には NATでは解決できないセキュリティ上の課題とその対策、一方でRFC 4864で IPv6ではNATなしで解決できるとされているが現実的にはNATも有効な解決策となりえる課題について概説する。 2.1 NATでは解決できない課題
NAT は本来 IPv4 グローバルアドレスを節約するための方法として策定され利用されてきた。しかし、その本来の機能以外に副次的にもたらされる効果が、技術的には不十分で
あり、かつそれらを利用することによる副作用があるにもかかわらず、NAT の導入によって自動的に得られる便利な機能であるかのように認知されてしまっている。特に大きな影
響があるのは以下の機能である。
(1) ネットワーク出入り口でのフィルタリング (2) トポロジの隠蔽とプライバシ
(1) ネットワーク出入り口でのフィルタリング
NAT は内部からの通信の必要性に応じて動的に外部とのアクセスを確保するために、外部から内部への通信に対するステートフルフィルタリング機能を提供しているかのように
思われている。しかし、これはアドレスを動的に共有するため、言い換えればアクセスを
確保するために行われているものであり、遮断するためのものではない。 例えば、ネットワーク境界に設置した NAT が特定のホストに対するスタティック NATとして設定されているケースでは、特定のポートと特定の内部ホストが関連付けられてい
るため、フィルタリングはまったくなされていない。また、NAPT の配下に多くのホストがある場合は、ポートへの無差別攻撃であっても多くの内部ホストに影響を与える可能性
がある。 つまり NATのフィルタとしての動作は、アドレス変換の関係が固定ではなく、かつ事前にわかっていない場合でのみ意味を持ち、運用方法や状況に大きく依存するため「導入す
れば自動的に確保される」セキュリティとしてはまったく信頼できない。 RFC 4864および RFC 5902では、上記のような理由によって、このようなフィルタリングのためにNATを利用することは不適切であり、フィルタリングにはそのためにファイアウォールの機能として設計されたステートフルフィルタリングを利用すべきであることを
述べている。
2 http://www.iab.org/
－ 35 －
(2) トポロジの隠蔽とプライバシ
トポロジの隠蔽の目的は、伝統的なセキュリティ管理の第一歩として、ネットワーク外
部の者に対して内部ネットワーク上のデバイスの存在およびそれらの構成（設定）を知ら
れることを防ぐことにある。 NAT を利用していればインターネット上では NAT の配下にあるホストからの通信は、すべて NATから、原則的には同じ IPアドレスからの通信に見えるため、観測される IPアドレスから単純に端末の存在が知られることを防ぐことができる。 しかし、古くから指摘されている通り、IP-IDフィールドなどのアドレス以外のパケットヘッダの値が予測可能な方法で選ばれている場合はそれらを関連付けることでNAT配下の特定のホストからの通信であることを判断できる[6] ため、結果として NAT 配下のホスト数の推定が可能であることが知られている。 この問題に対しては NAPTを利用し、複数のアドレスをコネクション毎にランダムに割りあてるなどの複雑な構成をとればNAT技術でもさらなる防御が可能であるが、そうすれば SIP（Session Initiation Protocol）や SCTP（Stream Control Transmission Protocol）などの複雑なコネクションを利用する通信がNATを通過できなくなる可能性が高まる。 さらに OSやそのバージョン、利用されているアプリケーションなどのホストのより詳細な構成を分析するHost finger printingについては上述したようなアドレスのランダム化等のNAT構成の複雑化では防ぐことができない。Host finger printingはホストの要求-応答の対応関係からその構成を推定するため、通信路上でパケットを観測するだけで十分な情報
を得られる。動的なアドレス利用、アドレス対応の短い周期での変更などは推定のための
情報を得られにくくはするが、本質的な対策にはならない。 また、サブネット構成などのトポロジ情報についてもパケットの到着タイミング、遅延
の計測、パケットヘッダの Hop Limitフィールドの値などから相対的な位置関係が特定可能であり、Host finger printingによって特定されたホストがあれば、そこからさらなる推定が可能となる。
IPv6 ではこれらの問題に対して、RFC 4941 で規定している pseudo-random privacy address [7] および RFC 4193で規定している ULA（Unique Local Address）[8] が用意されている。RFC 4941では SLAAC（Stateless Address Auto Configuration）で自動的に設定されるインターフェース ID に MAC アドレスを元にした EUI-64（Extended Unique Identifier-64）ではなくランダムな数字を用い、それらの有効期間を短くする（デフォルトでは 1日）ことでアドレスから特定のホストを特定される危険性を減らし、RFC 4193ではIPv4 におけるプライベートアドレスと同様に内部だけで利用できるアドレスを利用することでネットワークアドレスから内部のアドレスを推定される危険性を減らしている。 しかし、これらの方法では NAT と同程度の隠蔽は実現できないため、RFC 4864 では、グローバルアクセスが必要な内部ノードに対して、実際のトポロジに対するアドレスの他
－ 36 －
に外部アクセス用の論理アドレスを割り当て、外部接続ルータによってその論理アドレス
へのホストルートを管理する方式が提案されている。またそれを自動化し、より NATに近い形で運用するために経路最適化をしないMobile IPの利用が提案されている。しかし、これらについては、内部で管理する経路が複雑化するため運用のスケーラビリティがすぐに
問題になるほか、Mobile IPについては外部への経路通知機能（Binding update）の制御についても検討する必要があり、現状では現実的な運用に耐えうるかどうかの検証が不十分
である。 RFC 5902では、これらの問題に NATで対応するには上記のように技術的に不十分であるばかりか、End-to-Endの通信を確保するというインターネットの大前提に大きな影響をもたらすことを指摘しているが、一方で IPv6によるソリューションが十分であるかどうかは議論していない。 2.2 NATが有効な解決策となりえる課題
一方で、RFC 4864 で指摘されている以下の課題については、NAT66[3]、RFC 5902等で実際にはNATを現実的な解として検討できることが議論されている。
(1) アドレス変更（Avoiding renumbering） (2) マルチホーム対応（Facilitating multi-homing） (3) 設定情報の統一（Making edge consumer network configurations homogenous）
(1) アドレス変更
IPv4はホストが複数のアドレス、特に複数の CIDR（Class-less Inter Domain Routing）アドレスを扱えるようには設計されていなかったため、ISPを変更する場合などはプロバイダから割り当てられているアドレスを一斉に切り替える必要がある。このとき NATを利用していればNAT配下のアドレスはその影響をうけないため、アドレス変更のコストは大幅に削減できる。
IPv6ではホストが複数の異なる CIDRアドレスを同時に利用できるように設計されており、DHCP-PD[9] によってアドレス Prefixを動的に配信するプロトコルも整備されたため、原理的には切り替える前後のアドレスを同時に利用できる期間を設けることで切り替えを
スムーズに進めることができるとされている。しかし、実際には IPアドレスは端末が直接通信に利用しているだけではなく、様々な設定に記述されているため、移行には DNS やDHCP、ファイアウォールなどのフィルタリング、さらには IDS や資産管理システムなど多岐にわたるシステムを考慮する必要がある。 エンドユーザとしての利用のみであればアドレスを手動で管理する局面はほとんどない
ため、現在のメカニズムでも大きな問題にはならないが、一定以上の規模を持ち固定アド
レスのサーバなどを有する管理されたネットワークでは依然として大きな問題となる。こ
のような場合、IPv6ネットワークであっても NATは有力なソリューションになる。
－ 37 －
PI（Provider Independent）アドレスを取得し、独自のアドレス空間を所有していればNATに頼らずにスムーズなアドレス変更が可能となるが、すべての組織が PIアドレスを利用すれば経路制御の拡張性に重大な影響を及ぼすため、十分な解決にはならない。 (2) マルチホーム対応
アドレス変更に関連の深いもうひとつの問題はマルチホームである。企業ネットワーク
などでは冗長性や負荷分散のためにも複数の ISP に接続するマルチホームが必要とされるが、IPv4 では原則として複数のネットワークアドレスを必要に応じて切り替えて使うことができないためそもそも困難な課題となっている。NATを利用すればそれらの課題がNAT装置だけの課題となり解決が容易になる。
NATを利用したマルチホームは経路制御面で大きな利点がある。NATを利用することでネットワークをひとつの IPアドレスで代表するため、ネットワークへの経路を新たに広告する必要がなく、マルチホーム化が経路制御に影響を与えない。
IPv6 ではホストは同時に複数のネットワークに所属できるため特別な装置に頼ることなくマルチホーム化が可能であるが、そのためにはそれらのネットワークアドレスを経路情
報として広告する必要があるため、経路制御へのインパクトが懸念される。 実際これまで経路制御に影響を与えないマルチホームを実現するには異なる ISP から割り当てられた複数の IPv4アドレスを外部アドレスとして割り当てられた NATに頼るしかなかった。そのため IPv6でも IPv4と同様の NATを利用したマルチホーム化は自然な流れともいえる。 ただし、NAT を利用すると End-to-End の通信が阻害される問題も同時に持ち越されることになる。一方、IPv6 で容易に実現できる複数の経路を広告する形のマルチホームではEnd-to-Endの原則が確保でき、かつ様々なトラフィックエンジニアリングや負荷分散を可能とできる利点がある。 (3) 設定情報の統一
ISP の立場からみれば、NAT によってすべての顧客のアドレス空間が同じになっていることをサポートコストの削減に積極的に利用しているため、この方面の利点も無視できな
い。IPv6 ではリンクローカルアドレスの概念によって複数のリンクに同じアドレスを割り当てることができるため、NAT なしでも同じサポート体制が構築できる可能性があるが、それが十分であるかどうかはまだ検証されておらず、このことも IPv6で NATを必要とする要素となっている。 3. まとめ
RFC 5902で述べられている IABの見解は、「IPv4で広く普及し、しばしばセキュリテ
－ 38 －
ィ的な意味もあると思われている NATは、実際にはセキュリティ装置として利用できるとはいえず、その観点からは IPv6で NATは不要である」としている。一方で、現状ではアドレス変更、マルチホーム対応、設定情報の統一という課題に対してはNATの有効性を否定できないことも述べている。
RFC 5902では、これらの課題を考えるにあたっては、NATの有効性を考えるのではなく、あるサイトが NAT を利用することによって、NAT を利用しない残りのインターネットがどんな影響を受けるかが重要なポイントであることを指摘している。 NAT の有無が大きく影響する「End-to-End の原則」は、これまでインターネットの発展を支えてきた重要なコンセプトであり、これを保持できるかどうかは上記の課題の解決と
両立できるかどうかにかかっていることから、IABでは RFC 5902を通して「End-to-Endの原則」を確保できる提案を強く求めている。 一方で、目前にせまった IPv4アドレスの枯渇に対応するためには IPv6の普及が不可欠であり、企業や家庭のネットワークでの実用的で安全な IPv6の構築と運用には、RFC 4864でも指摘されている IPv6 で導入できるようになるプライバシアドレスや ULA、複数アドレスの積極的な利用についての実用的なノウハウの蓄積が求められている。
以上
－ 39 －
参考文献
[1] IPv4アドレス枯渇対策タスクフォース，「IPv4アドレス枯渇について」， http://www.kokatsu.jp/blog/ipv4/
[2] G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein, “Local Network Protection“, RFC 4864, May 2007
[3] M. Wasserman, F. Baker, “IPv6-to-IPv6 Network Address Translation （NAT66)”, Internet-Draft, http://tools.ietf.org/id/draft-mrw-behave-nat66-02.txt, Nov. 2008
[4] Aboba, B. and E. Davies, “Reflections on Internet Transparency”, RFC 4924, July 2007
[5] D. Thaler, G. Lebovitz, “IAB Thoughts on IPv6 Network Address Translation”, RFC 5902, July 2010
[6] Bellovin, S., “A Technique for Counting NATed Hosts”, Proc. Second Internet Measurement Workshop, November 2002
[7] Narten, T. , R.Draves, and S. Krishnan, “Privacy Exensions for Stateless Address Autoconfiguration in IPv6”, RFC 4941, September 2007.
[8] Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses”, RFC 4193, October 2005.
[9] Troan, O. And R. Drms, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) Version 6”, RFC 3633, December 2003.
－ 40 －
7. Gumblar攻撃に対する技術の現状と課題
宮川 寧夫 1. はじめに
2009年下期には Gumblarと呼ばれるWeb媒介型の攻撃手法攻撃が注目された [1] が、未だ収束していない様子である。Gumblar 攻撃は一連の攻撃であり、その一連の攻撃への対策箇所を下表（表 1）に示す。
表 1： Gumblar攻撃への対策箇所
攻撃の順序 Webサイトにおける対策 エンドユーザにおける対策 ①罠をしかけて誘導する (1) セキュアな Web ファイ
ルのアップロード
②待ち伏せ攻撃 （初期感染）
関連ソフトウェアの脆弱性
を解消 ③感染後の連続的動作 (2) 出方向のパケットフィル
タリング 本稿においては、2点の対策技術をとりあげる。
(1) セキュアなWebファイルのアップロード
意図しないリダイレクトの設定等のWebファイルの改変についての対策として、Webサイトの管理者向けに FTP／SSHにおける本人認証（authentication）機能についてとりあげる。Webコンテンツの管理は、しばしばアウトソーシングされている実態があり、安直なパスワードが流通しているようである、そこで、実質的に必要なエントロピーに
関する指針文書を紹介し、より強い本人認証の利用可能性について現状を整理する。な
お、Web ファイルの改変についての監視等の継続的な対策については本稿においては割愛する。
(2) 出方向のパケットフィルタリング
Gumblar 攻撃においては、エンドユーザが意図しない出方向トラフィックをマルウェアが発生させて、後続のシーケンシャルマルウェアを呼び寄せている構図がある。そこ
でエンドユーザ環境にも出方向のパケットフィルタリングを配備することが推奨されつ
つある。エンドユーザがブラウザを操作してアクセスするWebサイトをフィルタリングすることも一種の出方向のフィルタリングではあるが、今般のマルウェアによる外部の
サイトへのアクセスは、HTTPのトラフィックに限定されない。
－ 41 －
2. セキュアなWebファイルのアップロード
2.1 攻撃対象とされるWebコンテンツ管理者のアカウント
まず、意図しないWebファイルのアップロードについては、Webサイトのコンテンツ管理者向けの話題となる。
Web コンテンツ管理用には、各種の Web オーサリングツールや CMS（コンテンツ管理システム）のユーザインタフェィスと連動する FTP画面が用意されていることがある。また、アウトソーシングされている場合、FTPよりは経路を防護される SSH（Secure Shell）[2] の scp コマンド等が利用されることが望ましい。SSH の代表的な実装と言えば
OpenSSH3 が挙げられる。経路が防護されるファイル転送用のプロトコルとしては、他にFTPS（File Transfer Protocol over SSL/TLS）[3][4] もある。
Gumblar攻撃において、Webコンテンツ管理者のアカウントが攻撃対象となるが、その際の攻撃ツールとして、FTP や SSH のアカウントに対してブルートフォース攻撃を行うツールの存在が広く知られてしまっている状況にある。FTPや SSHのアカウントについては、通常、パスワードによる認証（authentication）の機能が利用されている。 2.2 運用上の対策項目
今期の SANSの ISC（Internet Storm Center）の日誌に掲げられている SSHの運用管理における対策事項[5]を手がかりとして検討してみる。この中では、下記の対策事項が掲げられている。
TCP 22番以外のポートに SSHサーバを導入する…(1) SSHブルートフォース防止のためのツールを導入する…(2) リモートのルートログインを不許可にする…(3) パスワードによる認証（authentication）を禁止に設定して鍵を利用する…(4) パスワードを使わなければならない場合は複雑なものにする…(5) AllowGroupsを使って特定のユーザグループのアクセスを制限する…(6) 可能であれば SSHに chroot jailを利用する…(7) SSHに接続できる IPレンジを制限する…(8)
(1) ポートスティーリング（ポート番号の変更） ポート番号の変更は、FTPにおいても古くから利用可能なテクニックであった[6]。このテクニックは、SSHにおいても有効である。 (2) 対策ツールの導入 3 http://www.openssh.org/
－ 42 －
今日的なツールとして sshdfilter（V1.5.7 ssh brute force attack blocker）4がある。これ
は、SSHに対する攻撃のログから ipfilterを作るものである。 (5) パスワードの複雑化 例えば、MUSTANシステム5によって観測される SSHアカウントに対する攻撃は、次のようなアカウント名を対象としている（例：admin、test、oracle、mysql、postgress等）。このように、コンテンツ管理者のアカウント以外にDBMS管理者のアカウントも狙われている。パスワードの選択においては、これらの傾向を反映して一定の「辞書ルール」を適
用して安直なパスワードを避けることが必要である。 今日的なパスワードのエントロピーに関する文書としては、NIST の SP 800-63,
“Electronic Authentication Guideline” [6] 中の Appendix A `Information about estimating the entropy of passwords’が良くまとまっている。上述の「辞書ルール」に関しては、パスワードの文字数が長くなるに従って追加的な効果は期待できなくなるが、長く
ないパスワードが設定される場合には有効であることも示されている。本書自体は、エン
ドユーザが利用する本人認証機能についての要件を、4つのレベルに分けて規定しているものであり、この詳細については本稿においては説明しないが、その中で「レベル 2」については`Passwords shall have at least 10 bits of min-entropy’と規定されているように、エンドユーザ向けのパスワードについては、さほど多くの字数が要件とはされていない。また、
ランダムに生成されたパスワードのエントロピーは、ユーザが選択するパスワードのエン
トロピーよりも高い。 システム管理用の本人認証については、一般に、より高いレベルの本人認証が要求され
ることになるが、本書が「レベル 3」以上の要件として規定するトークン等のデバイスを利用するようなWebコンテンツ管理用のリモートアクセス手段は見あたらない。後続のシーケンシャルマルウェアの中にクライアント PC 内に保存されている正規の FTP もしくはSSH のアカウントのパスワードを探査するものもあるようであるので、トークン等のデバイスに本人認証用の秘密データを待避できることが理想的ではある。当面は「複雑なパス
ワード」によってエントロピーを高めてしのぐことになろう。 OpenSSH には、長いパスワードを入力することができ、unix 用のものでは 128文字までの入力を許容できる。アウトソーシングされている実態のもとで、紙の契約文書と共に
オフラインで渡すことができるパスワード方式には有用性があり、必ずしもユーザが選択
しなければならない要件は無い場合が多い。 改ざん後の対策（パスワードの変更） ひとたび Gumblar 攻撃の一環として罠を Web コンテンツの中に埋め込まれてしまうよ
4 http://www.csc.liv.ac.uk/~greg/sshdfilter/ 5 http://mustan.ipa.go.jp/mustan_web/
－ 43 －
うなインシデントが発生した場合、強制的にパスワードを変更させる必要がある。この際
に、強制的にランダムに生成されたパスワードに切り替えることも考慮する価値がある。 2.3 実装についての話題
SP 800-63における「レベル 3」以上に相当するような、トークンを用いる、より強い本人認証機能の可能性を話題としたい。既述のように、シーケンシャルマルウェアの中には
クライアントPC内に保存されている正規のFTPもしくはSSHのアカウントのパスワードを探査する機能が実装されているものもあるようであるので、トークン等のデバイスに本
人認証用の秘密データを待避できることが理想的ではある。実際上、PKI（公開鍵インフラストラクチャ）技術に基づくことになるので、PKI 環境を構築・配備した環境をもつ組織体であれば導入できる。 (1) SSHについての実装
OpenSSHにおいて X.509 v3証明書を利用できるようにする実装の試みは、Petrov氏によって行われており OpenSSHがバージョンアップされるたびに更新されている。6 証明書管理については OpenSSL の証明書ストレージ（X509 Store）に依存した実装となっているので、認証機能も基本的に OpenSSLに依存していることになる。 本人認証においては、毎回、署名と証明書の検証するのがデフォルトとなっており、本
人認証に失敗すると署名が無効になるような記述もある。システム構成において選択する
項目は多い（例：暗号アルゴリズムの選択、証明書検証関連の選択、等）。 (2) FTPSについての実装 FTPSについて、クライアントの実装にもサーバの実装にも多くのもの実装された7 。これらの中には、経路の防護のみならず証明書管理についても OpenSSLに依存しているものが多い。 3. 出方向のパケットフィルタリング
3.1 出方向のトラフィックへの関心の経緯
組織のネットワークを防護する際に、とかく外部から内部への入方向（ingress）のトラフィックについての関心事が話題の中心となり、外部からの防護が重視されている。一方、
出方向（egress）のトラフィックにも固有のセキュリティ論点がある。例えば、正規のWebサイトを装うフィッシング（phishing）サイトへのアクセスや、マルウェアが掲載されているサイトへのアクセスを抑止するフィルタリング技術のような話題がある。ボットネッ
6 http://roumenpetrov.info/openssh/ 7 http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
－ 44 －
トが台頭してきたことを受けて2005年頃の対策文書の中に出方向のフィルタリングについての言及は見られる[8]。それ以前は、出方向のフィルタリングは、ISP（インターネットサービスプロバイダ）向けの話題であった[9]。ISP 単位の大きなドメインについて論じられていたこの話題は、組織単位で論じられる話題となった。 今般の関心事は、「いわゆるシーケンシャルマルウェアが、マルウェアを連続的にダウン
ロードするための外部サイトへのアクセスを抑止できないか？」という関心事であり、ネ
ットワークセキュリティについてのプロフェッショナル向けトレーニングの分野において
数年前から重要性が指摘されていた[10]。この関心事においては、Web アクセスを扱うHTTPトラフィック（80番ポート）も含めて扱うが、マルウェアが使う他のポート番号（例：IRC の 6660～7000 等）のトラフィックも扱うことになる。シーケンシャルマルウェアの挙動は、2008年末の Conflicker（Downadup）の蔓延時に注目された。この蔓延を受けて検討された追加的な推奨事項として出方向のトラフィックについてのフィルタリングが挙
げられている[11]。 出方向フィルタリングについての要件は、2008年10年に発行されたPCI（Payment Card
Industry）-DSS（Data Security Standard）のバージョン 1.2 [12] 以降のバージョンの 1.2.1節および 1.3.5.節にも見られる。
3.2 実装についての話題
具体的に、多くのブロードバンドルータにおいて出方向のフィルタリングを設定するこ
とは、現状では必ずしも容易ではないようである。出方向のフィルタリングを設定し易く
することは課題のひとつと言えよう。 IPv6環境を構築する際にも、今般、IPv4環境において起きている Gumblar攻撃のような脅威を想定して、この出方向のトラフィックの制御のような対策がし易い実装を用意し
ておくことが期待される。 以上
－ 45 －
参考文献
[1] 井上 大介，「Web媒介型攻撃 Gumblarの動向調査」
http://www.ipa.go.jp/security/fy21/reports/tech1-tg/b_05.html [2] RFC 4251, “SSH Protocol Architecture” (2006)
http://tools.ietf.org/html/rfc4251 [3] RFC 2228, “FTP Security Extensions” (1997)
http://tools.ietf.org/html/rfc2228 [4] RFC 4217, “Securing FTP with TLS” (2005)
http://tools.ietf.org/html/rfc4217 [5] SANS, Internet Storm Center Diary,
`Distributed SSH Brute Force Attempts on the rise again’, Published: 2010-06-18, http://isc.sans.edu/diary.html?storyid=9031
[6] NIST SP 800-63, “Electronic Authentication Guideline” Version 1.0.2 (2006) http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
[7] RFC 2577, “FTP Security Considerations” (1999) http://tools.ietf.org/html/rfc2577
[8] US-CERT Informational Whitepaper, “Malware Threats and Mitigation Strategies” (2005), http://www.us-cert.gov/reading_room/malware-threats-mitigation.pdf
[9] RFC 3013，「推奨される ISP セキュリティサービスと手順（Recommended Internet Service Provider Security Services and Procedures）」（2000） http://www.ipa.go.jp/security/rfc/RFC3013JA.html
[10] “Detecting and Preventing Unauthorized Outbound Traffic”, SANS (2007), http://www.sans.org/reading_room/whitepapers/detection/detecting-preventing-unauthorized-outbound-traffic_1951
[11] SANS Technology Institute. Group Discussion/Written Project GIAC Enterprises Downadup Incident (2009), http://www.sans.edu/resources/student_projects/200903_1.pdf
[12] PCI Security Standards Council, “PCI DSS Version 1.2”, https://www.pcisecuritystandards.org/
－ 46 －
8. QubesOS
面 和毅
1. コンセプト
QubesOS は、OS レベルでデスクトップのセキュリティを保護するために開発された、オープンソースの実装である。一般的に OS上のセキュリティを担保する手法は様々あるが、Qubes OS ではコンパートメント化によりセキュリティを担保するアプローチをとっている。 例えば、図 1のように OS上では様々なアプリケーションが動作している。その中でも、比較的危険度の高いWebブラウザや、メールクライアント、ネットゲームなどをそれぞれコンパートメント化し、業務で使用しているWork Dataの Spread Sheetや、その他アプリにアクセスできないようにする（図 1）。
図 1
また、同じWeb ブラウザでも、社内イントラ（Work Data）にアクセスするブラウザと、ショッピングをするブラウザ、社外情報閲覧用のWeb ブラウザは、それぞれのコンパートメントに分けて考える必要がある（図 2）。
－ 47 －
図 2
このようなコンセプトを実装するには、SELinux のように強制アクセス制御を付加し、各リソースをドメインに分けてコンパートメント化するような方法がある。しかし、この
方法では、Linuxカーネル自体にバッファオーバーフローなどの脆弱性が発覚した際に対応できない。また、ひとつのカーネル上ですべてのドライバ類をハンドリングするには、ACL（Access Control List）やポリシーなどが繁雑になりすぎ、ユーザが現実的に管理できなくなってくる。 2. QubesOSのモデル
QubesOSでは、このようなコンパートメントを VMを用いて実装する（そのため、Qubes「OS」と銘打っているが、実際には Xenを利用した VMによる実装となっているため、作者は"OS のディストリビューション"ではなく、"Xen のディストリビューション"であると言っている）。現状の、システムに対してひとつのカーネルを使用している状態では、すべ
てのドライバ類をハンドリングしなくてはならなくなるため、セキュリティリスクが高い。
そのため、一つのカーネルでシステムの機能をすべて提供し、ハンドリングするのではな
く、Hyper Visorを用い、各機能を提供する専用の VMを用意する。 図 3が QubesOSのモデル図になる。
－ 48 －
図 3
(1) Domain0
管理とセキュアな環境を提供する。Domain0 には Network 機能と Storage機能は含まれない。通常ユーザが使用するアプリケーションは Domain0で起動する。
Dom0は、2500行の Cコードで書かれているため、軽くかつ脆弱性が入る確率が低い実装になっている。
(2) Network Domain VM Network機能専用の（非特権な）VM。物理レイヤをコントロールする。
(3) Storage Domain VM Storage機能専用の（非特権な）VM。物理レイヤをコントロールする。
(4) Application VM Applicationを動作させる VM。QubesOSの名前の元になっている（Qube： ブロックのイメージ）。
各ドメイン（Work、Shopping、Randomなど）毎に起動され、ユーザにアプリケーションを提供する。非常に軽く、管理コンソールからアップデートが
可能である。 Application VMは Template VM（Read Onlyになっている）を元に作成される。
QubesOS では、これら Hyper Visor 環境および VM を新たに作り起こすのではなく、
Xenと Linux（それぞれカスタマイズされているもの）を用いて実現している。そのため、ユーザのデスクトップ環境はすべて Linux となっている。7 月 1 日に Fedora13 ベースのAlpha2がリリースされているため、これを用いて QubesOSをテストすることが可能である。 （将来には、Windowsの VMをサポートするかもしれないとも述べている。）
－ 49 －
3. 特徴
QubesOSの特徴としては、以下の 3点になる。
(1) Lightweight Virtual Machine ドメイン毎にいくつも VM ゲストを立ち上げなくてはならないため、起動が早く軽い
「lightweight Virtual Machines」を作成し、実装している。これは、既存の VM Guest（Linuxベース）をカスタマイズしたものになっている。 (2) ユーザに VMを使用していることを感じさせないインターフェース
(1)の Lightweight Virtual Machineを使用して、各ドメインでここにアプリケーションを立ち上げることになるが、その際にユーザには、それが VM を使用して立ち上がっ
ているということを意識させないような作りになっている。Qubes OSはデスクトップ用のセキュリティ実装のため、そのようなユーザビリティにもこだわっている。 過去にも NetTopなど、VMを使用して機密レベルを分けるような実装はあったが、ど
うしてもゲスト OSの枠内で動作していることが見た目で分かるようになっていた。しかし、QubesOSでは、見た目は一般のアプリが立ちあがっているようにしか見えず、ただアプリケーションに、ドメインを表す色つきのマークと、ドメイン名称しか表示されな
いようになっている（図 4）。また、異なるドメイン間で、Clipboard を通してコピーを行ったり、ファイルの転送も行うことができる（図 5および図 6）。ファイルを転送する際には、仮想の"pendrive"を作成して受け渡しに使用し、データが自動的に Application VM間を移動しないようになっている。
－ 50 －
図 4
図 5
－ 51 －
図 6
(3) Disposable（使い捨て）VM たとえ前述のように、Work用の AppVMや、Shopping用の AppVMにアプリケーシ
ョンを分けていても、Work AppVM内のソフトに脆弱性が出てしまった場合には、Work AppVM内にある他のソフトも影響を受けてしまう。例えば、Work AppVM内にメールクライアントがあった場合、あるユーザから送信されてきたメールに添付されている
PDF ファイルを見ようとしてダブルクリックしたら、脆弱性を利用するマルウェアであったという場合もあり得る。その際には、このマルウェアを通じて、Work AppVM内のブラウザにキャッシュされている情報や、Spread Sheetなどのデータを盗み見されてしまうかもしれない。また、そこからブラウザの脆弱性を攻撃されるという可能性もある。 あるいは、上述の PDFを念のために Random AppVMなど、他の AppVMに転送して
見てみると言う方法もある。しかし、その場合には、もし PDFが本当に仕事に関してのコンフィデンシャルな情報だった場合には、情報流出の危険性が生まれてしまう。 その様なときのために、Disposable VMのコンセプトが考えられた。これは、1s以内
で起動でき、かつ毎回クリーンな状態で立ちあがってくるような、ひとつのアプリ専用
に用意されたさらに軽い VM である。例えば、前述の例であれば、メールに添付されて
いる PDFを、Disposable VM内で動く PDFビューアでプレビューする（この際、操作性を考えて、右クリックで「Disposable VM でプレビューを行う」などと表示させ、そちらを選択するようにするプランである）。仮に PDF ファイルが正常のものであれば、Workドメインで改めて PDFビューアを用いて保存等を行えばよい。仮に PDFファイルにマルウェアが混入していた場合には、汚染されるのは Disposable VMだけである。ま
－ 52 －
た、この Disposable VMは毎回シャットダウン時に破壊してしまい、次回起動時にはまったく新しくクリーンな状態で立ちあがってくるため、この VM を介してのセキュリテ
ィ被害の拡大はない。これが、Disposable（使い捨て）と呼ばれる所以である。 QubesOS Beta1で実装予定である（実際には、操作性のところを解決したり、VMが
1s 以下で起動するようにしたりなど、実装しなくてはならない機能が多いため、時間がかかっている）。
4. インストール方法
Fedora13 ベースの Alpha2 がリリースされている。ハードウェアは 64bit の CPUのみが対象となっている。 基本的に Yumを利用してインストールすることになるが、最初にインストールするパッケージとして
Desktop Environments/KDE Applications/Editors Base System/Base Base System/Fonts Base System/Hardware Support Base System/X Window System
のみを選択しなくてはならない（Desktop Environmentは KDEのみが対応となる）。 Fedora13のセットアップ後は、Yumを用いて
Domain 0のカーネル Qubes OSをコントロールするツール 各 AppDomain用に起動する AppVM（Linux）のテンプレート SystemVM
をインストールしていくことになる。 5. 利用方法
QubesOSは、そのコンセプトからも、デスクトップのセキュリティを担保することが主眼となっている。そのため、オフィスで使用するマシンで
1. Work （業務用） 2. Shopping（購買用） 3. Random（その他、Web閲覧など多目的） のドメインを定義し、それぞれに
－ 53 －
1. Mailクライアント、OpenOffice、社内イントラ接続用Webブラウザ 2. Amazon等に購買用途で接続するためのWebブラウザ 3. 社外に接続するWebブラウザ、その他
を割り当てる。また、Disposable VM を用いて、主要なアプリケーションビューアがそれぞれ立ち上げられるようにしておき、メールにファイルが添付されていた場合には、常に
Disposable VMを用いてビューアで確認してから、Workドメインで開くようにする。 これにより、
a.) ブラウザその他に脆弱性があった場合に、社外に接続した際に脆弱性を利用するスクリプトなどを踏んでしまったとしても、業務データが流出する危険性はない。
b.) 逆に、最終的に Random ドメインに侵入を許すような事態になったとしても、業務デ
ータを改ざんするなどの行為は行えない。 c.) Shopping ドメインを通して個人情報が漏れてしまった場合でも、Work ドメインに侵入されることはない。
d.) 万一マルウェア等が添付されたメールがWorkドメインに来た場合でも、ビューアで開いた際にWorkドメインに被害をもたらすことはない。
という環境が実現できる。 現時点では VMゲストの対象が Linuxしかないため一般ユーザに進めるのには敷居が高いが、Windowsが VMゲスト対象に含まれるようになれば、一般ユーザに進めることができるようなソリューションであると考えられる。
以上