Kindel DXのカバー

Kindle DXを使うようになって数週間。いつも出社時はパソコンと一緒にクッションの効いたバッグに入れて持ち歩いているのであまりカバーの必要性は感じないが、単体で持ち歩くときにはカバーがないとちょっと不便なので、なにか欲しくなって来た。

Amazon を眺めてみて気になったのは、Cole Haan の自然な風合いの革製の製品。写真で見る限りとても素敵なのだけれど、値段が高いのが気になる。$139.99 も出すなら、WiFiモデルのKindle 3が買えてしまうではないか。さらに実際に使ってみた方の感想をWebで見ると、装着時に厚みが Kindle DX の３倍、重さも重くなってしまうとのこと。折角軽さと薄さが売りの Kindle なので、重くなるのは避けたい。

世の中には同じような悩みを抱えている方も多いようで、カバーを自作する人も結構いるようだ。
それなら私も作ってみるか、ということで、こちらで紹介されていた無印良品のノートカバーを利用する方法を参考にして、作ってみた。

まずは無印良品で、B5版のノートカバーを購入。ジーンズのラベル部分の素材ということだが、触ってみると手触りがあまり私好みではない。せっかくなので生地屋で気に入った柄の木綿の布を購入。ベルクロテープをKindleに直接貼付けるのは気がひける気がしたので、本体に貼付ける代わりに、Kindleをくるみ込むようなカバーを作ってみた。

それがこちら。

[%]

薄くて軽いのは◎
でも適当に作ったので細かいところの細工が歪んでいるのはご愛嬌。

なんかイマイチだけど、壊れるまで暫く使ってみて、飽きたらちゃんとしたのを買うかなあ。

Kindle DX購入

以前から気になっていたKindleをついに購入しました。電子書籍リーダーを購入する理由は人それぞれだと思いますが、私の場合は以下の２つが主な動機でした。

  • 仕事がら、洋書の技術書を買うことが多い。しかし大抵分厚くてかさばるので持ち歩きに不便であり、電車にのる時間が主要な読書時間となっている身としては、じっくり読むことができない。結果として本棚の肥やしとなるし、場所をとって邪魔になる。
  • やはり仕事がら論文やホワイトペーパーなどのPDF文書を読む機会が多い。１本をじっくり読むなら印刷して赤ペン入れながらというのが好きなのだが、大量のものをざっくり読みたいときには印刷するだけで面倒くさいし紙が邪魔。

Kindleを買う場合には2010年10月現在、３つの選択肢があります。

WiFiオンリー版普通サイズKindleは現在たったの 139USD という低価格のため、円高の現在かなりお買い得で心が揺れたのですが、PDFを読むにはやはり大画面がよさそうということで、Kindle DXに決定しました。送料もろもろ合わせて約３万５千円くらいの出費になりました。

注文して４日くらいでさくっと到着。充電してスイッチを入れると Welcome XXXX と、すでに自分の名前が表示されています。amazon.com の自分のアカウント情報が登録されていて、何もしなくてもそのまま使えるという仕組み。これはITに慣れていないユーザには嬉しいだろうなあ。

画面はe-ink でとても読みやすいです。紙と比べても遜色ない読み心地で、バックライトがないので目が疲れませんし、日光の下でもちゃんと読めます。ただし描画は遅いです。ぺーじをめくるとき、一度画面を黒く塗りつぶしてから再描画するので、iPadなどの美しいディスプレイに慣れていると違和感を感じると思います。コンピュータじゃなくて「本」なのだと割り切るべきでしょうね。

重さは意外と重くて、片手だとちょっと疲れる感じ。両手なら問題ありません。

A4版のPDFを表示してみたところ。問題なく読めますが、若干縮小されるのでもとのフォントが小さい場合はちょっとくるしい。そんなときは画面を横にすることで読みやすくなるので、問題ありません。

ただ横に表示する場合にちょっと残念なのが、A4版の１ページを表示すると３画面に分割されるところ。
最後の１画面はページの下端がちょっと表示されるだけなので、画面サイズか表示サイズを調整してなんとか２画面におさめることはできなかったのか、と思ってしまいます。まあそれほど実害はないのですが。

電子書籍の場合にはより柔軟に、フォントサイズを変更できます。
また、いくつかの便利な機能があります。

1) インラインで辞書表示。わからない単語にカーソルを当てると、英英辞典の説明が表示されます。PDF版ではインライン表示ができないのですが、辞書自体を単独で使うことはできるので、移動中などには便利です。

