筆記: COVID-19 Contact Tracing Technology

Published:
  Lastmod: 2023-01-16
by Ernest Chiang

(圖說：凡走過必留下痕跡，那近距離接觸過後能否留下某種痕跡呢。圖片來源。)

April 10, 2020 這天，Apple 與 Google 同時發布了一份新聞稿：「Apple and Google partner on COVID-19 contact tracing technology」。並且各自提供了 Apple iOS 與 Google Android 兩個平台上的 API 工具，以及對應的 Contact Tracing Bluetooth Specification 與 Contact Tracing Cryptography Specification 文件。

推測 Flutter team 應該也會很快推出套件（吧）。

這份筆記打算從隱私與藍牙規格開始逐步閱讀，藉由閱讀筆記的整理，學習如何規劃技術架構，來解決未來的其他挑戰。

以下筆記內容有些段落是我閱讀過程之中或之後的觀察與補充，筆記的目的是增進我的學習效率，與保持分享的習慣。

文件清單

先將 Apple 與 Google 兩邊新聞稿所提及的技術文件列舉出來：

新聞整理

有些媒體已將技術文件內容圖像化解說，方便大眾理解。

重點資訊

  • 需要明確的用戶同意。
  • 不收集個人可識別化資訊、不收集使用者位置資訊。
    • 為了維持使用者隱私，不採集可識別化資訊與位置資訊。
    • 所以原本可以在雲端比對運算的任務下放到使用者手機做比對。
    • 有區分信號 (beacon) 和信號密鑰 (beacon key) 兩種資料。
    • 只有信號密鑰 (beacon key) 會在明確的用戶同意下，傳輸至公共衛生機構的雲端。
  • 只留存接觸紀錄，使用者在自己手機做比對。（不是在各和機構的雲端進行比對，然後推送通知。）
  • 需要知道的事實 (fact) 是「自己是否曾與檢測陽性者接觸過」。（不是「自己曾與哪一位檢測陽性者接觸過」。）

隱私安全

Apple 與 Google 都很在意維護使用者隱私。Google 列舉的四份文件的第一份就是在講隱私：Privacy-safe contact tracing using Bluetooth Low Energy，並附上圖像解說。以下簡單筆記。

簡單翻譯中文（未來官方可能會提供翻譯版本，請以官方為準）（括號內容是我自己的推論）：

  • 需要明確的用戶同意。
  • 不收集個人可識別化資訊、不收集使用者位置資訊。
  • 曾接觸者清單只存在該手機裝置中，不會離開該手機裝置。（意思應該是說不會透過任何通訊方式，離開該手機裝置。例如不會上傳雲端。）
  • 被檢測陽性者（該自然人），無法被其他使用者、Google、Apple 識別出來。（技術架構規劃精神著重在呈現事實資料。使大眾或第三方無需進行獵巫？）
  • 將只被用在公共衛生機構用於接觸追蹤 COVID-19。（依照圖說，會有公共衛生機構的應用程式 (app) 可以輸入使用者自己被檢測陽性的結果。）
  • 在 Android 手機或 iPhone 手機皆可交互使用。

原文備用：

  • Explicit user consent required
  • Doesn’t collect personally identifiable information or user location data
  • List of people you’ve been in contact with never leaves your phone
  • People who test positive are not identified to other users, Google or Apple
  • Will only be used for contact tracing by public health authorities for COVID-19 pandemic management
  • Doesn’t matter if you have an Android phone or an iPhone - works across both

使用情境描述：

  1. Alice 和 Bob 第一次碰面，互相聊了 10 分鐘。
    • 此時雙方手機互相交換匿名識別信號 (anonymous identifier beacons)，這個信號會時常更換。
  2. 幾天後，Bob 被檢測 COVID-19 陽性，並將測試結果輸入公共衛生機構發佈的 app 中。
    • 在 Bob 的同意下 (user consent)，他的手機上傳最近 14 天自己曾經廣播出去的（前述）匿名識別信號密鑰 (beacon keys) 至雲端。（是上傳自己的信號密鑰 (keys)，不是曾接觸者信號清單 (beacon list)。）
    • 雲端應該要是個短期的暫時儲存空間。
  3. Alice 繼續著日常生活而尚未得知曾經靠近過可能有傳染性的人。
    • Alice 的手機會定期下載她所在區域的檢測陽性者的信號密鑰 (broadcast beacon keys)。配對找到自己的手機中層紀錄有 Bob 的匿名識別信號 (beacon)。
  4. Alice 在手機上看到曾靠近過 COVID-19 檢測陽性者的通知。
    • Alice 的手機收到通知，通知中含有接下來該怎麼做的指引資訊。更多資訊將由公共衛生機構的 app 或網站提供。

