Redesign QR codes for more security and verification

[naftis]

The QR code link includes the https://farajaland.opencrvs.org/... -prefix for the URL. Imagine someone adding their own QR code with https://farajaland.0pencrvs.org/... and showing something that doesn't exist in reality. Could we only use the URL-suffix for the QR codes?

We would need to design a way to scan the QR code within OpenCRVS.

[euanmillar]

@eduffus @rikukissa I think we should consider discussing & prioritising this in 1.5 as this could be a way to steal a staff members password.

[rikukissa]

So to play this out, the attack vector is:

1. Attacker creates a realistic looking printout of the certificate
2. Staff member scans it, a realistic-enough looking OpenCRVS login opens up
3. Staff member types in their username and password
4. Attacker gets VPN credentials or has them already, accessing internal network where the real OpenCRVS is installed
5. Attacker accesses the real OpenCRVS login page, inputs username and password
6. Attacker gets staff member's 2FA from somewhere

My interpretation is that while this could happen, it's not a likely attack vector. VPN and 2FA will prevent logging in even if login credentials are compromised. We should still change the approach not to let the QR control the scanner's device.

Another requirement for the next iteration of the QR reader will be that scanning needs to work offline. Burkina Faso is asking for this. The main difference in approach, that will support both fixing the phishing attack and offline, is the staff member using an existing OpenCRVS feature for scanning the QR. That way we can remove the URL from the QR and embed whatever information we want in the QR code.

• Cryptographically verifiable token. This would have to be similar to JWT where the QR consist of [certificate details].[checksum]. The QR reader app would read this and use a known public key to verify the checksum is correct and created by the country config package using a secret key.
• Scanner client. This is a good chance to experiment building this UI to the country config instead of core. A more modular approach we could use for many things moving forward.

[naftis]

@rikukissa I think the attack vector is simpler, although this is more of a operations scam and not a password phishing issue.

1. Attacker creates a realistic looking printout of the certificate
2. Staff member scans it, a realistic-looking verify certificate page pops up
3. The staff member thinks the certificate is real and approves something based on the birth certificate

[rikukissa]

A few noteworthy challenges with offline digital signatures embedded to QR:

• If the private key used to sign the information leaks, all issued certificates need to be renewed
  • Would be safer to only print these to certified copies with for instance 6 month validity. This would reduce the impact, risk and reward of hacking the system.
• Signing algorithm should be well thought out and standard to the industry so there won't be a need later on to support reading multiple QR variants. WHO / EU COVID certificates could be a potential reference.