Wallet

From MgmtWiki
Revision as of 11:22, 6 February 2021 by Tom (talk | contribs) (Wallet to Relying Party)

Jump to: navigation, search

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.
  • 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.

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."

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.

Threats

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

Systemic Threats

  1. 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.
  2. 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.
  3. 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.
  4. 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 Proivder

  1. Spoofing
  2. Tampering
  3. Repudiation
  4. Information Disclosure
  5. Denial of Service
  6. Elevation of Privilege

Wallet to Relying Party

  1. 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.
  2. 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.
  3. Repudiation: The non-reputability of the report from the wallet requires that there is trustworthy Proof of Presence of the user at the device.
  4. 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.
  5. 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.
  6. 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.

Requirements

This list is just a SWAG.

  1. 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.
  2. Create a good architectural design that includes a risk assessment. (See list of threats above for some ideas.)
  3. Deploy a code management plan so that every line of code can be traced back to a developers check-in.
  4. Secure the supply chain and only sign and deploy code that is validated a meeting security risk requirements.
  5. 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.
  6. 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.

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.

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.

References