2) 本文中に線を引いたり、コメントを入れたり、ブックマークをつけたりできます。
つけたコメントを他の人と共有したり、Kindleから直接TwitterやFacebookで呟いたりできます。(Twitterと連携する場合、OAuthを使っているみたいで、後述のWebブラウザでTwitterのOAuth確認画面に飛ばされます）

コメント入力中

脚注のような印がつきます

コメントなどは一覧として見ることもできます。

3) 音声読み上げ機能があります。試験的機能という扱いですが、とても自然な読み上げで、非常に聞きやすいです。私は英文を読むのが遅いので、読まずに聞いていた方が楽なくらいです。（でもそれでは、大画面のDXを買った意味がなくなってしまう。。。）　ただし電子書籍限定で、PDFは読み上げできません。男声と女声から選択できます。

4) やはり試験的機能という扱いで、NetFront というモバイル向けのWebブラウザが入っています。ただし日本語は表示できないのと、描画の遅さや入力デバイスの制限、モバイル向けブラウザという制限のため、通常のWebブラウジング環境とは思わないほうがよいでしょう。他に選択肢がない際にちょっと使える、という程度の期待にしておいた方がよさそうです。
ためしにTwitterモバイル版を表示してみたところ。

わ、わからん。。。

5) PDFやそれ以外のファイルをメールで xxxxx@kindle.com というアドレスに送ることで、Kindle上で表示できます。しかしこれには問題もあるのです。詳しくは後で書きます。PDF以外のファイルを送るとAmazonのサーバで変換してKindleに転送してくれるようです。

6) Kindle storeには電子書籍以外のコンテンツもあります。

毎日新聞英字版を購読してみたところ。

Kindle Storeにはゲームもあります。懐かしのマインスイーパーを入れてみました。


嬉しくないところ

と、嬉しいところだらけのKindle DXなのですが、嬉しくないところもあります。

一番の問題は、ネットワーク接続が3Gのみであること。このWhispernetという3G接続はUS国内では無料らしいのですが、日本で使う場合は海外ローミングしていることになります。日本から使う場合には、

  • Kindle storeからの本の購入やWebブラウジングは、無料です
  • ただし新聞購読などには一週間あたり $4.99 の費用がかかります
  • さらにメールで xxxxx@kindle.com というメアドをつかってKindleにファイルを転送した場合、1MBあたり $0.99 の費用がかかります。切り上げ方式なので 1.1MBのファイルでも2MB扱いで $1.98 かかることになるので、気軽に使うにはちょっとお高いのです。
  • WiFi接続の場合には [email protected] という無償アカウントが使えるらしいのですが、DXはなぜか3GのみでWiFi搭載がないために使えません。こんな大きいのにWiFiはなしだなんて、なぜ。。。

PDFについてはUSB経由で転送もできるので今はこちらを利用しているのですが、仕事用のパソコンはセキュリティ上の理由でUSBに書き込めないようになっているので使えません。

さらにメールを経由してファイルを送る場合、送信者のメールアドレスが amazon.com に登録されているメールでないと、転送されないようです。多分SPAMや悪意ある第三者によるファイル転送を防ぐ目的だと思いますが、その気になればメール送信者のアドレスはいくらでも改ざんできるので、セキュリティ対策としてはあまり強くないですね。（SPAM対策というのが妥当な位置づけかと思います）

今のところ職場からは amazon.com に登録されている私用メールアドレスからメールを送る*手頃な*手段がないため、現在のところ職場からはまったくPDFファイルをKindleに転送できなくて、これが一番の不満です。退社前に読みたいファイルをちょちょっとKindleに転送して帰りの電車で読む、っていうのをやりたかったのですが。。。

最後に、電源を切るとスクリーンセーバー的な絵が表示されます。電気を使わなくても画像を保持できる e-ink ならではですね。白黒ですがグラデーションが奇麗で、毎回色々な絵がランダムに表示されるので、目を楽しませてくれます。

Content Security Policy (CSP)

WebSecurity

最近Mozillaが売り出している Content Security Policy (CSP) について調べてみた。
ここにある概要がわかりやすい。細かい仕様は ここにある。

CSPはXSS攻撃を防ぐためのブラウザ上の仕組み。Webページごとのポリシーを Webサーバが指示し、ブラウザはその指示従って動作することにより、従来の Same-Origin Policy (SOP) より安全になる。

CSPは現在のブラウザの世界と完全に後方互換性がある。ブラウザがCSP非対応だったりサーバ側がCSPポリシーを定義しなかったとしても、SOPと同じセキュリティレベルになるだけなので、害はない。

