Difference between revisions of "Wallet"

Revision as of 16:32, 29 January 2022

Full Title or Meme

The Wallet is a word with a common well-known meaning in real-life repurposed for use in Identity Management.

Context and History

Microsoft Info Card was the first imaginings of a digital identity token that could be placed in a Wallet. It was a complete failure.
Device Integrity Supporting User Authentication use case approved 2013-12-19 by IDESG.
Whose wallet is it anyway? 2020-04-25 by ANIL JOHN of DHS SVIP

In all of the following only those items that impact wallet design, deployment or testing are listed.

There are two distinct approaches to wallet definition:

The narrow approach taken by the Distributed Identity Foundation which starts with the assumption of blockchain, digital currency, W3C verifiable credentials and the DID core spec operating on their single use didcomm protocol between wallets.
The broad approach taken by standards organizations like OIDF that accommodate all participants like mobile Driver's Licenses and others that operation on existing HTTS networks.

NSTIC Principles

NSTIC Principles

Verifiable Credentials

From the Verifiable Credentials Data Model 1.0

repository = A program, such as a storage vault or personal verifiable credential Wallet, that stores and protects access to holders' verifiable credentials.
Terms of use - "This feature is also expected to be used by government-issued verifiable credentials to instruct digital wallets to limit their use to similar government organizations in an attempt to protect citizens from unexpected usage of sensitive data."
The cog ssi folk have created their own proprietary formats in an wallet interop sepc.

DID Core Spec

From the Decentralized Identifiers (DIDs) v1.0 (2021-02-03)

Design Goals

Control = Give entities, both human and non-human, the power to directly control their digital identifiers without the need to rely on external authorities.
Privacy = Enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other *data.
Security = Enable sufficient security for requesting parties to depend on DID documents for their required level of assurance.
Proof-based = Enable DID controllers to provide cryptographic proof when interacting with other entities
Simplicity = Favor a reduced set of simple features to make the technology easier to understand, implement, and deploy.

9.15 Level of Assurance

Additional information about the security context of authentication events is often required for compliance reasons, especially in regulated areas such as the financial and public sectors. Examples include but are not limited to protection of secret keys, the identity proofing process, and the form-factor of the authenticator. For example, Payment services (PSD 2) and eIDAS introduce such requirements to the security context. Level of Assurance (LoA) frameworks are classified and defined by, for example, eIDAS, NIST 800-63-3 and ISO/IEC 29115:2013, including their requirements for the security context, and making recommendations on how to achieve them. This might include strong user authentication and FIDO2/WebAuthn can be potential implementations. A LoA represents the level of confidence that an entity is in fact that entity. Some regulated use cases require the implementation of a certain LoA. Since verification relationships such as assertionMethod and authentication might be used in some of these use cases, information about the applied security context might need to be expressed and provided to a verifier. Whether and how to encode this information in the DID document data model is out of scope for this specification, but it should be noted that the DID document data model can be extended if necessary (see Extensibility section). Section Privacy Considerations remains applicable for such extensions.

10.3 DID Document Correlation Risks

The anti-correlation protections of pseudonymous DIDs are easily defeated if the data in the corresponding DID documents can be correlated. For example, using same public key descriptions or bespoke service endpoints in multiple DID documents can provide as much correlation information as using the same DID. Therefore the DID document for a pseudonymous DID also needs to use pairwise unique public keys. It might seem natural to also use pairwise unique service endpoints in the DID document for a pseudonymous DID. However, unique endpoints allow all traffic between two DIDs to be isolated perfectly into unique buckets, where timing correlation and similar analysis is easy. Therefore, a better strategy for endpoint privacy might be to share an endpoint among thousands or millions of DIDs controlled by many different subjects.

Mobile Driver's License

The mDL is an ISO standard that cannot legal be quoted. Here is one person's opinion.

