2012年11月30日

スマートフォン向け広告除去を試す方法

広告を除去するとどれくらい快適になるのか、試す方法。WiFi接続限定の一時的なものなので注意。
root化/jailbreakなどの保証対象外になりうるファームウェア改変をしたくは無いが、アプリ内広告の除去を試してみたい人向け。ウェブ上の広告はFirefox for AndroidなどのブラウザのAdblockアドオンを使うことをおすすめする。

(追記)以下の設定を自動化するアプリを公開しました
http://causeless.seesaa.net/article/306520220.html

wifiネットワークの確認
自宅などで無線ルーターにまず接続して、使っているネットワークとIPアドレスを確認する。
Androidなら設定→無線とネットワーク→Wi-Fi設定→(メニューボタンで表示される)詳細設定
iPhoneなら設定→Wi-Fi→SSID(アクセスポイント名)横の?マークをタップ

端末のプライベートIPアドレスが192.168.1.2や192.168.11.2などと表示されているはずなので、ピリオド区切りの最初の3つをメモ
例えば、192.168.1.2なら192.168.1までが使っているプライベートなネットワークにあたる


固定IPアドレスの設定
参考
Android http://www.akakagemaru.info/port/androidstaticipaddress.html
iPhone http://www.akakagemaru.info/port/iphone-staticip.html

IPアドレスに、192.168.1.(他の端末と被らない200〜250あたりの
数字)、たとえば192.168.1.200
ゲートウェイに、192.168.1.1 (ルーター/NATのローカル側アドレス)
サブネットマスクに、255.255.255.0
DNS1に、 (IPアドレスを変更しました。27.120.90.195)
DNS2に、 8.8.8.8
を設定する。

なお、Androidなら Wifi Staticがオススメ。自宅のアクセスポイントでのみ、固定IPアドレスを利用できる。
固定IP用の設定を入力して、
screenshot_2012-11-30_2004.png
SSIDにアクセスポイント名を入力する
screenshot_2012-11-30_2006.png
タグ:広告除去
posted by ko-zu at 20:25| Comment(0) | TrackBack(0) | 広告・ユーザ追跡 | このブログの読者になる | 更新情報をチェックする

2012年11月14日

オープンDNSリゾルバのDoS対策メモ

「Android/iPhoneスマホのroot不要な広告除去法」http://causeless.seesaa.net/article/289244107.html
で書いたように自宅サーバで、広告避けオープンDNSリゾルバを運用しているが、DoS攻撃と思われるクエリがよく来ている。

ほとんどがripe.netやisc.orgへのANYクエリで、特定のソースIPから短時間に多量の連続したアクセスがある。偽装されたソースIPへのトラフィック集中を目的としているらしく、DNS Ampによる回線飽和DDoS攻撃が実行中と思われる。

自分の回線やサーバーへの負荷は大したことは無いが、DoSの片棒を担がされているのは気に入らないのでフィルタ方法を考えてみた。


REFUSEする
自分のリゾルバは広告除去目的の限定的なオープンリゾルバなので、今回利用されたドメインへのクエリを一時的に禁止してみる。
zone "ripe.net" IN {
type master;
file "block.db;
allow-query {none;};
};
DNSリゾルバにセカンダリを正しく設定してあればそっちに問い合わせするので問題ない。高々最初のアクセスのレスポンスが1秒ほど遅くなるだけ。


REFUSEDをドロップする
BIND9にはunboundのdenyに相当する設定が無いので、refusedを返さず無視することが出来ない。仕方ないのでiptablesルールで何とかする。
コードが5=REFUSEDなレスポンスをDROPするルールを追記して対応
-A OUTPUT -p udp -m udp --sport 53 -m u32 --u32 "0>>22&0x3C@8&0x0F=5" -j DROP


hashlimitをかける
上の2つで弾けているはずが、なかなかDoSのクエリがとまらなかったので、テストを兼ねてhashlimitルールでINPUT側をフィルタしてみた

-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT
だったものを
-N DNSCHECKIN
-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j DNSCHECKIN
-A INPUT -p tcp -m tcp --dport 53 -m state --state NEW -j DNSCHECKIN
-A DNSCHECKIN -m hashlimit --hashlimit-upto 1/s --hashlimit-burst 50 --hashlimit-mode srcip --hashlimit-name DNSDENY --hashlimit-htable-expire 300000 -j ACCEPT
-A DNSCHECKIN -j DROP
に置き換え。これでほとんどDROPできた。
最初に50クエリまで許可して、以後1クエリ/sに制限。リゾルバのキャッシュが正しく効いてる普通のユーザーなら問題は無いはず。NATで複数人が回線共有していた場合残念なことになるが、そもそんな状況の人はオープンリゾルバ使わないだろうから「NATの中の人などいない」と割り切る。
(3G回線の人ならroot化済みでhostsでブロックしてるだろうし)


ということで対策してみた広告除去用オープンリゾルバ。101.111.213.2
セカンダリにはGoogle提供の8.8.8.8あたりをどうぞ。
公開停止しました。

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

2012年11月12日

Android版 Sleipnir/Operaで動くuserscriptメモ

ブラウザ側でjavascriptコードを追加する、userscriptに対応してるAndroid対応ブラウザをチェックしてみた。
2012/11時点での対応アプリから SleipnirとOpera Mobile。

