Papers

ReBOOTING THE WEB OF TRUST [pesions e Furune or Decenaaizeo S soveneion foewrry | Alice Attempts to Abuse a 'A. Verifiable Credential "‘ "« by P. Dingle, S. Hammann, D. Hardman, C. ‘\’» Winczewski, and S. Smith < RworXwesseowsoneoo: ]

INTRODUCTION Veifiuble credentinls (VCs) are an excitng innovation in decentralized identity. By standardizing a data format that allows the holder of a credential to be in control of the receipt and the presentation of digital docunets, Vs ropresont. a step forward in data control while il llowing authoritative information to flow. Howover there are reasonable concerns aronnd whether the remote interactions that VCs enabls can be secured. A verifisble credential is easy to copy. The cryptographic keys that protect them are easy to share, This makes an old problem from physical redential space more pressing: What mechanisms crist for the system to prevent frauds In this paper, e explore a subset of the frand problem: vulnerabilites associated with a malicions credential holder, Orur frame s a fctional nerrative abont Alice, a person who receives a prescription as a verifiable credontial. Unfortunately, Alice s addictod to the prosoribed drug, she is eager to carn quick cash, and she has litle respect for legal processes—so she s multiple motives to apply her credential and creativity for mischicf. ASSUMPTIONS We do not want to treat real-world drug addiction casally, and e also do nof want prescription experts to get bogged dovn in whether details of toduy's preseription systems make u particulur ubuse lss believable. Therefore, we add further layer of fietionalty: the drug that Alic is addicted 10 is melane (the fictionsl spice that drives a galactic coonomny in the sci-f universe of Dune), and this takes place some time in the furue. Tn Alioe's world, verifinble credentials are common, software that supports them is reasonably matire, and laws and procedures sy vary bit from what we know nos. Issues prescription ) Presents prescription Alice et H Doctor Bob H H e | Pharmacy R Us T i T fersy | ! oyt | T tcencea | fRewcstion H | Inevocation | poctor checc v Distrbuted Ledger M4 ' i Trust Framework v Hiustration 1 VC ecosystem 191119 Aleo Attempts to Abuse a VC 1.0 2

For simplicity it is assumed that the system consists of three categorios of participants: issuers, holders, and verifiers. Issuers and verifiers are assmed to be honest and acting in good faith—the doctor is licensed to practice and the pharmacy is licensed to distribute melange. Only the holder (Alice) is ucting maliciously. ALICE TRIES HER LUCK Alice Tampers with the Credential T start our scenario, Alice receives a valid prescription for melange from her doctor’s office, in the form of & verifisble eredential. However, she is not happy with the dosae. She decides 1o Lamper vith the credential and increase the amount of melango that she can buy. She changos the dosage text. value within the credential from 250mg to 500mg and presents the modified credential to the pharmacy. raditionally Signed Credential If Alice holds a traditionally signed credential, then when she presents it to the pharmacy, the pharmacy verifies its signature as follows

1. Locally compute the hash of the credential as specified in the crodential schema. (o.g. SHA256)

2. Resolve the doctor’s (issmer’s) Decentralized Identifier (DID) and retrieve the public key

3. Caleulate the local signature from the local hash and the public key

4. Compare the local signature to the credential signature At this point the verification fails becanse the local hash calculatod in Step 1 is different from the hash calculated when the credential was issued due to Alice’s tampering. Thus, the signature comparison does not match, and Alice’s tampered credential is rejected. Zero Knoviedae Proof (ZKP)-enabled Gredential If Alice holds a ZKP-enabled credential, then the pharmacy expects a proof that Alice is bound as holder to a eredential with & signature by the prover over the unmodified credential's content. Since Alice changed the proof’s content, the signatnre no longer matches tho content, and her deviee is unable to produce a. valid proof. The invalid proof is rejected by the pharmacy. Alternatively, Alice could try to construct & proof that her credential contains 500 mg in the dosage field rather than 250 me. However, since this is not the sctual content of her credential, her device is once again unable to produce a valid proof [1] Alice Forges a New Prescription from a Non-cxistcnt Doctor Next, Alice tries to forge a new prescription credential for melange. Howover, she alroady knoss that, the pharmacy performs signature verification, so having a credential with an invalid or missing signatur

e would not work. This is not stopping Alice, though. She hus recently taken a course about DIDs und verifisble credentials, 20191119 Alice Attempis to Abuse a VC 10 3

