Manipulation of the luca webapp leads to unverified phone numbers

[philipp-berger]

As the code of the webapp is freely editable, it is possible to uncomment the verification step or to change the phone number in between. This leads to a wrong phone number (not reachable or somebody else) being submitted in the encrypted data object.

A false identity has 2 consequences (as with the analog way) a) I am not informed if I am a risk person and cannot be tested. b) someone else is informed, resolves the misunderstanding, and effort was generated for nothing.

As it is not possible to secured the JS code executed in the browser from manipulation, let's evaluate some mitigation or resolutions.

[FrankGrimm]

Would the following work?

In the "send TAN" stage of guest registration, you could Blake2/HMAC/... the phone number to be verified with some (potentially rotating) secret, upon verification of the TAN on the Luca Server you send this hash back to the Guest App (as part of the verification result) and include that information in the contact data asset.

The above does not require storage of the guest's phone number outside of the asset and allows for verification when contact data is later decrypted (since that contains all necessary information, the phone number in question, hash, and optionally the registration date or key ID).

[philipp-berger]

Actually, good idea, as this would allow the health department to check the verification status of the phone number (using the proposed concept).

This would resolve the issue that "someone else is informed". We are still thinking of a concept to also solve the issue that the person itself is not informed.

The problem with traditional signatures (for phone number authentication, for example) is that the signed artifact must match the verified artifact. No matter how you slice it, the verification process for phone numbers and the validation process when uploading encrypted information need a common size for proving authenticity. This is messy, because profiling is (theoretically) possible in this way.

Another currently discussed approach is the extraction of the phone number into an own artifact linked with the contact data. As we like to prevent the "profiling", we are also evaluating an extension of the current approach by on-demand creating the contact data asset on check-in. We keep you updated if new drafts coming up.