CookieHookey

スマホとプライバシー2(対処の検討)

Tech

以前､スマホとプライバシーについて触れた｡ ここでは､モバイルデバイス上で､プライバシーを重視するにはどうするか､デバイスを長く使うにはどうするか､という2つの方向で考えていく｡

ただ､この方法で対応しましょうとは中々言えない｡症状に対して､｢はい､このお薬飲みましょう｣となっても､それが別の症状を生み出すようなことも考えられる｡全体的な整合性のためには､セキュリティ等の専門的な知見が必要となり､いちユーザーの手には余る｡この先は､考え方のひとつとして捉えていただきたい｡

Introduction

セキュリティやプライバシーというものが信頼で成り立つものならば､今日のスマホはそれに値しない｡なぜならば､ファームウェアからアプリまで透明性がないからだ｡クローズドソースでありバイナリBLOBを含む｡オープンソースでない限り､プライバシーがどう尊重されているか確かめようがない｡その時点で､スマホに対する信頼は限定的になる｡しかし､スマホというデバイスを筆頭に､既に普及し､利用する習慣を以て疑いの念は消え去っているように思える｡

デバイスを含めたフリーウェア化というのは､プライバシーを重視するためにも､長く使用するためにも大前提であるが､それが達成できてない｡本来は､プライバシーにまつわる議論をする前段階にフリーウェア化が来るべきで､その後初めてプライバシーを重視するには?という議論がされなければ意味がない｡この事から､今日のテクノロジーはプライバシーについて語る段階にはなく､これから考える対応策は結局の所､迂回策や妥協策に過ぎない｡

テーマ･方針

基本的な方針を定めておく｡

  • FLOSS
  • Isolation: 例)センサー･コンポーネントの外部化､モデムの隔離
  • Opt-in: 例)必要最小限のセンサー･コンポーネント･サービス､デフォルトOFFで必要な時だけON
  • Decentralization
  • Offline: わざわざクラウドを使わないとか
  • Fewer accounts: データの蓄積場所を指定していることになるので
  • Less technology: 機密にしたい情報は保存しないとか
  • OPSEC: 道具に依存するより使い方を工夫する｡
  • Mass surveillanceにフォーカス(<=>Targeted surveillance)

ハードウェア･OSの選定

ハードウェアの選定にあたって

プライバシー上の対策をするとともに､長く使うことを考えるにあたって障壁がある｡別記事で触れているが､ハードウェアがクローズドソースであることが障壁になる｡何故なら､最新の状態でもDMAを悪用される可能性があることに加え､セキュリティ更新を2･3年でやめるというベンダーの気まぐれを受け入れるしかないからだ｡以下､DMAについて｡

DMAは､ハードウェアのコンポーネントや周辺機器が､OSとは別に直接メモリにアクセスできるようにした仕組みであり､DMAでない場合CPUがメモリのアクセスまで管理するため､動作が遅くなるか､機能しない｡そのためDMA自体は､有効な仕組みと言えるが､特にクローズドなファームウェアにアクセスされた場合､encryption keyを取られるなどの危険性がある｡

それゆえに､カスタムROM等でシステムレベルをフリーにしても､ローレベルがクローズドのままであればプライバシー上の懸念は残る｡同様に､ベンダーが更新をやめた後にシステムレベルのセキュリティパッチを当てたところで限定的なため､セキュリティの観点から､やはり長く使えない｡

一番リスクがあるのは遠隔でいつでもどこでもアクセスし得るという点､規制の影響を受ける点でbasebandだと考えられる｡DMAの対応策はいくつか挙げられるが､一番効果的な手段は､スマホを一切使用しないことだ｡それ以外では大きく分けて2つの解決方針がある｡

理想的:フリーソフトウェア化を目指す

DMAの解決策の1つは理想的な方法で､オープンソースのハードウェア(コンポーネント､ファームウェア)で構成することだ｡オープンソースは万能作ではないが､少なくともコードの確認ができる｡セキュリティ更新に関しては､メーカーのペースではなくコミュニティのペースでアップデートが可能なため､長く使用することができる｡3つの行程があり得る｡

1つ目は､オープンソースにするように法律改正する方法｡ただ､FCCやCE(日本で言う技適マーク)など無線に関しては当局がレギュレーションしており､認証を受けるためには結果的にBLOBを含む必要があるようだ｡オープンソース化は､起こりそうにない｡

