Is it possible to verify device identity transparently?

Question

To what extent can we verify the identity of a particular mobile device, over NFC, in an entirely transparent manner?

Consider the following situation: A large organization currently handles access control with ID cards, which must be scanned for entrance into protected areas. However, for various reasons, they desire to move ID verification to a phone-based system. Individuals would scan their phones, using NFC, to verify their identities. (Yes, there are many drawbacks to this approach, along with some benefits. For the purposes of this question, please assume that the transition is inevitable.) Furthermore, the organization wishes to only allow each member exactly one device for identification. It should be prohibitively difficult to spoof the identity of one device with another device, even for the owner of both devices. Put another way, it should be nearly impossible to duplicate one ID across devices.

With proprietary software, this is somewhat possible, as the organization can install keys that are unknown even to the individual user, and/or force the phone to generate its certificate based on its own IMEI. But what about in open-source software? It seems that any private key could just be duplicated to other devices, and IMEI's could just be copied over. Yet, as an end user, I would much prefer having an open-source security option on my personal device than proprietary software managed by the organization.

The best idea I've come up with, so far, was to sign each unique identification attempt with the private key of the device's SIM card. As far as I know, that private key is difficult to access and sufficiently unique to each device (or, at least, to each SIM card). Yet, I don't know enough about mobile programming to say whether custom apps could easily get the SIM card to sign something. Additionally, I understand that a program could forward the identification request from a secondary device to the original device, then return the signature back to the NFC reader, though perhaps making the sign-in attempt time-sensitive could help that to some extent.

So, in a nutshell, is there any way to easily verify a device's identity in an entirely open-source, transparent manner?

Additionally, if there is any open-source software already available for this, I'd love to hear about it.

If this question is better for security.stackexchange.com, please let me know; I'd be happy to move it over. Many thanks.

Edit: If not the SIM card, I'd love to hear alternative ideas. For example, I considered sending a text to the device for each authentication, but the time delay and reception requirement would be prohibitive.

Edit 2: Yet another option might be to use the secure element of the NFC chip itself. Is it easy to get the NFC chip to identify and cryptographically verify itself to the reader (e.g., by signing a prompt from the reader)?

Edit 3: For context, this is a university setting, and the end-users are students. They already have NFC student ID cards, but they've been lending them out, against university policy. The university wants to move to a phone-based system to keep them from masquerading as each other as often (yes, it will still happen, but it will likely be less common, as people like to keep their phones close). Consequently, they want the identification/verification information locked to one device. I am curious whether this could even possibly be done in an open-source way, as I wouldn't want my university installing a proprietary app on my phone. Biometrics are similarly a too-invasive option, for my taste. It's an odd situation, to be sure. I'd personally prefer to stick with ID cards, but if the university is moving this way, I want to see if it can be done non-invasively and transparently.

Final edit: Thank you to all for your useful answers! I selected the answer that I believe best aligns with open-source principles while providing a practical solution. Now to make an open-source HSM company.... Thanks again!

Answer 1

I'm not sure why you're making this about some exotic phone identification. Android keystore can generate key material the user does not know or have access to the private portion of. This is probably best served if the key material is a public/private key pair of your choice.

• The user submits the public key as a part of their profile
• When authenticating to a system the app can take a challenge value or the current time and sign it.
• The verifier takes the user id, grabs their public key and verifies the signature.

Private keys in the android keystore, if not by default, I think can be set to refuse to be exported. ie it cannot be copied. This is not fool proof as a rooted device may get access to keystores. If you solution is deeply concerned about copying it should only accept devices with TrustZone/HSM as this gives hardware assurances the keys cannot be copied. Keys generated in this way (especially by TrustZone/HSM) are tied to the device.

Android implementation is open source to a point. TrustZone implementations are less open but generally only represent common cryptographic primitives when used from the context of keystore operations. With enough work one could in theory build a TrustZone app and open source it I guess. If the underlying key is stored in a secure way and is ideally bound to the hardware no amount of reading the source code will help any nefarious user.

You have similar assurances in iOS key management but a lot less openness in it's operation.

Answer 2

It seems to me that the place to start is the FSF's thoughts on Digital Restrictions Management, which note:

Then came Treacherous Computing, promoted as “Trusted Computing,” meaning that companies can “trust” your computer to obey them instead of you.

Once of the key aspects of free software is that free devices obey their owners, not their programmers. That means that you must not put the secrets that permit the user access onto the user's device, if that device is running only free software; you will not be able to prevent the user from exfiltrating them if you do. Basically, if the user can trust their device, you can't trust it, and vice-versa.

That does not mean that you can't build a secure system around free software, only that it will at some point also involve a device owned by the owner of the secrets, which interacts with external systems through open, published protocols in order to allow the user's free software to use the secrets therein without exposure of those secrets. In all such setups, the identification chain passes through the user's free devices but terminates in a device owned by the party whose secrets it houses.

SIM cards are a perfect example of this; they are devices owned and supplied by the GSM network operators, preloaded with secrets known only to those operators, but which (at least in my case) can allow the free software running on my phone to use those secrets to authenticate to the GSM network without my ever knowing those secrets.

The problem for you is that you don't know those secrets either, and the network operators won't tell you, so you can't base your security system on them. If you mandated dual-SIM phones for your users, you might be able to base an open system on the crypto operations of the second SIM, which SIMs you would have to program and distribute to your users. Other than that, I don't think general-purpose free phones have support for crypto HSMs, so you're onto a two-device solution, which will be operationally messy.

Answer 3

