Only a few weeks after its initial announcement, the partnership between Google and Apple to provide their mobile OSes with solid foundations for contact tracing applications has reached a key milestone, a preliminary draft of the Exposure Notification API and beta release for iOS.
To avoid confusion, it is worth noting that Apple and Google have renamed their technology solution as exposure notification, which is now preferred over contact tracing. The reasoning behind this decision is that contact tracing is a much broader solution including some kind of centralized system users connect to, which should be provided by regional health authorities. Apple and Google are just providing the technological foundation for this kind of applications, hence the more appropriate naming.
The new API takes into account a significant change in the cryptographic protocol defined by Google and Apple to strengthen privacy. Originally, the protocol used two cryptographic keys, a Tracing Key unique to each user that would never leave a device and a Daily Tracing Key generated each new day based on the former. Daily Tracing Keys were used to generate Rolling Proximity Identifiers, a kind of pseudorandom Bluetooth moniker used to detect device proximity in a given timeframe.
As it happens, having a unique key associated to a device opens the door to advanced attacks when direct access to the device is available. Therefore, the new protocol version uses completely random Temporary Exposure Keys to generate a Rolling Proximity Identifier Keys which are then used to generate Rolling proximity identifiers. Since Rolling proximity identifiers are not generated from a completely random key with a 24h lifetime, according to Apple and Google, it’s computationally infeasible for an attacker to find a collision on a Rolling Proximity Identifier without knowing also the corresponding Temporary Exposure Keys. This reduces the chances of replay and impersonation attacks.
The new Exposure Notification framework covers two user roles: affected users and exposed users. An affected user has a confirmed or suspected COVID-19 diagnosis, while an exposed user has had a potential contact with the former. When a user is diagnosed, their Temporary Exposure Keys are shared with other, potentially exposed users through the external diagnosis server. This step requires an explicit user authorization. Exposed users can retrieve the set of Temporary exposure keys using ENSelfExposureInfoRequest and ask the framework to determine whether those keys were observed locally using an ENExposureDetectionSession.
The central class to the Exposure Notification framework is ENManager, which is in charge of some preliminary tasks such as checking the authorization status of the app. ENManager can enable exposure notification using its setExposureNotificationEnabled:completionHandler method, which starts or stops Bluetooth advertising and scanning after asking the use for authorization. At any time, the getDiagnosisKeysWithCompletionHandler:completionHandler can be used to retrieve Temporary Exposure Keys used by this device to share with a diagnosis server. This step also requires explicit authorization.
The ENExposureDetectionSession class is the counterpart to ENManager in that it enables checking if a set of Temporary Exposure Keys received from the diagnosis server has been observed. This can be accomplished using the addDiagnosisKeys:completion and finishedDiagnosisKeysWithCompletion: methods. If an exposure is detected, more information such as the duration of the contact and the date can be retrieved using getExposureInfoWithMaxCount:completionHandler.
More detail about the new API can be found in the official Exposure Notification framework.
The new Exposure Notification API has just become available in iOS 13.5 Developer Release Beta 3, which will allow interested developers to try it out and start experimenting with contact tracing.