Mobile Driver's License Criteria

From IDESG Wiki
Jump to navigation Jump to search

Full Title or Meme

The Mobile Driver's License Criteria for a high level of Identity and Authentication Assurance.

Context

Actors

  1. Holder - the subject of the Mobile Driver's License, which is presumably hosted in a native smartphone app
  2. Reader - a device that can read and verify the mDL from the smartphone.
  3. Issuing Authority - typically a state motor vehicle agency (aka DMV, dept. of motor vehicles).
  4. Trust Authority - some sort of wide ranging list of valid participators - not well defined at this point.

Taxonomy

  • Caution on terms. mdoc, mDL and mDL app get conflated in the specs. The full mDL (mdoc) is seldom/never released by the app to the reader/verifier.
  • Compare there terms Verifiable Credential and Presentation Exchange from the DIF folk. The VC (like the mDL or mdoc) may be in the smartphone, but only a part is "presented" to the reader.
  • Digital identity is generally recognized as the digital representation of an individual in an electronic transaction. (from RFC).
  • An mDL is a digital representation of the identity information contained on a state-issued physical DL/ID. (from RFC).
  • Authenticate means establishing that a certain thing (e.g., mDL Data) belongs to its purported owner (e.g., mDL Holder) and has not been altered.
  • A Certificate Authority issues Digital Certificates that are used to certify the identity of parties in a digital transaction.
  • Data Freshness refers to the synchronization of mDL Data stored on a mobile device to data in a DMV’s database, within a specified time period.
  • Department of Motor Vehicles (DMV) refers to the state agency or its authorized agent responsible for issuing an mDL and for maintaining mDL data in its database.
  • Digital Certificates establish the identities of parties in an electronic transaction, such as recipients or digital signatories of encrypted data.
  • Digital Signatures are mathematical algorithms routinely used to validate the authenticity and integrity of a message.
  • Identity Proofing refers to a series of steps that a DMV executes to prove the identity of a person.
  • Identity Verification is the confirmation that identity data belongs to its purported holder.
  • Issuance includes the various processes of a DMV to approve an individual’s application for a REAL ID driver’s license or identification card.
  • An mDL is a digital representation of the information on a state-issued physical DL/ID, and is stored on, or accessed via, a mobile device.
  • mDL Data is an individual’s identity and DL/ID data that is stored and maintained in a database controlled by a DMV and may also be stored and maintained on an individual’s mDL.
  • mDL Holder refers to the owner of a mobile device that contains an mdoc (aka mDL).
  • mDL Reader refers to an electronic device that ingests mDL Data from a mobile device.
  • Offline means no live connection to the internet.
  • Online means a live connection to the internet.
  • An mDL Public Key Distributor is a trusted entity responsible for compiling and distributing Digital Certificates issued by DMVs.
  • Public Key Infrastructure (PKI) means a structure where a Certificate Authority uses Digital Certificates for Identity Proofing and for issuing, renewing, and revoking digital credentials.
  • Provisioning refers to the various steps required for a DMV to securely place an mDL onto a mobile device.
  • Token means a cryptographic key used to authenticate a person’s identity.
  • Data Verifier is part of the ISO 18013-5 mDL spec, but not part of the DHS request. It may be assumed to be the natural extension of the mDL reader.
  • Consent from 18013-5

    mDL verifiers should request the minimum data required for their use case. With each request for data, mDL verifiers should provide adequate informed consent, including the purpose and scope of data requested, to the mDL holder and never use blanket terms and conditions in lieu of informed consent.

  • E.13.5 Pre-consent

    Pre-consent enables mDL holders to configure specific mDL verifiers with whom they have a trust relationship to share data. Those mDL verifiers may be permitted access to a repeat set of mDL data without transaction-time consent. In all cases that pre-consent is long-lived, the mDL holder should clearly select this configuration and be aware that pre-consent is in place.

Two key concepts are deliberately left out of the ISO 18013-5 spec, but need to be part of the criteria for use.

  • User Consent to share their data with the verifier and data minization are not mentioned in the RFC, which does call for privacy 25 times without further explanation.
  • Protection of data at rest or Data Storage security is explicitly called out in the DHS RFC.

Use Cases

Problems

  • REAL ID has yet to approve a single state's Mobile Driver's License (mDL) for Federal access.
  • Supply Chain for components of the mDL has not been a part of existing criteria, but needs to be included based on the Solar Winds attack of government and commercial access.