and even knows that the pharmacy is looking up the doctor's public key on a public blockehain. Thus, she invents a doctor’s office with its own DID and key-pair, and registers that DID on the blockchain. She then issues herself & new prescription eredential, using the made-up doctor’s DID s the issuer. Since this credential as a valid signature, will her mischief succced?

No matter which type of eredential Alico is holding, when she presents this credential to the pharmacy, the pharmacy resolves the issuer's DID and successfully verifies the signature. This foils Alice’s evil plans once again, for the pharmacy’s verification process fails with the error “Credential is not issied by cartificd doctor's office.” Verification relies on a trust framevwork|2]—a published behavioral agreement adopted by mutual consent of all stalseholders. In our setting, we assume that there exists u trust framework governing the issuance of health care related eredentials such as prescriptions. Tn partieular, the trust framework specifies which issuers are authorized to issne preseription credentials. Alice’s made-np doctors office docs not belong to this list of issuers, so her forged credential s rejected.

Alice Tries to Use Prescription after Expiration

Alico remembers that she has an old prescription which she never filled last year. Knowing from her first attempt that modifying a credential fuils, she does ot try to change the date and simply hopes the date is mot checked. She submits this preseription Lo the pharmacy.

radstionaly Signed Credential

For the pharmacy, this is simple enough to detect. While the credential has a corree. signature from a cortified doctor, the pharmacy also checks the expiration datc against today's date, and rejocts the expired credential. Alice is again out of luck.

ZKP-cnabiad Credemtial

A ZKP-enablod credential conld disclose the expiration date, in which case the logic doseribed for traditionally- signed credentials applies as described in the preceding paragraph. Alternatively, the pharmacy conld challenge Alice to prove that the expiration date for her prescription lies in the future, Since Alice’s old credential expiration date has passed, her device is unable to produce such a proof.

Alice Tries to Sell Her Prescription

Alice searches the dark web, looking for buyers of her prescription credential. She imagines there will be high demand; surely there are addicts who are willing to pay lot to fill & melange prescription while p

retending to be her.

But Alice Tias nuch Tess success than she expected. Tt turns out, that her credential is mostly worthless on the black market, for one or more of the following reasons:

20191119 Alice Attompis to Abuse a VC 10 1

Traditionaly Signed Credential

• The credential is bound to a DID, and credential holdors are roquired to disclose the same DID every time they fll a prescription. The verifier can check to see if a person purporting to be Alice is using the same DID with this prescription s they used last week with a different prescription and can reject the eredential if there is a mismatch,

Fither Credential Type

• ‘The issuer (doctor’s office) s embedded in the prescription credential » biometric (¢.2., a photo, voieeprint, fingerprint, hand geometry, o iris scan) that bind it exclusively to Alice. Pharmacies are required to check this biometric to confirm that the person filling a proseription s the same person fo whoni it was issued. (Traditionally, capturing biometrics from a remote device, not under the control of the verifier, has hoen problematic. However, a now wave of solutions from academics[3] and industry gronps like the FIDO Aliance is now making this more practical )

ZKP-enabiad Credetial

= The link secret is protected by a link secrct band. This means Alice cannot sall her link seeret, (necessary o use the prescription) to anyone on the dark web, or else the dishonest people who learn the secret could also confiscate her bond in o way that's publicly observable. In this setting, pharmacies would be required to check the integrity of her bond and only accept a credential for which the link secret liss not been compromised

• Credential holders are required to use the same link socret cach time they fill a prescription. The verifier an check for link secret, continuity, without knowing the link secret itself. This prevents credential bransfers,

