技ビス : 技術、ビジネス、スタートアップ

技術、ビジネス、スタートアップに関する情報と話題とアイディアと事例

Covid-19アプリCOCOAの挙動を調べてみた。プライバシーを懸念する人へ。

※下記は2020/06/20時点の情報によるものです

厚生労働省から新型コロナウィルス接触アプリが公開されました。

www.mhlw.go.jp

ざっくり何ができるかというと、コロナ感染者と過去2週間のうちに濃厚接触したかどうかを判定してくれます。

一方で、「プライバシー大丈夫なのか」と言った懸念が出ているようです。なるほど id:yugui さん賢い。情報公開請求。

blog.yugui.jp

www.itmedia.co.jp

一定レベルアプリの挙動を見ればどう言ったデータを送っているのかをみることはできるので、試してみました。

結論としては、今回10分くらい観測した範囲では下記のことは確認できました。

  • 基本的にiOSに実装されているCovid19向けのAPIを利用しており、厚労省の接触確認アプリが独自仕様で個人情報を取得しているわけではない(?)
  • 接触確認アプリがBluetoothで発信している情報はApple/Googleが決めた仕様通りの情報。
  • アプリの利用データをmicrosoftのapp centerに送っている。おそらく、デバッグのため。
  • 初回利用時に、端末の登録を行っている(ユーザの情報は送っていない)。ただし、Apple/Googleの仕様にはない挙動で一定レベルのプライバシーリスクを認めることができる。

長文ですが、以下コンテンツです。

アプリのプライバシーアクセスを確認する

Androidは詳しくないのですがiOSのプライバシーアクセスはしっかりしており、基本的にOpt-inです。何を許可しているかは設定から確認できます。

例えばFacebookアプリの設定を開くとたくさんの情報にアクセスしていることがみて取れるかと思います。位置情報や写真など多くのプライバシー情報にアクセスしていることがわかるかと思います。

一方で接触確認アプリですが、ほとんどプライバシー情報にアクセスしません。

注目すべき点は「COVID-19接触通知」がオンになっているところです。

f:id:harajune:20200620213817p:imagef:id:harajune:20200620213822p:image

接触確認アプリを開くと、Bluetoothや通知に関するopt-inのメッセージは出ますが、GPSなどの位置情報の取得は出ません。この点からも、位置情報は取得していない・・・と類推されます。

iOSのCOVID-19接触通知で取得される情報

この機能はそもそも何でしたっけ?というのは、Appleのページに記載されています。

www.apple.com

あまりはっきりしたことが書かれていないですが、下記にAppleとGoogleが決めた仕様が詳細に記載されています。結論としては、下記の情報が取得されています。噛み砕いて書いているので、正確ではないですが詳細は後述。

  • COVID-19接触通知アプリを入れている人が近くにいた記録
  • その人と接触したタイミング

www.apple.com

判断が難しいのは、本当にアプリがこの仕様通りに動いているのか・・・という点ですね・・・

Privacy-Preserving Contact Tracingの仕組み

詳細は、上記のリンク先をご覧いただくとして、ここではどういう仕組みなのかをすごくざっくり解説したいとおもいます。

まず、感染通知アプリをインストールしているスマホの中で1時間に一回、完全にランダムな秘密の鍵(Temporary Exposure Key = TEK)を生成します。

f:id:harajune:20200621152028p:plain



このTEKはこのスマホの中にしか存在しておらず、個人情報とも結びついていません。

次に、このTEKを使って接触したことを判定する目印(Rolling Proximity Identifier = RPI)を生成します。この時、TEKからRPIは作れるがRPIからTEKを作れないのがポイントです。

f:id:harajune:20200621150830p:plain

濃厚接触すると、このRPIがBluetoothを通して接触者のスマホに転送されます。この時点ではまだ、感染したかどうかはわかりません。

f:id:harajune:20200621151004p:plain

ここでもし上の人が感染したことが発覚したとしましょう。すると上の人はアプリ上で接触したことを申告し、それをサーバにアップロードします。この時、サーバには秘密の鍵TEKをアップロードします。

f:id:harajune:20200621151223p:plain

サーバには、他の感染者の秘密の鍵TEK(b1)も一緒に蓄積されています。

f:id:harajune:20200621151346p:plain

