Question about distribution of signing keys

[ramnanib2]

How will the verification keys be distributed to the devices ? Will those simply be part of the app distribution or provided by the server through a certificate signed by Google/Apple CA ? Will the signing key pair be provided by Apple / Google when on-boarding the app to the app store ?

Seems like every app server will use its own public-private key pair. If that's the case, does that mean that the different apps using the exposure notification APIs won't be inter-operable since keys uploaded by app1 can't be verified by app2 ?

[mikehelmick]

/assign

[mikehelmick]

Hello - the public keys for verification of the export need to be distributed to devices by Apple and/ or Google. The owner of the server / app is responsible for generating the key material and safeguarding the private key.

The exact process for collecting these public keys from operators isn't yet determined.

Apps can be interoperable with each other. The federation API in this project allows for 2 servers to share verified temporary exposure keys with each other.

@gurayAlsac @squee1945 - anything else to add?

[squee1945]

The federation API is a peer-to-peer setup and only local provenance temporary exposure keys are exchanged (i.e., no "transitive" federation). These peer-to-peer scenarios assume trust: trust that the remote federation partner has appropriately validated the temporary exposure keys from the app on upload to the remote server.

[gurayAlsac]

We are working with governments and health authorities to whitelist api usage and during that same on-boarding process we would collect the public keys used to verify the signed exports. Google/Apple won't be generating these signing keys. Server/app developers will be generating the public/private key pair. Server and app developers do not need to manage delivery of the public verification keys to devices; that'll be handled by Google/Apple.

Servers can control which apps are allowed to use their exports by configuring access to their public verification key. So either servers can federate data between each other (if they operate in different regions) or apps can be configured to pull exports directly from other regions.

[ramnanib2]

Servers can control which apps are allowed to use their exports by configuring access to their public verification key

How is that accomplished ? Public keys are not secrets and since apps are not going to be authenticating with the server, seems like apps will be able to download and verify keys from any server endpoint or even multiple servers. Am I missing something ?

[mikehelmick]

Access to the exports and ability to import them is a separate thing from the signing.

If the exports are available on a public endpoint, then they can be imported by any app and will be verified by the device if the corresponding public key is installed.

If a server/app author wishes to protect their downloads some other way, then authentication would need to be implemented - not covered in our reference server.

[dirkx]

The current proposal calls for an unmanaged private key to be used; with the public key communicated out of bound to google and apple (to be announced).

With further key management (revoke, key rollover, dealing with loss or compromise) requiring similar out-of-bound involvement of google (and apple); and a need for a distribution of a new key likely outside the normal mobile-app distribution process of the app itself.

This approach is very unusual for at country level (even for such a `light’ origin signature that does not necessarily signal a legal binding agreement); which generally adhere to a set of trust management practices (often referred to as ETSI EN X19 and policy requirements such as ETSI TS 102/042) for such signatures.

As such PKI schemes provides appropriate levels of key lifecycle management, operational practices with an appropriate balance between digital sovereignty, reliability, robustness and interoperability.

Suggestion

The digital signature used to sign the infected Teks should be appropriately managed.

One could consider using a RFC5262 CMS signature along with full PKI chain information (leaving open how serialise this).

Or alternatively, suggest a RFC3161 signature/timestamp (as these are small self contained files designed to be included in the aforementioned zip or pre/post-fixed and whose serialisation is well understood/defined and less open to multiple options).

This would reduce the task of the corona application (or the google OS) to verify the key against the operating systems build in trusted CA that are already well managed; with proper processes for updating & revocation -- or against a root cert build in. And thus getting all the key rollover, recovery, revocation and other sundry.

[ijansch]

+1

Also please keep in mind that this feature is not tied to this reference implementation so the solution can’t be specific to this repository.

[mikehelmick]

We'll update this thread when we have more information about key distribution.

[sethvargo]

We don't rely on only TLS because this is protection against a potentially bad application (due to e.g. compromise). Both platforms (client and server) have a secure channel for distributing these keys and handling revocation, rotation, etc.

Adding an extra CA model on top of that is a lot of extra complexity and would require a new PKI scheme and new CAs. This leads to many other unanswered questions like who are the CAs for this? Given the time limits involved and the extra complexity for no perceived gain, we chose to not go down this route for v1.

[gurayAlsac]

W.r.t. the actual process of how to provide a server's verification keys to Google for distribution, the folks that are working to onboard you for usage of the API will provide you an issue tracker link you can use to upload the key along with some related information. If you are not already in communication with Google, you can start at https://support.google.com/googleplay/android-developer/contact/expo_notif_api

[github-actions[bot]]

This issue is stale because it has been open for 14 days with no activity. It will automatically close after 7 more days of inactivity.

[gurayAlsac]

Feel free to open a new issue if you have any further questions about export signing key distribution.