2012年11月04日

ハッシュ化ではユーザー追跡による名寄せ=個人情報の復号を回避できない

強固なハッシュ関数を用いても、名寄せ・ユーザー追跡を回避して個人情報を秘匿する役にはたたないことは、情報を利用する側の人以外には、あまり理解されていないように思う。
そうでなければ、「パスワードや個人情報をハッシュ化して対策」などという奇妙な誤解がまかり通るはずがない。現在のインターネット上で収集されるハッシュは元のメッセージとほとんど等価だ。


ハッシュでは元メッセージが推定できる
ハッシュ関数は原像困難性をもつので、秘密のメッセージMのハッシュC=H(M)から元のMを推定することは『メッセージMが完全にランダムな場合は』出来ない。
しかし、電話番号は約9桁で30bit程度しかバリエーションがない。48bitのMACアドレスも(UserAgentなどで公開される)端末のチップベンダーから高々24bitのバリエーションしか無い。

秘匿するべきメッセージの範囲が推定できる場合、いわゆる辞書攻撃ができる。メッセージとハッシュの組み合わせの辞書(あるいはレインボーテーブル)を用意することで、ハッシュからメッセージを復元できてしまう。30bitという組み合わせの数は6文字の英数字パスワード(30〜36bit程度)より弱い。

MACでも追跡し名寄せできる
漏洩対策として、ハッシュと秘密鍵やsaltを組み合わせたメッセージ認証=MACをハッシュ化と呼んで使うことが多い。パスワード保存時にハッシュとソルトを保存することは一般的になった(と願う)。しかしこれもほとんどの状況下で悪意ある名寄せの対策にはならない。

まず秘密鍵・saltがハードコードされた固定値の場合、秘密鍵Kは定数とみなせるのでMAC関数MH(M,K) == H(M) すなわち単なるハッシュに書き直せる。この場合、ハッシュ関数を書きなおすだけなので辞書攻撃のコストはほとんど変わらない。(パスワード保存にアカウントごとにランダムなsaltが必要な理由)

秘密鍵Kがユーザー毎に違って安全なMACであっても、IPアドレスなどの公開情報や、サードパーティCookie、ローカルDBなどアプリ・サーバー間通信を用いて、MACのままユーザーを追跡し名寄せすることは出来る。MAC自体から元メッセージを復元できない"匿名の識別符号"であっても、名寄せした先に個人情報、たとえばSNSのアカウント名や購買履歴などが紐ついていれば、最終的に個人情報の復元が可能になる。


個人情報を復号できなくするためには、
  • ハッシュではなく秘密鍵(salt)を組み合わせたMACを使うこと
  • 秘密鍵はランダムに生成し端末の安全な領域に保存し、他の情報から推定できなくすること
  • 秘密鍵はユーザーが追跡されてよいと考える範囲内でのみ保持・共有し、追跡されたくないときに破棄、あるいはランダムに再生成すること(例えば、アプリをアンインストールしたら秘密鍵を破棄する)

で足りるが、ユーザー追跡・名寄せによる個人情報の取得を回避するには、
  • ユーザー追跡手法を用いても、匿名の識別符号=ハッシュ自体を名寄せできないこと

が必要になる。
追跡の手段は多数存在し全てを遮断することは困難、そして個人情報を一切出さずにインターネット上で活動することは既に不可能に近い。個人情報と紐付けられた脆弱なハッシュや、悪意ある個人情報管理者が一つでもあれば元の個人情報を復元できてしまう。
ユーザーの個々のアクセスは匿名で行えても、ユーザー追跡は容易で、追跡した先に個人情報が紐ついている可能性は十分にある。

OS以下を管理できるPCなら追跡を排除できる可能性があるが、携帯端末のようにOSレベル以下を書き換えることが困難な場合それすら難しい。
アプリ内広告などに使われる端末固有識別子はアプリ自身が管理しているので、ユーザー側で名寄せ対策するには、全てのコードをデコンパイルし、実装・通信内容に問題が無いか確認するか、アプリと外部の通信を全て遮断するしか無い。

今のところ、アプリ利用時の権限チェックと、rooted・JailBreak端末で端末情報へのアクセスや広告サーバーへの接続を禁止することが現状最善の解決方法と考えている。しかし、実用上通信が必須なアプリは多く、root化済み端末をチェックして利用を拒否するアプリ・ライブラリはau marketなど既に普通に存在する。root化での環境改変自体法的にもグレーだ。アプリに許可された権限や署名を改変する、より強力な方法も無くはないが、OS実装に関する知識や安全な署名を必要とする。

不当な名寄せや個人情報の悪用は違法となるべきだが、ユーザー追跡・名寄せによる個人情報の収集はサーバー内で秘密裏に行うことが出来、巧妙な(あるいは馬鹿げた)利用規約で法律問題を丸ごと回避することさえ可能だ。
一方、セキュリティ上警察組織などリソースの限られた第三者しか情報の扱いの健全性を検証することが出来ないので、ユーザーには識別符号が適切に利用されているか判断することは不可能で、盲目的に信用するか、自衛するしかない。

アプリ開発側は、可能な限り送信・共有が必要な情報を明示し、通信内容の可読性を高めて第三者に検証をしてもらう努力をしなければ、利用者の不信は募るばかりと思う。
posted by ko-zu at 20:28| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年11月03日

SHA-3・Keccakのスポンジ関数の利点のまとめ

