diff --git a/ADIA-Security-Reference.bs b/ADIA-Security-Reference.bs index 3d94312..80ec2cf 100644 --- a/ADIA-Security-Reference.bs +++ b/ADIA-Security-Reference.bs @@ -33,14 +33,16 @@ spec:webidl; type:interface; text:Promise # ADIA Security and Privacy Goals # {#sctn-adia-secref-goals} 1. Allow Users to present a claim to the service provider, where - 1. SG-1: the service provider can verify that the shared claim was issued by an Issuer belonging to the ADIA ecosystem (and the assurance level this issuer was vetted at) and - 2. SG-2: the service provider can verify that the entity presenting the claim is the subject of that claim -2. SG-3: Ensure that the user needs to consent with the action of sharing the claim(s) -3. SG-4: Ensure that the user can select the claims to be shared (not only all claims or none). -4. SG-5: Ensure the issuer doesn't learn who the service provider is (Note: the service provider will learn who the issuer is) -5. SG-6: Ensure that a service provider that receives two claims doesn't learn whether the two claims belong to the same user *beyond* the degree of overlapping claims, i.e. We don't introduce another correlation handle. For example, if a service provider receives two claims that the respective subject is older than 21, there is no way for the service provider to know whether the two claims belong to the same or two different users. In the case the full name, birthdate etc. are included in the claims the service provider will learn that two claims containing the same attributes will likely or even certainly relate to the same users. -6. SG-7: Assessable level of assurance - throughout the system (IAL and AAL) -7. SG-8: Robust minimum assurance level with + 1. SG-0: the claims accurately reflect the subject and + owner of the VC + 2. SG-1: the service provider can verify that the shared claim was issued by an Issuer belonging to the ADIA ecosystem (and the assurance level this issuer was vetted at) and + 3. SG-2: the service provider can verify that the entity presenting the claim is the subject of that claim +2. SG-3: Ensure that the user needs to consent with the action of sharing the claim(s) +3. SG-4: Ensure that the user can select the claims to be shared (not only all claims or none). +4. SG-5: Ensure the issuer doesn't learn who the service provider is (Note: the service provider will learn who the issuer is) +5. SG-6: Ensure that a service provider that receives two claims doesn't learn whether the two claims belong to the same user *beyond* the degree of overlapping claims, i.e. We don't introduce another correlation handle. For example, if a service provider receives two claims that the respective subject is older than 21, there is no way for the service provider to know whether the two claims belong to the same or two different users. In the case the full name, birthdate etc. are included in the claims the service provider will learn that two claims containing the same attributes will likely or even certainly relate to the same users. +6. SG-7: Assessable level of assurance - throughout the system (IAL and AAL) +7. SG-8: Robust minimum assurance level with 1. Credential guessing resilience, i.e. provide robust protection against eavesdroppers, e.g. be resilient to physical observation, resilient to targeted impersonation, resilient to throttled and unthrottled guessing 2. Credential Disclosure Resilience: Be resilient to phishing attacks and real-time phishing attack, including resilience to online attacks by adversaries able to actively manipulate network traffic 3. Verifier Leak Resilience: Be resilient to leaks from other relying parties. I.e., nothing that a verifier could possibly leak can help an attacker impersonate a user to another relying party (e.g. claim's subject to service provider or user to issuer). @@ -53,27 +55,188 @@ Issue: The DAS will learn whenever claims are presented - this needs to be discussed somewhere. # ADIA Assets to be Protected # {#sctn-adia-secref-assets} -See section "Trust Model" of the ADIA specification. +See section "Trust Model" of the ADIA specification for an overview. -1. Private keys of: - 1. ADIA Global Directory - 1. ADIA Regional Directory - 1. Digital Address Service (DAS), key maintained by the DAS agent. - 1. Issuer, key maintained by the Issuer Agent. - 1. Service Provider, key maintained by the Service Provider Agent. - 1. User - 1. DAS User ID key, maintained by the DAS User Agent - 2. FIDO keys, maintained by the user's FIDO Authenticator(s), and all other FIDO related assets that need protection, see - FIDO - Security Reference. +## Private Key Assets ## {#sctn-adia-secref-assets-sk} +The following private keys need to be protected against disclosure ("confidentiality protection"): + +
+ + + + + + + + + + + + + + +
AssetProtection Method
AGD_ID_SK TODO
ARD_ID_SK TODO
DAS_USER_ID_SK TODO
USER_FIDO_SK maintained by the user's FIDO Authenticator(s), and all other FIDO related assets that need protection, see + FIDO + Security Reference. +
DAS_ID_SK TODO
ISSUER_ID_SK TODO
SP_ID_SK TODO
+
Protection of Private Keys
+
+ + +## Data Relation Assets ## {#sctn-adia-secref-assets-relations} + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AssetProtection Method
Issuer stored identity proofing records and their relation to the User's DA Stored in Issuer DB + +Issue: Is this proprietary to the Issuer? Do we have minimum security + requirements for that? Do we specify a minimum retention period + for this? +
Relation of a Digital Address to a Trust Anchor in + general Stored in AGD as (TA, ID, DA, HomeDASId) tuple. + +Issue: What is the protection method? How can that be audited? +
AGD_ID to AGD_DA relation Stored in AGD as (TA, ID, DA, HomeDASId) tuple. + +Issue: What is the protection method? How can that be audited? +
ARD_ID to ARD_DA relation Stored in AGD as (TA, ID, DA, HomeDASId) tuple. + +Issue: What is the protection method? How can that be audited? +
DAS_USER_ID to User's DA relation Stored in ARD as (TA, ID, DA, HomeDASId) tuple. + +Issue: What is the protection method? How can that be audited? +
DAS_ID to DAS_DA relation Stored in AGD as (TA, ID, DA, HomeDASId) tuple. + +Issue: What is the protection method? How can that be audited? +
ISSUER_ID to ISSUER_DA relation Stored in AGD as (TA, ID, DA, HomeDASId) tuple. + +Issue: What is the protection method? How can that be audited? +
SP_ID to SP_DA relation Stored in AGD as (TA, ID, DA, HomeDASId) tuple. + +Issue: What is the protection method? How can that be audited? +
DAS_USER_ID_PK to DAS_USER_ID relation signed DIDDoc-USER
ISSUER_ID_PK to ISSUER_ID relation signed DIDDoc-ISSUER
SP_ID_PK to SP_ID relation signed DIDDoc-SP
DAS_ID_PK to DAS_ID relation signed DIDDoc-DAS
ARD_ID_PK to ARD_ID relation signed DIDDoc-ARD
AGD_ID_PK to AGD_ID relation signed DIDDoc-AGD
Relation of the various Claims in a VC to the + Claim identifying the (Credential) Subject (see ADIA Trust Model).signed VC object
Relation of a VC to the VP and to the respective public key + that is used to the presentation.signed VP object
+
Protection of Data Relation Assets
+
+ + +Issue: For each item above, describe what methods are in place to protect these + assets. E.g. we use signed DIDDocs for integrity protection of the + *_PK to *_ID relations, etc. # ADIA Security Measures # {#sctn-adia-secref-measures} +1. SM-1: Tamper-Evidence through digitally signed data: + 1. Users digitally sign the VPs to provide evidence + that the credential subject is presenting the VC. + 1. Issuers digitally sign the VCs based on information the Issuers have verified. + 1. DAS digitally signs the DIDDoc-USER, i.e. the relation + between the DAS_USER_ID_PK and the DAS_USER_ID. + 1. DAS digitally signs the DIDDoc-ISSUER, i.e. the relation + between the ISSUER_ID_PK and the ISSUER_ID. + 1. ARD digitally signs the DIDDoc-DAS, i.e. the relation + between the DAS_ID_PK and the DAS_ID. + 1. AGD digitally signs the DIDDoc-ARD, i.e. the relation + between the ARD_ID_PK and the ARD_ID. + +1. SM-2: secure communication between the entities (except the User) using DIDComm [[DIDCOMM-MESSAGING-V1]] + +1. SM-3: secure communication between the User's DAA + and Issuer using TLS and Issuer specific methods to verify + the user's identity (e.g. remote ID Proofing). + +1. SM-4: secure communication between the User's DAA and the + 1. Cloud Agent using FIDO authenticated TLS. + 2. SP using TLS and TODO! Not yet clear how a session + initiated by the User would be tied to a VP in order to + know whether the User at the end of the line is the + VP's subject. + +1. SM-5: support Anonymous VCs leveraging + zero-knowledge-proofs (ZKPs). Issue: TODO ## Relation between Measures and Goals ## {#sctn-adia-secref-measgoals} +
+ + + + + + + + + + + + + + + +
Security GoalSupporting Security Measures
SG-0 Claims are verified by + Issuers. TODO: add stipulatoins for Issuer + systems to validate the claims and to keep the records + integrity protected - even under attack. Add details on dual + control to limit risk of malicious employee attack.
SG-1 SM-1
SG-2 TODO: Seems unclear at this stage! We + need some random value (server nonce) generated by the SP that is returned in + step "Wants proof and requests User to connect DAA via SP_ID" in figure "Verifiable Presentation and Verification (Option + 1)" and the same applies to the Optopn 2 Anonymous flow. This + server nonce also needs to be included in step "Invites SP for + DIDComm connection (mutual authentication)" since the SP wants to + know whether this communication relates to the session initiated + from some user in the beginning. +
SG-3 User consent is enforced by the User's Cloud + Agent via the DAA. +
SG-4 Claim selection is performed by + User's Cloud Agent via the + DAA. A VC structure is being + used that supports fine grained + claim selection (TODO add reference). +
SG-5 TODO: Ensure that step "Request for + VC along with sending User's consent" in "VC + Presentation and Verification" doesn't include any SP specific + hints. Since this communication with the Issuer is synchronous, + the Issuer at least learns the time when the user wants to share + the VC. That could statistically disclose some information + about the SP. The Issuer learns how often a user shares a + VC. Ideally, ADIA would "hide" that information and "cache" the VC. +
SG-6 SM-5
SG-7 TODO: We need to track IAL and AAL + throughout the system. We also need to avoid unexpected attack + points that might reduce the IAL/AAL.
SG-8 TODO
+
Relation between Security Measures and Goals
+
+ Issue: TODO # ADIA Security Assumptions # {#sctn-adia-security-assumptions} @@ -82,5 +245,143 @@ Issue: TODO # Threat Analysis # {#sctn-adia-threat-analysis} -Issue: TODO +## Threats to the Global Directory ## {#sctn-ta-agd} + +## Threats to a Regional Directory ## {#sctn-ta-ard} + +## Threats to the DAS ## {#sctn-ta-das} + +## Threats to the Issuer ## {#sctn-ta-issuer} + + + + + + + + + + + + +
T-4.1.1Malicious EmployeeViolates
+ A malicious employee forges an ID Verification. + +

