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 👇 https://twitter.com/EU_Commission/status/1372159608542871557
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 ✖️
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
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
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."
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?
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.
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*
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
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

(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 https://twitter.com/carmelatroncoso/status/1380439792001945602
You can follow @carmelatroncoso.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: