Dangerous Conditions Ahead: Navigating Security Issues in Mobile Identity

We’ve relied on our ability to identify people and things for hundreds of thousands of years, since the beginning of our species and before. The way you look, the way you behave, the way you communicate – all the things that make you intrinsically you – are used by others to identify you. Once you’re identified you may be trusted, or indeed you may be determined as an individual to be not trusted. But the identification itself must come first.

This only works when there is a pre-existing relationship that can be leveraged to gain the knowledge used to provide the identification, of course. When you need to identify yourself to someone else, someone you have never met, we’ve historically relied on documents, pictures, details and information about you and your background. People would travel with letters of introduction, or even another person – literally a trusted third party – to help identify themselves to others.

Nowadays, the world most people live and work in is much larger, more complex, and interconnected so we’ve created institutions and services which can act as these trusted 3rd parties to identify individuals or endorse proxy documents to do this in their stead. Passports and driver's licenses are examples of these types of proxy identification documents, providing utility as general-purpose identification systems, essentially extending their purpose beyond their initial remit. Until recently these types of identification systems have been entirely physical – very much just updated versions of ye olde letter of introduction.

However, this type of purely physical system can often be easily replicated, and we’ve seen over the course of the last decade or so the introduction of electronic passports and drivers licenses that combine the physical security features of a traditional passport with logical security features such as cryptographic signatures and internal processing. Now, we’re moving into a world of commoditization – of payments, of technology, and of identity – and this is resulting in our documents becoming digitized into mobile implementations as well.

In this post, I’ll be talking specifically about mobile driver's licenses (mDL) - what it is, how it works, and what it means for those both using them and looking to deploy them. At the time of writing the ISO standard for mDL (ISO18013-5) is not quite out yet, but UL has been a key participant and contributor to the ISO working group for some time now. Through this, and the work we’ve been doing with some of the early adopters of mDL, we have some unique context and experiences that we can share.

mDL – the TL;DR version

So what is a ‘mobile’ driver's license, and how does it work? Well, it’s not necessarily the same as the licenses you are used to … Traditional drivers' licenses rely on the physical implementation to provide security, through holograms on the plastic, specific picture overlays, maybe even a physical chip in the card, etc. These can be validated by the person checking the ID, helping to prevent forgeries and modifications.

A mobile driver's license, by contrast, is a digital version of these physical identification documents; stored and implemented on a Commercial Off the Shelf (COTS) system such as a mobile phone – hence the ‘m’ in mDL. Because a mobile license has no physical aspect, and it cannot rely on physical security features. Instead of using a person viewing the physicality of the license to authenticate it, an mDL must rely on the use of a separate ‘reader’ that connects to the mDL instance to authenticate the logical aspects of the implementation.

Connections can be made through various technologies – NFC, BLE, WiFi, optical, etc – and have cryptography applied to maintain privacy and authenticity of the data communicated.

I know you. I know all about you

We’ve already noted that identification can only work when there’s a pre-existing relationship or some trusted third party, and in the case of your physical driver's license this is your local version of the Department of Motor Vehicles, some government agency empowered with validating that:

1. You are able to drive a motor vehicle to local standards.
2. You are who you say you are.

This is generally done in person, with you turning up and providing other documents such as a birth certificate and sitting some form of test to validate your competency. However, with one of the often-touted advantages of mDL being that it can be remotely deployed – without visiting the DMV – how is the foundational challenge of Identification and Verification (ID&V) solved?

When an mDL is able to be commissioned remotely, it must rely on the presence of an existing physical license to act as the root of trust for the user identification. The user generally takes a photo of this existing license with their phone, then a ‘selfie’ picture as proof of their own identity, and both of these are used to confirm the validity of the existing license and the ownership of that license by the current user of the mobile phone.

Of course, the security implemented in this stage is very important, as this is establishing the owner of all data that will be subsequently provisioned to the mobile device. However, this stage is deliberately not covered by the current ISO standard for mobile driver's licenses as it is coming in a new standard to be worked on over the next few years – ISO 23220.

This current lack of clarity around issuance and provisioning of mobile licenses provides flexibility for implementations, but it does also bring with it complexity and risk as well. Most fraud in mobile payments occurs in the digitization phase, with criminals bypassing poorly implemented controls in the identification and verification stage. When deploying mobile drivers license implementations, how security around how this identification and verification is implemented, the efficacy of any biometric matching used, the use of metadata such as geolocation, the way in which fallback or scale-up mechanisms are implemented when the technology fails or risks are considered too high for automated matching – all of these things (and more!) must be carefully thought out and tested.

A scanner darkly

In the previous section, I noted that validating a mobile driver's license requires the use of a reader. Sure, you can just ‘look’ at such a license and you will see what amounts to a picture of a traditional physical license. However, such an image is just that – an image. Even with additional security, such as moving pictures of the driver, motion, or distortion effects implemented when the license picture is touched, the validity of a mobile license can really only be confirmed when using a separate reader component or system.