Keccakをもう少しよく見てみた感想。スポンジ関数はなるほどよくできている。
以前のエントリ、 Keccak自体は「SHA-3に選出されたKaccakのスポンジ関数方式」http://causeless.seesaa.net/article/295263150.html
を参照。

前提として、ハッシュ関数の耐性の分類

強衝突耐性
ハッシュCについて、C=H(M1)=H(M2)となる異なる2つのメッセージM1とM2を推定できないこと。
言い換えると、秘密のメッセージM1のハッシュC1=H(M1)について、C1だけが与えられた時、H(M2)==C1になるようなメッセージM2を推定できないこと。

弱衝突耐性
メッセージM1が与えられた時、H(M1)=C1=H(M2)となるようなM1と異なるメッセージM2を推定できないこと。

第二原像困難性
秘密のメッセージM1のハッシュC1=H(M1)について、C1だけが与えられた時、C1=H(M)ないかなるメッセージMを推定出来ないこと。(MはM1と違っても良い)

第一原像困難性
秘密のメッセージM1のハッシュC1=H(M1)について、C1だけが与えられた時、M1が推定できないこと。

大まかには上から順に重要度、つまり破られた場合の深刻度が増していく。

衝突耐性を突破する手法のほとんどは、M1に対応するM2がごく稀なので、推定できるM2は不正なフォーマットや意味のない文字列になることが予想される。元データを秘匿する必要がなく、フォーマットが不正なデータを排除する機能がハッシュ関数の外部にある場合については直ちに問題はない。

MD5以前のように意味有る衝突を実現できた報告がある場合、すなわち任意のM2を生成できる衝突耐性突破法が見つかった場合完全性の証明につかえなくなる。例えば、SSL・PGPなどの電子署名に使うことができなくなる。
また、原像困難性が突破された場合には上に加えて、メッセージの秘匿にも使えなくなる。例えば、パスワードのハッシュ化保存に使うことができなくなる。これは完全なレインボーテーブルが生成可能であることに等しい。


Keccakの安全性トレードオフ
Keccakに使われているスポンジ関数は、内部状態を大きくして、その一部にXORでデータを入力、あるいは一部を切り出してハッシュを出力する。入出力毎にスポンジ関数で内部状態全体が撹拌される。
http://sponge.noekeon.org/

スポンジ関数方式では、撹拌一回あたりの入出力データ幅という簡単なパラメータの調整で、原像困難性・衝突耐性とパフォーマンスのトレードオフをかなり自由に選択できる。
一回あたりの入出力データ幅を増やすと、出力されない秘密の内部状態は相対的に小さくなるため、原像困難性が低下する一方、スポンジ関数の呼び出し回数が減るためパフォーマンスが向上する。

たとえば、64bit処理系に最適化された、1600bitの内部状態をもつスポンジ関数に512ビット幅で512bitのデータを入力し、512bitのハッシュ出力を得るとする。
http://keccak.noekeon.org/tune.html の式における、r=512、c=1088に相当する。

スポンジ関数1回の逆演算コストが十分安くなったと仮定しても、512bitのハッシュだけでは元のメッセージを得る事は困難だ。スポンジ関数の内部状態の残り1600-512=1088bitはハッシュに出力されず推定するしかないため、原像を特定するには残り1088bitを総当りするか、スポンジ関数アルゴリズムの根本的欠陥を探す必要がある。

スポンジ関数自体が安全で、一回分の逆算ですら困難な場合、スポンジ関数を繰り返し適用して、例えば二回よびだして1024bitのハッシュを得ることも安全に出来る。
衝突耐性が原像困難性を上回ることはないので、1088bitを超えて際限なく出力することは無意味だが、出力時にスポンジ関数を可変回数呼び出せるよう実装すれば、変更の際に追加のハードウェアやソフトウェアを必要としない。
また将来、原像困難性をさらに向上する必要があった場合、たとえば1472bit必要になっても、4倍の処理時間を許容すれば入出力幅を128bitに小さくするだけで対応できる。


実装の容易さ
Keccakは基本的に64bitハードウェアを前提に設計されていて、必要なレジスタ数は25と多いものの、x64なソフトウェアでも現実的な性能が望める。SHA-2のようにハッシュ長毎の複雑な関数バリエーションを個別に実装する必要もなく、専用ハードウェア・IPもそう簡単には陳腐化しないだろう。(うまく実装すれば64bit版の一部を使って32bit版にも対応可能のようだ)
AES-128、SHA-256のみ対応、といった不完全・部分的な実装が蔓延する危険性も防げるかもしれない。

スポンジ関数が十分強固である場合、ハードウェア実装コスト低減と将来的なパフォーマンス・安全性の調整が可能であるという点で、SHA-3は良い選択と言えそうだ。

スポンジ関数という根本は実に単純なアイデアで、実装や普及上の困難の大部分を解決してしまっている。暗号技術の面白さがよく分かる事例と思う。





タイトルから期待していたものと違う!という御指摘(汗)が有ったので追記してみる。
https://twitter.com/daidaiBANANA/status/264664673369092096

鍵生成とストリーム暗号への適用可能性
スポンジ関数方式では最後に圧縮関数を使う必要がないので、単純に切り出すだけで、(入力途中含め)いつでも好きなだけ出力を取り出せる。
スポンジ関数一回の逆算のコスト=原像困難性が十分なら、ストリーム暗号とみなすことが出来る

