2013年02月20日

Nexus7 3G版 4.2.2/4.3のテザリング有効化手順メモ

Android4.2.2にアップデートしたNexus7でテザリングを再度有効化するためのメモ。root化前提。
4.3でも動いたため更新しておく。

主に http://blog.livedoor.jp/cn221283/archives/51078716.html を参考。

以下4.3用に更新

前提ツールのapktools と 7zaを android-sdk/platform-toolsに入れてパスを通しておく。
adb pull /system/framework-res.apk .
で取得してバックアップ

APK-Multi-Toolは
・framework-res.apkをothersに入れる
・Setup.batを起動して、3でフォルダ作成、2→1でframework-resからコンパイル用ファイルを抽出
・place-apk-here-for-moddingにframework-res.apkを入れる
・Script.batを起動して 24でプロジェクト選択、1でframework-resを選ぶ
・9でデコンパイルするとprojects/framework-res.apk/に展開されるので編集
・11 System appコンパイルを選択して、yをタイプすると、いったんprojects/framework-res.apk/buildというフォルダにコンパイル結果のコピーを展開
・署名されたresources.arscはコンフリクトするため削除
・何かキーを押す
・unsignedframework-resが生成される
という手順のようだ。

Nexus7 4.2.2のシステムイメージにもテザリング関連のバイナリは入っているようで、
http://forum.xda-developers.com/showthread.php?t=1995737 を参考に、framework-res.apkのうち、res/values/arrays.xmlの
    <string-array name="config_tether_usb_regexs">
        <item>rndis\\d</item>
    </string-array>
    <string-array name="config_tether_wifi_regexs">
        <item>wlan\\d</item>
    </string-array>
    <array name="config_tether_wimax_regexs" />
    <string-array name="config_tether_bluetooth_regexs">
        <item>bnep\\d</item>
    </string-array>
    <integer-array name="config_tether_upstream_types">
        <item>0</item>
        <item>1</item>
        <item>5</item>
        <item>7</item>
    </integer-array>
を修正するだけで動いた。

CWMのアップデートzipを作成してみようと思ったけれど何故か動かないためにAndroid起動中にadb shellから強引にframework-res.apkを上書き。特に問題なく動いている模様。
posted by ko-zu at 00:40| Comment(1) | TrackBack(0) | Android | このブログの読者になる | 更新情報をチェックする

2013年02月05日

第三者のDNSリゾルバを使う場合の問題について

自作のAndroidアプリに関連して、パブリックDNSリゾルバに関する誤解と思しき内容を見かけたので書いておく。


DNSリゾルバ(主にインターネット端末がドメイン名から接続先サーバのIPアドレスを調べるためのサーバ)の中には、誰でも自由に利用できるオープンリゾルバ・パブリックリゾルバと呼ばれる物がある。アドレスが8.8.8.8と覚えやすいGoogle Public DNSが著名だ。(日本では次点でNTT Americaか)
DNSで配信される情報は基本的に公開かつ普遍的(誰が調べても同じ)な内容なので、誰がリゾルバを提供してもプロトコルとしては問題ないのだが、第三者の提供するリゾルバを使うという事をプライバシー上問題視する意見が有る。

まず、(第三者の)DNSリゾルバを利用することにはプライバシー面で問題が発生する可能性がある、ということは事実だ。

DNSサーバーへのアクセスログを収集すればIPアドレス単位でユーザーがどのようなウェブサイトにアクセスしたか、どんなオンラインサービスを利用したかというアクティビティを推定することが出来る。
例えば、SNSの個人情報に紐ついたブラウザでアクセスした時、同一端末のIPアドレスから来たDNS問い合わせのドメインを収集し、個人情報と紐つけることは法的にはともかく技術的には容易だ。今後(プライバシー面で)杜撰なIPv6実装や運用が普及すれば個人追跡はさらに容易になるだろう。
グーグルを始めとする商業的に提供される無償のDNSリゾルバは、IPアドレスと紐付けられたユーザーの情報を欲しいがために高性能なDNSを提供して利用者を増やしている、と自分は考えている。
電気通信関連の法令の管理下となるISPの場合、ユーザーの情報を通信内容から収集することは制限されている。DNSリゾルバとのやり取りではISPが通信当事者になるので、DNSリゾルバのログは必ずしも通信の秘密として保護されるわけではないが、無関係な第三者よりはプライバシーを意識して取り扱われることが期待できる。もちろん、ISPにさえ通信内容を秘密にしたいのであれば、Torrなどの匿名化手法を使うしかないので、自身のウェブアクティビティをどこまで提供してよいか、という程度の問題といえる。


一方、DNSリゾルバから得られる内容の正確性については、どのDNSリゾルバを使おうと基本的に改竄されるリスクがあることに違いがない

まず、DNSにはDNSSECという情報の正当性を保証する機構があるものの、まだ一般には普及していないため、DNSSECで正しいと保証できない場合においても必ずしも内容が無効になるわけではない。ユーザーが明示的に検証を行うためのソフトを導入しない限りは、DNSで得られた内容が正しいかを検証することは出来ない。

