JP2023524829A - 匿名近接追跡の改善されたコンピュータ実施方法 - Google Patents

匿名近接追跡の改善されたコンピュータ実施方法 Download PDF

Info

Publication number
JP2023524829A
JP2023524829A JP2022567689A JP2022567689A JP2023524829A JP 2023524829 A JP2023524829 A JP 2023524829A JP 2022567689 A JP2022567689 A JP 2022567689A JP 2022567689 A JP2022567689 A JP 2022567689A JP 2023524829 A JP2023524829 A JP 2023524829A
Authority
JP
Japan
Prior art keywords
token
encounter
participating
participating device
list
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2022567689A
Other languages
English (en)
Inventor
カステルチア，クロード
ポワンシュヴァル，ダヴィド
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Centre National de la Recherche Scientifique CNRS
Institut National de Recherche en Informatique et en Automatique INRIA
Original Assignee
Centre National de la Recherche Scientifique CNRS
Institut National de Recherche en Informatique et en Automatique INRIA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Centre National de la Recherche Scientifique CNRS, Institut National de Recherche en Informatique et en Automatique INRIA filed Critical Centre National de la Recherche Scientifique CNRS
Publication of JP2023524829A publication Critical patent/JP2023524829A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3066—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy involving algebraic varieties, e.g. elliptic or hyper-elliptic curves
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/047—Key management, e.g. using generic bootstrapping architecture [GBA] without using a trusted network node as an anchor
    • H04W12/0471—Key exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Physics & Mathematics (AREA)
  • Pure & Applied Mathematics (AREA)
  • Mathematical Optimization (AREA)
  • Computing Systems (AREA)
  • Mathematical Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • Algebra (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

匿名近接追跡のコンピュータ実施方法であって、ａ）それぞれが、秘密鍵生成器と非対話型鍵交換プロトコルパラメータとを含む非対話型鍵交換プロトコルインタフェースを有する、無線通信が可能な複数の参加デバイス２を提供するステップと、ｂ）参加デバイスのそれぞれにおいて秘密鍵生成器を周期的に用いてそれぞれの現在の秘密鍵を取得し、それぞれの現在の秘密鍵及び非対話型鍵交換プロトコルパラメータに基づいて、参加デバイスのそれぞれにおいてそれぞれの現在の公開鍵を計算するとともに、参加デバイスのそれぞれが、周期的に無線でそれぞれの現在の公開鍵をブロードキャストするステップと、ｃ）第２の参加デバイスによってブロードキャストされたそれぞれの現在の公開鍵を第１の参加デバイスが検出すると、第１の参加デバイス及び第２の参加デバイスのそれぞれにおいて、ｉ．非対話型鍵交換プロトコルパラメータと、第１の参加デバイス及び第２の参加デバイスのそれぞれの現在の秘密鍵とによって定義される現在の共有秘密を計算するステップと、ｉｉ．現在の共有秘密を用いてパラメータ化され、バケット値に適用された擬似ランダム関数を用いて少なくとも１つのトークンを計算するステップと、ｉｉｉ．第１の参加デバイス及び第２の参加デバイスの双方に既知である２つの入力を用いて、全順序関数を適用することによって求められるソート値を計算するとともに、ソート値に基づいて、第１の参加デバイスの第１の遭遇トークンリスト及び第２の参加デバイスの第２の遭遇トークンリストに第１のトークンを記憶し、第１の参加デバイスの第２の遭遇トークンリスト及び第２の参加デバイスの第１の遭遇トークンリストに第２のトークンを記憶するステップ、又は、第１の参加デバイスの第２の遭遇トークンリスト及び第２の参加デバイスの第１の遭遇トークンリストに第１のトークンを記憶し、第１の参加デバイスの第１の遭遇トークンリスト及び第２の参加デバイスの第２の遭遇トークンリストに第２のトークンを記憶するステップと、ｄ）所与の参加デバイスが、所与の参加デバイスによるアップロード条件の検出時に、第１の遭遇トークンリスト又は第２の遭遇トークンリストのうちの一方の少なくとも一部を近接管理サーバに選択的にアップロードするステップとを含んでなる、匿名近接追跡のコンピュータ実施方法を提供する。【選択図】図１

Description

本発明は、近接追跡の分野に関し、より詳細には、匿名近接追跡（anonymous proximity tracing）のコンピュータ実施方法に関する。
モバイルデバイスの急増及び低エネルギープロトコルの発展に伴い、近接追跡は、顕著な発展分野の１つになっている。ビーコン（beacon）の出現とともに、多くの技術的事例が小売業界及び物流業界等から生じた。ＣＯＶＩＤ１９パンデミックの発生は、この傾向を強化したにすぎない。
全ての近接追跡アプリケーションに伴う最も大きな課題は、情報の品質と、不正使用を防ぐためにプライバシを保証することの絶対的な必要性とのバランスを取ることである。これは、２つの主要な手法の発展につながった。
一方は、通常、「集中型」（centralized）と呼ばれるのに対し、他方は、通常、「分散型」（decentralized）と呼ばれる。この区別は、サーバが存在するか否かに基づく。最初の反応（reflex）では、「サーバレス（又は、ほぼサーバレス）」がプライバシ面でより安全とみなされる場合があるものの、極めて直観に反することに、これらの解決策は、ユーザ群全体にわたる全てのユーザの全てのデータを複製するため、実際にはより危険であり、ほとんどのユーザに大量の無関係なデータを送信することを必要とするため、データを大量にどころか実際に膨大に消費する。
このため、本出願人は、サーバがユーザから最終的に或る種の情報を収集する「集中型」手法を検討した。第１の手法として、本出願人は、https://github.com/ROBERT-proximity-tracing/documentsからアクセス可能な２０２０年４月１８日に公開された論文である非特許文献１において、「ＲＯＢＥＲＴ」（ROBust and privacypresERving proximity Tracing）という名称の匿名近接追跡方法を提案した。
ＲＯＢＥＲＴ１．０は、集中化サーバによるユーザへの一時識別情報の割当て、他のユーザのデバイスがこの一時識別情報を保有するユーザのデバイスに近接したときの、この他のユーザによるこの一時識別情報の記憶、及びＣＯＶＩＤ１９と診断されたときの、ユーザによる「近接接触した一時識別情報」（met in proximity temporary identifications）のリストのアップロードに頼った。このようにして、集中化サーバは、ユーザに関する個人データを一切記憶せず、ユーザは、自身の一時識別情報のうちの１つが集中化サーバ上にリストされているか否かをチェックすることによって、ＣＯＶＩＤ１９陽性者と近接したことを認識することができる。
この方法は、興味深いが、特に、プロトコルにおけるサーバの役割を低減し、これを可能な限り「サーバレス（又は、ほぼサーバレス）」にするために、改善の余地がある。
"ROBERT: ROBust and privacypresERving proximity Tracing", published on April 18, 2020
本発明は状況の改善を目的とする。このために、本出願人は、匿名近接追跡のコンピュータ実施方法であって、
ａ）それぞれが、秘密鍵生成器と非対話型鍵交換プロトコルパラメータとを含む非対話型鍵交換プロトコルインタフェースを有する、無線通信が可能な複数の参加デバイスを提供するステップと、
ｂ）前記参加デバイスのそれぞれにおいて前記秘密鍵生成器を周期的に用いてそれぞれの現在の秘密鍵を取得し、前記それぞれの現在の秘密鍵及び前記非対話型鍵交換プロトコルパラメータに基づいて、前記参加デバイスのそれぞれにおいてそれぞれの現在の公開鍵を計算するとともに、前記参加デバイスのそれぞれが、周期的に無線で前記それぞれの現在の公開鍵をブロードキャストするステップと、
ｃ）第２の参加デバイスによってブロードキャストされたそれぞれの現在の公開鍵を第１の参加デバイスによって検出すると、前記第１の参加デバイス及び前記第２の参加デバイスのそれぞれにおいて、
ｉ．前記非対話型鍵交換プロトコルパラメータと、前記第１の参加デバイス及び前記第２の参加デバイスの前記それぞれの現在の秘密鍵とによって定義される現在の共有秘密（current shared secret）を計算するステップと、
ｉｉ．前記現在の共有秘密を用いてパラメータ化され、前記第１の参加デバイスに関係する第１の値に適用された擬似ランダム関数（pseudo-random function）を用いて第１のトークンを計算するとともに、前記現在の共有秘密を用いてパラメータ化され、前記第２の参加デバイスに関係する第２の値に適用された前記擬似ランダム関数を用いて第２のトークンを計算するステップと、
ｉｉｉ．前記第１の参加デバイス及び前記第２の参加デバイスの双方に既知である２つの入力を用いて、全順序関数（total ordering function）を適用することによって求められるソート値を計算するとともに、前記ソート値に基づいて、前記第１の参加デバイスの第１の遭遇トークンリスト及び前記第２の参加デバイスの第２の遭遇トークンリストに前記第１のトークンを記憶し、前記第１の参加デバイスの前記第２の遭遇トークンリスト及び前記第２の参加デバイスの前記第１の遭遇トークンリストに前記第２のトークンを記憶するステップ、又は、前記第１の参加デバイスの前記第２の遭遇トークンリスト及び前記第２の参加デバイスの前記第１の遭遇トークンリストに前記第１のトークンを記憶し、前記第１の参加デバイスの前記第１の遭遇トークンリスト及び前記第２の参加デバイスの前記第２の遭遇トークンリストに前記第２のトークンを記憶するステップと、
ｄ）所与の参加デバイスが、該所与の参加デバイスによるアップロード条件の検出時に、前記第１の遭遇トークンリスト又は前記第２の遭遇トークンリストのうちの一方の少なくとも一部を近接管理サーバ（proximity management server）に選択的にアップロードするステップと
を含んでなる方法を提案する。
前記方法は、近接サーバが近接対話の結果の最終リポジトリとしてのみ用いられるため有利である。さらに、トークンの性質に起因して、近接サーバは、ユーザ及びユーザのデバイスにとって完全に匿名（ブラインド：blind）であり、トークンの生成に関与する２つのデバイスのみが、互いを認識しない状態のまま、これに関係することができる。無関係なデータはユーザに拡散されず、ユーザは、自身の近接遭遇のみを反映する匿名化データのみを記憶する。最後に、公開鍵は、各デバイス内においてローカルで生成されるため、結果として得られるプロトコル（「ＲＯＢＥＲＴ ｖ２」）は、「サーバレス（又はほぼサーバレス）」とみなすことができ、分散型とみなすことさえできる。
様々な実施の形態において、前記方法は、以下の特徴のうち１つ以上を提供することができる。
前記全順序関数は、前記第１の参加デバイス及び前記第２の参加デバイスの前記それぞれの現在の公開鍵から導出された値を比較することによって前記ソート値を計算し、
ステップｄ）は、前記第１の遭遇トークンリストからトークンをアップロードすることを含み、
前記方法は、
ｅ）前記参加デバイスごとに、前記第２の遭遇トークンリストからの少なくとも１つのトークンを報告サーバに周期的に送信し、前記報告サーバは、別の参加デバイスが当該別の参加デバイスの第１のトークン遭遇リストから、前記第２の遭遇トークンリストからの前記少なくとも１つのトークンと同一のトークンをアップロードしたことを検出すると、前記第２の遭遇トークンリストを前記報告サーバに発した前記参加デバイスに、前記同一のトークンをアップロードしたことの検出を示すメッセージを送信するステップを更に含み、
前記方法は、
ｆ）前記参加デバイスごとに、前記第２の遭遇トークンリストからの少なくとも１つのトークンを前記報告サーバに周期的に送信し、前記第２の遭遇トークンリストからの前記少なくとも１つのトークンと、他の参加デバイスによって前記第１の遭遇トークンリストからアップロードされた前記トークンとの比較に基づいて、リスクスコアを計算するステップを更に含み、
前記非対話型鍵交換プロトコルは、Ｃｕｒｖｅ２５５１９、別の楕円曲線、楕円曲線ディフィ－ヘルマンプロトコル（Elliptic-curve Diffie-Hellman protocol）又はディフィ－ヘルマン鍵交換（Diffie-Hellman key exchange）に基づき、
前記第１の参加デバイス及び前記第２の参加デバイスのコロケーション（colocation）に関するメタデータが、前記第１の遭遇トークンリスト及び前記第２の遭遇トークンリストのうちの一方において、前記第１のトークン及び前記第２のトークンとともに記憶される。
本発明はまた、本発明による方法を実行する命令を含むコンピュータプログラムと、前記コンピュータプログラムを記録したデータストレージ媒体と、請求項に記載の前記コンピュータプログラムを記録したメモリに結合されたプロセッサを備えるコンピュータシステムとに関する。
本発明の他の特徴及び利点は、以下の図面の説明において容易に明らかとなる。図面は、本発明の例示的な実施形態を示す。
本発明による方法を実施するシステムの概略図である。 本発明による方法を実施する２つのデバイス間の交換の全体図である。 図２に続くデータ交換を示す時間図である。
図面及び以下の説明は、ほとんどの部分が、有益で明確に定義された特徴から構成される。結果として、これらは本発明を理解するのに有用であるのみでなく、需要が生じたときに用いて本発明の定義に寄与することもできる。
本明細書は、著作権によって保護された又は保護可能な要素を参照又は使用する場合がある。本出願人は、必要な法的公開物に制限される限り、これらの要素の複製に対して異議を有しないが、これは、権利又はいかなる形態のライセンスの放棄ともみなされるべきでない。
新たなバージョンは同じアーキテクチャを用いるが、主要な改善をもたらす。特に、これは、秘密の暗号で生成されたプライベート遭遇トークン（ＰＥＴ：Private Encounter Token）の概念を提示する。さらに、Ｂｌｕｅｔｏｏｔｈインタフェース上でブロードキャストされる一時的な識別子は、ここではモバイルデバイスによって生成され、ユーザに更なる制御をもたらす。最後に、サーバによって記憶される全てのデータは、ここではモバイルデバイスに記憶される鍵を用いて暗号化され、サーバにおけるデータ漏えいに対し保護される。これらの全ての変更により、悪意のあるユーザ及び機関に対するスキームプライバシが劇的に改善する。ＲＯＢＥＲＴの最初のバージョンにおけるように、リスクスコア及び通知は、依然としてサーバによって、したがって、保健機関によって管理及び制御され、これにより高いロバスト性、柔軟性及び効率性が提供される。
１ 序論
１．１ プライベート遭遇トークン（ＰＥＴ）
既存の近接追跡スキームとは異なり、本発明者らは、「短期Ｂｌｕｅｔｏｏｔｈ識別子」（ＥＢＩＤ：Ephemeral Bluetooth Identifiers）から生成されたプライベート遭遇トークン（ＰＥＴ）に基づく曝露通知システム（exposure notification system）を提案する。ＥＢＩＤ及びＰＥＴは、モバイルデバイスによってローカルで生成及び計算され、リンク付け不可能である。ＰＥＴは、２つのノード間の遭遇を識別し、これらのノードだけの秘密である（他の誰もこれを計算することはできない）。ＰＥＴの作成は、ディフィ－ヘルマン（Diffie-Hellman：以後、「ＤＨ」）鍵交換プロトコルに基づく。
単純にし、読むのを容易にするために、以下では乗法ＤＨ表記（multiplicative DH notation）に言及する。しかしながら、効率性の理由から、これをＣｕｒｖｅ２５５１９（Ｃｕｒｖｅ２５５１９の詳細は、https://en.wikipedia.org/wiki/Curve25519において得ることができる）を用いた（楕円曲線ディフィ－ヘルマン（Elliptic-curve Diffie-Hellman）又はＥＣＤＨとしても知られている）楕円曲線における離散対数のインスタンスを用いて実施することを提案する。本発明者らは、デバイスが、アプリケーションにおいて予め構成することができる同じグループ構造（順序ｐ及び生成器ｇ）を共有することを仮定する。
各エポックｉにおいて、
・デバイスＸは、ｇＸｉとして定義された新たなＥＢＩＤを生成及びブロードキャストする。ここで、Ｘｉは、Ｘによって生成される秘密である。楕円曲線暗号法及び楕円曲線Ｃｕｒｖｅ２５５１９を用いると、ｇＸｉは３２バイトを必要とする。これは２つの連続Ｂｌｕｅｔｏｏｔｈパケットにおいて送信される（以下のセクション５．３を参照されたい）。
・デバイスＹｉからＥＢＩＤ、ｇＹｉを受信すると、デバイスＸは、Ｋ＝ｇＸｉ＊Ｙｉを計算し、これをローカルリストに記憶し、ＰＥＴ Ｈ（Ｋ）を得る。ここで、Ｈ（）は、ＳＨＡ－２５６等の暗号化ハッシュ関数である。このＰＥＴは、ＸとＹとの遭遇のための一意の秘密識別子である。
・ＰＥＴ Ｈ（Ｋ）は、Ｘ及びＹによってのみ計算することができ、したがって、盗聴者（eavesdroppers）から保護される。これは、決定的ディフィ－ヘルマン（ＤＤＨ）仮定によって保証される。ＰＥＴは、異なる個人から到来するコロケーション情報をリンクするサーバの能力を低減するという、ＥＢＩＤを上回る利点を有する。さらに、この方法は、悪意のある個人が感染した（又は感染した可能性がある）個人によって受信されたＥＢＩＤを収集し、これを多くのロケーションにおいてリプレイし、これにより大量の偽陽性を生成する「リプレイ攻撃」（replay attack）を軽減する。
ＰＥＴトークンがパンデミック用途に特有のものではなく、全ての他の既存の近接追跡提案に利益をもたらし得ることは注目に値する。
１．２ プロトコル概観
本明細書において用いられる全ての表記は以下の表１に要約される。提案されるシステムは、図１に示され、ＲＯＢＥＲＴ ｖ２を用いる曝露通知アプリケーション（「Ａｐｐ」と称される）をインストールするユーザ２と、保健機関の制御下にあるバックエンドサーバ４（以下で報告サーバと呼ばれる）とを含む。サーバは既知のドメイン名、証明書を用いて構成され、高度にセキュア化されていることが仮定される。
Figure 2023524829000002
サーバとの全ての通信は、（ユーザを再識別するためにサーバによって利用され得るユーザのネットワークメタデータを隠すために）プロキシを通じて行われる。Ａｐｐは、少なくとも以下の４つの手順を通じてシステムと対話する。
・初期化：ユーザは、サービスの使用を望むとき、公式の信頼されたＡｐｐストアからアプリケーションＡｐｐをインストールする。そして、Ａｐｐは、永久識別子（ＩＤ）を生成するサーバ４に登録する。ＩＤＴａｂｌｅ（表１を参照）は、登録されたＩＤごとにエントリを保持する。記憶された情報は、「識別解除」（de-identified）され、特定のユーザに決して関連付けられない。換言すれば、個人情報はＩＤＴａｂｌｅに記憶されない。
・近接発見：サービスに登録した後、各デバイスＡは、
・各エポックにおいて新たなリンク付け不可能なＥＢＩＤＡを生成し、
・このＥＢＩＤＡを定期的にブロードキャストし、
・遭遇したデバイスのＥＢＩＤを収集し、
・或る特定の条件、例えば、接触長、受信信号強度等が満たされる場合、収集したＥＢＩＤからＰＥＴトークンを生成し、
・１つ以上のローカルリストに、必要な場合追加のメタデータ（接触長、速度、．．．）とともに、生成されたＰＥＴトークンを記憶する。
・感染ユーザ宣言：個人が検査され、ＣＯＶＩＤ１９陽性であると診断されるとき、並びに明示的なユーザ同意及び（例えば医療サービスからの）認証の後、ユーザのスマートフォンのＡｐｐが自身のローカルリストを機関のサーバ（以後、報告サーバ）にアップロードし、報告サーバがこれらを曝露ＰＥＴトークンのグローバルリストＥＬｉｓｔに加える。
・曝露ステータス要求：Ａｐｐは、ＰＥＴトークンの自身のリストを用いて報告サーバを定期的にプローブすることによって、自身の関連ユーザの「曝露ステータス」（exposure status）を問い合わせる（プルメカニズム）。そして、報告サーバは、ＥＬｉｓｔにＡｐｐのトークンのうちのいくつが現れるかをチェックし、この情報（並びに場合によっては曝露持続時間及び信号強度等の他のパラメータ）からリスクスコアを計算する。このスコアが所与の閾値よりも大きい場合、ビット「１」（「曝露のリスクがある」と同義）がＡｐｐに返送され、そうでない場合、ビット「０」が返送される。メッセージ「１」の受信時、従うべき指示（例えば、検査のために病院へ行く、特定の電話番号にかける、隔離施設に滞在する等）を示す通知をＡｐｐのユーザに送信することができる。
図２は、上記で説明した近接発見の手順中に行われる交換の概略図を示し、以下のセクション２．２においてより詳細に説明される。
まず、デバイスＡはＥＢＩＤ＝ｇＡをブロードキャストし、デバイスＢはＥＢＩＤ ｇＢをブロードキャストする。そして、ＥＢＩＤ ｇＢを検出すると、デバイスＡは、ＰＥＴ１＝Ｈ（「１」｜ｇＢ＊Ａ）及びＰＥＴ２＝Ｈ（「２」｜ｇＢ＊Ａ）を検出し、ＰＥＴ１をＲＴＬＡに記憶し、ＰＥＴ２をＥＴＬＡに記憶する。デバイスＢは、ＰＥＴ１＝Ｈ（「１」｜ｇＡ＊Ｂ）及びＰＥＴ２＝Ｈ（「２」｜ｇＡ＊Ｂ）を計算し、ＰＥＴ２をＥＴＬＢに記憶し、ＰＥＴ１をＲＴＬＢに記憶する。様々な実施形態によれば、ＰＥＴ１をＥＴＬＡ又はＲＴＬＡ（それぞれＥＴＬＢ又はＲＴＬＢ）に記憶することは、以下で更に説明されることになる、ソート値の決定に依拠することができる。
ＲＯＢＥＲＴ ｖ２プロトコルは、全てのスマートフォン及びサーバが（ネットワーク時間プロトコルを表すＮＴＰ、又はセルラモバイルフォンネットワーク情報又はＧＰＳ時間情報等のような他の時間同期メカニズムにより）緩く時間同期していると仮定する。時間は、ＮＴＰ「秒」値として表され、これは、時代０（era 0）について、ＵＴＣ１９００年１月１日０時からの秒数を表す。時間は、（例えば、１５分であるが、近接発見プロトコル及び追求される用途、すなわち、検出された遭遇に付加される意味に依拠して他の値が考えられ得る）エポックに離散化される。以下において、変数「ｅｐｏｃｈ＿ｄｕｒａｔｉｏｎ＿ｓｅｃ」は、秒単位のエポックの持続時間を指定する。本明細書に記載の例において、エポックは、ＭＡＣアドレスランダム化期間と同期される。
１．３ リスクスコアリング及び通知検討
特定の有効なリスクスコアリングは本明細書の範囲外である。ここで説明される例において、（１）サーバが、ユーザにリスクがあるか否かをユーザに通知するバイナリ返答を返すこと、及び（２）返答が計算されたリスクスコア値のみに基づくことが仮定される。これらの２つの仮定が論考される必要がある。いくつかの理由から、バイナリ情報の代わりに確率値を返すことが有用であり得る。さらに、クエリ返答メカニズムにおいていくらかのランダム性を加えることにより、プライバシを改善することができる（以下のセクション５．２を参照されたい）。
リスク評価アルゴリズム及びそのパラメータは、保健機関によって、疫学者と協力して定義及び監視されるべきであることが更に仮定される。パンデミック用途の場合、機関がアルゴリズム及びそのパラメータを経時的に適応させることができることも最も重要である。これらの調節は、状況の発展、特に、曝露された人物の数と、感染した人物の数と、利用可能なリソースと、ウィルス及びその拡散を理解するために疫学研究によってなされた進展とを考慮に入れる必要がある。実際に、近接追跡アプリケーションの主要な成功要因は、既存のヘルスケアインフラストラクチャ内のスムーズな統合であり、特に、応答を局所的な疫学的状況及び利用可能なリソースに適応させることが可能であることである。これは、曝露リスクスコア及び通知が報告サーバによって管理されるシステムを必要とする。同じことは、小売業界又は物流業界に関する他の技術的事例にも当てはまる。
本明細書に提示される手法の主な推進力（driver）は、この手法が、保健サービスにデータの分析を行わせ、感染を受けたリスクが最も高い人物にのみ警告を送信させることである。
主要な課題は、既存の近接追跡フレームワーク内でのアラートの後続の管理（手動の接触追跡、検査、隔離等も含む）である。インフラストラクチャが全ての警告に対処するのに十分な規模及び装備を有していない場合、近接追跡アプリケーションは、（個人へのケアの欠如に起因して）役に立たず、不安を煽るもの、及び（エッセンシャルワーカの迅速であるが不要な撤退を通じて）経済的に壊滅させるものとなり得る。リスク評価及び通知に対する「集中型」手法により、ユーザからのパニック反応又は関心若しくは信頼の喪失のいずれかにつながり得る過剰な警告を回避することが可能になる。
サーバの中心的役割の別の利点は、感染したユーザを特定しようとする攻撃者に対するシステムの耐性を増大させることである。要約すると、デジタル近接追跡ツールは、公共保健政策の１つの要素として展開されるべきであり、公共保健機関の制御下で他の既存の手段との相乗効果で機能するべきである。これは、真に非集中的な手法と不適合であるように見える、任意の実際のパンデミック又はヘルスケア関連曝露通知解決策の本質的な機能要件である。より正確には、例として、リスク計算アルゴリズムがユーザのデバイスにおいて計算される非集中的手法において、保健機関は、曝露した人物の数を認識していない。この情報は単独で、統計目的、及びリスク計算アルゴリズムを実際的な方式において調整することを可能にすることの双方にとって重要である。
２ ＲＯＢＥＲＴ ｖ２プロトコル説明
２．１ アプリケーション初期化
自身のデバイスにアプリケーションをインストールすることを望むユーザ２は、これを公式Ａｐｐｌｅ又はＧｏｏｇｌｅ Ｐｌａｙ Ｓｔｏｒｅｓからダウンロードしなくてはならない。アプリケーションＡｐｐＡをインストールした後、ユーザ２はバックエンドサーバに登録する必要がある。
登録段階は、２つの段階、すなわち、ユーザが匿名認証トークンを得る認証トークン生成と、ユーザが匿名でサーバに登録するユーザ登録とから構成される。
後述するように、これらの段階は、リンク付け不可能であり、ユーザに完全な匿名性を提供する。
１．認証トークン生成：ステップは、ユーザによって、ユーザ登録及び曝露ステータス要求段階において用いられる匿名認証トークンを得るために用いられる。これは、以下のセクション５．１において説明するように、ブラインド署名を用いることによって行うことができる。ユーザは、（Ｓｙｂｉｌ攻撃を制限するために、スマートフォンあたり１つのアプリケーションＡｐｐしか存在しないことを検証するように）自身の電話番号を明らかにするが、サーバは、ユーザの電話番号を生成された認証トークンとリンク付けすることができないことに留意されたい。
２．ユーザ登録：ユーザ２は、認証トークンＡＴＡを得ると、これをサーバに登録することができる。これは以下のように行うことができる。
ａ）ユーザ２は、自身の認証トークンＡＴＡを含む登録メッセージを送信する。
ｂ）サーバは、認証トークンを検証し、一意の識別子ＩＤＡ及びそのＩＤＴａｂｌｅにおけるエントリを作成する。本明細書に記載の例において、エントリテーブルは、登録されたユーザごとに、以下の情報を含む。
－ＩＤＡ（「Ａの永久識別子」（Permanent IDentifier for A））：各登録されたＡｐｐに一意であり、ランダムに生成される識別子（衝突を避けるために交換なしのランダム抽出プロセス）。
－ＵＮＡ（「通知されたユーザＡ」（User A Notified））：このフラグは、関連ユーザが既に曝露のリスクにあることを通知された（「真」の関連値）か否か（「偽」の関連値）を示す。ＵＮＡは値「偽」を用いて初期化される。
－ＳＲＥＡ（「ステータス要求エポック」（ＳＲＥ：Status Request Epoch））：ユーザ２が「ステータス要求」を送信した最後のエポックを示す整数。
－ＬＥＰＭＡ（曝露ＰＥＴメタデータのリスト（ＬＥＰＭ：List of Exposed PET Metadata））：このリストは、ユーザの曝露（時間及び周波数情報）を反映し、リスクスコアを計算するのに必要なメタデータ（例えば、ＣＯＶＩＤ１９陽性と診断された人物への接触の持続時間及び近接性）を記憶するのに用いられる。プロトコルのこのバージョンにおいて、各要素は、ユーザがＣＯＶＩＤ１９陽性と診断されたユーザと接触した日付、及びその遭遇の持続時間を符号化する。このリストに含まれる情報は、環境（屋内又は屋外）、信号強度、．．．に関する情報等のリスクスコアを計算するのに有用な他のタイプのデータを含めるように拡張することができる。
－ＥＲＳＡ（「曝露リスクスコア」（ＥＲＳ：Exposure Risk Score））：現在のユーザの曝露リスクスコア。
ｃ）サーバ：
ｉ．暗号化鍵ＥＫＡを生成する
ｉｉ．ＩＤＡ、ＥＫＡをユーザ２に送信する
ｉｉｉ．ＥＫＡを用いてＩＤＡを除くＩＤＴａｂｌｅ［ＩＤＡ］の全ての要素を暗号化する。ここで、認証された暗号化スキームを用いることが有利である。
ｉｖ．ＥＫＡを削除する
サーバはまた、受信した全てのＡＴトークンが１回のみ用いられたことを検証するために、これらを記憶する。代替として、サーバは、（例えば、自身の公開鍵／秘密鍵対を周期的に変更することによって）或る特定の日数のみ有効である認証トークンＡＴを生成することができ、これによりサーバに対する記憶負荷を低減することが可能になる。
２．２ 遭遇発見（Encounter discovery）
各ノードＡは、２つのテーブル、すなわち曝露トークンリストＥＴＬＡ及び要求トークンリストＲＴＬＡを維持する。
所与の日付の各エポックｉにおいて、ノードＡは、
１．Ａｉ－１及びＥＢＩＤＡ，ｉ－１を削除し、
２．Ａｉをランダムに選択し、ＥＢＩＤＡ，ｉ＝ｇＡｉを計算し、
３．Ｂｌｕｅｔｏｏｔｈを介してＥＢＩＤＡ，ｉを定期的にブロードキャストし、
４．期限切れの要素、すなわち、ＣＴ日よりも前に含まれていた要素を除去することによってＲＴＬＡ及びＥＴＬＡをクリーンにする。有利には、本明細書に記載の例において、ＣＴは伝染期間の長さ（通常、１４日）である。
ノードＢとの遭遇の度に、ノードＡは、
１．遭遇ＢからＥＢＩＤＢ，ｉ＝ｇＢｉを収集する。
２．遭遇がいくつかの所定の条件を満たす場合、ノードＡは、
ａ）遭遇の持続時間ｔＡ，Ｂを計算し、
ｂ）２つの別個のＰＥＴを計算する。
ＰＥＴ１ｉ＝Ｈ（「１」｜ｇＡｉ＊Ｂｉ）及びＰＥＴ２ｉ＝Ｈ（「２」｜ｇＡｉ＊Ｂｉ）
ｃ）（ビット列ｇＡｉがビット列ｇＢｉよりも長い）場合、ノードＡは、ＰＥＴ１ｉをＲＴＬＡに記憶し、そのタプル（tuple）（ＰＥＴ２ｉ；ｔＡＢ；ｄａｙ）をＥＴＬＡに記憶する。
ｄ）そうでない場合、ノードＡはＰＥＴ２ｉをＲＴＬＡに記憶し、そのタプル（ＰＥＴ１ｉ；ｔＡＢ；ｄａｙ）をＥＴＬＡに記憶する。
３．ｇＢｉを削除する
上で示したように、デバイスＡは、デバイスＢとの各遭遇を２つのＰＥＴ、すなわちＰＥＴ１及びＰＥＴ２に符号化し、これらは２つの異なるリストＥＴＬＡ及びＲＴＬＡに記憶される。ＰＥＴ１は、パラメータとしてデバイスＡに関する値（ここでは、「１」）及び共有秘密ｇＡｉ＊Ｂｉを用いて関数Ｈ（）を適用することによって生成される一方、ＰＥＴ２は、パラメータとしてデバイスＢに関する値（ここでは、「２」）及び共有秘密ｇＡｉ＊Ｂｉを用いて関数Ｈ（）を適用することによって生成される。他方で、デバイスＢは、厳密に同じ遭遇トークンを生成することになる。ステップｃ）は、デバイスＡ及びデバイスＢの双方が、生成されたトークン間をどのように区別するか、及びいずれのトークンリストにそれらをアップロードすべきかを知ることを確実にするために、ｇＡｉ及びｇＢｉの比較を用いる。この比較は、全順序関数を構成し、双方のデバイスが、同期を一切必要とすることなく同じタイプの順序付けを行うことを可能にする機能を意味する。
後述するように、リストのうちの一方（ＲＴＬＡ）を用いて、曝露について報告サーバに問い合わせる一方、他方（ＥＴＬＡ）は、デバイスＡのユーザがＣＯＶＩＤ１９陽性と診断される場合に報告サーバにアップロードされる。
これらの２つのリストは、同じ遭遇に関し、デバイスＡのリストＥＴＬＡの各トークンが、デバイスＢのリストＲＴＬＢに記憶されるようにデバイスＡ及びＢにおいて生成される。このため、デバイスＡのユーザがＣＯＶＩＤ１９陽性と診断される場合、ユーザＢは、ＣＯＶＩＤ１９陽性と診断された人物との近接遭遇について通知されるように、リストＲＴＬＢからのトークンを用いて報告サーバにポーリングすることができる。同時に、同じ遭遇に関係するリストＥＴＬＡ及びＲＴＬＡのトークンは、（デバイスＡによる場合を除いて）互いにリンクすることができないため、報告サーバは、ＥＳＲ＿ＲＥＱ要求におけるリストＲＴＬＡからのポーリングトークンと、リストＥＴＬＡのトークンとを比較することによって、ユーザＡの匿名性が奪われることを防ぐ。この保護がなければ、報告サーバは、これらのリンクを用いてそのリストＥＴＬＡのトークンをともに再接続し、デバイスＡのユーザの近接グラフを導出し得る。
一般に、時点ｔｂから、ＥＢＩＤＢをブロードキャストする別のデバイスＢと接触しているＥＢＩＤＡをブロードキャストするデバイスＡは、デバイスＡが時点ｔｅにおいて新たなＥＢＩＤ、ＥＢＩＤＡ，ｉ＋１の使用を開始する場合、又はデバイスＡが時点ｔｆから選択された持続時間（この値はパラメータである）にわたってＥＢＩＤＢの受信を停止する場合、新たなＰＥＴトークンを生成する。後者の事例は、デバイスＢがそのＥＢＩＤＢをＥＢＩＤＢ，ｉからＥＢＩＤＢ，ｉ＋１に変更するとき、又はデバイスＢがデバイスＡから離れたか又は一時的に障害物の後ろにあるときに生じ得る。
様々な状況によれば、デバイスは、単一の連続近接遭遇についていくつかのＰＥＴを生成するように導かれる場合がある。本発明は、この状況の制御を可能にする。
図３は、上記の規則と、デバイスＡ及びデバイスＢ間の緩い時間同期とを考慮に入れて２つのデバイスＡ及びデバイスＢによって生成することができる様々なＰＥＴを示す。これは、本発明が、真に非集中的コンテキストでの匿名近接遭遇検出を可能にする程度を理解することを可能にする。
この図において、デバイスＡは時点Ｔ０においてｇＡのブロードキャストを開始する。デバイスＡは、時点Ｔ０＋ｔ０においてデバイスＢに遭遇する。時点Ｔ０＋ｔ０＋ｔ１において、デバイスＡは自身のＥＢＩＤを変更する。結果として、デバイスＡは、ＰＥＴＡ，１Ｈ（ｇＢ＊Ａ）を生成し、これをその持続時間ｔ１と合わせて記憶する。同様に、時点Ｔ０＋ｔ０＋ｔ１において、デバイスＢは、ｇＡをもはや受信せず、したがって、ＰＥＴＢ，１Ｈ（ｇＡ＊Ｂ）を生成し、これをその持続時間ｔ１と合わせて記憶する。そして、デバイスＢが時点Ｔ０＋ｔ０＋ｔ１＋ｔ２においてそのＥＢＩＤを変更するとき、デバイスＢは、ＰＥＴＢ，２Ｈ（ｇＡ’＊Ｂ）を生成し、これをその持続時間ｔ２と合わせて記憶する。同様に、時点Ｔ０＋ｔ０＋ｔ１＋ｔ２において、デバイスＡは、ＰＥＴＡ，２Ｈ（ｇＢ＊Ａ’）を生成し、これをその持続時間ｔ２と合わせて記憶し、デバイスＡとデバイスＢとの遭遇が時点Ｔ０＋ｔ０＋ｔ１＋ｔ２＋ｔ３＋ｔ４において完全に終了するまで以下同様である。
２．３ 感染デバイス宣言
ユーザ２は、病院又は医療機関において検査され、ＣＯＶＩＤ１９陽性と診断される場合、自身のＥＴＬＡリストの各要素をサーバにアップロードするように提案される。例えば、可能な解決策は、ユーザ２が、ＣＯＶＩＤ１９陽性と診断されると、病院又は医療機関から認証コードを得ることである。そして、ユーザ２は、このコードを用いて、Ｎ個の匿名認証トークンを得ることができる。ここで、Ｎはユーザ２のＥＴＬＡリストにおける要素の数である（例えば、セクション５．１を参照されたい）。そして、ユーザ２は、これらのトークンを用いて、自身のＡｐｐのＥＴＬＡの要素のそれぞれを報告サーバに１つずつアップロードすることができる。ＡｐｐＡと保健機関との特定の対話についてはここでは詳細に説明しない。なぜならば、これらは、医療システムごとに異なり、本発明の核心を構成しないためである。有利には、このアップロードは匿名で行われ、特に、ユーザ２のアイデンティティも、そのＥＢＩＤのうちのいずれも報告サーバに明らかにしない。
予防策が不十分である場合、ＥＴＬＡのアップロードは、ＣＯＶＩＤ１９陽性と診断されたユーザ２の非特定化されたソーシャル／近接グラフを報告サーバが構築するのに潜在的に用いられる可能性がある。多くのそのようなソーシャル／近接グラフの統合は、いくつかの条件下で、そのノードの匿名性が奪われることにつながり、結果としてユーザのソーシャルグラフとなる可能性がある。ＥＴＬＡの単一ステップアップロードを行う代わりに、ＥＴＬＡの任意の２つの要素間のリンクを「破断する」（break）ために、本発明は、その要素のそれぞれを、独立してランダムな順序でアップロードすることを提案する。これを達成するために、様々な解決策を構想することができる。
・ＥＴＬＡの各要素は、Ｍｉｘｎｅｔ又はプロキシを用いることによって１つずつサーバに送信される。結果として、アップロードが長期にわたって分散されるため、報告サーバはこれらを特定のＥＴＬと関連付けることができない。
・ＥＴＬＡは、（例えば病院又は保健機構における）信頼されたサーバにアップロードされる。信頼されたサーバは、異なるＥＴＬからの要素を混合し、報告サーバへのアップロードに進む。そして、報告サーバは、信頼されたサーバによって提供される特定のＡＰＩを介してのみ、曝露されたエントリにアクセスすることができる。
・報告サーバは、ＥＴＬのアップロードを処理するセキュアなハードウェアモジュールを備えている。そして、報告サーバは、セキュアなハードウェアモジュールによって提供される特定のＡＰＩを介してのみ、曝露されたエントリにアクセスを有する。
このため、報告サーバは、ＣＯＶＩＤ１９陽性と診断された全てのユーザから到来した全ての曝露されたタプル（ｔｏｋｅｎ；ｄａｙ；ｔ）のグローバルリストＥＬｉｓｔを維持する。デバイスは無関係のデータを周期的にフラッシュするため、関連トークンのみを報告サーバにアップロードすることが保証される。代替的に、報告サーバは、トークンがもはや関連しなくなると、定期的にトークンをフラッシュすることもできる。
２．４ 曝露ステータス要求
ユーザ２に「リスクがある」か否か、すなわち、ユーザ２が最近のＣＴ日に感染した及び／又は伝染力があるユーザに遭遇したかどうかをチェックするために、アプリケーションＡｐｐＡは、ＩＤＡの報告サーバに「曝露ステータス」要求（ＥＳＲ＿ＲＥＱ）を定期的に送信する。例えば、これらのクエリ（query：問い合わせ）は定期的に、最大でＥＳＲ＿ｍｉｎエポックごとに送信される。例えば、ユーザが毎日Ｎ個のクエリを行うことを許可されている場合、ＥＳＲ＿ｍｉｎは、Ｔ＝８６４００／（Ｎ＊ｅｐｏｃｈ＿ｄｕｒａｔｉｏｎ＿ｓｅｃ）として定義される。そして、報告サーバは、「リスクスコア」（risk score）値を計算する。報告サーバは、「リスクスコア」が閾値よりも大きく、ユーザに「リスクがある」ことを示すとき、「１」に設定され、そうでない場合、「０」に設定されるＥＳＲ＿ＲＥＰメッセージを用いて返答する。
これは、例えば以下のように行うことができる。
１．デバイスＡが、ＴＬＳプロキシを介して、ＩＤＡ、ＥＫＡ、及びＲＴＬＡのＰＥＴトークンのうちのいくつか又は全てを含むＥＳＲ＿ＲＥＱＡ，ｉメッセージを報告サーバに周期的に送信する。
２．報告サーバは、ＩＤＴａｂｌｅ［ＩＤＡ］を取り出し、その要素のそれぞれを、ＥＫＡを用いて解読する。
３．報告サーバは、（各ユーザによって行われる日毎の要求の数を制限するために）（ｉ－ＳＲＥＡ）が閾値ＥＳＲ＿ｍｉｎよりも低いか否かを検証する。ここで、ｉは現在のエポック数である。低い場合、サーバはエラーコードを有するＥＳＲ＿ＲＥＰＡ，ｉメッセージを返す。そして、サーバは、ＥＫＡを用いてＩＤＴａｂｌｅ［ＩＤＡ］の各要素を暗号化し、ＥＫＡを消去する。そうでない場合、継続する。
４．報告サーバはＵＮＡフラグを検証する。ＵＮＡが「真」に設定される場合、報告サーバは「１」に設定された同じＥＳＲ＿ＲＥＰＡ，ｉメッセージ（ユーザに曝露のリスクがあることを示す）を返す。ユーザが既に「リスクがある」ことを通知されたアプリケーションＡｐｐが、このアプリケーションのトラフィックを、ネットワークトラフィックの観測時に他のユーザのアプリケーションのトラフィックと区別不可能にするために、ＥＳＲ ＲＥＱＡ，ｉメッセージの送信及び有効な回答の受信を継続することが優れた実践法である。そして、サーバは、ＥＫＡを用いてＩＤＴａｂｌｅ［ＩＤＡ］の各要素を暗号化し、ＥＫＡを消去する。そうでない場合、継続する。
５．そして、報告サーバは、ＲＴＬＡのＰＥＴトークンのうちのいずれかがＥＬｉｓｔの任意のタプル（ｔｏｋｅｎ；ｄａｙ；ｔ）に現れるか否かをチェックする。現れる場合、サーバは、ＥＬｉｓｔからマッチするタプルを除去し、全ての（ｄａｙ；ｔ）対をＩＤＴａｂｌｅ［ＩＤＡ］のＬＥＰＭＡリストに追加する。
６．報告サーバは、ユーザ２の曝露リスクスコアを計算し、これをＩＤＴａｂｌｅ［ＩＤＡ］（フィールドＥＲＳＡ内）に記憶する。代替的に、報告サーバは、ＩＤＴａｂｌｅ内に最後のＣＴにおいて生成されたＲＴＬトークンを記憶することもできる。これにより、所与のデバイスは、そのＥＳＲ＿ＲＥＱクエリにおいて日毎に「新たな」トークンを送信するのみでよいため、いくらかの帯域幅が節減される。加えて、これにより、日毎のトークンをローカルでのみ記憶するデバイスにおけるセキュリティが改善する。
７．このとき、２つの状況が可能である。
ａ）計算されたリスクスコアが、ユーザに曝露のリスクがあることを示す場合、サーバはフラグＵＮＡを「真」に設定する。そして、（ユーザに曝露のリスクがあることを示す）「１」に設定されたＥＳＲ＿ＲＥＰＡ，ｉメッセージがユーザ２に返される。
ｂ）計算されたリスクスコアが任意の大きなリスクを示さない場合、「０」に設定されたＥＳＲ＿ＲＥＰＡ，ｉメッセージがユーザ２に返される。
８．返答メッセージを送信した後、報告サーバは、ＥＫＡを用いてＩＤＴａｂｌｅ［ＩＤＡ］の各要素を暗号化し、ＥＫＡを消去する。
９．ＥＳＲ＿ＲＥＰＡ，ｉが「１」に設定される場合、ユーザ２は、ＡｐｐＡからの通知を、（例えば、検査を受けるために病院に行く、特定の番号に電話をかける、又は隔離を継続する）所定の指示とともに受信する。
デバイスＡを用いる所与のユーザについて、アップロードされたリストＥＴＬＡ及び要求ＲＴＬＡにおいて用いられるＰＥＴトークンは、同じ遭遇について異なるため、サーバはこれらの要素をリンクさせることができず、いかなる近接グラフも構築することができない。
さらに、要求から漏出する唯一の情報は、要素の数であり、これは、ＲＴＬＡに含まれる遭遇数に関する何らかの情報を与え得る。１つの解決策は、要求内の要素数を固定値Ｔに設定することである。ＲＴＬＡの要素数ＮＡがＴよりも小さい場合、ＡｐｐＡはその要求を（Ｔ－ＮＡ）個の偽トークンに埋め込む（pad）ことができる。要素の数ＮＡがＴよりも大きい場合、ＡｐｐＡは、その要求についてＲＴＬＡのＴ個の要素のみを用いる。他の変形は、ＲＴＬＡの要素をＢｌｏｏｍ又はＣｕｃｋｏｏフィルタに符号化することを含むことができる。
２．５ 通知されたデバイスの管理
デバイスが自身のユーザにリスクがあることを通知されるとき、そのＵＮＡフラグは、ＩＤＴａｂｌｅにおいて真に設定される。これ以降、報告サーバは、通常通り自身のＥＳＲ＿ＲＥＱクエリを処理するが、ＥＳＲ＿ＲＥＱの結果に関わらず、「１」に設定されたＥＳＲ＿ＲＥＰメッセージを用いて返答し続ける。
「リスクがある」に設定されているとき、通知されたデバイスユーザはいくつかのオプションを有する。
－ユーザが検査を受け、ＣＯＶＩＤ１９陽性と診断される。
・その場合、ユーザは、セクション２．３に記載されたように自身のＥＴＬＡリストをアップロードすることができる。
・これと独立して、ユーザは、サーバに、識別子ＩＤＡが検査を受けて陽性であったことを、（本明細書には指定しない）特定のプロトコルを介して通知することができる。この通知は、以前のＥＴＬＡリストアップロードと独立して行われ、合わせてリンク付けすることができない（報告サーバは、ＩＤＡによってアップロードされたＰＥＴトークンを識別することができない）。この情報は、保健機関がリスクスコア関数を較正するのに必須である。
－ユーザが検査を受け、ＣＯＶＩＤ１９陰性と診断される。
・ユーザは、報告サーバに、識別子ＩＤＡが検査を受けて陰性であったことを、（本明細書には指定しない）特定のプロトコルを介して通知することができる。結果として、報告サーバにおいてＵＮＡフラグが「偽」に再設定される。
－ユーザは、検査を受けないこと、又は報告サーバに自身の検査に関して知らせないことを決める。
・その場合、ユーザの「リスクがある」ステータスは、或る特定の固定の期間（３～４日、定義される値）の後に再設定することができる。
いずれの場合も、「リスクがある」と通知されたアプリケーションは、ＥＢＩＤの送受信及びＰＥＴの計算を継続する。これは、例えばユーザが検査結果を待っているときに必要とされる。ユーザが陰性であるとわかった場合、遭遇が記録され続け、ユーザが報告サーバにおける自身のステータスをロック解除するや否や、更新された曝露ステータスを、履歴におけるギャップなしで計算することができる。
陽性と診断されたユーザは、伝染力がある限り、アプリケーションを使用し続けるオプションを有するべきである。この期間中、ユーザは、自身のＥＴＬリストをサーバに定期的にアップロードしなくてはならない。
当然ながら、上記の手順は疫学者及び保健機関によって見直すことができ、したがって、変更を受ける。
３ プライバシ保護
３．１ サーバデータ侵害
サーバは、仮名のデータのみを記憶する。加えて、この情報は最小限にされ、曝露リスクスコアを計算するためにのみ用いられる。さらに、デバイスＡのＩＤＴａｂｌｅにおける各エントリは、鍵ＥＫＡを用いて暗号化され、鍵ＥＫＡは、デバイスＡにのみ記憶され、ＥＳＲ＿ＲＥＱクエリとともに報告サーバに提供される。
結果として、サーバのデータ侵害の場合、全ての有用な情報が暗号化される。このとき、データ侵害に関連付けられるリスクは最小限となる。
３．２ （悪意のあるユーザ及び機関による）受動的な盗聴／トラッキング
ＰＥＴトークンは、各遭遇に一意であり、ローカルで計算されるため、受動的な盗聴者は、ＥＢＩＤのみを取得し、これらはエポックごとに変化する。さらに、機関は、いくつかのＢｌｕｅｔｏｏｔｈ受信機を展開する場合、決定的ディフィ－ヘルマン（ＤＤＨ：decisional Diffie-Hellman）仮定の結果として、任意のＥＢＩＤ（すなわち、ｇＡｉ）を任意のＰＥＴトークンに関係付けることができない。したがって、サーバ又はユーザによる受動的なトラッキングは可能でない。
３．３ （悪意のあるユーザによる）能動的な盗聴／トラッキング
ユーザによる能動的な盗聴／トラッキングは可能でない。
３．４ （悪意のある機関による）能動的な盗聴／トラッキング
機関が能動的であり、例えばｇＺを含む自身の独自のＥＢＩＤもブロードキャストするＢｌｕｅｔｏｏｔｈデバイスを展開する場合、ターゲットデバイスＡは、ＰＥＴトークンＨ（「１」｜ｇＡ＊Ｚ）及びＨ（「２」｜ｇＡ＊Ｚ）を生成及び記憶する。報告サーバのデバイスは、サーバがターゲットのＥＳＲ ＲＥＱメッセージを識別し、場合によってはそのロケーションのうちのいくつかをトラッキングするのに用いることができる同じトークンも生成することができる。デバイスのＥＳＲ＿ＲＥＱクエリは（ユーザのＩＤＡを含むので）リンク可能であるため、これらのトラッキングデバイスが十分あれば、サーバは場合によってはいくつかのユーザを再識別し得る。
３．５ （悪意のある機関による）社会的対話グラフの再構築
デバイスＡのユーザは、ＣＯＶＩＤ１９陽性と診断されるとき、上記で説明したように、自身のＥＴＬＡの全ての要素を独立して匿名でアップロードする。結果として、報告サーバは、ユーザとアップロードされたＰＥＴトークンとの間にも、アップロードされたＰＥＴトークン自体の間にもリンクを作成することができない。
デバイスＡのユーザが自身の曝露ステータスについてサーバに問い合わせるとき、サーバは、ＥＳＲ＿ＲＥＱクエリに含まれる全てのＰＥＴトークンにＩＤＡをリンク付けすることができる。しかしながら、ＥＳＲ＿ＲＥＱクエリにおいて用いられるＰＥＴトークンは、デバイスＡのユーザが診断を受ける予定であった場合、報告サーバにアップロードされるトークンと異なる。結果として、報告サーバは、そのＥＬｉｓｔにおける被曝露トークン（exposed token）と、曝露要求におけるトークンとの間の任意のリンクを推測することができない。
さらに、ＥＢＩＤを交換し、関連ＰＥＴトークンを構築したそれぞれのデバイスＡ及びＢの２つのユーザは、曝露要求を用いてサーバに要求するとき、異なるトークンを用いてこれを行う。このため、報告サーバは、これらの要求においてトークンをリンク付けすることができない。
３．６ （悪意のあるユーザによる）感染デバイス再識別
ユーザは、感染接触を識別することができない。なぜならば、この情報はサーバ上に保持され、ユーザは自身の曝露リスクスコアのみを得るためである。しかしながら、全てのスキームに固有の「１エントリ」攻撃が依然として可能である。
そのような攻撃において、敵対者（adversary）は、自身のローカルリストにおいて、ＵｓｅｒＴに対応する１つのみのエントリを有する（これは、Ｂｌｕｅｔｏｏｔｈインタフェースをオフにし、敵対者が自身の被害者の付近になったときにオンに切り替え、再びオフに切り替えることによって容易に達成することができる）。敵対者は、「リスクがある」ことを通知されると、ＵｓｅｒＴがＣＯＶＩＤ１９陽性と診断されたことを学習する。
この攻撃は、以下によって軽減することができる。
－ユーザに、Ｓｙｂｉｌ攻撃を制限するために登録することを要求すること。
－各ノードが日毎に行うことができる要求数を制限するとともに、ユーザに「リスクがある」と通知されるときは更にこれを制限すること。この対抗手段は攻撃のスケールを制限する。
－セクション５．２に提示されるように確率通知スキームを用いること。
－要求側ユーザの被曝露トークン数が厳密に１よりも大きい場合にのみ「１」に設定されるＥＳＲ＿ＲＥＰを送信すること。
－返答「１」を提供する前に、要求が少なくともＮ個のトークンを含むことをサーバに検証させること。しかしながら、この対抗手段は、敵対者がフェイクトークンをターゲットトークンとともに用いることを阻止しない。
３．７ リプレイ攻撃
通信が対称であると仮定されるため、可能でない。例えば、悪意のあるデバイスＥがＥＢＩＤＣをデバイスＡにリプレイする場合、デバイスＡは対応するＰＥＴ１及びＰＥＴ２を計算して記憶する。しかしながら、デバイスＣは、これらの値を自身のＲＴＬ及びＥＴＬテーブルに有しない。
３．８ リレー攻撃
最大で１つのエポック内でのみ可能である。
３．９ 誤警報投入攻撃（False Alert Injection Attacks）
汚染は、悪意のあるノードが診断を受けたユーザと共謀して数人の被害者の識別子をユーザの接触リストに含める攻撃である。悪意のある敵対者の目標は、ターゲット被害者のＡｐｐに偽アラートを生じさせることである。
この攻撃は、共謀ユーザ及び被害者が自身のＰＥＴを計算するために対話することを必要とする。したがって、そのような攻撃は、リレー攻撃を介してのみ可能である。
４ ＲＯＢＥＲＴ ｖ２のステートレス・バージョン
上で示すように、ＲＯＢＥＲＴ ｖ２において、報告サーバは、登録されたユーザに関するいくらかの情報を記憶する。この情報は最小限であり、セキュアに記憶される。本出願人は、この特徴が、例えば登録ユーザ数を制御し、要求頻度を制限することによっていくつかの攻撃を軽減することを可能にするため、本発明のスキームの強みであることを発見した。
この特徴は、保健機関が、状況の発展に従ってリスクスコアを計算及び更新することも可能にし、セクション１．３に論じたように、保健機関に、リスクスコア関数を最適化するために非常に価値が高い可能性があるユーザ曝露に関する情報を提供する。他の技術的事例において、この特徴は、進化するパラダイムにシステムをより容易に適応させることを可能にする。
とはいえ、ＲＯＢＥＲＴ ｖ２をステートレス・システム（a state-less system）へと変換することが可能である。ここで、報告サーバは、ＣＯＶＩＤ１９陽性と診断されたユーザによってアップロードされたＥＬＴリストＰＥＴトークンと、ＥＳＲ＿ＲＥＱクエリに含まれるＲＴＬリストトークンとの間の単なる「整合マシン」（matching machine）である。
このとき、プロトコルは以下のように動作することができる。
－アプリケーション初期化
ユーザはサーバに登録する必要がない。ユーザは、日毎にＣＴ個の異なる匿名認証トークンを得るのみでよい。これらの認証トークンのそれぞれは、特定の日にのみ有効であるべきであり、登録中にバッチで得ることができる。例えば、ユーザは、ＣＴ個の異なる鍵の下、日毎にＣＴ個のトークン（毎日異なり、ｄｉ、ｄｉ－１、ｄｉ－２，．．．について今日使用可能なトークン、ｄｉ＋１、ｄｉ、ｄｉ－１について明日使用可能なトークン等）を得る。トークンの各役割について特定の署名鍵が用いられる。これは、ブラインド署名を用いたオンライン電子キャッシュスキーム「ａ ｌａ Ｃｈａｕｍ」において行われるのと同じ特質（vein）である。
－遭遇発見
上記で説明したＲＯＢＥＲＴ ｖ２プロトコルと同様。
－感染デバイス宣言
上記で説明したＲＯＢＥＲＴ ｖ２プロトコルと同様。
－曝露ステータス要求
ユーザはリンク付け不可能なＥＳＲ＿ＲＥＱクエリを用いて報告サーバに問い合わせし、クエリはそれぞれ、異なるＲＴＬＡの要素のサブセットを含む。各ＥＳＲ＿ＲＥＱクエリは、例えば、同じ日の間に生成されたＰＥＴトークンを含むことができる。この場合、各日ｄｉにおいて、ユーザは、ＣＴ個の異なるリンク付け不可能なＥＳＲ＿ＲＥＱクエリ（１つはｄｉ中に生成されたトークンを含み、１つはｄｉ－１中に生成されたトークンを含み、．．．、１つはｄｉ－ＣＴ中に生成されたトークンを含む）を送信する。
報告サーバは、要求に含まれる任意のトークンが被曝露トークンのリストＥＬｉｓｔに現れるか否かをチェックすることによって、これらのＥＳＲ＿ＲＥＱクエリのそれぞれを独立して処理する。そして、報告サーバは、各要求の結果としての曝露リスクスコアを計算し、結果を要求デバイスに返送する。
この拡張により、報告サーバは、ユーザの「グローバル」曝露リスクスコアをもはや計算することができず、リンク付け不可能な「日毎の」リスクスコアのみを計算することができることに留意されたい。デバイスは、グローバルスコアに集約する必要がある（異なるＣＴ日の前の日についての）ＣＴ個の異なるリスクスコアを得る。これは、全てのＡｐｐが、定期的に更新されることを必要とする場合がある集約関数（aggregation function）を含まなくてはならないことも暗に意味する。
最後に、全ての電話にサーバのＥＬｉｓｔに含まれる曝露ＰＥＴトークンを公開することによって、リスク評価を完全に非集中化することも可能である。このとき、結果として得られるスキームは、ＤＰ３Ｔ等のいわゆる「非集中化」手法に非常に類似している。しかしながら、本出願人は、感染デバイスの再識別に対する耐性を減少させることについてこの手法が不満足であることを発見した。さらに、リスクスコア計算のこの完全な非集中化は、多くの制御不可能な通知の生成につながり得る。これは、集団に劇的な影響を有する可能性があり、システムの信頼を低下させ、結果として、その採用率を低下させる可能性がある（上記のセクション１．３を参照されたい）。
５ 付録
５．１ 認証トークン生成
サーバが公開鍵（ｅ，ｎ）及び秘密鍵（ｄ，ｎ）．を有するＲＳＡ証明書を有すると仮定する。
ＴＬＳプロキシチャネルを用いて以下が実行される。
ユーザ－－－－－－＞ｐｈｏｎｅ＿ｎｕｍｂｅｒ－－－－－－＞サーバ
サーバは、ＩＤ＝Ｈ（ｐｈｏｎｅ＿ｎｕｍｂｅｒ）を計算し、ＩＤが存在しないことをチェックする。サーバは、ＳＭＳを介してコードＰＩＮをユーザに送信する。ＳＭＳを用いて、ユーザが電話番号、このためデバイスを所有することを検証する。ＰＩＮコードは、ユーザがＳＩＭカードを有しない場合、別のメカニズムを介して得ることができることに留意されたい。例えば、ＰＩＮコードは、医師又は医療機関によって、例えば電子メールを介して配信することができる。
ユーザは２つのランダムなｃ及びＲを生成し、ｃｅ．Ｈ（Ｒ）（ｍｏｄ ｎ）を計算し、以下を送信する。
ユーザ－－－－－－＞ＰＩＮ、ｃｅ．Ｈ（Ｒ）（ｍｏｄ ｎ）－－－－－－＞サーバ
サーバはＰＩＮを検証し、ＲＥＰ＝（ｃｅ．Ｒ）ｄ＝ｃ：Ｈ（Ｒ）ｄ（ｍｏｄ ｎ）を計算する。
ユーザ＜－－－－－－ＲＥＰ＝ｃ．Ｈ（Ｒ）ｄ（ｍｏｄ ｎ）＜－－－－－－クライアント
ユーザは、シグマ＝ＲＥＰ／ｃ＝Ｈ（Ｒ）ｄ（ｍｏｄ ｎ）を計算し、認証トークン（Ｒ，ｓｉｇｍａ）を得る。
サーバは電話番号及びＲＥＰを削除する。
そして、ユーザは、ＥＳＲ＿ＲＥＱを送信するとき、又は登録段階中、自身の認証トークンを用いて、自身が登録ユーザであることを証明することができる。
しかしながら、Ｓｙｂｉｌ攻撃を制限するためにスマートフォンあたり１つのアプリケーションしか存在しないことをユーザが検証するために自身の電話番号を明らかにするものの、サーバは、トークン（Ｒ，ｓｉｇｍａ）を任意の電話番号にリンク付けすることができないため、ユーザの電話番号を生成された認証トークンとリンク付けすることができないことに留意されたい。
アプリケーションをアンインストールするユーザは、新たなアプリケーションを後に登録することができないことに留意するべきである。これが問題となる場合、解決策は、電話番号あたり限られた数（すなわち、２又は３）のユーザ登録を認証することである。
５．２ 確率的通知
Serge Vaudenayによる論文「Analysis of DP3T」Cryptology ePrint Archive, Report 2020/399, 2020に記載されているように、全ての近接トラッキングスキームは「１エントリ」攻撃に対し脆弱である。
上記のセクション３．６に説明したように、この攻撃において、敵対者は自身のローカルリストにおいてＵｓｅｒＴに対応する１つのエントリのみを有する。敵対者は、「リスクがある」ことを通知されると、ＵｓｅｒＴがＣＯＶＩＤ１９陽性と診断されたことを学習する。
セクション３．６において記載したように、ＲＯＢＥＲＴ ｖ２は、いくつかの緩和手段を提案する。
本出願人は、この攻撃を阻止する唯一の方式が、いくらかの「拒否可能性」（deniability）を導入するために確率的通知を用いることであると考える。そのようなスキームにおいて、ＥＳＲ＿ＲＥＱメッセージを受信するサーバは以下を返答する。
ユーザのＩＤが曝露ＩＤのリストにない場合、「０」（すなわち、リスクがない）、
ユーザのＩＤが曝露ＩＤのリストにある場合、又はサーバによってランダムに選択される場合、「１」（サーバは、確率ｐで「１」返答を受信する、「０」返答を受信するはずの追加のユーザを選択するように構成される）。
結果として、ユーザは、「１」返答を受信する場合、自身が曝露されたことに起因するのか、又はサーバによってランダムに選択されたのかがわからない。ユーザはサーバにもはや問い合わせることができないため（既に「１」の返答を受信したことに起因する）、攻撃を精緻化するための追加の要求を送信することができない。この攻撃は、１人のユーザをターゲットにするｎ個の共謀ノードによって依然として可能なままであるが、この場合、ｎ個の共謀ノードは全て「１」を返され、自身の被害者の曝露ステータスを突き止めることになる。しかしながら、ここで、１人の被害者をターゲットにするのにｎ人の敵対者が必要となるため、攻撃のスケーラビリティが低減する。
この提案の副次的効果は、いくらかの偽陽性を導入することであり、すなわち、数人の人物は、実際に（少なくともリスクスコアに従って）「リスクがある」状態にないにもかかわらず通知を受けることになる。このトレードオフの許容可能性はいくつかの要素にある。第１に、近接追跡は完全ではなく、いずれにしても偽陽性又は偽陰性が存在することを認識する必要がある。この文脈において、５％又は１０％の更なる偽陽性を追加することは必ずしも問題ではない。第２に、システムが用いられる用途は、大きな役割も果たす。すなわち、Ａｐｐが検査を受けるべきユーザをターゲットにするために用いられる場合、５％又は１０％の更なるユーザをランダムに検査することは極めて許容可能であるが、Ａｐｐがユーザに隔離所に入るように通知する場合、偽陽性はより問題となり得る。
５．３ Ｂｌｕｅｔｏｏｔｈ通信
Ｂｌｕｅｔｏｏｔｈを介してブロードキャストされる識別子ＥＢＩＤは、ここで、１６バイトよりも大きく、したがって、アドバタイズパケットのみで搬送することができない。本発明は、このより大きなメッセージを、Ｂｌｕｅｔｏｏｔｈを介して送信するための２つの解決策を提案する。
５．３．１ 走査応答ベースの手法
２５６ビット識別子ＥＢＩＤＡ，ｉを、ＢＬＥ（Ｂｌｕｅｔｏｏｔｈ低エネルギー）を介して送信するために、本発明は、ＢＬＥ［8, Vol 3, Part B, sec. 4.4.2.3］の走査応答メカニズムを用いることを提案する。２５６ビット識別子は、１６バイトの２つのブロックに分割され、第１のブロックはＡＤＶ＿ＩＮＤパケットのアドバタイズデータに含まれるのに対し、第２のブロックは、ＳＣＡＮ＿ＲＳＰパケットのアドバタイズデータに含まれる（以下の表２及び表３を参照されたい）。
識別子セグメンテーション
２５６ビット識別子ＥＢＩＤＡ，ｉは、２つのブロック、ＩＤＬ＝ＬＳＢ１６（ＥＢＩＤＡ，ｉ）及びＩＤＨ＝ＭＳＢ１６（ＥＢＩＤＡ，ｉ）に分割される。ここで、ＭＳＢ１６（ｘ）及びＬＳＢ１６（ｘ）は、それぞれｘの最上位１６バイト及び最下位１６バイトを返す関数である。
Figure 2023524829000003
Figure 2023524829000004
５．３．２ 専用サービス
これらのブロックのそれぞれは、サービスのためのデータとして構成される。この目的のために、２つの専用サービスが定義される。１６ビットＵＵＩＤ ０ｘＦＤ０１を有するリスク通知サービス１（ＲＮＳ１）は、メタデータ（プロトコルバージョン及びＴｘ電力）と併せてＩＤＬを搬送し、リスク通知サービス２（ＲＮＳ２）は１６ビットＵＵＩＤ ０ｘＦＤ０２とともにＩＤＨを搬送する。
５．３．３ アドバタイズ及び走査応答ペイロード
アドバタイズパケットのペイロードは、以下から構成される。
・フラグ（３バイト）
・リスク通知サービス１（０ｘＦＤ０１）のＵＵＩＤを搬送する完全な１６ビットＵＵＩＤ（４バイト）
・サービスデータ－リスク通知サービス１のためのデータ、すなわち、ＩＤＬ（１６バイト）、プロトコルバージョン（１バイト）及びＴｘ電力（１バイト）を搬送する１６ビットＵＵＩＤ（２２バイト）。
走査応答のペイロードは、以下から構成される。
・リスク通知サービス２（０ｘＦＤ０２）のＵＵＩＤを搬送する完全な１６ビットＵＵＩＤ（４バイト）
・サービスデータ－リスク通知サービス２、すなわちＩＤＨ（１６バイト）のためのデータを搬送する１６ビットＵＵＩＤ（２０バイト）
ＥＢＩＤのローテーションはデバイスアドレスと同期されることが仮定された。したがって、２つのブロックＩＤＬ及びＩＤＨは、デバイスアドレスを介してリンク付けすることができる。これに当てはまらない場合、ＥＢＩＤの再構築を可能にするために、アドバタイズ及び走査応答パケットのペイロードに追加の識別子を含めなくてはならない。
５．３．４ アドバタイズ及び走査
Ｂｌｕｅｔｏｏｔｈ仕様［8, Vol 3, Part B, sec. 4.4.2.3］に述べられているように、アドバタイズパケット（ＡＤＶ＿ＩＮＤ ＰＤＵ）の受信後、スキャナは、走査要求（ＳＣＡＮ＿ＲＥＱ ＰＤＵ）を送信するか、又はアドバタイザに関する追加の情報を要求することができる。アドバタイザは、自身のデバイスアドレスを含むＳＣＡＮ ＲＳＰ ＰＤＵを受信する場合、同じプライマリアドバタイズチャネルインデックスにおいてＳＣＡＮ ＲＳＰ ＰＤＵを用いて返答する。
デバイスは、この要求応答メカニズムに従うように構成される。より詳細には、デバイスは、常に新たなアドバタイズパケットに応答して走査要求を送信するべきであり、走査要求の受信時に、常にデバイスは走査応答を用いて応答するべきである。
５．４ フラグメンテーション手法
別の解決策は、ＥＢＩＤＡ，ｉを２つのブロックに分割し、これらのブロックを、交互にアドバタイズパケットにおいて送信することに頼ることである。
より詳細には、ＥＢＩＤＡ，ｉは、セクション５．３．１に提示される手法に従って２つのブロックＩＤＬ及びＩＤＨに分割される。これらのブロックは、専用サービス（例えば、セクション５．３．２に提示されるように、ＵＵＩＤ ０ｘＦＤ０１を有するリスク通知サービス１）に関連付けられたサービスデータとしてアドバタイズパケット（ＡＤＶ＿ＩＮＤ ＰＤＵ）のペイロードにおいて送信される。送信されたアドバタイズパケットにおけるサービスデータは、交互にＩＤＬ及びＩＤＨの値をとる。
６ 拡張
６．１ 非ＣＯＶＩＤ１９関連の２つのＰＥＴベースの方法
本発明は、ＣＯＶＩＤ１９曝露管理の文脈において重点的に説明されているが、実際は多岐にわたる他の状況におかれる。
本発明は、２つのデバイスＡ及びＢが、対話を行うことさえなく、プライベートにかつセキュアに自身のコロケーションを第３のエンティティに証明する必要がある任意の状況に適用することができる。
大まかに言えば、上記で説明した実施形態の特徴の多くを交換することができる。例えば、
－Ｃｕｒｖｅ２５５１９の代わりに、別の楕円曲線、若しくはＥＣＤＨを用いることができるか、又は基本ディフィ－ヘルマン鍵プロトコル等の任意のタイプの非対話型鍵交換（ＮＩＫＥ：Non-Interactive Key Exchange）プロトコル（Freire E.S.V., Hofheinz D., Kiltz E., Paterson K.G. (2013)による論文「Non-Interactive Key Exchange」In: Kurosawa K., Hanaoka G. (eds) Public-Key Cryptography - PKC 2013. PKC 2013. Lecture Notes in Computer Science, vol 7778. Springer, Berlin, Heidelbergに記載の「ＮＩＫＥ」）を用いることができる。
－Ｂｌｕｅｔｏｏｔｈ及びＢＬＥの代わりに、無線（ＷｉＦｉ等）であれ、又は空中（超音波による）であれ、又は光変調によるものであれ、任意の他の無線送信プロトコルを用いることができる。
－本明細書に記載の関数Ｈ（）は、ハッシュ関数である。代替的な実施形態において、これは類似の結果を有する任意の擬似ランダム関数とすることができる。
－異なるメトリック及び／又はメタデータを用いて、監視されている遭遇のタイプ、求められている情報、例えば、持続時間、遭遇中の速度、遭遇が外で生じたか中で生じたか、瞬間密度（すなわち、いくつのＥＢＩＤが見えていたか）等に従ってＰＥＴに関連付けることができる。
－上記において、ＰＥＴの値は、ｇＡ及びｇＢの値を比較することによって、ＥＴＬ及びＲＴＬのリストに割り当てられる。ここでの目的は、更なる通信の必要性が存在することなく、Ａ及びＢの双方によって既知の入力に基づいてＡとＢとの間の順序を定義することである。より包括的には、これは、Ａ及びＢによって既知の２つの入力を所与として、ＡとＢとの間の順序を定義するソート値を出力する全順序関数を実施することによって行うことができる。
さらに、上記は、パンデミック管理に適用するための特にロバストで匿名の方法に関する。しかしながら、他の事例の研究に役立つようにより簡単なバージョンが用いられてもよい。例えば、２つのＰＥＴを計算し、これらを２つのリストに記憶して、悪意のある報告サーバ活動を防ぐ代わりに、１つのＰＥＴのみを生成してもよい。そして、例えば、デバイスのうちの１つが固定デバイスである場合、このデバイスは、自身の対話遭遇トークンを用いて様々なポリシの効率を評価することができる。例えば、この固定デバイスは、通信媒体の近く又は通信媒体の対象である要素の近くに位置決めすることができ、この通信媒体の効率性を評価する手段として遭遇トークンを監視することができる。
上記において、全てのデータ項目が有形なメモリ媒体上に記憶されることを理解するべきである。そのような有形なメモリ媒体は、ハードディスクドライブ、ソリッドステートドライブ、フラッシュメモリ、プロセッサに埋め込まれたメモリ、クラウドにおいてアクセス可能な遠方の記憶装置等による、任意の適切な方式で実現することができる。
同様に、上記の機能及び動作のほとんどは、１つ以上のプロセッサにおいて実行されるコンピュータプログラムによって実行されることが意図される。そのようなプロセッサは、ＣＰＵ、ＧＰＵ、ＣＰＵ及び／又はＧＰＵグリッド、リモート計算グリッド、特殊構成のＦＰＧＡ、特殊構成のＡＳＩＣ、ＳＯＣ又はＮＯＣ等の特殊チップ、ＡＩ特殊チップ等の、自動計算を行う既知の任意の手段を含む。
上記の参加デバイスは、アプリケーションを実行するスマートフォンとして説明されるが、無線機能を有する任意の移動デバイスが、本発明による方法を実施することができる。
より一般的には、本発明は、匿名近接追跡のコンピュータ実施方法を提案する。この方法は、
ａ）それぞれが、秘密鍵生成器及び非対話型鍵交換プロトコルパラメータを含む非対話型鍵交換プロトコルインタフェースを有する、無線通信が可能な複数の参加デバイスを提供するステップと、
ｂ）上記参加デバイスのそれぞれにおいて秘密鍵生成器を周期的に用いてそれぞれの現在の秘密鍵を取得し、上記それぞれの現在の秘密鍵及び上記非対話型鍵交換プロトコルパラメータに基づいて、上記参加デバイスのそれぞれにおいてそれぞれの現在の公開鍵を計算するとともに、上記参加デバイスのそれぞれが、周期的に無線で上記それぞれの現在の公開鍵をブロードキャストするステップと、
ｃ）第２の参加デバイスによってブロードキャストされたそれぞれの現在の公開鍵を第１の参加デバイスによって検出すると、上記第１の参加デバイス及び第２の参加デバイスのそれぞれにおいて、
ｉ．非対話型鍵交換プロトコルパラメータと、上記第１の参加デバイス及び上記第２の参加デバイスのそれぞれの現在の秘密鍵とによって定義される現在の共有秘密を計算するステップと、
ｉｉ．上記現在の共有秘密を用いてパラメータ化され、バケット値に適用された擬似ランダム関数を用いて少なくとも１つのトークンを計算するステップと、
ｄ）所与の参加デバイスによるアップロード条件の検出時に、当該所与の参加デバイスによって計算された上記第１のトークンのうちの少なくともいくつかを報告サーバに選択的にアップロードするステップと
を含んでなる。
この方法によれば、上記複数の参加デバイスは、第１の遭遇トークンリスト及び第２の遭遇トークンリストを更に記憶することができ、ステップｃ）ｉｉは、上記現在の共有秘密を用いてパラメータ化され、第１のバケット値に適用された擬似ランダム関数を用いて第１のトークンを計算するとともに、上記現在の共有秘密を用いてパラメータ化され、第２のバケット値に適用された上記擬似ランダム関数を用いて第２のトークンを計算することを含み、ステップｃ）は、ｉｉｉ．上記第１の参加デバイス及び上記第２の参加デバイスの双方によって既知の２つの入力を用いて全順序関数を適用することによって求められるソート値を計算するとともに、上記ソート値に基づいて、上記第１の参加デバイスの上記第１の遭遇トークンリスト及び上記第２の参加デバイスの上記第２の遭遇トークンリストに上記第１のトークンを記憶し、上記第１の参加デバイスの上記第２の遭遇トークンリスト及び上記第２の参加デバイスの上記第１の遭遇トークンリストに上記第２のトークンを記憶するか、又は、上記第１の参加デバイスの上記第２の遭遇トークンリスト及び上記第２の参加デバイスの上記第１の遭遇トークンリストに上記第１のトークンを記憶し、上記第１の参加デバイスの上記第１の遭遇トークンリスト及び上記第２の参加デバイスの上記第２の遭遇トークンリストに上記第２のトークンを記憶することを更に含むことができ、ステップｄ）は、所与の参加デバイスによって、当該所与の参加デバイスによるアップロード条件の検出時に、上記第１の遭遇トークンリスト又は上記第２の遭遇トークンリストのうちの一方の少なくとも一部を近接管理サーバに選択的にアップロードすることを含むことができる。

Claims (10)

  1. 匿名近接追跡のコンピュータ実施方法であって、
    ａ）それぞれが、秘密鍵生成器と非対話型鍵交換プロトコルパラメータとを含む非対話型鍵交換プロトコルインタフェースを有する、無線通信が可能な複数の参加デバイス（２）を提供するステップと、
    ｂ）前記参加デバイスのそれぞれにおいて前記秘密鍵生成器を周期的に用いてそれぞれの現在の秘密鍵を取得し、このそれぞれの現在の秘密鍵と前記非対話型鍵交換プロトコルパラメータとに基づいて、前記参加デバイスのそれぞれにおいてそれぞれの現在の公開鍵を計算するとともに、前記参加デバイスのそれぞれが、周期的に無線で前記それぞれの現在の公開鍵をブロードキャストするステップと、
    ｃ）第２の参加デバイスがブロードキャストしたそれぞれの現在の公開鍵を第１の参加デバイスが検出すると、前記第１の参加デバイス及び前記第２の参加デバイスのそれぞれにおいて、
    ｉ．前記非対話型鍵交換プロトコルパラメータと、前記第１の参加デバイス及び前記第２の参加デバイスの前記それぞれの現在の秘密鍵とによって定義される現在の共有秘密を計算するステップと、
    ｉｉ．前記現在の共有秘密を用いてパラメータ化され、前記第１の参加デバイスに関係する第１の値に適用された擬似ランダム関数を用いて第１のトークンを計算するとともに、前記現在の共有秘密を用いてパラメータ化され、前記第２の参加デバイスに関係する第２の値に適用された前記擬似ランダム関数を用いて第２のトークンを計算するステップと、
    ｉｉｉ．前記第１の参加デバイス及び前記第２の参加デバイスの双方に既知の２つの入力を用いて、全順序関数を適用することによって求められるソート値を計算するとともに、該ソート値に基づいて、前記第１の参加デバイスの第１の遭遇トークンリスト及び前記第２の参加デバイスの第２の遭遇トークンリストに前記第１のトークンを記憶し、前記第１の参加デバイスの前記第２の遭遇トークンリスト及び前記第２の参加デバイスの前記第１の遭遇トークンリストに前記第２のトークンを記憶するステップ、又は、前記第１の参加デバイスの前記第２の遭遇トークンリスト及び前記第２の参加デバイスの前記第１の遭遇トークンリストに前記第１のトークンを記憶し、前記第１の参加デバイスの前記第１の遭遇トークンリスト及び前記第２の参加デバイスの前記第２の遭遇トークンリストに前記第２のトークンを記憶するステップと、
    ｄ）所与の参加デバイスが、該所与の参加デバイスによるアップロード条件の検出時に、前記第１の遭遇トークンリスト又は前記第２の遭遇トークンリストのうちの一方の少なくとも一部を近接管理サーバに選択的にアップロードするステップと
    を含んでなる、匿名近接追跡のコンピュータ実施方法。
  2. 前記全順序関数は、前記第１の参加デバイス及び前記第２の参加デバイスの前記それぞれの現在の公開鍵から導出された値を比較することによって前記ソート値を計算する、請求項１に記載の匿名近接追跡のコンピュータ実施方法。
  3. ステップｄ）は、前記第１の遭遇トークンリストからトークンをアップロードすることを含む、請求項１又は２に記載の匿名近接追跡のコンピュータ実施方法。
  4. ｅ）前記参加デバイスごとに、前記第２の遭遇トークンリストからの少なくとも１つのトークンを報告サーバに周期的に送信し、前記報告サーバは、別の参加デバイスが当該別の参加デバイスの第１のトークン遭遇リストから、前記第２の遭遇トークンリストからの前記少なくとも１つのトークンと同一のトークンをアップロードしたことを検出すると、前記第２の遭遇トークンリストを前記報告サーバに発した前記参加デバイスに、前記同一のトークンをアップロードしたことの検出を示すメッセージを送信するステップを更に含む、請求項３に記載の匿名近接追跡のコンピュータ実施方法。
  5. ｆ）前記参加デバイスごとに、前記第２の遭遇トークンリストからの少なくとも１つのトークンを報告サーバに周期的に送信し、前記第２の遭遇トークンリストからの前記少なくとも１つのトークンと、他の参加デバイスによって前記第１の遭遇トークンリストからアップロードされた前記トークンとの比較に基づいてリスクスコアを計算するステップを更に含む、請求項３又は４に記載の匿名近接追跡のコンピュータ実施方法。
  6. 前記非対話型鍵交換プロトコルは、Ｃｕｒｖｅ２５５１９、別の楕円曲線、楕円曲線ディフィ－ヘルマンプロトコル又はディフィ－ヘルマン鍵交換に基づくものである、請求項１～５のいずれか１項に記載の匿名近接追跡のコンピュータ実施方法。
  7. 前記第１の参加デバイス及び前記第２の参加デバイスのコロケーションに関するメタデータが、前記第１の遭遇トークンリスト及び前記第２の遭遇トークンリストのうちの一方において前記第１のトークン及び前記第２のトークンとともに記憶される、請求項１～６のいずれか１項に記載の匿名近接追跡のコンピュータ実施方法。
  8. 請求項１～７のいずれか１項に記載の方法を実行する命令を含むコンピュータプログラム。
  9. 請求項８に記載のコンピュータプログラムを記録したデータストレージ媒体。
  10. 請求項８に記載のコンピュータプログラムを記録したメモリに結合されたプロセッサを備えるコンピュータシステム。
JP2022567689A 2020-05-06 2021-05-06 匿名近接追跡の改善されたコンピュータ実施方法 Pending JP2023524829A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP20305453.1A EP3907928A1 (en) 2020-05-06 2020-05-06 Improved computer implemented method for anonymous proximity tracing
EP20305453.1 2020-05-06
PCT/EP2021/061963 WO2021224376A1 (en) 2020-05-06 2021-05-06 Improved computer implemented method for anonymous proximity tracing

Publications (1)

Publication Number Publication Date
JP2023524829A true JP2023524829A (ja) 2023-06-13

Family

ID=71103304

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022567689A Pending JP2023524829A (ja) 2020-05-06 2021-05-06 匿名近接追跡の改善されたコンピュータ実施方法

Country Status (5)

Country Link
US (1) US20230198758A1 (ja)
EP (1) EP3907928A1 (ja)
JP (1) JP2023524829A (ja)
CA (1) CA3182161A1 (ja)
WO (1) WO2021224376A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021225867A1 (en) * 2020-05-06 2021-11-11 Noodle Technology Inc. Contact tracing among workers and employees
CN114676169B (zh) * 2022-05-27 2022-08-26 富算科技(上海)有限公司 一种数据查询方法及装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2315465A1 (en) * 2009-10-20 2011-04-27 ETH Zurich Method for secure communication between devices
JP2016518075A (ja) * 2013-04-05 2016-06-20 インターデイジタル パテント ホールディングス インコーポレイテッド ピアツーピア通信およびグループ通信のセキュリティ保護

Also Published As

Publication number Publication date
CA3182161A1 (en) 2021-11-11
EP3907928A1 (en) 2021-11-10
WO2021224376A1 (en) 2021-11-11
US20230198758A1 (en) 2023-06-22

Similar Documents

Publication Publication Date Title
Kunal et al. An overview of cloud‐fog computing: Architectures, applications with security challenges
Reichert et al. A survey of automatic contact tracing approaches using Bluetooth Low Energy
Beskorovajnov et al. Contra corona: Contact tracing against the coronavirus by bridging the centralized–decentralized divide for stronger privacy
Hekmati et al. CONTAIN: Privacy-oriented contact tracing protocols for epidemics
Castelluccia et al. DESIRE: A Third Way for a European Exposure Notification System Leveraging the best of centralized and decentralized systems
Bell et al. Tracesecure: Towards privacy preserving contact tracing
Arifeen et al. Blockchain-enable contact tracing for preserving user privacy during COVID-19 outbreak.
Hasan et al. WORAL: A witness oriented secure location provenance framework for mobile devices
JP2023524829A (ja) 匿名近接追跡の改善されたコンピュータ実施方法
Li et al. Secure data deduplication protocol for edge-assisted mobile crowdsensing services
Tseng et al. Hierarchical and dynamic elliptic curve cryptosystem based self-certified public key scheme for medical data protection
Nath et al. A privacy-preserving mutual authentication scheme for group communication in VANET
Prasad et al. ENACT: encounter-based architecture for contact tracing
Ahmed et al. DIMY: Enabling privacy-preserving contact tracing
Gupta et al. Quest: Practical and oblivious mitigation strategies for COVID-19 using WiFi datasets
Pietro et al. Self-healing in unattended wireless sensor networks
Benssalah et al. A provably secure RFID authentication protocol based on elliptic curve signature with message recovery suitable for m‐health environments
Braeken et al. Highly efficient key agreement for remote patient monitoring in MEC-enabled 5G networks
Hassan et al. [Retracted] A Lightweight Proxy Re‐Encryption Approach with Certificate‐Based and Incremental Cryptography for Fog‐Enabled E‐Healthcare
Alansari et al. Efficient and privacy-preserving contact tracing system for COVID-19 using blockchain
Tedeschi et al. SpreadMeNot: A provably secure and privacy-preserving contact tracing protocol
Ghafghazi et al. Location-aware authorization scheme for emergency response
Franco et al. WeTrace: A privacy-preserving tracing approach
Boutet et al. DESIRE: Leveraging the best of centralized and decentralized contact tracing systems
Tang Another look at privacy-preserving automated contact tracing

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240409