2つ目は､オープンソースにするようメーカーに対応させる方法｡ハードウェア業界は､少数の巨大半導体メーカー(Mediatek, Qualcommなど)が牛耳っているため､競争がなく､パテントで守られている｡積極的にフリーウェアを導入する理由がないため､業界側からの変革は期待できそうにない｡

3つ目は､バイナリを分析し､パッチを当てる方法｡すべて透明性をもてるまで､何年かかろうともハッキングし､オープンソースのファームウェアを作る｡しかし､オープンソースのコミュニティーは､スキルは集まるが､マンパワーが足りない事が多く､時間がかかる｡フリーウェア化の道としては一番あり得そうだが､多大な労力を必要とする｡仮にバイナリを理解し､代替するファームウェアを用意できたとしても､最近のスマホは署名が付いたファームウェアしか受け付けないので､入れ替えることができない(🔗)､(🔗)｡

現実案･妥協案:Isolation

DMA解決策の2つ目は､Isolationであり､現実的な妥協策と言える｡クローズドソースを隔離しCPUやメモリと言ったchipにアクセスできないようにすることだ｡ところがIsolationを確約するデバイスは少ない｡例えば､SMMU(IOMMU)を手段として挙げられるが､デフォルトでDMA対策をするわけではなく､システム側でどう管理するかが重要なる｡また､Boot時が弱点にもなるため､IOMMUがModemよりも前に起動する必要があるが､そのためにはBootloaderも同時にフリーであることが必須だ｡つまり､フリーのBootloaderとIOMMUが前提となる｡加えて､IOMMUのドキュメントがあること､コードのペアレビュー､ModemがIOMMUを書き換えないという確約ができれば良い｡ただIOMMUにはIOMMUなりの脆弱性もあるようだ(🔗)｡ 別のIsolationの手段としては､RAMではなくUSBを通じてmodemと通信する方法がある(🔗)､(🔗)｡

IOMMUで､メモリに関しては守ることができたとしても､メモリ以外の部分に関しての動作を制御できるのかはわからない｡例えば､他のコンポーネント(GPS､マイク､カメラ等)ヘのアクセス､勝手な通信など｡フリーであるに越したことはないので､妥協策となるが､現実的対応策である｡

OS･デバイスの選定

アプリ､OS､デバイスあたりは密接に紐付けされており､ゼロから選ぶ場合､デバイスを選択する前に､どのOSを使用するか検討することになる｡例えば､Androidアプリを使いたいならば､基本的にAndroid系のOSを選ぶ必要がある｡しかし､AndroidはOpen-sourceというより､Shared-sourceであり設計等においてGoogleの影響を大きく受けるし､Androidにしかない企業のアプリは､ほぼクローズドソースである｡カスタムROMであっても､それらは変わらないため､LinuxOS(Linux-based,Linux Phone)を選択する｡LinuxOSの場合､AnboxとかWaydroidで､Androidアプリを利用できる可能性はあるが､不明｡Mobian､PostmarketOS､Maemo LesteなどがLinuxOSとして挙げられる｡

OSが決まれば､対応デバイスは限られるので､デバイスも決まる｡選択したOSの対応デバイスを調べるのだが､LinuxOSの場合､大体Librem5とかPinephoneあたりが中心点になると思う｡両デバイスともに､キルスイッチが付いているが､Librem5にはセンサーの物理的なキルスイッチがある一方で､Pinephoneにはない｡ただ､キルスイッチがあっても､クローズドである限り､スイッチON時の動作は不明である｡特にモデムはBLOBを含むが､適宜､自分でファームウェアを入れ替えてもいい｡

アプリにこだわるなら

Androidのアプリを使いたい場合､Androidである必要がある｡｢いつでもどこでも｣でなければ､PCでVMでもいい｡この場合､自宅等でVMでAndroidアプリを使用し､モバイルデバイスではLinuxOSを選ぶという方法を取れる｡より軽量のAnboxやWaydroidといった方法もあるが､モバイルとアーキテクチャが違うため､アプリが対応していない可能性がある｡

Androidアプリを持ち歩きたいならば､フリーウェア化の側面ではReplicantが選択肢に入るが､対応デバイスが古いのか､中古市場でも見つけられない｡フリーウェア化とは行かないが､firmwareを含めたセキュリティに注力しているGrapheneOSが良さそうだ｡

