Get ready for the next part of the blog series "Is the Future of Identification Digital? Exploring the Potential of Mobile Driver License (mDL) Technology." Don't miss out on part 1 - it's a must-read!
In this blog, you will gain a thorough understanding of the following:
- How an mDL is securely provisioned and stored on your smartphone.
- How to use it to verify your identity.
Provisioning Process
There are two ways to set up mDL on your phone: at the DMV or remotely. This article covers the remote provisioning process:
Step 1: Initiate Enrollment: The user starts the process by downloading an official state mDL app provided by the issuing authority (e.g., DMV). The steps below might differ slightly for Apple, Google, or Samsung wallets.
Step 2: Identity Verification: The user must verify their identity, usually by providing personal information, taking a live selfie, and scanning their physical driver's license using the phone’s camera. Some systems may require additional verification, such as answering security questions or providing extra documentation.
Step 3: Back-End Verification: The issuing authority's system verifies the submitted information against their records.
Step 4: Secure Transmission: Once the identity is verified, the issuing authority begins the provisioning process, where it signs the mDL data (e.g., name, date of birth, license number, address, photo) with its private key. The digital signature (hash) serves as a unique fingerprint of the data, ensuring that even a tiny change in the mDL data would invalidate the signature, thus providing the integrity of the mDL data. This hash (signature) and mDL data bundle is then securely transmitted to the user’s device.
Step 5: Encrypted Data Storage: If there is one lesson that we can borrow from securing the data on credit cards is that the mDL data must be securely stored on a device (source: Identity Week 2024). Several ways could be employed to protect sensitive data from unauthorized access:
Option 1: Secure Enclave/Secure Element: A Secure Enclave (for Apple devices) or Secure Element (for Android devices) is a dedicated hardware-based security component within a mobile device. It operates independently from the central processor and provides high security for storing sensitive information.
Benefits: 1) This ensures that even if the central operating system is compromised, the data within the Secure Enclave or Secure Element remains protected. 2) Only authorized applications (like the mDL app) can interact with the stored data.
Option 2: UICC (commonly known as SIM): UICCs are equipped with secure elements (SEs) that provide hardware-level security modules (HSM) for storing sensitive data, making them ideal for personal identity information like mDLs.
Benefits: 1) UICCs are compatible with ISO/IEC standards for personal identity, like ISO/IEC 18013-5 for mDL, ensuring interoperability across regions and devices (users can maintain their mDL data when switching smartphones without needing to transfer the information manually) 2) can be programmed to restrict access to the mDL data only under specific conditions (such as biometric authentication or password entry), ensuring the data isn't easily compromised 3) can also be remotely updated or revoked, adding flexibility for authorities in managing mDL information.
Option 3: Encrypted Storage: If the device does not have a Secure Enclave or Secure Element, the mDL data may be stored in an encrypted format within the device's general storage.
Option 4: Application Sandboxing: Mobile operating systems like iOS and Android employ a sandboxing model, where each app runs in its isolated environment with limited access to the rest of the system.
mDLs employ additional measures to ensure the security of the mDL data:
Device Integrity Checks: The app can regularly validate the digital signatures and hashes of the stored mDL data to ensure that the device is not compromised (e.g., by malware or rooting). If any discrepancies are found, the app may alert the user or invalidate the mDL until it can be reissued
Remote Wipe: If a device with an mDL is lost or stolen, the issuing authority or the user may be able to wipe the mDL data from the device remotely.
Tamper-Evident Design: The mDL app and data are designed to be tamper-resistant. Any unauthorized attempt to alter the mDL data or the app will be detected, and the app may automatically invalidate the mDL or alert the user.
Audit Trails and Logging: The mDL system can maintain audit logs of all access and updates, providing a trail that can be reviewed in case of suspected fraud or misuse. Users can often view their usage history, seeing when and where their mDL was used.
Verification Process
Step 1: Request Initiation: When a verifier (e.g., law enforcement store clerk) needs to verify the mDL, they initiate a request to the mDL holder's device. This can be done via scanning a QR code, NFC, Bluetooth, or another secure communication method.
QR-code initiated verification: Verifier can generate a QR code that Holder can scan with their mobile device
Holder scanning QR from Verifier's website for authentication and/or pre-filling an application with Holder's mDL data
Holder scanning QR-code displayed on Verifier's mDL app (free for businesses; no hardware required esp. for small businesses)
NFC initiated verification: Holder can tap their device on a physical mDL Reader to begin the process
Step 2: Binding mDL app to the Owner: Access to the mDL app on the user's device often requires strong authentication, such as biometrics (fingerprint or facial recognition), PINs, or passwords. This ensures that only the authorized user can access their mDL.
Step 3: Cross-Device Communication: After scanning the QR code, a communication channel between the mDL holder's device and the verifier is established and is typically secured using TLS, ensuring that the data exchanged is encrypted and protected from eavesdropping or tampering.
Step 4: Mutual Authentication: Before any data exchange occurs, the mDL app and the verifying party (e.g., a law enforcement officer's device) can authenticate each other to confirm that both parties are legitimate and trusted. This process prevents man-in-the-middle attacks where an attacker might attempt to intercept and alter the data during transmission. This way, the mDL app can ensure that a trusted mDL Reader requested before the app transmits mDL data to the Reader.
Step 5: Request for the mDL Data: After the mutual authentication is complete, mDL Reader asks for data depending upon the use-case. For instance, a liquor store can request for the age about 21 evidence or a content-sensitive website can request for a minor check per the screenshot below:
Step 6: Selective Disclosure: The mDL allows users to share only the necessary data for authentication. For example, if the website only needs to confirm the user's age, the mDL can share that specific information without revealing the entire driver's license details.
Step 7: Data Transmission: The mDL holder’s device sends the requested data, including the digital signature, to the verifier.
Step 8: Verification by the Verifier: The verifier retrieves the issuing authority's public key, which is either stored locally in their system (offline retrieval - interface defined by the ISO 18013-5 standard) or fetched from a trusted public key repository (online retrieval - will be defined by ISO 18013-7 standard). This trusted key is necessary to validate the digital signature. The verifier’s system then uses this public key from a trusted Issuing Authority to decrypt the digital signature and compare it against a hash of the received mDL data. If the signature matches the hash, it confirms that the issuing authority signed the data and has not been altered since it was signed (data integrity check).
Step 9: Final Verification and Use: The mDL holder's identity or specific credential (e.g., age, driving privileges) is then confirmed. Based on the verified information, the verifier can proceed with the necessary action (e.g., allowing entry, completing a transaction, or conducting a traffic stop).
This cryptographic authentication ensures that the mDL is legitimate, the data hasn’t been altered, and the holder is indeed who they claim to be, all while protecting the user’s privacy.
Additional resources:
mDL provisioning process - CA DMV video
mDL verification process - CA DMV video
https://www.nccoe.nist.gov/projects/digital-identities-mdlhttps://www.nccoe.nist.gov/projects/digital-identities-mdl
Disclaimers
I truly appreciate your understanding that the content is based on my secondary research.
Although the blog contains detailed information on several concepts, I have deliberately presented the content at a high level to ensure that it is easily comprehensible to everyone without compromising its accuracy.
Your feedback is invaluable, so please do not hesitate to share your comments if you come across any inconsistencies in the content.
Additionally, the images featured in the blog are original and are the exclusive property of my company, Demystify Biometrics.
To ensure the information's accuracy and tone, AI-based tools have been utilized for research and content refinement. Your support and understanding mean a lot—thank you for being part of this journey.
Kommentare