分散型プライバシー保護近接追跡

分散型プライバシー保護近接追跡

開発者	エコール ポリテクニック連邦ローザンヌ校 チューリッヒ工科大学 ルーヴェン・カトリック大学 デルフト工科大学 ユニバーシティ・カレッジ・ロンドン ヘルムホルツ情報セキュリティセンター トリノ大学 ISI財団 INESCテック[1]
紹介された	2020年4月4日[2] ( 2020-04-04 )
業界	デジタル接触追跡
互換性のあるハードウェア	Android および iOS スマートフォン
物理的範囲	約10メートル（33フィート）[3]
Webサイト	https://github.com/DP-3T/documents

分散型プライバシー保護近接追跡（DP-3T 、 dp ³ tと表記）は、COVID-19パンデミックに対応して開発されたオープンプロトコルで、感染者のデジタル接触追跡を容易にする。 ^{[4] [5]}このプロトコルは、競合プロトコルである汎ヨーロッパプライバシー保護近接追跡（PEPP-PT）と同様に、Bluetooth Low Energyを使用して他のユーザーとの接触を追跡および記録する。^{[6] [7]}これらのプロトコルは報告メカニズムが異なり、PEPP-PTではクライアントが接触ログを中央報告サーバーにアップロードする必要があるのに対し、DP-3Tでは中央報告サーバーは接触ログにアクセスすることはなく、接触を処理してクライアントに通知する責任もない。^[1]接触ログが第三者に送信されることはないため、PEPP-PTアプローチに比べてプライバシー上の大きな利点がある。^{[8] [9]}ただし、感染報告を処理するためにクライアント側でより多くの計算能力が必要になるという犠牲を払うことになる。^[10]

Apple/GoogleのExposure NotificationプロジェクトはDP-3Tプロトコルと同様の原理に基づいており、2020年5月からその変種をサポートしています。^{[11] [12] [13]} Huaweiは2020年6月に「Contact Shield」として知られるHuawei Mobile Services APIにDP-3Tの同様の実装を追加しました。^[14]

DP-3T SDKとキャリブレーションアプリは、iOSおよびAndroidデバイス向けにリリースされ次第、Apple/Google APIをサポートする予定です。^{[15] [16]}

2020年4月21日、スイス 連邦保健局は、スイスの国家コロナウイルス接触追跡アプリがDP-3Tをベースにすると発表した。^[17] 2020年4月22日、国家デジタル接触追跡アプリを主導しているオーストリア赤十字社は、DP-3Tアプローチへの移行を発表した。^[18] エストニアも、自国のアプリがDP-3Tをベースにすることを確認した。^{[19] 2020年4月28日、}フィンランドが「Ketju」と呼ばれるDP-3Tのバージョンを試験運用していると発表された。 ^[20]ドイツでは、 SAP SEとドイツテレコムが、プロトコルの作成者団体の1つであるCISPAと共同で、 DP-3Tをベースに国家アプリを構築している。 ^[21] 2020年9月30日現在、DP-3Tを使用した接触追跡アプリは、オーストリア、ベルギー、クロアチア、ドイツ、アイルランド、イタリア、オランダ、ポルトガル、スイスにおいて利用可能となっている。 [ ^22]

DP-3T プロトコルは、クライアントを一意に識別する半ランダムなローテーション文字列である Ephemeral ID (EphID) に基づいて動作します。^[23] 2 つのクライアントが遭遇すると、EphID を交換し、ローカルのコンタクト ログに保存します。^[24]次に、ユーザーが感染の検査で陽性と判定されると、レポートが中央サーバーに送信されます。ネットワーク上の各クライアントは、サーバーからレポートを収集し、レポートに含まれる EphID がないか、ローカルのコンタクト ログを個別に確認します。一致する EphID が見つかった場合、ユーザーは感染患者と密接な接触があったことになり、クライアントから警告が送信されます。各デバイスはコンタクト ログをローカルで検証するため、コンタクト ログが第三者に送信されることはありません。そのため、中央レポート サーバーは、ネットワーク内のどのクライアントの ID またはコンタクト ログも独自に確認できません。これは、中央レポート サーバーがクライアントのコンタクト ログを受信して​​処理する PEPP-PT などの競合プロトコルとは対照的です。^[25]

TCNプロトコルとその一時連絡先番号と同様に、DP-3Tプロトコルは16バイトのエフェメラルID（EphID）を使用して、クライアントの近くにあるデバイスを一意に識別します。これらのEphIDは受信クライアントのデバイスにローカルに記録され、第三者に送信されることはありません。^[1]

EphID を生成するには、まずクライアントがを計算して毎日ローテーションする秘密鍵 ( )を生成します。ここで はSHA-256などの暗号化ハッシュ関数です。はEd25519などの標準の秘密鍵アルゴリズムによって計算されます。クライアントは日中にを使用してEphID のリストを生成します。1 日の初めに、クライアントは1 日を通してブロードキャストするサイズの新しい EphIDのローカル リストを生成します。ここで は EphID の有効期間 (分単位) です。悪意のある第三者が広い範囲で静的識別子をトレースして移動パターンを確立するのを防ぐため、EphID は頻繁にローテーションされます。秘密の日次鍵 が与えられると、各デバイスは を計算します。ここではグローバル固定文字列、はHMAC-SHA256のような疑似ランダム関数、 はバイトを生成するストリーム暗号です。このストリームは 16 バイトのチャンクに分割され、ランダムにソートされてその日の EphID が取得されます。^[1]${\displaystyle SK_{t}}$${\displaystyle SK_{t}=H(SK_{t-1})}$${\displaystyle H()}$${\displaystyle SK_{0}}$${\displaystyle SK_{t}}$${\displaystyle t}$${\displaystyle n=(24*60)/l}$${\displaystyle l}$${\displaystyle SK_{t}}$${\displaystyle S\_EphID(BK)=PRG(PRF(SK_{t},BK))}$${\displaystyle BK}$${\displaystyle PRF()}$${\displaystyle PRG()}$${\displaystyle n*16}$

DP-3T プロトコルは、他のユーザーとの近距離での接触を追跡して記録すること (デバイス ハンドシェイク) と、他のクライアントが感染患者と接触したかどうかを判断できるようにそれらの接触を報告すること (感染報告) という 2 つの別々の役割から構成されています。ほとんどのデジタル接触追跡プロトコルと同様に、デバイス ハンドシェイクではBluetooth Low Energy を使用してローカル クライアントの詳細を検索して交換し、感染報告段階ではHTTPS を使用してレポートを中央報告サーバーにアップロードします。さらに、他の分散型報告プロトコルと同様に、中央報告サーバーはクライアントの接触ログにアクセスすることはありません。レポートは、クライアントがレポートから個別に接触を導き出せるように構成されています。^[1]

デバイスの近くにあるクライアントを見つけて通信するために、プロトコルは Bluetooth LE のサーバー モードとクライアント モードの両方を利用し、これらを頻繁に切り替えます。^[26]サーバー モードでは、デバイスはクライアントが読み取れるように EphID をアドバタイズし、クライアントはサーバーをスキャンします。^[27]クライアントとサーバーが出会うと、クライアントは EphID を読み取り、その後、自身の EphID をサーバーに書き込みます。その後、2 つのデバイスは、大まかなタイムスタンプと信号強度に加えて、それぞれの接触ログに遭遇を保存します。信号強度は、感染報告プロセスの一部として、感染患者とユーザー間の距離を推定するために使用されます。^[1]

感染を報告する際には、地方保健当局が管理する中央報告サーバーが存在します。ユーザーが報告を提出する前に、保健当局はまず感染を確認し、クライアントが報告をアップロードすることを許可するコードを生成する必要があります。保健当局はさらに、患者に報告を開始する日（ と表記）を指示します。次に、クライアントはとのペアを中央報告サーバーにアップロードし、ネットワーク内の他のクライアントが後日ダウンロードします。元のEphIDを生成するために使用されたのと同じアルゴリズムを使用することで、クライアントは 過去および を含む期間に使用されたすべてのEphIDを再現し、それをローカルの接触ログと照合して、ユーザーが感染患者に近接していたかどうかを判断できます。^[1]${\displaystyle t}$${\displaystyle SK_{t}}$${\displaystyle t}$${\displaystyle t}$