Consequences: + + Issue: TODO + +

+

Mitigations: + + Issue: TODO + +

[=SG-1=]
+ + +## Threats to the Service Provider ## {#sctn-ta-sp} + +## Threats to the User Environment ## {#sctn-ta-user} + + + + + + + + + + + + +
T-6.1.1DAA CorruptionViolates
+ The Digital Address Application used by the user + is corrupted (e.g. user installed and uses a + malicious version or the original DAA was modified + by malware). + +

Consequences: + The USER_FIDO_PK/SK might be weakly protected + (e.g. generated in SW rather than TEE, or + generated such that it could be used without a + user gesture, or generated such that export is allowed). + + The USER_FIDO_PK might be misused for unexpected + purposes. + + QR-code scanned at "User Onboarding to First + Issuer" might be misinterpreted. + + Data for remote ID Proofing might be taken from a + source other than the device's live camera (e.g. a + recording). + + ID-Attributes for HIDA computation might be + malicious in User Initiated Digital Address Creation + with DAA. + + The DAA might maliciously disclose the DAS_USER_ID + and/or the DA. + + The DAA might maliciously disclose the SP_ID + to the issuer. + + The DAA might display a malicious set of + attributes to be included in a verifiable claim in VC + Issued to a User by an Issuer. + + The DAA might display a malicious set of + attributes to be included in a verifiable claim to + be presented to a service provider or a malicious + service provider name in Verifiable Presentation and + Verification. + + The DAA might maliciously chose Option 1 instead + of Option 2 in Verifiable Presentation and + Verification. +