さらに、スポンジ関数がストリーム暗号として使えると、鍵生成関数も不要になる。
通常の暗号は別途に鍵生成関数を実装する必要がある。人間が入力するパスワードには偏りがあり、長さも暗号鍵、例えば256bitAESより短いことが多いため、そのままでは秘密鍵として不適切。通常はハッシュ関数を使って、なるべくランダムに分布する秘密鍵を作るので、暗号とハッシュ(鍵生成関数)の両方を実装する必要がある。

スポンジ関数をストリーム暗号として使う場合、鍵生成の代わりに通常のKeccak同様にパスワードをメッセージとして入力する。
その後、ブロックサイズ、例えば512bitのカウンタをスポンジ関数の一部にXORして、スポンジ関数出力512bitを暗号文とXORすることでCTRモード暗号として利用できる。 復号もカウンタの初期値を受け取って全く同様の方法で行えば良い。
概念的には http://sponge.noekeon.org/ 下の方の画像を参照

これらはスポンジ関数の入出力にごく簡単なロジックを追加するだけで実装できる。AESとSHA-2を両方実装するよりも、Keccak一つ実装するほうが実装面積が少なくてすみ、一旦ハードウェア実装してしまえば、スポンジ関数の計算量も何とかなりそう。ブロック暗号や鍵生成関数の利用法を間違える危険性も減る

ただし、Keccakのスポンジ関数は高速化のため、AESなどの近代的な暗号と違って乱数表(S-BOX)を一切使っておらず、AESより弱い暗号かもしれない。
直感的にはハッシュ関数の原像困難性と暗号の復号困難性は同じなので安全と期待されるが、SHA-3コンペはあくまでもハッシュ関数部分の評価なので、Keccakの鍵生成・ストリーム暗号としての評価や規格が定まるのはまだ先と思われる。
posted by ko-zu at 14:17| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年10月25日

ブラウザのパスワードマネージャのクリックジャッキング脆弱性

ブラウザのパスワード自動入力機能(パスワードマネージャ)とクリックジャッキングを併用して、ユーザに意図せずSNSなどにログインさせる方法がある。
自分はこれはセキュリティ上問題のある動作、ブラウザ側の脆弱性だと思っている。

前提として、セキュアなHTTPSでないサイトについてパスワードマネージャーに対する攻撃は知られていて、HTTPSで設定したパスワードをHTTPでは自動入力しない、という方法がとられている。
もしHTTPでも自動入力を許してしまうと、ブラウザ側の同一生成元ポリシー(SameOriginPolicy/SOP)による対策はDNSインジェクションや偽装WiFiAPなどを利用して簡単に破られるので、簡単なJavascriptで網羅的にパスワードを詐取できる。従って、現存する全てのパスワードマネージャはSOPとHTTPSで守られていると考えていい。

しかし、ログインフォームにクリックジャッキング対策が為されていない場合、SOPが守られていても、ユーザに意図せずパスワードを送信させることが出来る
パスワードマネージャの自動入力のクリックジャッキング脆弱性自体は、既に2年以上前にBugzillaにポストされていた(mala氏から教えて頂いた)が、セキュリティバグではないと判断されてしまっている。Chromiumにもポストしたが、セキュリティバグでないとリジェクトされてしまった。
しかし自分はこの問題には、ブラウザ側で対策すべき理由があると考えている。攻撃に利用されるクリックジャッキング未対策のウェブサイト側には、積極的に塞ぐ理由が(ごく一部のユーザーからの信頼以外)無く、ユーザが巧妙に仕掛けられた罠iframeを見破ることは事実上不可能だからだ。


この手法それ自体では、攻撃者が直接的な利益を得られる確率は低い。僅かな利益を得られるシナリオとしては、
・SNSのログインページにログイン後リダイレクト機能があり、同一SNS上に用意した自分のページのログインユーザ閲覧数を稼ぎたい場合。
・攻撃対象ユーザのリアルタイム情報自体に価値がある、標的型攻撃の場合
があるが、露見時のリスクから考えてもっと他に良い方法が有るだろう。

一方、SNS側には露見した場合も信用の低下以外に被害がない
ユーザーの個人情報を集積し、広告を流すことで利益を得ているSNS側は、なるべく多くのユーザにログイン状態にいて欲しい。また、クリックジャッキング対策に有効なX-Frame-OptionsヘッダはまだXが付く標準化以前のものであり、必須ヘッダではない。そして、この対策をすることによって、ごく一部のユーザーの信頼の維持以外に直接的な利益が無い。
Evilなウェブサイトがユーザーのログインという同意を、第三者の攻撃に見せかけて捏造することさえ不可能でない。


他方、被害を受けるユーザーにとっては問題が生じうる
クリックジャッキングによってログインした場合に、SNSには位置情報など、通常ユーザーの意思で保護されるべきリアルタイムの情報が意図せず伝わってしまう。
SNSが足跡機能やユーザー現在位置などリアルタイム情報を公開する機能を持っていれば、SNSを通じて第三者が"意図的にログアウトしたい状況下にある"ユーザーの情報を取得できる可能性がある
そもそも、ログアウトしたはずのサイトにログインしているという事自体、ユーザの意図に反する動作で、安全でない環境にアクセスする際はCookieを削除してこまめにログアウトする、という初等的なセキュリティ対策を無効化してしまう。

