スイスの新型コロナウイルス感染者接触追跡アプリケーションで使われる仕組み DP-3T

スイスでも、新型コロナウイルスの感染追跡ツールとしてスマートフォンの利用が検討されています。既にアジア各国やイギリスではスマートフォンを用いた感染追跡は実用化されていますが、プライバシー保護が厳格なスイスにそのままの形で導入することは難しいため、より個人情報に配慮した DP-3T (Decentralized Privacy-Preserving Proximity Tracing; 分散型プライバシー保護接触追跡) という仕組みを考案し、Apple, Google とも協力して開発が進められています。

DP-3T の詳細インターネット上で公開されています。ホワイトペーパーを読んでみましたが、なかなか巧妙で面白い仕組みだったので、覚書を残しておきます。

経緯

DT-3T は、スイスを代表する理工系大学であるスイス連邦工科大学ローザンヌ校とチューリッヒ工科大学の共同プロジェクトとして始まり、最終的に欧州の25人の科学者・研究者の手によってまとめられました。成果物は下記サイトで公開されています。

https://github.com/DP-3T/documents

背景

接触追跡の目的は、新型コロナウイルス感染者が判明した場合に、その人が発病した日以降に一定以上の接触があり新型コロナウイルスに感染している可能性がある人間を特定し、それ以上の感染拡大を防ぐことです。

伝統的な手法としては感染者に対する聞き取り調査があり、またアジア諸国で導入されているスマートフォンの位置情報を利用する方法もありますが、いずれも欠点があります。

聞き取り調査

  • 高度な訓練を受けた専門家の関与が必要なため、実施可能な件数が限られ、時間がかかる。
  • 感染者の記憶と自己申告に頼ることになるため、記憶が曖昧な場合や本人が申告しないケース（知られたくないお店や相手への訪問など）は追跡ができない。

位置情報を利用する方法

  • 当局がアプリケーション利用者の行動履歴を追跡できるため、プライバシー侵害の懸念がある。
  • システムに侵入された場合に、利用者の行動履歴が漏洩する。特に感染者が特定された場合のリスクが大きい。

DP-3T は専門家による聞き取り調査を置き換えるものではありませんが、それを補完する仕組みとして機能します。

仕組み

ホワイトペーパーでは低コスト分散接触追跡 (Low-cost decentralized proximity tracing) と、それを発展させた連結不能分散接触追跡 (Unlinkable decentralized proximity tracing) という二つのデザインが提示されています。とりあえず、前者のみ。

概要

短寿命識別子の処理と記録

  1. 各スマートフォンは、スマートフォン内で短寿命識別子 (ephemeral identifier, EphID) を生成し、それを一定間隔で周囲に送信する。
  • この EphID は頻繁に変更されるため、受信者が送信者を特定・追跡するためには使えない。
  • EphID の送信には Bluetooth Low Energy (BLE) という規格を用いる。これは短距離通信のための規格なので、受信するためには物理的に送信者の近くにいる必要がある。
  1. EphID を受け取ったスマートフォンは、EphID とおおよその受信時刻、ならびに受信していた期間を記録しておく。

感染者情報の登録と接触者への通知

  1. 患者が新型コロナウイルスに感染していることが判明した場合、感染者は保健当局の承認を得て、感染していた期間に送信した EphID の圧縮表記 (compact representation) をサーバーに登録する。
  • compact representation は複数の EphID を圧縮してまとめたもので（詳細は後述）、受信者は compact representation から EphID を計算で求めることができる。
  1. 他のスマートフォンは定期的にサーバーから感染者の compact representationを受信し、それから感染者が過去に送信した EphID を計算する。
  2. 以前に受信・保存していた EphID と感染者が送信した EphID が一致していた場合、そのスマートフォンは感染者のスマートフォンと過去に近接していたことになる。近接していた期間・距離などから感染リスクを計算し、感染リスクが高い場合にはスマートフォンに通知を表示する。

詳細

初期設定

スマートフォンでは、毎日、そのスマートフォン固有の秘密鍵を生成する。t を分散型接触追跡システム全体で共有された基準日からの経過日数、その日のスマートフォン固有の鍵を SKt と表記する。（この SKt が概要で挙げた compact representation に相当）

スマートフォンに接触追跡アプリケーションをインストールすると、スマートフォンはランダムに最初の SKt の値を決める。この値はスマートフォン内に記録され、この時点では誰とも共有されない。

短寿命識別子の生成

スマートフォンは接触者を漏れ無く記録するため、可能な限り多くの EphID を受信・記録できる必要がある。

したがって同時接続数に上限がある接続型の通信を使うことはできず、非接続型の Bluetooth Low Energy ビーコン機能を利用する。Bluetooth Low Energy ビーコンの技術的制約により、EphID のサイズは 16 バイトとなる。

まずスマートフォンは、毎日、秘密鍵を変更する。H を暗号学的ハッシュ関数とし、基準日から t 日目のカギは前日の秘密鍵 SKt-1 から次のように求める。

SKt = H(SKt-1)

なお暗号学的ハッシュ関数の性質上、

  1. SKt-1 から SKt を計算するのは簡単だが、逆は難しい。
  2. SKt は固定長

ということが保証される。

同一の単寿命識別子を長時間送信すると、その識別子を用いて送信者を追跡することが可能になるため、スマートフォンは頻繁に単寿命識別子を変更する必要がある。同一の単寿命識別子を送信する時間を l 分とする（システム全体で共有する設定値）。

