Wallet Security Standardization Roadmap

Two problems to solve:

• device binding
• wallet authentication

Motivation:

• successful but propietary solution in german BKAmt pilot
• efforts in Germany & Canada
• standardization neccessary for interoperable and scalable solution

Status Quo

• using upfront REST API calls before sending the DIDComm invitation
• Certificate Pinning

Device Binding

Prior thoughts on device binding : https://docs.google.com/document/d/1iJAB7VRe1P4wEaBOAb-g8Fn4JvyMXpkpEMkK06U1Qh4/edit#heading=h.y4fziuuyzbcj

Issuance Option #1:

• Issuance Option 1a: define new DIDCommProtocol

  • send invitation and establish DIDComm conncetion first, process device binding, process credential issuance
  • binding between Device Binding and issue credential protocol?
  • proposal 1a: https://hackmd.io/@pwlb/Sk2jrJZlc

• Issuance Option 1b: extend existing with decorators/attachments

  • more compact, less messages
  • missing first communication form issuer to holder?
  • multiple issue_v* processes
  • Sebastian Bickerle will evaluate possiblities for Option 1b
  • proposal 1b: https://hackmd.io/@sbickerle/rka12zWe5

• how to bootstrap process?

  • DIDComm discover 2.0 feature ?
    • get WalletSecurityCapabilities? device binding and wallet authentication

• writeup Aries RFC

Verification process must also be considered

todo: where to integrate proof?

Options:

1. self-attested attribute (status quo)
2. decorator for present proof V* (2b)
3. separate protocol (2a)

Wallet Authentication

• Motivation:
  • user authentication performed locally on device, key mangement on device
  • there this requires trust into the correct implementation of the wallet
  • eIDAS also requires user authentication
• usable mechanisms: Android SafetyNet, iOS Device Check, Key Attestation etc..

Design questions

• Question 1 : Who shall request wallet authentication? (Issuer) vs (Issuer and Verifier)
• Question 2: How fresh must this information be?
• Question 3: How is this information transmitted?
• Question 4: Is Device Binding coupled to Wallet Authentication or is it separatly usable?

Best practice:

• one hardware key per credential(where necessary) instead of one global key -> ensure best privacy possible
• repsect data privacy as best as possible, try to avoid trackable information
• ues ZKP for checks where possible

Option #1:

• Wallet Authentifaction directly to the issuer

• Advantage:

  • Issuer directly validates the wallet
  • high security
  • "fresh" proof

• Disadvantage:

  • mechanisms are initially intended for app backend, nonce provided by "third party"
  • might run into scalibility issues when many parties using this (ecpecially verifiers)
  • requires separate DIDComm Protocol?

• regard hybrid solutions Cloud/edge

Option #2a:

• Wallet Authentication is proofed towards a service, e.g. Wallet Issuer, that encodes the information in a VC
• Advantage:
  • easily usable for Issuer and Verfier
  • interoperable solution using existing mechanisms
  • scalable
• Disadvantage:
  • proof is "not fresh"
  • trust is indirect - although we have to trust the wallet implementer anyhow
  • additional work for the wallet implementer

challenges: Device Binding and/or prevent VC to be transferable (Backup/recovery)?

question: timeframe for renewal?

Option 2b:

• Wallet contacts Wallet issuer upfront
• they perform Wallet Authentication with SafetyNet/DeviceCheck etc..
• secure hardware key is generated
• wallet authentication and hardware public key isnchored in VC
• Advantage:
  • one Wallet Auth VC per hardware key
  • "fresh" proof during key generation
• Disadvantage:
  • one Wallet Auth VC per hardware key
  • key format/signature/security mechanism is determined upfront
  • additional work for the wallet implementer

giving this VC to the Verifier?

offtopic:

• Wallet implementer should go through a certification/pen testing(both variants)
• binding to Google Android, iOS Services
• Android Derivatives?
• What about chinese phones?