また、冤罪事件から分かるように、CSRFやクリックジャッキングによるユーザーの意図しない行動について、刑事捜査の過程で(少なくとも冤罪被害者に利する方向には)考慮されない事が分かった。
ログインフォームにCSRF対策がなされていても、クリックジャッキング脆弱性があればログインを誘導でき、現状XSSは論外としても、ログインユーザに対するクリックジャッキングやCSRF脆弱性がウェブサイトの何処にも無いと言い切るのは無謀と考えられる。愉快犯がクリックジャッキングを二度成功させ、SNSや掲示板などにログインさせて犯行予告をポストできた場合、冤罪被害者が第三者による悪意あるCSRFやクリックジャッキングであると証明することはとても難しいのではないだろうか?


現在、ユーザーが意図せず情報を送信あるいは公開しうるSNSを2つ確認している。一つはログイン直後に位置情報がSNS側に送信され、もう一つはログイン状態表示と足跡機能によってリアルタイム情報を第三者に公開しうる。
二段階のクリックジャッキングによってログインユーザを騙って犯行予告といった比較的簡単な条件ならもっと有りそうだ。

少なくとも、X-Frame-OptionsヘッダがRFC標準でMUSTになるか、ブラウザのデフォルト動作がDenyになるまでは、クリックジャッキング対策は可能な限りブラウザ側で行うべきだ。
例えば、XFOヘッダに頼らなくても、以下のような解決法がある。

パスワードマネージャは、iframe.srcとwindow.location(つまりアドレスバーのドメイン)が異なるオリジンの場合に自動で入力はしない。パスワードを入力する前に、BASIC認証自動化URLの警告と同様に、「異なるサイトexample.comにパスワードが送信される場合があります」などと警告した上、ユーザーの明示的確認を得てから半自動で入力する。


将来的には、iframeを完全に禁止する、より安全な対策が実現するかもしれない。しかし今のところクリックジャッキングは何処にでも存在しえて、ウェブサービス側はともかく、一部のユーザーには脅威になる。ウェブサイトの善意に頼るよりも、ブラウザ側に対策が求められると考えている。

現時点で、この攻撃に対する手軽な対処法は、拡張機能などでiframeでの外部リンクを禁止すること。例えば、Adblockで次のフィルタを追加する。
##iframe[src*="//"]
サイト自身の機能を利用するためにiframeが必須なサイトがどれだけ有るか考えると、これが一番と思われる。

posted by ko-zu at 23:47| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年10月24日

DoS攻撃元としてIPアドレス特定された件

アンドロイドアプリ危険性評価サイトsecroid.jpを運営されている@lumin氏にDoS攻撃元としてIPアドレスを特定されてしまった。

自宅マシンおよびほぼ常駐のサーバをひと通りチェックしたものの、侵入などの形跡は無かった。DDoSでないようなので、何故DoS攻撃元と判定されたかを考えてみた。

Chromeのタブ開きすぎて再起動
本命。自分はベータ版Google Chromeでいろいろいじってたりするため、タブを大量に開いたまま落ちたり落としたりで再起動することがある。最近のFirefoxと違い、Chromeは起動した瞬間に全てのタブを読み込もうとするため、実質的にDoS攻撃になる。いわゆる田代砲と同じ。
secroid公開直後ぐらいに早速DoS攻撃受けてる、というツイートをほぼリアルタイムで見た覚えがあるので。これが自分だった可能性は高い。
これが下手な相手だった場合、もしかすると某図書館事件的に刑事告発・逮捕勾留されていたかもしれない。……Chromeを閉じる前にタブは全部閉じよう。

ルータの80が開いている
NEC・Atermの一部の家庭用ルータはデフォルトでWAN側httpdが開いているようだ(設定で禁止することが出来ないっぽい)。オープンプロクシやトロイと思われたのかもしれない。
WAN側port80のフィルタ設定してもHTTP動いてるんけれど、これバグじゃないの? Aterm……。

もろもろのポートでTCPが空いている
自宅サーバ有るためこれは仕方ない。自宅サーバは自分専用なのでkernel他サービス中断必須のアップデートも自由にできるし、保守されてない放置サーバよりかは安全。と思う。
流石にノーガード的な設定はしていないはず。


sakuraのVPSあたりに公開サーバを移すか検討中。ただメモリは自宅サーバじゃないと高い……。
月の電気代1000円程度で8GB物理メモリ自由に使える、ってのはVPSじゃ絶対無理。
ラベル:secroid
posted by ko-zu at 22:24| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年10月16日

ブログの投稿予約でアシの付かない犯行予告は出来るか?

……か?方式のタイトルなので話半分でお願いします。
真面目な話は http://tumblr.tokumaru.org/post/33682810605/web 辺りを読んだほうが良い。

大抵のブログには投稿を予約する機能があり、実装やUIは様々だが、指定時刻にブログ投稿・トラックバックやSNS通知を実行できる。
この機能を使って、アシの付かない犯行予告が出来るかもしれない

犯行予告偽装問題で警察が"特定"したIPアドレスは、メールのヘッダやサーバなどのアクセスログから得られたものと思われる。ISPはIPと契約者の対応関係を保持しているので、契約者までたどり着ける。
メールは様々な場所に半永久的に保存される事がほとんどだが、HTTPサーバや各種ファイアーウォールのアクセスログはデータ量が膨大になるので適当な期間で破棄してしまうことが多い(ログローテート)。
共用レンタルサーバなど、どのアクセスが重要なログか管理者が識別できなかったりすれば、全てを保存することは困難になる。

