2012/03/22

暗証番号と生体認証の違いと国民総背番号制

これまで生体認証については、指紋の他に虹彩や静脈認証の経験がある。 静脈認証はかなり良い線いっているけれど、工作で回避できたという主張もある。

とはいえ、いまの暗証番号よりも信用しすぎる事がなければ、ずっと良い代替手段にはなるはずだ。

では切り替えが進んでいないようにみえる背景にはどんな事があるんだろう。

基本的なことがら

暗証番号が生体認証におきかわったとした未来を想像して、いままでの自分の経験に照らして困る事といったら、17,18の頃に父親の代りに生活費を銀行口座から引き出していた事ぐらいだ。

とはいえ、パソコンのログインパスワードが生体認証に置き換わった時には、相当混乱するであろう現場をいままでの経験から両手では数え切れないぐらい知っている。

だからパスワードは無くならないと思う。

容易に他人に移譲できる暗証番号番号から、物理的にも特定の個人に紐付く生体認証にかわっただけの事で、その基本的な機能は変化していない。ただ、一時的な例外的な扱いにつて、例外処理を厳格に設けなければいけなくなっただけだ。

権限が移譲されている事の証明が必要になる。

しかし、なにより、基本的にはこれまで適切な人間を代理人に指名して、それを証明する便利な方法は存在していない。

社会生活上は委任状の仕組みがあるけれど、それはただの責任を回避する仕組みでしかない。

住民票の取得なんかで免許証で個人を特定できたとしても(Authentication)、その人が権限を移譲されているかどうかを判断すること(Authorization)とは本質的に別の事だ。

ある人が他人に自分の権限を移譲するためには、これまた別の第三者がそれを信じるに足る相当な理由が客観的に証明されなければいけない。そのために時間がかかるようでもいけない。

代理人の存在を証明するには、その生体認証そのものを使って署名をするのがベストな方法だと思う。 その署名データが流通する仕組みがあれば、、他人も十分に代理人の正当性を信じる事ができるだろう。

データの流通の問題が解決できれば生体認証の仕組みを使って相当に便利な世の中にする事ができるはずだ。 それを提供するのは行政の役割のような気もするし、社会インフラとして整備すれば、ある情報が特定の人によって了承された事が容易に証明できるようになる。

一卵性双生児の存在がセキュリティホールにならない程度に生体認証の精度が上げられれば、技術的にはパスワードは不要なものとなるだろう。

生体情報をいろいろな場面で要求される事で発生する問題

署名とはいっても実際にはICカードなどに入っている電子的な本人証明書にアクセスするための鍵として生体認証が使われるだけだけれど、そのICカードと生体との電気的接続の間をハイジャックする事ができれば、同じ電気信号を与える事と鍵の入っているICカード的なものを盗む事でその鍵を開けられてしまうかもしれない。

ICカードなんかからチャレンジコードを出してタンパー耐性のあるデバイスと暗号通信させるしかないんだろうけれど、手軽に指をガラス上に置く機会が増えれば鍵となる生体データをコピーされる機会もまた増えるだろう。

問題は解決しないように思えるけれど、定期的な証明書の再発行と古い証明書の廃棄で被害を抑えこむ事はできるだろうし、暗証番号とは違って外部からの観察によって漏れる危険はかなり低いから現状よりはずっと安全になるだろう。

現状の暗証番号を使う場面よりも、安全だと勘違いをして、広く権限を与えるような事をしなければ、つまり、いままでと同程度の使い方であれば、生体認証への切り替えはずっと安全になるはずだ。

最終的には生体認証を積極的に使うべきだと思うけれど、その導入が銀行のATMだけなら、コストとラーニングカーブの観点からかなり普及は難しいだろう。普及のハードルはかなり高い。

人間の心理的な抵抗を甘くみることはできない。

とはいえ、全体的な絵を描けるアーキテクトが出現するか、現行のシステムが破綻するほど治安が悪化すれば、生体認証は表舞台に立てるだろう。 そうでなければ、せいぜい大企業のシステムに取り込まれるぐらいで終ってしまうかもしれない。

普及についての議論はおおいに盛り上って楽しいものになるだろうけど、現実の近未来を考えると、その見通しはかなり悲観的に感じざるを得ない。技術的な問題よりも心理的な抵抗を軽減することが難しいと思う。

自分自身をその変化に適応させてまで必要だと納得するのは難しいだろう。 現行のシステムに欠点があると知っても、それが自分自身にふりかかるまでは、耐えられるからだ。

積極的な普及を図るなら、小さい成功事例を積み上げていくしかないだろう。 いまのところは個人で始められるのは、NFCがRFIDぐらいだけれど、可能であればいろいろな場面で生体認証を使う機会を増やして、その可能性が確かなものか試していきたい。

EXIF Geotag Checker Chrome機能拡張を作った時の変更点まとめ

