ローリングコンバットピッチなう！

AIとか仮想化とかペーパークラフトとか

AppleとGoogleのContact Tracingの仕様書を読んで見た(新型コロナウィルス濃厚接触者追跡ソリューション)

[technology]位置情報ではダメなのか？

下記の発表が話題になっています。AppleとGoogleがスマフォのBluetoothを活用し、新型コロナウィルス感染者と濃厚接触した可能性のある人を検出する技術です。

AppleとGoogle、新型コロナウイルス対策として、濃厚接触の可能性を検出する技術で協力
www.apple.com

発表だけ見ると詳細が判らないのですがBluetoothを使った近接スキャンの仕様が公開されています。
www.apple.com

仕様書は下記の3つ。

  • Contact Tracing - Bluetooth Specification
  • Contact Tracing - Cryptography Specification
  • Contact Tracing - Framework API

そのうち「Contact Tracing - Bluetooth Specification」
https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ContactTracing-BluetoothSpecificationv1.1.pdf
を軽く読んでみました。

6ページの短いドキュメントで現時点で記載されているのは、Bluetoothを利用してどのように近接スキャンするかの仕様/通信フォーマットとその際のプライバシー保護の仕組みです。
近接スキャンしたデータをどのようにして感染者情報と突き合わせるか？については記載されていません。デバイス(スマフォ)に搭載されるBluetoothを利用したスキャンの方法のみが記載されている様に読めます。

