[conspire] Checking a CDPH Digital COVID-19 Vaccine Record

Rick Moen rick at linuxmafia.com
Thu Sep 9 16:02:59 PDT 2021


I wrote:

> CA Dept. of Public Health signed aboard with SMART Health Card.
                                               ^^^^^

As one of CABAL's public services is to help you being annoyingly
pedantic, you can now drop "Substitutable Medical Applications, Reusable
Technologies" randomly into conversations, the way I'm sure you already
do "Light Amplification by Stimulated Emission of Radiation" (LASER), 
"RAdio Detection And Ranging" (RADAR), "SOund Navigation And Ranging"
(SONAR), "Laser Imaging, Detection, And Ranging" (LIDAR: recursive
acronymitis noted in passing), and "LOng RAnge Navigation" (LORAN, of
blessed memory).

Acronyms notoriously infest the military, but also healthcare, 
particularly in government agencies and non-governmental organisations
(NGOs) concerned with it.  So, starting in the 2000s, there was a lot of
concern over standards for EHRs -- er, electronic health records,
creating standard record formats and communications protocols to deal
with the Tower of Babel problem.

Thus, in 2010, Boston Children’s Hospital Computational Health
Informatics Program and the Harvard Medical School Department of
Biomedical Informatics founded "SMART Health IT" to define a "health
data layer", leveraging the pre-existing FHIR (Fast Healthcare
Interoperability Resource) API and resource definitions.  After SMART
Health IT bubbled away for a few years on a $15M four-year government
contract from Dept. of Health and Human Services's (HHS's) Office of the
National Coordinator (ONC), and developed prototype code and specs, the
five largest EHR vendors got together with the SMART folks to work with
yet another group, the HL7 organization (aka Health Level Seven
International, https://en.wikipedia.org/wiki/Health_Level_7, a reference
to the OSI protocol model's application layer, which is level 7),
creators of the FHIR interoperability standard for exchange of
healthcare information -- to build SMART into the releases of the
vendors' products, and to standardize the SMART API in HL7 specs).

And, in 2020, HHS got a requirement for SMART as a med biz
interoperability standard written into the 21st Century Cures Act.

https://en.wikipedia.org/wiki/21st_Century_Cures_Act#Medical_software
https://en.wikipedia.org/wiki/Electronic_health_record#Open_specifications
https://smarthealthit.org/an-app-platform-for-healthcare/about/
http://www.hl7.org/
https://smarthealthit.org
http://radar.oreilly.com/2012/09/growth-of-smart-health-care-apps-may-be-slow-but-inevitable.html



> An app that verifies a SMART Health Card needs to do the following:
[...]
> Read the iss field, which contains the issuer’s Web address. 
> This is then used to find the issuer's public key under
> /.well-known/jwks.json , which then gets fetched off the Internet.

At a quick glance, in this and other areas, the SMART Health Card
infrastructure strikes me as being fundamentally limited in its security 
aspirations by the security of the network and DNS used to verify 
cards.

Ain't we going to have fun, when the blackhats start playing around 
with this stuff?


> Since anyone can issue a SMART Health Card, maintain a list of
> trusted issuers (trust directory) and verify the contents of the iss
> field against this list prior to continuing.  If issuer is trusted,
> proceed to download the key and use it to verify the signature.

So, basically, any person or software that evaluates a SMART Health Card
has to start with some inbuilt sense of "here's a list of 50 certifiers 
of EHRs I trust as being non-bozos, and equally trustable with each
other, and anyone else's key signatures shall be interpreted as being
from bozos".  

This is basically the same general type of security model as is used for
Certificate Authorties (CAs) that attest to Web site certs.

Which means it's kind of, well, bad.

I mean, not catastrophicaly bad like where you have hundreds of CAs all
over the world, some of which are inept, some of which are corrupt, some
of which are under the control of hostile government spook agencies, and
some of which are probably some combination of those three, all of them
declared interchangeably perfect sources of truth, but as with CAs at
the mercy of any bad actor who's considered a certifier, and also
necessitating Master Lists of Trusted Oracles Who Sign Things.

The software specs have a very 2010 flavour-du-jour aspect, like the
love of JSON.  I'm sure if I kept looking, there'd be XML peeping out of
there, somewhere.  I also see a lot of W3C Semantic Web stuff in there
(https://www.w3.org/OWL/).  

Hey, bingo!  XML!
https://en.wikipedia.org/wiki/Health_Level_7#Version_3_messaging


Anyway, much is now explained about California Dept. of Public Health's 
Digital COVID-19 Vaccine Record.


First, I wonder (generally) why they wrote it that way?  Answer: 
They _didn't_ write it.  They leveraged the SMART Health Card,
completely off the shelf, unmodified.


Second, I wondered why there was absolutely no effort to have
compatibility with European Union Digital COVID Certificate (EUDCC)
and EU COVID-19 Travel Certificate -- used in almost all EU member 
states, as well as in some other European countries such as Iceland, 
Switzerland, and Norway.  In Europe, EUDCC issuers are generally 
national health authorities, and recognise each other.  Some other
countries like UAE and Australia (not to mention the UK's NHS COVID
Pass), have created their own digial EHR standard for COVID-19
vaccination, and now, so has California, likewise New York’s Excelsior
Pass, and doubtless others.  But basically, the European national health
authorities have a sufficient degree of trust in each other to
automatically consider each other's word equivalent, and to trust that
each complies with the European Medicines Agency (EMA)'s guidance about 
vaccines and with other EU practices such as GDPR -- and so naturally
with every outside authority, trust is an open question, and, to pick an
example, how would Switzerland know whether it ought to trust Rite-Aid's
IT Department?

Looks like the EUDCC's spec definition is gratuitously different from
that of SMART Health Card (or vice-versa), but use hilariously 
identical concepts, right down to the JSON and CA-like attesting.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021D1073

So, looks like the answer to my question #2 is:  California's set of
attestation authorities are one pope, and the EU's are another, and 
neither trusts the other's theology by default.  Predictable.






More information about the conspire mailing list