TCN プロトコル

一時連絡先番号プロトコル

開発者	TCN連合（Covid Watch [1]およびCoEpi [2]を含む）
紹介された	2020年3月17日[3] ( 2020-03-17 )
業界	暴露通知
物理的範囲	約10メートル（33フィート）[4]

一時連絡先番号プロトコル（TCNプロトコル）は、 COVID-19パンデミック[5]に対応してCovid Watch ^[1]によって開発されたオープンソースで分散型の匿名曝露アラートプロトコルです。^{[6] [ 7] [8]}スタンフォード大学とウォータールー大学の独立した研究協力として始まったCovid Watchチームは、3月初旬にこのトピックに関するブログ投稿^[11]を書いた後、 CoEpi ^[2]と共同で完全に匿名のBluetooth曝露アラート技術をホワイトペーパー^[9]を公開し、^[3]オープンソース化しました^[10]。

Covid WatchのTCNプロトコルは大きなニュース報道を受け^[12]、2020年4月初旬にはDP-3T、PACT、^[13]、Google/Apple Exposure Notification フレームワークなどの同様の分散型プロトコルが続きました。Covid Watchはその後、TCN CoalitionやMIT SafePaths ^[14]などの他のグループがオープンソースプロジェクト内でTCNプロトコルを実装するのを支援し、分散型技術の開発をさらに進め、接触追跡および曝露アラートアプリの世界的な相互運用性を促進しました。これは、広範な採用を達成するための重要な側面です。^[15] Covid Watchのボランティアと非営利団体のスタッフは、最初はTCNプロトコルを使用して、後に非常によく似たGoogle/Apple Exposure Notification Framework（ENF）を使用して、匿名の曝露アラートを送信するための完全にオープンソースのモバイルアプリも構築しました。^{[17] [ 18]}

このプロトコルは、BlueTraceやGoogle / Appleの接触追跡プロジェクトと同様に、Bluetooth Low Energyを使用して他のユーザーとの接触を追跡および記録します。^{[19] [20] [21]} TCNとBlueTraceなどのプロトコルの主な違いは、中央報告サーバーが接触ログにアクセスすることはなく、接触の処理とクライアントへの通知の責任も負わないことです。^{[22] [23]}接触ログは第三者に送信されることがないため、BlueTraceで使用されているようなアプローチに比べてプライバシー上の利点が大きくあります。^{[24] [25] [26]}ただし、このアプローチでは、その性質上、人間が関与する報告が許可されておらず、報告が公衆衛生機関によって検証されていない場合は誤検知につながる可能性があります。^{[19] : p. 6}

TCNプロトコルは、BlueTrace ^[29]、 Exposure Notificationフレームワーク、Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT)プロジェクト^{[30] [ 31 ]と並んで、最初に広くリリースされたデジタル接触追跡プロトコルの1つとして悪名を馳せました。また、}ブロックチェーン技術を取り入れていることでも際立っており、 ^[32] Google / Appleプロジェクトに影響を与えました。^{[33] [20] [34] [35] [36]}

TCN プロトコルは、シードから派生した半ランダムな識別子である Temporary Contact Numbers (TCN) に基づいて機能します。^[37] 2 つのクライアントが遭遇すると、一意の TCN が生成され、交換され、ローカルのコンタクト ログに保存されます。^[38]次に、ユーザーが感染の検査で陽性と判定されると、レポートが中央サーバーに送信されます。ネットワーク上の各クライアントは、サーバーからレポートを収集し、レポートに含まれる TCN がないか、ローカルのコンタクト ログを個別に確認します。一致する TCN が見つかった場合、ユーザーは感染患者と密接な接触があったことになり、クライアントから警告が送信されます。各デバイスはコンタクト ログをローカルで検証するため、コンタクト ログが第三者に送信されることはありません。そのため、中央レポート サーバーは、ネットワーク内のどのクライアントの ID またはコンタクト ログも独自に確認できません。これは、中央レポート サーバーがクライアントのコンタクト ログを受信して​​処理する BlueTrace などの競合プロトコルとは対照的です。^[39]

プロトコル全体は、クライアント デバイスのシード値から決定論的に生成される一意で匿名の 128 ビット識別子である一時連絡先番号(TCN) の原理に基づいています。TCN は、ユーザーが接触した人物を識別するために使用され、シードは、中央レポート サーバーに感染を簡潔にレポートするために使用されます。TCN レポートは、クライアントのみが保持する秘密によって本物であることが認証されます。

TCN を生成するには、まず、署名方式の署名鍵と検証鍵 (RAK-RVK ペア) として、レポート認証鍵(RAK)とレポート検証鍵 (RVK) を作成します。リファレンス実装では、このペアはEd25519署名方式を使用して作成されます。^{[40] : 行。13}次に、RAK を使用して、アルゴリズム、SHA -256ハッシュ関数、を使用して初期の一時コンタクト キー(TCK) が生成されます。この TCK は TCN の生成には使用されませんが、次の TCK で使用されます。以降のすべての TCK は、アルゴリズム 、を使用して計算されます。次に、アルゴリズム 、指定された TCK から 128 ビットの TCN が生成されます。これは、 指定された数値をリトルエンディアンの符号なし 2 バイト整数としてフォーマットし、^[41]、SHA-256 ハッシュ関数 、です。次の図は、キー導出プロセスを示しています。${\displaystyle tck_{0}=H\_tck(rak)}$${\displaystyle H\_tck()}$ ${\displaystyle H\_tck(s)=SHA256({\text{b'H}}\_{\text{TCK'}}||s)}$${\displaystyle tck_{i}=H\_tck(rvk||tck_{i-1})}$${\displaystyle tcn_{i>0}=H\_tcn(le\_u16(i)||tck_{i})}$${\displaystyle le\_u16()}$${\displaystyle H\_tcn()}$${\displaystyle H\_tcn(s)=SHA256({\text{b'H}}\_{\text{TCN'}}||s)[0:128]}$

TCN は各デバイスの遭遇ごとに固有であり、RAK-RVK ペアは定期的に循環され、クライアントが特定の期間の接続のみを報告できるようにします。

クライアントが TCN インデックスのレポートを に送信する場合、レポートは として構造化されます。次に、RAK を使用して署名が計算され、 としてサーバーに送信されます。 ${\displaystyle s>0}$${\displaystyle e}$${\displaystyle report=rvk||tck_{s-1}||le\_u16(s)||le\_u16(e)||memo}$${\displaystyle s\_report=report||sig}$

与えられた TCK はどれも、同等かそれ以上のインデックスの TCN を導出するためにしか使用できないため、 を提出することによって、より前のエンカウンターは計算できなくなります。ただし、同じ RAK-RVK ペアを使用して計算されるエンカウンターの数に上限はないため、これらは頻繁に循環されます。クライアントが未使用の TCN を計算しないようにするために、は、与えられたRVK で生成された最後の TCN インデックスを示します。^{[42] ：行 49～61}さらに、RVK は TCK の計算に使用され、 が提供されているため、報告期間内の有効な TCN は不正な報告から導出できません。一致しない RVK と から計算できる唯一の正しい TCN は、報告期間の開始前の TCN です。${\displaystyle tck_{s-1}}$${\displaystyle tcn_{s-1}}$${\displaystyle e}$${\displaystyle tck_{s-1}}$${\displaystyle tck_{s-1}}$${\displaystyle tcn_{s-1}}$

