From 1c72ec805358cf52a50d9ccff9271187b9886eb0 Mon Sep 17 00:00:00 2001 From: Simone Onofri Date: Wed, 4 Sep 2024 11:06:55 +0200 Subject: [PATCH] Update index.html --- index.html | 104 +++++++++++++++++++++++++++-------------------------- 1 file changed, 54 insertions(+), 50 deletions(-) diff --git a/index.html b/index.html index 6e9e6a3..17fd7b0 100644 --- a/index.html +++ b/index.html @@ -173,7 +173,7 @@
-

Threat Modeling for Decentralized Identity @ W3C

+

Threat Modeling for Decentralized Identities @ W3C

September 6th, 2024

Simone Onofri
@@ -186,14 +186,14 @@

Threat Modeling for Decentralized Identity @ W3C

Who am I?

    -
  • W3C Security Lead since 2024 +
  • W3C Security Lead 安全标准领域负责人 since 2024
      -
    • Staff Contact for Web Application Security, Web Authentication, Federated Identity Working Groups, and Security Interest Group proposed
      • +
    • Staff Contact for Web Application Security, Web Authentication, Federated Identity Working Groups, and proposed Security Interest Group
    • Co-Chair of Threat Modeling Community Group
  • I was in W3C in 2006 for the Semantic Web Deployment Working Group
    • -
  • But in general, I am Security Geek since 2004 (and before)
    • +
  • But in general, I am Security Geek since 2004 (and before) for Red Teaming, Blue Teaming, Security Research, etc...
  • I care about a secure Web
@@ -213,35 +213,36 @@

World Wide Web Consortium 万维网联盟

What is Threat Modeling?

    -
  • Threat Modeling is a family of structured, repeatable processes that allow us to make rational decisions to secure applications, software, and systems (Shostack, 2014).
    • -
  • During Threat Modeling, we can identify potential threats, such as vulnerabilities or absence of controls, and prioritize the mitigations (OWASP).
    • -
  • It is a form of risk assessment that models aspects of the attack and defense sides (NIST SP 800-53 Rev. 5, NIST SP 800-154).
    • +
  • Threat Modeling is a family of structured, repeatable processes that allow us to make rational decisions to secure applications, software, and systems (Shostack, 2014).
    • +
  • During Threat Modeling, we can anticipate potential threats, such as vulnerabilities or absence of controls, and prioritize the mitigations (OWASP).
    • +
  • It is a form of risk assessment that models aspects of the attack and defense sides (NIST SP 800-53 Rev. 5, NIST SP 800-154).
-
+

Why Threat Modeling for Digital Credentials?

    -
  • At W3C, Threat Modeling analyzes standards and writes the security and privacy considerations sections.
    • -
  • When the standardization of the Digital Credentials API was proposed since it will mediate high-assurance and government-issued credentials, a more wide-ranging analysis was requested.
    • -
  • Therefore, we created the Threat Modeling Community Group to support standards developers in their work, starting from Digital Credentials in general and not only the API.
    • +
  • At W3C, we use Threat Modeling to analyze standards and write the security and privacy considerations sections.
    • +
  • When members proposed the standardization of the Digital Credentials API, members requested a comprehensive threats analysis because the API will mediate in the Browser high-assurance and government-issued credentials.
    • +
  • Therefore, we created the Threat Modeling Community Group open to all to discuss the various threats.
    • +
  • We started a generic 'meta' model, not only on the API, that can also be used as a starting point by any SDOs, Governments, and Implementers.

How are we doing Threat Modeling?

-

We are using the "Four Questions Framework":

+

We are using the "Four Questions Frame":

    -
  • What are we working on?
    (understanding architecture, actors, data flows, etc...)
    • +
  • What are we working on?
    (understanding scope, architecture, actors, data flows, etc...)
  • What can go wrong?
    (understanding threats, threat actors, attacks, etc...)
    • -
  • What are we going to do about it?
    (identify and prioritize countermeasures, residual risk, etc...)
    • +
  • What are we going to do about it?
    (Identifying and prioritizing countermeasures, residual risk, etc...)
  • Did we do a good job?
    (reiterating until we are happy with the result)

What are we working on?
Architecture

-

We started from the Verifiable Credentials Data Model (VCDM) to identify main Actors, Data Flows, and Data to protect.

+