Here, a parallel can be drawn with payments again. When you use a payment card, that card is not validated through only physical means anymore – data on the card magnetic stripe, or data on the internal card chip, are used to allow the card to be validated by other parties (the terminal, the acquirer, the Issuer). This is because the physical aspects of payment cards are easy to ‘clone’ or copy so simply physically examining the card itself is insufficient. Even checking purely static data, such as that on the magnetic stripe on a card or machine-readable barcodes, is often not sufficient as this can also be easily copied from one card to another.

In the same way, we have payment terminals to read and validate data on payment cards, we need mDL readers to do the same for mobile drivers licenses. Does this constrain the utility of an mDL as opposed to a traditional license? Perhaps, in some ways – but it can also make them more secure. The challenge is in implementing the reading systems in the most easily deployed and interoperable way, perhaps by exposing web-based APIs or free-to-download apps for common mobile operating systems.

An illustration of the high-level components and connections of an mDL system is provided below.

It is important that the security of these reading and backend systems is also validated to ensure that the whole ecosystem is correctly and securely set up. It is likely that you may want to have different reader types for different levels of assurance; if an mDL is being checked for age validation at a movie theater, this is clearly a different risk profile than if it is being checked at a border crossing or police check. The readers implemented may similarly provide different levels of assurance and security to the actual reading process, for example, it’s likely the police will want a dedicated system of license validation or that you will want to have additional checks on the COTS systems being used by such organizations if dedicated readers are not used.

Education on how to correctly use and validate an mDL is important too; you don’t want people using just an image of an mDL for ID when setting up a banking account, for example!

Shhh … It’s a secret!

Using a COTS device to provide the base for mobile driver's license functions is a great way to ensure maximum coverage of the technology, but it does pose complications when it comes to the security of the data and processing used by both the mDL and any COTS-based readers. During the identification and verification stage, the license holder identifies themselves to the driving authority backend and is assigned (“provisioned”) some specific data to help uniquely identify that COTS device and bind the application instance to the identity of the user. Without protection this data could be copied to another phone, essentially replicating or ‘cloning’ the mobile license. Worse, it could be modified in transit or storage, before use, showing a person as being older than they actually are or with additional driving privileges they do not actually have.

