Talk given at DEFCON 31 at the Crypto & Privacy Village on Attacking Decentralized Identity.

1. Attacking Decentralized
Identity
Gabe Cohen, TBD / Block
Brent Zundel, Gen
Crypto & Privacy Village, DEFCON 31
August 11, 2023

2. What is
Decentralized
Identity,
anyway?
2

3. The Evolution of Digital Identity
Identity Model Centralized Federated Decentralized
Technology
● ID/Password
● Multi-factor Auth
● SSO
● OAuth
● OpenID
● SAML
● Secure Personal
Storage
● SIOP, Web5
● Cryptographically
driven auth
Characteristics
● Identity fragmented
across many service
providers
● Corps have full control
of user data
● Centralized data
providers at risk for
attack
● Rely on a single/set of
centralized identity
providers
● Identity information
fragmented between IdPs
● Centralized data
providers at risk for
attack
● Identity portable across
ecosystems
● User controlled data
on-device or
user-controlled cloud
● Users are in control of
their data

4. 4
SSI Principles
● Existence – Users must have an independent existence
● Control – Users must control their identities
● Access – Users must have access to their own data
● Transparency – Systems and algorithms must be transparent
● Persistence – Identities must be long lived
● Portability – Information and services about identity must be
transportable
● Interoperability – Identities should be as widely usable as
possible
● Consent – Users must agree to the use of their identity
● Minimalization – Disclosure of claims must be minimized
● Protection – The rights of users must be protected

5. Why Decentralize?
5

6. 6
SSI
Standards
Landscape

7. W3C Verifiable Credentials
(VCs)
A Verifiable Credential is a W3C standard
mechanism of expressing claims about an
individual on the Web in a way that is
cryptographically secure, privacy respecting,
and machine-verifiable.
A VC is inherently independently verifiable –
which means a verifier will never need to go
back to the issuer to conduct or complete
verification.
7
Claims can include, but aren’t limited to, the same
claims in traditional credentials such as health cards,
passports, university degrees, or business licenses.

8. Holder
The entity controlling a VC. This entity is
usually the subject of the VC, though not always.
There are scenarios where the entity may have been
issued a VC, but is not the subject of the VC.
8
Issuer
The issuing entity of a VC. This entity asserts claims
about the subject of the VC and issues it to a Holder.
Verifier
The entity to which a VC is presented to as proof
of a claim or set of claims. This entity might
request a VC, and then verify that the VC satisfies
their requirements.
Actors in Decentralized
Identity Systems

9. W3C Decentralized Identifiers
(DIDs)
A Decentralized Identifier W3C standard for a
type of user- or business-controlled
identifier that enables verifiable,
decentralized digital identity on the Web.
DIDs are URIs that associate a DID subject
with a DID document allowing trustable
interactions with that subject. DID documents
contain public keys and other data.
9
A DID can refer to any subject, including a
person, organization, thing, data model, abstract
entity, etc.

10. 10
An Ecosystem of
Decentralized Interactions

11. Cool cool.
Who’s using
this stuff?
11

12. Decentralized Identity:
In the Numbers
60+
Public & private companies
building in the space
40+
Countries using some form of
Decentralized Identity
12
3B+
Verifiable Credentials
Issued

13. 13
Decentralized Identity:
In the Logos

14. 75%+ of the world
will be using
decentralized
identity tech
within the next 5
years
14

15. “
“Decentralized identity is important for confirming user identities
and securely storing them. It offers numerous advantages separate
of the greater identity autonomy it delivers to customers.”1
“…passkeys do not protect our privacy or give us complete control of
our online identities. For that to happen, we need to look at
self-sovereign identity (SSI).”3
“Individuals can own and manage their own tamper-proof credentials
for applications such as personal health, education, and voting
records in an encrypted digital wallet on their personal devices.”2

