Legacy SHC revocation

[christianpaquin]

Pre v1.2.0 SHC revocation (to be specified externally)

Starting from specification v1.2.0 (per PR #205), SMART Health Cards can be revoked using a revocation ID rid encoded in their Verifiable Credential object. Health Cards issued using an older specification version, or Health Cards issued without a revocation ID can use the following schemes to calculate a dynamic identifier from the Health Cards content. Issuers sets up their Card Revocation Lists as specified in the SMART Health Card Framework (including support for revocation time ranges), using the specified method identifier.

See discussion #207 for background; some ideas proposed there could still apply to what's proposed here.

Why multiple scheme proposals?

Two methods are proposed, one that works well in closed ecosystems (e.g., a single state or province), vs one that works for all the SHC ecosystem. An issuer could potentially support both, one to prevent fraud in its own jurisdiction (more common in term of SHC usage), and one for out-of-jurisdiction SHC use.

Revocation ID schemes

FHIR Bundle digest

Method identifier: hash-fhir

To use this scheme, an issuer needs to be able to recreate the FHIR bundle for the revoked Health Cards. If this is not possible, multiple FHIR bundle “candidates” can be created (e.g., using the various immunization events), from which multiple revocation IDs are calculated and added to the revocation list.

Given a FHIR bundle, the revocation ID rid is computed as the base64url encoding of the first 64 bits of the SHA-256 digest of the base64url encoding of the UTF-8 encoding of the minified FHIR bundle.

Privacy considerations

This mechanism could allow a sophisticated attacker to brute force the data needed to match a published CRL entry. For n bit of entropy contained in the bundle (which varies depending on the issuer), 2^n hash calculations are needed to match a CRL digest. An issuer should be comfortable with the disclosure risk before using this method.

Patient resource digest

Method identifier: hmac-patient

To use this scheme, an issuer needs to be able to recreate the patient resource for the revoked Health Cards. The issuer creates a random 256-bit secret revocation key, that it privately shares with trusted verifiers.

Given a FHIR patient resource, the revocation ID rid is computed as the base64url encoding of the first 64 bits of the HMAC-SHA-256 output of the base64url encoding of the UTF-8 encoding of the minified FHIR patient resource, using the issuer revocation key.

Because of the low-entropy in a patient resources, publishing their hash digests is almost equivalent to publishing their content. Therefore, this method uses the HMAC message authentication code with SHA-256 and a secret key shared between the issuer and a set of trusted verifiers. This prevents brute-forcing the matching patient resources, but can only be used in closed systems where verifiers have a back-channel to the issuer.

[bradhead]

What is the model for those issuers that can neither (with confidence) reconstitute the FHIR bundle issued, nor the Patient resource, and has not yet adopted the revocation ID concept?

…

On Nov 17, 2021, at 11:30 AM, Christian Paquin ***@***.***> wrote: Pre v1.2.0 SHC revocation (to be specified externally) Starting from specification v1.2.0, SMART Health Cards can be revoked using a revocation ID rid encoded in their Verifiable Credential object. Health Cards issued using an older specification version, or Health Cards issued without a revocation ID can use the following schemes to calculate a dynamic identifier from the Health Cards content. Issuers sets up their Card Revocation Lists as specified in the SMART Health Card Framework, using the specified method identifier. Revocation ID schemes FHIR Bundle digest Method identifier: hash-fhir To use this scheme, an issuer needs to be able to recreate the FHIR bundle for the revoked Health Cards. If this is not possible, multiple FHIR bundle “candidates” can be created (e.g., using the various immunization events), from which multiple revocation IDs are calculated and added to the revocation list. Given a FHIR bundle, the revocation ID rid is computed as the base64url encoding of the first 64 bits of the SHA-256 digest of the base64url encoding of the UTF-8 encoding of the minified FHIR bundle. Privacy considerations This mechanism could allow a sophisticated attacker to brute force the data needed to match a published CRL entry. For n bit of entropy contained in the bundle (which varies depending on the issuer), 2^n hash calculations are needed to match a CRL digest. An issuer should be comfortable with the disclosure risk before using this method. Patient resource digest Method identifier: hmac-patient To use this scheme, an issuer needs to be able to recreate the patient resource for the revoked Health Cards. The issuer creates a random 256-bit secret revocation key, that it privately shares with trusted verifiers. Given a FHIR patient resource, the revocation ID rid is computed as the base64url encoding of the first 64 bits of the HMAC-SHA-256 output of the base64url encoding of the UTF-8 encoding of the minified FHIR bundle, using the issuer revocation key. Because of the low-entropy in a patient resources, publishing their hash digests is almost equivalent to publishing their content. Therefore, this method uses the HMAC message authentication code with SHA-256 and a secret key shared between the issuer and a set of trusted verifiers. This prevents brute-forcing the matching patient resources, but can only be used in closed systems where verifiers have a back-channel to the issuer. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#207>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJHJ3N6TQMBNZZWNLBSRQWDUMP7ERANCNFSM5IHZYRUQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[christianpaquin]

There are little that can be done for issuers that don't have any state for previously-issued SHC. Can you elaborate on the situation? When and how such an issuer be made aware of a fraudulent SHC being issued? What minimal information would such issuer have to potentially identify the card?

[bradhead]

We generate SHCs on the fly and cache until the source data mutates. We do not journal/log the SCH generated nor do we journal any hash of it. Citizens can fetch self-service any time. The Source data may change including the patient resource at any time. Since the patient resource has no identifier in it we also cannot rely on a hash of it since it too may have mutated. Excuse the typos. Sent from my iPhone,

…

On Nov 17, 2021, at 12:03 PM, Christian Paquin ***@***.***> wrote:  There are little that can be done for issuers that don't have any state for previously-issued SHC. Can you elaborate on the situation? When and how such an issuer be made aware of a fraudulent SHC being issued? What minimal information would such issuer have to potentially identify the card? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[christianpaquin]

Let me flip the question around: given your situation, can you propose a revocation mechanism that would work? (either in a closed system with specific verifiers, or for the broader SHC ecosystem)? How would you (or the source data provider) 1) determine that a card (or person? or immunization?) would need revoking, and 2) how could you achieve this? Patient resource simply contains name and DoB, so that should be immutable enough, no?