Contact Tracing 藍牙規格

曾經參與過 Bluetooth SIG Working Group 工作小組，順手閱讀一下藍牙規格書應該也是合理的 XD （明明就是求知慾旺盛呀？！）

這一段就不做太多翻譯，預計會是中英文夾雜的筆記。盡量保留原文、原名詞，這樣未來開發者在開發文件中比較好做對應。

這裡只是筆記，若要參照，請務必使用官方釋出的文件。

v1.1, April 2020

封面第一頁開宗明義先講「Preliminary - Subject to Modification and Extension」。

第二頁內容目錄：

  • Overview
  • Definitions
  • Contact Detection Service
  • Advertisement Payload
  • Advertising Behavior
  • Advertising Flow
  • Scanning Behavior
  • Scan Power Considerations
  • Scanning Flow
  • Privacy

目錄看起來很多項目，但其實整個 PDF 檔案只有 6 頁，扣掉封面和目錄，只剩下 4 頁。是一份相當精簡、易讀的藍牙規格文件。大家不妨也下載下來閱讀品嚐一下，拉近自己與藍牙的距離 :) 若是產業內的產品經理、開發人員，也可以學習模仿規格文件的組織結構。

Overview

  • 這份文件記載著新的、預留隱私的藍牙通訊協定，以支援 Contact Tracing (接觸追蹤)。
  • Contact Detection Service 將作為載體以實作出 Contact Tracing (接觸追蹤)，並使用 Bluetooth LE (Low Energy) 作為對附近智慧型手機的接近偵測 (proximity detection)，及定義資料交換機制。

Definitions

  • Contact Detection Service - The BLE service for detecting device proximity.
  • Tracing Key - A key that is generated once per device.
  • Daily Tracing Key - A key derived from the Tracing Key every 24 hours for privacy consideration.
  • Diagnosis Key - The subset of Daily Tracing Keys which are uploaded when the device owner is diagnosed positive for the COVID-19 virus. (若需要上傳雲端，且使用者同意時，會是這個 Diagnosis Key。)
  • Rolling Proximity Identifier - A privacy preserving identifier derived from the Daily Tracing Key and sent in the bluetooth advertisements. It changes every ~15 minutes to prevent wireless tracking of the device. （會被藍牙廣播出去的是這個 id，從 Daily Tracing Key 分出。約每隔 15 分鐘變更一次。）

Contact Detection Service

  • Contact Detection Service 是個 BLE service，已向 Bluetooth SIG 註冊使用此 16-bit UUID 0xFD6F。
    • 剛剛 (April 11, 2020 23:50) 查詢 Bluetooth SIG 官網會員可申請註冊的 16-bit UUID 清單，還沒出現這一組 UUID，很好奇會歸在哪家公司下面。
    • 以時間點推算可能在 20/March/2020 至 02/April/2020 之間派發此組 UUID。並且暫時隱藏。
    • 放一個螢幕截圖給大家參考：
    • 更新 2020/05/06 螢幕截圖，由 Apple 註冊這組 UUID：
  • Rolling Proximity Identifier 有 128-bit。
  • 藍牙廣播包的 AD Type 定義請參考官網這裡。
    • 0x01: «Flags»
    • 0x03: «Complete List of 16-bit Service Class UUIDs»
    • 0x16: «Service Data - 16-bit UUID»
  • 現階段的情境應用，大多數的欄位都是固定的，會週期性變動的只有 Service Data 裡最末段的 128-bit (16-bytes) Rolling Proximity Identifier。

