This website was mostly translated automatically from the
German version. We
apologize for any translation errors.
x
Key Management
Zilp-Zalp uses an external Public-Key Infrastructure (PKI) to
encrypt data as well as to authenticate health departments to
backend servers and to sign requests published by them.
As with all systems, the security of the overall system depends
crucially on the security of this PKI. Zilp-Zalp is designed to
work with existing PKI systems.
Basic ideas
Health departments have individual asymmetric key pairs for
signing data, as well as a shared key pair for - encrypting&
decrypting data. These are signed by one or more root certificates,
which serve as trust anchors for the backend servers. In order to
make the overall system as robust as possible against the loss of
keys, the following measures should be observed:
The applicability and power of individual keys should be
limited as much as possible in space and time.
Private keys should only be generated on site and not
"moved".
Necessary keys
Zilp-Zalp requires the following key pairs during operation:
One or more root certificates that serve as trust anchors.
For each health department, one or more key pairs (GA keys) for
signing requests to the backend servers.
For the global encryption of visit data, all health departments
share a GÄ data key.
For an ombudsman office, an asymmetric key pair with which
visit data is additionally encrypted and which allows, in
exceptional cases, access to such data without the involvement of a
user.
Root key pairs are generated by a trusted authority, and the
public keys and certificate details are distributed throughout the
system, serving as trust anchors for all actors.
GA signing keys are generated locally and signed by the trusted
entity via Certificate Signing Requests (CSR). The common GA data
key is also generated locally, signed and then distributed to
individual GAs via a secure channel. It should be changed
regularly; this requires a "key agreement" process between the
GÄs.
Risk analysis
The following sections describe risks that arise from the loss
of private keys in the system.
Loss of a private GÄ data key
If an attacker gains access to a private GÄ data key, he can
remove the outer decryption of a user's contact information.
However, it can only decrypt this data with the aid of the key $K _
a$, which must be provided by the user or determined via the user's
visit data. Visit data can only be decrypted with the aid of a
group key, which in turn can only be obtained with the cooperation
of a user or, within the framework of the ombudsman process, with
the cooperation of the ombudsman's office and an operator. The loss
of a private GÄ data key thus only leads to a very low risk of
decryption of personal data, at least if the attacker does not also
succeed in obtaining further keys. Since these additional keys are
stored decentrally and can only be obtained with the manual
involvement of individual actors, the hurdle to obtaining them is
very high for the attacker.
Loss of a private GÄ signing key
If an attacker gains access to a private GÄ signing key, he can
use it to authenticate himself to a backend server, retrieve data
from there and make abusive requests. However, he cannot retrieve
(encrypted) contact data from backend servers without knowledge of
$I _ D$ values. To obtain such $I _ D$ values, he can make requests
for visit data. However, this also requires the presence of a GA
data packet (under user control) or a decrypted visit data packet.
As explained above, the systematic acquisition of this information
is associated with high hurdles for the attacker.
Loss of a private root certificate key
If an attacker gains access to a private root certificate key,
he can sign his own key pairs and make them appear trustworthy to
all actors. He can thus cause backend servers to make requests for
visit data or retrieve data from them. However, since additional
secret values are required to retrieve data and retrieval of
specific information (e.g. contact data) is only possible with the
presence of corresponding identification features (e.g. $I _ D$),
the hurdle for the attacker is also very high here.
Compromise of system components
In both of the above scenarios, it is assumed that the attacker
has only gained access to key material, but has not compromised any
system components apart from this. These scenarios are described in
more detail in the risk
analysis and are therefore left out here.
Key Management
Zilp-Zalp uses an external Public-Key Infrastructure (PKI) to encrypt data as well as to authenticate health departments to backend servers and to sign requests published by them.
As with all systems, the security of the overall system depends crucially on the security of this PKI. Zilp-Zalp is designed to work with existing PKI systems.
Basic ideas
Health departments have individual asymmetric key pairs for signing data, as well as a shared key pair for - encrypting& decrypting data. These are signed by one or more root certificates, which serve as trust anchors for the backend servers. In order to make the overall system as robust as possible against the loss of keys, the following measures should be observed:
Necessary keys
Zilp-Zalp requires the following key pairs during operation:
Root key pairs are generated by a trusted authority, and the public keys and certificate details are distributed throughout the system, serving as trust anchors for all actors.
GA signing keys are generated locally and signed by the trusted entity via Certificate Signing Requests (CSR). The common GA data key is also generated locally, signed and then distributed to individual GAs via a secure channel. It should be changed regularly; this requires a "key agreement" process between the GÄs.
Risk analysis
The following sections describe risks that arise from the loss of private keys in the system.
Loss of a private GÄ data key
If an attacker gains access to a private GÄ data key, he can remove the outer decryption of a user's contact information. However, it can only decrypt this data with the aid of the key $K _ a$, which must be provided by the user or determined via the user's visit data. Visit data can only be decrypted with the aid of a group key, which in turn can only be obtained with the cooperation of a user or, within the framework of the ombudsman process, with the cooperation of the ombudsman's office and an operator. The loss of a private GÄ data key thus only leads to a very low risk of decryption of personal data, at least if the attacker does not also succeed in obtaining further keys. Since these additional keys are stored decentrally and can only be obtained with the manual involvement of individual actors, the hurdle to obtaining them is very high for the attacker.
Loss of a private GÄ signing key
If an attacker gains access to a private GÄ signing key, he can use it to authenticate himself to a backend server, retrieve data from there and make abusive requests. However, he cannot retrieve (encrypted) contact data from backend servers without knowledge of $I _ D$ values. To obtain such $I _ D$ values, he can make requests for visit data. However, this also requires the presence of a GA data packet (under user control) or a decrypted visit data packet. As explained above, the systematic acquisition of this information is associated with high hurdles for the attacker.
Loss of a private root certificate key
If an attacker gains access to a private root certificate key, he can sign his own key pairs and make them appear trustworthy to all actors. He can thus cause backend servers to make requests for visit data or retrieve data from them. However, since additional secret values are required to retrieve data and retrieval of specific information (e.g. contact data) is only possible with the presence of corresponding identification features (e.g. $I _ D$), the hurdle for the attacker is also very high here.
Compromise of system components
In both of the above scenarios, it is assumed that the attacker has only gained access to key material, but has not compromised any system components apart from this. These scenarios are described in more detail in the risk analysis and are therefore left out here.