« Prescription credential holders are required to commit a DID to a link secret. In Alice's society, when someone becomes an adult and is legally able to Bl prescriptions for themselves, they must uppear in person at a pharmacy and prove their identity with a strong, link-secret-based 1D, such as a. driver's liconse. A fragment.of this proof is kept on file for cach person. Later, when a person fill a proscription, they must demonsrate to the verifir (the pharmacy) that the link secret embedded in the current prescription is the same us the link secret used in the proof on file for the named person, and that it is also equal to the link secret in & randomly chosen credential that the pharmacy challenges then to prove they possess (a driver's license, a credit card, a passport, cic). Since the fraudster can't pr

edict in advance which credential they will need, even if Alice sells her link scret, she can't just sell one credential on the black market—she must sell many of them or none. (A similar technique might be used for non-ZKP credentials, except. that the linking would be DID-based and DID-disclosing, instead of link secret based and scrot-hiding.)

20191119 Alice Attempis to Abuse a VC 10 5

Alice Tries to Rent Her Prescription

Finding that selling the prescription s impractical, Alice tries a different tack. She offers to participate in o remote proving interaction with a pharmacy, ou demand, for a fee. Busically, she's offering to do legitimate proving on someone else's hehalf Tf successful, this transfers the benefits of the credential to another person, even thongh Alice remains the holder and prover.

However, the verificr defeats this by requiring a single, coherent, richly contextualized presentation. This has the effect of guaranteeing that the person who proves proper possession of the prescription (Alice) is also the person whose shipping address and eredit card are used to pay for and ship,receive the drugs; Alice can't redirect the payment or the drugs.

Alice Tries a Visual Hack

Alico notices that when sho fills her prescription at the pharmacy, her phone shows a big green checkmark. She wonders if maybe a groen checkmark alone could result in distribution of additional melange. She takes & sereenshot of her app showing the success sereen and shows it to the pharmacy agent.

“Dhis doesn't work, The phurmacy has trained all of ts employees t only believe data when confirmed by its own systoms. Thus, what Alice's phone says is irrelovant; the eredential must be embodied n a digital verifiable erdential presentation that's transmitted to the pharmacy's systems and evaluated there.

Alice Double Sponds Her Prescription

Alice wonders whether she could fulfl her prescription more frequently than the doctor intends. She walks to several pharmacics and prosents her verifiable credential in each place.

Alice is stymied by the rules established by the trust framework mentioned earlier. One of the issues the trust Tramework plans for is attenpts to fill a given prescription more than once.

One way the trust rameswork can make prescriptions one-time use only is by requiring pharmacies to publish information about filled preseriptions (perhaps just a unique prescription ID) to a common databsse. Another option is to require pharmacies to revoke (or to ask isers to revoke) prescriptions the moment they are nsed. Alico Trios to Hack the Pharmacy

Alice tries to loverage the verifiable eredential to gain unauthorized access to pharmacy resources. She knows that, ‘many pharmacics don't take basic secnrity precautions seriously and so rescarches how she could alter the sclf- asserted parts of the verifiable credential in a way that could compr

omise the system. There are many types of hacks, but Alice decides to work on the one item ou the infamous OWASP T st that can be influenced us an ond user.

20191119 Alice Attempis to Abuse a VC 10 6

Alico changes her name in the doctor’s system to Alice’); DROP TABLZ PRESCRISTIONS;, hoping to canse the pharmacy to forget whether her preseription was already issued. Unfortunately for Alice, the pharmacy has implemented robust imput validation and is sanitizing all data received from within a verifisble credentisl. Characters that could be interpreted as escape characters by the system are rendered harmless either by detecting and removing the characters or by converting them to text equivalonts. Penctration tests have been performed to ensure that; various kinds of injoction are blocked. Alice Tries to Prevent Connectivity to the Pharmacy Alico wonders whether any of her attacks wonld work beter if the pharmacy were temporarily offfine and unable to do aggressive verification. She walks to the pharmacy, finds the intcrnet, cable running into the building, and cuts it, For some amount of time, the pharmacy is unable to perform simple operations like resolving DIDs against a ledger But the pharmacy is more prepared for this than Alice expected. It regularly caches all soris of data, including: radstionally Signed Credentials

= The DIDs and verkeys of each holder.

• Auy relevant revocation lists Both Credential Types

• The DIDs and public keys for doctors who are authorized by the trust framework to write prescriptions ZKP-enabled Credentials

• Statc information for pairwise DIDs (In ZKP ocosystems, holders don't intcract on preseriptions via a

public DID; instead, they use pairwise DIDs. Pharmacies will have the associated DID docs.)

• The relevant revoeation merkle tree rools or eryplographic accumulators, When Alice presents her credential in any of the fraudulent ways that were previously discussed, the pharmacy is able to operate off its cached data according to a stalencss policy that the pharmacy carcfully dosigned. Porhaps they conclude that since public DIDs of issuers are relatively stable, they can have a staleness of up to 24 hours, whereas revocation data needs to be current within the previous hou. 20191119 Alice Attompis to Abuse a VC 10 7