Advertising Behavior

  • Advertisements are to be non-connectable undirected of type ADV_NONCONN_IND (Section 2.3.1.3 of 5.2 Core Spec).
  • The advertiser address type should be Random Non-resolvable.
  • On the platforms supporting Bluetooth Random Private Address with randomized rotation timeout interval, the advertiser address rotation period shall be a random value, greater than 10 minutes and less than 20 minutes.
  • The advertiser address and Rolling Proximity Identifier shall be changed synchronously so address and Rolling Proximity Identifier can not be linked.
  • A separate advertising instance should be used, if HW allows, to provide advertising reliability and flexibility in choosing optimal interval.
  • The advertising interval is subject to change, but is currently recommended to be 200-270 milliseconds.

Advertising Flow

Scanning Behavior

有人廣播 (advertising) 就可能有人掃描 (scanning) 然後得以接收，以下是關於 Scanning 的部分。

  • Discovered Contact Detection Service advertisements shall be kept on the device.
  • Scan results shall be timestamped and RSSI-captured per advertisement. （RSSI 值可以推估與發送裝置之間的距離。只能推估。）
  • Scanning interval and window shall have sufficient coverage to discover nearby Contact Detection Service advertisers within 5 mins.
  • Scanning strategy that works best is opportunistic (leveraging existing wakes and scan windows) and with minimum periodic sampling every 5 mins.

Scan Power Considerations

  • Platforms running the Contact Detection Service should be designed to account for large volume of advertisers in public spaces that shall rotate their Random Non-resolvable address and Rolling Proximity Identifier frequently.（設計時請考量到在公共空間會有大量廣播包的情境。之前自己團隊曾測試過 50~100 個裝置（其他產品應用情境）同時在相同空間廣播是可行，但如果數量更多，有可能就需要動態調整 advertising interval。）
  • Wherever supported by HW and OS, Bluetooth controller duplicate filters and other HW filters should be used to prevent excessive power drain.

Scanning Flow

Privacy

  • 保持、維護使用者隱私是這個規格在設計時的基本要求。
  • Contact Tracing Bluetooth Specification 沒有使用位置資訊來做 proximity detection。完全地、嚴謹地使用 Bluetooth beaconing 來偵測 proximity。
  • A user’s Rolling Proximity Identifiers changes on average every 15 minutes, and needs the Daily Tracing Key to be correlated to the user. This reduces the risk of privacy loss from advertising them.
  • Proximity identifiers obtained from other devices are processed exclusively on device.
  • Users decide whether to contribute to contact tracing. (使用者自己可以決定是否參與)
  • If diagnosed with COVID-19, users consent to sharing Diagnosis Keys with the server. (若被確診，使用者自己同意將分享 Diagnosis Keys 到伺服器。)
  • Users have transparency into their participation in contact tracing. (對參與者公開透明)

FAQ

陸續收到一些反饋與討論，整理如下：

  1. 請問個非常門外的問題：手機互相交換匿名識別信號 (anonymous identifier beacons)，這件事的地理範圍（距離）能夠多遠啊？
    • 距離是基於藍牙技術的通訊距離，如果是有通過藍牙認證的裝置（市售品應該都需要通過藍牙認證），則最遠距離約在 10 公尺左右，依照裝置以及裝置間的阻礙物而定。科普可參考：https://en.wikipedia.org/wiki/Bluetooth_advertising
    • 沒有通過藍牙認證的裝置，就… 不好說了 把線路天線或晶片天線改接在衛星收發站應該也是可行 XDD 可能可以量測星球與星球之間的 Contact Tracing （歪樓

先暫時閱讀到這邊。之後完成其他文件的閱讀，再陸續更新。

希望大家繼續勤洗手、保持社交距離、保持健康。

Revision History

  • 2020-04-12 00:30: Init. 先閱讀了使用情境與藍牙規格文件。
  • 2020-04-12 14:30: 整理重點。加上 FAQ 段落。
  • 2020-04-13: 加上 Advertising AD Type 參考連結。

因為主要使用了 Bluetooth 技術，身為 Bluetooth 技術愛好者，請容我加上這個 hashtag： #BluetoothCanHelp

（Bluetooth SIG 可以減免我的年費嗎？ XDD）

Loading comments…