+

Mitigations: + Attestation of FIDO Authenticator allows the + server to verify whether USER_FIDO_PK was + generated in an authenticator with acceptable + security characteristics. + + Issue: Should add a need to using SafetyNet and + the iOS equivalent in order to allow the server to + verify that the original DAA is being used. +

[=SG-1=], [=SG-3=], [=SG-4=], [=SG-5=], [=SG-6=]
+ + + + + + + + + + + + +
T-6.1.2Cloud Agent CorruptionViolates
+ The Cloud Agent that acts on behalf of the user is + attacked. + +

Consequences: + The attacker might try to extract the DAS_USER_ID_SK. + + The attacker might try to misuse the DAS_USER_ID_SK + (e.g. to sign or decrypt messages withouh approval + of the user). + + Issue: Should consider renaming DAS_USER_ID_PK to + CA_USER_ID_PK (for cloud agent) +

+

Mitigations: + + Issue: TODO, e.g. let Cloud Agent use HSMs and + tight coupling of the HSM to the User's FIDO Key(s). + +

[=SG-2=], [=SG-3=], [=SG-4=], [=SG-5=], [=SG-6=]
+ + diff --git a/header.include b/header.include index 0023088..24578cc 100644 --- a/header.include +++ b/header.include @@ -7,17 +7,47 @@ diff --git a/resources/bikeshed/header.include b/resources/bikeshed/header.include index 87037bf..24578cc 100644 --- a/resources/bikeshed/header.include +++ b/resources/bikeshed/header.include @@ -10,6 +10,44 @@ h1, h2, h3 { color: #f29c00; } + table, th, td { + border: 1px solid black; + border-collapse: collapse; + } + :link { + color: #00C; + } + :visited { + color: #609; + } + a:active { + color: #C00; + } + a[href]:focus, a[href]:hover { + color: #C00; + } + a[href] { + color: #034575; + text-decoration-color: #034575; + } + :link, :visited, a:active { + background: transparent; + } + a:link img, a:visited img { /* no border on img links */ + border-style: none + } + .issue, .issue::before, .issue > .marker, details.issue > summary { + color: #aa0000; + text-decoration-color: #aa0000; + background: #fbb; + border-color: #aa0000; + } + .note, .note::before, .note > .marker, details.note > summary { + color: #52e052; + text-decoration-color: #52e052; + background: #e9fbe9; + border-color: #52e052; + } diff --git a/sections/operations/directory-enrollment.include b/sections/operations/directory-enrollment.include index d404609..22e8598 100644 --- a/sections/operations/directory-enrollment.include +++ b/sections/operations/directory-enrollment.include @@ -126,7 +126,7 @@ provides services to persist and search the Credential Metadata associate The diagram below represents a `new` User requesting a Digital Address from an Issuer. The DAS providing the Agency services, provisions a Cloud Agent for the User to create -a public/private key pair and a DID (i.e. DAS_usER_ID) for the User. The identifier (DAS_USER_ID), along with the +a public/private key pair and a DID (i.e. DAS_USER_ID) for the User. The identifier (DAS_USER_ID), along with the HomeDAS identifier (HomeDAS_ID) are persisted on the DAS to associate their identifiers with the newly created Digital Address. Please refer to the [[#sctn-trust-anchor]] and [[#sctn-digital-address]] sections for more details on the representation and usage of the Digital Address. diff --git a/sections/operations/vc-operations.include b/sections/operations/vc-operations.include index dc4d29d..1b0c040 100644 --- a/sections/operations/vc-operations.include +++ b/sections/operations/vc-operations.include @@ -79,6 +79,11 @@ Please refer to the section on [[#sctn-trust-model]] for details on how the I
Verifiable Presentation and Verification (Option 1)
+Issue: The third arrow ("Provide SP_ID to DAA") seems wrong: The SP cannot directly connect to the DAA. I think this arrow should start a User (meaning user's Browser) and then do to DAA. + +Issue: We should rename user to User's Browser to be more precise. + +Issue: Need to add more steps to the end that show how the User's Browser would continue interacting with the SP. Essentially the SP has established an authenticated session a known user and now needs to return an authorization token to the user's browser. ADIA spec should be open to what type of token is used, but we need to show how that could be done. ### Present Anonymous Credentials ### {#sctn-anon-creds} @@ -99,6 +104,7 @@ to avoid the exposure of a correlation handle.
Verifiable Presentation and Verification (Option 2: Anonymous)
+Issue: Need to add more steps to the end that show how the User's Browser would continue interacting with the SP. Essentially the SP has established an authenticated session a known user and now needs to return an authorization token to the user's browser. ADIA spec should be open to what type of token is used, but we need to show how that could be done. ## User Consent ## {#sctn-user-consents} diff --git a/sections/overview/trust-model.include b/sections/overview/trust-model.include index 0825691..90d79e6 100644 --- a/sections/overview/trust-model.include +++ b/sections/overview/trust-model.include @@ -5,6 +5,8 @@
ADIA Trust Model
+Issue: Add DIDDoc-SP. It is referenced in a sequence diagram (setup new SP) and also in the Security Reference. + When verifying a verifiable presentation of a verifiable credential, the following objects need to be verified: 1. Verifiable Presentation, i.e. an object containing a