ブルートレース

ブルートレース

開発者	シンガポール政府デジタルサービス
紹介された	2020年3月24日 ( 2020-03-24 )
業界	デジタル接触追跡
互換性のあるハードウェア	Android および iOS スマートフォン
物理的範囲	約10メートル（33フィート）[1]
Webサイト	ブルートレース

BlueTraceは、COVID-19パンデミックの拡大を食い止めるために、ユーザーのデジタル接触追跡を容易にするオープンソースの アプリケーションプロトコルです。^{[2]もともと}シンガポール政府によって開発されたBlueTraceは、TraceTogetherアプリの接触追跡を強化しています。^{[3] [4]}オーストラリアとアラブ首長国連邦はすでに政府アプリでこのプロトコルを採用しており、^{[5] [6] [7]}他の国々もBlueTraceの採用を検討していました。^{[8] [9]}このプロトコルの原則は、プライバシーの保護と保健当局の協力です。^[10]

ユーザーのプライバシー保護は、BlueTrace の設計において中心的な考慮事項の 1 つでした。これを実現するために、個人情報は登録時に 1 回だけ収集され、感染の可能性がある患者に連絡する場合にのみ使用されます。さらに、ユーザーはいつでもオプトアウトして、すべての個人情報を消去し、記録されたデータを追跡不可能にすることができます。接触追跡は、Bluetooth Low Energy を使用してクライアント デバイス上で完全にローカルに行われ、過去 21 日間の接触を記録した接触履歴ログにすべての接触が保存されます。接触ログ内のユーザーは、保健当局が発行する匿名の時間シフト「一時 ID」を使用して識別されます。つまり、ユーザーの身元は、登録されている保健当局以外には確認できません。さらに、一時 ID は定期的に変更されるため、悪意のある第三者がログ エントリを経時的に観察してユーザーを追跡することはできません。

ユーザーが感染の検査で陽性と判定されると、保健当局は接触ログを要求します。ユーザーがログを共有することを選択した場合、ログは保健当局に送信され、そこで一時 ID と連絡先情報が照合されます。保健当局は外国のユーザーに関するログ エントリにアクセスできないため、それらのエントリは適切な外国の保健当局に送信され、そこで処理されます。ログが処理されると、保健当局は記録によって識別されたユーザーに連絡します。

このプロトコルは、デバイス付近の登録済みユーザーのローカルログ記録と、プライバシーを保護しながら運用する保健当局へのログの送信という 2 つの領域に重点を置いています。これを実現するために、プロトコルはデバイス間通信(DDC) とデバイスとレポート サーバー間の通信(DRSC) の領域に分けることができます。

DDCコンポーネントは、既存のBluetooth Low Energyプロトコル上で動作し、2つのデバイスが互いの存在を認識する方法を定義します。^{[10] : p. 2} DRSCコンポーネントは、ユーザーが感染の検査で陽性となった場合、 HTTPSを使用して保健当局が所有する中央サーバーに訪問のタイムラインを送信します。保健当局は、ログを使用して、感染患者と接触したユーザーに通知することができます。^{[10] : p. 2}

BlueTrace プロトコルを実装する各アプリには、保健当局が運営する対応する中央レポート サーバーがあります。レポート サーバーは、初期登録の処理、一意のユーザー ID のプロビジョニング、プロトコルの DDC 部分によって作成された接触ログの収集を担当します。ユーザーが BlueTrace アプリを初めて起動すると、国際形式の電話番号の入力が求められ、静的なユーザー ID が割り当てられます。^{[10] : section. 4}この電話番号は、ユーザーが感染患者の接触ログに遭遇を記録した場合、後で使用されます。

登録されると、ユーザーには他のデバイスに対して一意に識別される一時 ID (TempID) がプロビジョニングされます。各 TempID の有効期間は 15 分で、悪意のある第三者がリプレイ攻撃を実行したり、静的な一意の識別子を使用してユーザーを長期にわたって追跡したりするのを防ぎます。^{[10] : section. 4.2} TempID は、ユーザーのユーザー ID、TempID の開始時刻、および TempID の有効期限から生成され、秘密の対称暗号化キーを使用してサーバーによって暗号化され、 Base64でエンコードされた文字列に変換されます。不安定なネットワーク環境でもデバイスに TempID が一定に供給されるように、TempID は日付が付けられたバッチでデバイスに送信されます。^{[10] : section. 4.2} TempID の構成を以下に示します。