とすれば、アクセスログが消える時点以降に予約投稿できれば、脆弱性を突いて予約投稿した時点の真犯人のログを消去させる事は不可能ではない
例えばブログに、バックエンドDBにフルアクセス可能なSQLインジェクション脆弱性があれば、予約投稿記事や投稿者・DB上のログを捏造するのはたやすい。そしてそういった脆弱性は度々発見され、即座に修正されることがほとんどとはいえ、修正までに実際に攻撃されたかどうか細部までログを調べてチェックする人は稀だろう。

予約された犯行予告が正常に投稿された時には、深刻な脆弱性は全て塞がっているだろうから、真っ先に疑われるのはブログの運営者とサーバーの管理者で、アクセスログ無しに悪意ある第三者の存在を証明することは非常に難しくなる。
従って、犯行予告に使われうるコミュニケーション・パブリケーション系のサービスでは、アクセスログは全て、少なくとも威力業務妨害・脅迫罪の時効、例えば5年より長い期間保存する事が必須になる。


……というつまらない笑い話が浮かんだ。
同様にタイマーを使って記録を回避する方法は色々ありそう。例えばクライアントのメーラーやウェブメールの予約送信機能を悪用したり、もっとシンプルにタスク・スケジューラやcronで実行したり。

電子的な記録は捜査の"手がかり"になることはあっても、脆弱性さえあれば容易く偽造も隠滅も出来る、ほとんど証拠能力の無い代物。
脆弱性が過去に一つも存在しなかったソフトウェア・OSなど、現代ではもう存在しないと言って構わないだろうから、アクセスログがなかったら冤罪被害に遭うかも、なんてのは杞憂。

だといいんだけれど……
posted by ko-zu at 19:42| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年10月12日

平文パスワードの復号を必要としない生体認証について

前エントリの続き。プラス、平文パスワードを復号できる必要性が、某氏に理解してもらえなかったようなので。

一般に、OSサポートの無いサードパーティの認証ソフトウェアは、平文のパスワードを何らかの方法で復号する必要がある。(追記:もし平文パスワード無しにログインできるなら、OSの認証機構それ自体が脆弱であり、考慮する意味が無い。)
つまり「暗号化されたパスワード」という、総当りで簡単に平文を得られる可能性の高いデータを保持する必要があり、十分なパディングなど総当り耐性を高める適切な暗号化を施す必要がある。
暗号専用ハードウェアなどに保存されていたり、十分なDRMで見つからないよう保護されているならともかく、windowsレジストリなどの他のユーザからアクセス出来る場所に置くなんて論外だ。そのうえ、件の認証ソフトウェアは暗号化方式が酷かった。(恐らく56bit鍵だが直ぐ分かったということなので、秘密鍵をDRM無しにハードコードしていたのだろう。もしくはIV固定で選択平文で解けて鍵不要だったとか)

平文パスワードを必要としない指紋認証にするには、OSのサポートが必要になる。

認証ハードウェアにカーネルレベルのサポートがあれば、話は簡単。カーネル内の情報がユーザーランドから読み書き出来るなら、そもそも安全なOSでは無いので考慮する必要はない。カーネルは認証ハードウェアに直接アクセスして、ユーザーを識別出来る。
OSSならサードパーティベンダはカーネルドライバを提供してユーザにカーネルをリビルドしてもらえばよい。

プロプライエタリなユーザー認証機構をもつカーネルでサードパーティ認証を実装するには、Oauthと同じ仕組みが必要になる、と言えばWebの人にわかってもらえるだろう。
例えばTwitter=OS、twitterfeed=生体認証ソフトウェア、エンドユーザはそのまま人間に対応する。(無関係だけど今twitterfeedがうまく動かない……)

(追記、認証制御できる特権を持たないという意味で、)ユーザーランドで動く認証ソフトウェアは、OSサポートが無い限り、ユーザのパスワードを(暗号化して)保存して、複合した平文パスワードをOSに渡すしか無いが、OSサポートがあれば、ユーザを生体認証してアクセストークンを渡せば済む
この場合はアクセストークンを正しく暗号化して保護する必要はあるが、トークンが漏れてもパスワードは漏れない
またカーネルが異常なトークン利用や、脆弱なトークン保護機構を検出した際に、生体認証ソフトウェアを個別に失効させる事もできる。


前エントリ http://causeless.seesaa.net/article/296998112.html と合わせて、
OSサポートのないサードパーティの生体認証では少なくとも平文パスワードを復号できる必要があり、ハードウェア対ダンパ性か強固な暗号化の無い場合脆弱になる。OSサポート=カーネルレベルで実装するべき。
ということ。

ラベル:暗号論 生体認証
posted by ko-zu at 08:22| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

指紋認証の脆弱性に関するメモ

UPEK Protector Suiteなる指紋認証が、あまりにも馬鹿馬鹿しい実装だったらしいので解説しておく。
http://blog.crackpassword.com/2012/08/upek-fingerprint-readers-a-huge-security-hole/

生体認証は
・生体データが本当に生体から得られているかチェック(例えば偽造指紋スタンプではなく生きた指かどうか)
・生体データから得られる鍵が十分な長さを持つ(他の人と一致しない)
・認証プログラム自体が保護されている(ブルートフォース対策)
ことの組回せで成り立っている。
正しく実装すれば、生体データから鍵を作り、秘密データを復号することで、秘密データを安全に復元できる。