16. Attack Surface
16
Service Providers Networks User Agents Individual Entities
Companies like
Microsoft, Ping
Identity, Okta, MATTR,
Trinsic, and more.
Their service offering
= your opportunity!
EBSI, Velocity,
Sovrin, Indicio,
Cheqd, and others.
Networks are forming
to standardize,
monetize, and
facilitate identity
Your phone, your
computer, your
applications.
You thought being your
own bank was hard, how
about being your own
IdP?
You, your mom, your
dog, your employer,
your trustworthy local
politician.
In a world of
decentralized trust,
each entity is an
entrypoint for
exploit.

17. That
vulnerability
is just my
type!
17

18. 18
Vuln #1:
Gimme That
Data!
●
In a world with verifiable data, any data can be
requested by anyone at any time…
○ Why is this data being requested? Is there
other less sensitive data that would
suffice?
○ Is the requester who they claim to be? How
do you know?
○ Is the requester the right entity to
receive and handle this data?
○ What can be done with this data in other
contexts? What’s protecting the data from
unauthorized usage?

19. Attack #1: Abuse of Trust
19
Alice goes to the store…
1. Store requests proof that Alice is
over 18
2. Alice scans a QR code with her digital
identity app
3. Alice selects which credential matches
the request
4. Alice has an option to submit

20. Attack #2: Confused Trust
Alice goes to open a bank account…
1. Alice navigates to a bank’s website
and clicks “sign up”
2. Alice is asked for a few pieces of
information
a. Government issued ID
b. Proof of employment
c. Proof of funds to open the
account
The website appears legitimate, and her
app thinks so too, does Alice send over
the data?
20

21. 21
Vuln #2:
You thought
distributed
systems
were hard…
●
In a distributed systems, usually…
● You’re aware of all nodes in the system
● Consistency ensures that all nodes in the system
have the same up-to-date view of data
In a decentralized system…
● There is no one method of decentralized
consistency
○ Strongly consistent (BTC)
○ Eventually consistent (IPNS)
● Even with consistency, you may not always know
if you have the latest state

22. Attack #3: Data (Un)availability
Bob goes to verify a credential
22

23. did:jwk
(+) Self-resolving key that
always has the latest state
(-) No updates
(-) No way to signal
compromise
did:web
(+) Domain based method
(+) Supports updates
(-) Relies on TLS certs
(-) Relies on DNS / domain
registrars
(-) No historical state
resolution
23
did:ion
(+) Supports any DLT and
Content-Addressable Storage
(+) Permissionless + full
featured (update, recovery,
deactivation)
(-) Complex architecture
(-) Uncertain if you have
the latest state / pinning
risk
Attack #4: DIDn’t I tell you?

24. Vuln #3:
You want
to do WHAT
with your
data?

25. Attack #5: Heated Seat
Subscriptions
25
What You See What They See

26. Attack #6: Oops I centralized
again
Areas for Centralization
● DIDs
● Data storage / replication
● Verification of credentials
○ Status checks
○ Schema checks
● Wallets/agents
● Permissioned networks
● Payment networks
● SSI Suites (issuance/verification
services)
● Everywhere!
26

27. 27
Vuln
#4,5,6:
Oh yeah,
those too…

28. Attack #7: The Semantic Web
Strikes Back
28

29. Attack #8: (Don’t) Roll Your Own
Crypto
29

30. Attack #9: Is AI going to
destroy decentralized trust?
30

31. Attack #10: Why are you hitting
yourself?
31

32. OK, now what?
32

33. Mitigation #1: Smart Agents
Digital Bodyguards = Freedom
Centralize When Necessary
● Trust needs to start somewhere
● Trusted issuers/verifiers →
centralized trust registries
○ What are they trusted for?
○ What have their last x
interactions been like?
○ Are there transparent reviews?
● Trusted vendors
○ Agents/wallets
○ Personal data stores
Take Privacy-First Stances
● Are you disclosing as little as
possible?
● What rights do you enforce after you
share?
33

34. Mitigation #2: More than a
green checkmark
Establish Trust; Minimize Disclosure
● Alice’s smart agent has a built-in Trust
Registry, and can now verify that requests
are legitimate
● Alice’s smart agent is able to advocate for
a privacy-preserving presentation mechanism,
selective disclosure
● ZKPs are coming!
● Make sure to authenticate, always
Is this enough?
34