GrapheneOSでは､カーネルにあるオープンなドライバーが許可した場合にだけ､ホストのメモリにアクセスできる｡IOMMUにより､メモリはIsolationはできているようだ(🔗)､(🔗)｡ 対応デバイスをGoogle Pixelにしているので､他デバイスより融通が利くメリットはあるが､端末が6万円くらい?と高いし､3年くらいで買い換えるために費用がかさむ｡

ユーザーはLinuxOSを選べない

ユーザーは､アプリを重視してOSを選択することになる｡ゲームのコンソールと同じ様な感じで､このソフトはこのコンソールでのみ使えますとか､新しいソフトは上位機種でなきゃ発売しませんよ､というだけでみんな買い換えることになる｡アプリ(ソフト)をコントロールすると､ハードウェア(コンソール)もコントロールできるということだ｡

大衆を狙うのであれば､おそらく決済系､銀行系のアプリやGAFAMなど人気なアプリを充実させる必要があるが､企業はクローズド好むので､わざわざLinuxOSでアプリを公開しない｡結果Androidを多くのユーザーは使うことになり､Linux OSには移動できない｡Windows Phoneの時と同じように､利用者を増やすことは難しいだろう｡ユーザーは､企業のアプリに依存しているため､寡占されたデバイスから離れられない｡アプリをコントロールされることで､多くのユーザーはオープンソースのデバイス､OSを選べないようになっている｡

利用方針

デバイス選定後の話｡

LinuxOSの場合

  • 通信はすべてIP上で､SSLで暗号化し､Tor等を通じて行う｡
  • 適宜センサー･コンポーネントを外部化する
  • PSTNの電話網は､ブリッジのあるSIPプロバイダーを利用する｡

など趣味嗜好に合わせて､工夫する｡

Android OSの場合

Androidのプライバシー対策を参照｡

製造･流通経路

  • 中央集中したパーティーを避ける｡
  • ハードウェア関連は実店舗で購入する｡オンラインなら､決済とPIIと送付先を切り離す｡

MISPがデータを売る

メタ情報(位置情報､タイムスタンプ､加入者情報)と通信･音声データは必要になる｡対処としては､プリペイドSIMを利用し､すべてIP上でtorで通信する｡プリペイドでなくても､加入者情報を紐付けないようなSIM(libremのawesim?)があるらしい｡

国境での検査

主にアメリカで､手荷物検査以外にも､laptopとかスマホの中身の調査･コピーをすることができる｡はっきりとした見解はわからないが､パスワードを設定していても解錠も求められ､拒否した場合は拘束とともに､さらなる調査に繋がりうるようだ(🔗)｡ FDE等の暗号化はセキュリティとしては重要ではあるが､解錠を半ば強制されるのであれば､やはり､テクノロジー的解決(E2EE=OK)では足りない｡

一般に､国内の警察よりも､国境警備員の権限は強く､入国者のプライバシーは弱くなる｡主にローカルの写真やメッセージなどを対象としているようだが､(SNSアプリが入っていた場合?)SNSのアカウントの認証情報を求めることを検討しているようだ｡

スマホやlaptopを渡す際には､ハードウェアにスパイツールを入れられる可能性もある?(🔗)｡

対処例

  • 持っていくデバイスを絞る
  • 個人情報を含まない旅行専用のデバイスだけ持っていく
    ただ､対策しすぎてると思われることもまた疑われる原因になりうる?
  • 一時的に､データをローカルからクラウドに移動させておき(client side encryption)､入国後落ち着いてから､ローカルに戻す｡
    • 自宅サーバーなど自分の管理が及ぶクラウドのほうがベター｡
  • ファームウェアの書き換えにはverified bootは対抗策になり得る｡

より詳しい状況については､digital-privacy-us-border-2017を参照｡

その他

  • デバイスは､ホテル等に置かず､持ち歩く
  • 自分のUSB以外は差さない･利用しない(充電器とか)｡
    • 自分のUSBアダプターを媒介させる｡
    • USBデータブロッカーで､電気だけ通るようにする｡
    • ワイヤレス充電はOK
  • 入国後でもデバイス自体にアクセスされる懸念があるならば､クラウドに一時移動させたりする｡

ユーザーのマインドを変える必要性

プライバシーを重視したいならば､テクノロジー的解決策のみでは足りない｡デジタルリテラシーを高めること､利便性を放棄することが大切だ｡

テクノロジー的解決策よりもOPSEC