このうち生体データには、ノイズ以外にも体調・成長による変化といったゆらぎがある為、十分大きな鍵を作ることは難しい。
普及レベルに実用的な生体認証は小さい鍵しか得られないため、一般にブルートフォース攻撃に脆弱になる。

ブルートフォースから保護するためには、認証プログラムを安全なOS環境で実行し、時間辺りの認証回数を制限したり、一定回数失敗したら秘密情報を破棄する必要がある。
たとえば、銀行ATMは秘密鍵として使える情報量の少ない静脈認証が使われているが、静脈を銀行の監視カメラの下で偽造するのは難しく、ブルートフォースは不可能なので問題はない。

逆に言えば、認証プログラム自体を改ざんしたりして、ブルートフォース対策を迂回できる場合、(十分な長さを持たない)生体データを予想することで、比較的簡単に秘密情報にアクセスできてしまう。認証プログラムが一般のPC上で動いている場合、他のユーザのように一定のアクセス権を持つ第三者からも、完全に保護することはとてもむずかしい。

高価なアプライアンスでは、独立したハードウェアに認証システム全体を取り込み、ハードウェアの耐タンパ性で認証プログラムとデータを保護することで、生体情報の鍵データの小ささをカバーしている。これが本来の生体認証と言われるもの。

問題が指摘されている指紋認証は、ソフトウェア、しかもWindowsレジストリに秘密データを保存していたため、簡単に暗号化された秘密情報にアクセスでき(ブルートフォース対策を回避する必要が無い)、しかも指紋から得られる鍵情報がとても小さいため簡単に鍵を推定できるようだ。
さらに酷いことに暗号化されたと言っても、常に一定の固定鍵だったようだ。
http://www.zdnet.com/enterprises-most-vulnerable-to-fingerprint-reader-attacks-researcher-says-7000005575/


大雑把に言って、レジストリにアクセス可能なソフトウェアをインストールしてしまうと、パスワードを平文で得られる。
悪意あるソフトウェアを起動した瞬間にパスワードが漏れることになるため、記事の参照しているブログでは、指紋ログイン機能を停止することを推奨している。

(追記)
生体認証の安全性と、平文パスワードを復号する必要のない生体認証を実現する条件について、次のエントリに書いた
http://causeless.seesaa.net/article/297035731.html

(追記)
Lenovoの http://support.lenovo.com/en_US/downloads/detail.page?DocID=DS031505
が対策パッチかもしれない from http://b.hatena.ne.jp/airj12/20121012#bookmark-115103634


ラベル:生体認証 暗号論
posted by ko-zu at 00:12| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年10月11日

通信記録やPC上のデータは確実な証拠にはならない

PC遠隔操作による脅迫事件について、崎山伸夫氏と小倉秀夫氏の昨日辺りから続く(とても不毛に見える)議論を見ていた。

現在、PCに遠隔操作用に、アンチウイルスソフトウェアで検出できないウイルス類を送り込むことは不可能ではなく、実際に今回の件で実行できてしまった。
同時に、Web・PCに関する一定の知識を持っている人にとって、PCにウイルス等が感染し、第三者が遠隔操作してその後隠蔽のために削除された、という偽の記録を作ることはむしろ簡単である。

これは既に、PC上のデータには確実な証拠能力は無いことを意味する。弱い状況証拠として採用されることは有りうるだろうが、不確実な状況証拠だけでは有罪になり得ない。
同様に、PC上のデータが証拠能力を持たないのであれば、PCが利用しているIPアドレスとの通信記録も確実な証拠能力を持つわけではなくなる。つまり、PCを誰が制御していたかの証明にならない。

これがもし電話番号だったら、警察・裁判所も冷静に対応できたかもしれない。
例えば、置引きされた携帯電話から脅迫電話がかけられるということは有りうることであり、通話記録それ自体は確実な証拠と言えない
脅迫電話の録音テープと本人の声紋の一致、凶器準備、利害関係の確認といった他のより確実な物的・状況証拠を積み上げる必要があるのは明らかだ。

今回の事件を脅迫電話にたとえるならば、家に鍵がかかっていない長閑な田舎の固定電話を用い、不法侵入した第三者が役所に脅迫電話をかけ、録音テープのような他の物的証拠なく何も知らない家主を突然逮捕した、ということだ。逮捕理由は電話機に残る通話記録を隠される可能性があるため。そして受話器からは他人の指紋が見つかった。

今回の事件で警察が捜査を逮捕時点で捜査を打ち切った場合、釈放される事なく有罪にされた可能性がある。警察が調べないほうが有罪になる確率が上がるというのは、あってはならない状況だ。裁判所がまともであればいいが、今回の逮捕状を出したのは裁判所だ。少なくとも対応した裁判所に本件について適切な判断力があったとは考えにくい。最高裁判所なら、罷免に投票できるが、今回の件で逮捕状を許可した裁判官の名が明かされることはないだろう。


今後同様の事件が起きた場合、例えば爆破予告なら、必要な火器など凶器準備の証拠を集める必要がある。
PCのデータやIPアドレスの記録など電磁的記録の証拠能力がほぼゼロである以上、購入履歴など直接的な証拠となりうる第三者のデータなり物的証拠なりが必須で、それまでは継続監視するなど、逮捕以外の方法で安全を確保するしか無い。

国外などへ逃亡の恐れがあったり、凶器を処分される恐れが高い案件であれば、逮捕は必要だろうが、大義名分である証拠処分の容易性を証明するのは警察側の責任だ。
そもそも証拠能力のないPC上のデータを消される可能性について、逮捕の必要性を論ずること自体的はずれに過ぎる。


