Carmela Troncoso Profile picture
Apr 9, 2021 40 tweets 9 min read Read on X
We hear that the Digital Green Certificate (DGC) is good news as it will enable "safe free movement". Safe free movement is great news, the technical proposal not so much

A long thread coming 👇
This thread is based on three documents:
Legal analysis: ec.europa.eu/info/sites/inf…
Technical proposal: ec.europa.eu/health/sites/h…
Factsheet: ec.europa.eu/commission/pre…
Summary in 4 tweets

The DGC documents do not provide evidence whether and how the three promises will be met:
security is not guaranteed by design ✖️
certificates cannot themselves ensure non-discrimination✖️
"essential data" might just not be essential ✖️
Worse, experts say that vaccination certs are not a clear solution to stop the pandemic

Hence, they should not entail high risks for fundamental rights
euronews.com/2021/03/18/who…
nytimes.com/2021/03/22/opi…
What the DGCs do create is a new pan-european infrastructure of automated administrative control that will be hard to disentangle from our health system. And the fast roll-out of this solution will only amplify the problems that come with this type of infrastructure
Notably, in the name of urgency, the proposal is being rolled out without a proper impact assessment: there is no good understanding of its risks or what measures might be absolutely necessary to mitigate these risks Image
Before diving into the analysis, a wild thought: A standardized (photographed,pdf) paper may be an efficient way to visually check vaccination status with *enough* security. And it comes with a huge gain: no longlasting, hard to control, harmful infrastructure
Now, the analysis👇
CLAIM 1 "Be accessible and secure for all EU citizens"

The framework gives no information to assess accessibility claims. I'll leave it as ❓

There is no actual security definition. I'll assume it means that users cannot have a valid DGC if they are not vaccinated/tested
The security of the system relies on digital signatures. For a DGC to be accepted the signature must be valid, and the signing key must be trusted Image
So, security relies on (1) the signing keys being well protected, and (2) that those who can can create signatures are trusted.

The framework foresees that DGCs can "be issued by hospitals, test centres, health authorities." Image
Will every authorized employee at these institutions have their own signing key? If so, how will they be secured? How can we be sure they are? Employees could lose their keys, or lend them to others voluntarily or under coercion
A common solution to avoid the problems that stem from trusting humans with keys problems is to outsource the signing key to another party or IT system that is easier to secure, and then have this party sign on their behalf
When signing is outsourced, how can the signer ensure that they create a DGC for the correct person? Or that this person has been vaccinated? How it is even possible to know whether an authorized person requested the signature and not a hacker that gained control over a computer?
The security of the DGCs depends on:
-No signature key being stolen
-No IT system of test center/hospital being hacked
-No employee (doctor, nurse, IT,...) of test center/hospital being coerced or corrupted

in any country whose keys are accepted by countries in the program
To make things worse, if any of these conditions is not met, it is not that we get one DGC that is invalid. Because of the trust architecture, such a security breach can lead to fraud at scale as many illegitimate DGCs can be easily produced
In summary: the system is not secure by design. Security depends on many actors being well-behaved. In such a complex system, where many actors with poor digital capacity are expectd to partake in, we can expect this not to be true in many cases
So the question is: how secure is a digital certificate in reality? does it provide enough security to outweigh the risk of discrimination and surveillance that it brings? does it really pay off to build such an infrastructure?
While we are on the signature topic. What happens if a signing key has been abused? The proposal says there will be a list of revoked certificates per country. Will that country add all certificates signed by the abused key? Image
And how will countries know which certificates to add to the revocation list? Only the "fraudulent" ones? How is that determined? Do they add all certificates signed with that key? What happens to the people who were legitimately vaccinated and signed under this key?
Traditionally, revocation builds on top of a PKI hierarchy. It seems, however, that DGC does not implement such a hierarchy but instead implements a semblance of such a structure via a custom EU gateway. Why use established solutions when you can roll your own?
Revocation is one of the most complex and hardest tasks in security. The underspecification of this process (only one section with vague reference to a list) leaves the door open to bad or incorrect implementations that can either decrease security, decrease utility, or both
Revocation cannot be left for future specification and the potential implications should be part of an impact assessment and fundamental part of deciding whether we should prop up this infrastructure to begin with
CLAIM 2: "Be non-discriminatory".

I don't even know where to start... the DGC in and of itself cannot be non-discriminatory. You may or may not have a DGC, but that fact by itself does not dictate what you can do, where you can go or what services you can receive
What matters for discrimination is not only the possibility of having a DGC. It is what the DGC will give access to, and under which circumstances.