デバイス､OS､アプリ等にこだわったとしても､使い方を誤れば､その拘りは水泡に帰す｡デバイスがどうとかよりも､OPSEC(使い方とか)の方が重要度は高い｡テクノロジー的なソリューション(単語)に振り回されないことだ｡｢~ならOKだ｣という安易な発想は避けることだ｡

Good opsec will save you from bad crypto, but good crypto won’t save you from bad opsec.

E2EE=OKではない

E2EEのIMは別に万能ではないが､E2EEというキーワードに振り回された結果､勝手に安心を感じることもあり得るだろう｡(暗号化の方法とか技術的なところは触れない｡)

  • 本当に意図した送信相手なのか｡(E2EEは､安心安全な経路が確保されただけだ｡)
  • メッセージをアプリ外に持ち出していないか(他人と共有､暗号化解除要請､スクリーンショット､外部メモ)

テクノロジー的解決を図ったところで､人には思い込み等の隙が生じる｡

オープンソース=OKではない

pinephoneユーザーを対象としたdiscordサーバー上で､snake gameを装ったマルウェアが配布された(🔗)｡ 当初はバイナリ版のみアップされていたが､後にソースコードは公開された｡

バイナリ版の横にソースコードがあったからといって､そのソースコードからビルドされたことを意味するわけではないということだ｡このケースの場合､バイナリの中身にはモデムのファームウェアを削除したり､ファイル･ディレクトリを削除するコードが含まれていた｡

利便性の裏表

テクノロジー推進のキーワードは｢便利･簡単｣である｡テクノロジーは少しでも勉強する意識がないと､なかなか取っ付きにくい｡Wifiのセットアップ1つとっても､初めてでは苦労するし､面倒だ｡そんなときに､｢安心･簡単｣とあったら､飛びつくだろう｡そこで､WPSの登場だ｡ セキュリティ業界では､｢簡単｣と書いて｢トラブルの基｣と読むらしい｡ユーザーにとって簡単ならば､サードパーティーにとっても大抵簡単である｡テクノロジー導入のキーワードは利便性であっても､何らかの形でユーザーは意図的に利便性を放棄する必要がある｡そうでなければ､変わりに別のもの(セキュリティとか)を失うことになる｡

リテラシーがないのは危険サイン

社会とは､1人ですべての要素･作業をカバーすることはできない以上､delegation(委任､人に任せること)で成り立っている｡delegationで重要なことは信頼であるが､仮に信頼に値しなくてもdelegationした瞬間､信頼していることになる｡さて､政府は信頼できるか､企業は信頼できるか､サービスは信頼できるか｡そうしたことを検討するよりも前に､delegationがシステム化され､受け入れるしかない状況があっても､信頼したことになる｡

ICTに馴染みがなかったり､人に任せざるを得ないくらい複雑であるということは十分理解できるが､テクノロジーにおいても同様にdelegationをした場合､セキュリティとプライバシーに対するコントロールを受け渡していることと同値である｡どのデバイスを使うか､どのアプリを使うかといった選択をするとき､delegationした場合は従うことになる｡大抵の場合､企業はクローズドソースという形でデバイスやアプリをブラックボックス化することで､明確に管理する側と管理される側を分けているが､それでもユーザーは納得している(ことになっている)｡ブラックボックスがある段階でプライバシーについては語れない｡

デジタルプライバシーを重視するためには､ユーザー自身が､プライバシーに対するコントロール(パワー)を取り戻す必要がある｡その源にあるものが､デジタルリテラシー(テクノロジーに関する知識)である｡自分が求めるものはどれかを主体的に判断する必要がある｡

現状､テクノロジー化が進む割には､ユーザーのリテラシーは高くなっていない｡原因は､ユーザーがお客様でいることを望み･それに慣れたため学ぼうとしなくなったからだと思う｡つまり､ユーザーが求めるものは知識ではなく､テクノロジー的解決策(利便性)であり､一言で言えば｢そっちで何かやって｣みたいことだ｡お客様に慣れすぎたユーザーは知識を求めなくなり､それに反応して企業はユーザーをお客様として扱うようになった｡前提の知識が不足したユーザーは､いざ調べようとしてもテクノロジーの用語が理解ができずに､調べなくなる｡delegationを望むユーザーに対して､企業はますますお客様として扱うようになる､というようなプライバシー上の悪循環が起こっている｡

