Embed Size (px)
Citation preview
情報セキュリティ技術動向調査
タスクグループ報告書
（2011 年下期）
2012 年 3 月
目次
序 2011年下期の技術動向 - 今日のセキュリティエンジニアリングの話題....................... 1 1. capsicum ............................................................................................................................ 3 2. NIST SP 800-63-1 電子認証に関するガイドライン....................................................... 13 3. OpenID Connect.............................................................................................................. 21 4. JOSE - Webオブジェクトツリーへのディジタル署名と暗号化..................................... 31 5. 非同期の他源泉リクエストと新たな脅威........................................................................ 37 6. クラウドコンピューティングセキュリティ - VXLAN／NVGRE によるネットワーク分離 .......................................................................................................................................... 47 7. インターネット経路制御のセキュリティに関する動向 - BGPSEC .............................. 54
1
序 2011年下期の技術動向 - 今日のセキュリティエンジニアリングの話題
宮川 寧夫 1 背景
「情報セキュリティ技術動向調査 TG（タスクグループ）」[1]は、その第 8回目の会合を2011年 12月 22日に開催した。情報セキュリティのエンジニアリングの分野において注目すべき動向を発表しあい、発表内容に基づいて討議した。 本報告書は、読者として IT技術者を想定している。IT技術者によるエンジニアリング活動の中で、注目すべき動向もしくは話題を各委員独自の視点から紹介・解説していただい
て本書を取りまとめた。 2 目的
本書は、読者として主に情報処理技術者を想定している。情報技術の「アーリーアドプ
ター（Early Adopters）」や「アーリーマジョリティ（Early Majority）」[2]と呼ばれるような先進的な技術に関心を寄せる読者に、そこで想定されている用途に関する情報を添え
て提供する。これによって、各自もしくは各組織における情報セキュリティに関するエン
ジニアリングの課題の解決に資するものとしたい。 なお、先進的な技術を題材とするため特定の実装を紹介することがあるが、オープンな
仕様が存在している場合、主にその仕様に基づいて解説するように留意している。 3 概況
今期、オペレーティングシステム FreeBSD 9.0に実装された capsicumというメカニズムを紹介する。これは、プロセス単位の特権制御よりも細かく、システムコール群にマス
クするような制御をつかさどるメカニズムである。 アイデンティティ管理の分野において、国際的にも注目されていた米国連邦政府文書が 5年ぶりに更新されて公開された。NIST（National Institute of Standards and Technology）の『電子認証ガイドライン』（SP 800-63-1）がその注目されていた文書であり、4レベルのユーザ認証要件（Level of Assurance）に応じて、それぞれに採用可能な技術を示している。また、オンラインのシングルサインオンや属性情報交換を行う OpenID2.0 の後継仕様は、別系統の仕様であった OAuth 2.0に基づいて策定されようとしている。 この OpenID Connect仕様は JWT（JSON Web Token）というセキュリティ機能を採用するが、この JWTデータに対するディジタル署名や暗号化を行うプロトコル仕様を策定すべく IETF（Internet Engineering Task Force）に JOSE（Javascript Object Signing and Encryption）というワーキンググループが設置された。
2
近年、ブラウザ側で動作するAjaxなWebアプリケーションが活発に開発されているが、新たな脅威モデルが想定される。その対策を概説する。 プライベートクラウドのクラウド側のネットワークを構築する際に、ネットワークの論
理分割に使える仕様として、2010年下期の OpenFlow仕様に続いて始まった VXLAN仕様と NVGRE仕様の策定状況を報告する。 最後にインターネットインフラストラクチャの経路制御を支えている BGP（Border
Gateway Protocol）にセキュリティの仕組みを加える拡張仕様である BGPSECを紹介する。
参照
[1] 情報セキュリティ技術動向調査 TG（タスクグループ） http://www.ipa.go.jp/security/outline/committee/isec_tech1.html
[2] ジェフリー･ムーア（著），川又 政治（訳），「ハイテク・マーケティング」『キャズム』，
翔泳社（2002）pp. 11-38
3
1. capsicum
面 和毅 1.1. 概要
FreeBSD9.0 からは、新たなセキュリティ機構としてケーパビリティを利用するcapsicum が実装された。ここでは、一般的なケーパビリティと、capsicum の使用方法を
説明する。 1.2. capabilityについて（POSIXケーパビリティと Linuxでの実装）
通常 Unixでは、プロセスは一般ユーザの権限で動くか、特権（root権限）で動くかの 2種類となる。たとえば、Apacheなどのサービスが 1024番未満のいわゆる「特権ポート」をプロセスで使用する際や、pingや snortなどのように生（raw）ソケットをイーサネットデバイスに対してオープンし、生の IPデータトラフィックを見る時、あるいは ntpd などでシステムの時刻を設定する際には、プロセスに特権が必要になる。 しかし、プロセスに特権をすべて与えてしまうと、動作しているプロセスに脆弱性があ
った場合に、不正な操作ですべての特権が取られてしまう可能性がある。 この問題は随分前から指摘されており、これを解決する方法として「ケーパビリティ
（POSIXケーパビリティ）」という提案が POSIXのドラフト 1003.1eとして提出されていた[1]。 これは、特権を更に細分化した「ケーパビリティ」と呼ばれる単位で取り扱う事ができ
るようにし、プロセスに必要最小限のケーパビリティを与えて、必要な処理だけを行わせ
ようというものになる。これにより、プロセスに脆弱性が発見されて悪用されたとしても、
そのプロセスに必要な最小限のケーパビリティしか悪用されないため、被害を局所化（コ
ンパートメント化）できるようになる。 この POSIXケーパビリティは、Linux上では「Linuxカーネルケーパビリティ」としてカーネル 2.4から採用されている。 最新のカーネル 3.2での POSIXケーパビリティを次に示す。
4
Linuxにおける Capability CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_FSETID CAP_KILL CAP_SETGID CAP_SETUID CAP_SETPCAP CAP_LINUX_IMMUTABLE CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_ADMIN CAP_NET_RAW CAP_IPC_LOCK
CAP_IPC_OWNER CAP_SYS_MODULE
CAP_SYS_RAWIO
CAP_SYS_CHROOT CAP_SYS_PTRACE CAP_SYS_PACCT CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_NICE CAP_SYS_RESOURCE CAP_SYS_TIME CAP_SYS_TTY_CONFIG CAP_MKNOD CAP_LEASE CAP_AUDIT_WRITE CAP_AUDIT_CONTROL CAP_SETFCAP CAP_MAC_OVERRIDE CAP_MAC_ADMIN CAP_SYSLOG CAP_WAKE_ALARM
それぞれのケーパビリティに関する詳しい説明は、Linux カーネルソース内の
/usr/src/linux/include/capability.hファイルに、コメントとして説明が載っている。 Linux カーネルケーパビリティを前提にしたプログラムは、既にいくつもリリースされている。 例えば、DNSの実装で有名な bindはソースコード中で、OSが Linuxだった場合に、プロセスのケーパビリティを一度初期化してから、必要最低限の
CAP_NET_BIND_SERVICE（ポートバインディングに必要）や、CAP_SYS_CHROOT（chroot化するのに必要）を付加している（コード 1）。
コード 1 ---bin/named/unix/os.c--- #ifdef HAVE_LIBCAP cap_t curcaps; cap_value_t capval; char strbuf[ISC_STRERRORSIZE]; int err; #endif /*% * We don't need most privileges, so we drop them right away. * Later on linux_minprivs() will be called, which will drop our * capabilities to the minimum needed to run the server. */ INIT_CAP; /* * We need to be able to bind() to privileged ports, notably port 53! */ SET_CAP(CAP_NET_BIND_SERVICE); /* * We need chroot() initially too. */ SET_CAP(CAP_SYS_CHROOT);
5
これにより、Linux 上でケーパビリティによる制御を有効にしている場合には、bind にセキュリティホールが見つかり悪用されたとしても、攻撃者はすべての特権ではなく一部
のケーパビリティ（CAP_NET_BIND_SERVICE や CAP_SYS_CHROOT）しか取得できないため、被害を局所化することが可能になっている。 1.3. capsicumについて
(1) capsicumと FreeBSD 9.0 一方、FreeBSDでは、FreeBSD 9.0から、capsicumと呼ばれるケーパビリティ制御機構が実装された。capsicum は、Linux での Capability と違い、ソースコードレベルでのCapability の操作を主体に考えた実装となっており、各プログラムのソースコード中で、プログラムが使用するファイルディスクリプタをすべて用意した後に、そのプログラムを
「ケーパビリティモード」と呼ばれる状態に移行し、それ以降はそのプログラムがディス
クリプタを新たに作成できないようにする事で、そのプログラム上で想定外のアクセスに
よる不正アクセスが発生した場合でも、使用できるリソースを規制するというものである。 capsicumによって提供されるセキュリティは、ユーザ側で何か変更をするというものではなく、プログラム提供者が capsicumの機能を利用するようにソースコードを変更していくというものになる。そのため、ユーザ側にとっては、特に使い勝手が変わることなく、
今までよりも高セキュリティになったシステムを使用できる事になる。 一方開発者側にとっても、capsicum対応にはロジック変更が必要無いため、実装することはそれほど難しくない。 実際、FreeBSD 開発者会議ではすでに、capsicum をどのライブラリやコマンドに適用
させるかの議論まで進んでおり、google chrome のオープンソース版である chromium などでは既に採用されている。 (2) capsicumを有効にする 9.0-Release の時点では、capsicum を使用するにはカーネルを再構築する必要がある。
このためには、/sys/[アーキテクチャ]/conf/以下に CAPSというファイルをリスト 2のように作成し、リスト 3の手順で CAPS ファイルを含んだカーネルを構築／インストールして再起動する。
リスト 2 include GENERIC ident CAPS # enable Capsicum options CAPABILITIES options CAPABILITY_MO
6
リスト 3 cd /usr/src/ make KERNCONF=CAPS buildkernel make KERNCONF=CAPS installkernel
(3) capsicumの使い方
capsicumでは、ファイルディスクリプタを介してケーパビリティ（許可する操作を設定した、特別なファイルディスクリプタ）を作成する。この際に使用できるケーパビリティ
には、次のようなものがある。
capsicumにおける capability CAP_READ CAP_WRITE CAP_MMAP CAP_MAPEXEC CAP_FEXECVE CAP_FSYNC CAP_FTRUNCATE CAP_SEEK CAP_FCHFLAGS CAP_FCHDIR CAP_FCHMOD CAP_FCHOWN CAP_FCNTL CAP_FPATHCONF CAP_FLOCK CAP_FSCK CAP_FSTAT CAP_F CAP_EXTATTR_DELETE CAP_EXTATTR_GET CAP_EXTATTR_LIST CAP_EXTATTR_SET CAP_ACL_CHECK CAP_ACL_DELETE CAP_ACL_GET STATFS CAP_FUTIMES CAP_CREATE CAP_DELETE
CAP_MKDIR CAP_RMDIR CAP_MKFIFO CAP_LOOKUPCAP_ACL_SET CAP_ACCEPT CAP_BIND CAP_CONNECT CAP_GETPEERNAME CAP_GETSOCKNAME CAP_GETSOCKOPT CAP_LISTEN CAP_PEELOFF CAP_SETSOCKOPT CAP_SHUTDOWN CAP_SOCK_ALL CAP_MAC_GET CAP_MAC_SET CAP_SEM_GETVALUE CAP_SEM_POST CAP_SEM_WAIT CAP_POLL_EVENT CAP_POST_EVENT CAP_IOCTL CAP_TTYHOOK CAP_PDGETPID CAP_PDWAIT CAP_PDKILL CAP_MASK_VALID
capsicumが有効になったシステムでは、各プログラム中で cap_enter()を呼び出すと、プログラムはケーパビリティモードと呼ばれるモードに移行される。 このケーパビリティモードでは次のような制限が加わる。
1. 新たなファイルディスクリプタを取得することができなくなる。 2. 図 1に示すような、グローバルなファイルシステムにアクセスできなくなる。
7
図 1：グローバル ネームスペース
3. 既に作成されたファイルディスクリプタを介して与えられたケーパビリティをベースにして、新たに別のケーパビリティを作成できる。
4. 3.の新たなケーパビリティは、権限を拡大することはできず、縮小することのみが可能である。
5. プログラムがケーパビリティモードに入っている際に fork されたプロセスはケーパビリティモードに入っており、ケーパビリティが引き継がれる。
プログラムがこのケーパビリティモード中で使用できるケーパビリティを定義するため、
capsicumでは、cap_new()を使用する。 例として、サンプルプログラム 1を見てみよう。
サンプルプログラム 1
#include <stdlib.h> #include <stdio.h> #include <fcntl.h> #include <unistd.h> #include <err.h> #include <errno.h> #include <sysexits.h> #include <sys/capability.h> main(void) { int fd1, fd2, ret, len, cap1, cap2; char insert_txt[]="write_test"; char content1[BUFSIZ]; char content2[BUFSIZ]; fd1 = open("READ_WRITE", O_RDWR); if (-1 == fd1)
8
err(EX_NOPERM, "open error: %d", errno); fd2 = open("READ_ONLY", O_RDWR); if (-1 == fd2) err(EX_NOPERM, "open error: %d", errno); // add capability cap1 = cap_new(dup(fd1), CAP_READ | CAP_WRITE | CAP_SEEK ); // ----a. if (cap1 == -1) err(EX_NOPERM, "cap_new(1) error: %d", errno); close(fd1); // -----b. cap2 = cap_new(dup(fd2), CAP_READ | CAP_SEEK ); if (cap2 == -1) err(EX_NOPERM, "cap_new(1) error: %d", errno); close(fd2); // enter capability mode cap_enter(); ret = write(cap1, insert_txt, 10); // --- c. if (-1 == ret) err(EX_NOPERM, "read error: %d", errno); len = read(cap1, content1, BUFSIZ); if (-1 == len) err(EX_NOPERM, "read error: %d", errno); printf("%s¥n", content1); ret = write(cap2, insert_txt, 10); // --- d. if (-1 == ret) // --- d. err(EX_NOPERM, "read error: %d", errno); // --- d. len = read(cap2, content2, BUFSIZ); if (-1 == len) err(EX_NOPERM, "read error: %d", errno); printf("%s¥n", content2); return; }
まずプログラム中の a.のように、取得済みのファイルディスクリプタに対して、どのケーパビリティを使用することが出きるかを宣言しておく。この際には、cap_new(2)ではdup()で複製したファイルディスクリプタを用いて、ケーパビリティの宣言をするのが通例である。ケーパビリティ宣言後は、ケーパビリティが宣言されているファイルディスクリ
プタを使用するため、元のファイルディスクリプタは使用しないので、b.のように close()しておく。
cap_enter()によってケーパビリティモードに移行した後は、こうしてケーパビリティを与えられたファイルディスクリプタに対して c.のように read/writeなどの処理を行う。
9
この際に、CAP_WRITEが与えられていないファイルディスクリプタ（cap2)に対して、d.のように writeの処理を行うと、次のように「ケーパビリティが足りない」というエラーが出力される。
> gcc -o sample3 sample3.c > ./sample3 sample3: read error: 93: Capabilities insufficient
d.の箇所を削除して再度コンパイルして実行すると、次のように処理が成功する。
> ls -l READ_* -rw-r--r-- 1 omok omok 29 Feb 6 00:56 READ_ONLY -rw-r--r-- 1 omok omok 0 Feb 6 00:56 READ_WRITE > more READ_WRITE > more READ_ONLY This is read-only test file. > gcc -o sample3 sample3.c > ./sample3 This is read-only test file. > more READ_WRITE write_test > more READ_ONLY This is read-only test file. > ls -l READ_* -rw-r--r-- 1 omok omok 29 Feb 6 00:56 READ_ONLY -rw-r--r-- 1 omok omok 10 Feb 6 00:57 READ_WRITE
(4) capsicumを使用した例 最後に、capsicumを使用した際に攻撃されるとどうなるかの例を、簡単にみてみよう。 サンプルとして、バッファーオーバーフローを起こす脆弱性のあるプログラムを作成する
（サンプルプログラム 2）。
サンプルプログラム 2 #include <stdlib.h> #include <stdio.h> #include <fcntl.h> #include <unistd.h> #include <err.h> #include <errno.h> #include <sysexits.h> #include <sys/capability.h> void copy_to_buff(char *input)
10
{ char buf[8]; strcpy(buf, input); } void main(int argc, char *argv[]) { // enter capability mode cap_enter(); if (argc > 1) { copy_to_buff(argv[1]); printf("Input %s¥n", argv[1]); } }
プログラムの所有者は rootにし、さらに Sticky bitを立てておく（通常ありえない設定であるが、あくまで攻撃のサンプルのため）。この状態で、攻撃用のコードを一般ユーザ
omokで実行すると、バッファーオーバーフローの脆弱性を使用して、rootユーザでシェルが開かれてしまう。
> ./sample aaa Input aaa > ls -l sample -rwsr-xr-x 1 root omok 4998 Feb 6 02:13 sample > ./exploit # id uid=1001(omok) gid=1001(omok) euid=0(root) groups=1001(omok),0(wheel) # whoami root # touch /root/exploit_rec # ls -l /root/exploit_rec -rw-r--r-- 1 root wheel 0 Feb 6 02:16 /root/exploit_rec しかし、このプログラムが（バッファーオーバーフロー脆弱性のある場所の前に）ケー
パビリティモードに移行していた場合にはどうなるか。サンプルプログラム 2 のように、copy_to_buff()を呼び出す前に cap_enter()を実行してケーパビリティモードに移行していれば、以降はグローバルなファイルシステムにアクセスできなくなるため、root でシェルが開けなくなる。
> ./sample aaa Input aaa > ls -l sample -rwsr-xr-x 1 root omok 4998 Feb 6 02:13 sample > ./exploit aaa > <------- exploitでシェルが開けなくなる
11
このように、ファイルディスクリプタの割り当てとケーパビリティの割り当てなどの必
要な処理を施した後に、ケーパビリティモードに移行しておけば、プログラムに想定外の
脆弱性があっても、必要最低限の権限しか与えられていないため、被害を（完全には防げ
ないものの）局所化出来ることが分かる。 1.4. まとめ
ケーパビリティは、SELinuxなどのように動作の主体（Subject）／対象（Object）の両方に対してラベルを設定し、アクセス権を与えていく様なセキュリティ機構に比べて、
Subjectに対してのみアクセス権を加えていくため、設定が（理論上、当然粗くなるが）簡単になる。また、Object の変更に左右されないため、実際の運用環境のように、アクセス対象のファイルが個々のシステムによって生成／改変されていくような状況でも、Subjectは変更されにくいために、いちいち設定をカスタマイズ化／修正運用していく手間が少な
いため、より実運用に向いているといえるだろう。 このようにケーパビリティを利用してシステムを設計していけば、一般的な DAC（Discretionary Access Control）の仕組みを生かしつつ被害の局所化などでセキュリティを高められるため、ぜひ推奨したい。
以上
12
参考文献
[1] "Summary about Posix.1e"
http://wt.tuxomania.net/publications/posix.1e/ 参考資料
「権限を最小化する Linuxカーネルケーパビリティ」
http://www.atmarkit.co.jp/fsecurity/rensai/lids03/lids01.html 「FreeBSD Daily Topics 新セキュリティ「Capsicum」」
http://gihyo.jp/admin/clip/01/fdt/201111/08 「IPA セキュアプログラミング講座」 （旧）第 6章 セキュア C/C++プログラミング（「6-1. バッファオーバーラン ～その１・こうして起こる～」） http://www.ipa.go.jp/security/awareness/vendor/programmingv1/b06_01.html
13
2. NIST SP 800-63-1 電子認証に関するガイドライン
金岡 晃 2.1. はじめに
SP 800-63-1文書[1]は、米国 NIST（National Institute of Standards and Technology：国立標準技術研究所, NIST）が発行する SP（Special Publications）シリーズのひとつであり、米国 OMB（Office of Management and Budget：行政管理予算局）が米国各省庁および各政府機関長官宛に発行したガイダンス OMB M-04-04「連邦政府機関向けの電子認証にかかわるガイダンス（E-Authentication Guidance for Federal Agencies）」を上位ポリシーとしたガイドラインである。 ガイドラインは OMB M-04-04にある 4レベルの保証をベースに、認証に係る作業（登録、本人確認、トークン、認証プロトコル）について記載されている。
SP 800-63自体は 2004年 6月に発行され、2004年 9月の Versioin1.0.1、2006年 4月の Version1.0.2 [2]を経て、2011年 12月に SP 800-63 Revision 1（SP 800-63-1）[1]として発行された。 2.2. 800-63からの変更点
SP 800-63からの変更点として、文書内で挙げられているポイントは以下の通りである。 トークン種類の増加 アサーションプロトコルと Kerberosに対する詳細要件 「トークンとクレデンシャル管理（Token and Credential Management）」章の新設 パスワードエントロピーと認証試行制限（スロットリング、Throttling）についてのガイドラインの単純化
SP 800-63-1が連邦政府機関 ITシステム向けの文書であることの強調 異なるモデルの承認（より広い電子認証モデル、プロキシを利用するアサーション
モデル） 認証レベル 3と 4間の差異を明確化 派生クレデンシャル（Derived Credential）発行を行なう既存クレデンシャルのレベル付けを行なうガイドラインの新設
大きな内容変更は上に挙げた通りであるが、文書量と章構成も大きく変わっている。新
たな章として「トークンとクレデンシャル管理（Token and Credential management）」、「アサーション（Assertions）」が追加されており、また文章量は参考文献、付録を含めた総ページ数が 54ページから 110ページとほぼ倍増となっている。増加分は新規追加の 2章だけでなく、既存の各章もそれぞれ文章量が増加している。
14
本調査では新規追加された 2 章に加え、種類が増加したトークンに焦点を当てて解説する。 2.3. トークン種類の増加
SP 800-63では 4種類だったトークンは、本改訂で 9種類へと増加している。本ガイダンスでのトークンとは、認証要求者が所持し管理しているなんらかの情報であり、認証要
求者の身元識別情報の認証に使用されるものを指す。 SP 800-63では「パスワードトークン（Password Token）」、「ワンタイムパスワードデバイストークン（One-time Password Device Token）」、「ソフトトークン（Soft Token）」、「ハードトークン（Hard Token）」の 4種類であったが、SP 800-63-1では「記憶された秘密トークン（Memorized Secret Token）」、「事前登録知識トークン（Pre-registered Knowledge Token）」、「ルックアップ秘密トークン（Look-up Secret Token）」、「帯域外トークン（Out of Band Token）」、「単要素ワンタイムパスワードデバイス（Single-factor (SF) One-Time Password (OTP) Device）」、「単要素暗号デバイス（Single-factor (SF) Cryptographic Device）」、「複数要素ソフトウェア暗号トークン（Multi-factor (MF) Software Cryptographic Token）」、「複数要素ワンタイムパスワードデバイス（Multi-factor (MF) One-Time Password (OTP) Device）」、「複数要素暗号デバイス（Multi-factor (MF) Cryptographic Device）」の 9種類となった（表 1）。
表 1：トークン種類の増加
15
9つの各トークンの概要を表 2に示す。
表 2：トークンの概要
16
トークンに対する脅威も細分化されている。SP 800-63では認証の基本要素である「知っていること（Something You Know）」「持っているもの（Something You Have）」「持っている特徴（Something You Are）」の 3種類について脅威が語られていたが、SP 800-63-1ではより具体的に 8種類の脅威を挙げ、それらについての脅威軽減策が述べられている（表3）。またそれぞれのトークンが利用可能な保証レベルについても定めている（表 4）。
表 3：トークンへの脅威/攻撃
表 4：トークンタイプと利用可能な保証レベル
2.4. トークンとクレデンシャル管理
7章の「トークンとクレデンシャル管理（Token and Credential Management）」は、SP
17
800-63-1 で新設された章である。トークンやクレデンシャルの管理について、そのライフサイクルに関わる作業（Activities）とその脅威について記載されている。それらの作業は以下の項目となっている
クレデンシャルストレージ（Credential Storage） トークン・クレデンシャルの検証サービス（Token and Credential Verification
Services） トークン・クレ デンシャル の更新 /再発 行（ Token and Credential
Renewal/Re-issuance） トークン・クレデンシャルの失効と破棄（Token and Credential Revocation and
Destruction） 記録保持（Records Retention） セキュリティ制御（Security Controls）
また、これら作業における脅威が挙げられている（表 5）。
表 5：トークンとクレデンシャル管理に関わる脅威/攻撃
この章ではこれらの作業と脅威について、保証レベルごとに要件が示されている。
18
2.5. アサーション
SP 800-63-1 で新たな章として追加されたアサーションは、SP 800-63 でも Cookie とSAMLについて取り上げられていた。また SP 800-63の「認証プロトコル」章に、受け入れるアサーションについての記載もあった。しかしひとつの章として独立したものではな
く、アサーションそのものについての脅威分析やそれら脅威に対する保証レベルごとの要
件については記載されていなかった。 SP 800-63-1では新たな章としてアサーションの利用モデル、脅威と対策、そして保証レベルごとの要件などの詳細を述べている。 アサーションを用いる認証のモデルとして、「直接アサーションモデル（Direct Assertion
Model）」、「間接アサーションモデル（Indirect Assertion Model）」、「プロキシモデル（Proxy Model）」の 3つが挙げられている。それぞれの概要図を図 1、図 2、図 3に示す。
図 1：直接アサーションモデル
図 2：間接アサーションモデル
19
図 3：プロキシモデル
アサーション種類はクッキー（Cookies）、SAML（Security Assertion Markup Language）アサーション、Kerberos チケットの 3 種類が示されている。このうち Kerberos チケットは SP 800-63には記載のなかったものである。 アサーションに対する脅威は「アサーションの自作／変更（ Assertion
Manufacture/Modification）」、「アサーションの開示（Assertion Disclosure）」、「検証者によるアサーションの否認（Assertion Repudiation by the Verifier）」、「加入者によるアサーションの否認（Assertion Repudiation by the Subscriber）」、「アサーションリダイレクト（Assertion Redirect）」、「アサーションの再利用（Assertion reuse）」、「二次認証子の自作（ Secondary Authenticator Manufacture）」、「二次認証子の保存（ Secondary authenticator capture）」、「アサーションの代用（Assertion Substitution）」の 9種類が挙げられており、それらに対する保護機構が各保証レベルで求められている。それぞれの脅
威に対して各保証レベルが要求する耐性は表 6の通りである。
表 6：アサーションの脅威と保証レベル
*Kerberosを除く
20
2.6. まとめ
SP 800-63-1では、SP 800-63と比較してトークン種類やトークンとクレデンシャル管理、アサーションに対する記載の充実化が行なわれ、また既存部分の記載も追記・修正が行な
われるなど大きな改訂となった。 その背景には SP 800-63が公開された 2004年（Version 1.0.2は 2006年）以降、電子認証を巡る状況が大きく変わったことが挙げられる。とくにトークン種類や、アサーション
の重要性の高まりは SP 800-63公開以降最も変化があったことと言えよう。 また SP 800-63-1には、「米国連邦政府機関のシステム向けである」と明記した部分も増えた。これは SP 800-63が本来対象としていた米国連邦政府機関のシステムを越えて世界で広く参照されてきたことに対する NIST の意志表示であると考えられるが、逆の見方をすればこの文書の電子認証分野での重要性をあらためて示すことにもなっており、SP 800-63-1もより広く参照・言及される文書となるであろう。
以上 参考資料
[1] SP 800-63 Rev. 1, "Electronic Authentication Guideline" (Dec. 2011)
http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf
[2] SP 800-63 Version 1.0.2, "Electronic Authentication Guideline" (Apr 2006) http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
21
3. OpenID Connect 工藤 達雄
3.1. はじめに
本報告では 2011年下半期のアイデンティティ管理技術に関する動向として、OpenID 仕様の次期バージョンとなる予定のOpenID Connect [1]の概要を紹介する。OpenID Connectは、OpenID 2.0の次期バージョンとなる予定の仕様群である。現在、米国 OIDF（OpenID Foundation）の OpenID AB/Connect ワーキング・グループ[2]にて、仕様策定の議論が進行している。 3.2. OpenID Connect登場の背景
現行の OpenID 仕様である OpenID Authentication 2.0および OpenID Attribute Exchange 1.0（以下「OpenID 2.0」と表記）は、ふたつのWebサイト間における、Webブラウザを用いたアイデンティティ情報（エンドユーザの認証結果と属性情報）の要求・
提供を行うためのプロトコルとして、2007年 12月に策定された[3]。現在までに、インターネットサービス事業者（例： Yahoo!、Google、ミクシィ）、携帯通信事業者（例： NTTドコモ、KDDI、ソフトバンク）、ネット決済事業者（例： 楽天（楽天あんしん支払いサービス）、PayPal）などのような、多数のユーザを抱えるWebサイトが、他社WebサイトにID情報を提供するための API（Application Programming Interface）として OpenIDを採用している。OpenID 2.0仕様では、ID情報を要求するWebサイトを RP（リライング・パーティ）、一方、提供するWebサイトを OP（OpenIDプロバイダ）と称する。同仕様のフロー概要を以下に示す（図 1）。
図 1：OpenID 2.0のフロー概要
22
OpenID 2.0 は実装を容易にするために、ユースケースを「OpenIDプロバイダの ID情報を用いた、RPへのログイン／属性提供」に限定した仕様となっている。その結果、以下のような要件を満たすことは、仕様の範囲内では容易ではない（図 2）。
図 2： OpenID 2.0の課題
機能の制限された Web ブラウザへの対応
OpenID 2.0 では、ユーザ・エージェントとして一般的なWebブラウザを対象としており、ある程度大きな URL長を処理する能力や、リダイレクト機能などを有する必要がある。そのため、携帯端末などのように機能が制限された環境のWebブラウザでは、OpenID 2.0 プロトコルを処理できない場合がある。
セキュリティ要件への対応
OpenID 2.0 プロトコルでは、Web サイト間での ID情報の要求（認証リクエスト）ならびにその提供（アサーション）は、Web ブラウザのリダイレクト機能を用いて、平文のメッセージをやりとりすることにより行われる。そのため、OpenIDプロバイダが RP に対して提供したアサーションの内容が、Web ブラウザにおいて露見することになる。 またメッセージには改竄防止のために署名を付加するが、Web サイト間での共通鍵を用いるため、認証リクエストやアサーションの否認防止にはならなかった。
実装しやすさの改善
23
先に述べた通り、OpenID Authentication 2.0仕様では、Webサイト間でのメッセージ交換に署名を付与することになっており、そのための鍵の交換をWebサイト同士が動的に行う必要がある。
Webサイトはこの機能を実装するにあたり、スクラッチからではなく、OpenID 2.0に対応したフレームワークやライブラリを用いることが一般的である。しかし既存シ
ステムへのライブラリの導入ができない、広く使われているライブラリが存在しない
などといった制約から、OpenID 2.0 に対応することが難しくなっている場合もあった。 Web サイトではないアプリケーションに対する ID情報の提供
OpenID 2.0 が対象とするユースケースはWebサイト間での ID情報の要求・提供であり、スマートフォンにインストールされたネイティブ・アプリケーションや、Webブラウザにダウンロードされた JavaScriptアプリケーションなどの、これらWebサイトではないアプリケーションが RPとなる用途には向いていない。
サービス連携との組み合わせ
近年、APIを提供する事業者が、自社外のサービスやアプリケーションに対し、API へのアクセス権をユーザの同意に基づき認可するユースケースが増えてきており、そ
のアクセス権許可のプロトコル標準として OAuth[4]が普及してきている。 ただし OAuthはあくまでアクセス権限提供のためのものであり、OAuthの認可シーケンスの中で認証結果と属性情報を扱うための規定は含まれていない。OpenIDのシーケンスに OAuth の認可フローを組み合わせ、ID 情報の要求・提供とアクセス権委譲を同時に行う「OpenID/OAuth Hybrid」という手法が存在するが [5]、同手法では結局 OpenIDと OAuthの双方を実装しなくてはならず複雑なことから、広く利用されるには至っていない。 結果的に、独自の「アイデンティティ API」を定義し、OAuthによるアクセス認可を行うサービスが多数存在することになり、API を利用する側からは、個々の仕様に対応する必要が発生していた。 これらの課題に対し OpenIDコミュニティでは、OpenID 2.0 策定以降、OpenID CX（Contract Exchange）[6]や AB（Artifact Binding）[7]などのワーキング・グループを OIDF 配下に設置し、仕様の改良を進めてきた。一方 2010 年、これらの活動とは別に、OAuth 2.0をベースとする新たな OpenID仕様「OpenID Connect」の試案がコミュニティの一部から提唱された [8]。 その後 OpenID コミュニティはこの試案に、従前の CXと ABの議論を反映し、現在の OpenID Connect仕様の策定を進めている。
24
3. 3. OpenID Connect 仕様
(1) 特徴
OpenID Connect 仕様の主な特徴を以下に示す。 OAuth 2.0仕様に準拠した上で、ID情報の要求・提供の機能を定義している。これにより、実装の容易性や様々な種類のデバイスへの対応など、OAuth 2.0 仕様の特長を引き継ぎながら、後述する「シンプルな認証結果と属性情報の取得」のユースケース
であれば、一般的な OAuth 2.0認可+ APIアクセスとほぼ同様のフローによって実現することができる。さらに OAuth 2.0のアクセス権限提供のしくみはそのまま利用可能であるため、ID連携とサービス連携が単一のプロトコルによって処理することができるようになり、実装者の負担軽減にもつながることになる。
メッセージ形式に JSON（JavaScript Object Notation）[9]を採用し、加えて JWT（JSON Web Token）[10]を活用することにより、公開鍵暗号方式によるメッセージへの署名と暗号化もサポートする。これにより、送信されたメッセージの真正性の保証
や、意図しないアサーション露見の防止が可能となる。 仕様のモジュール化により、要件に応じてどのように仕様を利用するか（プロファイ
リング）が容易になっている。これにより、例えば仕様の最小範囲を利用しクライア
ント側の対応を容易にする、あるいはセッション管理仕様を加えてサービス間でのシ
ングル・サインオンを実現する、そして否認防止や暗号化などを規定し高い保証レベ
ルを実現する、といったように、さまざまな用途への適用が可能となる。 (2) 仕様の構成
OpenID Connect仕様は、以下より構成されるプロトコル・スイートである（図 3）。なお同仕様の記述に従い、OpenID 2.0における RP を、以降は「クライアント」と表記する。
図 3：OpenID Connectプロトコル・スイート
（https://openid.net/connect/の図「OpenID Connect Protocol Suite」を元に作成）
25
OpenID Connect Messages 1.0 [11] エンドポイントおよび関連するメッセージ形式の仕様。
OpenID Connect Standard 1.0 [12] OpenID Connect Messages 1.0の HTTPプロトコルへのバインディング仕様。
OpenID Connect Basic Client 1.0 [13] クライアントとなるWebサイト向けの、理解しやすく実装しやすい、OpenID Connect Standard 1.0 のプロファイル仕様。
OpenID Connect Dynamic Client Registration 1.0 [14] クライアントが、動的に自身の情報を OpenID プロバイダに登録し、OpenID プロバイダから必要なクレデンシャルを取得する方法を定義する仕様（オプション）。
OpenID Connect Discovery 1.0 [15] クライアントが、ユーザの OpenIDプロバイダならびにその OpenIDプロバイダのエンドポイントを発見する方法を定義する仕様（オプション）OpenID プロバイダが OpenID Connect Discovery 1.0と本仕様に対応することにより、クライアントはエンドユーザの指定した識別子をもとに未知の OpenID プロバイダを発見し、信頼関係を確立するという、現行の OpenID 2.0と同様の機能を実現できるようになる。
OpenID Connect Session Management 1.0 [16] OpenIDプロバイダ／クライアント間でのユーザ・セッションのライフサイクル管理・同期の方法を定義する仕様（オプション）。
OAuth 2.0 Multiple Response Type Encoding Practices [17] OAuth 2.0 仕様の response_typeパラメータに指定するOpenID Connect特有の値の定義と、その値の扱い方に関するガイダンス。
(3) OpenID Connectのフロー
OpenID Connectのフローを以下に示す（図 4）。基本的には OAuth 2.0の認可フローに従っており、認可リクエストのパラメータ（scopeや、response_typeなど）に指定する値や、独自のトークン（ID トークン）の追加、トークンを用いた ID 情報の取得方法などが新たに拡張されている。
26
図 4：OpenID Connectのフロー概要
3. 4. ユースケース
OpenID Connectの適用例を以下に挙げる。 (1) シンプルな認証結果と属性情報の取得
OpenID Connect フローを実行した結果、クライアントは認可サーバから、OpenID Connectが規定する「ID トークン」と、OAuth 2.0の「アクセス・トークン」という、2種類のトークンを得る。クライアントはこれらのトークンをもとに、認証結果と属性情報
を取得する。 まず認証結果（例： ユーザ識別子（user_id）、認証日時（auth_time）など）は、IDトークンに含まれている。IDトークン（id_token）は JWT形式の文字列であり、JWS（JSON Web Signature）によって署名されている。クライアントは自ら IDトークンのデコードと署名の検証をするか、もしくは同等の処理を行う外部の「Check IDエンドポイント」に IDトークンを送信し、JSON 形式の認証結果を抽出する。 次に属性情報は、アクセス・トークンを用いてUserInfoエンドポイントにアクセスし取得する。どの属性情報を要求するかは、クライアントがフロー開始時の認可リクエストの
scopeパラメータに、取得したい「クレーム（ここでは、エンドユーザの ID情報の種類）」を記述することで指定する。仕様に規定されているクレームは profile（一般的なユーザ属性）、email（メールアドレス）、address（住所）、phone（電話番号）の 4種類であり、これらは複数同時に記述可能である。UserInfoエンドポイントからのレスポンスは JSON形式となる。
27
(2) 仕様に規定されている以外の属性の取得
クライアントが規定以外の独自クレームを取得したい場合には、認可リクエストの scopeにそのクレーム名を指定する。さらに要求する属性を指定したい場合には、「リクエスト・
オブジェクト」を用いる。 リクエスト・オブジェクトとは認可サーバへのリクエスト・パラメータを JWT形式にエンコードしたものであり、認可リクエストのパラメータに同オブジェクトそのもの、もし
くは同オブジェクトの場所を指定する。 (3) 認証コンテキストの指定
OpenID Connect では、クライアントと認可サーバ間での認証コンテキスト(Authentication Context Class Reference）の要求・提供方法を規定している。クライアントは認可サーバへの認可リクエストに際し、リクエスト・オブジェクトに、要求する認証
コンテキストを記述する。同様に認可サーバは、エンドユーザの認証結果である IDトークンに、認証コンテキストを含めて返却する。 認証コンテキストとして記述可能な値は以下の 3種類である。
"0", "1", "2", "3", "4"
1 から 4 は、ITU-T X.1254 | ISO/IEC 29115 Entity Authentication Assurance [18] の規定する保証レベル。0 は、エンドユーザの認証が同保証レベル 1 の要件に適合しないことを示す場合に指定。
絶対（absolute）URI An IANA registry for Level of Assurance (LoA) Profiles [19]に登録されている名称
(4) UserInfoエンドポイントの外部にあるクレームの取得
OpenID プロバイダ は、自身以外の外部の「クレーム・プロバイダ」が表明するクレームを、クライアントに提供することができる。提供方法として、外部クレームの実体を含
む「集約（aggregated）クレーム」と、外部クレームへの参照（実体を取得するための情報）を含む「分散（distributed）クレーム」のふたつが規定されている。 3. 5. 現在の状況と今後
OpenID Connect 仕様群のうち OpenID Connect Session Management 1.0を除く仕様が、OIDF会員の投票より、2012年 2月 16日に実装者ドラフトとして承認された[20]。今後、仕様の最終レビュー、投票を行い、仕様確定に至る見込みである。 実サービスへの適用状況としては、Googleや Salesforce.com、VZnetなどが、検討段階の仕様の一部を自社サービスに採り入れている[21][22][23]。また 2011年 12月に開催され
28
た OpenID Summit Tokyoにおいて、楽天、Yahoo! JAPAN、日本経済新聞社などが、自社サービスに OpenID Connectを採用する予定であると表明した[24]。 3. 6. まとめ
OpenID Connectは OpenID 2.0を OAuth 2.0ベースに作り直すというだけのものではなく、既存の ID連携仕様である SAML（Security Assertion Markup Language）[25]やWS-Federation [26]の実世界での適用パターンや、さらには事業者独自の OAuthベースのアイデンティティ APIなどを分析し、仕様化したものとなっている。 SAMLや WS-Federationの仕様改版の動きがないこと、また OAuth 2.0ベースのアイデンティティ API として他に標準となりうる仕様が存在しないことから、今後エンタープライズ分野／コンシューマー向けサービス分野の双方において、OpenID Connect採用の検討が進むものと思われる。
以上 参考資料
[1] Connect | OpenID https://openid.net/connect/
[2] AB/Connect Work Group | OpenID
https://openid.net/wg/connect/ [3] 情報処理推進機構：情報セキュリティ：調査・研究報告書：情報セキュリティ技術
動向調査（2008年上期）9 アイデンティティ管理技術 http://www.ipa.go.jp/security/fy20/reports/tech1-tg/1_09.html
[4] OAuth Community Site
http://oauth.net/ [5] draft: OpenID OAuth Extension
http://svn.openid.net/repos/specifications/oauth_hybrid/1.0/trunk/openid_oauth_extension.html
[6] OpenID Wiki / Contract Exchange
http://wiki.openid.net/w/page/12995142/Contract%20Exchange [7] OpenID Wiki / Artifact Binding
29
http://wiki.openid.net/w/page/12995134/Artifact%20Binding
[8] OpenID Connect（2010年 5月 19日時点） http://web.archive.org/web/20100519120350/http://openidconnect.com/
[9] JSON
http://www.json.org/ [10] draft-jones-json-web-token-07 - JSON Web Token (JWT)
https://tools.ietf.org/html/draft-jones-json-web-token [11] Draft: OpenID Connect Messages 1.0 - draft 07
https://openid.net/specs/openid-connect-messages-1_0.html
[12] Draft: OpenID Connect Standard 1.0 - draft 07 https://openid.net/specs/openid-connect-standard-1_0.html
[13] Draft: OpenID Connect Basic Client 1.0 - draft 15
https://openid.net/specs/openid-connect-basic-1_0.html
[14] Draft: OpenID Connect Dynamic Client Registration 1.0 - draft 09 https://openid.net/specs/openid-connect-registration-1_0.html
[15] Draft: OpenID Connect Discovery 1.0 - draft 07
https://openid.net/specs/openid-connect-discovery-1_0.html
[16] Draft: OpenID Connect Session Management 1.0 - draft 05 https://openid.net/specs/openid-connect-session-1_0.html
[17] Draft: OAuth 2.0 Multiple Response Type Encoding Practices - draft 03
http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html
[18] Work item: X.1254 (ex X.eaa) - ITU-T Work Programme http://www.itu.int/itu-t/workprog/wp_item.aspx?isn=6842
30
[19] draft-johansson-loa-registry-04 - An IANA registry for Level of Assurance (LoA)
Profiles https://tools.ietf.org/html/draft-johansson-loa-registry
[20] OpenID Connect Implementer’s Drafts Approved | OpenID
https://openid.net/2012/02/16/openid-connect-implementers-drafts-approved/ [21] Using OAuth 2.0 for Login - Authentication and Authorization for Google APIs -
Google Code https://code.google.com/intl/ja/apis/accounts/docs/OAuth2Login.html
[22] Digging Deeper into OAuth 2.0 on Force.com - developer.force.com http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com
[23] OpenID Connect - VZ Developer Wiki
http://developer.studivz.net/wiki/index.php?title=OpenID_Connect&redirect=no
[24] 2011年 12月 1日開催 OpenID Summit Tokyo講演資料 - OpenIDファウンデーション・ジャパン
http://www.openid.or.jp/modules/docs/contents/contents.html
[25] OASIS Security Services (SAML) TC | OASIS http://www.oasis-open.org/committees/security/
[26] OASIS Web Services Federation (WSFED) TC | OASIS
http://www.oasis-open.org/committees/wsfed/
31
4. JOSE - Webオブジェクトツリーへのディジタル署名と暗号化
宮川 寧夫 4.1. 概要
2011年 9月、IETFの Security Areaに新しいワーキンググループ（以下WG）が設置された。JOSE（Javascript Object Signing and Encryption）というWGであり、JSON（Javascriptオブジェクト記法）[1]で運ばれる構造化データ（例：JWT（JSON Webトークン））にディジタル署名を添えたり、その構造化データを暗号化したりする規格を策定す
る。この JOSEについて報告する前にWebオブジェクトツリーへのディジタル署名と暗号化に関するもうひとつの代表的な仕様である XML 署名と暗号化の仕様についてもふり返る。 4.2. インターネット上で交換されるデータオブジェクトツリー
今日、インターネット上でツリー構造を備えるデータを交換する仕様には、下図のよう
に複数のものがある。
図 1：各種データ構造表記仕様の成立
最初に定められた ASN.1（Abstract Syntax Notation One）[2]の用例として、PKI（Public
Key Infrastructure）の分野で用いられる X.509ディジタル証明書が挙げられる。X.509ディジタル証明書はツリー構造をもつデータであり、ASN.1 によって表記されたデータに対してディジタル署名が付される。 今日、ASN.1 [2]によって表記される他の代表的なディジタル署名に関する規格として
CMS（Cryptographic Message Syntax）[3]が挙げられる。これは IETFの S/MIME WG
32
において策定され、S/MIMEメールの仕様等に使われている。S/MIME WGは 2010年 10月に解散したが、CMSに関する RFCは、その成果物として今年まで発行され続けた。
XML（eXensible Markup Language）は、周知のように汎用的なマークアップ言語であり、関連規格はW3C（World Wide Web Consortium）1において策定されている。
JSON（Javascriptオブジェクト記法）は、IETFにおいて RFC 4627 [1]として規定されている。IETF において策定されるプロトコルで JSON を利用するものが台頭してきており、前期（2011年上期）にはWebsec WGについて報告した[4]。 これらの規格はすべて現在も利用されているものであり、時代の変遷によって置き換え
られてきたというわけではない。それぞれが適する用途に使われている。 4.3. XMLデータオブジェクトへの署名と暗号化
(1) ASN.1との違い
ASN.1 [2]による表記を扱うことは、今日の読者にとって、敷居が高いように思われるかもしれない。各種の記法（例：選択型（CHOICE）、順序列型（SEQUENCE）等）を駆使することによって柔軟なデータ構造を表現することができる一方、実際には ASN.1コンパイラが許容してくれる記法は限られる。また、外部データを参照する際には、あらかじめ
登録しておく OID（オブジェクト ID）を通じて参照する。たとえ、その外部データがURLによって参照可能な場合においても、OID経由で参照される。ASN.1によって表記されるデータについてディジタル署名や暗号化が行われる前には、DAR（Distinguished Encoding Rules）[2]エンコードによって正規化（Canonicalization）される。データの冗長性をなくしたり、混在している等価な表現をある統一形式に整形したりすることによって、データ
について下ごしらえを施しておくのである。 一方、XMLによる表記を扱うことについては、読者の抵抗感は少ないかもしれない。タグは「読み物」となるように柔軟に定義される。また、外部データを参照する際には、直
接、URL を記入することができる。XML データについてディジタル署名や暗号化が行われる前にも、正規化（Canonicalization）するための規格が発行されている。 (2) 2000年以降の標準化
2000 年以降に行われてきた XMLデータへのディジタル署名と暗号化に関する規格についてふり返る。 まず、ディジタル署名を付す規格についてはW3Cと IETFの共同文書として策定された。 RFC 3075，「XML 署名文法と処理（XML-Signature Syntax and Processing）」（初版：2001，2nd Edition：2008）
RFC 2807，「XML 署名要件（XML Signature Requirements）」（2000） 1 www.w3.org/
33
一方、一連の処理の中で暗号化する手続きに関する規格はW3C単独による文書として策定された。この 5章の中で暗号アルゴリズムも指定されている。
「XML暗号化の文法と処理（XML Encryption Syntax and Processing」）（2002）2 さらに公開鍵の有効性検証用の規格もW3Cの文書として策定された。 「XML鍵管理仕様（XKMS：XML Key Management Specification）2.0」（2005）
3 (3) 今期報告された XML関連の攻撃可能性
XML署名と暗号化に関する攻撃法を分類した資料があるので、その一覧を示す。[5]
1. C14N Denial of Service 2. Transform Injection 3. Hash Collision attack against SignedInfo with comments 4. External Reference Attacks 5. Reference Complexity 6. Element Wrapping Attacks 7. Untrusted Keys
今期、注目された脆弱性は「6. Element Wrapping Attacks」に関するものであった。
Shibboleth Security Advisory:“OpenSAML software is vulnerable to XML Signature wrapping attacks”（2011-07-25）
W3C,“Some notes on the recent XML Encryption attack”（2011-10-24）[6] 後者は、2011年 10月に開催された「CCS'11 conference」4において発表された研究論文
[7]に対応してW3Cが表明したものである。 XML暗号化の規格は、単に XMLデータ構造体を暗号化するものではなく、一連の手続きの中で条件を指定して指定する暗号アルゴリズムに処理を行わせるフレームワークを提
供している。広く使われているアルゴリズムは、AES-CBC（AESアルゴリズムの CBCモード）である。この攻撃法は特定のアルゴリズムを選ばず、CBCモード全般についての「選択暗号文攻撃」であり、典型的なWebサービスサーバの実装が攻撃可能な対象となってしまう。 この攻撃が XML暗号化の規格と実装に与える影響として、いくつかの対策の可能性が掲げられている。 2 http://www.w3.org/TR/xmlenc-core/ 3 http://www.w3.org/TR/xkms2/
34
まず、規格に関しては、必須実装アルゴリズムを変更し、AES-GCM（AES アルゴリズムの Galois/Counter モード）を含むようにすることを検討している。XML暗号化の規格は、任意の暗号アルゴリズムで動作するように設計されているので、仕様に関する変更は
少数に留まる見通しであるという。暗号アルゴリズムの交換可能性（algorithm agility）の確保は重要である。 次に、実装については、下記の対策を施す可能性があるという。
暗号化のみならずインテグリティをも保証するアルゴリズム（例：AES-GCM）を使えるようにすること
暗号化されたメッセージのインテグリティを確保する他の手法を組み合わせて使
う執筆時点ではまだ動作する AES-GCM は見あたらない。実装ライブラリが整備
されることが期待される。 4.4. JOSE（JSONへのディジタル署名と暗号化）
(1) XMLとの違い 前期（2011 年上期）の報告[3]においても述べたように、JSON を書くためには、XMLを書く際のようにタグを覚えることが不要なので簡単に書ける。 (2) 2011年の JOSE
2011 年 9 月、IETF の Security Area に JOSE（Javascript Object Signing and Encryption）WGが設置された。当初、このWGの名称はWOES（Web Object Encryption and Signing）とすることが構想されていた5。 また、このWGの作業は、当初、「JSONを使用するプロトコル間のセキュリティ機能の相互運用性を増加させるためにふたつのセキュリティーサービス、インテグリティ保護（デ
ィジタル署名とMAC）および暗号化を標準化することである」とされていた。 ディジタル署名に関する規格：
JSON データ構造を含むデータについて、インテグリティ保護を適用する方法を指定するスタンダードトラックの文書。このインテグリティ保護には、共通鍵MACと共に公開鍵ディジタル署名も含まれる。
暗号化に関する規格：. JSON データ構造を含む)データについて、暗号化を適用する方法を指定するスタンダードトラックの文書。
4 http://www.sigsac.org/ccs/CCS2011/cfp.shtml 5 http://www.ietf.org/mail-archive/web/woes/current/msg00077.html
35
その後、WGは JOSEに改名され、ふたつの案件が追加されて、標準化が行われている。 公開鍵のエンコードに関する規格：
JSON を構造化したオブジェクトとして公開鍵をエンコードする方法を指定するスタンダードトラックの文書。
必須暗号アルゴリズムに関する規格： 上記の 3 つの規格において実装することが必須のアルゴリズムを指定するスタンダードトラックの文書。
(3) JOSEの注目点
XML暗号化の規格と見比べると、JSONには正規化（Canonicalization）に関する規格が見受けられない。筆者は、JSON においてもデータの冗長性をなくしたり、混在している等価な表現をある統一形式に整形したりする必要性がある（例： ハッシュテーブルの表現等）と考えるので、今後の標準化における議論に注目していきたい。
以上
36
参考資料
[1] RFC 4627, "The application/json Media Type for JavaScript Object Notation
(JSON)" (July 2006) http://tools.ietf.org/html/rfc4627
[2] ITU-T, X690, "OSI networking and system aspects – Abstract Syntax Notation One (ASN.1)" (July 2002) http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
[3] RFC 5652, "Cryptographic Message Syntax (CMS)" (September 2009) http://tools.ietf.org/html/rfc5652
[4] 前回報告 「IETFにおけるWeb 2.0 セキュリティ（Websec WG，JWT等）」 http://www.ipa.go.jp/security/fy23/reports/tech1-tg/a_06.html
[5] "A Taxonomy of Attacks against XML Digital Signatures & Encryption", https://www.isecpartners.com/files/iSEC_HILL_AttackingXMLSecurity_Handout.pdf
[6] W3C, "Some notes on the recent XML Encryption attack" (2011-10-24) http://www.w3.org/QA/2011/10/some_notes_on_the_recent_xml_e.html
[7] Tibor Jager, Somorovsky Juraj, `How to Break XML Encryption' In Proceedings of the 18th ACM Conference on Computer and Communications Security (CCS), 2011.
37
5. 非同期の他源泉リクエストと新たな脅威
長谷川 武 5.1. 新しい侵害パターン
リクエスト強要（CSRF）攻撃[1]はこれまで、更新系トランザクションについて警戒を要するものであると、慎重なWebアプリケーション開発者の間で認識されてきた。しかし、Ajax [2] 技術および他源泉へのリクエスト（Cross-origin Request）[3]を用いたWebアプリケーションでは、参照系トランザクションに関しても攻撃を警戒する必要が生じている。
図 1：リクエスト強要──従来の侵害のかたち
図 2：リクエスト強要──新しい侵害パターン
5.2. リクエスト強要攻撃（Cross-site Request Forgery Attack）
(1) 攻撃には Cookieが関係 リクエスト強要攻撃が成立する要因には、主に Cookie [4]の仕組みが関係している。Cookieは、一度ブラウザによって保持されると、特定のサーバへ向けたHTTPリクエストには毎回それが添付されるという性質をもつ。 リクエスト強要攻撃は、Cookie によるセッション維持が成立している状況に悪意の第三者が便乗して、ユーザ本人の意思に反したトランザクションを投入するよう、ブラウザを
誘導する攻撃である。
38
図 3：リクエスト強要攻撃は、セッション維持の Cookieに便乗する
(2) 攻撃成立の詳細 リクエスト強要攻撃は次の図のように進行する。
図 4：リクエスト強要攻撃成立の詳細 5.3. 非同期の他源泉リクエスト（Asynchronous Cross-origin Request）
昨今はいわゆる Ajax [2]と呼ばれる、ひと組の JavaScriptが長時間ブラウザ上に常駐してその中でサーバアクセスを行うタイプのWebアプリケーションが増えてきた。この Ajaxの中でも、自分の出身サーバとは異なるサーバへのリクエスト、すなわち他源泉リクエス
39
ト（Cross-origin Request）[3] を発行するものも出てきた。 (1) 非同期の他源泉リクエスト 「非同期の他源泉リクエスト」を、ここでは次のように定義する。 ブラウザ上の JavaScriptコード内から、 その JavaScriptコードの出身サーバ（「源泉」）とは異なるWebサーバ（別の「源泉」）へ HTTPリクエストを送ってレスポンスを受け取り、
その後も JavaScriptコードが動作を継続すること (2) 「非同期の他源泉リクエスト」複数の方法 非同期の他源泉リクエストを実現する方法には次のような複数のものが知られている。
図 5：非同期の他源泉リクエストの 5種類の方法
5.4. 他源泉におけるリクエスト強要攻撃
上記の「非同期の他源泉リクエスト」のどの方法についても、リクエスト強要攻撃が成
立する状況がありうる。 (1) 攻撃が成立するシナリオ 非同期の他源泉リクエストの上記 5 種類の方法のそれぞれについてリクエスト許容攻撃が成立するシナリオを想定すると、次のようになる。 JSONP [5] に対して攻撃が成立するシナリオ
40
図 6：JSONPへの攻撃 ここでは次を仮定している。
• ブラウザがサーバ Bの有効なセッション IDの Cookieをもっている iframeコール[6] に対して攻撃が成立するシナリオ
図 7：iframeコールへの攻撃 ここでは次を仮定している。
• ブラウザが、サーバ Bの有効なセッション ID の Cookieをもっている（XHR 1でもCookieが飛ぶ）
• サーバ B の iframe コンテンツに対して孫 iframe にロードさせるコンテンツの URIをパラメタで指定できるがその検査が甘い
iframe+postMessage [7]に対して攻撃が成立するシナリオ
41
図 8：iframe+postMessageへの攻撃 ここでは次を仮定している。
• ブラウザが、サーバ B の有効なセッション IDの Cookieをもっている（XHR 1でもCookieが飛ぶ）
Webワーカ+importScripts [8]に対して攻撃が成立するシナリオ
図 9：Webワーカ+importScriptsへの攻撃 ここでは次を仮定している。
• ブラウザが、サーバ Bの有効なセッション IDの Cookieをもっている（なお、ここでは XHR 1は使えない）
XMLHttpRequest level 2（XHR 2）[9]に対して攻撃が成立するシナリオ
42
図 10：XHR 2への攻撃 ここでは次を仮定している。
• ブラウザが、サーバ Bの有効なセッション IDの Cookieをもっている • サーバ Bにおける Origin:リクエストヘッダの検査が甘い • 悪意のサーバに対しても、「Access-Control- Allow-Origin: リクエストしてきたサーバ」および「Access-Control- Allow-Credentials: true」のレスポンスヘッダが発行される
(2) リクエスト強要攻撃への耐性 これらを要約すると、攻撃が成立するための条件が他よりも厳しいことから、XHR 2は比較的攻撃に耐性があるということがいえる。
図 11：5種類の方法の、リクエスト強要攻撃への耐性
43
5.5. XMLHttpRequest level 2（XHR 2）
ここでは、XHR 2の動作をもう少し掘り下げて議論する。 (1) XMLHttpRequest level 2（XHR 2）の通信 XHR 2は次のような HTTP通信上の特徴をもつ。[10] Origin: リクエストヘッダを送信する Access-Control-Allow-Origin: レスポンスヘッダをサーバから受信することを期待している（これ以外にも複数種類の Access-Control-* ヘッダがある）
XHR 2 は、サーバが所定の Acess-Control-Allow-Origin: ヘッダを返さなければ、レスポンスデータを JavaScriptコードへ引き渡さない等の制約を課すことで、セキュリティの確保に配慮している。 (2) XHR 2 を用いた他源泉リクエスト XHR 2を用いた他源泉リクエストは次のように進行する。
図 12：XHR 2を用いた他源泉リクエスト (3) リクエスト強要──XHR 2を突破できるケース リクエスト強要攻撃がXHR 2を突破するためには次のふたつの条件が成立している必要がある。
44
・条件 1： データ供給サイトは、他源泉リクエストを受け付ける際の Origin: リクエストヘッダの検査が厳しくない。送ったオリジンが含まれる Access-Control-Allow-Origin: レスポンスヘッダもが返される。
・条件 2： データ供給サイトでは、Cookieを用いたセッション維持が行われている。そのため、サイトからは、Access-Control-Allow-Credentials: trueレスポンスヘッダが返される。
図 13：XHR 2の他源泉リクエストにおけるリクエスト強要攻撃
5.6. 他源泉リクエスト状況におけるリクエスト強要対策
他源泉リクエストにおけるリクエスト強要対策にあたっては、次の点を考慮する。 (1) セッション対策／トークン対策 • セッションを用いない（できるだけ） • セッション維持に Cookieを用いない（Basic認証、Digest認証も[11]） → 対策例 1 • 他者が推測困難なトークンの発行・照合 → 対策例 2 • OAuth [12] のアクセストークンの利用 (2) XHR 2 • 他源泉リクエスト発行手段には XHR 2 を選ぶ（IE 8 では XDR） • サーバでは Origin: を厳密に検査 • Access-Control-Allow-Origin: の発行を必要最小限に (3) そもそも、他源泉リクエストの使用を必要最小限に
45
図 14：対策例 1 セッション IDを POSTデータで搬送
図 15：対策例 2 Cookieによるセッション IDのほかにトークンを照合
46
5.7. まとめ
リクエスト強要攻撃は、「更新系」処理のみならず、「参照系」処理でも警戒する 非同期の他源泉リクエストには、複数の実装方法がある どの実装方法も、リクエスト強要攻撃の餌食にできる XHR 2は、他の実装方法よりも比較的強固である 他源泉リクエスト状況におけるリクエスト強要対策は、セッション対策 + XHR 2の慎重な利用である
以上 参考文献
[1] 「リクエスト強要（CSRF）対策」 http://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/301.html [2] "Ajax: A New Approach to Web Applications" http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications [3] "Cross-Origin Resource Sharing (Cross-Origin Request）" http://www.w3.org/TR/cors/#cross-origin-request0 [4] "HTTP State Management Mechanism" (HTTP Cookie） http://tools.ietf.org/html/rfc6265 [5] "Defining Safer JSON-P" http://www.json-p.org/ [6] 井上誠一郎ほか共著，『パーフェクト JavaScript』p.298「11-2-10 iframeハック」 ISBN 978-4-7741-4813-7 [7] "window.postMessage" https://developer.mozilla.org/en/DOM/window.postMessage [8] "Web workers" http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html [9] "XMLHttpRequest Level 2" http://www.w3.org/TR/XMLHttpRequest/ [10] "HTTP access control" https://developer.mozilla.org/En/HTTP_access_control [11] RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication" http://tools.ietf.org/html/rfc2617 [12] "OAuth 2.0" http://oauth.net/2/
47
6. クラウドコンピューティングセキュリティ
- VXLAN／NVGREによるネットワーク分離
馬場 達也
6.1. はじめに
近年、ソフトウェアやハードウェアなどのリソースをネットワーク経由で利用する形態
である「クラウドコンピューティング」が流行っている。クラウドコンピューティングに
は、SaaS（Software as a Service）や PaaS（Platform as a Service）、IaaS（Infrastructure as a Service）などの「パブリッククラウド」や、企業毎に自社のデータセンタ上でサーバ仮想化技術を使用して、社内の部門に対して仮想サーバの貸し出しサービスを行う「プラ
イベートクラウド」などが存在するが、複数の企業のプライベートクラウドを物理的に同
じインフラ上で実現することでコスト削減を実現する「仮想プライベートクラウド」が注
目されてきている。仮想プライベートクライドでは、サーバの論理分割だけでなく、ネッ
トワークの論理分割を行い、各社のプライベートクラウド間のセキュリティを確保する必
要がある。本稿では、この論理分割を実現するための新しいネットワーク技術である
VXLANおよび NVGREについて説明する。 6.2. 「仮想プライベートクラウド」実現の課題
現在は、各社が自社のデータセンタに独自にプライベートクラウドを構築している。こ
の状態では、サーバの集約効果はあるものの、コスト削減効果は限定的であった。このた
め、サーバだけでなく、データセンタやネットワークも他社と共有することでコストを削
減する「仮想プライベートクラウド」が注目されている（図 1）。 1台の物理サーバを複数の企業が共同利用するためには、サーバ仮想化技術を利用するが、ネットワークを複数の企業が共同利用するためには、VLAN（Virtual Local Area Network）などのネットワーク仮想化技術が必要となる。ネットワークの論理分割の方法として
VLANをはじめとする従来技術を使用する場合は、パケットに VID（VLAN ID）を付与し、図 2のように、レイヤ 3スイッチ、ファイアウォール、ロードバランサ、レイヤ 2スイッチ、サーバなどを垂直に並べる方法が取られる。
48
図 1： 仮想プライベートクラウドの仕組みとメリット
図 2： ネットワークの論理分割のイメージ
6.3. VLANの課題と解決の方向性
この仮想プライベートクラウド環境においては、いくつかの問題が指摘されている。ひ
とつは、VIDが不足するという問題である。VLANでは、図 3のように、イーサヘッダに12ビットの長さの VID（VLAN Identifier）を含む VLANタグを埋め込むことで、レイヤ2レベルでテナントを識別する。この VIDは 0と 4095を除いて、最大 4,094個割り当て
49
が可能である。しかし、仮想プライベートクラウドを利用する企業が増えると、4,094では足りないという問題がある。
図 3： タグ VLANのプロトコルフォーマット
ふたつめは、ライブマイグレーションへの対応である。ライブマイグレーションに対応
するためには、仮想マシンが移動した後でも、同じネットワーク設定（IPアドレスおよびデフォルトゲートウェイ）で利用できるように、フラットなレイヤ 2ネットワークで構成する必要がある（図 4）。しかし、既存の環境では、レイヤ 3スイッチやルータなどのレイヤ 3機器が存在することが多く、このような機器を越えてライブマイグレーションを行うことができない。
図 4： ライブマイグレーション時の VLANの問題
このため、テナントを識別するための識別子の上限を増やし、さらに、トンネル技術に
50
よって、レイヤ 3ネットワーク上にレイヤ 2ネットワークをオーバーレイで実現する仕組みを備えた VXLAN（Virtual Extensible Local Area Network）および NVGRE（Network Virtualization using Generic Routing Encapsulation）というプロトコルの提案がされている。
6.4. VXLANの概要
VXLANは、VMwareと Ciscoが中心となって提案している、現在の VLANを拡張する技術である。2011年 8月に、VMware、Cisco、Arista、Broadcom、Citrix、Red Hatの共著で、“VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks”（draft-mahalingam-dutt-dcops-vxlan-00.txt）[1]というインターネットドラフトが提出された。 図 5のように、VXLANでは、12ビットの VIDの上限（4,094）を拡張するために、24ビット（1,677万）の「VNI（VXLAN Network Identifier）」を含む VXLANヘッダを使用する。また、ライブマイグレーションに対応するため、イーサフレーム全体をUDPおよびVXLANヘッダでカプセル化することによって、レイヤ 3ネットワーク上にフラットなレイヤ 2ネットワークを実現することが可能となっている。
図 5： VXLANのフォーマット
図 6に VXLANのアーキテクチャを示す。VXLANに対応した仮想スイッチの間で同じテナントに所属する仮想サーバを結ぶトンネルを構築し、テナントは 24ビットの VNIで識別される。間に存在する物理スイッチや仮想サーバは VXLANに対応する必要はない。
図 6： VXLANのアーキテクチャ
51
6.5. NVGREの概要
NVGREは、Microsoftが中心となって提案している、現在の VLANを拡張する技術である。2011年 9月に、Microsoft、Arista、Intel、Dell、HP、Broadcom、Emulexの共著で、“NVGRE: Network Virtualization using Generic Routing Encapsulation”（draft-sridharan-virtualization-nvgre-00.txt）[2]というインターネットドラフトが提出された。 図 7のように、NVGREでは、12ビットの VIDの上限（4,094）を拡張するために、24ビット（1,677万）の「TNI（Tenant Network Identifier）」を含む GREヘッダを使用する。また、ライブマイグレーションに対応するため、イーサフレーム全体を GREでカプセル化することによって、レイヤ 3 ネットワーク上にフラットなレイヤ 2 ネットワークを実現することが可能となっている。
図 7： NVGREのフォーマット
図 8に NVGREのアーキテクチャを示す。NVGREに対応した仮想スイッチの間で同じテナントに所属する仮想サーバを結ぶトンネルを構築し、テナントは 24ビットの TNIで識別される。間に存在する物理スイッチや仮想サーバは NVGREに対応する必要はない。
図 8： NVGREのアーキテクチャ
52
6.6. VXLANと NVGREの違い
VXLANと NVGREは、同じようなアーキテクチャであるが、以下のふたつの点が異なっている。 (1) 実装の容易さ
NVGREは、トンネリングに汎用の GREを使っているが、多くのネットワークチップはGREをサポートしているため、実装が容易であるという特徴がある。
(2) ECMPへの対応
ECMP（Equal-Cost Multi-Path）は、5つの情報（送信元 IPアドレス、宛先 IPアドレス、プロトコル、送信元ポート、宛先ポート）を使って回線のロードバランシングを行う
技術である。VXLANは UDPでカプセル化するため、UDPのポート番号が使用できるが、NVGREは、カプセル化に GREを使用しており、TCP/UDPのポート番号が存在しない。このため、NVGREでは、ECMPによるロードバランシング機能が十分に機能しないという問題が指摘されている。 6.7. VXLANおよび NVGREのセキュリティ
VXLANおよび NVGREのセキュリティレベルは、VLANとほぼ同じレベルであるが、管理すべき IDの数が多くなるため、設定ミスが増加し、セキュリティレベルが下がる可能性がある。 (1) 論理分割のレベル
VXLANおよび NVGREは、両方ともレイヤ 2レベルでの仮想化を実現しており、論理分割のレベルは VLANと同じである。
(2) 運用面での課題
VLANと同様に VNIや TNIと呼ばれている IDの管理が課題となる。1677万の IDを管理すると、設定ミスが増加し、セキュリティレベルが下がる可能性がある。このため、何
らかの IDの自動割り当てが可能なコントローラ機能が必要となる。 6.8. 実装状況
VMwareの仮想スイッチや、VMware上で動作する仮想スイッチ「Cisco Nexus 1000V」において VXLANのサポートが予定されている。
53
6.9. VXLANおよび NVGREの導入上の課題
VXLANおよび NVGREは、トンネルで構築されたレイヤ 2ネットワーク上で、マルチキャスト通信およびブロードキャスト通信を行うために、物理インフラのマルチキャスト
機能を使用する。つまり、物理インフラ上のルータに、DVMRP（Distance Vector Multicast Routing Protocol）、PIM-DM （Protocol Independent Multicast-Dense Mode）、PIM-SM（Protocol Independent Multicast-Sparse Mode）などのマルチキャストルーティングの設定を行い、テナント毎にマルチキャストグループを対応付けする作業が必要となる。 また、VXLANでは 48バイト、NVGREでは 40バイトのトンネル用のヘッダが付加されるため、MTUが減少し、フラグメントが発生するという問題がある。このため、サーバ側で経路MTU探索を行い、フラグメントが発生しないように注意する必要がある。 6.10. まとめと今後の展開
VXLANおよびNVGREの両仕様ともインターネットドラフトの初版の段階ではあるが、VMware、Citrix、Microsoft、Red Hat、Ciscoといった大手ベンダが強力にサポートしており、標準化に先行して仮想スイッチへの実装が進むと予想される。
VLAN ID の枯渇の問題と、レイヤ 2 フラットなネットワークの実現という意味では、OpenFlowも解決策のひとつであり、今後、VXLAN、NVGRE、OpenFlow [3]の 3方式の動向をチェックしていく必要がある。
以上 参考資料
[1] “VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer
3 Networks”，http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-00 [2] “NVGRE: Network Virtualization using Generic Routing Encapsulation”，
http://tools.ietf.org/html/draft-sridharan-virtualization-nvgre-00 [3] IPA，『情報セキュリティ技術動向調査（2010 年下期）』「8. OpenFlowによるネット
ワーク分離」，http://www.ipa.go.jp/security/fy22/reports/tech1-tg/b_08.html
54
7. インターネット経路制御のセキュリティに関する動向 - BGPSEC
木村 泰司
7.1. BGPSECの動向
現代のインターネットは、BGP（Border Gateway Protocol）[1]と呼ばれるプロトコルを扱うルーター（以下、BGPルーターと呼ぶ）が相互に接続することで、IP（Internet Protocol）のパケットが届く世界規模のネットワークとして形作られている[2]。BGPルーターは ISP（Internet Service Provider）等に設置され、IPアドレスやインターネットの経路に関する情報を BGP ルーター同士で交換しており、隣接していない IP のネットワークに対してIPパケットが転送できるようになっている。
2011 年後半、この BGP に、セキュリティの仕組みを加えるための BGPSEC（BGP Security Extension）に関する議論が IETF（Internet Engineering Task Force）で活発化した。2011年 7月から 12月にかけて、提案文書である Internet-Draftが出揃ってきた。また米国のNIST（National Institute of Standards and Technology）では、BGPSECやリソース PKI [3]に関する試験や評価を行うプロジェクト[4]が立ち上がり、実現性を検証する動きが出てきている。 本稿では、2011 年下半期のインターネット経路制御のセキュリティに関する動向として
BGPSECを解説する。
7.2. BGPSECの背景と現状
BGPSECのような、インターネットの ASパス（経路に関する情報）を確認するための技術は、2009年頃、IETF SIDR WG（Secure Inter-Domain Routing Working Group）で既に標準化に向けた話題として上がっていた。しかし、当時はリソース PKIとこれを使った IPアドレスの正しさを確認する仕組み[5]の標準化に向けた議論の最中であり、BGPSECの議論に入れない状況であった。WGのメンバーの間でも BGPSECの技術標準化の必要性が認められていたものの、まずリソース PKIと Secure BGPを標準化して IPアドレスの正しさを確認できるようにする、というのが WG としての考え方であった。その標準化が一段落した 2011年になって、ようやく BGPSECの標準化が始まったのである。
BGPSECは、まだその名称がひとつに絞られておらず、”BGP Security Extension”または”A security extension to BGP”などと呼ばれている。BGPSECは、BGPで伝えられるメッセージの中の重要な情報である ASパスと呼ばれる情報と IPアドレスが正しいかどうかを BGPルーターにおいて確認するための仕組みである。
55
不正な ASパスの情報を BGPルーターの間にうまく伝えることができると、インターネットからの特定の ISP への到達性を失わせたり、インターネットの経路を操作して特定のWebサービスのすべてのトラフィックを盗聴したり、更にはMan-in-the-Middle攻撃を行ったりすることが可能である[6]。 執筆現在、BGPSECに関してまとまった文献はほとんど無く、詳しい文献には、全体像を述べた「An Overview of BGPSEC」[7]や、IPv4アドレスの枯渇予測で知られる Geoff Huston氏による ISP Columnの記事「Securing BGP with BGPsec」[8]がある。
BGPSECの標準化は始まったばかりであるが、後述する NISTにおけるシミュレーションでは、2016年が普及の始まる目処とされている。リソース PKIの標準化に 5年かかっていることから、今後、2～3年で詳細が決められていくと考えられる。
7.3. BGPSECの仕組み
BGPSECはいくつかの脅威モデルが立てられ、それらに対策するための仕組みとして考案された[9]。例えば、インターネットの経路の途中で AS パスの中に不正な値を追加されたときに、BGP ルーターにおいてそれをどう検知するか、といった考え方である。その仕組みの中で重要な役割を果たすのが、BGPSECパス署名と呼ばれる電子署名である。
BGPでは、AS番号（Autonomous System Number）と呼ばれる数字でネットワークが識別される。AS番号は IPアドレスと同様に、JPNICのような「インターネットレジストリ」から、ISP毎にひとつ、または Googleや Yahoo、YouTubeといったサービスのネットワークにひとつといった形で割り当てられている。AS 同士が BGP を使って経路の情報を交換することで IP を使った広域の通信ができるようになっている。AS 同士は、どの ASを経由するとあて先の IP アドレスに到達できるかを示す、AS パスと呼ばれる AS 番号の並びの情報を交換している。ASパスは、IPアドレスのプレフィックスに続いて送られる。
図 1は BGPルーターAのAS001が含まれる ASパスの情報がBGPルーターCに伝わっ
図 1： BGPと ASパス
BGPルーターA(AS001)
BGPルーターB(AS002)
TCPコネクション
BGPルーターC(AS003)
TCPコネクション
ASパス10.1.0.0/16, AS002, AS00110.2.0.0/16, AS00210.1.0.0/16 10.2.0.0/16
ASパス10.1.0.0/16, AS001
BGPルーターA(AS001)
BGPルーターB(AS002)
TCPコネクション
BGPルーターC(AS003)
TCPコネクション
ASパス10.1.0.0/16, AS002, AS00110.2.0.0/16, AS00210.1.0.0/16 10.2.0.0/16
ASパス10.1.0.0/16, AS001
56
ていく様子を示している6。BGPルーターAは 10.1.0.0/16という IPアドレスのネットワークを収容しており、BGP ルーターB は 10.2.0.0/16 というネットワークを収容している。BGPルーターB から 10.1.0.0/16に IPパケットを到達させるためには、BGPルーターA、すなわち AS001に IPパケットを転送すればよい。これを「10.1.0.0/16, AS001」と示している。
BGP ルーターA と隣接していないネットワークからも到達できるようにするため、AS001 の情報は、BGP ルーターB から BGP ルーターC に伝えられる。そのとき先頭にAS002が加えられる。AS003のネットワークからAS001のネットワークに到達するには、まず AS002を通る必要があるという意味である。この情報は「10.1.0.0/16, AS002, AS001」と示される。この AS002 AS001という AS番号の列が ASパスである。 この ASパスの情報に対して電子署名を行ったものが AS パス署名である。ASパス署名は各 ASによって署名が加えられていくため、入れ子構造をしている。
図 2は ASパス署名が加えられたネットワーク層到達性情報を示している。ネットワーク層到達性情報は AS パスを伝えるための BGP のメッセージに入っている。ふき出しの10.1.0.0/16 へのネットワーク層到達性情報の中では、始めに AS パス（AS_Path）が示され、その後に BGPSECパス署名（BGPSEC_Path_Signature）がつけられている7。
AS001は、次の AS が AS002であることを示すため、「10.1.0.0/16, AS001」に AS002を加えた値に電子署名を行っている。これを AS001 sig{10.1.0.0/16, AS001, AS002}と表している。AS002 はこれに次の AS である「AS003」を加えて更に電子署名を行っている。これが AS002 sig{{10.1.0.0/16, AS001, AS002}, AS003}である。これを受け取った AS003は、BGPSEC_Path_Signatureをひとつずつ確認した結果を AS_Pathと比較し、相違がなければ本来の経路であることがわかる。 もし途中の BGPルーターで不正に ASパスが変更されると、その箇所の AS番号の並び
6 実際には、基本的に双方向に伝えられていく。 7 執筆の段階では、ASパス署名の中の AS番号の順列は ASパスとは異なる。
図 2： BGPSECパス署名
NLRI：10.1.0.0/24AS_Path: AS002 AS001BGPSEC_Path_Signatures
AS001 sig ｛10.1.0.0/24, AS001, AS002｝AS002 sig ｛｛10.1.0.0/24, AS001, AS002｝, AS003｝
NLRI: Network Layer Reachability Information（ネットワーク層到達性情報）
AS001 AS002 AS003
NLRI：10.1.0.0/24AS_Path: AS002 AS001BGPSEC_Path_Signatures
AS001 sig ｛10.1.0.0/24, AS001, AS002｝AS002 sig ｛｛10.1.0.0/24, AS001, AS002｝, AS003｝
NLRI: Network Layer Reachability Information（ネットワーク層到達性情報）
AS001 AS002 AS003
57
に対しては有効な電子署名がつかないことになる。また本来と異なる BGPルーターが他のASに成りすまそうとしても、その署名のための秘密鍵を持っていないため、正しい電子署名を加えることができない。更に経路の情報に含まれるあて先 IPアドレスが詐称された場合は、リソース証明書と ROA（Route Origination Authorization）を使って本来の IPアドレスではないことが確認できる。つまり BGPで伝えられる重要な情報を電子署名で確認できるようにしているのである。 運用面のメリットもある。ASのつながりが変わったときに、それが運用者の意図通りである場合には、そのひとつひとつについて各国のネットワーク管理者の間で連絡を取りあ
わなくてもよいことになる。また、例えば、特定の ISP のトラフィックを一旦中継して通信内容を改ざんするようなMan-in-the-Middle攻撃や、過去に起きた YouTubeの事件のように、他の ASによって特定のサービスの到達性が失われるような不正な経路の情報が国際的に伝わってしまう範囲、つまり影響範囲を、各 BGPルーターにおいて小さくできると考えられる。
7.4. 実現に向けた大きな課題
BGPSECは、電子署名の技術を使って不正なASパスの操作から経路を守る技術である。従って、各 ASの BGPルーターにおいて電子署名を施し、また検証できる必要が出てくる。これには大きく分けてふたつの課題がある。 ひとつめは、ルーターの性能である。米国の NISTにおけるシミュレーション[10]によると、ASパスが含まれる BGPの Updateと呼ばれるメッセージの平均のサイズは平均 78バイトであるが、BGPSECパス署名が含まれると平均 1,188バイトになる（鍵長 2,048ビットの RSAを使った場合）。BGPルーターに BGPSECが導入され、仮に 2016年から普及し始めた場合、2020年頃には IPv4だけで 7.9Gバイトものメモリ量8が必要になる。IPv6も加えると更に増える[11]。現代の BGPルーターは数百Mバイトのメモリ量で経路の情報が溢れる恐れが指摘されており、このサイズは現代の BGPルーターでは考えられないほど大きい。 もうひとつは、ASにおける電子証明書の普及9、そしてその運用である。インターネット
の接続性を維持するために、BGP ルーターのオペレーターは、秘密鍵を管理したり証明書の有効期限に気をつけたりする必要がある。TLS（Transport Layer Security）のサーバ証明書を扱うよりも更に慎重な運用が求められる可能性が高い。
BGPSECは IETFにおける標準化が始まったばかりである。その実現には大きな課題があるが、BGPにおける IPアドレスの不正な利用や、適切かどうかわからない ASパスは、 8 ここでは RIB(Routing Information Base)のサイズをメモリ量と呼んでいる。 9 IPアドレスや AS番号が入った電子証明書であるリソース証明書の方は、世界の 5つの地域インターネットレジストリから提供が始まっている。しかし、これを使う実装がほとんどなく、普及には至っていな
い。
58
米国や欧州、そして日本でも観測されている。BGP のネットワークは国際的なものであるため、各国の社会情勢や外交上の問題がインターネットという共通基盤に対する脅威につ
ながりなりかねない。また、インターネットにおける到達性が、一部の人によって操作で
きるものになってしまうと、テロ行為のために使われてしまう恐れもある10。 BGPSECが、グローバルなインターネットにみられる不正な経路制御に対して、どれほど有効に機能し、また日常的な運用のできる技術になっていくのか、今後も動向をみてい
く必要がある。 以上
10 本文で紹介したNISTの BRITEは、米国国土安全保障省の活動の一環でもある。
59
参照文献
[1] Y. Rekhter, T. Li, “A Border Gateway Protocol 4 (BGP-4)”, March 1995, RFC1771, http:/www.ietf.org/rfc/rfc1771.txt
[2] あきみち，空閑 洋平，「インターネットのカタチ―もろさが織り成す粘り強い世界―」（2011年 6月）ISBN-10:4274068/162, ISBN-13:978-4274068/169
[3] 木村泰司，「Resource PKIの動向」，情報セキュリティ技術動向調査（2008年下期),
2009年 3月, http:/www.ipa.go.jp/security/fy20/reports/tech1-tg/2_09.html
[4] “BRITE - BGPSEC / RPKI Interoperability Test & Evaluation”, National Institute of Standards and Technology (NIST), http:/brite.antd.nist.gov/
[5] “An Infrastructure to Support Secure Internet Routing”, M. Lepinski, S. Kent, (May 2011), http:/tools.ietf.org/html/draft-ietf-sidr-arch-13
[6] Alex Pilosov, Tony Kapela, “Stealing The Internet - An Internet-Scale Man In The Middle Attack”, Defcon 16, Las Vegas (Aug, 2008), http:/www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf
[7] M. Lepinski, S. Turner, “An Overview of BGPSEC” (October 2011), http:/tools.ietf.org/html/draft-ietf-sidr-bgpsec-overview-01
[8] Geoff Huston, Randy Bush, “Securing BGP with BGPsec” (July 2011), http:/www.potaroo.net/ispcol/2011-07/bgpsec.html
[9] “S. Kent, Threat Model for BGP Path Security” (February 2011), http:/tools.ietf.org/html/draft-kent-bgpsec-threats-01
[10] K. Sriram, O. Borchert, O. Kim, D. Cooper, and D. Montgomery, “RIB Size Estimation for BGPSEC”, (May 2011), http:/www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation.pdf
[11] K. Sriram, O. Borchert, O. Kim, D. Cooper, and D. Montgomery, “RIB Size Estimation for BGPSEC Including IPv4 and IPv6”, (June 2011), http:/www.antd.nist.gov/~ksriram/BGPSEC_RIB_Estimation_v4_v6.pdf