画像ファイルにGPSの位置情報が入っていたら気持ち悪いなぁと思って、いくつかChrome機能拡張を探してみました。 ちゃんとExif情報を表示するものはいろいろあったのですが、その中からプライバシー情報を見つけるのは面倒で、汎用的なViewerはあったのですが、適当なものがみつかりませんでした。

Exif Geotag Checker Window

EXIF情報が常に悪いかというと、写真なんかを扱う人であれば、管理上は間違いなく重要な情報で、画像ビューアーがいつの間には画像を上書き保存していてEXIF情報が失われたと知れば怒る人もいるでしょう。

iPhoneであれば画像をメーラーで添付する時にEXIF情報は削除してくれますが、iPhoto経由なんかで普段とちょっと違う方法で画像をアップロードしたらGPS情報がばっちり残っている可能性もあります。

今回は思い切ってEXIFの数あるエントリの中から、GPSだけ、それも時刻、緯度、経度情報の3点だけを表示するツールを作成してみました。 EXIFの時刻情報のDateTimeOriginalもみるべきなのかもしれませんが、それはツールが勝手に改竄したとかいう主張も通りそうに思えるので今回は省きました。

興味のある方は、Gitoriousでコードをforkして機能を追加してみてください。

今回作成した機能拡張の機能そのものもはライブラリに頼っていますが、それ以外の基本的なところでいろいろ壁にぶつかったのでまとめておくことにしました。

作成したChrome機能拡張について

DateTimeOriginalについてのところで書きましたが、今回はGPS情報の3点だけを表示するようにしました。 EXIFのコメント欄にメールアドレスなんかが入っている可能性もあります。
とはいえ、全部をチェックするのは時間がかかる上に、現実的には問題が発生する可能性は低そうです。

それが必要であればEXIFのViewerを使ってください。

制限事項

今回作成したアプリケーションは、Ajaxなどでブラウザに動的に表示している画像には対応できません。

その他にもいくつか制限はあるものの、本格的なExifViewerはむしろ余計に混乱するので、いくつかの技術的なポイントの解決策の模索と合わせて、ニッチな需要を探してみる事にしました。

技術的なポイント

機能的の中心になるEXIF情報の取得には、既に公開されている外部ライブラリを使っています。 README.mdにも含めていますが、中心となる機能部分にはJacob Seidelinさんのexif.js(+binaryajax.js)を使用しました。

この他にもContent Scripts側での非同期処理を扱うために、jsDeferredライブラリ(jsdeferred.nodoc.js)も使用しています。

いろいろライブラリは使用しましたが、最終的にはexif.jsとbinaryajax.jsには、次のような変更を加えています。

  • IEに特化したコードをロードする個所のコメントアウト
  • 起動時の自動ロード(loadAllImages)の停止
  • exif属性のあるimgタグだけを対象にしていた処理のスキップ
  • 画像データを入手するためにメッセージボディ全体を入手するコードの追加

作業の中心はEXIFについてではなく、できるだけドキュメントのDOMの影響を受けないようにしたり、非同期呼び出しの内部構造作成に時間を取るようにしました。

取り組んだいくつかの課題

開発の前の調査段階と開発初期の試行錯誤の時期では次のような、課題を感じました。

Chrome機能拡張に固有な課題

画面に表示されているデータはDOMとして入手が可能ですが、Chromeで直接にDOMを操作するためにはContent Scriptsと呼ばれるコードインジェクションの手段を使う必要があります。 BackgroundタイプやBrowser Actionタイプからは非同期(コールバック)通信の仕組みを利用して、その結果だけを受け取る事になります。

またContent Scriptsは、画面に表示されているドキュメントの構造(DOM)の影響を受けます。 例えば、Content Scriptsを使って画面上にjQuery UIのポップアップウィンドウを表示させようとすると、コンテンツが既にロードしていたCSSの影響などを受ける可能性があります。

他のExifViewerを使って感じた課題

EXIF Viewerと呼ばれるようなアプリケーションをいくつか触ってみた時に、画像を解析するために外部のCGIを呼んでいるものがありました。

Browser Actionであるポップアップウィンドウから画像データにアクセスするのは面倒なのでリーズナブルな方法ではありますが、データを送信したCGIから画像データにアクセスするため、外部に公開されているサイトでないと正常に動かない課題があります。

このため、NATの中にいる自宅やイントラネットなどからはうまく動かない事になります。 また場合によっては画像が外部サイト上にキャッシュされる事を問題視する事もあるでしょう。

解決するべき課題

ざっと感じた点をまとめて、以下のようなポイントに注意して作業を進めました。

  • 外部サイトのCGIなどに頼らず、Chromeブラウザで完結した処理を実現する
  • アドレスバーの横にアイコンを出し、ポップアップした画面に結果を表示する
  • 問題があるか、ないか、ひと目で判断できるようにする

とはいえ画像データを2重にダウンロードする課題はあります。そのためJPEG画像のみをロードするようにPNGやGIFは無視する仕組みを入れています。そのためにexif.jsにもともとあった、読み込む対象をexif属性で指定する処理と、全ての画像データにアクセスする処理は動かないようにしています。