We started from the Verifiable Credentials Data Model (VCDM) to identify main Actors, Data Flows, and Data to protect.

The roles and information flows of VCDM
@@ -250,8 +251,7 @@

What are we working on?
Architecture

What are we working on?
Actors and Data Flows

-

The Actors and the Data Flows:

-
    +
    • We have an Issuer, which issues the Verifiable Credential to the Holder and manages the status (e.g., revocation).
    • We have a Holder, who stores the Verifiable Credential in a Wallet, and send the Verifiable Presentation to a Verifier.
    • We have a Verifier, who verifies the Holder's Verifiable Presentations to give access to a resource or a service.
      • @@ -260,82 +260,86 @@

      What are we working on?
      Actors and Data Flows

-

What are we working on?
The actors exchanges

+

What are we working on?
Exchanged Data

  • Verifiable Credentials (created by the Issuer):
      -
    • Metadata: of the Credentials (e.g., reference to the issuer, the validity date)
      • -
    • Claim(s): one or more assertions where a characteristic of a subject is described (e.g., Alice is a citizen of a certain state).
      • -
    • Proof(s): cryptographic proof of the integrity of the credential, typically via a digital signature.
      • +
    • Metadata: of the Credentials (e.g., reference to the issuer, the validity date)
      • +
    • Claim(s): one or more assertions where a characteristic of a subject is described, in a specific format (e.g., Alice is a citizen of a certain state).
      • +
    • Proof(s): cryptographic proof of the integrity of the credential, typically via a digital signature.
  • Verifiable Presentations (created by the Holder):
    • Metadata: of the Presentation
      • -
    • Verifiable Credential(s): data stemming from multiple Verifiable Credentials can contain additional metadata in the form of additional claims.
      • -
    • Proof(s): cryptographic proof of the integrity of the credential, typically via a digital signature.
      • +
    • Verifiable Credential(s): data from multiple Verifiable Credentials in the form of additional claims.
      • +
    • Proof(s): cryptographic proof of the integrity of the credential, typically via a digital signature.
-

From a Threat Modeling perspective, we also need to consider Cryptographic elements (e.g., algorithms), Identifiers, Revocation methods, etc...

+

From a Threat Modeling perspective: we have cryptography, formats, serialization, canonicalization, identifiers, revocation methods, etc...

What are we working on?
Identifiers

    -
  • Talking about identifiers, we mainly refer to the Decentralized Identifiers (DIDs), an identifier technology based on cryptography that empowers us to control our data and consent to its usage.
    • +
  • Talking about identifiers, we mainly refer to the Decentralized Identifiers (DIDs), an identifier technology based on cryptography that empowers the user to control their data and and usage.
  • DIDs methods can rely on various technologies, including blockchains, the web, InterPlanetary File System (IPFS), and Domain Name System (DNS).
-

From a Threat Modeling perspective, each DID method needs it is own Threat Model

+

From a Threat Modeling perspective: each DID method needs it is own Threat Model (e.g., did:web may calls home, did:btcr may have correlation)

-

What can go wrong?
Threats/Attacks/Controls Frameworks

+

What can go wrong?
Mnemonic Threat Lists

+ One effective though inefficient approach to threat modeling is to cycle the various lists to understand how they may affect the model
    -
  • STRIDE: Spoofing, Tampering, Repudiation, Denial of service, Escalation of privileges
    • -
  • LINDDUN: Linking, Identifying, Non-Repudiation, Detecting, Data Disclosure, Unawareness & Inintervenability, Non-Compliance
    • -
  • RFC 3552: Replay Attacks, Message Insertion, Message Deletion, Message Modification, Man-In-The-Middle
    • -
  • RFC 6973: Correlation, Identification, Secondary Use, Disclosure, Exclusion
    • -
  • OSSTMM: Visibility, Access, Trust, Authentication, Indemnification, Resilience, Subjugation, Continuity, Non-Repudiation, Confidentiality, Privacy, Integrity, Alarm
    • +
  • STRIDE (Security Threats): Spoofing, Tampering, Repudiation, Denial of service, Escalation of privileges
    • +
  • LINDDUN (Privacy Threats): Linking, Identifying, Non-Repudiation, Detecting, Data Disclosure, Unawareness, Non-Compliance
+

Note: Repudiation is a Security Threat, and its negation Non-Repudiation, is a Privacy Threat.