Sleipnir Mobile
https://play.google.com/store/apps/details?id=jp.co.fenrir.android.sleipnir

http://extensions.fenrir-inc.com/dev.html
ほぼgreasemonkey互換。HTTPS上でも動作する。
.slex.jsを拡張子にすることで任意ドメインからの自動インストールが可能。ユーザーは悪意あるスクリプトを間違ってインストールしないよう注意が必要。

scriptロードタイミングはwindow.onloadの後なので、再描写が必ず生じてしまう。
例えばDOMの除去は透明化などボックス配置の再描写が起こらないよう注意しないと、ユーザーの操作を妨げる

自作サンプル
Google検索のリダイレクタ除去と広告の半透明化。 Google Search Mod http://slex.usb0.net/gsm.slex.js
標準のYahoo検索からGoogle検索に自動リダイレクトする。 Yahoo to Google http://slex.usb0.net/y2g.slex.js



Opera Mobile
https://play.google.com/store/apps/details?id=com.opera.browser

ほぼGreaseMonkey互換(拡張子 .user.js)と、全ページへの挿入するグローバルscriptの両対応。
opera:configからuserscriptフォルダを手動設定し、そこに手動でダウンロードすることが必要。
HTTPS上では動作しないよう設定できる。

onloadの直前に動作するとのことで、再描写は起こらないように見える。
自作の http://userscripts.org/scripts/show/149312
も動作する模様


Android版FirefoxもGreasemonkey対応できるようにしてくれ……


posted by ko-zu at 19:16| Comment(0) | TrackBack(0) | Android | このブログの読者になる | 更新情報をチェックする

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年11月02日

高木先生に解釈の相違を頭がおかしいのではと非難された件について

不正指令電磁的記録、いわゆる「ウイルス」に関して、高木先生とやり取りして感じたことをまとめてみる。

高木先生は全国電話帳の件について、どこにも端末の電話帳が利用されることは記載されておらず、違法であると考えているようだが、
http://secroid.jp/d/e/a/c/info.jigensha.hellopage.html
https://twitter.com/cause_less/status/263678476920442880
について以前のエントリやツイートで書いたように、自分は全国電話帳のアプリ説明は誤認を誘導するために複数の読み方が出来るように書かれていると考えている。

日本語には単数と複数の区別がなく指示語の曖昧さがあるので、「アプリ利用者」という単語だけでは、利用者個人をさすのか、全ての利用者全体を指すのか区別できない。Google Playのアプリ説明はアプリの一般的な解説を意図しているので、アプリ利用者は当該アプリを利用している全ての人間を指す可能性があり、個人を指すと断定することが出来ない。
アプリ利用者「本人の」、と補って解釈すれば他人のアドレス帳から検索できた時点で明らかに違法であり、「全員の」といれれば逆に合法の可能性がある。

高木先生は他の読み方はあり得ず、自分のような解釈をするのは頭がおかしい、と言われるが、不明確な用語の利用は高木先生も各種サービスの利用規約の問題点として指摘されている通り、一見問題無さそうな文章でも、解釈によっては悪用されうるということは、(すくなくともサービス開発や運用に携わる人には)一般的な認識になっていると思う。あるいは、そう願う。
他の解釈はあり得ない、という考え方は、一方的な断定であると思う。

全国電話帳アプリに利用者を騙す意図が有ったことは本人の言から明らかで、ソフトウェアの社会的信頼を毀損する意図が有ったことは明白だが、悪意と違法性はイコールではない。違法でなければ何をやってもいいという考え方は倫理的に好ましくないが、反社会的な悪意を直ちに違法と見なすことはより好ましくないと自分は考えている。

不正電磁記録はアプリ利用者の意図と反する挙動をするソフトウェアであって、「アプリが本来どのような動作をするべきか」を判断する際に立場によって解釈の相違が生じうる。
極端に解釈すれば、ソフトウェア解説が他言語で書かれていて、利用者が読めないにもかかわらず実行可能な場合はすべて不正電磁記録と見なすことさえ出来る。
アプリ利用者がどの程度の前提知識を持ち、どの程度アプリの解説を読み、どの程度の操作(同意ボタンなど)をもって同意と認めるのか。逆に言えば、どのような解説や規約・同意判定を実装すれば不正電磁記録に当たらないのかは、判例なり明確な判断基準が示され、実際に法廷で争われるまで分からない。
個人的に、この不正電磁記録の考え方は「法律の穴」と言っていいレベルの瑕疵だと思っている。

識者と目される方が、違法かどうかを判断する上で一方的な解釈のみを採用し、「解釈の相違」という法律の穴から目をそむけるような態度をとるのは、問題が有ると考えている。
現状、識者が悪意をもって「このアプリの挙動は私の解釈に反する」と告発すれば、大抵のソフトウェアは違法にできてしまえるのではないだろうか。

匿名の自分に、法解釈について議論できるほどの知識も資格もない、と言われることは大いに予想できることだが、逆説的に、一部の有識者による一方的な解釈によって個人の行為が違法にされうる、という不安をソフトウェア開発者の一人が感じていることを理解いただければと願う。
posted by ko-zu at 23:16| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。