レポートを受信すると、クライアントは元のアルゴリズムを使用して、特定の期間の TCK と TCN を個別に再計算します。これは、クライアント デバイスがローカルの接触ログをチェックして感染患者との潜在的な接触を確認するために使用されますが、誤ったレポートでは一致する TCN が生成されないため、レポートを検証できるという 2 つの利点があります。 $${\displaystyle {\begin{array}{lcr}tck_{s}=H\_tck(rvk||tck_{s-1})\\tcn_{s}=H\_tcn(le\_u16(s)||tck_{s})\\tck_{s+1}=H\_tck(rvk||tck_{s})\\tcn_{s+1}=H\_tcn(le\_u16(s+1)||tck_{s+1})\\...\\tck_{e}=H\_tck(rvk||tck_{e-1})\\tcn_{e}=H\_tcn(le\_u16(e)||tck_{e})\end{array}}}$$

レポート構造では、メモは TCN 実装間で異なる自由形式のメッセージのためのスペースです。セクションは 2 ～ 257 バイトで、特定の実装を識別するタグと、データおよびデータ長のペアで構成されます。形式は です 。データはさまざまなタグに対して標準化されており、次のようになります。 ${\displaystyle memo=tag||len(data)||data}$

このプロトコルは、TCN アプリを実行する 2 つのデバイス間のエンカウンターと、患者と接触したユーザーへの潜在的な感染の通知という 2 つの役割に分けられます。この仕様では、これらの領域をエンカウンター ハンドシェイクと感染報告と呼んでいます。エンカウンター ハンドシェイクはBluetooth LE 上で実行され、2 つのデバイスが互いの存在を確認する方法を定義します。感染報告はHTTPS上に構築され、クライアント間で感染通知を配布する方法を定義します。

2つのデバイスが互いの範囲内に入ると、TCNを含むハンドシェイクを交換します。これを実現するために、エンカウンターハンドシェイクは、ブロードキャスト指向とコネクション指向の2つのモード（それぞれに2つのサブモードがあります）で動作します。ブロードキャスト指向は、ブロードキャストモードとオブザーバーモードを使用して動作し、コネクション指向は、ペリフェラルモードとセントラルモードを使用して動作します。この2つのモードは、特にバージョン13.4より前のiOS制限に関して、特定のデバイス制限を回避するために使用されます。^[43]どちらのモードでも、プロトコルは16ビットのUUID 0xC019で識別されます。

ブロードキャスト モードでは、ブロードキャスターはアドバタイズ データのサービス データ フィールドを使用して 16 バイトの TCN をアドバタイズします。オブザーバーはこのフィールドから TCN を読み取ります。コネクション指向モードでは、ペリフェラルは UUID を使用してアドバタイズします。サービスは、TCN を共有するための読み取りおよび書き込み可能なパケットを公開します。TCN を共有した後、セントラルはペリフェラルから切断されます。

ユーザーが感染の検査で陽性と判定された場合、過去 14 日間の接触を計算できる署名済みのレポートを中央サーバーにアップロードします。クライアント デバイスは定期的にサーバーからレポートをダウンロードし、検証アルゴリズムを使用してローカルの接触ログを確認します。一致する記録がある場合、アプリはユーザーに感染の可能性を通知します。

2020年4月5日、Covid Watchと他のグループによって、本質的に同じアプローチと大部分が重複するプロトコルを中心に結成されたグローバルTCN連合が設立されました。その目的は、断片化を減らし、追跡および警告アプリの世界的な相互運用性を実現することです。これは、広範な導入を達成するための重要な側面です。^[44] TCN連合は、デジタル接触追跡および警告のデータ権利フレームワークの確立にも貢献しました。これは、そのようなアプリのユーザーの権利章典として機能します。^[45]

現在、このプロトコルはTCN連合のメンバーであるCoEpi ^{[46] [47]}とCovid Watch ^{[48] [22]}によって使用されており、同様のGoogle / Appleの接触追跡プロジェクト^{[35] [34]}のインスピレーションの源となった可能性が高い。

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

• Covid Watch 2020-04-17ウェイバックマシンにアーカイブされました
• TCN連合は2021年7月4日にWayback Machineにアーカイブされました
• 仕様とリファレンス実装