現状のインターネットでは、DNSで得られた情報が正しいかどうかは一旦保留し、DNSで得たアドレスのサーバに通信を試みて、本当に目的のサーバーか確認することで安全を確保している。これはSSLやTLSとよばれる暗号通信と接続先認証プロトコルを用いて実装されていて、インターネットで一般的かつ根本的な解決法とされている。
これらの通信プロトコルで暗号通信し、かつ通信対象の証明書が権威の有る認証局から発行されたものか検証すると、通信対象が『接続したいドメイン名を名乗ることが認証局に許された正当なサーバーである』ことが保証できる。
(証明書を検証せずただ暗号化しただけでは、中間者攻撃=悪意ある伝言ゲームをすれば回避できてしまう。またいわゆるオレオレ証明書ではドメイン名を名乗る正当性は証明できない)

DNSから得られた情報が仮に誤っていたとしても、証明書を検証すれば接続が遮断されるので、情報が漏れたりすることはない。また、ドメインの所有者が管理しているDNSサーバーや、ドメインレストラのアカウントが侵入されるなどして、DNSプロトコルとしては正しいが、結果として悪意ある情報が混入された場合も、証明書を検証すれば接続できないという以上の問題はない。

また、DNSというプロトコルは正常に運用されている状態でも、歴史的な性善説的実装や性能面を理由に、様々な悪意ある情報の混入が起こりうる。(だからこそ常にHTTPSが必要)
攻撃対象のドメイン名に対応するIPアドレスを不正に上書きするDNSポイゾニング攻撃では、現状の(DNSSEC有効でない)DNSの原理上、成功確率を下げることはできても完全に排除することが難しい。また、近頃数多くのTLD管理下のDNSサーバの内容が不正に改ざんされるなど、DNS運用者側のセキュリティ上の問題も皆無とはいえない。
DNSにたよるシステムでは、もっと言えばインターネットというシステムでは、確実に接続できるという保証は存在しない

結局、DNSリゾルバが返す内容が正しいかどうか、安定性(接続できなくなることがない)や性能(どれぐらい高速か)という点では意味があるが、DNSの内容が正しくても、最終的な通信経路(例えばWiFi無線など)が安全でない場合、接続先サーバーのアドレスが正しくても何の意味もない
DNSで得られた情報に高い信頼性を求めることよりも、SSL/TLSによる暗号化通信でエンドツーエンドの安全性を検証することこそが重要ということだ。


次にフィルタリングによる意図的な編集が考えられる。

現在のDNSでは、リゾルバを提供する管理者が、DNSで配信される情報に意図的に手を加える事が許容されている。
例えば、明らかに犯罪に利用されている場合など、ドメイン運用上のルールに反したドメイン名を無効にする、といったことがDNSリゾルバの段階で行われている事がある。これを一歩すすめたものが、自分が提供している広告フィルタDNSだ。
こういった手法はDNSフィルタリングと呼ばれ、不正ドメイン対応だけでなく、不正なIPアドレスや実際には利用できないAAAAレコード(IPv6アドレス)など、セキュリティ改善や端末の接続性改善などの様々な目的でISPを含め多くのDNSリゾルバに適用されている。このフォルタリングポリシーやフィルタ内容の全容を公開しているISPは、そう多くないだろう。少なくとも自分は知らない。
フィルタリングによって内容が変化している可能性は常に存在し、リゾルバ管理者による不適切な改竄が気になるのであれば、自分自身で完全なリゾルバを用意するしかない。


どのDNSリゾルバを利用するかは、
・管理者に自分のネットでのアクティビティ情報を渡してよいか?
・DNSリゾルバのフィルタリングポリシーは適切か?
・DNSリゾルバの性能は十分か?
を勘案して決めるべきということになる。

拙作の広告フィルタDNSや、アンチウイルスベンダーの提供するセキュリティフィルタDNSなどを利用することは、個人的には考慮に値する選択肢であると思う。
(ユーザー行動監視なんてブラウザからSNSからポイントカードから収集されすぎていて慣れっこだ、という現代人には特に)

繰り返すが、どのDNSリゾルバを利用するにせよ、暗号通信と証明書による接続先の検証は非常に重要だ

ウェブブラウザではユーザーにHTTPSの利用を強制する仕組みが整いつつあるものの、まだ完全ではない。IMAP・POP・SMTP・FTPなど比較的マイナーなプロトコルは言わずもがな。
あなたにとって価値がある情報を取り扱うネットサービスにおいて、暗号化通信が提供されていなかったり、証明書が正しく設定されていなかった場合は、直ちに代替のサービスを探すことをおすすめする。
posted by ko-zu at 18:32| Comment(0) | TrackBack(0) | セキュリティ | このブログの読者になる | 更新情報をチェックする
×

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