CSPでは、次のような制限をポリシーに記述できる。

  • どのサイトからJavaScriptをダウンロードできるかというドメイン名のホワイトリストを定義できる。ホワイトリスト以外のサイトを指定した <script src="..."> がHTML中にあっても、無視される。
  • 同様に、イメージ、スタイルシート、オーディオやビデオなどのマルチディアコンテンツ、objectタグやembedタグで指定するオブジェクトのダウンロード元サーバをホワイトリストで制限できる
  • ポリシーはXMLで記述され、そのURIが拡張された policy-uri というHTTPレスポンスヘッダでブラウザに返される
  • また、report-uri というヘッダで、問題が起こった時のレポートの通知先URLを指定する

かなりシンプルで強力な仕様なのだが、一方で、Webページには以下のような制約が生じる。

  • コンテンツの中にインラインで埋め込まれた スクリプトやイベントハンドラは無視されて動作しなくなる。私の知る限りでは、
    • たとえば <body onload="..."> という形でイベントハンドラをインラインで書いているアプリケーションが大半なので、これは既存のコンテンツへの影響が大きいと思う。
    • <script src="..."> というタグをつかってJavaScriptファイルを読み込み、その中で DOM API を使ってコードの中でイベントハンドラを設定することはできるので、インラインスクリプトを使うコードを同じ振る舞いをするCSP互換なコードに書き換えることは、技術的にはできるはず。
  • 文字列をJavaScriptとして評価・実行するような関数は使えなくなる。
    • 代表的なものは eval だが、他にも setTimeout や setInterval 、また Function オブジェクトのコンストラクタで、処理の内容のスクリプトを文字列として渡す機能がJavaScriptにはあるが、これらは使えなくなる。ただし eval 以外のものは、文字列の代わりに Function オブジェクトを渡せる同等な関数があるので、変換はできるはず。
    • JSON 文字列をパーズしてオブジェクトに変換するために eval を使っている実装もあるが、これらはちゃんとしたJSONパーザを実装する必要がある。
  • src属性など（例 <img src="...">） に指定できた javascript: で始まるURLは、スクリプトとして実行されなくなる。（ちなみに現在でもFirefox 3.xなどのブラウザでは <img src="javascript:..."> は実行されない。ただし <iframe src="javascript:..."> は実行されるなどの抜け道があるので、これらもすべて無視されることになる）
  • "data:" で始まるURLは、ポリシーで明示的に許されている時だけOKになる。（data: で始まるURLではその後にエンコードしたコンテンツを文字列として指定できる。JavaScriptコンテンツをBase64でエンコーディングして <
  • policy-uriや report-uriは、Webページと同じドメインのみが許される。


CSPにより、ほとんどのXSSを防ぐことが可能になると考えられる。攻撃を成功させるには、ユーザ入力が動的に生成されるJavaScriptファイルの中に埋め込まれる必要があるので、Webアプリの方でそんな作り込みになっていなければ、攻撃は難しそうだ。（皆無とは言えないと思うが．．）

また、Clickjackingなどの攻撃も、embed タグで埋め込むオブジェクトの提供元を制限できるので有効。

CSPでは当初CSRFも対象にしようとしてたらしいが、現在の仕様からは外されたらしい。CSRFについては、HTTP Request に Origin というヘッダを追加して、その値をサーバ側で判断する方向を検討しているようだ。Origin ヘッダというのは Referrer に似ているが、ホスト名より上だけを通知するもの。これで、プライバシー上の問題は最小に、サーバ側でリクエストの連続性を確認できる。

感想：
バックワードコンパチでかつシンプルな良い仕様だと思う。予想外の設計を採用してしまうWebアプリは意外と多いのでこれですべてを防げるわけではないと思うが、大部分のものをカバーできると思う。
が、一方で、既存の Ajax アプリは大抵インラインのスクリプトやイベントハンドラを多用しているので、大幅な書き換えが必要になり、普及阻害要因となりそう。Dojoなどのライブラリで吸収できるのかもしれないけど。

Cloud Computingの攻撃利用

CloudSecurity

Cloud computing環境を攻撃に利用するというのも、やればできると思っていましたが、すでに事例が結構発生しているみたいですね。

ITMediaの記事によると

  • Amazon AWSのドメインによる攻撃が11月末時点で約250件
  • ボットネットの指令サーバがGoogleのAppEngine上に構築されている
  • Amazon EC2でパスワードの総当たり攻撃を試したところ、アルファベット8文字を使うパスワードならわずか3ドルで、数字を含めた場合でも45ドル程度で成功

一方で、オンライン共有ストレージのサービス提供事業者を踏み台にしたDDoS攻撃においては、分散型のインフラでサービスを提供しているクラウドでは、特定のサーバが狙われてもほかのサーバでサービスを継続できるため、対策として有効。