その他にも、ポップアップ画面で画像を表示させる時にもBasic認証が必要なページや相対URLから絶対URLへの変換といった面倒な処理への対応が必要になります。

こんな感じで、解決するべき課題はありました。 しかしなんとか、荒削りですが、一通り動かすことができるものを作る事ができました。

作成したコードはGitoriousから入手する事が可能です。

また機能拡張自体はChrome Webストアから入手する事ができます。 [ EXIFジオタグチェッカー ]

Browser Actionとしてポップアップ画面からコンテンツの画像を表示する方法

Chrome機能拡張についていえば、アクセスしているタブページとBrowser Actionでアドレスバー横のボタンを押して表示されるポップアップ画面とは完全に独立しています。

この環境でポップアップ画面に画像データを表示するためには、imgタグのsrc=...に次の2つの方法で画像ファイルを指定する必要があります。

  • httpから始まるURLで画像ファイルの場所を指定する
  • Base64でエンコードされたデータそのものを指定する

データそのものを指定する方法は、情報量が増えるので普通は使いません。

どちらでも良さそうだと思ったのですが、認証が必要なページの画像をURL指定でポップアップ画面からアクセスした時には認証ダイアログは出ずにアクセスが拒絶されました。 そんな分けでBase64を使って、タブページから画像データの情報そのものを入手できるようにContent Scriptsを作成しました。

扱うデータの量が増えたので、少し負荷テストらしき事をしてみました。 この段階ではSpeed Tracerのために開発版のChromeを使う必要があって準備していないので、細かい時間の測定は後回しにして、印象だけで書いています。

負荷テスト1

バックグラウンドでexif情報をチェックするスクリプトを動かして画面のレンダリングに異常がないか、確認しました。

テストのためにWebサイトの画像作成用に持っているイメージ素材集のJPEGイメージをいくつか使い、一つのindex.htmlの中にimgタグを2600以上配置させる負荷テストを行ないました。

この中にgeotag情報を持ったJPEG画像を配置しましましたが、時間がかかったものの、ローカルのWebサーバを経由させた事を考えても、思ったよりも早いスピードで処理を行なう事ができました。

負荷テスト2

次にGPS情報を持ったJPEGファイルのコピーを100件作成し、index.htmlに100件のimgタグを書き込んで、このファイルをロードするテストを行ないました。

この記事を書きながらテストしている今は、結果を表示するまでに1、2秒程度のタイムラグがあります。 デフォルトのページの内容が更新されないと、読み込み中なのかどうか、そのステータスを表示することができていません。

機能拡張を入れることでJPEGデータのロードは2倍発生するので、その分の処理時間は単純に倍かかります。 その予測とほぼ同じ変化がある事はわかりました。

ブラウザが表示した画像データのキャッシュにアクセスできれば良いのですが、そうするとCaptchaや乱数表のようなアクセスする度に変化する事でセキュリティを保っているようなアプリケーションの脅威になってしまうので、永遠にそんな事はできないでしょう。

そんな分けで、JPEGファイルについて再読み込みを許可、あるいは予測していない場合には、JPEGファイルに2回アクセスする事で問題が発生する可能性はあります。

今後Chrome機能拡張を作成する時に気をつけること

今後も気が向けば機能拡張を作ったり、現状のアプリケーションに変更を加える事もあるでしょう。

タブに開いているコンテンツ(のDOM)にアクセスするタイプのアプリケーションは、その解析にContent Scriptsを使い、そのデータの取得に非同期(コールバック)通信の仕組みを使う事になります。

そういった全体の構造を考えて、どういうコードをどこで使うか、そういう判断というか、全体の構成と楽をするための手段について検討することが必要でしょう。

JavaScriptを使う時にはライブラリを使わなくとも似たような処理はいろいろな方法で可能になります。 しかしコードが長くなって読み難くなってしまうところが難点だと思っています。

苦労すれば最終的に同じ(ような)機能の実装はできるけれど、それを高いメンテナンス性を保って作る事は、相当な知識と面倒な作業が発生するでしょう。JavaScriptの手軽さと難しさはそういうところにあると思います。

余談ですが、JavaScriptを学校で教えるべき言語に上げる人は多いそうですが、かなり特定の問題領域(ドメイン)に特化した知識+経験になりそうな点が心配です。

情報系の大学であれば、同じものを別の角度でみるためにも、JavaとScalaを合わせて教えて、同じ機能を別々の方法で実装させたりするのが、時間はかかっても最終的には良いJavaScriptプログラマを生み出すような気がします。

創造性っていうのは応用力の積み重ねでしかないので、思ったものが作れれば何でもいいんですけどね。

JavaScriptの需要が多いのは確かですが、最初からJavaScriptだと、苦労をしてもJavaScriptしか使えない人間になりそうに思えるのが怖いところです。