2020/09/28
Exposure Notifications System
シルバーウィークはいかがお過ごしだったでしょうか。
私は日頃の運動不足を解消しようと思って近所をたくさん歩いたら足を痛めてしまい結果倒れていました。リモートワークの弊害です。
今回は弊社の栗山が「Exposure Notifications System」について話しました。
Apple / Google が提供している API、フレームワークなどの集まりである、濃厚接触の可能性を検出するシステム(Exposure Notifications System) の仕組みを解説します。
日本の COCOA もこのインフラを使っていますが、どういう仕組みで動いているかを理解する手助けになれば幸いです。
Exposure Notifications System と表現してるのは Google で、Apple だとExposure Notification Framework などと呼ばれています。ユーザー向けの表現は iOS では、Exposure Notification (日本語だと接触通知) となっています。
Bluetooth Low Energy を使って、それぞれの端末が、時間で変化するランダムな識別子をばら撒くと同時に、周囲の識別子をどんどん拾っていきます。
厚生労働省は、陽性者と診断された人のうち登録OK とした人の識別子を通知サーバーにアップし、端末は毎日それをダウンロード。
拾った識別子とダウンロードしたものを比較して、マッチすれば端末に画像のようなプッシュ通知を送るといった流れです。
端末は2週間分の拾った識別子を保存しています。
またカウントされていたとしても、どのタイミングでどのように接触したのかはわからないようになっています。
もうすこし推測する方法はあるのですが、それは後ほど説明します。
Temporary Exposure Key (TEK)
一番メインになる鍵で、日次鍵と呼ばれます。完全な16ビットの乱数です。毎日 UTC で 00:00 のタイミング(日本時間の午前9時)に全てのデバイスが一斉に更新されます。
陽性者にならなければ端末の外に出る情報ではありません。
ENIntervalNumber (ENIN)
時刻を示す値で、エポック秒 / 600 したものです。TEK は一日ごとに一斉に作られますが、その開始時刻を ENIN で表現したものが先ほどの TEK とペアで2週間分が端末に保存されます。
Rolling Proximity Identifier Key (RPIK)
Bluetooth でばら撒くものの鍵となるものです。これ自体はばら撒きません。
通知サーバーからとる Diagnoses Keys (診断鍵) と呼ばれるデータにはこれが含まれているはずです。
Rolling Proximity Identifier
今使っている TEK に紐付いた ENIN を RPIK を使って AES 暗号化したもの。 これが端末から Bluetooth でばら撒かれる識別子です。
Bluetooth の仕組みとして、定期的に MAC アドレスを更新するというのがあるそうで、そのタイミングでばら撒く識別子も変更するという仕様になっています。
結果的には RPI(Rolling Proximity Identifier) が Bluetooth を使って周囲にばら撒かれ、端末はそれを拾っていくという仕組みです。
陽性の診断を受けると、検査機関から陽性者の情報が保健所に伝わり、本人に電話連絡がいくそうです。 その際、「接触確認アプリを使っている場合は処理番号を発行します」と言われます。
発行された番号をアプリから入力すると、自分の端末に保存されている TEK / ENIN ペア 2週間分が厚生労働省のサーバーに送られ、さらに厚生労働省のサーバーから、それら送られてきたデータが一日分まとめて通知サーバーにアップされるような流れとなります。
先ほど少し話しましたが、iOS 端末の場合、設定のところから接触通知を開くと、接触チェックの記録一覧が見れ、そこから JSON がダウンロードできるようになっているのですが、それには下のような情報が入っています。
iOS では
プッシュ通知を受けた人は、
ですが、 それをやるには厚労省の持ってるデータ(それだけで十分個人情報)が必要なので、
このことから、日本の接触確認アプリも陰性者として使う範囲では個人的には全く問題ないと思っています。 ただし「陽性者として処理番号を登録すると、端末内の RPIK が送信され、最終的に全ユーザーにばら撒かれる」ということは意識しておく必要がありそうです。
私は日頃の運動不足を解消しようと思って近所をたくさん歩いたら足を痛めてしまい結果倒れていました。リモートワークの弊害です。
今回は弊社の栗山が「Exposure Notifications System」について話しました。
Apple / Google が提供している API、フレームワークなどの集まりである、濃厚接触の可能性を検出するシステム(Exposure Notifications System) の仕組みを解説します。
日本の COCOA もこのインフラを使っていますが、どういう仕組みで動いているかを理解する手助けになれば幸いです。
※今回の話は完全ではない解析による想定を含んでいます。ご注意ください。
概要
今年の4月、GoogleとApple で共同発表された Exposure Notifications System ですが、公開された仕様案によれば、Android / iOS 両方で同じ仕様を用いた API を用意して、プライバシーに配慮しつつ、低消費電力で陽性者との接触可能性を追うための仕組みとのことでした。Exposure Notifications System と表現してるのは Google で、Apple だとExposure Notification Framework などと呼ばれています。ユーザー向けの表現は iOS では、Exposure Notification (日本語だと接触通知) となっています。
仕組みについて
大まかな説明ですが、、Bluetooth Low Energy を使って、それぞれの端末が、時間で変化するランダムな識別子をばら撒くと同時に、周囲の識別子をどんどん拾っていきます。
厚生労働省は、陽性者と診断された人のうち登録OK とした人の識別子を通知サーバーにアップし、端末は毎日それをダウンロード。
拾った識別子とダウンロードしたものを比較して、マッチすれば端末に画像のようなプッシュ通知を送るといった流れです。
端末は2週間分の拾った識別子を保存しています。
またカウントされていたとしても、どのタイミングでどのように接触したのかはわからないようになっています。
もうすこし推測する方法はあるのですが、それは後ほど説明します。
裏側の仕組み
政府が用意している仕様書があるのですが、こちらを参考に裏側の仕組みについて話していこうと思います。Temporary Exposure Key (TEK)
一番メインになる鍵で、日次鍵と呼ばれます。完全な16ビットの乱数です。毎日 UTC で 00:00 のタイミング(日本時間の午前9時)に全てのデバイスが一斉に更新されます。
陽性者にならなければ端末の外に出る情報ではありません。
ENIntervalNumber (ENIN)
時刻を示す値で、エポック秒 / 600 したものです。TEK は一日ごとに一斉に作られますが、その開始時刻を ENIN で表現したものが先ほどの TEK とペアで2週間分が端末に保存されます。
Rolling Proximity Identifier Key (RPIK)
Bluetooth でばら撒くものの鍵となるものです。これ自体はばら撒きません。
通知サーバーからとる Diagnoses Keys (診断鍵) と呼ばれるデータにはこれが含まれているはずです。
Rolling Proximity Identifier
今使っている TEK に紐付いた ENIN を RPIK を使って AES 暗号化したもの。 これが端末から Bluetooth でばら撒かれる識別子です。
Bluetooth の仕組みとして、定期的に MAC アドレスを更新するというのがあるそうで、そのタイミングでばら撒く識別子も変更するという仕様になっています。
結果的には RPI(Rolling Proximity Identifier) が Bluetooth を使って周囲にばら撒かれ、端末はそれを拾っていくという仕組みです。
陽性登録
これまでの話は陰性、もしくは検査を受けていないユーザーの話だったのですが、今度は陽性になったユーザーが陽性登録する時の仕組みについてです。陽性の診断を受けると、検査機関から陽性者の情報が保健所に伝わり、本人に電話連絡がいくそうです。 その際、「接触確認アプリを使っている場合は処理番号を発行します」と言われます。
発行された番号をアプリから入力すると、自分の端末に保存されている TEK / ENIN ペア 2週間分が厚生労働省のサーバーに送られ、さらに厚生労働省のサーバーから、それら送られてきたデータが一日分まとめて通知サーバーにアップされるような流れとなります。
接触可能性のある日時を特定する
それでは、それらの識別子を用いて何ができるのでしょうか。先ほど少し話しましたが、iOS 端末の場合、設定のところから接触通知を開くと、接触チェックの記録一覧が見れ、そこから JSON がダウンロードできるようになっているのですが、それには下のような情報が入っています。
{
"Hash" : "2E363DA3EFBF64A65C5DAAE8A5525FD43F7D53B733923E23A61C715EB2879217",
"MatchCount" : 1,
"KeyCount" : 7,
"AppBundleIdentifier" : "jp.go.mhlw.covid19radar",
"Timestamp" : "2020-09-06 00:21:25 +0900"
},mhlw が厚生労働省、covid19radar がアプリです。MatchCount は接触回数になります。iOS では
MatchCount とともに Hash という情報が保存されていますが、これはおそらく RPIK のことです。 厚生労働省の通知サーバーに置いてある陽性者データファイルは RPIK と ENIN があるので、ENIN からその RPIK がいつ作られたか (UTC 00:00-23:59 有効) がわかります。プッシュ通知を受けた人は、
Hash から接触可能性のある 24 時間を特定できるので、その日の行動を振り返り、どのタイミングで陽性者と接触し得る状況があったのかを推測することができます。プライバシー的な考慮点
Google / Apple 側の仕様として、個人を特定しないと言っていること自体は正しいのですが、日本の場合、厚労省側で陽性者に関するデータ (RPIK とそれを個人情報に紐付ける) を持っているので、 全端末に配られているデータのHash と、厚労省が持ってるデータを突き合わせれば本人が特定できてしまい、 Hash が個人に紐づく情報、と言えなくもないかもしれません。ですが、 それをやるには厚労省の持ってるデータ(それだけで十分個人情報)が必要なので、
Hash だけをもってそれが要プライバシー配慮情報と言うことは難しいと思われます。このことから、日本の接触確認アプリも陰性者として使う範囲では個人的には全く問題ないと思っています。 ただし「陽性者として処理番号を登録すると、端末内の RPIK が送信され、最終的に全ユーザーにばら撒かれる」ということは意識しておく必要がありそうです。