[bradhead]

Time range based with the caveat that we are able to reconstitute Patient resource as a set of possible values over time then use a tuple of ( kid, patient resource hash(es) + time range) , with patient hash as an Or-ed collection of possible values to cover off the mutations . Excuse the typos. Sent from my iPhone,

…

On Nov 17, 2021, at 12:24 PM, Christian Paquin ***@***.***> wrote:  Let me flip the question around: given your situation, can you propose a revocation mechanism that would work? (either in a closed system with specific verifiers, or for the broader SHC ecosystem)? How would you (or the source data provider) 1) determine that a card (or person? or immunization?) would need revoking, and 2) how could you achieve this? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[christianpaquin]

I believe the hmac-patient method above achieves that (you can use time ranges, as per the main SHC revocation method). Although we propose using hmac hashes to prevent brute-forcing the revocation id (in which case verifiers need to obtain the hmac key from the issuer).

[pvillela]

@christianpaquin, #207 describes the FHIR bundle digest legacy revocation scheme at a very high level. Where will additional details (such as in #204 (comment)) and pending decisions be described, e.g., use of kid (or <group id>) for publishing of revocation files?

[christianpaquin]

The proposal here is to use the exact same structure for per-kid revocation files (as per #205), with counters; only the calculation of the rid is different. The method identifier in the CRL file tells verifier how to manage the rid (calculate it based on the SHC's content, or use the one contained in the SHC). First step: get feedback on the approach. Second step: flesh out the details and decide where this "profile" would live, adjacent to the core spec.

[pvillela]

Thanks for the clarification, @christianpaquin. If I understand correctly, a given kid will be associated with a single revocation method. Thus, when an issuer starts tracking issued SHCs and their respective rids, it should start using a new key from that point onward, right?

[christianpaquin]

If I understand correctly, a given kid will be associated with a single revocation method. Thus, when an issuer starts tracking issued SHCs and their respective rids, it should start using a new key from that point onward, right?

That is my suggestion, yes. It's debatable (we could specify a way to support multiple revocation methods for one key), but I'd try to keep things simple and I think that's a low friction way to do it.

[p2-apple]

If I read this correctly this allows us to revoke any specific FHIR bundle, not the actual SHC around it. Is this desirable? This means it's impossible to re-issue the same FHIR bundle (e.g. a Patient and 2 Immunization resources), is that right? Is this really desired or do we run the risk that SHCs issued, then revoked, then re-issued without changing the FHIR bundle (because the data is actually correct) will be invalid out of the gate?

[christianpaquin]

I realize this page is a bit confusing on its own. These methods are meant to extend the current proposal in PR #205, which allow for time ranges. You'd be able to effectively revoke a FHIR bundle up to a certain datetime, to invalidate previously issued cards.

[p2-apple]

Ah I see, thank you!

[pvillela]

I'm confused about the SHC version numbering. This discussion mentions v1.2.0 but, as far as I can see in the repo's tags and releases, the current version is still v1.0.0-RC. This begs the question -- where can I find v1.1.0?

[christianpaquin]

Current version of the specification is 1.1.1, as listed in the changelog. The revocation PR would bump that to 1.2.0.

[pvillela]

Thanks, @christianpaquin. However, the list of releases and tags in the repo does not make it clear that the current version is 1.1.1.

[christianpaquin]

A bit confusing, I agree. I opened issue 209 on the spec to clarify.

[pvillela]

SHC CRL Brute Force Attack Scenarios

Following are some brute force attack scenarios against the two legacy revocation methods. Some assumptions are made and a rough summary assessment is presented for each scenario. Feedback is much appreciated.

Assumptions

• Attacker has:

  • A dictionary of hypothetical person names, assumed to contain 10,000 entries or
  • A list of actual person names with their respective dates of birth, obtained from breaches of personal data against other sources; the list is assumed to contain 10,000 entries

• There are 4 approved vaccines in Canada

• There are 1,000 possible lot numbers for each approved vaccine in Canada

• The attacker has the lists of possible lot numbers

• The attacker will target people with ages between 21 and 70, resulting in approximately 50 * 365 possible dates of birth

• The CRL is stored by the attacker in an associative array (hash table) and access to it is fast

• When the hmac-patient revocation method is used, the discussion below assumes that the method is implemented without the shared secret between the issuer and verifiers. If there is a shared secret, a brute force attack is infeasible unless the attacker can obtain the shared secret.

1. Attack on hmac-patient CRL with list of known person names and DOBs

• Target -- hmac-patient CRL
• What the attacker knows -- A list of persons with their names and dates of birth
• What the attacker can gain -- Knowledge that specific persons have had an SHC revoked
• Computational effort -- Person_list_sizeSHA-256 computations
• Probability of success -- Proportional to number of known person name-DOB pairs and size of CRL
• Assessment summary
  • Effort: low
  • Probability of success: low
  • Gain: very low

2. Attack on hmac-patient CRL with dictionary of hypothetical person names

• Target -- hmac-patient CRL
• What the attacker knows -- Nothing
• What the attacker can gain -- Valid person names and their dates of birth
• Computational effort -- Name_dictionary_size * 50 * 365 SHA-256 computations
• Probability of success -- High
• Assessment summary
  • Effort: medium (200 million computations)
  • Probability of success: high
  • Gain: high

3. Attack on hash-fhir CRL with list of known person names and DOBs

• Target -- hash-fhir CRL
• What the attacker knows -- A list of persons with their names and dates of birth
• What the attacker can gain -- Valid person names and their dates of birth plus knowledge that those persons had an SHC revoked and what vaccinations those persons may have had
• Computational effort -- Person_list_size * 2 * 4 * 1000 * 2 * 365 SHA-256 computations, assuming 2 vaccinations and all vaccinations were administered over the past 2 years
• Probability of success -- Proportional to number of known person name-DOB pairs and size of CRL
• Assessment summary
  • Effort: high (60 billion computations); effort can be reduced by trying fewer combinations but then the probability of success will go down as well
  • Probability of success: medium
  • Gain: high

4. Attack on hash-fhir CRL with dictionary of hypothetical person names

• Target -- hash-fhir CRL
• What the attacker knows -- Nothing
• What the attacker can gain -- Valid person names and their dates of birth plus knowledge that those persons had an SHC revoked and what vaccinations those persons may have had
• Computational effort -- Name_dictionary_size * 50 * 365 * 2 * 4 * 1000 * 2 * 365 SHA-256 computations, assuming 2 vaccinations and all vaccinations were administered over the past 2 years
• Probability of success -- High, assuming the dictionary of hypothetical person names has high coverage of actual person names
• Assessment summary
  • Effort: prohibitive (1 quadrillion computations); effort can be reduced by trying fewer combinations but then the probability of success will go down as well
  • Probability of success: high
  • Gain: high

[christianpaquin]

Thanks for this analysis. Some things to consider for the threat analysis: capabilities of an attacker really influences the effort (e.g., access to a bitcoin mining rig, which can perform maaaaaaany hashes/sec). Sensational journalist could target their attacks to celebrities/politicians with known DoB, to see if one tried to get a fake-and-then-revoked SHC; I think that'd fall in your 1st scenario, and I'd say in this case the gain is more than "low". For fhir-hash based method, you might not learn actual immunization details since this data might be fake (hence the revocation), but you'd learn the fact that this person tried to obtain a SHC fraudulently.

[pvillela]

Good points, Christian.

[alex-akinox]

A key point for the risk assessment is that the revocation lists contain information that might have been issued by mistake, might have been valid but leaked, or might have been obtained fraudulently. There is thus some level of plausible deniability, lessening the value for an attacker since there is no way through that list to invariably infer that the person obtained an SHC fraudulently.

[christianpaquin]

When the hmac-patient revocation method is used, there is no shared secret between the issuer and verifiers.

I think you mean hash-fhir

[pvillela]

Sorry, I meant to say that the analysis was for the degenerate case where the shared secret is omitted. Some provinces want to use that method but find the shared secret to be a an impediment. I wanted to get a feel for the privacy risk exposure associated with omitting the shared secret in the implementation of the method. I updated the text to clarify.

[christianpaquin]

I see. Yes, the impediment is by design. If an issuer wants to use an empty hmac key, then the impediment is still there because verifiers not aware of this fact wouldn't know how to check the revocation status of a given SCH (in other words, only verifiers in-the-loop could process CRLs from these issuers, and they might as well share a back-channeled hmac key at that point for extra security). A new hash-patient method could be created, but would need to be debated, and overcome the privacy objections to be ratified as part of the core spec.

My goal would be to agree on the go-forward revocation method (defining CRL formats, etc.), and then bring the legacy methods into focus, to see if the two proposed ones are enough/ok, or if they need change or alternates.

[pvillela]

Your phased approach makes sense and is in line with recent discussions I've been part of in Canada. Getting the forward-looking v1.2 approach finalized quickly would be a very beneficial first step.

[pvillela]

By the way, @christianpaquin, i think there is a typo in your description of the hmac-patient method. Where you say "minified FHIR bundle", I think you meant "minified FHIR patient resource".

[christianpaquin]

Your phased approach makes sense and is in line with recent discussions I've been part of in Canada. Getting the forward-looking v1.2 approach finalized quickly would be a very beneficial first step.

We haven't heard serious objections on the main scheme, so I think we can push forward after the thanksgiving weekend (sorry in advance if I'm silent for the next few days :))

[christianpaquin]

Moving this proposal as a spec RFC; see PR #215.