Now, don’t get me wrong, the security of modern COTS operating systems is actually really good. A fully patched and up-to-date Android or iOS device is one of the most secure commercial products you can buy. However, for mDL deployment, you are probably not going to want to limit the scope to only the most recent and fully patched devices, as this will significantly limit the scope of deployment. See the graph below on Android version distribution over time (collected from the Google Android distribution website https://developer.android.com/about/dashboards and beautifully rendered in this graph below at https://www.bidouille.org/misc/androidcharts). This shows how long older versions of Android can stick around in the market, even though they may be several versions out of date.

The problem, of course, is you can’t support all of the historical versions because regardless of how secure a new or updated system may be when it is initially released, older and unpatched COTS devices, applications, or Operating Systems can be quite insecure …

So, decisions need to be made on what minimal level of device or operating system you will accept for deployment of your mDL implementation. Any such decision then also implies the need for periodic updates to the accepted COTS platforms, as what was previously considered acceptable becomes too old and insecure to use anymore as time continues to expose previously unknown vulnerabilities.

How are you going to make these decisions? How are you going to communicate to existing mobile license holders that they must either update their existing phone or have their mDL revoked? What level of security is required for your implementation and how are you going to validate that this is implemented correctly across all devices to which the mDL is deployed?

For example, will you require that the mDL isolates sensitive operations in a logically separate Trusted Execution Environment (TEE) or dedicated security processor, which will limit the type of devices supported and how they are deployed? Or are you happy with the application and data protected in the ‘rich’ operating system of Android or iOS, if you can ensure some level of security is still applied? How are you going to determine and validate that security level that must be applied, and what data do you have or should you use to help make that decision?

As with many things, there are choices to be made between scope, interoperability, and security and often this is a zero-sum game, where choices in one direction impact the choices you can make in another.

Does my backend look vulnerable in this?

Across the previous discussions on the use and security of mobile driver's licenses, we have discussed that the reader and the mDL itself connect to a backend system; but exactly how that it is implemented is left as a decision to the implementer. Often common security protocols such as TLS will be used, which is a good idea, but the exact configuration is just as important – what ciphersuites, what versions, how to manage certificates, etc?

In the last section, we discussed the security of the storage of provisioned data, and here we need to consider the security of communications, which also implies a bootstrap problem. If you are delivering the provisioning data to an mDL for the first time, it is essentially a ‘vanilla’ application – just like every other mDL application of that type that has been downloaded from the app store. Until the first step of the provisioning process, there’s no unique data to any application. How do you then identify and authenticate the application for initial provisioning to prevent ‘In-The-Middle’ attacks, where an attacker may sit between the genuine app and the backend to collect or modify the data sent? How do you identify the platform and system being used, the person requesting the license data?

As mobile operating systems are getting more secure with each version they are also increasing privacy controls by isolating and preventing the use of user or device-specific data. Somewhat ironically, this can complicate the application of security controls, with backend systems like attestation and monitoring controls often working better for older versions of operating systems than they do for the newer versions.

There are further complications when it comes to the security of the backend itself. How is the data protected where it is stored at this concentration point? What specific privacy requirements apply in the geography you will be deploying the mobile license system, and how does what you’re doing impact those beyond the traditional license data you are collecting (for example, how are any biometric matching systems maintained and controlled)? If you are using a third-party system, what have you done to validate the efficacy of their security setup?

Tokenising identity

The mobile driver's license standard allows for the delivery of a ‘tokenised’ identifier to be delivered to the reader so that the license data is not actually directly transferred from the mDL – instead, the reader uses the token as an authentication mechanism to request the license data to be retrieved directly by the reader from the backend systems. This can be useful when the data to be retrieved places an excessive burden on the data transfer medium (such as when using QR codes).

The use of tokens also allows for more flexibility in trust around the use of the reader; you may choose to increase the security of the system by requiring more authenticity checks of readers connecting with tokens. Alternatively, you may indeed decrease the level of security for readers when a token is used, as the token provides some implicit intent and time-bounding for the retrieval of that data. Your decision either way – for more security or less security when dealing with tokens – may depend on the type of token supplied and what data it is allowed to fetch.

How exactly you allow for this to be used is important. The use of tokens in mDL can absolutely make things more secure. Poorly implemented, they can also create entirely new issues.

Interoperability

Traditional driver's licenses can be used across many different geographies and jurisdictions, but because of the need for readers that can authenticate the cryptographic aspects of an mDL, there can be an interoperability issue when considering these for similar widespread use. To ensure that your licenses can be authenticated, you will need to share some common cryptographic framework or have a master root signing key that is used (or at least trusted) by a number of different geographies.

The ISO standard for mobile driver's licenses ensures that any arbitrary implementation (if designed to the standard) should be able to format data in a way that any arbitrary reader can interpret. However, the answer, as always, as you may by now have guessed, is not that simple. The ISO standard allows for different physical communication interfaces to be used (NFC, wifi, QR codes, etc), and so if a reader is designed for use with optical mDL implementations, but the mDL itself only communicates over Bluetooth, then they will not talk.

Anyone who has worked with standardization and interoperability will also know that standardized protocols can often be implemented incorrectly, or with different interpretations of the normative rules built into the standard. Testing of implementations is essential – you cannot just assume that any system will be able to work correctly in all situations. Perhaps less obviously, interoperability testing can also uncover security issues where data is handled or managed incorrectly, or where data that should otherwise remain private is leaked.

Online vs offline

One final aspect of mobile driver's licenses that must be considered is offline use. It is very reasonable to consider that a mobile device may be out of communication range when it is required for the mDL to be used. Perhaps the user's data allocation is all used up, perhaps they are in a building car park or dead-spot with no reception, or perhaps they have turned data off to save roaming or other charges. In any case, where connection with the backend is not possible, it is reasonable to expect that the mobile license will still be useable.

But does this impact the security of your implementation? It’s also reasonable to expect that a user can have their mDL transferred to another phone (in case of loss, upgrade, etc) – and now we must consider what happens if a phone is taken offline and then the same user installs their mDL onto another (online) phone? At this point, we have two completely valid copies of the mDL, the (old) offline version, and the (new) online version! An illustration of this process is provided below.

This is essentially an ‘easy’ method to clone any mDL instance. Of course, the correct picture of the original license holder is applied to each license, but this does make it easier for people to ‘share’ licenses between friends (I am sure that none of us have ever known people to do that so they could sneak their friends into bars and nightclubs have we?).

The specifics of how you implement your mDL use cases, user education, and deployment must consider methods to mitigate the impact of this type of cloning.

Better than plastic?

So, is a mobile driver's license really better and more secure than a physical one? Well, as with almost all things, it depends. It depends on the level of assurance you need in your system if the mDL is being used with a valid reader, what security controls are built into the implementation and the methods you have used to validate these. It depends on how secure your mDL applications and your mDL readers are, how secure your backend is, and how well you’ve set up your key management. It depends on how effectively you have educated people to use mDL instances properly, and how easy it is for them to put this education into effect.

To put it simply, when it comes to the security of mDL implementations your mileage may vary. At UL, we have been participating in the standardization and conformance testing of mDL implementations for years now, creating and validating threat models and test plans, and helping educate people on both the risks and opportunities. Using a final car analogy, we’ve been around this block a few times already.

Let us help to show you the way.