Adi Shamir 先生来訪
本日、イスラエルのAdi Shamir先生が研究所に来訪しました。言うまでもなく RSA を発明した3人のうちの "S" の人。RSA暗号の過去（完成したいきさつ）と現在、未来というテーマでお話を伺いました。
特に、過去の話は面白かったです。
- 図書館に行ったときにテーブルの一番上におかれていたIEEE Trans. on Information Theory に、Diffie Hellman が
後悔公開鍵方式の可能性について書いた記事が載っていて、それを見て興味を持った - が、もともとまったく暗号の知識がなかった。でもそれが逆に新しい視点で考えるのに役立った
- なかなかうまくいかなかったが、1977年の4月のPassover（ユダヤの過ぎ越しの祭り）の時に、ワインを飲みすぎて眠れず、眠れないのでウンウン考えていたら良いアイディアが出て、それが breakthrough だった
- 発表後、夏休み旅行に出ている間に論文希望の封筒が7000通も届いていて、オフィスのドアを開けたとたんに崩れてきて危うく死ぬところだった
- 3人を紹介する写真を撮るときに、後ろの黒板に上段でP=NPと書いておいて、知らない人が見たらこの3人がP=NP予想を証明したとびっくりするようなジョークを仕込んだ
- 初期のPCは遅くて512ビットRSAの復号に2分もかかった。それで、高速処理のために専用のハードウェアを作ろうとしたけど、もともと何の知識もなかったので失敗した
などなど．．．
このテーマで何回も話をされているらしく、まるで落語のように練れた、ユーモラスな語り口でした。
最近は、ハードウェアの電力差分解析攻撃などをやっているようです。専用ハードウェアを作ろうとした経験が役に立ったのかも。
有名な方なので既に名誉職のような感じなのかと思っていたのですが、まだまだ現役バリバリのようで、すごくパワフルでした。
The Multi-Principal OS Construction of the Gazelle Web Browser, Usenix Security 2009
Wang, H. J.; Grier, C.; Moshchuk, A.; King, S. T.; Choudhury, P. & Venter, H, The Multi-Principal OS Construction of the Gazelle Web Browser, pp.417-432, Usenix Security Symposium 2009.
Microsoftの Helen Wang らによって最近発表された、新しい、安全なブラウザのアーキテクチャの提案。
Webブラウザにロードされるコンテンツの主体 (principle) ごとに細かい単位でOSのプロセスに分離して実行される。また、既存のコンテンツとの互換性を大事にしていて、テストした20のWeb appのうち、19は動いた。
セキュリティモデル
- Same Origin Policy (SOP)がベース。
- ただし、<iframe>だけでなく、<object>, <embed>, <img>, ある種の <input> は、それぞれにロードされたコンテンツのオリジン単位の主体となる。つまり、SOPが plug-inのコンテンツにまで適用される。
- 主体 (principle) の単位で、別のOSプロセスに分離される (principle instance)。プロセスとOSの間にBrowser Kernelがいて、全体をマネージする。
- principleの判別方法は、基本的に same-origin policyと同じで、{プロトコル、サーバ、ポート} の組で判定される。
- 別のTabで同じURLにアクセスしても、別の principleになる
- ただし、あるページの中のIFRAMEが親ページと同じドメインなら、デフォルトで同じ principleになる。ただし、親ページ側で制限をかけることも可能
- Browser Kenelの仕事は
- 画面描画に関しては、
- principle instanceがコンテンツをレンダリングして bitmap にするところまで責任がある。ブラウザカーネルがbitmapをうけとって、画面のどの部分にどう描画するかを決める。
- ページ内にフレームなどが含まれる場合、ページの principle instanceが 大家（地主）、フレームの principleが店子、になる。大家と店子の間で互いのコンテンツを干渉しないように、細かいアクセス制御が行われる。たとえば
- 店子フレームの場所は大家しかRWできない
- 店子フレームのサイズは大家がRW、店子は自分のサイズをRできる
- 店子フレーム内に表示している情報は店子しか見られない
- 店子フレームのURLは、大家はWのみ、店子はR/W可能
既存のブラウザとの違い
- Chromeとの違い
- IE8との違い
- IE8ではブラウザのタブごとに別のプロセスとして動作するが、タブの中にIFRAMEがある場合などには同じプロセス内で表示されることになる
- OP Browser[2] との違い
- OP BrowserではHTML engine, javascript などが別のプロセスとして分離される
- そのため、コンポーネント間のIPCのコストが高い
- 各コンポーネントはWebページをレンダリングする際に運命を共にするようになってるので、ひとつがコケると殆どのページが表示されない
- OSレベルの cross-principleな保護はできない
- Tahoma[11]との違いは、TahomaではWeb applicationごとにVMで分離するが、Web applicationの区切りはmanifestファイルで決めるので、既存のブラウザの principleごと（SOPということ？）の保護はできない
医療の個人情報保護とセキュリティ その１
最近、医療情報の電子化とかそれに伴うプライバシー保護問題とかHIPAAとかいう話をよく聞くのだけれど、具体的にどういう問題があるのかいまひとつピンと来ない、ということが多いです。
ちょっと勉強しようと思って本を買ったので、読んでまとめてみます。
第1章
欧米の医療における個人情報保護の歴史
医療というのは患者のプライバシーに深く関係する一方で、感染性の疾患の流行を防ぐとか、様々な患者のデータを集積して新しい解決策を見出すなど、経験や情報の適切な共有も重要。この相反する要求をバランスよく解決することが、医療における個人情報保護の中心命題。
医療における医者の守秘義務は、紀元前300年ごろにギリシャの医療従事者ギルドで作られた「ヒポクラテスの誓い」にまでさかのぼり、これは近年まで殆ど変わっていない。
近年になって、1974年に制定された米国のプライバシー法 (Privacy Act.) で、「自己に関する情報に対するコントロール権」に主眼が置かれるようになって、これが大きな変革。その後、
と続く。
日本の現状
日本では憲法には直接これらの言葉は定義されていないが、現在の憲法学では憲法13条がプライバシーや個人情報を保障した権利だと解釈されている。
「すべて国民は、個人として尊重される。生命、自由および幸福追求に対する国民の権利については、公共の福祉に反しない限り、立法その他の国政の上で、最大の尊重を必要とする」
プライバシー権の内容は、
- 自己決定権
- 自己情報コントロール権
に大きく二分される。
刑法の場合
- 刑法134条の秘密漏示罪が基本条文となる。この条文では意思、薬剤師、医薬品販売業者、助産師が業務上知りえた秘密について守秘義務を負うことが明記されている。
- 看護士等などについては明記されていないため、近年保険師助産師看護師法が改正され、同様の条項が追加された。
民法の場合
新しいプライバシーの概念とOECE8原則
1980年に制定された OECDのプライバシーガイドライン (Guidelines on the Protection of Privacy and Transborder Flows of Personal Data) では次の「個人情報の自己コントロール権」を基本とした、8つの原則がある。OECD参加国に対しては、ガイドラインに基づく法整備を考慮することを求めている。
- 収集制限の原則
- データ完全性の原則
- 目的明確化の原則
- 利用制限の原則
- 安全管理の原則
- 公開の原則 （個人データにかかわる開発・運用・方針を公開すべき）
- 本人参加の原則 （データの存在を知る権利、修正・削除を求める権利）
- 責任の原則
日本におけるカルテ開示の流れ
一般的にはプライバシー情報は本人が一番詳しいが、医療情報の場合には患者本人は内容を理解できないという、情報の不均衡がある。
- 明治〜昭和初期には、患者に容易に読まれないようにカルテをドイツ語で書く習慣があった。
- つまり、診療情報は、患者の精神状態や理解力を見定めた上で、医療従事者が編集した上で知らしめるという慣習があった
しかし近年、わが国でもカルテ開示が進む方向にある。これには二つの方向がある：
ただし、いろいろセンシティブな問題がある
- 開示することが患者の不利益になる場合（例：がん告知で精神的ショック）
- 本人以外のものが開示を求める場合
- 患者が死亡した場合の遺族からの開示要求。死者のプライバシーに関してはプライバシー保護の法律で言及されていない
- 未成年など、判断力が未熟・欠落している場合。児童虐待が疑われる場合など注意が必要。
2002年に日本医師会が「診療情報の提供に関する指針（第2版）」を発表している。
CLAMP: Practical Prevention of Large-Scale Data Leaks
IEEE Symposium on Security and Privacy (Oakland) 2009で発表された論文を読んでみた。
- CLAMP: Practical Prevention of Large-Scale Data Leaks, by Bryan Parno, Jonathan M. McCune, Dan Wendlandt, David G. Andersen, and Adrian Perrig
SQLインジェクションなどにより、Webサーバが攻撃されて、DBに格納されている他のユーザの情報まで盗まれてしまう、というような攻撃への対策となる、Webアプリケーションサーバのアーキテクチャの提案。
手法としては、Webのリクエストが来たら、ユーザ認証を行って、ユーザごとに別の仮想Webサーバ (WebStack) を作る。それぞれの WebStack は XenのVM上で動くので、ユーザごとのサーバ側のアプリケーション・インスタンスが分離されるイメージ。さらに、DBのクエリーを制限するProxy (Query Restrictor) が WebStack からのDBクエリを仲介し、他のユーザに属するデータにアクセスできないような制限をかけることで、Webアプリケーションを信頼することなく、サーバ側のデータを保護できる、というもの。
感想：
今年のOaklandで発表された論文なのだが、正直あまり新しさを感じない。Xenで環境分離することによりユーザやドメインごとのデータを保護するというのは、最近ではすでにおなじみの手法だと思うし、ブラウザ側でやっているものは既にあったと思う （ちょっとどの論文だったか失念）。
Query Restrictorによる制限というのも、 「where UID=今アクセスしているユーザ」的な clause をSQL Query に追加しているだけに見える。
ユーザごとにVMのインスタンスを起動するというのも、リソース使用量やパフォーマンスの面で、あまり現実的ではないのではないだろうか。
Cyber Cold War
備忘録的に。最近アメリカでは、Cyber Crimeを超えるCyber Warというのが流行っているらしい。
- McAfee Virtual Criminology Report 2009
- Report: Countries prepping for cyberwar, CNet News, Nov 16, 2009.
Quantifying Information Leaks in Outbound Web Traffic
Quantifying Information Leaks in Outbound Web Traffic, by Kevin Borders (Web Tap Security, Inc.), Atul Prakash (University of Michigan), IEEE Symposium on Security & Privacy 2009.
タイトルや Introduction から Webトラフィック上でのDLP (Data Leakage Prevention) の話なのかと思ったのだが、どうもそうではないらしい。前提としている脅威シナリオが最初に明確に書いてないのだが、どうやら、「ブラウザやClient上のスパイウェアが、Webトラフィックをチャネルとして利用して、外部に情報を漏洩させる可能性がある」というのが前提らしい。
ネットワークトラフィックの量は膨大なので、Sensitive dataを検出しようという試みはうまくいかない。かわりにこの論文では、実際に漏出している情報の量を定量的に評価し、制御する手法を提案する。
情報量を定量的に評価する手法は、HTTPがHTMLとJavaScriptとインタラクトするプロトコルに着目し、HTTPリクエストの期待されるコンテンツを推測する手法。実際のコンテンツと期待されるコンテンツの edit distanceが、流れている情報の量となる。
- Webページをparseして、含まれているリンクを取り出す。たとえば、ここに含まれているリンクへのアクセスは予想の範囲内、といえる。
- ブラウザ環境をシミュレートしてリンクを抽出する
- HTML内のFormの名前と、HTTP Postのパラメータ名のマッチングを取る
- HTTP headerなどの固定情報は排除する
- また、Request/Responseのタイミングを使った covert channel も推測
メリット：