-

What can go wrong?
Using LINNDUNN

+

What can go wrong?
Other lists

+
    +
  • Open Source Security Testing Methodology Manual (OSSTMM) (Controls): Authentication, Indemnification, Resilience, Subjugation, Continuity, Non-Repudiation, Confidentiality, Privacy, Integrity, Alarm
    • +
  • RFC 3552 (Security Attacks): Replay Attacks, Message Insertion, Message Deletion, Message Modification, Man-In-The-Middle
    • +
  • RFC 6973 (Privacy Threats): Correlation, Identification, Secondary Use, Disclosure, Exclusion
    • +
+
+
+

What can go wrong?
Using LINDDUN

-
Brainstorming in a Side Meeting @ IETF120
+
Brainstorming, using gamification, in a Side Meeting @ IETF120
-

What are we going to do about it?
Cryptography

+

What are we going to do about it?
Presentation and Verification

    -
  • Blinded Signature: is a type of digital signature for which the content of the message is concealed before it is signed. It is possible to send the cryptographic proof of the signature without providing the verifier with any other information about the signer.
    • -
  • Selective disclosure: is the ability to show only a part (a claim) of the credential and not the full one. For example, we can show only the date of birth rather than the entire driver's license where it is contained.
    • -
  • Predicate Proofs and Range Proof: is the ability to respond to a boolean assertion (true-false) to a specific request. For example, if we say we are of age, we don't have to show the date of birth but compute the answer.
    • -
  • Post-Quantum Cryprography: generating a digital signature using Post-Quantum digital signature algorithms.
    • +
  • Anonymous Revocation: a verifier must be able to verify the status of a credential, without having the ability to correlate information about the credentials and the holder.
    • +
  • No Phoning home or back-channel communication: Software often "calls home" for several reasons. They normally do this to collect usage or crash statistics but that can be used to trace the users or the verifier.
    • +
  • Privacy-Preserving DIDs: When resolving a DID, it is possible that the method uses a connection to a system for resolution.
-

What are we going to do about it?
Presentation and Verification

+

What are we going to do about it?
Cryptography

    -
  • Anonymous Revocation: a verifier must be able to verify the status of a credential, but this must be done without allowing the ability to correlate information about the specific or other credentials.
    • -
  • Rotational Identifiers: identifiers can be used to correlate, so it is important that they are temporary as much as possible during a session and changed after they are used.
    • -
  • Phoning home or back-channel communication: Software often "calls home" for several reasons. They normally do this to collect usage or crash statistics and track the users or the verifier.
    • -
  • Notification/Alerts: A holder must be notified if a presentation is going to be phoning home and must decide what to do.
    • -
  • Privacy-Preserving DIDs: When resolving a DID, it is possible that the method uses a connection to a system for resolution. If this system is under the direct or indirect control of the Issuer
    • +
  • Selective Disclosure and Unlinkable Credentials: is the ability to show only a part of the credential and not the full one, in an unlinkable manner. For example, we can show only the date of birth rather than the full ID document where it is contained, we are working on BBS cryptosuites.
    • +
  • Post-Quantum Cryprography: Quantum-safe cryptosuites for signatures.
+

Feedback on the EU Digital Identity's ARF 1.4.0: Our specific recommendation is to use the BBS [...], and countering future quantum threats.

Did we do a good job?

-

All models are wrong, but some are useful from statistician George Box (1976), quoted by Shostack (2014) in the context of threat modeling

+

All models are wrong, but some are useful from statistician George Box (1976), quoted by Shostack (2014)

    -
  • This Model is useful for us to understand the big picture.
    • -
  • Each solution (e.g., EUDI Wallet) needs a dedicated Threat Model.
    • -
  • Do you want to Threat Model? Join us!
    • +
  • This Model is useful for us to understand the big picture, create a place to sharing ideas, and understanding the need for other standards.
    • +
  • Each solution needs a dedicated Threat Model (e.g., EUDI Communication Protocol and Wallet).
    • +
  • Welcome to join the Threat Model discussions in the Threat Modeling Community Group
@@ -350,7 +354,7 @@

谢谢

https://www.w3.org/reports/identity-web-impact/
  • - Threat Modeling for Digital Credentials + Threat Model for Digital Credentials https://github.com/w3c-cg/threat-modeling/blob/main/models/decentralized-identities.md