Alice Gets Caught Causing Mischief, Gets Prescription Revoked Enough is enough, and after Alice’s r m lutest exploits, ber doctor’s office decides to revoke her credential el Nevartheless, she stil tries to uso Y, =N her credential to at least salvage 3 the dose of melunge that was 2 » actually issued to her. A - k. The pharmacy successfully verifes N the signature against the correct b o doctor's offce, but, us mandated by 20 . . the trust framework, in another T K "‘ . St i hocks revocaton lis o [ 3 registry available on the public 4 AN blockeliain, The pharmacy finds wn antry with the TD of Alice’s credential, and thus, again, reoets the credential Photo by amencliviespholos ac. Plickr, CC SA 2.0 BEST PRACTICES FOR VERIFIERS In this sction, we zoom ot from Alice's story and more generally describe best practioes that verifers shonld follow to protect against credential fraud from malicious credential holders. We present the points ronghly in the order in shich they apply during credential verifcation. + The verifer should not allow others to detesmine (parts of) the verification process.

• Verification doe by the holder does ot provide uny guarantees; the Lolder could use dishonest software that makes it ook like verification was secesshl.

• The verifier must be explicit abont acceptable fssers and acceptable credential schemas and must confirm that the evidence in a presenation matches those requirements. A schema that encodes daes with month first must not be confuscd with a schema that cncades dates with day-ofmonth first when testing expiration, for example

• Using a third purty verifier leaves the verifir vulerable to snyone who could collude with that verifier, or to vulnerabilitics or bugs in that verifer

• The verifier should treat data provided by a credential holder as untrusted fnput and perform proper imput validation sather than assume corvect credential format

• This is a standard secure coding practice: Any input from untrusted sources must be properly validated 10 prevent, e, code njection o buffe overflow atacks

Mm-11-19 Alioe Attempts to Abuse a VC 1.0 8

• The code specific to verifiable credential verification should only be excented after successfil input validation,

• The verifier must always perform signature verification with respect to the issuer’s public key, or properly varify a prosented zero-knowledgo proof.

• In particular, omitting this check should never be an acceptable fallback to keep business running, c.z in case of comnectivity outage, The potential cost incurred by credential fraud is potentially much higher than that ineurred by & brief interruption of business activities,

• While caching the issuce’s public key for a short time may be acceptable, as a best practice this cacho time shonld be short to prevent signature verification against an outdated public key (e.g, the issuer may have rotated the key because the old key was compromised).

« The verifier must ensure that the issuer s authorized 1o issue this type of eredential with respect 10 the nderlying teust. framework * A trust framework must be in place with clearly defined rules about which issuers can validly issne

wehich types of eredentials, and these rules must be enforced by the verifier.

« The verifier must have a clearly defined set of acceptance criteria for credentials. This includes, but is not limited to, establishing that the credential belongs to the subject the holder claims it belongs to {often the holder themselves)

• Some methods to bind a verifiable credential to a subject were ontlined in the “Alice trics to sl rent her credentials”. Note that this is a complex matter that cannot be fully addressed in one bullet point of this paper.