ISO 18013-1 is the card in your wallet right now. It is machine readable. It would not be retired by any means known today.
ISO 18013-5 is the mobile Driver's License. It lives inside an app on your phone as an mdoc (whatever that might mean).
All implementations in North America (2021-02-04) have the state, rather than the federal government or user choice, supply an app.
State-issued apps and driver's license web sites all have sovereign immunity and some, like Texas, have no regard for user privacy.
The reader can ask the phone to prove some set of attributes (eg over 21, state resident)
The app can either get the data or a pointer to the data.
The phone does not leave the user's hands (and thus is not subject to seizure w/o legal basis)
No consensus exists on the means with which the user consents (it might be proximity).
While the use of the standards is limited to a driver's license, actual practices include other things, like access to drugs and alcohol.

The Kantara response with the FIC to the AAMVA RFI.

Threats

This follows the classical Threat Model design of Howard, Garg and Kohnfelder.

Systemic Threats

By far the largest threat is posed by very concept of a wallet to hold user secrets. This puts users in the habit of allowing their secrets to be held by others. If the concept of wallet is to become a symbol of trust, rather than an infection vector, the industry needs to take early action to ensure that bad actors cannot find a place to inject malware or poorly written code into the security space.
The core cause of the Solar Winds breach of major governmental and commercial web sites was trust in the code that was used to protect the servers on the web. A similar Supply Chain threat is opened by wallets. They will be a magnet for attackers that want to steal user credentials that can be used to infect other parts of the user and the user's navigation to site where they have administrative rights.
An example of system threat is the damage that can be caused by adding extension to browsers, which have become the defect place for collecting and protecting user passwords. Originally password managers were extension, but lately the browsers the selves have hosted password managers, which as limited the market for malware or poorly written managers.
The Vaccine imbroglio present since introduction of a small supply of vaccines into a huge market is bowser extensions like the Washington State Vaccine Locations service. On 2021-02-05 this site would send to you a map of locations were sites like Overlake Hospital Medical Center would send you to a third party signup service that installed a browser extension of unknown provenance. That "sign-up service" insisted on taking over the user's search bar, which is not only a valuable source of links for the service (Google makes most of their money this way), but also yet another source of infection vectors. This same pattern will surely repeat itself when COVID vaccination wallets become available.

Wallet to Credential Provider

Spoofing: In this case the user must be assured that the Credential Provider is trustworthy before it downloads a credential which might be very inappropriate for the user, like saying that the user is a registered pedophile
Tampering: The integrity of the message mandates that the message from the wallet is signed by the wallet and that the Wallet is known to protect the signing key.
Repudiation: The Non-Repudiation feature of a report of a wallet requires there is trustworthy Proof of Presence of the user at the device with suitable time stamping of the transaction.
Information Disclosure: The confidentiality of the interchange requires encryption. If TLS (HTTPS) is used it must be validated that the keying material of RP is trustworthy.
Denial of Service:
Elevation of Privilege:

Wallet to Relying Party

Identity Spoofing: The authenticity if the message depends on the level of assurance that the wallet provides a trustworthy report of the user's intent and that there is trustworthy Proof of Presence of the user at the device.
Tampering: The integrity of the message mandates that the message from the wallet is signed by the wallet and that the Wallet is known to protect the signing key. Also man-in the-middle attacks must be blocked.
Repudiation: The non-reputability of the report from the wallet requires that there is trustworthy Proof of Presence of the user at the device.
Information Disclosure: The confidentiality of the interchange requires encryption. If TLS (HTTPS) is used it must be validated that the keying material of RP is trustworthy.
Denial of Service: Availability of the wallet and the service needs to be high so that the user is not forced to use less secure methods.
Elevation of Privilege: The most common problem will be a web site claiming to be a trustworthy site when it is not. This requires clear indication to the user of a strong identity of the RP web site.

Wallet Application Code