Example: if I have a DGC, but it says I am not vaccinated, can I travel? or go to a concert? or the pub? or to the synagoge?
So the question is not whether the DGC is available. The questions are:
1) what are the conditions (vaccination, negative test) to receive a DGC that enables access to services and free movement?
2) how can people achieve these conditions, and can everybody achieve them?
In summary: "DGC is non-discriminatory" is a void statement that distracts from real issues: what will the DGC give access to, for whom, and under what circumstances. Only with the answer to these questions we can have a discussion about discrimination
CLAIM 3: "Contain only essential information". The certificate in itself is not a purpose, so it is not possible to claim it has only the essential data. Essential for what? The documents do not provide a goal or a justification.
The minimal set of data proposed is pretty extensive, and not justified for the purposes one can foresee. Image
From a data minimization perspective, if the DGC is only about movement, why, for example, is DoB included? why is the country where the dose were given relevant? or the signing authority? These reveal lots about people and their whereabouts, but have NO role in verification
And more important, why is a unique identifier needed to validate the certificate? This unique number associated to a name creates an electronic identity but serves no purpose to cross a border. The docs say "link back to the underlying data registry" but...
What data registry? What is the goal of this link? Who holds this database? Who has access to it?

The answer is: THEY DON'T KNOW. This essential number's use will be *defined in the future* Image
Setting aside the registry, and assuming these data are indeed essential, nothing in the proposal limits the collection and processing of these data. According to the documentation limitations are only by policy, no technical barrier for collection Image
An additional claim is that the DGC "will [] secure personal data". However, the machine-readable data in the DGC is not even encrypted! So there is no by-design mechanism to prevent anyone from reading, processing, and storing all the data in the DGC

Image
(worth noting that the proposal suggests the possible use of selective disclosure -- only showing some attributes-- using cryptographic credentials. But these are already *unencrypted attributes*. How would selective disclosure even work? Yet another inconsistency)
Very worrisome: the proposal completely ignores metadata associated with verification. The verifier can collect times, locations... these practicces are not even discouraged, just not accounted for despite their potential for surveillance.
Even worse, the proposal foresees that there could be online verification. This type of verification would give the online verifying partner full visibility on citizens movements in real time. What are the safeguards planned?
Nicely, the proposal specifies that a central database is not required. But it is neither forbidden nor discouraged. Such databases will arise, with little chance to control their reuse for any purpose, with online verification capability

What other functions will they support?
In summary:
there is no support for the claim that only essential data is present
there is no protection by-design of
the data in the DGC
data or metadata collection by third parties
against centralization of this data
My conclusion is: this is an immature design of an extremely complex infrastructure with no guaranteed security. The proposed scheme is likely to go down the slippery slope of discrimination and surveillance.
I'd like to end reminding my wild thought: Given that fraud is possible anyway, a simple paper-based solution with enough protection to deter cheating may be sufficient to get us through this summer, avoiding long-term consequences

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Carmela Troncoso

Carmela Troncoso Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @carmelatroncoso

Aug 6, 2021
I was going to write about how Apple's new detector for child sexual abuse material (CSAM), promoted under the umbrella of child protection and privacy, is a firm step towards prevalent surveillance and control, but many others have already written so good stuff. Some of it 👇
First, don't be fooled by the fancy crypto and the flashy privacy claims. This is a backdoor to encryption. Yes, folks, a privacy-preserving backdoor is no less of a backdoor. We are back to the crypto wars. @EFF goes at lenght about this in their analysis eff.org/deeplinks/2021…
Can be said louder, but not clearer
Read 13 tweets
Oct 13, 2020
Yesterday, I had a business lunch. The restaurant asked me to input my data on SocialPass, an app now mandatory in Canton Vaud for restaurants gastrovaud.ch/coordonnees-de…
I get the need for tracking, not the creation of abusive surveillance infrastrutures ignoring data protection👇 Image
The app is extremely invasive. The designers have not heard of Data Minimization. It is unclear why my address, my name, or *my date of birth!* is at all necessary for a tracer to call me (yes, all fields mandatory and phone number checked via SMSa) Image
The privacy policy does not specify the purpose of the collection of these data (also not heard about purpose limitation)
socialpass.ch/protectiondesd…
I have to give it to them that they say they won't use or sell the data... Why even collect it then??????
Read 9 tweets
Apr 3, 2020
As countries deploy data-hungry contact tracing, we worry about what will happen with this data. Together with colleagues from 7 institutions, we designed a system that hides all personal information from the server. Please read and give comments!
More info in our repo: github.com/DP-3T/
3-page brief: github.com/DP-3T/document…
White paper: github.com/DP-3T/document…
Data Protection: github.com/DP-3T/document…
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(