In order to answer your indirect question of "what's the best way to do this using a mobile phone", I think it's important to understand why you're wanting to make this transition in the first place. Presumably your current system has some shortcoming, and it's hard to recommend a specific solution without knowing exactly what problem this overall effort is trying to solve. For that reason my answer is fairly generic.

As MadHatter wrote, your crypto secret would have to be stored somewhere where the free software could never access it. Free software means the user could replace it with a modified version that allowed them to back up their credentials. Even proprietary software can't guarantee the secret doesn't get duplicated, since rooting a phone gives you a lot of access to hook into a program's internals and alter its behavior. This probably means means you'll need a secret that's stored in a hardware security token of some sort.

SIM cards can be cloned, and the NSA and GCHQ have famously intercepted them at the factory and cataloged their private keys so that they can decrypt and listen in on mobile phone conversations. Even if your threat model doesn't include nation-state threats, those SIM databases can get stolen and published. Many of the encryption methods used by SIM cards have been broken (or at least weakened). There's not a good way to authenticate against the NFC chip itself, programmable NFC chips exist and it's not difficult to program one to spoof another. Specialty chips that do that sort of thing might exist, but not in commodity phone hardware. Every piece of hardware identification that I know of on a mobile phone can be spoofed in one way or another.

I think the safest thing is to store your crypto secrets in is a hardware security token, like a USB dongle. That meets your security requirements, but likely locks you into using the vendor's proprietary software (and hoping that their software supports all your devices). Not to mention, they make security keys that support NFC, so adding the phone into the equation is just extra complication for no benefit. At that point your NFC-enabled security dongle is just a more expensive, more complicated version of your existing security cards, so this isn't necessarily an improvement.

Based on your description, you already have cards that meet all your security requirements. It seems like the path of least resistance would be to put your access card between your phone and your phone case (or get a case with a card slot on the back). You get all the security of the existing device, and access is still a simple tap of the phone. Not to mention, a solution like that would solve a laundry list of other issues: phone doesn't support NFC, battery is dead, got a new phone, users don't like the extra hassle of turning NFC on and off every time they go through a door, doesn't work on protected areas where mobile devices are prohibited, etc. There's a reason those NFC cards are so popular. They're extremely cheap, easy to control, and avoid a whole lot of problems.

Answer 4

You want to be able to trust something on an end users device.

Short answer - the end user controls the device. They can in principle, for most purposes, root it and hide the rooting from your detection, copy any data that can physically be copied between devices, and alter any data that can't be copied, when read.

Even if the phone isn't rooted, recovery can be used or written (TWRP or similar), which won't show up and will effectively allow universal access at least until reboot, on many common devices.

You can't trust your app, the phone OS, recovery, to detect or report accurately or truthfully, any data, against a moderately determined user, with even moderate enthusiast skills.

What can you trust? Literally, only anything in the machine that cannot be altered by the user, and cannot be misreported, moved, or falsified. If such things exist.

That's in effect, maybe challenge-response protocols for some kind of encrypted secrets container that isn't accessible beyond its APIs even on a totally exposed device, and can't be moved to another device. Not much else.

The problem is, most phones aren't designed for such purposes, and may not provide that capability.

As with so much else security, all you can often do is raise the barrier. Not prevent.

Answer 5

The operator of a system that requires security will want to rely on the safe storage of its credentials and on the control over (or at least trust in) the cryptography that is used to protect it. For mobile operators this is the SIM card which provides both secure storage and encryption capabilities. For payment systems this is the chip on the credit card, or the trust into the secure storage areas in the phones (with HSM or not). That's why most banking and payment apps first check if the OS on the phone is still in its original state and would stop working if the phone was rooted. For access control systems it is usually the physical storage of credentials in access cards or tokens, where the card's communication to the access control reader is encrypted (e.g. 3DES for MIFARE DesFire cards) and the company that operates the access control system controls the key (sometimes they even use key-diversification).

None of this is 'security by obscurity', the way to store things and the encryption methods are usually published. There is just an additional hardware layer on top to make it more difficult to fake.

Long story short: The operator of a service needs assurance that everything is fine, and the idea of open source seems to remove one layer of security, that's why it is not going to happen.

B.t.w. almost everything can be spoofed, you can even replace the IMEI of your phone. The IMSI might be a better approach, but I am unclear how an access control reader can ensure it is being presented the actual IMSI of a phone. I am not aware that the encryption mechanism of the SIM card (and its private key) is available to apps on the phone through an API. This might open it to brute-force attacks. You might find more details on the SIM card in the IS Stack Exchange

Answer 6

Furthermore, the organization wishes to only allow each member exactly one device for identification. It should be prohibitively difficult to spoof the identity of one device with another device, even for the owner of both devices. Put another way, it should be nearly impossible to duplicate one ID across devices.

This is almost what Physically Unclonable Functions (PUF) do; From Wikipedia;

A physical unclonable function (sometimes also called physically unclonable function, which refers to a weaker security metric than a physical unclonable function), or PUF, is a physical object that for a given input and conditions (challenge), provides a physically defined "digital fingerprint" output (response) that serves as a unique identifier, most often for a semiconductor device such as a microprocessor.

There are NFCs that implement PUF some listed here. Check your NFS's support on this. If you use NFS with PUF then you can uniquely identify each device and make sure that it is not cloned (duplicated).

Make sure that you back up the phones and the system in the usual way not using the PUF mechanisms and secret since they are unclonable.

---

Note that PUFs are almost everywhere, from paper to FPGAs to ASIC to CMOS/CCD.