Storage of Health Departments' private keys on Luca server

[ralfr]

You are stating

The encrypted private keys are stored on the Luca Server.

Given that culture4life GmbH and the parties contracted to operate the Luca infrastructure at any time do have access to Luca Server, this would immediately break the promise, that Luca has no access to the data protected by the Health Departments' key pair. Private keys must not be stored in infrastructure owned or operated by an intermediary or they cannot be considered private anymore.

What is the rationale behind storing the Health Departments' private keys on Luca owned infrastructure?

[ralfr]

Disregard. You are storing an encrypted version of the private key, correct?

[hrantzsch]

You are storing an encrypted version of the private key, correct?

Correct. I assume you are referring to the daily keypair. The encrypted private key can only be decrypted by the Health Departments using their Health Department Encryption Keypair (which is never sent to the server).

[ralfr]

You are storing an encrypted version of the private key, correct?

Correct. I assume you are referring to the daily keypair. The encrypted private key can only be decrypted by the Health Departments using their Health Department Encryption Keypair (which is never sent to the server).

What's the general reason to store any private key on a central server as opposed to consequently storing it with the owning entity.

[reneme]

Since health departments are federated in Germany, they need to share a common keypair (namely the daily keypair). This keypair is regenerated and distributed among all health departments on a daily basis (see Daily Keypair Rotation for further details).

For the distribution, we use the HDEKPs (that are uniquely owned by each health department) to encrypt the daily keypair's private key for each health department. This encrypted private key is then uploaded to luca.

The public key of the current "daily keypair" is used by the client apps to encrypt their check-ins.

When an app prepares a QR code for a check-in it cannot know for which specific health department it needs to encrypt the check-in. Imagine, you travel to Berlin and visit a museum where you check-in using luca. Days later, back at home, you fall sick with Covid. Your local health authority will get in touch and initiate a contact tracing. At this point, your local health authority will need to be able to decrypt the contact information of the other guests in the museum in Berlin.

[sprohaska]

An alternative could be to associate every venue with a single responsible health department and encrypt a check in with the responsible health department's public key (instead of the daily key) and the venue's public key. Finding potential contact persons would require collaboration with the responsible health department.

In your travel example, the home health department would learn about the museum in Berlin and would then ask the responsible health department in Berlin to decrypt the check ins and transfer them to the home health department. The two health departments would probably have to coordinate in practice anyway. The transfer could happen via the luca server. The responsible health department could decrypt the check ins an re-encrypt them for the home health department.

For fixed venues, the responsible health department should be obvious. For ad-hoc venues that users might create by themselves, the responsibility is less obvious. A reasonable choice might be the health department that is responsible for the user's home address. An alternative could be the health department that is responsible for the current location.

A potential problem with this idea is that the flow for Check-In via Mobile Phone App would have to be modified. The QR code that the guest app generates would no longer depend only on a single daily public key but would depend on the responsible health department, which depends on the venue.

A security benefit would be that the impact of an adversary who learns the private key of one health department would be limited. The adversary could not decrypt all check ins that were decrypted by a venue owner during Finding Potential Contact Persons and stored on the luca server, because there is no single daily key that is shared between all health departments.

[philipp-berger]

Another alternative would be to add an additional layer of encryption right before the transfer of venue-owner encrypted check-ins.
Thereby, we circumvent the complex process of finding the right key on check-in and defer it until the actual inquiry of the health department. (when the right key, is the one of the requesting department)
The selection of the right health department on transferring the secrets as a user has to be manual in that case in front of generating the TAN number.