接触アプリは定期的にこの鍵TEKのリストをダウンロードし、接触した時に取得した目印RPIと比較することで接触したかどうかを判定します。

f:id:harajune:20200621151510p:plain

細かいところは省略していますが概ねの仕組みとしてはこうです。

この時、いくつかのポイントにより感染者のプライバシーが保たれています。

  • 秘密の鍵TEK(a1)は完全にランダムな値で個人を紐づける方法がないため、TEKから個人を特定することができません。
  • 感染するまでTEKが自分のスマホの外にでることはなく、非感染者のプライバシーも安全です。
  • Bluetoothで渡されるのはRPIのみで、またRPIからTEKを見つけることは困難なため、感染したTEKから感染者を特定することはできません。TEKは毎日変更され、また、一般的に十分だと思われる長さ(128bit)を持っています。

よくできた仕組みですね。

実際にこの通りに実装されているのか問題

このアプリのベースになっているものはオープンソースで公開されていますが、これをそのままアプリとして出しているわけではないそうです。また、Apple/Googleの仕様通りに動いているのかも、確認することはなかなか難しいでしょう。

確認できる範囲でみてみようかとおもいます。

Bluetoothの挙動

Apple/Googleの仕様によると、ランダムに変更されるBluetooth機器のMACと共に、0xFD5Fのサービスでアドバタイズしているようです。ツールを使ってアドバタイズを確認してみましょう。Macの標準ツール、Bluetooth Explorerでできます。

f:id:harajune:20200621153157p:plain

Service UUIDがFD6Fになっているアドバタイズパケットを探してきてみました。確かに、AddrがRandomに指定されており仕様通りのパケットがアドバタイズされていることがわかります。

サーバとのHTTP/HTTPS通信

アプリをインストールした直後から10分程度のHTTP/HTTPS通信の中身を観察してみました。

f:id:harajune:20200621153432p:plain

ざっくり内容を見たところ、概ね下記の3パターンでした。

  • アプリの利用に必要な利用登録
  • 利用規約などアプリに関する情報を取得している
  • アプリの利用ログの収集と思われるもの

いったん注目すべきは1点目かなと思うので掘り下げてみましょう。POSTリクエストですがクエリは空です。

f:id:harajune:20200621153941p:plain

このリクエストに対してサーバ側からシークレットキーとこの端末を識別するUUIDが送られてきています。

f:id:harajune:20200621154457p:plain

なるほど?先ほどのGoogle/Appleの仕組みからするとちょっと気持ち悪いですが、日本の接触確認アプリではサーバ側で払い出した識別情報(UUID)と秘密鍵(secret)を元に感染者や接触者を特定しようとしている・・・・のかな?ここは謎です。

GIthubにあげられているアプリの仕様

ここでちょっと視点を変えて、接触確認アプリのベースになったらしいソフトウェアのリポジトリを見てみましょう。メンテされているかは不明ですが、こちらに簡単なドキュメントが書いてあります。

github.com

詳しくは解説しませんが、割とApple/Googleの仕様からは離れています。パッとみた感じ、Google/Appleの仕組みと比べるとこの仕組みにはいくつか欠点がありそうに思います。

  • 端末登録時に識別情報が1意に特定(厳密にいうとちょっと違うけど)され、それをアドバタイズするので、自分の識別情報がバレると大声で個人情報を叫んでるのと似たような状況になってしまう。
  • 誰でもとあるIDが感染した人なのかを確認可能なので、街中で拾った適当な値を使って濃厚接触したかを確認できてしまう。上記の問題と合わせると、例えばスタバで座ってる目の前にいる人が濃厚接触者だったかどうかを確認できてしまう。

ちょっと、危なっかしい気がしますね・・・・

そして、この仕様はアプリの挙動を見る限りまだ残っていそうです。いいのかな・・・?

接触確認アプリのプライバシーリスクについてのまとめ

おおすじ安全と言えるのではないでしょうか。今後、検証されていくものと思います。

懸念点としては下記でしょうか。

  • Apple/GoogleのAPIを使ってそうな割に、独自仕様のUUIDの挙動が残っている。そして、独自仕様の仕組みには致命的ではないにしても一定レベルのリスクがある。
  • アプリの利用ログをどの程度取得しているかによって、端末と感染者を紐づけられる可能性はゼロではない気がする。確率はかなり低そう。

というわけで、土日の合間でできた確認はここまででした。