概要としては以下のものです。

  • Bluetooth Low Energyを使用する。
  • デバイス毎の固有のKey(Tracing Key）を付与する。
  • 24時間毎にTracing KeyからDaily Tracing Keyを導出する。
  • デバイスは自IDを周囲にadvertiseする。ただしこのIDはTracing KeyやDaily Tracing Keyそのものではなく、Daily Tracing Keyから導出された「Rolling Proximity Identifier」を利用する。Rolling Proximity Identifierはおよそ10〜20分毎に新しい値に更新される。
  • Rolling Proximity Identifierのadvertise時、送信元アドレスもRolling Proximity Identifierの変更と同期して変更される。これにより端末アドレスとRolling Proximity Identifierの紐付けを防止する。(ここでの端末アドレスはBluetoothのMACアドレスと思われる)
  • Advertiseは200〜270ms周期で実行される。
  • 周囲のスキャン間隔、ウィンドウは5分間程度(常時スキャンではなく、5分スキャン、5分休止？)...濃厚接触の特定に有効な値に今後調整される。
  • スキャン結果はRSSIと合わせて端末に保存される。(RSSIから距離を推定するものと想定)
  • 感染者は自己申告すると、Daily Tracing KeyのサブセットであるDiagnosis Keyが追跡サービスにアップロードされる。

こんな感じで、Bluetooth固有のMACアドレスを報知せず、代わりにデバイス毎に設定されたTracing Keyから2段階の演算を経て導出されたRolling Proximity Identifierを一定時間毎に切り替えながら使う事で、デバイスと報知されるIDの紐付けを防ぐ..というのがプライバシー保護の骨子の様です。

Tracing Key→Daily Tracing Key→Rolling Proximity Identifierを導出する詳細な演算方法は規定されていません。おそらくは何らかのハッシュアルゴリズムを利用してTracing Keyと日付、時刻を掛けあわせたものに、一方向性演算(総当り以外に逆算が困難)を掛けるものと推測されます。

仕様書には本ソリューションにおいて近接判定にはBluetoothの信号のみを利用し、位置情報は利用しないことが明記されています。

Bluetooth上での報知に利用するIDと端末の紐付けを防ぐ仕組みは良く考えられている様に思います。
ただし、Bluetoothで他の通信も同時に実施していると、その信号もスキャンしてMACアドレスとRSSIの強度分布と、Rolling Proximity Identifierとそれに紐づくRSSIの強度分布を比較するとある程度推測できたりしないかな...ディープラーニングとか使って学習させるとピンポイントじゃなくても候補くらいは出せそうな気がちょっとしています...まあ、そこまでやる人は居ないかな...

最初に発表を見た際の感想としては「Bluetooth？位置情報使った方が実装早いんじゃないの？」というものです。
例えばandroid端末でgoogleアンケートというアプリをインストールすると、種々のアンケートがgoogleから送られてきます。回答するとgoogle playのクレジットが少しづつ貰えるのですが、そのアンケート内容は明らかに位置情報から拾ったもの「最近xx(商業施設名、ホテル名等)に行きましたか？」が多くあり、googleはgoogleアカウントとユーザーの位置情報履歴を紐付けたデータベースを持っているはずです。おそらくAppleも同様のものを持っているので、その2つのデータベースを相互検索可能にしたほうが遥かに実装は早いはずです。

もちろん近接判定の精度としてはBluetooth LEを使った方が精度が高いかもしれませんが、一定時間以上(30分とか1時間とか)、密閉された空間で一緒に過ごしたレベルの濃厚接触であれば位置情報ベースでもそれなりの精度が出る気がします。また今回のソリューションは位置情報を使わないため、「どこで？」が当人には判りません。
時刻情報は残るのだけど、感染者が居た場所と自分が居た場所の情報が提供されない場合、「あなたは4/11の14時頃に新型コロナ感染者の近くに居ました」という通知だけが来るわけで、この情報だけで自分を自主隔離するのは、心理的にハードルが高いな..と思います。

プライバシー配慮が強調されていますが、両社共に既にユーザーの位置情報を様々なビジネスに利用している状況で少し違和感があり、両社が互いの「宝の山」である位置情報履歴データベースを相互接続したくない..という意図があるのではないかと勘ぐってしまいます。

いずれにせよ、これから、
1. Apple(iPhone,iPad等)及びandroidデバイスにContact Tracing昨日を実装
2. Contact Tracing情報を蓄積するデータベースサーバーと検索システムを実装する
3. 2.が共通サーバーでない場合、両社のサーバー・サービスを接続する
必要があります。

Appleの場合は、iOSのバージョンアップとしてOS自体に組み込んでばら撒けますが、androidはOSレベルの改変は各デバイスベンダーが実施することになるので、OSレベルへの組み込みはかなり時間がかかります。アプリとして実装してgoogle play上に置く事は出来ますが、androidアプリだとメモリ不足時に強制停止されたりして技術的には安定稼働に不安があるのと、OSレベルのアップデートでない場合にどの程度普及するか未知数な感じがします。

更に今回のソリューションはユーザーの同意を得て動作すること、となっていますが、OSレベルで組み込んでしまえば、技術的にはデフォルト有効とか強制有効にすることも可能と思われます。
このあたりの運用レベルにApple製品とgoogle製品(androidだけでなくchrome OS等も入るのでしょうか？）で差が出そうな気がします。

取り組み自体は否定しないものの、「今、感染拡大している新型コロナウィルス」に間に合うのか？(そもそも間に合うとしたら、収束がかなり長引いて、これから1,2か月では済まないという事)、次に同様の感染症が広がった際に対策になるのでは？という気もしますが、そこはAppleとGoogleなので、あと1週間くらいでアプリが提供されそうな気がします。



追記: 位置情報は屋内だとGPSよりWi-Fi測位が主体になるのだと思いますが、どこかにBLEとWi-Fi測位の精度に関する情報無いかなと探したら下記の様な資料がありました。
BLEでも5〜10m誤差は出る様ですね。Wi-Fiだと10〜20mくらいか？
いずれにせよスマフォを使う場合、機種ごとのアンテナ設計、感度や持ち方(手に持つか、かばん等に入れるか)でかなり誤差の幅はあると思います。
BLEを使った場合でもピンポイントで「2m以内」とか判定するの難しい気も。10m以内くらいを「接触可能性有り」にするのかな？

避難誘導のためのWiFi/Bluetoothを用いた
低コストな屋内測位環境構築に関する実験
https://www.mlit.go.jp/common/001081387.pdf

追記2: BLEによりスキャン結果(Rolling Proximity IdentifierとRSSI測定値とおそらくは時刻情報)は端末に保存されます。
おそらく感染者が自己申告してアップロードしたDiagnosis Keyがサーバーから降ってきて、これを端末内に保存された他の端末から報知されたRolling Proximity Identifierと比較するんじゃないかと思いますが、単純比較出来ないはずなので、結構な演算量が生じる気がします。それとも感染者側に保存された接触記録を全部サーバーに吸い上げて、サーバー側でマッチング処理やって結果だけ濃厚接触の疑いがある人に通知されるのかな？
デバイス性能考えると後者のほうが良い気がしますが、そのあたりは仕様書からは読み取れないです。