Orie (2021-05-03) For folks on the ID&D call who had trouble following the “JSON-LD Context and Signatures” debate: Here is my summary, @Sam Smith feel free to add your own view, etc…

wallet/v1 -> term IRI is protected by software supply chain (exploitable)
IF wallet/v1 -> term IRI is changed, signatures break (exploit is detectable… but catastrophic).

There were some good questions about how this related to SolarWinds… In that case:

The update was malicious but signed by the correct issuer.
The update altered the function of the software, AND was not detected.
Everything was worse because the update did not cause crashes :slightly_smiling_face:

There are a couple principles hidden in this conversation which are universal:

Always fail loudly (don’t swallow exceptions)
Signature verification does not protect against software supply chain compromise.

What might have helped mitigate solar winds?

independent build servers, handling deterministic builds, and comparing the resulting hash… the compromised server would have differed

…humans could have asked the question…. why is this deterministic build differing in hash?.. maybe we should investigate. Now imagine that the “JSON-LD Canonicalization” process, called “createVerifyData” and described here: https://w3c-ccg.github.io/ldp-bbs2020/#create-verify-data-algorithm Is a kind of independent build…. in that, the code that constructs the verification data, and the code that produces it may be in different languages and on different devices (build servers)… Lets imagine the solar winds hack had changed a context, not a software implementation (which is dumb because its like shoplifting an apple where you will be detected vs a gold bar where you would not)…. In this case, the compromised createVerifyData would produce a different hash, and the signature would fail to verify…. which is good…. of course the attacker might be able to also update the verification algorithm to return true…. which again proves my point…

If your software supply chain is compromised, JSON-LD is the least of your concerns :slightly_smiling_face:
Now its true, that JSON-LD dependency and software implementations of RDF DataSet Normalizations AND createVerifyData are strictly speaking increased attack surface…
similar to implementing a JSON Parser (but worse)… this extra code may be exploitable… and in the infosec community we assume that if a bad thing can happen… it does.

We must then ask the question, how is the attack (we assume it is happening) detected?

This leads us to software supply chain, and https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

The tools we need to feel safer here are:

Independent deterministic builds
Code Signing
Security Audits of algorithms
Security Audits of implementations
Security Audits of hardware

Tom Jones 1:35 PM thanks Orie - one term of art is policy. The audit typically covers policy and tools rather they trying to see what s/w engineers actually do. (i guess that is what you mean by implementation). So i have actually done all of this and seen it work. It can be done. Step one was missing on solar winds. BUT this has little to do with what we need which is the format / schema on the data that transits from 1) the dev org, 2) the package installer 3) the interaction of the device w/ the s/w. 4) the action of the s/w when signing a bundle, 5) the receipt and validation of the bundle received. 1:37 let’s try to not dig into the details too far on every call or we will make little progress. The one thing missing from the call today was the realization that we need to trust the s/w signing bundles that the verifier needs to trust. 1:42 OH - employee vetting is required including immediate updates of access of terminated employees. (and physical security) - If you ever get to the place where this is needed I can help put it together - i doubt that it belongs in the protocol doc. (edited)

QR Codes

Since Native App Wallets are not able to use the same front-end code that OpenID Connet use to get a good user experience, several schemes have switched to using QR code that call any protocol that is supported by the smartphone. While this seems to be good for security, it is well known in 2022-01 that scammers have learned to use it for a variety of subtle attacks against the user.

Requirements

Also known as normative statements.

The first principle is that if it is not documented, then it didn't happen. Be sure that you have the documentation to provide to the team that certifies the app.
Create a good architectural design that includes a risk assessment. (See list of threats above for some ideas.)
Deploy a code management plan so that every line of code can be traced back to a developers check-in.
Secure the supply chain and only sign and deploy code that is validated as meeting Security Risk requirements.
Ensure that the user is never asked to agree to (or to sign) any access that they cannot fully understand. Options MUST be in plain language that is clear and easy for a general audience (typically defined to be an 8th grade education) to understand.
Protect the user's information assets in a manner consistent with the risk. The user's control of the use of the identifier would require the highest level of protection.

