「Androidのセキュリティを勉強する会〜端末開発にまつわる苦労話〜」ログ

まとめはもうあるので、こちら。
http://togetter.com/li/200612

ビッグサイト撤収
今から向かっても、だいぶ早いなぁ。どうすべ。
着いたが、さすがにまだ早いなぁ。
ぼつぼつ人がきはじめた。
横で原稿の話をしているぞ。きっとこゆい本に違いない。
すげぇ。電源完備、芋場は２本。いい会場だわ。
@eggman お、同じとこかな？
今日はUstはなしか。
「Androidのセキュリティを勉強する会〜端末開発にまつわる苦労話〜」シャープ株式会社重田大助さん。
会場の入りは95%くらいかな。若干の空席がある。これから来る人もいるのかな。
会ったことあるひと、ちらほらいるけど、お顔とお名前がちっとも一致しないわん(^^;。
あ、お茶買ってくるの忘れた。
時間通り開始。
端末視点での話をテーマにした。
はじめに。自己紹介と話す内容。twitterは公私混同してやっている。現在の業務内容。kernel、省電力、不具合調査、セキュリティ、ブートローダー、アップデートのソフト開発。
これまで。zaurus、海外向けフィーチャーフォンなど。
話題。端末の脆弱性。マルウエアは対象外。専門ではないので。
端末。通信事業者から販売されているスマフォ。ROM書き換えできるものは対象外。
目次。SHARP端末の実装方針。実際に発生した端末セキュリティ。LMS実装など。
SHARP端末の実装方針。オープンプラットフォームの進化を妨げてはいけない。後から機能を追加する事が大きな魅力。アプリやサービスを安心して提供できる環境が必要。
既にさまざまなお客様が利用している。安全に利用できる端末が必要。進化と保護のバランスが重要。
安心してサービスを提供するためには。端末の脆弱性が少ない。セキュリティパッチの継続適用。
サービスの利用者のなりすましができない。ハードウエアに基づいた認証情報FeliCa等の実装。
実行環境が設計通りに動作する。ROM書き換えの禁止。
ワークメモリに展開されている情報が守られている。RAMの読み書きの禁止。
「安心して利用してもらうためには」自己責任ではなく端末である程度守ってほしい。悪意のアプリが自由に動作しない端末。悪意のあるアプリが利用する脆弱性を少なくする。
root権限の取得。セキュリティパッチの継続適用。
ROMへのアプリのインストール。ROM書き換えの禁止。
電話機としての端末。個人を特定できる情報を管理している。端末識別。回線利用者識別。きっちり守る必要がある。
セキュリティモデルをお客様が認識していない。これまでの携帯電話と同じように認識。自由度が高いのに。
「セキュリティ対策方針」フレームワーク部への修正を行わない。互換性維持。動作に影響を与えない。
Linuxが持つ機能をいくつか無効化。すべての機能がなくても動作。デバッグ用途の機能を無効に。
端末としての動作には影響を与えず、お客様やアプリ。サービスを保護。
「ABC2010springのプレゼン」root権限を奪われた場合に備えて、kernelの機能を除外。互換性維持。ソース開示。Googleと相談して方向性。IS01からポリシーに変更なし。
「考え方」uidを使って権限の運用を前提にしている。異なるuid割り当て、独立プロセス。他のアプリと干渉しない。
rootとられれば想定外の動きをする。任意のプロセスの情報が取得できる。ファイルの読み書きできる。
rootを取られないようにする。脆弱性をつぶす。rootであっても読み書き制限。LSMを使う。
rootでもROM書き込みを制限。LSMで。
ハードウエアの支援を受けたサービスの実現。FeliCaの搭載。
「実際に発生した端末セキュリティにまつわる事例」
root権限取得。４つ。exploit、rageagainstthecage, psneuter, GingreBreake。パッチの取り込みや独自修正(2,3はパッチの前に自前で)。
どの端末でも使えるので、情報が出やすい。パッチの適用で対処可能。
独自修正。アップデート回数を減らしたい。アップデートで修正するのは脆弱性対策だけではない。他のソフトの修正の緊急度に応じてスケジュールが決定する。できる限りそのスケジュールにあわせて対応を行いたい。注意点。独自修正の場合は、その影響範囲についてGoogle社に相談した上で対応をしている。
「ROM書き換え、キー操作履歴の取得」insmod, tunerdrv, KeyHookManagerの３つ。シャープ固有の脆弱性を修正。insmodにはチップ固有の問題も。
シャープ独自のソフトウエアの脆弱性を利用している。環境の変化にメンバーの意識が追随できていない。オープンプラットフォームでのソフトウエア開発においてセキュリティへの意識づけが重要。
実際問題、完璧というのはないので、新しい取り組みをすすめることが必要。DroidDreamでは何がおこったか」情報取得し送信、root取得、/systemにアプリインストール。
データ送信は防ぐことはできない。root取得は当時の環境で対策済み。system書き換え保護によりインストール不可。被害をある程度おさえることができた。
isdmod脆弱性を利用したROM書き換え」背景IS01ではアップデートが見送られた。端末を解析するということをした人たちがいた。書き換えは想定していたので、そういう事実だけ。
IS01のROM書き換えは実現した。insmodは必要か？不要：kernelを自由に操ることが可能。必要：WiFiの省電力はinsmod/rmmodをベースに設計。起動途中まではinsmodを有効にするという折衷案でIS01を実装。
isnmodの禁止方法。2.6.31のmodule_disableを2.6.29にbackport。wifiでも操作できるように修正。init.rcの途中で許可を禁止する。
insmodを禁止するタイミングが遅かった。rildがシステムプロパティに記載のバイナリを実行する。root権限で端末起動時にコード実行が可能。デバイスメーカーのデバッグモード？対策：特定のモジュールのみinsmod可能にする。
シャープのLSM実装について」コード　
GPLで開示されている部分まで。上にはいろいろ乗っているのでまずい。
RAMの読み書き制限ptrace禁止dev/mem, kmemの削除。ROM書き込み制限。正しいROMのみ/systemに見せつ。任意のバイナリのmout禁止....
ptraceの禁止。プロセスをデバッグする機能。root権限があれば任意のプロセスの動作を解析可能。Androidでは不要。LSMで禁止する。
procの下もいくつか影響が出る。ソースの解説はしない。質問もらえれば解説できるかも。ソースもってきてない。
dev/mem,kmemの削除。メモリに直接アクセス可能。無効にするにはコンフィグレーションでオフにするだけ。kconfigにも注意が書いてある。
ROM制限。アプローチは２つ。書き換えを防ぐIS01。正しくないROMが書かれたらどうさしない。セキュアブート。
フラッシュ上のデータの書き換えを防ぐ。フラッシュメモリドライバが書き換えを防止。kernel書き換えも防止。起動時にRAM展開するkernelのコードを書き換えられて突破された。
この方式だけではうまくないとは思っている。
正しいROMのみsystemに見せる。mountの禁止。完全に禁止は不可能。initで/systemをmountするから。正しいROMイメージ以外はmountを禁止。対策にはLSM。ちょこちょこと手直しはしている。
chroot, pivotrootの禁止。Androidの動作には不要。LSMで無効に。
deckardやmiyabiの名前の由来。アーキテクチャを指す開発コードとして。別の名前がついていたので使わなかった。kernelのアーキテクチャを指す名前に転用。defconfigに使った。deckard,cをsevurityフォルダに作ってしまった。
deckard LSMと言われるようになった。担当者がすきなので、そういう名前になった。
社員の名前。雅さんがいる。社内でも知られていない。名付け親は話者。プロジェクトの初期段階でつけたコードネーム。ファイル鯖にも付けた。なにをさしているのかわからなくなった(^^;。
LSMの担当がdeckardがさわぎになっているので、ということでmiyabiにかわった。
LSMのために付けた名前ではない。
今後どうあるべきか」結論出ていないものがほとんど。
なぜroot権限が必要？与えられた端末では満足できない。フォント、シャッター音消す、スクリーンキャプチャ、WiFi アドホックしたい(できるかどうかわからないと担当)、CPUクロックの変更、デバイスドライバの自作、パケットキャプチャ、自力でVerupしたい。
端末の機能として入れて良いものは入れておけばよい。デバドラ自作はぼくたちの端末でやらないでほしい(^^;。開発用の端末を作ったこともある。
パケットキャプチャは、いろんなものが乗っているので、端末開発サイドとしては見ないでほしい(^^;。商用端末でroot取る必要性はないのじゃ？
いくつか取り組んでいる。フォントとスクリーンキャプチャはできるようにした。フォントはカスタムする仕組みをREADME含めて入れてある。
商用端末はroot取るのはやめてほしい」不安に思う開発者がアプリやサービスを搭載しなくなる。お客もコワいので使わなくなる。
自分で改造できる人以外が興味を持たないプラットフォームになってしまう。改造したいのであればroot取得可能な開発用ハードウエアを利用すべき。
(うーん、わたしはそうは思わないけどね。)
マニアだけのものになってしまうのがコワい。
商用Android端末としてどうあるべきか」互換性を維持しAndroidで利用しない機能を制限。脆弱性はパッチ適用。ROM書き換えは対策。
そもそも必要な機能は搭載しておく。美しいフォントなど。
必要なAPIはオープンソースへのコントリビュート前提で提供する。実際には拒否されたりしている。
「解決できない壁」暗号化zipのパスワードをどこに隠す？そのままダメ、難読化は解析される、都度入力は不便、ハードウエアアシストFeliCaやトラストゾーンは誰でも利用可能でない、サーバーはコストかかる。端末だけでは守りきれないものも多く存在する。
何をどう守りたいのか考えて、どう守るのか意識して作る。ご意見があればほしい。
「検討すべき課題」事前に堅牢化しておくだけでなく、発生した後も対応できるような取り組み。マルウエア対策、MDM(Mobile Device Management)。アプリ権限で動作するものでは限界があるため、事前に端末への組み込みと権限の提供が必要。
動作速度、消費電流、アプリの動作への影響をおさえ端末を守るための枠組みの検討が必要。
アプリ実行しようと思ったら「ウイルスの可能性があります」と言われても困る。配慮が必要。検討はまだ不十分。
まとめ。(略)
10分オーバーした。ありがとうございました。
質疑の前に休憩20時まで。懇親会に出る方挙手。これから予約する。
質疑。
セキュリティを配慮するにあたって、どういう機能やデータを守ろうとしたか？守るものがなければ何もしなくてもいい。電話機として守るべきもの。いろんな方と相談してコレくらいのレベルというラインはある。個別については言えないので、なんとなくイメージして。
Googleの反応は？興味のないものは興味ないという感じ。落ち着くまでにいろいろ提案。完全に拒否されたこともある。こだわりはハッキリしている。
なんかポストに失敗するなぁ… twiter。。。
投稿可能数を越えたと言われちゃったよ。

というわけで、以下は未ポスト。

セキュリティを配慮するにあたって、どういう機能やデータを守ろうとしたか？守るものがなければ何もしなくてもいい。電話機として守るべきもの。いろんな方と相談してコレくらいのレベルというラインはある。個別については言えないので、なんとなくイメージして。
コンサルビジネスは？中の人なので、そういうことはできるかわからない。共有はしていく。
MDMやDWARD iOSなら想定されている機能があるが、Androidは弱い。今後Googleはどう？端末ベンダが独自でうやるもの？ Googleは知らない。SHARPのは言えません(^^;。言っちゃうと、あーってなる。
うわさで、修正パッチを出す際に、キャリアの検査項目が多くて大変と聞くが？おいついてないとか？痛い質問。たくさん端末出しているので手間はかかっている。リリース日程にどう影響しているかは、キャリアはわからないが、社内ではソフトウエアアップデートのタイミングは他とあわせて。日程に直結してはいない。いろんな判断が働く。判断がなにかは説明できない。
キャリアから絶対これをという指示は？キャリアによって、いろんな色がある。
端末縛りが２年だが、サポートの体力はどのようにしていく？いつまでというのは話せない。販売の仕方で２年というのはある。ユーザーがいればサポートするのは大事。いつまでというのはいろんな話がからんでくるので、判断はいろいろ。18ヶ月という話はどうなったのか。蚊帳の外。よくわからない。現時点ではちゃんと答えは出ていない。やらないといったら、書き換えようかという話も出てくるか。ちゃんと考えていかないといけない。
ごろーくんです。日経のほうでAFAが記事に。セキュリティの対策しようと思うと衝突しない？言えません。絶対言える内容ではない。Googleはディベロッパーを重視している。影響ができるのはダメ。Googleと相談しながらやってきたのは、そういう背景。
セキュリティをビジネスで回していると限界がある。トラステッドなエリアで何かしら普通のユーザーを守ることはできないか。意見があれば。
最後の内容と通じるが、そういう仕組は必要だと思う。検討はまだ不十分。提案があったら真剣に検討する。何か具体的にあるか？ BREWの機構が使えないか。署名と勝手アプリの２つ。署名があればトラステッドなAPIを使える。そうでないものは使わせない。
(それはないな)
rootは普通の人が取るのは反対派。
プラットフォーム証明書で縛っている。権限の分割は賛成。どのように切るのかは決まっていないので、これから。
BREWはGPSなどAPIごとに専用の証明書が必要。マーケットの人の審査があって払い出し。
Marketの話はメーカーは口出しできない。証明書の分割は、それを使ってアプリを書かれる人と決める必要がある。汎用な枠組みとしての提案だったが、その範囲で実際にどうしていくのかさぐっていく必要がある。
一般ユーザーでROM書き換えて文鎮化して、ショップに持ち込む人がいる。root取ったのものを中古に出す人も。誰も普通かどうかを担保できない。他社は工場出荷時に書き戻しモードがある。SHARPはアップデートもきかないし、復旧もできない。ユーザー保護の観点からも、初期化方法を。
問題だと認識している。社内では十分に検討していない。持ち帰って検討する。
OECさん。最近だと思うが、VMwareなどがモバイルで仮想化する仕組みを出している。SamsungやLGは乗っかった。そういう方向性への感想など。
仮想化は有効な方法だと思う。ポイントはOSの箱の中で動くものとそれ以外を仕切ることができる。もともとハードで用意されていればいいが。取り組んでいくべきだと思っている。
SHARPを使っているが、赤外線が便利。標準で入っていない機能はコントリビュートするということだが、Googleの反応は？
セキュリティ関係ないですね(^^;。セキュリティ的にダメとかいうのもあるでしょ？これからの話しは言えない。詳しくしらない。赤外はレガシーなデバイスはいらないとダメを食らった。
アプリを作る立場で、root取られても見られたくない場所がほしい。CPRMやTrustZoneで作ったセキュアストレージがあったりする。相談したら使えるようになるのか？
まずは相談してもらいたい。話が進まない。どう作るのかへの落し込みにはいろいろあるが、メリットがあれば実装するのはやぶさかではない。使いたいという声があれば。
質疑終わり。
ようてんさん。LT。脊髄反射で申し込んだ。

こっから復帰。

ようてんさん、トーン高い！
わたしは不同意。RT @tetsu_koba: 同意。RT @kinneko: #securedroid 自分で改造できる人以外が興味を持たないプラットフォームになってしまう。改造したいのであればroot取得可能な開発用ハードウエアを利用すべき。
撤収〜。今日はくたびれたので、懇親会やめときます。

次回予定は？と聞いてみた。危険な回答が帰ってきた(^^;。