The REAL ID Act

  • The Act set minimum requirements for state-issued DL/ID accepted by Federal agencies for official purposes, including accessing Federal facilities, boarding federally regulated commercial aircraft, entering nuclear power plants, etc.
  • Full enforcement of the REAL ID regulation begins October 1, 2021 (note implementation of the Real ID Act in the US has been delayed multiple times since its passage more than 15 years ago) (update 2021-04-27 it's now May 2023. In early 2021, only 43% of driver's licenses issued in the U.S. were REAL ID-compliant, according to DHS data.)
  • Examples of security requirements applicable to physical cards include ‘‘common machine-readable technology’’ and ‘‘security features designed to prevent tampering, counterfeiting, or duplication . for fraudulent purposes. (i.e. ISO 18013-1 plus a few embellishments.)
  • Good security practices in creating an implementing the distribution.
  • ISO 18013-5 (mDL) will need embellishments as well for the REAL ID Act. AAMVA is given official recognition in this effort.
  • For Federal agencies to accept mDLs for official purposes, an mDL ecosystem must allow for trusted and secure communications between a DMV, a mobile device, and a federal agency.
  • a system would provide functionality analogous to the physical security features required under 6 CFR 37.15 that are designed to deter forgery and counterfeiting, promote confidence in the authenticity of the DL/ID, and facilitate detection of fraud.
  • a DMV would be responsible for issuing an mDL and enabling a user’s mobile device to store and/or access mDL data.
  • An individual’s mDL Device would transmit mDL Data, or a digital ‘‘token,’’ to the reader via wireless or secure optical communication protocols.
  • the reader and mobile device would require the capability to communicate and authenticate the mDL data in at least offline (no internet connection) mode. The system would require digital security protocols to protect the confidentiality, privacy, security, and integrity of the mDL data, through its full lifecycle.
  • an mDL Holder would authorize release of relevant mDL Data from the device.
  • The communication interfaces enable the parties to exchange information and assess if the mDL Data (1) was provisioned by a trusted source (the DMV), (2) belongs to the individual asserting it, and (3) was transmitted to and received by an agency unaltered.
  • ‘Remote’’ provisioning, in contrast, does not require an individual to be physically present at a DMV location. Instead, individuals would electronically send identity verification information to the DMV to establish their identities and ownership of the target device.
  • Off-line comms needs more detail: NFC QR BLE or WiFi Aware.
  • Federal agencies cannot accept an mDL unless the agency can authenticate the identity information. This means confidence that the mDL Data came from a trusted source (the DMV), and the mDL Data was transmitted to the agency unaltered.
  • Reg establishes such ‘‘trust’’ by requiring physical DL/IDs to include physical security features on the surface of a card that are designed to deter and detect forgery and counterfeiting. As mDLs lack a physical form they cannot overtly display physical security features. Therefore, regulatory requirements for physical security features on a physical substrate need to be updated to establish comparable mDL-specific security features.
  • an mDL can be verified via two methods:
  1. Attended verification requires the physical presence of an attendant to supervise the mDL transaction.
  2. unattended verification is performed algorithmically without the presence of an attendant. Draft standard 18013–5 sets forth requirements specifically for attended verification, but does not address the unattended online model (but DHS understands this may be the subject of a future ISO/IEC project).

Responses to RFC

Preamble to the response:

This response to the DHS RFC for mobile Driver's links addresses the issues in the 18013-5 document and the other topic below that are not addressed in that document.

  1. The issuing authority should ensure that the mDL:
    1. remains in control of that mDL holder throughout the lifetime of the credential;
    2. protects the credential and the mDL data;
    3. can only be used by the mDL holder or with the consent of the mDL holder;
    4. meets the mDL verifier’s needs for Authentication Assurance particular to their region.
    5. gets informed consent from the mDL holder to share data.
  2. requirements on storage of mDL data and mDL private keys.
  3. The interaction of an issuing authority with a federal government.

Here are the 15 questions from the RFC in the order requested.

1 Security generally

