LUCA-LucaSecurityConcept-280121-1434-156
Dieses Dokument ist Teil der Anfrage „Unterlagen zur Prüfung der luca-App“
Luca Security Concept Goal The Luca System is designed to enable anonymous and secure contact information transfer. Visitors and guests of public or private events should be able to anonymously share their contact data with the organizer. Only in case of an infection, shall the local health authorities be enabled to access the collected personal contact information. Both the consent of the infected guest and the organizer are required. The following data is processed during the identification of possible contact persons. Types of data contact details of guests check-in information of guests location information name location name of the location street, street number, city, postal check-in time name and email of the contact code check-out time person of the location phone number address of the location email coordinates of the location check-in radius private event tracing code health authority information name of the authority name, email, certificates of legitimate employees The personal information of guests is the most valuable asset processed in the Luca system. System Overview Component Description [external] Email Is used to contact organizers and health departments, also to validate given contact information Service
[external] Is used to validate phone number used while entering contact details SMS Service [user] Guest A person that is required to securely provide their personal information before entering a location and later (on infection) submit their location history to the health department [user] Heath employee of the local health department responsible for identification of contact persons Department Employee [user] Location private person, or business owner/manager of a location that has guests and is obliged to trace contact information Owner shall be able to manage events / locations and scan guests Guest App The Luca guest app, also described as Luca app, is the interface for the guests. (Android, App, Guests enter the contact information in the app and use the app to checkin at several locations without re-entering their Webapp) contact details. Health Department Enables the health department to trace infection cases and contact potential contact persons. Frontend Location Frontend The frontend of the managers/organizers of locations/venues/restaurants. Here, a professional or private user can create locations or events which will enable the manager to checkin guests Luca Backend Stores encrypted check-in and contact information (never in possession of personal information in plain text) Centrally orchestrates the other technical components Scanner Frontend / The scanner app is used by the organizer or its employees to scan the anonymous Luca codes and check-in guests App Self-registration The self-registration frontend enables locations to also let guests enter their information manually on-site on an iPad or Frontend something similar. Static Code Generates printable QR codes to be used by people without smartphones to allow check-ins at Luca locations Generator Core processes Luca's primary goal is to automate the identification of contact persons for venues, restaurants and locations and ease the health department's identification of possible contact persons of infected persons. The table below provides a high-level overview of the involved processes to achieve this goal. Process Purpose Involved parties Input Output name Location Register an event or a venue with the Luca professional location email, password, venuePrivKey registration system and enable it to check-in guests via owner location information venuePubKey Luca. OR (name, address, ...) private event organizer Scanner Links Health Collect the check-in history of infected users Health department authentication Certified "health department encryption department and trace/ potential contact persons from manager certificate, name of the key pair" (HDEKP) and "... signing key registration those locations health department pair" (HDSKP) User Set up a smartphone user to check-in at some citizen willing to personal contact details userPrivKey registration venues using Luca user Luca userPubKey (via Luca additional local secrets App) anonymous userID Static QR Set up a static QR code badge allowing Static Code Generator, anonymous QR Code code check-in at venues to people without a some citizen willing to generation smartphone use Luca User checkin Transmit anonymous contact information to Luca user, venue anonymous QR Code uploaded tracing data /out location owner owner (or employee) 1) Scanner checkin 2) self-registration 3) table checkin 4) self/automated checkout
Identification Retrieve contact information in case of an Health department user TAN affected locations of infection employee, Luca user, HDEKP contact data of affected users contact 1) Reveal contact information to health venue owner persons department (Infection) 2) Reveal location history to health department 3) Venue approval for identification of contact persons 4) Reveal contact information of possible contact persons Asymmetric Encryption The underlying security used during the core processes relies on our asymmetric encryption scheme that shall be presented in the following section. We define our asymmetric encryption similar to DLIES (BSI TR-02102-1 3.5) according to the technical guideline of the BSI . Components asymmetric key parameters secp256r1 (NIST P-256) symmetric encryption EK AES-128-CTR message authentication code MACKM HMAC-SHA256 key derivation function H SHA256 Encryption Decryption function signature: AsymEnc(data, publicKey, [iv]) The inputs for the decryption are encryptedData, receiverPrivateKey, IV, ephemeralPublicKey and an (optional) MAC The inputs for encryption are data and a receiverPublicKey. The encryption procedure: The decryption procedure: 1. generate ephemeral ECC keyPair: ephemeralPrivateKey and ephemeralPublicKey 1. calculate DHKey = ECDH(receiverPrivateKey, 2. generate IV = random bytes (16 bytes) (if not given as input) ephemeralPublicKey) 3. calculate DHKey = ECDH(ephemeralPrivateKey, 2. calculate encryptionKey = SHA256(DHKey || 0x01) (truncate to receiverPublicKey) 16 bytes) 4. calculate encryptionKey = SHA256(DHKey || 0x01) (truncate to 3. calculate authenticationKey = SHA256(DHKey || 0x02) 16 bytes) 4. verify MAC (if available) = HMAC-SHA256(encryptedData, 5. calculate authenticationKey = SHA256(DHKey || 0x02) authenticationKey) 6. calculate encryptedData with AES-128-CTR(data, 5. calculate decryptedData = AES-128-CTR(encryptedData, encryptionKey, IV) encryptionKey, IV) 7. calculate MAC = HMAC-SHA256(encryptedData, authenticationKey) Output: decryptedData Output: encrypted data, MAC, IV, ephemeralPublicKey Notes: the MAC might be skipped/ignored and the IV might be given as an input Processes Daily Public Key Rotation Luca uses a daily key rotation system to reduce the impact of a any single compromised key. The keys are identified by a keyId (integer), which is incremented with each rotation. The rotation will be triggered by any health department employee that logins after the last daily public key expired. The daily public key is owned and kept secret by the health authorities. It is used to encrypt the user's personal data on checkins and registration, as described in the following processes. Rotation Process The life time of a daily key pair is 24 hours. If a daily public key has expired, any one health department employee automatically generates a new dailyLucaKeyPair. The newly generated daily private key is then shared with all other health departments by encrypting it for each HealthDepartmentEncryptionPublicKey and uploading it to the luca system. This effectively replaces the old daily key. Measures are taken to solve race conditions if multiple health department employees try to rotate the daily public key simultaneously. Stepwise process health department employee logins via client certificate
check for current expiration of daily key pair; continue only if key is expired locally generate a new daily key pair (NIST P-256) fetch all HealthDepartmentEncryptionPublicKeys (in the form of encryption certificates) from the luca system validate each encryption certificate against the configured CA and check their revocation status via OCSP encrypt dailyPrivateKey with all HealthDepartmentEncryptionPublicKeys and upload the encryptedDailyPrivateKeys sign the dailyPublicKey, the ID of the signing health department and the current timestamp with the local HealthDepartmentSigningPrivateKey upload the signed dailyPublicKey to luca system luca system validates the utilized HealthDepartmentSigningPrivateKey against the configured CA and checks its revocation status via OCSP luca system validates the signature of the uploaded dailyPublicKey, checks the signed timestamp for plausibility and concludes the rotation process result: daily key pair is exchanged, all new operations will be performed using the new key pair Key Destruction Daily private keys that are older than roughly two weeks (epidemiologically relevant time span) can be destroyed as no infection-relevant contacts happen beyond this time. The luca system can delete all such encryptedDailyPrivateKeys for all health departments. Furthermore, the health department frontend app might need to remove locally stored copies of such daily private keys. User registration 1) App Registration Upon first launch the user provides their contact information (see on top) to the app. The app then verifies the user's phone number via the luca system. For that, the plaintext phone number is sent to the backend, forw arded to the SMS service that creates a challenge. The SMS service sends a verificationTAN as SMS or voice call to the provided phone number. After entering the verificationTAN in the Luca app, it is verified via the backend with the SMS service provider. After that, the user's phone number is no longer stored on the luca backend. The app generates an EC secp256r1 keypair, a user tracing secret (16 bytes entropy), a user verification secret (16 bytes entropy) and a userDataKey (16 bytes random data). The app then encrypts the personal information and the user verification secret using AES-CTR- 128 with the userDataKey and signs it with the user's private key. The user's publicKey, the encrypted data and signature are transferred to the luca system which returns a unique userID for the app to store. The App stores the following: user id (uuid) user public key (ec secp256r1) user private key (ec secp256r1) user data key (16 bytes random data) user tracing secret (16 bytes random data) user verification secret (16 bytes random data) The Luca system stores the following: user id User Registration.txt user public key encrypted personal information (including verificationSecret) encrypted data iv 2) Static QR Code Generation The static QR code generation workflow is meant to be usable by users without access to a smartphone. The user will register through a purchase onboarding process. The generated code will then be printed and sent to the user via postal service. This process is subject of active discussion. See here for more details. These static QR codes cannot give the same security and privacy guarantees as the app-based checkin, though. Location Registration Both professional location owners and private event organisers can register with the luca system via a web application. The registration process involves the generation of a venueKeyPair whose private key is then stored either locally or encrypted by a password in the luca system. 1) Professional Location Owner A professional location owner (e.g. concert venue, museum, restaurant, etc.) can register a long-term location in the luca system. Each location can be managed by a web interface to set up individual QR code scanners and configure other venue-specific parameters (e.g. auto checkout behaviour). Process
location owner registers with email and password locally generate a venue key pair (NIST P-256) in the web application store the venuePrivKey to local file system upload the venuePubKey to the luca system 2) Private Event A private event is a one-time event organised by an individual user that is identified via its email address. Private organiser may be contacted by the health department for identification of contact persons similarly to professional venue owners. For simplicity we don't require private users to download and keep the private key for their event locally. Instead, they are asked to provide a password that is used to encrypt the locally generated private key. In case identification of contact persons becomes necessary, they can retrieve their encrypted private key from the luca system and decrypt it with their event password. Process create a one-time event by providing a valid email address via a web interface generate a venueKeyPair (NIST P-256) provide a sufficiently strong password for the event derive encryption and authentication keys from the password using PBKDF2 encrypt venuePrivKey like: AES-128-CTR(venuePrivKey, encKey, IV) authenticate the encryptedVenuePrivKey via HMAC-SHA256 under authKey upload encryptedVenuePrivKey, PBKDF2-salt, IV, venuePubKey and MAC to the luca system Health Department (HD) Registration A new health department receives an authentication certificate to authenticate to Luca. This certificate does not need to be signed by the external CA, as it only needs to be trusted by Luca. It is used to login to the Luca frontend. The health department creates an encryption certificate (HealthDepartmentEncryptionKeyPair HDEKP) and a signing certificate (HealthDepartmentSigningKeyPair HDSKP) on first login. Both of these certificates must be issued by the external CA via a manual process to ensure authenticity of the requesting HD admin. They are used to authenticate to (a) the app on checkins and (b) other health departments on key rotation /distribution. HDEKP is the key pair that needs to be accessible by any HD employee when performing Identification of contact persons, as it decrypts the daily health department private key. The HDSKP is highly sensitive, as it authenticates the daily health department public key. The signed public key of the HDEKP is uploaded to the Luca system, where it is available when distributing a new daily key. Both keypairs' private keys are securely stored locally. For use cases where the keypairs need to be accessible from multiple workstations the HD frontend provides secure export and import functionalities. Future Improvement: Employee Management Tools In a future version the HD frontend will provide facilities to simplify distributing access to the keypairs among health department employees. To this end, the HDEKP will be stored encrypted on the Luca backend. Each administrator and employee will receive an Offline Keypair that can be used to access the HDEKP. This will avoid the process of exporting and importing copies of the HDEKP and make it easier to revoke access for specific employees' keypairs, when needed. Overview of secrets and their location of the health department Secret Use Location HDEKP Public Key: Encrypt the daily health department key (one per HD) Public Key: Luca backend HealthDepartmentEncryptionKeyPair Private Key: Decrypt the daily health department key Private Key: Local devices HDSKP Sign the daily health department key for key rotation in the morning Admin local device HealthDepartmentSigningKeyPair Admin Auth Cert Authenticate to Luca System to manage employees Admin local device Employee Auth Cert Authenticate to Luca to trigger identification of possible contact persons Employee local device (Planned) Admin Offline Key Pair Decrypt the HDEKP Admin local device (Planned) Employee Offline Key Pair Decrypt the HDEKP (transport HDEKP from Admin to Employee) Employee local device User Check-in/out In this process the Luca system creates and persists a trace object that can be used (a) to trace an infected user's check-in at a specific location, and (b) to trace potential contact persons, that were at the same location at the same point of time.
There are multiple possibilities how the check-in can be done. The basic use case is for a venue to use the Luca Scanner App to scan a QR code generated by the Luca Guest App. Alternatively, users can self-check-in using a printed QR code (for example at a restaurant table). In both cases the general flow of the process is the same: The Guest App generates a trace ID, that can be used to trace the user if and only if the tracing party (the heath department) know the user's tracing secret (see Identification of contact persons). Scanner Check-in When check-in is activated, the Guest App will continuously generate new traceIDs. Each trace created as HMAC-SHA256 of the user id and the current timestamp (down-sampled to the minute) as data and the user tracing secret as key. The resulting value is truncated to the first 16 bytes. Subsequently, the App asymmetrically encrypts the userID and the userDataKey for the current daily health department key. The IV is defined as the first 16 bytes of the ephemeral public key used in the encryption scheme. The App then calculates a verification tag as HMAC- SHA256 of the timestamp and the encrypted data as data and the user verification secret as key, truncated to the first 8 bytes. In this process, the App fetches the current dailyPublicKey along with its generation time stamp from the Luca backend. The dailyPublicKey and the timestamp are signed by a specific HealthDepartmentSigningKeyPair certificate so that the Luca App can verify the authenticity of the provided data. For that, the HDSKP- certificate must be downloaded, validated against the issuing CA and checked for its revocation status via OCSP. Only then will the Luca App Scanner Check-in.txt trust the downloaded dailyPublicKey. Furthermore, the app checks the signed generation time stamp for plausibility and reject the usage of outdated dailyPublicKeys. The App then displays a QR code, updated every minute with the current timestamp and a new traceID. The QR code contains: QR code version device type keyID (specifies which daily health department key was used) timestamp traceID encrypted data (userDataKey and user id encrypted as described above) ephemeral public key verification tag checksum (SHA256 of all data above, truncated to 4 bytes) The payload is concatenated and encoded with ASCII85 to be displayed as a QR code. Upon scanning the QR code, the Scanner App in turn must asymmetrically encrypt the encrypted data and the verification tag using the venue public key. The IV is randomly generated. The Scanner App uploads the following data to the Luca backend: traceID scannerID timestamp (doubly) encrypted data IV, MAC, and ephemeral public key from the encryption device type (indicating the Scanner App) When storing this information the Luca backend associates it with the venueID (which it determines using the scannerID) and the check-in time. Self-Check-in In this variation the Guest App assumes the role of the Scanner App in order for the user to check-in at the venue autonomously. To enable this process, the venue needs to provide a QR code that encodes the required information: a valid scannerID for this venue, the venueID, and the venue public key used for the asymmetric encryption. The Guest App can use the scannerID in order to retrieve additional information about the venue from the Luca backend and display it to the user. Once the user scans the QR code using the Guest App, the App generates the same information as in the Scanner Check-in variation. Note that this involves the same validation of the dailyPublicKey signature as detailed above. Then, instead of displaying it as a QR code, it also performs the steps normally done by the Scanner App (i.e. add second encryption layer, associate with scannerID and device type) and uploads it to the Luca system.
Additional Data Luca provides the functionality to associate a check-in with additional data. This can be done by either the Guest App or by the Scanner App. Additional Data is designed to be non-sensitive data that can be used in the identification of possible contact persons. An example is the table number a user was placed at in a restaurant. Regardless of which App creates and uploads the additional data, the data is asymmetrically encrypted using the venue public key before being uploaded. Checkout When a user leaves a venue, they can be marked as checked out. This can be done (1) manually on the Guest App, (2) automatically by the Guest App, or (3) manually by the venue owner. In case of the automatic checkout the App can use the user's geo-coordinates in combination with the venues geo-coordinates and a geofencing radius. To perform the checkout the respective traceID to be checked out and the current timestamp are sent to the Luca backend. Security Considerations When encrypting the (encrypted) user data and the additional data with the venue public key the authenticity of that public key is crucial. In the Scanner Check-in scenario, this is guaranteed because the scanner app is already provisioned with the correct public key. In the Self Check-in scenario, users and the venue owners need to access the authenticity of printed QR codes, in order to avoid scanning forged QR codes that have been printed and placed at the venue by an attacker. The scannerID sent as part of the check-in data is the only indicator Luca can use in order to infer the associated venue. Forging a non-existent scannerID could potentially allow an attacker to send bogus data to the Luca system. However, this does not reveal any information to the attacker in any scenario. On a similar note, knowing the scannerID of a venue basically allows the impersonation of the venue's Scanner App. This is accepted; more specifically, this is specifically desired in the Self Check-in scenario. Notably, the physical equivalent of this would be for an attacker to "steal" the Self Check-in QR code and place it in another venue. The Luca system cannot avoid such mischief. Caused by the limited capacity of QR codes, the Guest App directly interacts with the Luca backend in the processes listed above. The Luca backend could associate the user's current IP address with the checked-in traceID, thus there is no storing of the associated IP addresses. In addition it is not possible to infer future or past traceIDs without having access to the user-owned traceSecret. Identification of contact persons The Identification of contact persons consists of two major parts: (1) tracing the location history of the known infected person and (2) finding and informing potential contact persons. Tracing the Location History of an Infected Person In the beginning of this process, an infected person is directly contacted by a local health department. The health department needs to acquire the secrets stored locally within that person's Guest App. Therefore, the health department will ask the person to reveal their personal information and location history via a functionality in the App. Step 1: Accessing the Infected User's Tracing Secret When this functionality is activated, the Guest App creates a User Transfer Object that holds the relevant information. The app will encrypt the secrets for sharing like follows: serialize userId, userDataKey and userTracingSecret in a JSON asymmetrically encrypt the serialized JSON for the current daily health department key Infection 20201122.txt upload the encryption results to Luca Luca will return a TAN The TAN serves as an identifier for the Transfer Object within Luca and does not carry any further security relevance. The Luca user can now communicate the TAN to the health department, in order for the health department to retrieve the encrypted package from Luca. In order to retrieve the encrypted Transfer Object from Luca the health department employee needs to login using their login certificate. To decrypt the encrypted Transfer Object, they further need access to the relevant daily health department keys, which they can retrieve from the Luca backend and decrypt using they HealthDepartmentEncryptionKeyPair. Step 2: Recovering the Infected User's Location History In this step, the health department finds all venues where the infected user has checked in within the relevant recent timespan (e.g. 14 days).
To start the tracing process, the health department sends the infected user's tracing secret to the Luca backend. Based on the secret and the affected userID, the backend will generate all possible traceIDs for the affected time frame. These traceIDs are used to find all trace objects checked in by the user. Luca can use the trace objects to contact all venues the infected user has attended. They will be contacted via Email and asked to reveal the potential contact persons. Step 3: Finding Potential Contact Persons The venue downloads all trace objects in the Location Frontend and validates which guests might be contact persons (for example using Additional Data attached to the trace objects). Both the Additional Data and the outer layer of encryption in the trace object can be decrypted using the Location's private key. The decrypted data is still encrypted with some daily health department key and thus is only accessible to the health departments. The encrypted data contains the userID and the userDataKey (see User Check-in). This data is then uploaded back to Luca in order to be shared with the health department. After each affected location responded, the health department can download and decrypt the traces using the relevant daily health department key. The health department now has access to the personal data of the contact persons. The authenticity of each trace can be validated using the verification secret. Security Properties User tracking It is impossible for the LUCA system to track users as they generate trace ids that can only be correlated when having the user trace secret, which will only be transmitted in an infection case and even then only readable for the health department. Users that only had contact with an infected user will not reveal their user trace secret and therefore can not be tracked. Data safety The users personal information is encrypted at all times and will only ever be readable by persons that have knowledge of the userDataKey. The userDataKey can only be obtained from the user himself or in an encrypted form from a venue that scanned his QR code. All decryption is handled locally by the respective actors. Data integrity All data stored in the luca system is in some way signed/mac'ed by the owner of the data, so no employee can alter data. Security Considerations Static Badges Badges with static content can be copied and misused. A future protection could be One-Time Badges or TAN lists with one-time use, so a QR code can only be used with a valid unused TAN. Data Analysis The LUCA system can potentially infer from the data how many users were at a venue at any given time. This could be mitigated by sending dummy checkins as noise to obfuscate the real usage. Checkin Data verification The LUCA system can not verify data integrity at certain levels. Example: The LUCA System can not verify that data was not modified by the venue. Th e venue can not verify that the provided data by the user is valid. A venue can submit arbitrary data as no verification is done by the LUCA system. But the data can and will be validated when the health department decrypts the users personal information and can then verify the authenticity and integrity of the data. Internet connection If we want to disallow venues uploading checkins for timestamps that are different to the current time, they will need to have constant internet connection while doing checkins. If we don't disallow this, they can upload checkins for scanned badges at arbitrary times as we have no way of verifying this (this only applies to badges not app users). Rogue Venues A rogue venue could invalidate users data or just not upload checkins. They could also loose, forget or destroy their venueKeyPair. Rogue User
A user can submit invalid data, which will only be detected at the decryption stage of the health department. This is mitigated by validating the phone number via SMS verification. A user can loose, forget or destroy his app and his secrets when infected. Rogue Service An employee can't alter data but they still can remove and invalidate data when having direct access to the database. Glossar Description Owner / Who has access? authentication certificates X509 certificates used to login as an health department employee himself employee healthDepartmentEncryptionKeyPair Generated once for each health department on the first login of the admin healthDepartmentEncryptionPrivKey used to decrypt the encryptedDailyPublicKey stored encrypted at luca, key is owned by every employee and the admin of the corresponding health department employeeKeyPair generated once on the first login of each health department employee employeePrivKey used to decrypt the healthDepartmentEncryptionKeyPair stored encrypted at Luca, key is owned by Health Department and it's employees dailyPublicKey used to encrypt personal information and traces during publicly stored at Luca the identification of contact persons encryptedDailyPrivateKey used to decrypt personal information and traces during stored encrypted with the the identification of contact persons healthDepartmentEncryptionPublicKey for each healthDepartment tan / user tan human readable code, generated on upload of transfer generated by App, given to Health object, transmitted via phone between guest and health Department department employee traceId derived ID of the checkin, obfuscated to only allow publicly stored at Luca tracking on infection case userDataKey randomly generated on user-side, used to encrypt stored in App in secure key storage personal information encrypted in QR code stored encrypted (twice) at Luca on checkin userId unique identifier of the user in the luca system, ex. used to identify personal information userKeyPair generated on user registration userPrivKey randomly generated store in guest app, used to sign stored in App in secure key storage transfer objects userPubKey public key of the user, uploaded to luca system on publicly stored at Luca registration userTracingSecret randomly generated on user-side, used to secure tracing stored in App in secure key storage information only given to healthDepartment when user infected userVerificationSecret used to authenticate information of the user, and to verify stored in App in secure key storage traces by the health department stored encrypted at Luca, key is the userDataKey venueKeyPair generated pub/priv key pair owned by the location owner / venue; generated on registration of the location owner
venuePrivKey private key of the venue, generate on venue/location stored encrypted at Luca, key is owned by registration venue operator a) downloaded by the location owner, and securely stored by the user or b) (private events) for one-time events, generated on stored locally at venue operator event registration, encrypted with 10-digit alphanumeric ; encrypted stored in the luca backend venuePubKey public key of venue, used on checkin to secure the stored publicly at Luca check-in /trace information Used implementations of cryptographic operations function web/node iOS Android ecc keyPair generation indutny/elliptic Apple native Security library with SecKeyCreateRandomKey Bouncy Castle ECDSA-SHA256 indutny/elliptic Apple native Security library with ecdsaSignatureMessageX962SHA256 algorithm Bouncy Castle ECDH indutny/elliptic Apple native Security library with ecdhKeyExchangeStandard Bouncy Castle AES-128-CTR digitalbazaar/forge CryptoSwift Bouncy Castle HMAC-SHA256 digitalbazaar/forge CryptoSwift Bouncy Castle SHA256 digitalbazaar/forge CryptoSwift Android MessageDigest