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
접촉 추적 앱은 아키텍처, 프라이버시, 보안, 효능, 사용자 채택과 관련해 해결되지 않은 질문을 제기한다. 이 survey는 세 가지 아키텍처, 제안된 애플리케이션, 보고된 사용자 우려, 공격 취약성을 검토하며, 어떤 아키텍처도 보편적으로 더 우수하지 않고 프라이버시와 보안 우려가 여전히 채택의 핵심임을 결론짓는다.
문제
접촉 추적 앱은 아키텍처, 데이터 관리, 효능, 프라이버시, 보안, 공격 취약성에 대한 종합적 평가가 부족하며, 이러한 문제들이 채택에 영향을 미치고 있음에도 그러하다.
방법
이 논문은 세 가지 접촉 추적 앱 아키텍처, 제안된 애플리케이션, 보고된 사용자 우려, 근접성 추정 방법, 앱 보안과 프라이버시에 대한 공격을 survey한다.
결과
이 review는 아키텍처가 프라이버시 보호, 공격 모델, 구현 복잡도, 운영 비용에서 서로 다르며, 앱에는 데이터 관리, 정확도, 보안, 프라이버시 우려가 존재한다고 밝힌다.
시사점 및 한계
아키텍처 선택은 정부의 기술 친숙도, 기존 프로세스와의 통합, 배포 용이성에 좌우되며, 사용자 채택은 신뢰, 투명성, 데이터 오용 방지 보호조치에 좌우된다.
시사점 및 한계
RSSI에만 기반한 근접성 추정은 환경 간섭과 휴대전화 간 차이가 거리 추정에 영향을 미치기 때문에 제한적이다.
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의 무증상 전파와 수동 추적의 한계로 인해 smartphone 기반 contact-tracing app이 주목받고 있으며, 이러한 앱의 architecture, efficacy, privacy, security가 핵심 쟁점이 되었다. 이 논문은 이러한 속성과 현재 및 새롭게 등장하는 tracing-app 설계의 함의를 조사한다.
- 동기 부여: 무증상 감염 전파가 가능하므로 감염자는 양성 판정을 받기 전에 COVID-19를 전파할 수 있으며, 이에 따라 신속한 contact tracing이 필요하다.수동 추적은 지난 14–21일 동안의 접촉자를 대상으로 한 면담에 의존하지만, 감염자는 모르는 접촉자를 식별하지 못할 수 있고 반복 면담에는 상당한 규모의 훈련된 인력이 필요하다.
- 동기 부여: Smartphone은 GPS 또는 WiFi를 통한 위치 추적과 Bluetooth를 통한 근접성 탐지를 지원하므로 contact tracing을 자동화하는 데 적합하다.연구자들은 이러한 기술을 활용해 감염 위험이 상당한 접촉자를 빠르고 신뢰성 있게 식별하고자 한다.
- 과제: Tracing app은 architecture, data management, efficacy, privacy, security를 둘러싼 논쟁을 촉발했으며, privacy에 대한 우려가 도입에 영향을 미쳤다.대부분의 app은 명시적인 사용자 허가 없이는 접촉자의 personally identifiable information, 신원 정보 또는 위치 정보를 공개하지 않는다고 주장한다.
- 구성: 이 논문은 이후 분석을 centralized, decentralized, hybrid architecture를 중심으로 구성한 뒤, security, privacy, data management, BLE proximity estimation, 그리고 attack 또는 vulnerability를 다룬다.이 주제들은 survey의 Sections 2–5를 구성한다.
2 시스템 아키텍처 · 2.1 중앙집중형
이 논문은 서버 사용 방식에 따라 중앙집중형, 분산형, 하이브리드 tracing architecture를 구분하며, 중앙집중형 설계에서는 핵심 기능을 신뢰된 서버에 할당한다는 점을 강조한다. 중앙집중형 Bluetrace 기반 protocol 에서는 기기들이 암호화된 임시 식별자를 교환하고, 접촉 분석과 알림은 서버 측에 남는다.
- 2 시스템 아키텍처: 이 survey는 서버 사용 방식에 따라 COVID-19 tracing system을 중앙집중형, 분산형, 하이브리드 아키텍처로 분류한다.
- 2.1 중앙집중형: 중앙집중형 Bluetrace protocol 에서는 사용자가 사전 등록을 하고, 서버가 기기를 위한 암호화되고 privacy-preserving한 Temporary ID를 생성한다.
- 2.1.1 등록 단계: 등록에는 개인정보 입력과 SMS를 통한 mobile-number verification이 필요하며, 이후 서버는 수명이 짧은 TempID를 계산한다. Bluetrace는 TempID가 15분 후 만료되도록 권장한다.
- 2.1.2 접촉/연락처 정보 등록: 접촉 중 기기들은 TempID, phone model, TxPower를 교환하고 RSSI와 timestamp를 기록하며, phone number는 접촉 메시지에서 제외된다.
- 2.1.3 접촉 데이터 업로드: 접촉 기록은 COVID-19 양성 사용자가 보건당국의 확인과 OTP verification을 받은 뒤 자발적으로 업로드할 때까지 로컬에 남는다.
- 2.1.4 업로드된 데이터의 서버 측 처리: 업로드 후 서버는 TempID를 복호화하고 이를 mobile number에 매핑하며, TxPower와 RSSI를 사용해 접촉 근접도를 추정한다.
- 2.1.4 업로드된 데이터의 서버 측 처리: 서버는 근접도와 timestamp를 결합해 접촉 위험을 판정하고 보건당국을 위한 정보를 준비한다. 신뢰와 규제가 전제되더라도 중앙집중형 책임은 privacy concerns를 높인다.
2.2 탈중앙화
탈중앙화 아키텍처는 식별자 생성과 노출 알림 처리를 서버에서 사용자 기기로 옮겨 서버의 역할을 줄이고 개인정보에 대한 접근을 제한한다. 기기는 로컬 seed에서 수명이 짧은 pseudonym을 생성하고, 사용자는 감염 사용자의 seed를 다운로드한 뒤 로컬에서 노출을 재구성한다.
- 아키텍처: 탈중앙화 tracing은 익명 식별자를 생성하고 사용자 기기에서 노출 알림을 수행하므로 서버의 개입을 최소화한다.이 설계는 서버와 다른 사용자 모두에게 실제 신원이 드러나지 않도록 하는 것을 목표로 한다.
- 식별자 생성: PACT 를 사용하면 기기는 사용자를 사전 등록하거나 서버에 PII를 저장하지 않고 random seed와 약 1분 길이의 pseudonym, 즉 “chirp”를 생성한다.seed는 현재 시간과 결합된 pseudorandom function의 입력으로 사용된다.
- 서버와 프라이버시: 서버는 감염 사용자의 seed를 게시하는 honest-but-curious rendezvous point로 기능하며, 다른 기기는 이를 다운로드해 해당 chirp를 재구성하되 신원을 직접 도출하지는 않는다.노출 위험 분석은 다른 앱 사용자만 자신의 기기에서 수행한다.
- 접촉 정보 교환: 기기는 Bluetooth를 통해 몇 초마다 새로운 chirp를 broadcast하고, 수신한 chirp를 timestamp 및 maximum RSSI와 함께 저장하며 1분 이내에 수신된 중복 항목은 무시한다.centralised architecture와 달리 seed와 chirp는 모두 서버가 아니라 기기에서 생성된다.
- 추적 과정: 승인된 양성 진단 후 사용자는 로컬에 저장된 seed와 생성·만료 시각을 업로드하고, 다운로드한 seed를 이용해 과거 chirp를 로컬에서 재구성하여 노출을 추적한다.사용자는 일반적으로 하루에 한 번 서버에 접속해 감염 사용자가 업로드한 seed를 다운로드한다.
2.3 Hybrid · 2.4 아키텍처 요약
Hybrid 아키텍처는 contact tracing 기능을 서버와 디바이스에 분산하며, 아키텍처 요약은 서버 기능과 privacy preservation을 기준으로 centralised, decentralised, hybrid 설계를 비교한다. 이 protocol은 privacy-preserving registration, ephemeral identifiers, encounter tokens, server-assisted risk matching을 사용한다.
- 2.4 아키텍처 요약: Hybrid 아키텍처는 복잡한 tracing 기능을 서버와 디바이스에 분산한다. 이는 기능을 centralised하는 centralised 설계나, 기능을 전적으로 디바이스에 위임하는 decentralised 설계와 다르다.Hybrid model에서는 모든 tracing operation을 수행하는 대신 서버가 제한적인 coordination 및 lookup 책임을 유지한다.
- 2.3 Hybrid: Desire protocol 은 PII를 기록하지 않고 각 app에 고유한 device ID를 할당하며, BLE를 통해 cryptographic Ephemeral ID를 교환하고, 각 encounter마다 서로 연결할 수 없는 Private Encounter Token 두 개를 저장한다.Protocol의 interaction sequence는 Figure 9에 제시되어 있다.
- 2.3.1 Installation and registration: Hybrid registration은 phone-number OTP와 서버가 발급한 authorization-token authentication을 사용한 뒤, app ID를 할당하고 phone number와 encryption key를 삭제한다.Figure 10은 이 registration 과정을 보여준다.
- 2.3.2 Ephemeral ID 생성 및 교환: 디바이스는 Diffie–Hellman key exchange 를 통해 EphID를 생성하고, 일반적으로 15분마다 이를 교체하며, 수신한 각 identifier에서 PET 두 개를 도출한다.Figure 11은 encounter 과정을 보여주며, app은 encounter data를 위한 upload 및 query table을 유지한다.
- 2.3.3 Encounter data 업로드: 양성 진단 후에는 user ID, encryption key, PET, timestamp, duration을 서버에 업로드하기 전에 명시적 동의가 필요하다.서버는 PET와 관련 data를 기록하고 encryption key를 사용해 infected user의 status를 업데이트한다.
- 2.3.4 Contact tracing process: 사용자는 proxy 또는 anonymisation network를 통해 exposure를 조회하며, 서버는 PET를 매칭하고 시간과 duration으로 risk를 평가한 뒤, 위험에 노출된 사용자에게 health authorities에 연락하도록 알린다.Figure 12는 notification 과정을 제시한다.
- 2.4 아키텍처 요약: 세 아키텍처는 central server에 할당된 functionality와 privacy preservation에 따라 분류되며, centralised system은 security, identifier, risk-analysis, notification 역할을 유지한다.아키텍처 요약은 이러한 서버 책임이 decentralised system에서는 디바이스로 이전되고 hybrid system에서는 분담되는 양상을 대조한다.
3 데이터 관리, 프라이버시 및 보안
이 절에서는 중앙집중형, 분산형, 하이브리드 contact-tracing 아키텍처 전반의 데이터 관리를 비교한 뒤, 정부, 서버, 디바이스, 악성 사용자가 초래할 수 있는 프라이버시 및 보안 위험을 살펴본다. 아키텍처에 따라 데이터의 저장 위치, 접근 주체, 공격이 프라이버시·무결성·가용성을 침해하는 방식이 달라짐을 보인다.
- 데이터 관리, 프라이버시 및 보안: 각 아키텍처를 평가하기 위해 어떤 데이터가 생성·교환·저장되며 각 이해관계자가 어떤 데이터에 접근할 수 있는지 검토한다.정부, 중앙 서버, 악성 사용자, 그리고 양성 사례의 신원을 아는 보건 당국을 분석 대상에 포함한다.
- 중앙집중형 아키텍처: 중앙집중형 시스템은 personally identifiable information, 임시 식별자, 양성 사례의 접촉 목록을 서버에 저장하며, 디바이스는 접촉 데이터를 보유하고 사용자 동의에 따라 이를 업로드할 수 있다.서버는 주기적으로 TempID를 생성하고 전송하는 반면, 디바이스는 지정된 기간 동안 접촉을 생성·교환·저장하며, 그 기간은 보통 21일이다.
- 분산형 아키텍처: 분산형 시스템은 시간별 seed, chirp, RSSI, timestamp, 잠재적인 위치 메타데이터를 디바이스에 보관하며, 서버의 역할은 더욱 제한적이다.사용자는 seed를 다운로드하고 감염 사용자와 연관된 chirp를 계산할 수 있어, side-channel 정보로 식별될 위험이 발생한다.
- 하이브리드 아키텍처: 하이브리드 시스템은 디바이스에 PET 항목으로 접촉을 저장하고 서버에는 제한된 디바이스 정보를 기록하며, 업로드에 자발적으로 동의한 양성 사용자에게서만 PET를 수신한다.하이브리드 프라이버시 보호에는 secret sharing, decisional Diffie-Hellman, private set intersection이 포함되므로, 한 당사자가 침해되어도 전체 secret이나 위험 분석 결과가 노출되지 않는다.
- 프라이버시: 중앙집중형 아키텍처에서는 침해된 서버가 세 가지 데이터 범주 모두에 접근할 수 있는 반면, 분산형 시스템은 재식별 위험을 지니고 하이브리드 시스템은 privacy-preserving computation을 통해 정보 공개를 줄인다.세 가지 범주는 참여자 PII, pseudonymous contact advertisements, social/proximity graphs이며, smartphone 도난이나 강압은 모든 아키텍처에서 디바이스에 저장된 데이터를 노출할 수 있다.
- 보안: 보안 위협에는 데이터 절도, 허위 노출 알림, 익명성 해제, 잘못된 항목, 그리고 서버가 침해되거나 악성 주체와 공모할 때 발생하는 서비스 거부가 포함된다.따라서 중앙집중형 서버에는 trusted execution environment, 인증, 접근 제어가 필요하며, 모든 아키텍처는 무결성과 가용성 위협에 대응해야 한다.
4 근접성 추정
감염 위험을 평가하려면 근접성 추정이 핵심이다. 전파 가능성이 접촉 거리와 지속 시간에 좌우되기 때문이다. 현재 스마트폰 방식은 주로 GPS와 Bluetooth RSSI를 사용하지만 실제 환경에서는 여전히 신뢰성이 낮아 근접성 오차와 오분류를 상당히 많이 발생시킨다.
- 근접성 추정: 현재 앱은 주로 GPS와 Bluetooth를 사용해 근접성을 추정하며, 이를 통해 접촉 거리와 지속 시간에 따른 감염 위험을 평가한다.WiFi도 제한적인 근접성 추정을 제공할 수 있지만 지원 인프라와 설정이 필요하다.
- 근접성 추정: Bluetooth는 무선 신호가 이동 거리에 따라 감쇠하기 때문에 RSSI로 거리를 추정하며, path-loss model을 사용해 신호 세기와 이격 거리를 연결한다.이 모델에는 기준 거리의 RSSI와 path-loss exponent가 포함되며, 수신기는 기록된 RSSI 값으로부터 대략적인 거리를 추론한다.
- 근접성 추정: 벽, 가구, 사람을 포함한 환경적 장애물과 채널 효과는 거리의 영향만으로 설명되지 않는 방식으로 RSSI를 왜곡하며, 실제 조건에서 완화 전략의 효과를 제한한다.path-loss exponent의 변동은 일부 환경 요인을 반영하지만, 알려지지 않은 모델 매개변수와 noise variance가 추가적인 불확실성을 만든다.
- 근접성 추정: 현재의 근접성 기법은 false positives and false negatives를 발생시켜, 때로는 사람들이 멀리 떨어져 있는데도 가까운 접촉으로 나타내거나 가까운 접촉을 놓친다.벽이나 다른 장애물 때문에 겉보기에는 가까운 거리 추정치가 실제 노출을 나타내지 못할 수 있으며, 인접한 아파트 사이의 접촉이 그 예다.
5 공격
이 절에서는 replay, tracking, location inference, enumeration, linkage, identifier-carryover를 비롯해 centralized, decentralized, hybrid contact-tracing architecture를 대상으로 한 공격을 살펴본다. architecture별 설계 선택이 공격 범위, 식별 가능성, 저항성에 영향을 미치며, 추가 sensing은 privacy 보장을 약화시킬 수 있음을 보인다.
- Replay 및 relay attack: Replay attack은 메시지를 전달하는 것만으로도 최소한의 자원으로 false positive를 유발할 수 있으며, centralized, decentralized, hybrid architecture는 취약성과 피해자 범위에서 차이를 보인다.Centralized replay는 originator를 close contact로 식별할 수 있고, decentralized replay는 여러 recipient에게 영향을 미칠 수 있다. 반면 hybrid protocol은 replay를 방지하지만 relay attack에는 여전히 취약하다.
- Device tracking: BLE advertisement, temporary identifier, phone-model 정보는 device tracking을 가능하게 할 수 있지만, 짧은 identifier 수명은 공격자가 연속된 identifier를 연결하지 않는 한 tracking 범위를 제한한다.Address carryover와 identifier의 소멸 및 즉각적인 교체에 대한 분석은 identifier 변경이 동기화된 경우에도 anonymous-ID 만료 이후까지 tracking을 확장할 수 있다.
- Location 및 enumeration attack: Centralized encounter data는 특정 사용자가 한 location에 존재하는지를 드러낼 수 있는 반면, decentralized upload를 통해 사용자는 공유된 seed로부터 positive-case count를 추정할 수 있다.Positive case 수를 은폐하기 위해 server가 생성한 chirp를 저장하는 Bloom filter가 제안된다.
- Linkage attack: Linkage attack은 side-channel correlation을 통해 사용자를 de-anonymize할 수 있다. decentralized system은 positive user를 노출할 수 있고, centralized system은 close contact를 노출할 수 있으며, hybrid protocol은 일반적으로 unlinkable하다.Mobile-model 정보, isolation, contact duration, isolated encounter는 centralized system에서 식별을 뒷받침할 수 있다.
- Server 및 privacy threat: 공격자는 wireless encounter를 상관 분석하거나 휴대전화를 탈취해 interaction data를 수집할 수 있지만, 악성 server는 positive test도 positive patient와의 contact도 없는 사용자와 관련된 interaction을 공개할 수 없다.추가 sensor 또는 gait recognition은 일부 tracking attack에 대응할 수 있지만, 더 많은 contextual 또는 personal data를 수집하면 privacy 보장이 약화될 수 있다.
6 구체적인 앱 및 프로토콜 분석
이 절에서는 세 가지 광범위한 시스템 아키텍처를 구현하는 구체적인 contact-tracing 앱과 프로토콜을 검토하며, 여러 국가에서 제안·개발·배포된 사례를 다룬다.
- 6 구체적인 앱 및 프로토콜 분석: 앞서 논의한 세 가지 광범위한 아키텍처를 구현하는 tracing apps and protocols를 소개한다.아키텍처 수준의 특징, 기능, 공격 노출에서 구체적인 시스템으로 논의를 전환한다.
- 6 구체적인 앱 및 프로토콜 분석: 여러 국가에서 제안되고, 개발되고, 배포되고 있는 시스템을 다룬다.Figure 15는 이 분석에 포함된 앱과 프로토콜을 요약한다.
- 6 구체적인 앱 및 프로토콜 분석: 논의는 세 개의 절로 나뉘며, 각 절은 서로 다른 시스템 아키텍처에 초점을 둔다.
6.1 중앙집중식 아키텍처 기반 앱/프로토콜
중앙집중식 contact-tracing 구현으로는 BlueTrace 기반의 TraceTogether와 CovidSafe, ROBERT 기반의 StopCovid, Bluetooth와 GPS를 결합한 Aarogya Setu가 있다. 이들은 저장 데이터, 알림 절차, identifier 수명, privacy 또는 attack 노출 측면에서 차이를 보인다.
- 구현: BlueTrace 기반 TraceTogether 와 CovidSafe 는 중앙집중식 아키텍처를 사용하며, ROBERT 기반 StopCovid 와 Aarogya Setu 는 다른 배포 사례에 해당한다.Aarogya Setu는 Bluetooth와 GPS를 모두 사용하며, OpenTrace와 StopCovid source code는 공개되었다.
- TraceTogether와 CovidSafe: CovidSafe는 TraceTogether의 15-minute 수명에 비해 2-hour TempIDs를 사용해 다운로드 횟수를 줄이지만 replay attacks에 대한 취약성은 높인다.그 밖에 두 앱은 Bluetrace를 따르며 Table 4에 열거된 attacks에 대한 취약성도 공유한다.
- BlueTrace와 ROBERT: ROBERT는 BlueTrace의 personally identifiable information 대신 anonymous EphIDs를 저장해 privacy를 강화하지만, 사용자가 risk notifications를 확인하기 위해 서버에 자주 접속해야 한다.두 프로토콜은 notification processes도 서로 다르며, BlueTrace는 대조적인 notification mechanism을 사용한다.
- BlueTrace와 ROBERT: ROBERT는 contact linking과 social-graph analysis를 어렵게 하도록 positive users의 EphIDs를 시차를 둔 무작위 순서로 업로드하지만, traffic analysis를 통해 보고서를 다시 연결할 수 있다.반면 BlueTrace는 모든 contacts를 한 번에 업로드한다.
- Aarogya Setu: Aarogya Setu는 500 m에서 10 km 이내의 positive cases를 나타내는 analytics를 위해 personally identifiable, contact, GPS-location 및 self-assessment data를 수집한다.앱의 Android code는 공개되었지만 iOS 및 server code는 아직 제공되지 않았다.
6.2 분산형 아키텍처 기반 앱/프로토콜
이 절에서는 Apple/Google의 exposure-notification system, 두 가지 PACT 프로토콜, DP-3T, TCN, Pronto-C2, Hamagen을 포함해 분산형 접촉 추적 프로토콜과 구현을 살펴본다. 이러한 설계는 일반적으로 추적 데이터를 로컬에 보관하고 privacy-preserving 식별자를 사용하며, linkage, enumeration, 정확도, 도입 문제를 대안적 메커니즘으로 다룬다.
- Apple/Google exposure notification: Apple과 Google 은 보건 당국 앱용 API와 OS 수준 지원을 갖춘 분산형 exposure-notification system을 제안했으며, SwissCoviD와 Corona-Warn-App 같은 배포를 가능하게 했다.API는 20 May 2020에 공개되었고, 독립형 앱에 대한 의존도를 낮추기 위해 운영체제 통합이 계획되었다.
- PACT 프로토콜: PACT East-coast 와 PACT West-coast [47]는 로컬 암호화 저장소, pseudorandom 식별자, 자발적 데이터 업로드를 사용하지만 linkage 및 enumeration attacks에 여전히 취약하다.PACT East-coast는 접촉 맥락을 식별하고 false positive를 줄일 가능성을 높이기 위해 위치 메타데이터를 선택적으로 저장하며, PACT West-coast는 CovidSafe (UoW) 의 기반이 된다.
- DP-3T: DP-3T 는 매일 갱신되는 키와 만료되는 Bluetooth EphID를 로컬에 저장하며, ‘Un-linkable’ design에서는 업로드된 키를 서버에서 필터링된 EphID로 변환해 linkage 및 enumeration 위험을 줄인다.Un-linkable design은 서버 처리 시간을 늘리고 false positive를 제한하기 위해 Cuckoo-filter 조정이 필요하지만, false negative를 방지하고 선택적 encounter 업로드를 지원한다.
- 기타 프로토콜 및 애플리케이션: 그 밖의 분산형 접근법으로는 compact keychain seed를 업로드하는 TCN [49], 중앙 서버가 익명 디바이스 통신을 파악하지 못하게 하는 Pronto-C2, Bluetooth 접촉을 기록하는 대신 GPS 기록을 로컬에서 대조하는 Hamagen이 있다.Hamagen의 위치 데이터는 개인의 휴대전화 밖으로 나가지 않으며, Pronto-C2는 특히 mass surveillance에 대한 보호를 목표로 한다.
6.3 hybrid architecture 기반 앱/프로토콜
Hybrid protocol은 server-mediated risk analysis와 notification을 device-generated identifier와 결합한다. DESIRE, ConTra Corona [64], EpiOne [65]는 cryptographic mechanism과 server separation을 통해 linkage, enumeration, social-graph attack을 제한함으로써 privacy 향상을 목표로 한다.
- DESIRE: DESIRE 는 EphID와 구별되는 cryptographically generated PETs와 client-held encryption key를 사용해 contact-data harvesting를 막고, breach 이후 server-stored data를 보호한다.Risk analysis와 notification은 server-side에 남아 있어 user-launched Enumeration 및 Linkage attack의 가능성을 낮춘다.
- ConTra Corona: ConTra Corona [64]는 DDH key exchange와 분리된 server를 사용해 diagnosed user의 upload를 검증하고 decentralized app에 대한 linkage attack을 완화한다.이 privacy protection은 non-colluding server와 anonymized 또는 authenticated communication channel을 전제로 한다.
- ConTra Corona: ConTra Corona [64]는 daily warning identifier, encrypted seed identifier, pseudorandom identifier를 생성한 뒤, 15-of-45 secret sharing을 사용해 broadcast에서 contact event를 재구성한다.Device는 동일한 random identifier에 연관된 share를 포함하는 broadcast 15개를 축적한 뒤 event를 재구성한다.
- EpiOne: EpiOne [65]는 Private Set Intersection을 사용해 사용자가 수신한 token과 encrypted positive-case seed에서 재구성된 token을 어느 집합도 공개하지 않고 비교하여 enumeration과 social-graph construction을 방지한다.Positive user는 health official을 통해 encrypted seed를 upload하고, 사용자는 token intersection의 cardinality만 알 수 있다.
7 일반적인 사용자 우려
사용자 수용성은 다운로드 수만으로 추론할 수 없으며, 실질적인 우려로는 배터리 사용량, 기기 및 앱 호환성, 동의 철회, 투명성이 있다. 이러한 우려는 contact tracing 애플리케이션에 대한 신뢰와 광범위한 도입을 제한할 수 있다.
- 배터리 소모: 배터리 소모는 처리, 데이터 관리, 메시지 교환, 통신 프로토콜, 그리고 앱이 foreground 또는 background에서 실행되는지에 따라 달라진다.CovidSafe와 TraceTogether iOS는 background 실행 문제를 겪는 것으로 보고되었으며, Google–Apple 운영체제 지원은 일부 제약을 해결한다.
- 호환성: 호환성은 tracing 앱이 서로 다른 운영체제 버전을 지원하고, 사용자가 이동하거나 여러 앱을 설치할 때 앱 간 동작이 불분명하기 때문에 여전히 어렵다.TraceTogether와 CovidSafe는 서로 다른 Android 및 iOS 최소 버전을 요구하며, 아키텍처 차이로 인해 상호운용성이 복잡해진다.
- 동의 철회: 로컬에 저장된 접촉 데이터에 대한 동의 철회는 간단하지만, 감염된 사용자가 다른 기기에 도달하는 데이터를 업로드하거나 seeds를 업로드한 후에는 어려워진다.분산형 시스템에서는 전송된 seeds와 재구성된 chirps가 21일 삭제 기간이 끝날 때까지 남아 있을 수 있다.
- 투명성과 신뢰: 투명성은 open-source code와 Privacy Impact Assessments를 통해 신뢰를 강화할 수 있지만, 사용자는 여전히 개발자, 운영자, 검토자, 플랫폼 제공자를 신뢰해야 한다.CovidSafe (AU)와 DP-3T만 PIA가 함께 제공된 것으로 보고되었다.
8 미래 연구 방향
이 논문은 proximity 정확도, 완전 decentralized architecture, adaptive AI를 단기 연구의 우선 과제로 제시하고, 더 강력하고 안전한 tracing application을 위한 장기 기회로 quantum computing, sensing, communications를 지목한다.
- 8 미래 연구 방향: 향후 5년 동안의 단기 연구는 proximity 정확도, decentralized architecture, AI 기반 감염 가능성 알고리즘을 대상으로 해야 한다.보다 장기적이고 추측적인 연구는 5년 이후로 미룬다.
- 8 미래 연구 방향: 차세대 application은 BLE 발전, Bluetooth 유사 protocol, UWB, sensor fusion을 통해 proximity estimation을 개선할 수 있으며, UWB는 500MHz bandwidth를 사용해 cm급 정밀도를 제공할 수 있다.제안된 fusion 입력에는 WiFi, Enhanced-GPS, gyroscope, accelerometer가 포함된다.
- 8 미래 연구 방향: privacy 우려를 해소하고 governing authority에 의존하는 architecture를 넘어 더 폭넓은 대중의 adoption을 지원하려면 완전 decentralized peer-to-peer 감염 tracing이 필요하다.조사한 application은 모두 정도의 차이는 있지만 central server를 사용한다.
- 8 미래 연구 방향: AI 기반 알고리즘은 실제 감염 판정, missed detection, false-positive 결과에 맞춰 적응함으로써 감염 가능성 판단을 동적으로 개선할 수 있다.향상된 phone processing power로 더욱 정교한 on-device 알고리즘을 구현할 수 있다.
- 8 미래 연구 방향: Quantum computing 은 향상된 computational power를 활용하는 quantum machine learning과 advanced Monte-Carlo 또는 particle-filter tracking을 통해 향후 tracing을 지원할 수 있다.Quantum computing이 곧 주요 개발 및 commercialization 돌파구에 도달할 수 있으므로 지금 연구를 시작할 것을 권고한다.
- 8 미래 연구 방향: Quantum sensing 은 timing, synchronization, acceleration, location 정확도를 개선할 수 있으며, quantum communications 은 tracing의 security와 privacy를 강화할 수 있다.Quantum communications는 이미 commercial offering과 proof-of-principle 우주 배치를 갖추고 있다.
9 결론
Contact tracing 앱은 보건 당국이 잠재적 노출을 식별하는 능력을 강화할 수 있지만, 만능 해결책은 아니며 아키텍처상의 tradeoff, privacy 우려, 자발적 도입에 제약을 받는다. 이 글은 이러한 기술적·사이버보안 고려사항을 연구자, 사용자, 기관에 알리는 것을 목표로 한다.
- 9 결론: Contact tracing 앱은 보건 당국이 노출되었을 가능성이 있는 사람을 신속히 식별하는 데 도움을 줄 수 있지만, 팬데믹 접촉 추적의 과제를 그 자체로 해결할 수는 없다.이 글은 이러한 앱이 추적 역량을 향상할 수 있지만, 여전히 사용자, 데이터 보호 기관, 연구자의 우려에 직면한다고 강조한다.
- 9 결론: 아키텍처 선택에 따라 서로 다른 이점, 단점, 공격 모델, 보호 수단, 구현 복잡도, 운영 비용이 발생한다.정부의 선택은 기술적 친숙도, 기존 추적 절차와의 통합, 배포 용이성에 따라 달라진다.
- 9 결론: 사용자 도입은 자발적이며, personally identifiable information의 privacy 및 security에 대한 우려는 앱 도입을 가로막는 핵심 장벽으로 남아 있다.이러한 우려는 tracing 앱을 통해 수집되는 PII와 관련해 사용자들이 제기한다.
- 9 결론: 사용자는 이미 WiFi, cellular tower, GPS 앱, 카메라 및 기타 애플리케이션을 통한 광범위한 tracking에 노출되어 있으며, 이러한 기술의 security 및 privacy 영향은 불분명할 수 있다.이 글은 tracing 앱을 기존 tracking 기술과 일상적으로 설치되는 애플리케이션으로 구성된 더 넓은 생태계 안에 위치시킨다.
- 9 결론: 이 글은 연구자들이 tracing-app 기술과 cybersecurity를 이해하도록 돕는 동시에, 사용자와 기관이 더 충분한 정보를 바탕으로 자발적 도입을 결정할 수 있도록 지원하고자 한다.대상 독자는 연구 공동체, 사용자, 그리고 각자의 지리적 영역에서 제공되는 앱을 평가하는 기관이다.