• 1 there are checks that must be performed manually, such as comparing a photograph (o a person’s face, procise guidelines must be in place to be followed by employecs.

• We described a special type of credential that may only be presented once; other credential types may require different domain-specific checks. The trust Iramework must elearly define the additional checks a verifior must. perform.

“ The verifier must check that the credential has not expired and has not. been revoked.

• Revocation checks involve a revocation registry (e.5., the sume ledger where the issuer’s public key is stored). Thus, the same best. practices (¢.., short caching times) should be applied as for looking up the private key.

This lst of best practices is not exhaustive. More general-purpose recommendations are indonbtedly appropriate, and specific best practices may be important in part

icular industries or particular proving contexts. SURVIVABILITY

Most of our discussion has taken a traditional cybersecurity mindset, emphasizing vulnerabilities and theix conntermeasnres. However, military planners take an altcrnative perspeetive grounded in the discipline of mission. survivability. Tn this approach, the question is not "How can we prevent attacks?" — rather, it is "how can we ‘accomplish our mission in the face of active opposition?" [4] In our Alice-pharmacy scenario, the pharmucy's mission is to Bl preseriptions according to law/regulation, to an acceptable level of assurance —and this suggests 20191119 Alice Attompis to Abuse a VC 10 9

that we ponder threc interdependent factors that influcneo the ontcom:

« Suscoptibility (likelihood of attack)

• Vuerability (likelinood of damage, given an attack)

• Recoverability (ease and completeness of recovery, given damse) Most countermeasures listed above address vuluersbilty, but there are exceptions. The biometric and linked scerat. bond mechanisms do ot dircetly impede a oredential salo (docrease vulnerability); instead, they make it nlikely (ess suseeptible) by undermining incentives. Stuch techniques can have profound application to credentialing scenarios. As a case in point, consider the online. voting system in Estonia that allows each citizen to vote as many times us they like, but counts only the lust vote. (5] This undermines any incentive for buying votes, since a eitizen who sells their vote can just vote again afterward, cancelling th cffect of the fraud and altering susccptibility. Similarly, recoverabiliy is worth pondering. Tf eredential fraud is quickly and automatically detected, undone, and prmished, some proving secnarios may decide that protections are adequate, even if the initial frand is relativaly easy. Tn our offline verification scenario, for example, it may be better 10 relax the freshuess guarantees on signatures slightly, in the intorest of disponsing lifo-giving medicines quickly—but the timing and antomated nature of recovery wonld have to be weighed with care, Trust frameworks exist to make sure such tradeoffs have been carefully evaluated and publicly documented. W intuit that & matire and safe ceosystem for verifishlo crodentials will include thoughtful decisions on all threo of these dimensions, not just on vulnerability. SUMMARY Stepping back, we can see that Alice has not been successful in her attempts to modiy or profit from her prescription credential, At each step, her atterpts to tamper with the eredential or use it in ways outside of the intended scope were detected, remediated, andfor undone. The pharmacy, acting as & verifier, has ensured intogity within the systom and significantly mitigated risks by following bast, practices. Tt is worth noting that while this paper attempts to identify many possible attack voctors initiating fom the perspective of the holder, this is by no means an exhaustive list for either present or future attacks. The appropriate standards for accuracy and completeness of verification eriticalily vary according to use case. The authors suggest that any implementer of verific

ation and consulting this paper should also perform a thorough threat analysis that framed by their spocific noeds. 20191119 Alice Attempis to Abuse a VC 10 10

NOTES

1. Seethis explanation o er-knowledae proofs in yperedaer Ursa.

2. For a general explration of trust framesorks, see *Trust Fromewarks: ThirCetical Role in Governing denthySystems and Allocating

Liabilty". Two very extensive examples ae the Sovrin Governance Framework and the Pon-Conodian Trust Framework. A much simpler

example s found in ries REC 0103.

3.See “private Eyes: Secure Remote Biometrc Authentication" and "Remote Bometric Authenticaton 5stem using Android Phone.

4.See *Anthropomorvhized risks for digital assets”.

5.See "What the U, Can Leam About Electronic Voting From This Tiny Eastern European Nation'.

Additional Credits:

Lead Author: S. Hammann 4‘}

Authors: P. Dingle, 8., Hammann, D, Hardman, C. Winczewski, and S. Swmith ’-.‘ -4

Sl A st "

Dingle, P., Hammann, §., Hardman, D., Winczewsld, C., and Smith, § (2019). Alice

Attempts to Abuse o Verifiable Credential. Rebooting the Web of Trust IX. Retrieved from

hitps:/ github,com / WehOFTrustinfo ot prague/blob /master final.documents /alice-attempts-abuse-verifiablo.

credential pdt

This paper is liconsed under CC-BY-40.

About Rebooting the Web of Trust

This paper was produced as port of the Rebooling the Web of Trust IX design workshop. On September 7* Lo 6%,

2019, over 60 tech visionarics came together in Prague, The Czech Repubic to talk about the future of

decentralized trust on the internct with the goal of writing at least § white popers and specs. This is one of them.

RWOT Board of Directars: Christopher Allen, Joo Andrieu, Kim Hamilton Duffy

Members of the Organizing Commitiee: Dan Burnel, Dmitri Zagidulin

Sponsors: Digital Contract Design (Gold), Protocol Labs (Silver), Digital Bazaar (Ongoing Sustaining), Jolocom

Gommunity Sponsors: Blockehein Commons, Consensys, Learuing Machine, Legendary Requirements

Workshop Credits: Christopher Allen (Founder, Co-Producer), Joo Andrien (Co-Prodncer and Facilitator), and Shannon Appelcline (Editor-in-chief).

Thanks to our other contributors and sponsors!

20191119 Alice Attempis to Abuse a VC 10 n

Thanks also to Paralelnd Polis and the Institute for CryptoAnarchy in Prague. ‘What's Next? The dosign workshop and this paper are just starting points for Rebooting the Web of Trust. If you have any comments, thoughts, or expansions on this paper, please post them to our Gitkub issues page: bttps:/ /sithub,com/ WebOfLrustlnfo/ rwotd issues The tenth Rebooting the Web of Trust design workshop is scheduled for early 2020. If you'd like to be involved or would like to help sponsor the event, email rwotleadership@googlegroups.com 20191119 Alice Attompts to Abuse a VC 1.0 2