毎日の開始時に、スマートフォンはデバイス内で n = (24 * 60) / l 個の単寿命識別子を、下記の式に従って計算する。

EphID1 || EphID2 || ... EphIDn = RPG(RPF(SKt, "broadcast key"))

左辺の || は文字列の連結。言い換えると、右辺の出力結果を 16 バイト単位で切り出して、順に EphID1, EphID2, … とするという意味。

  • RPF: 擬似乱数関数（HMAC-SHA256など）
  • スマートフォンのみが知っている暗号鍵 SKt を初期値（シード）とし、公開された文字列のハッシュ値を計算する。
  • PRG: ストリーム暗号 (AES-CTR モードなど)
  • 上記の擬似乱数関数の出力を秘密鍵として、n*16バイトのデータを生成。
  • 注記：RPG はストリーム暗号とあるが、ここでは暗号化ではなく任意長の乱数生成が目的なので、暗号化する平文は存在しない。たとえば平文とノンスは全ビット0の固定値として構わない。
  • “broadcast key”: システム全体で共有される公開固定文字列

ここでも SKt が分かっていれば EphID を計算するのは容易だが、逆に EphID から SKt を計算するのは難しい。

スマートフォンは、こうして生成した EphID1, EphID2, … をランダムな順番で、それぞれ l 分ずつ送信する。

受信した単寿命識別子と、生成した秘密鍵 SKt の記録

スマートフォンは、受信した単寿命識別子を、近接度合（信号強度）、時間（長さ）、ならびにおおよその時刻（例：4月2日）と共にスマートフォン内部に一定期間保存しておく。同時に、スマートフォンは生成した秘密鍵 SKt もスマートフォン内部に14日間保存しておく。

保存期間は保健当局のガイダンスによって定められ、システム全体での設定項目として扱われる。

分散型接触追跡

このプロセスの参加者

  1. 感染者のスマートフォン
  2. 他のユーザのスマートフォン
  3. サーバー
  4. 保健当局

サーバーは通信の媒介者としてのみ機能し、一切のデータ処理を行わない。

保健当局は感染者に検査結果を伝えるとともに、感染者がサーバーにデータをアップロードすることを許可し、また伝染条件（感染者と何メートル以内に何分いたら感染リスクが有ると見なすか）を決定する。また疫学者が、発症何日前から他人に（無症状でありながら）感染させる可能性があるかを推定する。

感染者は、他人に感染させた可能性がある最初の日に自身のスマートフォンが用いた秘密鍵 SKt と、その日 t の組 (SKt, t) をサーバーにアップロードする。なお、この時点で用いていた SKt は破棄し、再度、初期設定からやり直す。

サーバーは、分散型接触追跡アプリケーションをインストールしている全てのスマートフォンに、定期的に感染者が用いていた (SKt, t) の組を送信する。

受信したスマートフォンは (SKt, t) の組から、感染者が送信した可能性がある単寿命識別子を計算し、過去に受信して記録してあるデータと照合する。もし過去に受信したデータに含まれていた場合、アプリケーションは記録してある近接度合い、時間から感染リスクを計算し、感染の可能性が高い場合には、スマートフォンに通知を表示する。

感想

プライバシー

プライバシーに対する配慮が、良くなされていると思います。

新型コロナウイルスに感染していることが判明した場合、当然ながら、検査を行った医師や届け出を受けた保健当局は感染者の情報を知ることができます。しかし、感染者の行動履歴は当局も知ることができません (*1)。

その他のユーザについても行動履歴が当局に知られることはなく、また感染者と濃厚接触が合ったと判明した場合でも、その事実が分かるのはスマートフォンから通知を受けた本人だけです。第三者が知ることはできません。

これに対して、スマートフォンが位置情報を政府機関に定期的に報告し、政府機関の方で近い位置にあったデバイスを突き合わせる方式だと、利用者の行動を政府機関が完全に把握できることになります。

(*1) 厳密には、資金力と高度な技術力がある組織が Bluetooth Low Energy ビーコンの情報を多数の箇所で収集した場合、秘密鍵 SKt が公開された時点で遡って感染者の行動履歴を追跡できる可能性があります。この点を改善する連結不能分散接触追跡 (Unlinkable decentralized proximity tracing) という方法も、ホワイトペーパー中で議論されています。

追跡の完全性

またシステムが限りなく自動化されており、利用者が手作業で行う作業が少ないのも利点です。ビルに入退出するたびに、そこにある 2D バーコードをスキャンするようなシステムも考えられますが、これだと面倒ですし、うっかり忘れたりする可能性も高い。そうなると、追跡に漏れが出てきます。

システム負荷

Bluetooth Low Energy ビーコン規格を使うことで、スマートフォンのバッテリー消費電力への影響を小さく抑えています。

またサーバーを介してやり取りされる情報が、極めて小さく抑えられています。

ユーザ同士が接触した際にスマートフォン間でやり取りされる情報は短寿命識別子ですが、感染者が出た場合にサーバー経由でやりとりされる情報は、その感染者が「他人に感染させた可能性がある最初の日」に用いていた秘密鍵と日の組 (SKt, t) 1 つだけです。

ある日に用いていた秘密鍵 SKt が分かれば、

SKt = H(SKt-1)

という計算を行うことで、その日以降の秘密鍵 SKt は全て求めることができ、さらに SKt が分かれば、感染者のスマートフォンが送信した単寿命識別子も

EphID1 || EphID2 || ... EphIDn = RPG(RPF(SKt, "broadcast key"))

として全て計算できるため、全ての単寿命識別子をサーバー経由でやりとりする必要がありません。