現在、インターネット上の何かいうこと=データの複製はタダだ。「今日誰かを○します」という書き込みはいくらでもできる。警察が全てまともに取り合うならば、dDoSになることは明らかだ。

警察は「嘘を嘘と見抜ける能力」を育てて、ネット上の通信を全て本気にして近視眼的に逮捕勾留するのではなく、本当に本人が犯罪予告している緊急な案件を見分ける力を育てなければならないのではないだろうか?
今回の件は、せいぜい利用された可能性のあるPCを差し押さえして被疑者を監視をすればいい案件だったように思われる。

逮捕に必要な、証拠隠滅や逃亡の恐れを証明する必要性があるのは逮捕する警察の仕事だ。
逮捕した上、自白を強要したあとで、証拠がなくなりました、なんて論外。別件逮捕と同根。

posted by ko-zu at 22:09| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年10月07日

全国電話帳アプリのアドレス帳漏洩と、住所でポン!について個人的まとめ

各社報道も出揃ったようなので自分の理解をまとめてみる。

現状の報道
http://www3.nhk.or.jp/news/html/20121006/t10015569881000.html
http://www.jiji.com/jc/c?g=soc_30&k=2012100700067
http://www.tokyo-np.co.jp/article/national/news/CK2012100702000096.html
http://mainichi.jp/select/news/20121007k0000m040072000c.html
などなど。

@tottoriloop氏の提供する『全国電話帳』アプリは、ユーザーの電話帳70万件以上を公開状態に置いていたとして捜査されている。
この問題は、複数の法律にまたがったややこしい問題を含んでいる。

問題視された点は
・全国電話帳アプリがユーザ端末内のアドレス帳をアップロードした点
・作者のサーバでは、ユーザがアップロードしたデータが誰でも閲覧・検索可能になっていた点
・上記の点が正確にユーザーに伝わっていない点

また直接は関係ないが、同一作者の
・「住所でポン!」というサイトでの電話帳情報公開
も関連して語っている人が居る。


@ アドレス帳のアップロード
これは、不正指令電磁的記録の供用、所謂コンピュータウイルスの悪用として、問題視されている。

高木先生の解説などが詳しいが、法令の定義上、『ユーザーが意図しない事』を実行するプログラム全般がウイルスとみなされる。

アプリ解説には、
過去のハローページとタウンページに掲載された約3800万件の情報をもとにデータベースを作成しています。加えて、アプリ利用者のアドレス帳、GPSの情報も利用します
とあり、この一文によって、作者はユーザーの同意を得て、ユーザーの意図通りアップロードしたもの、と考えて居るようだ。
これは http://causeless.seesaa.net/article/296089367.html に書いた。

これは作者が意図してグレーゾーン、それもかなり黒い側ギリギリを狙って書かれたアプリ説明と思う。
もし自分なら、
全てのアプリ利用者のアドレス帳を対象に検索することができ、そのためにサーバーに各利用者のアドレス帳をアップロードします。
のように明記し、アプリ起動時にも同様の警告を行なって利用の可否をユーザーに尋ねるよう、実装するだろう。グレーゾーンに踏み込む必要など無い。


A サーバー上での公開
これは個人情報保護法について問題視されている。
個人情報保護法には例外規定があり、総務省のガイドラインには
http://www.meti.go.jp/policy/it_policy/privacy/kaisei-guideline.pdf
個人情報データベース等が、以下の要件のすべてに該当する場合は、その個人情報データベース等を構成する個人情報によって識別される特定の個人の数は、上記の「特定の個人の数」には算入しない。

@個人情報データベース等の全部又は一部が他人の作成によるものであること。
A氏名、住所・居所、電話番号のみが掲載された個人情報データベース等(例えば、電話帳やカーナビゲーション)であること、又は、不特定かつ多数の者に販売することを目的として発行され、かつ、不特定かつ多数の者により随時に購入することができる又はできた個人情報データベース等(例えば、自治体職員録、弁護士会名簿等)であること。
B事業者自らが、その個人情報データベース等を事業の用に供するに当たり、新たに個人情報を加えることで特定の個人を増やしたり、他の個人情報を付加したりして、個人情報データベース等そのものを編集・加工していないこと。
とある。 不正指令電磁的記録として問題がなかった場合、アプリがユーザーの意図通りアドレス帳データベースを作成することは、作者側にとってみれば、ユーザーから他人が作成したデータベースを受け取るだけになる。複数のデータベースを持っていても、加工・編集しなければガイドラインの3に当たらない。(NTTの電話帳と名刺一枚を持っているからと言って個人情報取扱い業務にあたらない)
つまり、個人情報保護法の対象外になる可能性がある。

アプリの説明文にある通り、誰でもユーザのアドレス帳からの検索をするためには、何らかの形でユーザーのアドレス帳を誰でもアクセス出来る状態=公開状態に置く必要がある。
したがって、「アプリ利用者が論理的に考えれば、何処かで公開されることに同意したとみなせ、不正指令電磁的記録に当たらない。」作者が法廷に立たされれば、そう反論するのが予想される。これも意図的にギリギリの説明を悪用して、ユーザーの誤解を引き起こそうという考えが透けて見える。


B説明は十分か