ユーザーが感染検査で陽性と判定されると、保健当局はユーザーを認証するPIN を発行し、接触ログをレポート サーバーにアップロードします。ログには各接触に関するメタデータが含まれますが、最も重要なのはタイムスタンプと保健当局識別子 (HAI) です。

HAI は、ログに記録された連絡先がどの保健当局に報告するかを識別します。HAI が外国の保健当局を表す場合、ログ エントリは識別された当局に送信され、そこで処理されます。

保健当局はログ エントリをフィルタリングしてホーム クライアントのみを含めるようにした後、TempID を復号化して、UserID、開始時刻、有効期限を明らかにします。開始日と有効期限は、有効性を確認するために遭遇時のタイムスタンプと比較され、UserID は電話番号と照合されます。その後、保健当局は電話番号に連絡して、感染患者との接触の可能性についてユーザーに通知できます。

プロトコルの DDC 部分は、2 つのデバイスがどのように通信し、その接触を記録するかを定義します。各デバイスは、それぞれ約 1:4 のデューティ サイクルで、セントラルまたはペリフェラルの 2 つの状態のいずれかになります。

ペリフェラルモードでは、デバイスは自身の存在をアドバタイズし、セントラルモードではアドバタイズしているデバイスをスキャンします。さらに、一部のデバイスはセントラルモードで動作できないため、純粋にペリフェラルモードで動作します。^[11] 2つのデバイスが互いを発見すると、それらのデバイスは自身の情報を含む特性パケットをやり取りします。パケットはJSONファイルとして形成され、デバイスのTempID、デバイスモデル、HAI、BlueTraceプロトコルバージョンが含まれます。

セントラル モードで動作している場合、デバイスは信号の強度も送信し、後で 2 つのデバイス間のおおよその距離を計算できるようになります。以下は、セントラル特性パケットの例です。