what security risks, including data interception, alteration, and reproduction, may arise from the use of mDLs by Federal agencies. These are the kinds of vulnerabilities that have been identified for mDL.

  • A feature to detect, deter and mitigate risk - test wallets - trust registry for wallet, reader and issuer
  • B new threat vectors
    • Attacker with complete control of smartphone and wallet. They may be able to infer DHS intent by the nature of the request.
    • Mitigations from strong threat analyses at every step from architecture to deployments and updates will avoid many difficulties later. (see numbered list following.)
  • C physical security - The wallet can present the MAAS doc + proof of presence to reader + Only NFC should be enabled for ANY federal purposes, BLE is too broad.
    • user gesture from the phone is required before PII data flows
    • driver's ID or other PII must be an unusual request as defined in an appropriate authentication profile for that site
  1. Issuer private keys are compromised when the wallet (mDL holder) is not secure. There is no current plan to even test deployed wallets. The attacker can get the mDL on a device that they have root access with software storage for the holder's (their) key which they can use to manipulate the results anyway they desire.
  2. Spoofing
    1. that is where the attacker can authenticate using another’s mDL data.
    2. It can also be that the verifier spoofs a known site the user trusts.
    3. Somehow the trust registries need to be made known to the verifier and perhaps to the user.
  3. Information Disclosure - or loss of privacy.
  4. Linking (a form of disclosure where one set of attributes are aggregated to the point where the real-world user is identified.) ( Not sure if this is in scope - we can decide later when we have more content and can remove it at that point.)
  5. Repudiation - where a user is able to deny having provided the information. (We may decide to pass on this vulnerability - we can decide later.)
  6. Denial of Service - where a user is unable to access the resource desired. Note that this includes both intentional and unintentional outages and could be considered to be a reliability issue. (We may decide out-of-scope.)
    1. If the DoS attack is on the notification channel, then the attacker can block messages that would warn the user of attacks.
  7. Tampering - where an attacker is able to change the data in-flight.
    1. This can be just a form of Denial of Service, or
    2. This can result in spoofing one of the attributes, like age.
  8. Supply chain attacks can include devices sold by the attacker for amazingly low prices specifically designed to siphon off user private keys and mDL data for their use.
    1. Foreign governments, like China, can force manufacturers to install attack software as part of the deployed device.
    2. Telcos are easy to establish and have large control over the security of devices deployed on their networks.
  9. Attacks directed against the smartphone holder directly are now possible.
    1. Consider the Havana syndrome (Are U.S. Officials under silent Attack? New Yorker (2021-05-31) https://www.newyorker.com/magazine/2021/05/31/are-us-officials-under-silent-attack).
    2. Also the holder's other information on the smartphone can be targeted by a deceitful app.

2 Privacy generally

what privacy concerns or benefits may arise from mDL transactions, and how DHS should address those in the REAL ID context.

  • Reader can ask for all user data under false pretenses - reader can be attacker - issuer can collect behavior of user in the real world by where mDL is used.
  • PII Data on a open channel must be encrypted, access to the keying material must be protected.
  • Any party to the transaction, most specifically the U.S. government can track users if there are many instances where an ID is requested.
  • Propose a taxonomy of purpose codes that could be understood by the user and limit data transfer (FIC calls this "Data Minimization Agreed by Use Case".)
  • Research on the User Experience of the privacy of their data is important. There is an on-going experience with current roll-outs. These experiments need to be mined for both good and bad user experiences.
  • User notifications of consents and breaches need to be honest and timely to maintain user trust in the product. In many cases the user understanding of the trust level will be more important than the reality.
  • BLE and Wifi used for device initiation can be used to track the physical location of that device over time. A sufficiently long path can be used to identify an individual person.
  1. The verifier is presumed to be unworthy to access user data until it is recognized by the user’s device.
    1. The user may decide which verifiers are trusted. It would be helpful to the user to not need to make this choice more than once so that they do not experience cognitive overload and automatically accept any site asking.
    2. The verifier can be spoofing a well known vendor and should themselves be properly verified, which is why the user’s device needs to know which trust registries are trustworthy.
    3. The verifier may have emergency powers to access user data. These types of accesses are situational in that the requester must be able to prove the role that they have at the time of the request.
      1. Law officers on duty.
      2. Paramedics (or physicians) on duty.
      3. Various branches of DHS: FEMA, ICE, TSA, etc.
  2. The initial interaction between the mDL and the verifier is unencrypted and potentially could leak data.
  3. The storage of the mDL on the smartphone is not secure and other apps can get access to the data unless it is encrypted-at-rest.
  4. The data link between the smartphone and verifier can be intercepted. Encryption-in-motion is called for in the standard.
  5. The verifier maintains all the data sent to it against applicable privacy guidelines.
  6. The verifier uses holder data without informed consent (e.g. facial recognition)
  7. Data at the verifier site is not secure and is breached.
  8. The verifier inappropriately shares user private data.
  9. The verifier asks for more user data than is situationally required.
    1. The verifier must be able to understand what the profile is that is appropriate.
    2. One way would be for a set of standard profiles to be created and deployed.
    3. That would make it easier for the agency to get the right set of data for the situation.
  10. The person in possession and presenting the mDL is not the subject. (Or, in other words, the physical holder of the device is not the "holder" of the DL.)
  11. The rights granted to the subject using the mDL are improperly diverted (e.g. drugs or alcohol).
  12. Profiling of the user by the issuing authority is not in scope of the spec, but should be at least addressed by federal regulations. For example, if every access of the database by a police officer were recorded, the behavior of the holder could be incorrectly inferred or used against the holder. This weakness could be mitigated by the use of a trusted third party that would validate all requests by verifiers and pass them anonymously to the issuing authority to assure that the license was still valid. The actual validity of the license MUST not be released to any location other thay traffic officers and courts. This point does NOT apply to the expiry date on a certificate or license document.

3 Industry Standards

Any industry standards should be chosen describe how DHS should choose the standards, and the appropriate baseline to impose.

  • This is a MUST ANSWER for Kantara and for OIDF!
  1. Mobile Authentication Assurance Statement
  2. OpenID Connect
  3. Proof of human presence is required - level of liveness must be addressed (tbd and may be part of authentication profile)

4 ISO 18013-5 Interface to Feds

Evaluate current and future developments where the Feds operate as a reader.

  • A Current standards do not have all of the components necessary for adopt by the Feds. More is needed and can be provided by existing open standards orgs. The 18013-5 spec for OIDC seems to be focused on small businesses. The connections between the Feds and the state issuers needs to be highband width and resilient. Mutipath connections and even local caching should be consider if consistent with U.S. privacy regulations. There is some concern about tracking the user.
  • B If the standards for interaction with the Feds do not exist a great cacophony interchanges among wallets and readers will complicate any broad deployment.
  • C Costs for implementers will be high an recurring if the Feds requirements are not known soon. A common standard will promote a market in low cost solutions.
  • D The security of the wallet from malicious users could be a gigantic burden unless control of wallet security attestations is in place. The sooner the better.
  • E The model of the First Net application approval process should be examined and the best parts replicated in mDL wallets for the holders.

5 ISO 23220-3 Communication Interface Between DMV and mDL Device

Evaluate current and future developments.

  • Industry engagement in this effort has not been good and the process is opaque to those not involved.
  • We recommend an US/Canada effort to establish needs in a Federal government environment.

Question parts:

  • A Maturity of existing stds - no known implementations. Preference would be for open source development process.
  • B Alternatives are not known - we could lean on AAMVA and FIC for guidance.

6 Provisioning

both in-person and remotely.

  • A In person provisioning creates the potential for the DMV personnel to become a help desk for app loading into the phone of people who have never done it before. When done remotely the process is fraught with vulnerabilities that could be exploited by attackers with dubious apps. Some apps will be expelled by the app stores, but still have the potential to cause a create deal of havoc before their are discovered and expelled.
  • B security protocols must, at the very least, determine who the owner of the phone is and then if that is the same as the holder of the mDL. For some elderly folk, it could well be a grandchild, or phone store person that is installing and enabling the app. The person could leak holder information in many unexpected ways.
  • C The messages from the wallets MUST include: MAAS + POP
  • D Estimated costs for DMV on provisioning. In person could be high and does not address user changing phone. On App store provision cost is low, but user support costs would be high and continuing, but spiking during roll-out. Without good support success is not likely. DHS should consider a support line and a means for user's to test their wallet before heading to the airport or nuclear facility.

7 Storage of mDL on device

Both h/w and s/w implementations need to be considered, perhaps several levels of assurance, for example:

  1. Access to driving or other state controlled sites (Medicare, fishing licenses, etc.) - s/w ok
  2. Access to airport security, access to controlled drugs (REAL ID) - h/w required for private key and signing operation.
  3. Access to nuclear power plant - DHS approved device and software required with protection of all credentials in or by h/w.

8 Data freshness

is data current - sure let's do it. But condition the requirements for data freshness on the level of assurance required (see above list of levels.)

9 IT Security Infrastructure

Is PKI sufficient. Is there an alternative (like VCs and DIDs) Consider costs.

  • A describe https://trustregistry.org/ and the list of items that could be included in any trust authority.
  • A1 - talk about VC and the need for a mature implementation before it would even be possible to run a test.
  • B Cost for a DMV or Federal Agency to implement IT security. Specifically mention other vendors that are known to be trusted like Kantara/FIC or one of the existing CAs. It would be much more likely to be ready on time than a government provisioned site.

10 Alternative IT Security Solutions

Also look at Vehicle-Vehicle interchanges and Healthcare prescriptions for controlled substances.

  • Combine with other efforts like TSA - describe travel and covid cert integration.
  • Open Banking
  • Healthcare using the Kanatara site - can share costs for the federal gov't
  • Pharmacies with sure scripts or HIE
  • Existing Kiosks for 18013-1 retrofitted for 18013-5
  • V2V or D2D - can one wallet talk to another - like didcomm - describe that?

11 Offline and Online Data Transfer Modes

mitigate security and privacy risks

  • A offline security and privacy risks
  • A online security and privacy risks
  • B offline mitigation
  • B online mitigation

12 Unattended Online mDL Verifications

how can DMVs help mitigation of threats introduced by unattended operation.

  • A It's easier to explain what is gained by attendant's and see if alternates are available without them. The biggest advantage is biometric matching, but that works well if the smartphone is trusted. Looking at the levels of assurance (above) unattended operation might depend on a higher level of assurance about the smartphone and app.
  • B The basic security protocol needed for secure unattended operation is a proof of possession of a h/w protected key, or proof of presence of the user at the phone.

13 Costs to individuals

time, effort and money. Consider other uses - (like Medicaid, fishing licenses)

  • A Time and effort
  • B Fees at DMV
  • C Changes needed for additional attributes/endorsements (Donor, HAZMAT, hunting, vehicle licenses (car/trailer/boat)

14 Considerations for mDL Devices Other than Smartphones

  • smartwatch (maybe home healthcare?)
  • If 18013-5 is extended to cover the car's license plate, should the car respond to a request for a license plate number

15 Obstacles to acceptance

(Education, Accessibility, disenfranchised and Inclusion)

  • Bad experiences by users, even news reports of other's bad experiences, will cause new users to stay away.
  • There appears to be a general distrust building in the US to government over-reach with misinformation on the web feeding that distrust. Early attention to bad experiences needs to be part of the plan when the project begins roll-out.
  • Reliance on education to avoid security or privacy problems never works well, but education for improved user experience with the device is helpful. The virtues of fast access for example.
  • Monitoring for "bad-actors" and swift action to eliminate therets will provide comfort that the government has the people's interest at heart.
  • Engaging with other user's of the mDL can make adoption better and can provide a path to user reactions that can be used for quick action to fix issues or dispel doubts.
  • The proliferation of conflicting state laws and lack of federal guidance will make a common user experience difficult. The constitution requires that "Full faith and Credit shall be give in each State to the public Acts, Records and judicial Proceedings of every other State. And the Congress may by general Laws prescribe the Manner in which such Acts, Records and Proceeding shall be proved and the Effect thereof."

Assessment Methodologies

List in no particular order

  • Black box testing
  • Fuzz testing
  • Management commitment to Code of Conduct
  • Check list - for example the HIPAA Compliance Checklist
  • Supply chain validation
  • Development methodologies
  • Bug tracking & triage criteria
  • User experience, especially the selection of good security and privacy practices
  • Notification (Consent and Breaches)

Input

Ideas collected from the Kantara team that need to be addressed somewhere in the responses.

  • Impact to ONC Trust Registry proposal
  • How do we know the cert applies only to the code that was actually run?
  • Identity Assurance levels (is this implicit in the REAL ID, or is it required in all presentations)
  • Authentication Assurance levels from the device or proof of presence of thee holder (could be biometric)
  • Does the holder private key need to be protected by hardware (Secure Enclave)?
  • Should there be a (1) device (IME) number, (2) s/w instance registration number, or (3) instance private key? That would allow the s/w to sign on its own behalf but would add privacy concerns.
  • The FHIR spec has a Safety Check List which include patient privacy and data sensitivity and well as consistency issues.
  • Redress & Recovery (including key and ID roll-over)
  • Resilience (will this continue to work in all weather on all roads in the US and Canada)
  • Access by Government officials (Sovereign access (copy on the road, access to gov't buildings & TSA)
  • Privacy by sovereign entities selling our data
  • Selective release of inappropriate data - needs to be based on requirements
  • Canonical list of data by access types (in car, public health, ...) is this in scope?
  • Can there be a national credential (from state to state)
  • Other stuff - car insurance, registration, etc.
  • Guardianship & delegation (particularly if different states involved)
  • Culture (en-US) gilt - globalization internationalization localization translation
  • Jurisdiction
  • Inclusion Accessibility
  • NLETS - FirstNet
  • Donor card
  • Other uses - Medicaid, firearms, 22 types of ID in WA state.
  • Professional licenses - including access to prescribing
  • VC and DIDs
  • Attribute updates
  • Alternate identities
  • Compliance with CCPA, FTC, user consent (intention)
  • Purpose of use must not expand w/o permission
  • Sensitivity of data attributes
  • Who owns data, who controls data, can it be made into a right (is the State DMV even in scope for this response?)
  • Rights seem to evolve - privacy & right to be forgotten and extended on to property rights for ID data access
  • Are notification of changes or breaches in scope?

References

Retrieved from "https://wiki.idesg.org/index.php?title=Mobile_Driver%27s_License_Criteria&oldid=16101"