35. Mitigation #3: Start From
First Principles
Decentralize where it matters most
● DID Method → If your DID method
isn’t decentralized and feature
rich, you’ve boxed yourself in
● DIDs → Use a mix of
public/long-lived and
private/ephemeral DIDs
● Providers → Make sure your data
isn’t locked to a single provider;
beware of single vendor solutions
Assert your rights
● Is it clear what you’re signing?
● What could go wrong?
● What are you giving up?
● Is there another path? 35

36. More Mitigations
● Build flexible, privacy-promoting standards
+ software
● User-defined terms of service/use to
enforce fair data usage
● Decentralized trust scoring mechanisms
(verified Google Reviews/Yelp)
● Use of open source software
● Use of open networks and ecosystems–say no
to walled gardens!
● More interactive protocols that enable user
negotiation & optionality
36
I
m
p
l
e
m
e
n
t
e
r
s
Individuals
O
r
g
a
n
i
z
a
t
i
o
n
s

37. Embracing
Decentralization For
Dummies
37

38. Choose Your Own Adventure
38
User
Control
Centralization Risk
(decreasing)
UX
(worsening)
Nerd Tools
Grandma
Tools
Land of Opportunity

39. Not Your Keys, Not Your Coins
→
Not Your DID, Not Your Data
39

40. Remember where we’re headed
40

41. Gabe Cohen : @decentralgabe : gabe@tbd.email
https://tbd.website
Brent Zundel : @brent_zundel : brent.zundel@gendigital.com
https://www.gendigital.com
Standards Links
● VCs w3.org/TR/vc-data-model/
● DIDs w3.org/TR/did-core/
● DID JWK github.com/quartzjer/did-jwk/
● DID Web w3c-ccg.github.io/did-method-web/
● Sidetree
identity.foundation/sidetree/spec/
● Presentation Exchange
identity.foundation/presentation-exchange/
● Trust Establishment
identity.foundation/trust-establishment/
● SD-JWT
datatracker.ietf.org/doc/draft-terbu-sd-jw
t-vc/02/
● JWP datatracker.ietf.org/wg/jwp/about/
● BBS
datatracker.ietf.org/doc/draft-irtf-cfrg-b
bs-signatures/
Get Involved
● DIF identity.foundation
● W3C VCWG w3.org/groups/wg/vc/
● W3C DIDWG w3.org/groups/wg/did/
● DIF Discord discord.gg/ZHxa4FQubB
● TBD Discord discord.gg/tbd
● Gen Twitter twitter.com/GenDigitalInc
● TBD Twitter twitter.com/TBD54566975
Slides: tinyurl.com/defcon31attackingdid

42. Attacking Decentralized
Identity

43. ● What is Decentralized Identity anyway?
● That vulnerability is just my type
● Showing some real vulnerability
● Is nothing safe?
● Deployments
● Fin

44. What is Decentralized Identity Anyway?
● SSI Principles
● Verifiable Credentials
● Decentralized Identifiers
● Why would I even want that?
●

45. That vulnerability is just my type
● Private key compromise
● Validity vs verifiability
● Fake News!
● Blockchain problems
● Key management is hard
● Lack of Review

46. Showing some real vulnerability
● Some examples of attacks in the real world
● Ledger data breach
● How attackers might exploit vulnerabilities in decentralized identity systems
● The potential consequences of successful attacks
● Examples of real-world attacks on DIDs and verifiable credentials

47. Is nothing safe?
● Cryptographic techniques and key management practices to strengthen
security
● Best practices for designing and implementing decentralized identity systems
● Examples of successful mitigation strategies

48. Deployments
● Existing open-source software
● Standards bodies, active work, specifications, and participants

49. Fin
● The importance of addressing vulnerabilities in decentralized identity systems
● The potential impact of successful attacks on individuals and organizations
● The need for continued research and development to improve security and
resilience in decentralized identity systems