キャリアのショップ等で質問をしようにも､それも結局はビジネスの一環だ｡ビジネスにつながらない好奇心はまともに相手にされない｡変化が早く､新しいサービスがどんどん登場する業界では､良くて基本的な使い方を知るにとどまり､デジタルプライバシーについて考える余裕は生まれない｡誰しもが私的空間にテクノロジーを持ち込む以上､外国語よりも必須科目となり得るのだが､体系的に学べる場所は見当たらない｡

自分自身で知識を身に着けていかないと､否が応でもdelegationすることになり､それはプライバシーのコントロールに関してもdelegationすることになる｡大抵は､広告やマーケティングといった声の大きいビジネスに巻き込まれ､寡占に貢献する｡結果GAFAMなどのモンスター(中央化した巨大企業という意味で)が登場した｡寡占する企業が､世界を監視するだけのリソースを持っている｡それを我々は､知ってか知らずか許したことになる｡

de-centralization

利便性の過度な追求と､過度なdelegation(デジタルリテラシーの不足)がGooglezonというモンスターを生む(🔗)､(🔗)｡ Googlezonとは存在しない架空の企業であるが､中央にパワー(コントロール)が集中していくなかで､プライバシー上の懸念とかがでてくる､といったようなテーマを扱った動画に登場する｡ユーザーだけではなく､Googlezon自身もコントロールを失う段階が来る可能性がある｡皆が求めているか､求めさせられているかに関わらず､一極集中により歪みが生じる｡生じた歪みは寡占する企業にとてつもない量のリソース･データ･権限を与える｡情報は力だ｡GAFAM等に依存すると､これからも歪みがひどくなる｡養老たけしの超パノプティコン社会､I, Robotのヴィキの様な仕組みを連想する｡中央が力を持つような仕組み(システム)になり､今度はそのシステム自体を守る仕組みが出来上がる｡中央にとって都合の良い情報ばかりが広まる｡今でも､SNSやsearch engine界の寡占･検閲はひどい｡プライバシー重視したと謳う検索エンジンやブラウザがあっても､結局indexは同じだったり､ベースは同じものを使っている事が多く､中央集中は表面上よりも深刻である｡

寡占を防ぎ､de-centralizationを勧める方法として､法的な規制､企業側からの変革､ユーザー側のアクションの3つの場合を考えてみる｡

まず法的な規制だが､法的に寡占を規制し､罰金を科したところで､寡占企業にとってはopex(必要経費)である｡暴れるピットブルを細いleashでつないでいるようなものではないか｡Cレベルに対するペナルティとか別のアプローチが必要かも知れない｡ただ､GAFAMなどの肥大化したTech企業が､政府の監視部門のフロントエンドを機能的に担っている｡そのため､中央集中していた方が政府にとっては管理しやすいだろう｡

次に企業側からの変革だが､寡占で公平な競争が生まれない以上､企業側から寡占をやめるような動きはありえないだろう｡例えば､人間が地球を幅広く占領していたとして､他の動物が独占だと指摘したとする｡人間は占領や独占をやめるか? 生きるのをやめるか? そうはならないし､なれない｡寡占企業も同様だ｡独占･寡占できるなら､結局それがつづく｡仮にやめたかったとしても､やめられないと思う｡

最後に､ユーザー側のアクションについてだ｡業界が変わることを待つのではなく､結局ユーザーやコミュニティが主体的にオープンソースのハードウェアを取り入れようとする必要があると考えている｡それが､de-centralizationに繋がり､寡占企業の力を分散させることに繋がる｡しかし､やはり問題がある｡なるほど企業の態度は需要に対する反応である｡ユーザーが不買運動をすればBig brothersも反応するしかないわけだ｡ところが､利便性に極度に依存し､delegationしている現状では不買運動はできない｡BtoBにおいても例外ではない｡まずはユーザー自身がお客様をやめ､テクノロジーを学ばなければいけないだろう｡

まとめ

脆弱性への対応は､｢これでOK｣みたいなことはない｡テクノロジー的解決はもちろん望まれるが､ユーザーのマインドやリテラシーを高める意識の方が重要だと思う｡

企業や組織側は､脆弱性を期待し利用し維持している側面がある｡どれが脆弱性を望むパーティーなのかはわからないが､諜報･ハッキング･法執行･広告等の側面では脆弱性は利用できる｡それらは現状強い力やブームを持っている｡加えて､安全保障､CSAM､Carbon Footprint等､あらゆる方向から監視体制を強めようとする動きがあるため､新しい動きにも注目しておくことは大切だ｡