AppleとGoogleの新型コロナ対策「Exposure Notification」メモ 

* 本記事は[Note](https://note.com/ken_hamada/n/nce3db6fb0a80)から転載させて戴きました。

[AppleとGoogleの新型コロナ対策、提供方法などの具体像が固まる](https://www.itmedia.co.jp/pcuser/articles/2005/05/news016.html)という記事がありました。見ますとコードも公開されているという事で、Androidのが以下にありました。

https://github.com/google/exposure-notifications-android

上記のREADMEを見ると各仕様が置いてありましたので、ごくごく荒くではありますが漁ってみました。

**ちなみに私の技術力、英語力は共に悲惨極まりない老害のそれなので鵜のみは禁止でリンクした仕様の補完という意味合いで使って下さい。私の文章を元に何かしでかして損害こうむっても私は知りませんですごめんなさい…**

## デバイス同士でのやりとりについて

Bluetoothの通信仕様は以下でApril 2020 v1.2 に基づいています。

https://www.blog.google/documents/70/Exposure_Notification_-_Bluetooth_Specification_v1.2.2.pdf

割と簡単です。ざっと見た所以下。

* BluetoothLowEnergyのAdvertiseを使っています。なのでいわゆるビーコンデバイスって物となりますでしょうか。
* データを送信する際にはランダムアドレスを使います。スマホの物理アドレス（設定画面に出るもの）は使ってませんので、受ける相手はここで定義された信号からそれを取得することはできません。
* しかも定期的（10分から20分？）にそのランダムアドレスは変更しろとあります。

で、どういうデータを吐き出しているかというと以下

（１）Associated Encrypted Metadata。以下のデータが含まれます

　　→Exposure Notificationのバージョン（現時点ではメジャー1でマイナー0が入るっぽい）
　　→送信パワー：+127から-127dBmで指定。これは距離の類推で使うような感じっぽい。

（２）RollingProximityIdentifie

　　→16バイトの数列。送り元の時刻情報と定数を元に作られた識別子

上記（１）、（２）は暗号化されたデータとして定義されています（概要は次節）

要は識別子と電力値を暗号化してバラまいてますよーというものです。このデータは今の仕様だと1秒間に3-5発は出す感じみたいです。なのでAdvertiseを拾うアプリ作ればこのデータを受け取るのは比較的簡単ではあります。このデータ交換イメージを以下に（ひっぱたくとおっきくなります）

![fig1.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/294469/8d45038d-1544-3bd7-311f-fedf1e66f86a.png)


図だと１対1に見えますが、これは他の対応スマホが近くに無い想定です「バラまいている」と書いたように、Bluetooth（BLE)が届く範囲内全てのスマホ（というかBLEデバイス）に向けてデータは出しますので、対応スマホは受けたデータは全部蓄積します。なので飲み会の席で範囲内に対応スマホを持つ人が10人いれば、10人のデータがそこで蓄積されます（データロスがなければですが）

## データについて

で、RollingProximityIdentifierって何者って話になるかと思いますが、それは以下の暗号化仕様に書いてありました。こちらもApril 2020 v1.2の仕様についてみたものです。

https://www.blog.google/documents/69/Exposure_Notification_-_Cryptography_Specification_v1.2.1.pdf

結論からいうと、仕様を見る限り、RollingProximityIdentifier自体は特に意味がある数値ではなさそうです。この数値単体で例えば持ち主が誰であるとか位置などが分かるようなものではないと思われます。作り方は上記資料にあります。それを咀嚼して算出アルゴリズムをまとめたものが下図です。間違いがあったらごめんなさいなのです…（ひっぱたくとおっきくなります。まぁご参考までで…）

![fig2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/294469/4d0a6b45-d810-fee4-3011-78d4302b9ed0.png)


図で赤く書いたデータがBluetooth(BLE)で送信されます。緑で書いたデータはスマホ内部の安全な場所に保存されます。

図でHKDFとあるのはIETF RFC 5869で定義されたハッシュベースのメッセージ認証コードに基づく鍵生成アルゴリズムとのことです（ペディアの説明が[ここ](https://en.wikipedia.org/wiki/HKDF)）。AESとかAES－CTRというのは暗号化処理を指します。

ちなみにRollingProximityIdentifierのデータはおおよそ10分、鍵情報は1日で更新されるみたいです。両者で違いがあるのはRollingProximityIdentifierの算出時に時間を使い、その時間情報が10分で更新されるためです。

上記のデータが暗号化され、Bluetoothを経由して別のスマホ（複数）に定期的に送られる事となるです。

## スマホが保存するデータ

Exposure Notificationが有効なスマホでは以下のデータが保存される事になるはずです。

* 自分が出したデータの鍵情報と時刻情報（一定時間例えば14日間とか）
* 他のスマホが吐き出した暗号情報。これも一定期間（※１）

　　※１：Bluetoothの仕様を見るとそう取れるという感じです。

## 利用者から陽性者が出るとどうなるか

* ユーザーが陽性と判定されると、その人のスマホは自分で溜めてた鍵情報と時刻情報全部を業者のサーバに上げます（※２）
* サーバ側で陽性者データリストを持っていて、そこに追加されます（仕様ではDiagnosis Keysとあるもの）

　　※２：恐らくですが自動ではなくユーザが許可しないとダメになると思われます。陽性という設定をどっかでしないとですから。

## 陽性者データリストについて

で、Exposure Notificationはこの陽性者データリストを定期的にサーバから取得します。つまり陽性者から過去に（陽性判定される前に）送られてきた暗号化データを元に戻すことが可能です。

この情報が更新されたならば、その陽性者データと内部に蓄積したBluetoothで受信した他のスマホからのデータ（暗号化データ）とを突き合わせます。ここで一致するものがあれば、時刻情報やAssociated Encrypted Metadataの電力値等の情報を元に接触度合いを推察して、警告がする事が出来るよーみたいな仕組みらしいです。というイメージ絵を以下に（ひっぱたくとおっきくなります）。

![fig3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/294469/8a1351c6-7b0c-1c4a-ce05-3d185a2e1825.png)


## つーことで

Bluetooth Low Enegryとサーバとを紐づけて色々しているという感じに思えましたですまる。IoTがこんな所でもという感じですね。

* 以下のURLにある仕様書を参考に本記事を書かせて戴きました。
https://github.com/google/exposure-notifications-android

* 「いらすとや」さんの素材を利用させて戴きました
https://www.irasutoya.com/

* 図でプロ生ちゃんと言うキャラを利用させて戴きました。
https://kei.pronama.jp/guideline-others/