また、こちらの 記事によると、ZeusボットのコントロールサーバとしてAmazon EC2 が使用されていたらしい。もとの CAのブログはこちら。

EC2でRSA鍵解読を試みた人はいないのだろうか。。。

XCS: Cross Channel Scripting and its Impact on Web Applications

WebSecurity

Hristo Bojinov, Elie Bursztein, and Dan Boneh, XCS: Cross Channel Scripting and its Impact on Web Applications, ACM CCS 2009.

WebとWeb以外のチャネルにまたがってスクリプトインジェクト攻撃を行うものを XCS と呼び、攻撃手法の分類と、この攻撃への対策となる Site Firewall の提案。

XCSは大まかにいって、以下の3種類に分類される。

  • Web以外のチャネルからJavaScriptをインジェクトし、Webブラウザで見たときに実行させる XCS
    • たとえば、Webの管理インタフェースを持つNASなどで、ファイルを格納するときに、ファイル名にスクリプトをインジェクトしておく。すると、Webの管理インタフェースから見たときに、スクリプトが解釈されて実行される。
    • P2Pを介したXCS。BitTorrentから直接ファイルをダウンロードする機能を持っているようなNASの場合、ファイル名にスクリプトを仕込んだファイルをアップロードしておく
    • Logを介したXCS。たとえば存在しないユーザ名で管理コンソールにログインしようとすると、ログインが失敗して、ユーザ名がログに記録される。このとき、あらかじめユーザ名にスクリプトを仕込んでおくと、管理者がWebの管理コンソールでログを見たときに、スクリプトが実行される。
    • 携帯電話のXCS。Google Android や Palm WebOSはアプリケーションビューを作るのにHTMLとJavaScriptを使っているので、なんらかの方法でスクリプトをインジェクトできる可能性がある。現に、Palm PreではXCS脆弱性が報告されているらしい。
  • 逆に、Webのチャネルから攻撃をインジェクトし、Web以外のチャネルを攻撃するのが reverse XCS
    • もともとWeb管理コンソールつきのフォトフレームで、XSSやCSRF脆弱性のあるものに対して、ユーザのブラウザ経由で攻撃コードをインジェクトするようなものを reverse XCSと呼んでいるらしい。
  • RESTful APIを利用する RXCS. FacebookやTwitterなどREST APIを提供するSNSがあるが、これらのAPIを利用するサードパーティアプリを攻撃する。

対策としては、Client-side WAFのようなSite Firewallという仕組みを提案している。これは Firefox の Content Security Policy (CSP) に近くて、サーバ側からクライアントに対して、「このアプリからアクセスして良いサイトの一覧」をセキュリティポリシーとして通知する。Site Firewallではこれを見て、リスト以外のサイトへのアクセスを禁止する。セキュリティポリシーのコンテナとしてCookieを使ってるのが、少々変わっているところ。
PoCはFirefox Extensionとして実装。

感想：
Site Firewallの機能的にはCSPのサブセットのようなものなので、あまり新規性はないように見えるが、Cross-Channel Scripting という攻撃クラスを定義して、様々な攻撃パタンについて考察しているあたりがウケたのかなあ、と思える。

Cache Attacks and Countermeasures: The Case of AES

CloudSecurity
  • Dag Arne Osvik, Adi Shamir and Eran Tromer, Cache Attacks and Countermeasures: The Case of AES, Topics in Cryptology – CT-RSA 2006

CPUのキャッシュのサイドチャネルを使って、AESの鍵を見つける、という攻撃。
AESの処理の大部分は table lookup なので、キャッシュの使われるパタンを利用して、細かくメモリのどの部分が読まれているかというのを調べて行くと、AESの鍵が分かるらしいです。

先日読んだ ACM CCS 2009 の Amazon EC2上でのサイドチャネル攻撃についての論文 の中でも参照しています。ACM CCS 2009 の論文では同じキャッシュのサイドチャネル攻撃でも、VMの負荷やネットワーク負荷などの粒度の荒い情報しか検出していませんでした。
VMM上ではまた別の要因がからんでくるので、このRSA 2006 の論文と同じ攻撃を実行するのは困難、というようなことが書いてありました。が、キャッシュのサイドチャネル攻撃で暗号鍵の検出ができるほどの粒度が出せるというのは、さらに重大な攻撃の可能性を示唆していると思います。

なおこの攻撃の対策として、某社のHWで、AESの専用ハードウェアを使って、AES暗号の処理がメインのCPUキャッシュを使わないようにしたらしいです。