各社の報道、たとえばNHKには、
セキュリティ会社「ネットエージェント」の杉浦隆幸社長は、「電話帳を利用すると記載していたとしても、目的などを十分に説明しておらず問題だ。スマートフォンの情報を収集するアプリは少しずつ増えており、注意が必要だ」と話しています。
とあり、説明が不十分だったと問題視している。

カレログ、the Movieといった過去に問題となったアプリは、全く記載なく、あるいはユーザ以外の第三者が端末に導入することを推奨して、データ漏洩を引き起こすため問題視されていた。

しかし、全国電話帳アプリの説明は、論理的に考えるば、アップロードと公開アクセスが推論でき、第三者の端末に勝手に導入することを推奨していないので、この説明が不十分であるということは、もっと直接でわかりやすい記載を要求することになる。

ところが、既にFacebookやLINEのように、電話帳をアップロードするアプリは多数あり、個々アプリの機能説明において、アップロードについて説明がどの程度直接的かは怪しい

どの程度直接的な説明なら利用者の同意とみなせるかは、非常に難しい問題と考えられ、特定商取引法表示のような法で決まった表示規定が無い現状、事例ごとに裁判で個別に判断するしか無い。
全国電話帳アプリは黒に近いグレーゾーンで、"問題視"されるのは当然だが、違法だと断言してしまうと、他のアプリも黒であるという事になりかねない。

各社報道は、(捜査中なので当然だが)問題点・懸念として指摘し、違法と断言しているわけではない。
もちろん情報を収集される側のユーザとしては、黒であるほうが望ましい。


ついでに、
C住所でポンとの連携について。

@saronpasu氏が
https://twitter.com/saronpasu/status/254454228813242368
で、全国電話帳で収集した個人情報が、住所でぽんに利用されている、と指摘していた。
これは自分は確認できていない。

住所でポンは、作者の説明や乗っているデータから考えるに、NTTの電話帳を機械的に一般公開しているサイトで。それ自体は例外規定によって個人情報保護法の対象ではない。(=NTTが電話帳を公開できる理由)
しかし、複数のデータベースから名寄せしてデータ新たなデータベースを作って利用・公開する場合、例外規定ガイドラインの3に反するので、個人情報保護法対象となり、公開ができなくなる。

作者の過去ツイートをおうと、その点は考慮して公開しているようだ。


結論として、
・自衛として、アプリ説明や利用規約をしっかり読むこと
・わかりやすい定式化された説明の表示義務の法制化を急ぐこと
が非常に重要だ。
前者は多くの報道で指摘されているが、後者は指摘されている様子がない。

意地悪な言い方をすれば、ユーザデータを収集して利用する営利企業にとってみれば、表示義務が強くなると収集に支障をきたしたりコスト増を招くので、ユーザに自衛してもらうほうが好ましい。

現状、アプリに限らず迂遠な説明・利用規約でユーザ情報を収集しようとすることが多いと考えている。
わかりやすい説明の迅速な義務化を切に願う。

https://twitter.com/cause_less/status/254560614360424452





追記。
「情報に詳しい通りすがり」さんのコメントに対して、
http://causeless.seesaa.net/article/297244474.html
にエントリとして返答を書きました。

追記。
一週間経過し連絡らしきものが無いため削除しました。
http://megalodon.jp/2012-1021-0148-04/causeless.seesaa.net/article/296187376.html
posted by ko-zu at 15:06| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする

2012年10月06日

全国電話帳アプリは不正指令電磁的記録供用に当たるか

https://twitter.com/HiromitsuTakagi/status/254538144169476096
高木先生が違法と断言した全国電話帳アプリ
https://play.google.com/store/apps/details?id=info.jigensha.hellopage

不正指令電磁的記録供用についてと思われるので検討してみる。

アプリ説明には、『不正指令電磁的記録供用』を回避する事を意図したと思われる文言がある。
https://play.google.com/store/apps/details?id=info.jigensha.hellopage より

過去のハローページとタウンページに掲載された約3800万件の情報をもとにデータベースを作成しています。加えて、アプリ利用者のアドレス帳、GPSの情報も利用します。
zenkokudenwa.png


裁判になれば、アプリ作者の(@tottoriloopとは別?)は恐らく、こう主張するだろう。

アプリ利用者のアドレス帳を検索対象として用いるためには、アプリ利用者のアドレス帳をどこかにアップロードするなり、アプリがP2P型の公開サーバとして振る舞う必要がある。つまり、アプリがアドレス帳を外部に送信することは、論理的にみて当然の前提。
アプリをインストールした利用者は、アプリ説明と権限を確認してインストールしているため、同意を得た送信であり、不正指令電磁的記録に当たらない。

カレログの場合は本人の意思と無関係に第三者がインストールした場合(その第三者が)問題視された。
The Movieの場合、全く記載のない情報送信が問題視された。
しかし、このアプリは利用法が示されているため、問題ではない。

といった感じの主張が容易に想像される。
消費者保護の観点から、これは明らかにユーザーを惑わせるための婉曲な表現と言えるだろうが、長くユーザーにわかりづらい規約は一般に存在し、100%有罪と言うのは難しいのではないだろうか?

逆にこの件が明確に有罪となってくれるならば、ユーザー情報収集や利用を隠そうとする意図が見え見えの、婉曲・迂遠な利用規約を掲げる事業者の訴訟リスクは大幅に高まるので、(被害にあった人には悪いが、)追跡される側のユーザーとしては非常に喜ばしい。

posted by ko-zu at 21:31| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする