-
Stupid questions about Public-key cryptography and QR Code Vaccine Passports
Posted by edy on 24 Sep, 2021 19:11 -
I have had some fascination with public/private-key cryptography for some time and even managed to generate a key-pair back in 2014 and uploaded my public key to the MIT server (and more recently OpenPGP key server). More recently I've played around with it because of the soon-to-be implementation of QR Codes being introduced in my province to validate vaccination status. I've been trying to wrap my head around how it will be done and even created a test-bed using various PGP apps I've downloaded, but I had some extra questions. I'm sure someone here can answer it.
First, the QR code vaccine status. My understanding is that the Health Ministry in my province will be signing a block of text containing information like your name, health card number, vaccination dates, etc. When I used my PGP software and signed my text block with my private key, I would see the text still in "plain-text" but there would be a signature tagged on afterward. If I modified the text at all, when I tried to authenticate it would show it was tampered with.
So I am assuming our Health Ministry will be issuing us basically a signed block of text using their private key, turned into a QR code. I signed some text with my private key, converted the block into QR codes, then scanned them back to retrieve the text, dumped the text back into PGP and authenticated with my public key and it proved I was the one that signed the original message and that it wasn't tampered with.
This would be a quick way for people to prove they do not have fake vaccine records, as the information presented at public events/restaurants/etc. would have to be authenticated by a highly publicized Health Ministry public key. And you could only get your vaccine record downloaded and properly signed by government using a private key which supposedly will be highly secured on their servers.
Now, my question is this... I want to ENCRYPT the text block with my PRIVATE key as well so that the plain-text isn't immediately obvious. Encrypting in and of itself would automatically authenticate because anyone who wanted to see my message could only see it if they used my PUBLIC key on it, right? Why do I need to "sign" it and have a signature tagged after my plain-text message? Could I not just encrypt the whole message?
My PGP software gives me the option of using my PRIVATE key to sign but the software also asks for a recipient's PUBLIC key, assuming that I want to only send the message to that specific person (then they use their PRIVATE key to unlock it, and my PUBLIC key to authenticate it came from me). Is this a limitation with the software I'm using? It will let me SIGN stuff but includes the original message in plain-text. When I want to ENCRYPT it will *NOT* allow me to choose any private keys to encrypt it with... only PUBLIC keys are available.
I thought maybe a way to get around this is to have 2 key-pairs... one for signing and one for encryption purposes. So the one used for encryption would use the PUBLIC key to encrypt, but recipients would need the corresponding PRIVATE key to decrypt... meaning I would have in fact reverse roles... I'd keep the encryption PUBLIC key secret and share the encryption PRIVATE key with everyone out there so they could decrypt any messages I generate.
Also, the second key-pair for signing only, I would use as normal to sign the message, so everyone can authenticate the message has not been tampered with by authenticating it using my Signing PUBLIC key (whose PRIVATE counterpart was used to sign the message).
I don't know if this is just a software issue or I'm thinking about this all wrong. But this is all because my software doesn't let me encrypt messages with my private key, it only lets me sign them with my private key and so the message is retained in plain-text. It only gives me the option to encrypt with someone else's public key... which automatically targets the message to them only. And to get around that I have to make another key-pair which essentially pretends everyone "out there", aka "the public", is one person and so I have to share the "private" key with everybody instead, and keep the public key for myself, which seems kind of backwards.
Any help wrapping my head around this would be great. I can post some examples too if needed on my trials and errors playing around with it.
-
Now, my question is this... I want to ENCRYPT the text block with my PRIVATE key as well so that the plain-text isn't immediately obvious. Encrypting in and of itself would automatically authenticate because anyone who wanted to see my message could only see it if they used my PUBLIC key on it, right? Why do I need to "sign" it and have a signature tagged after my plain-text message? Could I not just encrypt the whole message?
If you encrypt the text with your key then only you are able to decrypt it, or any other person who has a copy of your private key. But your signature can be verified by using your public key. The idea is to keep the private key private and to publish the public key. The public key is used to encrypt a message to you or to verify your signature (and that your message wasn't altered). The private key is used to decrypt or sign messages. Private and public keys are not two different keys. They are a pair of keys, each key part has its special function. BTW, you can encrypt and sign in any combination.My PGP software gives me the option of using my PRIVATE key to sign but the software also asks for a recipient's PUBLIC key, assuming that I want to only send the message to that specific person (then they use their PRIVATE key to unlock it, and my PUBLIC key to authenticate it came from me). Is this a limitation with the software I'm using? It will let me SIGN stuff but includes the original message in plain-text. When I want to ENCRYPT it will *NOT* allow me to choose any private keys to encrypt it with... only PUBLIC keys are available.
If you want to encrypt something for yourself then use your own public key. It's the basic philosophy of asymmetric cryptography.I thought maybe a way to get around this is to have 2 key-pairs... one for signing and one for encryption purposes. So the one used for encryption would use the PUBLIC key to encrypt, but recipients would need the corresponding PRIVATE key to decrypt... meaning I would have in fact reverse roles... I'd keep the encryption PUBLIC key secret and share the encryption PRIVATE key with everyone out there so they could decrypt any messages I generate.
No, you just need one key pair. Each part of your key pair has its special purpose. But there are signing keys (key pairs) meant for signing other keys. The idea is that a trusted entity signs your key to let others know that you are the person you claim to be.Also, the second key-pair for signing only, I would use as normal to sign the message, so everyone can authenticate the message has not been tampered with by authenticating it using my Signing PUBLIC key (whose PRIVATE counterpart was used to sign the message).
Again, you need just one key pair. You could use two key pairs, one for encryption (for you) and one for signing. But it would confuse other users because they might not know which key is for which purpose - they see two different public keys and aren't any wiser. -
If you want to read about how it is implemented in BC there are some comments here:
https://old.reddit.com/r/vancouver/comments/pmzil5/so_how_does_the_vaccine_qr_scanner_work_offline/hcltrrj/?context=3
https://old.reddit.com/r/vancouver/comments/ppgy0i/i_made_a_working_decoder_for_the_information/hd3lrks/ -
When you encrypt, the cyphertext size will depend on how big the plaintext message was. When you sign, the signature size will always have same length, equal the size of the public key.
-
Thanks for the Reddit links and explanations. It seems to work as I thought, basically just signed plain text (or in the case of the vaccine a base64 coded block). There will be an app to download and they will be releasing source code to provide transparency to reduce public fears of “Big Brother”. I suspected it would not require a live internet connection so this way as long as the app has the government public key embedded in it to authenticate the signature, something to scan the QR code and decode the base64, I assume it will look for the name field in there and display it for the business owner to match against the ID of the person. Otherwise the app will determine if and how many times you were vaccinated. So all it should display the business owner is a name and a green check mark or red “X”. The name so you can verify the person in front of you is who they claim on the photo ID card, and the green/red basically a pass/reject. No encryption seems to be involved so the info can be easily read once you run it through a base64 decoder. It’s only signed to ensure you don’t generate your own fake QR codes.
-
The Federal government mandated that all provinces follow the SMART Health Card standard. The spec is here: https://spec.smarthealth.cards/ . It should answer all your questions.
-
Nothing can ever really be made secure, from the citizen's perspective, about making people present a digital domestic ID card to go about daily life. All round a very bad idea, does nothing but make people less trusting, more antagonistic, and makes those who are hesitant to get vaccinated all the more unwilling. The way out of this mess has to be trusting people to do the right thing and be hygienic, not tracking their every movement.
-
Nothing can ever really be made secure, from the citizen's perspective, about making people present a digital domestic ID card to go about daily life. All round a very bad idea, does nothing but make people less trusting, more antagonistic, and makes those who are hesitant to get vaccinated all the more unwilling. The way out of this mess has to be trusting people to do the right thing and be hygienic, not tracking their every movement.
Whine somewhere else. -
From now until Oct 22 when the Health Ministry comes out with a signed vaccine QR code, people can present easily-forgeable "vaccination receipts" since there is no way to authenticate whether it is real or somebody copied another receipt and changed info. Not only that, but most are just printed paper or PDF or scanned images on phones that have a name that a business is supposed to match to whatever ID the person presents (to show the receipt belongs to them).
Funny thing is, even after Oct 22 it seems the government will still allow this form of proof. Too many old people either without phones or the know-how to get QR codes will be allowed to use this, so it seems.
There is currently an independent coding group of volunteers working to bridge the gap by making validation QR codes available for easy storage (Apple wallet) and presentation with a verification app. They published their entire open source on Github. They are found here: https://grassroots.vaccine-ontario.ca/
I spoke to one of the developers and even with this system it can be easily forged because they purposefully DO NOT collect or store any identfiable information for privacy reasons. Therefore a QR code generated by this system could be copied to other users as the verification app a business uses to screen people doesn't display the name of the person for whom the QR code has been created! The QR code only contains vaccination details but no personally identifiable information. They did this because as a volunteer coding group they didn't want to get into a legal privacy debacle like happened with some other government roll-outs of half-baked apps that leaked user info. What the heck is the point of a receipt if you can't verify it belongs to the person it is supposed to be for?
So basically right now it is a mess until the government forces everyone to download and use a digitally signed receipt that makes the name and date of birth available to whoever scans it, makes businesses validate it using a well-known easily verifiable public key, and introduce a system to continuously issue updated signed receipts and public keys for verification purposes as private keys either expire or get compromised. And enforcement is another issue as there are a growing number of businesses who are just refusing to even check people.
-
So basically right now it is a mess until the government forces everyone to download and use a digitally signed receipt that makes the name and date of birth available to whoever scans it, makes businesses validate it using a well-known easily verifiable public key, and introduce a system to continuously issue updated signed receipts and public keys for verification purposes as private keys either expire or get compromised. And enforcement is another issue as there are a growing number of businesses who are just refusing to even check people.
Interesting to see how different provinces are failing at this differently.
Here in BC as of Sept 26, the signed QR code is the only acceptable proof of vaccination (there are some exceptions for Canadian Forces, international visitors and such). They didn't roll out vaccination requirements at all until the SHC was available, but gave a few weeks where the handwritten records were acceptable. The first few days of availability the system was overloaded, but it's been working well now. Their verification app works well, shows the person's name (but not DoB for some reason, though it is in the QR code) for verification against their ID, doesn't require Internet and seems pretty fast. I've been to a few places that aren't using the proper scanning app to verify, which is allowed, so people could use forged ones at those places, but overall compliance seems to be pretty good here in Vancouver. Who knows about parts further out, but technically they should be requiring it and checking ID and the fine is pretty stiff ($2300).
Where they have failed IMO is that there is no app for citizens to access their QR code in an easy manner. Instead they link you to a PNG (originally they had a PDF option, but this seemed to overload the system so they quickly took it down) and then tell you to screenshot or save it to your phone, and then leave it up to you to figure out how to access it quickly, which isn't all that straightforward on phones these days. They also aren't surfacing the .smart-health-card file in their UI (or presumably at all) as the SHC spec 'requires', which would make it easier for potential third-party apps to pick it up automatically as a MIME handler rather than some convoluted QR scanning or something. A simple app would help usbility a lot, especially for the less tech savvy, and really all it needs to do is ingest the .smart-health-card file and produce a QR code when opened.
So meh, I'm alright with the implementation here.