Assessment Criteria

Management commitment to the code of conduct.
Development plan.
Data flow diagram suitable for a threat analysis.
Test criteria for each measurable requirement from the spec.

Examples

Not all meet the requirements listed above.

Apple Wallet

There are no terms and conditions for the wallet above and beyond that for the iPhone. Apple Pay and any card in the wallet does come with terms and conditions that are part of the agreement with the user for those services. Encryption is never mentioned other than in connection with privacy.

Digital Certificates

The Apple Software contains functionality that allows it to accept digital certificates either issued from Apple or from third parties. YOU ARE SOLELY RESPONSIBLE FOR DECIDING WHETHER OR NOT TO RELY ON A CERTIFICATE WHETHER ISSUED BY APPLE OR A THIRD PARTY. YOUR USE OF DIGITAL CERTIFICATES IS AT YOUR SOLE RISK. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, APPLE MAKES NO WARRANTIES OR REPRESENTATIONS, EXPRESS OR IMPLIED, AS TO MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE, ACCURACY, SECURITY, OR NON-INFRINGEMENT OF THIRD PARTY RIGHTS WITH RESPECT TO DIGITAL CERTIFICATES.

Security; Lost or Disabled Devices

Apple Pay stores virtual representations of your Supported Cards and should be protected as you would protect cash or your physical credit, debit, prepaid, rewards, or gift cards. Providing your Device passcode to a third party or allowing a third party to add their fingerprint to use Touch ID or enable Face ID may result in their ability to make payments, send, request, or receive person to person payments, withdraw money from your Apple Cash card, or receive or redeem rewards or credit using Apple Pay on your Device. You are solely responsible for maintaining the security of your Device and of your passcode. You agree that Apple does not have any responsibility if you lose or share access to your Device. You agree that Apple does not have any responsibility if you make unauthorized modifications to the Apple Software (such as by way of a “jailbreak”).You may need to enable additional security measures, such as two-factor authentication for your Apple ID, in order to access particular features of Apple Pay, including Apple Card, the Apple Cash card, and person to person payments with Apple Pay. If you subsequently remove those security features, you may not be able to continue to access particular features of Apple Pay.If your Device is lost or stolen and you have Find My iPhone enabled, you can use Find My iPhone to attempt to suspend the ability to pay with the virtual Supported Payment Cards or sending person to person payments on that Device by putting it into Lost Mode. You can also erase your Device, which will attempt to suspend the ability to pay with the virtual Supported Payment Cards or send person to person payments on the Device and will also attempt to remove the Apple Pay-Enabled Cards. You should also contact the issuer of your Supported Payment Cards, the merchant who issued your Apple Pay-Enabled Cards, or Apple in the case of your Apple Card or Apple Cash card in order to prevent unauthorized access to your Supported Cards.

Jolocom

Connect.me

This wallet is provide by Evernym. This is what their website says:

Why can I trust this?
- We don’t own any of your information
  - Zip, zero, zilch. Connect.Me is built on Sovrin, which means you can use your credentials anywhere, even on a different app altogether.
- Your info lives with you
  - Your information isn’t stored in the cloud, it lives in your pocket. So you’re the one in control of your data, where it goes and how it’s used.
- State of the art encryption
  - Connect.Me creates unique, pairwise cryptographic connections to communicate. It's like inventing a new, unique language each time you speak with someone new— and only the two of you understand it.

This is what the app says:

Sophistication and Risk of Cryptographic Systems

By utilizing the Application, User represents and warrants that User understands the inherent risks associated with cryptographic systems and that User has an understanding of the usage and intricacies of key cryptography, native cryptographic tokens, and blockchain-based software systems.

Risk of Weaknesses or Exploits in the Field of Cryptography