プロトコル全体を通して、保健当局は接触記録にアクセスすることはなく、患者の検査と報告書の提出の承認のみを行う。^{[1] : p. 11}

ユーザーがDP-3Tアプリをインストールすると、疫学者とデータを共有するかどうか尋ねられます。ユーザーが同意した場合、感染患者との濃厚接触が確認されると、その接触を含むそれぞれの接触ログエントリが中央統計サーバーに送信される予定です。悪意のある第三者がこれらのアップロードを検出して潜在的な感染を発見するのを防ぐために、レポートは定期的に送信され、送信するデータがない場合には区別がつかないダミーレポートが送信されます。^[1]

別々の保健当局が管理するDP-3Tアプリ間の互換性を確保するため、アプリはユーザーが訪れた地域のローカルリストを維持しています。地域とは保健当局の管轄区域に直接対応する広いエリアのことで、正確な場所は記録されません。アプリはその後、これらの地域をそれぞれの海外中央報告サーバーに接続し、通常のホーム報告サーバーに加えてこれらのサーバーからレポートを取得します。アプリは、ユーザーが感染検査で陽性となった場合も、これらの海外報告サーバーにレポートを送信します。^[1]

暗号学とセキュリティの学者セルジュ・ヴォードネは、DP-3Tのセキュリティを分析して^[28]次のように主張した。

DP3T によるプライバシー保護対策の一部は、意図したものとは逆の効果をもたらす可能性があります。具体的には、病気や報告を受けた人々の匿名性が失われ、プライベートな接触が明らかになり、人々が収集した個人データを明らかにするよう強要される可能性があります。

— セルジュ・ヴォードネ、^{[28] ：p.1}

ヴォードネイの研究では、DP-3Tや類似のシステムに対する攻撃がいくつか紹介されている。これに対してDP-3Tグループは、ヴォードネイが紹介した12のリスクのうち、8つは集中型システムにも存在し、3つは機能せず、電話への物理的アクセスを伴う1つは機能するが軽減できると主張している。^[29] その後の研究^[30]で、ヴォードネイは集中型と分散型の両方の追跡システムに対する攻撃をレビューし、診断された人々の識別攻撃に言及して、次のように結論付けている。

集中型アーキテクチャと分散型アーキテクチャを比較すると、分散型システムに対する攻撃は検出不可能であり、大規模に実行でき、提案された対策はせいぜい限られたシナリオで攻撃を軽減できる程度であることがわかります。対照的に、集中型システムでは、アカウンティングと監査によって多くの対策が提供されます。

— セルジュ・ヴォードネ、^{[30] ：p.6}

同じ研究^[30]で、ヴォードネイは、集中型アプローチも分散型アプローチも十分なレベルのプライバシー保護を提供しないため、異なる解決策を検討すべきであると主張し、特に「第三の道」としてコントラコロナ^[31] 、エピオーネ^[32]、プロントC2 ^[33]システムを提案している。

タン^[34]は主要なデジタル接触追跡システムを調査し、DP-3Tがいわゆる「標的型識別攻撃」の対象となっていることを示している。

DP-3Tに対する理論的な攻撃はシミュレーションされており^[35]、自発的に識別子をアップロードしたDP-3Tシステムの最初のバージョンのユーザーを永続的に追跡することは、Bluetooth Low Energyデバイスの大規模な艦隊をインストールできる第三者にとって容易であることが示されています。この攻撃は、1日中のユーザーのリンク可能性を利用するため、英国で提案されたシステムなどの一部の集中型システムのすべてのユーザーに対して1日以内に可能ですが^[36]、感染したユーザーの識別子がキーやシードなどのコンパクトな表現を使用して送信されない「リンク不可能な」バージョンのDP-3Tでは機能しません。^[37]

• ブルートレース
• TCN プロトコル
• 汎欧州プライバシー保護近接追跡
• Google / Apple 接触追跡プロジェクト

• DP-3T ギットハブ