Source-linked AI summary
A Survey of COVID-19 Contact Tracing Apps
Nadeem Ahmed, Regio A. Michelin, Wanli Xue, Sushmita Ruj, Robert Malaney, Salil S. Kanhere, Aruna Seneviratne, Wen Hu, Helge Janicke, Sanjay Jha
TL;DR
Contact tracing appには、architecture、privacy、security、efficacy、user adoptionをめぐる未解決の問題がある。本surveyでは、3つのarchitecture、提案されたapplications、報告されたuser concerns、attack vulnerabilitiesを検討し、すべての状況で普遍的に優れたarchitectureはなく、privacyとsecurityへの懸念がadoptionの中心に残ると結論づける。
問題
Contact tracing appでは、adoptionに影響するにもかかわらず、architecture、data management、efficacy、privacy、security、attack vulnerabilitiesについて包括的な評価が不足している。
方法
本論文では、3つのtracing-app architecture、提案されたapplications、報告されたuser concerns、proximity-estimation methods、ならびにappのsecurityとprivacyに対するattackをsurveyする。
結果
reviewの結果、architectureはprivacy protection、attack models、implementation complexity、operating costsの点で異なる一方、appはdata-management、accuracy、security、privacyに関する懸念に直面していることが示された。
示唆と限界
Architectureの選択は、政府のtechnology familiarity、既存processへのintegration、deploymentの容易さに依存する一方、user adoptionはtrust、transparency、data misuseに対するsafeguardsに依存する。
示唆と限界
RSSIのみに基づくproximity estimationは、環境干渉やphone間の差異が距離推定に影響するため、limitedである。
Abstract
from arXiv · showhide
The recent outbreak of COVID-19 has taken the world by surprise, forcing lockdowns and straining public health care systems. COVID-19 is known to be a highly infectious virus, and infected individuals do not initially exhibit symptoms, while some remain asymptomatic. Thus, a non-negligible fraction of the population can, at any given time, be a hidden source of transmissions. In response, many governments have shown great interest in smartphone contact tracing apps that help automate the difficult task of tracing all recent contacts of newly identified infected individuals. However, tracing apps have generated much discussion around their key attributes, including system architecture, data management, privacy, security, proximity estimation, and attack vulnerability. In this article, we provide the first comprehensive review of these much-discussed tracing app attributes. We also present an overview of many proposed tracing app examples, some of which have been deployed countrywide, and discuss the concerns users have reported regarding their usage. We close by outlining potential research directions for next-generation app design, which would facilitate improved tracing and security performance, as well as wide adoption by the population at large.
1 はじめに
COVID-19の無症候性伝播と手作業による接触者追跡の限界を背景に、スマートフォンベースの接触者追跡アプリが注目されている。そのアーキテクチャ、有効性、プライバシー、セキュリティが主要な論点となっている。本稿では、これらの属性と、現在および次世代の接触者追跡アプリ設計がもたらす含意を概観する。
- 動機: 無症候性の感染性により、感染者は検査で陽性となる前にCOVID-19を他者へ感染させる可能性があるため、迅速な接触者追跡が必要となる。手作業による追跡では、過去14–21日間の接触者について聞き取りを行う。しかし、感染者は面識のない接触者を特定できない場合があり、聞き取りを繰り返すには相当数の訓練を受けたスタッフが必要となる。
- 動機: スマートフォンは、GPSまたはWiFiによる位置追跡と、Bluetoothによる近接検知をサポートするため、接触者追跡の自動化に適している。研究者は、感染リスクが有意な接触者を迅速かつ確実に特定するため、これらの技術を追究している。
- 課題: 接触者追跡アプリをめぐっては、アーキテクチャ、データ管理、有効性、プライバシー、セキュリティについて議論が生じており 、プライバシー上の懸念が導入に影響を与えている 。大半のアプリは、ユーザーの明示的な許可なしに、接触者の個人識別情報、身元情報、または位置情報を開示しないと主張している。
- 構成: 本稿では、以降の分析を、集中型、分散型、ハイブリッド型アーキテクチャ、続いてセキュリティ、プライバシー、データ管理、BLE近接推定、攻撃または脆弱性という枠組みで構成する。これらの論点が本サーベイのSections 2–5を構成する。
2 システムアーキテクチャ · 2.1 集中型
本稿では、サーバーの利用形態に基づき、接触追跡アーキテクチャを集中型、分散型、ハイブリッド型に分類し、集中型では中核機能を信頼されたサーバーに割り当てる点を強調する。集中型のBluetraceベースプロトコル では、デバイスが暗号化された一時識別子を交換し、接触分析と通知はサーバー側で行われる。
- 2 システムアーキテクチャ: 本サーベイでは、サーバーの利用方法に基づき、COVID-19接触追跡システムを集中型、分散型、ハイブリッド型のアーキテクチャに分類する。
- 2.1 集中型: 集中型のBluetraceプロトコル では、ユーザーが事前登録を行い、サーバーが各デバイス向けに暗号化された、プライバシーを保護するTemporary IDを生成する。
- 2.1.1 登録フェーズ: 登録には個人情報の提供とSMSによる携帯電話番号の認証が必要であり、その後サーバーが短期間のみ有効なTempIDを計算する。Bluetraceは有効期限を15分後とすることを推奨している。
- 2.1.2 接触・コンタクト情報の登録: 接触時には、デバイス間でTempID、携帯電話モデル、TxPowerを交換し、RSSIとタイムスタンプを記録する。接触メッセージには電話番号を含めない。
- 2.1.3 接触データのアップロード: 接触記録は端末内に保持され、COVID-19陽性者が、医療当局による確認とOTP認証を受けた後に、自発的にアップロードするまで外部に送信されない。
- 2.1.4 アップロードデータのサーバー側処理: アップロード後、サーバーはTempIDを復号し、携帯電話番号に対応付け、TxPowerとRSSIを用いて接触の近接度を推定する。
- 2.1.4 アップロードデータのサーバー側処理: サーバーは近接度とタイムスタンプを組み合わせて接触リスクを判定し、医療当局向けの情報を準備する。信頼と規制が前提とされているにもかかわらず、サーバーへの集中化された責任はプライバシー上の懸念を生じさせる。
2.2 分散型
分散型アーキテクチャでは、identifierの生成と曝露通知処理をサーバーからユーザーデバイスへ移し、サーバーの役割を縮小するとともに、個人情報へのアクセスを制限する。デバイスはローカルシードから短寿命のpseudonymを生成し、ユーザーは感染者のシードをダウンロードした後、曝露をローカルで再構成する。
- アーキテクチャ: 分散型tracingでは匿名identifierを生成し、ユーザーデバイス上で曝露通知を実行するため、サーバーの関与は最小限に抑えられる。この設計は、サーバーと他のユーザーの双方に対して実際のidentityを秘匿することを目指す。
- Identifier生成: PACT では、デバイスがユーザーを事前登録したり、サーバーにPIIを保存したりすることなく、random seedと約1分間のpseudonym、すなわち「chirp」を生成する。シードは、現在時刻と組み合わせたpseudorandom functionへの入力となる。
- サーバーとプライバシー: サーバーはhonest-but-curiousなrendezvous pointとして機能し、感染者のシードを広告する。他のデバイスはそれをダウンロードし、identityを直接導出することなく、対応するchirpを再構成する。曝露リスクの分析をデバイス上で実行するのは、他のアプリユーザーだけである。
- 接触情報の交換: デバイスは数秒ごとにBluetooth経由で新しいchirpをbroadcastし、受信したchirpをtimestampおよび最大RSSIとともに保存する一方、1分以内に受信した重複は無視する。centralised architectureとは異なり、シードとchirpはいずれもサーバーではなくデバイス上で生成される。
- Tracingの過程: 認証済みの陽性診断後、ユーザーはローカルに保存されたシードとその生成時刻および失効時刻をuploadする。ダウンロードしたシードにより、過去のchirpをローカルで再構成して曝露をtracingできる。ユーザーは通常、感染者がアップロードしたseedをダウンロードするため、一日に一度サーバーへ接続する。
2.3 Hybrid・2.4 Architecture summary
Hybrid architectureはcontact tracing機能をサーバとデバイスに分担させる。一方、architecture summaryでは、サーバ機能とprivacy preservationの観点からcentralised、decentralised、hybridの設計を対比する。そのprotocolはprivacy-preserving registration、ephemeral identifiers、encounter tokens、server-assisted risk matchingを用いる。
- 2.4 Architecture summary: Hybrid architectureは、複雑なtracing機能をサーバとデバイスに分担させる。これは、機能をcentralisedするcentralised designsや、すべてをデバイスに委ねるdecentralised designsとは異なる。Hybrid modelでは、サーバはすべてのtracing operationを実行するのではなく、限定的なcoordinationおよびlookupの責務を保持する。
- 2.3 Hybrid: Desire protocol は、PIIを記録せずに各appへ一意のdevice IDを割り当て、BLE経由でcryptographic Ephemeral IDsを交換し、各encounterにつきunlinkableなPrivate Encounter Tokensを2つ保存する。protocolのinteraction sequenceはFigure 9に示されている。
- 2.3.1 Installation and registration: Hybrid registrationでは、phone-number OTPとserver-issued authorization-token authenticationを用い、その後app IDを割り当ててからphone numberとencryption keyを削除する。Figure 10はこのregistration processを示す。
- 2.3.2 Generating and exchanging Ephemeral IDs: デバイスはDiffie–Hellman key exchange を通じてEphIDsを生成し、通常は15分ごとにrotateさせ、受信した各identifierから2つのPETsを導出する。Figure 11はencounter processを示し、appはencounter data用のupload tableとquery tableを保持する。
- 2.3.3 Uploading Encounter data: positive diagnosis後、user ID、encryption key、PETs、timestamps、durationsをサーバへuploadする前に、明示的な同意が必要となる。サーバはPETsと関連データを記録し、encryption keyを用いてinfected userのstatusを更新する。
- 2.3.4 Contact tracing process: ユーザはproxyまたはanonymisation networkを介してexposureをqueryする。一方、サーバはPETsをmatchし、timeとdurationからriskを評価し、at-risk usersにhealth authoritiesへの連絡を通知する。Figure 12はnotification processを示す。
- 2.4 Architecture summary: 3つのarchitectureは、central serverに割り当てられたfunctionalityとprivacy preservationによって分類される。centralised systemsでは、security、identifier、risk-analysis、notificationの役割を保持する。architecture summaryでは、これらのserver responsibilitiesを、decentralised systemsにおけるデバイスへの移管、およびhybrid systemsにおける分担と対比する。
3 データ管理、プライバシー、セキュリティ
本節では、集中型、分散型、ハイブリッド型の接触追跡アーキテクチャにおけるデータ管理を比較し、政府、サーバ、デバイス、悪意あるユーザーに関わるプライバシーおよびセキュリティ上のリスクを検討する。アーキテクチャによって、データの所在、アクセス主体、攻撃によってプライバシー、完全性、可用性が侵害される方法が決まることを示す。
- データ管理、プライバシー、セキュリティ: 各アーキテクチャについて、どのようなデータが生成、交換、保存され、各ステークホルダーからアクセス可能であるかを評価する。政府、中央サーバ、悪意あるユーザー、陽性者の身元を把握する保健当局を分析対象とする。
- 集中型アーキテクチャ: 集中型システムでは、個人識別情報、temporary identifiers、陽性者の接触者リストをサーバに置く一方、デバイスには接触データを保持し、ユーザーの同意を得てアップロードする場合がある。サーバは定期的にTempIDsを生成して転送し、デバイスは通常21日間、指定期間の接触を生成、交換、保存する。
- 分散型アーキテクチャ: 分散型システムでは、hourly seeds、chirps、RSSI、タイムスタンプ、位置情報メタデータの可能性をデバイス上に保持し、サーバの役割はより限定的である。ユーザーはseedsをダウンロードし、感染ユーザーに関連するchirpsを計算できるため、side-channel情報を通じた識別リスクが生じる。
- ハイブリッド型アーキテクチャ: ハイブリッド型システムでは、デバイス上に接触をPET entriesとして保存し、サーバには限定的なデバイス情報を記録し、アップロードに自発的に同意した陽性ユーザーからのみPETsを受け取る。ハイブリッド型のプライバシー保護には、secret sharing、decisional Diffie-Hellman、private set intersectionが含まれ、一方の当事者が侵害されても、秘密全体やリスク分析結果は明らかにならない。
- プライバシー: 集中型アーキテクチャでは、侵害されたサーバに3つのデータカテゴリーすべてが露出するのに対し、分散型システムでは再識別のリスクがあり、ハイブリッド型システムではプライバシー保護計算によって開示を低減する。3つのカテゴリーは、参加者のPII、仮名化された接触広告、社会関係／近接グラフである。スマートフォンの窃取や強要によって、いずれのアーキテクチャでもデバイス保存データが露出し得る。
- セキュリティ: セキュリティ脅威には、データ窃取、誤った曝露通知、匿名性解除、誤入力、サーバが侵害されるか悪意ある主体と共謀した場合のサービス拒否が含まれる。したがって集中型サーバには、trusted execution environments、認証、アクセス制御が必要であり、すべてのアーキテクチャで完全性と可用性への脅威に対処しなければならない。
4 近接推定
近接推定は、感染リスクの評価において中心的な役割を果たす。これは、感染伝播の可能性が接触距離と接触時間に依存するためである。現在のスマートフォン手法は主にGPSとBluetooth RSSIに依存しているが、実環境では依然として信頼性が低く、近接推定誤差や誤分類を大きく生じさせる。
- 近接推定: 現在のアプリは主にGPSとBluetoothを用いて近接度を推定し、接触距離と接触時間に基づく感染リスクの評価を支援する。WiFiでも限定的な近接推定は可能だが、支援インフラと設定が必要である。
- 近接推定: Bluetoothは、無線信号が伝搬距離に応じて減衰することを利用し、path-loss modelによって信号強度と距離を関連付けてRSSIから距離を推定する。このモデルには基準距離におけるRSSIとpath-loss exponentが含まれ、受信機は記録されたRSSI値からおおよその距離を推定する。
- 近接推定: 壁、家具、人などの環境障害物やチャネル効果は、距離の影響を超えてRSSIを歪め、実環境における緩和策を制限する。path-loss exponentの変動によって一部の環境要因は捉えられるが、モデルパラメータが未知であることやノイズ分散によって、さらなる不確実性が生じる。
- 近接推定: 現在の近接推定技術はfalse positives and false negativesを生じさせ、実際には遠く離れた人々を近接接触と判定したり、近距離の接触を見逃したりすることがある。壁やその他の障害物によって、近接しているように見える距離推定が実際の曝露を反映しなくなる場合がある。例えば、隣接するアパート間の接触が挙げられる。
5 攻撃
本節では、中央集権型、分散型、ハイブリッド型の接触追跡アーキテクチャに対する攻撃を検討する。対象には、replay、tracking、location inference、enumeration、linkage、identifier-carryover attacksが含まれる。アーキテクチャ固有の設計選択が、攻撃範囲、識別可能性、耐性に影響する一方、追加センシングはプライバシー保証を低下させうることを示す。
- Replayおよびrelay attacks: Replay attacksは、メッセージを転送するだけで、最小限のリソースによりfalse positivesを誘発できる。一方、中央集権型、分散型、ハイブリッド型のアーキテクチャでは、脆弱性と被害対象の範囲が異なる。中央集権型でのreplayは、発信者を近接接触者として特定できる。分散型でのreplayは複数の受信者に影響しうるのに対し、ハイブリッド型プロトコルはreplayを防ぐが、relay attacksには依然として脆弱である。
- デバイス追跡: BLE advertisements、temporary identifiers、phone-model informationはデバイス追跡を可能にしうるが、識別子の有効期間が短いため、攻撃者が連続する識別子を結び付けない限り追跡は制限される。Address carryoverと、ある識別子の消失および直後の置換の分析により、識別子の変更が同期されている場合でも、anonymous-IDの有効期限を超えて追跡を継続できる。
- 位置推定およびenumeration attacks: 中央集権型の接触データは、既知のユーザーがある場所に存在するかどうかを明らかにしうる。一方、分散型のアップロードでは、共有されたseedsからユーザーが陽性者数を推定できる。サーバーが生成したchirpsを格納することで、陽性者数を隠すBloom filterが提案されている。
- Linkage attacks: Linkage attacksは、side-channelの相関を通じてユーザーをde-anonymize usersしうる。分散型システムでは陽性ユーザーが露見し、中央集権型システムでは近接接触者が露見しうるのに対し、ハイブリッド型プロトコルは一般にunlinkableである。中央集権型システムでは、モバイルモデル情報、隔離、接触時間、隔離された接触が識別を支援しうる。
- サーバーおよびプライバシー上の脅威: 攻撃者は無線接触を相関させたり、電話を盗んで相互作用データを採掘したりできるが、陽性検査を受けておらず、陽性患者との接触もないユーザーに関する相互作用を、悪意あるサーバーが開示することはできない。追加センサーや歩容認識は一部の追跡攻撃への対抗策となりうるが、より多くの文脈データや個人データを収集すると、プライバシー保証が弱まる可能性がある。
6 具体的なアプリとプロトコルの分析
本節では、三つの広範なシステムアーキテクチャを具体化した接触追跡アプリとプロトコルを取り上げ、各国における提案、開発、導入を扱う。
- 6 具体的なアプリとプロトコルの分析: 本節では、先に論じた三つの広範なアーキテクチャを具体化した追跡アプリとプロトコルを紹介する。アーキテクチャレベルの特徴、機能、攻撃への曝露から、具体的なシステムへと焦点を移す。
- 6 具体的なアプリとプロトコルの分析: 多くの国で提案、開発、導入が進められているシステムを扱う。Figure 15に、本分析で取り上げるアプリとプロトコルをまとめる。
- 6 具体的なアプリとプロトコルの分析: 議論は三つの節に分かれ、それぞれ異なるシステムアーキテクチャに焦点を当てる。
6.1 集中型アーキテクチャに基づくアプリ／プロトコル
集中型のcontact tracing実装には、BlueTraceベースのTraceTogetherとCovidSafe、ROBERTベースのStopCovid、BluetoothとGPSを組み合わせるAarogya Setuがある。これらは、保存データ、通知プロセス、識別子の有効期間、プライバシーまたは攻撃への曝露の点で異なる。
- 実装: BlueTraceベースのTraceTogether とCovidSafe は集中型アーキテクチャを用いる一方、ROBERTベースのStopCovid とAarogya Setu は別の実装に該当する。Aarogya SetuはBluetoothとGPSの両方を使用する。OpenTraceとStopCovidのソースコードは公開された 。
- TraceTogetherとCovidSafe: CovidSafeはTraceTogetherの15分間の有効期間に対し、2時間のTempIDsを使用するため、ダウンロード数を減らせる一方、リプレイ攻撃への脆弱性が高まる。それ以外では両アプリともBluetraceに従い、Table 4に列挙された攻撃に対する脆弱性を共有する。
- BlueTraceとROBERT: ROBERTはBlueTraceの個人識別情報ではなく匿名EphIDsを保存するため、より高いプライバシーを実現するが、リスク通知を受けるにはユーザーがサーバーを頻繁に確認する必要がある。プロトコルは通知プロセスも異なり、BlueTraceは対照的な通知メカニズムを用いる。
- BlueTraceとROBERT: ROBERTは、接触のリンク付けやソーシャルグラフ分析を妨げるため、陽性ユーザーのEphIDsを時間差をつけたランダムな順序でアップロードする。ただし、トラフィック分析によって報告が再び結び付けられる可能性がある。これに対しBlueTraceは、すべての接触情報を一度にアップロードする。
- Aarogya Setu: Aarogya Setuは、500 mから10 km以内の陽性例を示す分析のために、個人識別情報、接触情報、GPS位置情報、自己評価データを収集する。このアプリのAndroidコードは公開されたが、iOSコードとサーバーコードはまだ利用可能になっていなかった 。
6.2 分散型アーキテクチャに基づくアプリ／Protocol
本節では、Apple/GoogleのExposure Notification system、2つのPACT protocol、DP-3T、TCN、Pronto-C2、Hamagenを含む、分散型のcontact tracing protocolと実装を概観する。これらの設計は一般にtracing dataを端末内に保持し、privacy-preserving identifierを用いる一方、linkage、enumeration、精度、普及に関する懸念に、代替メカニズムによって対処する。
- Apple/Google Exposure Notification: AppleとGoogle は、保健当局向けアプリ用APIとOSレベルのsupportを備えた分散型Exposure Notification systemを提案し、SwissCoviDやCorona-Warn-App などの展開を可能にした。APIは20 May 2020に公開され、その後、単独アプリへの依存を減らすためのOS統合が計画された。
- PACT protocol: PACT East-coast とPACT West-coast [47]は、ローカルな暗号化ストレージ、pseudorandom identifier、任意のdata uploadを用いるが、linkage攻撃とenumeration攻撃の影響を受け得る。PACT East-coastは、接触状況を特定し、false positiveを減らす可能性を持たせるため、位置metadataを任意で保存する。一方、PACT West-coastはCovidSafe (UoW) の基盤となっている。
- DP-3T: DP-3T は、daily keyと、端末内に保存される期限付きBluetooth EphIDを用いる。一方、その‘Un-linkable’ designは、uploadされたkeyをserver-filtered EphIDに変換し、linkageとenumerationのリスクを低減する。Un-linkable designはserver processing timeを増加させ、false positiveを制限するためのCuckoo-filter tuningを必要とするが、false negativeを防ぎ、選択的なencounter uploadを支援する。
- その他のprotocolとapplication: その他の分散型アプローチには、compact keychain seedをuploadするTCN [49]、匿名端末通信をcentral serverから秘匿するPronto-C2 、Bluetooth encounterを記録する代わりにGPS historyを端末内で照合するHamagenがある。Hamagenのlocation dataは個人のphone外部に送信されないのに対し、Pronto-C2は特にmass surveillanceからの保護を目的とする。
6.3 ハイブリッドアーキテクチャに基づくアプリ／プロトコル
ハイブリッドプロトコルは、端末が生成する識別子と、サーバーを介したリスク分析・通知を併用し、集中型と分散型の機能を組み合わせる。DESIRE、ConTra Corona [64]、EpiOne [65]は、暗号技術とサーバー分離によって、リンク付け攻撃、列挙攻撃、ソーシャルグラフ攻撃を制限し、プライバシーの向上を目指す。
- DESIRE: DESIRE は、EphIDsとは異なる暗号学的に生成されたPETsと、クライアントが保持する暗号鍵を用いて、接触データの収集を防ぎ、侵害後もサーバーに保存されたデータを保護する。リスク分析と通知はサーバー側に残されるため、ユーザーが開始する列挙攻撃およびリンク付け攻撃の可能性が低下する。
- ConTra Corona: ConTra Corona [64]は、DDH鍵交換と分離されたサーバーを用いて、診断済みユーザーによるアップロードを検証し、分散型アプリに対するリンク付け攻撃を緩和する。そのプライバシー保護は、共謀しないサーバーと、匿名化または認証された通信チャネルを前提とする。
- ConTra Corona: ConTra Corona [64]は、日次の警告識別子、暗号化されたシード識別子、疑似乱数識別子を生成し、その後、15-of-45秘密分散を用いて、ブロードキャストから接触イベントを復元する。端末は、同じ乱数識別子に関連付けられたシェアを含むブロードキャストを15件蓄積すると、イベントを復元する。
- EpiOne: EpiOne [65]は、Private Set Intersectionを用いて、ユーザーが受信したトークンと、暗号化された陽性者シードから復元されたトークンを、いずれの集合も開示せずに比較し、列挙攻撃とソーシャルグラフの構築を防ぐ。陽性者は保健当局を通じて暗号化されたシードをアップロードし、ユーザーにはトークン集合の共通部分の濃度だけが知らされる。
7 一般的なユーザーの懸念
ユーザーの受容性はダウンロード数だけから推測できない。実際的な懸念には、バッテリー消費、デバイスおよびアプリの互換性、同意の撤回、透明性が含まれる。これらの懸念は、tracing applicationsへの信頼と、より広範な導入を制限し得る。
- バッテリー消費量: バッテリー消費量は、処理、データ管理、メッセージ交換、通信プロトコル、ならびにアプリがforegroundまたはbackgroundで実行されるかどうかに依存する。CovidSafeとTraceTogetherのiOS版ではbackground実行の問題が報告されている一方、Google–Appleのoperating-system supportは一部の制約に対処している。
- 互換性: 互換性の確保は依然として困難である。tracing appsが異なるoperating-system versionsをサポートしており、ユーザーが移動したり複数のアプリをインストールしたりする場合のアプリ間の挙動も不明確だからである。TraceTogetherとCovidSafeは、AndroidおよびiOSの異なる最低バージョンを必要とする一方、アーキテクチャの違いが相互運用性を複雑にしている。
- 同意の撤回: ローカルに保存された接触データについては同意の撤回は容易であるが、感染者が他のデバイスに到達するデータまたはseedsをアップロードした後は困難になる。分散型システムでは、転送されたseedsと再構成されたchirpsが、21日間の削除期間が経過するまで残存する可能性がある。
- 透明性と信頼: 透明性は、open-source codeとPrivacy Impact Assessmentsを通じて信頼を強化し得るが、ユーザーは依然として開発者、運用者、審査者、platform providersを信頼しなければならない。PIAsを伴うものとして報告されたのは、CovidSafe (AU)とDP-3Tのみであった 。
8 将来の方向性
本稿は、近い将来の研究課題として近接精度、完全分散型アーキテクチャ、適応型AIを優先し、より高性能で安全な追跡アプリケーションに向けた長期的機会として量子コンピューティング、量子センシング、量子通信を挙げる。
- 8 将来の方向性: 今後5年間の近い将来の研究では、近接精度、分散型アーキテクチャ、AIベースの感染可能性アルゴリズムを対象とすべきである。より長期的で推測的な研究は、5年後以降に先送りされる。
- 8 将来の方向性: 次世代アプリケーションでは、BLEの進展、Bluetooth様プロトコル、UWB、センサフュージョンによって近接推定を改善できる可能性があり、UWBは500MHz帯域幅を用いてcm級精度を実現できる可能性がある。融合する入力として、WiFi、Enhanced-GPS、ジャイロスコープ、加速度計が提案されている。
- 8 将来の方向性: プライバシー上の懸念に対処し、行政機関への依存を前提とするアーキテクチャを超えて、より広範な公衆の導入を促すには、完全分散型のpeer-to-peer感染追跡が必要である。調査対象のアプリケーションはすべて、程度の差はあるものの中央サーバを使用している。
- 8 将来の方向性: AIベースのアルゴリズムは、真の感染者の同定、見逃し、偽陽性という結果に適応することで、感染可能性の判定を動的に改善できる可能性がある。携帯電話の処理能力の向上により、端末上で動作するアルゴリズムはますます高度化している。
- 8 将来の方向性: 量子コンピューティング は、量子機械学習や、より高い計算能力を用いた高度なMonte-Carlo追跡または粒子フィルタ追跡によって、将来の追跡を支援できる可能性がある。量子コンピューティングは近く大きな発展と商用化の突破口に達する可能性があるため、今すぐ研究を開始することを本稿は推奨する。
- 8 将来の方向性: 量子センシング はタイミング、同期、加速度、位置精度を改善できる可能性があり、量子通信 は追跡のセキュリティとプライバシーを強化できる可能性がある。量子通信にはすでに商用製品が存在し、原理実証段階の宇宙配備も行われている。
9 結論
接触追跡アプリは、保健当局が曝露の可能性を特定する能力を強化し得るが、万能薬ではなく、アーキテクチャ上のトレードオフ、プライバシー上の懸念、任意の導入という制約を受け続ける。本論文は、こうした技術上およびサイバーセキュリティ上の論点について、研究者、利用者、機関に情報を提供することを目的とする。
- 9 結論: 接触追跡アプリは、曝露した可能性のある人々を保健当局が迅速に特定するのに役立ち得るが、パンデミック時の追跡に伴う課題を単独で解決することはできない。本論文は、これらのアプリが追跡能力を向上させ得る一方で、利用者、データ保護機関、研究者からの懸念にも直面していることを強調する。
- 9 結論: アーキテクチャの選択には、利点、欠点、攻撃モデル、保護策、実装の複雑さ、運用コストの違いが伴う。政府による選択は、技術への習熟度、既存の追跡プロセスとの統合、導入の容易さに左右される。
- 9 結論: 利用者による導入は任意であり、個人識別情報のプライバシーとセキュリティに関する懸念は、アプリ普及の中心的な障壁として残っている。こうした懸念は、接触追跡アプリを通じて収集されるPIIに関連して利用者から提起されている。
- 9 結論: 利用者はすでに、WiFi、携帯電話基地局、GPSアプリ、カメラ、その他のアプリケーションを通じて広範な追跡を受けており、それらのセキュリティとプライバシーへの影響は不明確な場合がある。本論文は、接触追跡アプリを、既存の追跡技術および日常的にインストールされているアプリケーションから成る、より広範なエコシステムの中に位置づける。
- 9 結論: 本論文は、研究者が接触追跡アプリの技術とサイバーセキュリティを理解できるよう支援するとともに、利用者や機関による、より十分な情報に基づく任意の導入判断を支援することを目指す。想定読者には、研究コミュニティ、利用者、および各自の地理的地域で提供されるアプリを評価する機関が含まれる。