USER ACKNOWLEDGES AND AGREES THAT CRYPTOGRAPHY IS A PROGRESSING FIELD. ADVANCES IN CODE CRACKING OR TECHNICAL ADVANCES SUCH AS THE DEVELOPMENT OF QUANTUM COMPUTERS MAY PRESENT RISKS TO CRYPTOGRAPHIC SYSTEMS AND THE APPLICATION, WHICH COULD RESULT IN THE THEFT OR LOSS OF YOUR CRYPTOGRAPHIC TOKENS OR PROPERTY. TO THE EXTENT POSSIBLE, EVERNYM INTENDS TO UPDATE THE APPLICATION TO ACCOUNT FOR ANY ADVANCES IN CRYPTOGRAPHY AND TO INCORPORATE ADDITIONAL SECURITY MEASURES BUT DOES NOT GUARANTEE OR OTHERWISE REPRESENT AND/OR WARRANT SECURITY OF THE APPLICATION. BY USING THE APPLICATION, USER ACKNOWLEDGES THESE INHERENT RISKS

USER ACKNOWLEDGES AND AGREES THAT DATA THAT MAY BE INVOLVED IN CONNECTION WITH ANY SERVICE ACCESSIBLE THROUGH USE OF THE APPLICATION IS STORED ON USER’S DEVICE.

USER FURTHER ACKNOWLEDGES AND AGREES THAT USER IS SOLELY RESPONSIBLE FOR SECURELY MAINTAINING:

USER’S TOKENS (INCLUDING CRYPTOGRAPHIC TOKENS);

USERNAME, PASSWORD AND OTHER IDENTITY-RELATED CREDENTIALS;

THE SECURITY OF USER’S DEVICE; AND

SEPARATE BACKUP COPIES OF ANY DATA STORED ON ITS DEVICE INCLUDING WITHOUT LIMITATION ENCRYPTED DATA THAT MAY BE INVOLVED IN CONNECTION WITH ANY SERVICE ACCESSIBLE THROUGH USE OF THE APPLICATION.

Verified.Me

This wallet is from Secure Key and is focused at first on Governments Sign-In Canada. So it comes with an existing user sport system.

The legal documents for this wallet include Privacy Notice, Terms and Conditions, Trademarks, and engagement with credit bureaus. There are no user friendly describes of the privacy or limitations that could be discovered. There are buried descriptions about how it works and support features.

Solutions

Based on some level of hardware support at the user site, there are a wide range of possible solutions

Devices with Secure Enclave

All ARM and Intel CPUs now have some sort of Trusted Execution Environment included on chip.

Android report from Authenticate 2021-10-19 - Dave Kleidermacher, Google’s VP of Engineering for Android Security outlined what he sees as big challenges of digital safety during his keynote. Those challenges include the need to have simple, strong access control over digital and physical spaces and identity. That’s where he sees digital wallets that benefit from FIDO specifications as being a big help.

Kleidermacher explained that Android devices now offer a digital wallet with a built-in security key. “We’ve worked with the FIDO Alliance to build standard protocols and API’s for developers to incorporate what’s really a miracle of unphishable authentication to any service,” Kleidermacher s

Pluggable Hardware support

This comes in at least two styles:

FIDO 2 keys that contain the means to create a private key per correspondent web site.
USB devices that can off load the secrets, primarily for back-up and restore have been available for at least 20 years.
The Ldeger wallet is a method to store users secrets on an intelligent hardware portable stick. Since it is programable, it is also hackable and exploits have been described.

Examples:

Ledger Nano S Easily start your crypto journey: buy crypto, secure your assets and manage them in one single-app.

Native Apps

The primary feature of a Native App is access to the secure enclave.
Both Android and Apple wallets will allow migration of credentials from one of their wallets to another, but not between the two companies.

Cloud Based

These also come in a wide range of support functions from a full wallet implementation to trust service or back-up and restore functionality. They can also implement sharing between to user devices.