{ 
"id" : "FmFISm9nq3PgpLdxxYpTx5tF3ML3Va1wqqgY9DGDz1utPbw+Iz8tqAdpbxR1 nSvr+ILXPG==" 、// TempID "md" : "iPhone X" 、// デバイスモデル"rc" : -60 、// 信号強度"o" : "IJ_HAI" 、// ヘルスオーソリティー識別子"v" : 2 // プロトコルバージョン}	  
	  
	  
	  
	  

これらの特性は、デバイスのローカル データベースに追加され、21 日間保存され、後でレポート サーバーに送信できます。また、接続されたデバイスは、2 つのデバイスが繰り返し接続するのを防ぎ、電力とストレージを節約するために、2 つのデューティ サイクルにわたってローカル ブラックリストに追加されます。

個別の保健当局間の協力は BlueTrace プロトコルの中核コンポーネントであり、ユーザーが登録されていない外国の当局に個人情報を開示することなく、複数の当局が連携できるように設計されています。各当局は個別の暗号化キーとユーザー記録を保持しているため、保健当局は外国のユーザーのデータを復号化して見ることはできません。

ログ エントリが正しい機関に送信されるよう、DDC ハンドシェイクの一部には、登録済みの保健機関に割り当てられた一意の文字列である保健機関識別子 (HAI) が含まれます。外国の保健機関のログ エントリが識別されると、受信側の保健機関はログ エントリを外国の機関のレポート サーバーに送信し、そこで検証されて静的な PseudoID が返されます。

PseudoID は、 UserID のソルト付き 暗号化ハッシュであり、外国の保健当局が接触ログの統計分析を実行し、不必要な個人情報を開示することなく特定のユーザーについて通信できるように設計されています。PseudoID が感染患者と密接に接触していたと評価されると、PseudoID を発行した外国の保健当局に通知され、必要に応じてフォローアップできます。

ユーザーがいつでもデータの使用と収集に対する同意を撤回できることは、プロトコルの設計において重要な考慮事項でした。^{[10] ：セクション3、ポイント4}これを可能にするために、個人を特定できる情報はプロトコルのDDCコンポーネントから除外されます。つまり、個人情報が保存される唯一の場所はレポートサーバー上であり、そこでは匿名の静的ユーザーIDに関連付けられています。このユーザーID（TempIDで暗号化）は、プロトコルのDDC部分で識別のために使用されます。ユーザーが同意を撤回した場合、ユーザーレコードはレポートサーバーから削除され、連絡先ログから取得されたユーザーIDを電話番号と照合できなくなります。

BlueTraceやPEPP-PTなどのプロトコルに関して生じるプライバシーに関する最大の懸念の1つは、集中型のレポート処理の使用です。^{[12] [13] [14] [15] [16] [17]}集中型のレポート処理プロトコルでは、ユーザーは接触ログ全体を保健当局が管理するサーバーにアップロードする必要があり、保健当局はログエントリを連絡先の詳細と照合し、潜在的な接触を確認し、最終的に潜在的な接触についてユーザーに警告する責任を負います。^[18]

一方、分散型レポート処理プロトコルは、中央レポートサーバーを持ちながら、ログ処理の責任をネットワーク上のクライアントに委任します。TCNやDP-3Tなどのこのアプローチを使用するプロトコルでは、クライアントが番号をアップロードし、そこから個々のデバイスがエンカウンタートークンを導き出します。次に、クライアントはこれらのトークンをローカルの接触ログと照合して、感染患者と接触したかどうかを判断します。^[19]このプロトコルは政府に接触ログへのアクセスを許可しないという事実に内在しており、このアプローチには大きなプライバシー上の利点があります。ただし、この方法にはいくつかの問題もあります。主に、人間が関与する報告がないため、誤検知の発生率が高くなることです。^[18]また、一部のデバイスが大量のレポートで圧倒される可能性があるため、潜在的なスケールの問題もあります。分散型レポートプロトコルは、集中型のプロトコルほど成熟していません。^{[20] [21] [22]}

OpenTraceは、 GPL-3.0ライセンスの下でリリースされたBlueTraceのオープンソースリファレンス実装です。^{[23] [24] [25]}プロトコルのDRSC側はFirebaseプラットフォームを使用して実装されており、^{[26]すべてのクライアント呼び出しに}サーバーレスコンピューティングフレームワークであるFirebase関数を使用しています。また、Firebase Secret Manager ^{[27] : 29行目から37行目}、およびStorage ^{[28] : 22行}目に暗号化キーと連絡先ログを保存しています。プロトコルのアプリ/DDC側には、AndroidおよびiOSデバイス用のTraceTogetherアプリの修正版が含まれています。^{[29] [30]}

COVIDSafe ^{[31] [32]は、進行中の}COVID-19パンデミックと戦うために2020年4月14日に発表されたOpenTrace / BlueTraceに基づいたオーストラリア連邦政府によって発表されたデジタル接触追跡アプリです。^[33] 2020年4月26日、オーストラリア連邦政府はアプリの最初のバージョンを一般にリリースしました。^{[6] [5]}リリース後24時間以内に100万人以上がアプリをダウンロードし、^[34] 48時間以内に200万人を超えました。^[35] 2週間目までには、400万人以上のユーザーが登録しました。^[36]リリースに伴い、ピーター・ダットン内務大臣は、たとえ登録して陽性反応が出た場合であっても、アプリからデータを引き渡すよう強制することを違法とする新しい法律を発表しました。^{[37] [38]}アプリのソースコードも、オーストラリア信号局による審査が完了するまでの遅延^{[41]の後、2020年5月8日にリリースされました。[39 ] [ 40 ] [42]}

• 一緒にトレース
• TCN プロトコル
• 汎欧州プライバシー保護近接追跡
• (Google/Apple) 接触通知 (GAEN)

• ホワイトペーパー
• オープントレース GitHub
• BlueTrace ホームページ