4

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.

8
  • What are the user's desires in this? That is, are you asking for open-source ways to help an end-user prove his/her identity, or asking you asking for open-source ways to allow an organisation to prevent an end-user duplicating a set of credentials?
    – MadHatter
    Dec 7 '21 at 9:15
  • The first rule of security: You must assume that an attacker knows everything except the password for your private key. Dec 7 '21 at 9:30
  • @BartvanIngenSchenau absolutely, which is why I think it's important first to determine if the attacker and the person knowing the private key are one and the same person.
    – MadHatter
    Dec 7 '21 at 9:35
  • @MadHatter I believe I'm looking for the latter option, open-source ways to prevent an end-user from duplicating a set of credentials across devices. I don't even know if that's possible, theoretically. The end-user may be an attacker, if I understand you correctly. Dec 7 '21 at 9:43
  • @MadHatter For example, a single user may want a friend to be able to sign in for him, using a secondary device, while the original user retains possession of the original device. My question is whether it is possible to prevent this, transparently. Dec 7 '21 at 9:45
7

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.

2
  • If this is the true answer, so be it, and many thanks. However, the dual-SIM option wouldn't be workable for my scenario, so I'm going to keep this question open to other answers for a bit. Dec 8 '21 at 0:40
  • "Other than that, I don't think general-purpose free phones have support for crypto HSMs" - The Pixel series has unlocked bootloaders, and as I understand it, the Titan chip is similar enough to an HSM for OP's purposes (i.e. it supports remote attestation), so the 6 at least should serve as a counterexample. However, I suspect the same is also true of much older phones.
    – Kevin
    Dec 8 '21 at 2:37
2

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.

2

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.

4
  • +1 for "attach the card to the phone". There is utterly no advantage, and lots of disadvantages, to having the phone act as a MITM here. Dec 8 '21 at 16:00
  • 1
    Good thoughts. A lot of people are using their cards attached to the phone, for convenience. The issue was that people were lending out their cards. While far from a guarantee, people seem less likely to lend out their phones, thus the desired transition to a phone-based system. It's not a transition that I'm a fan of, but since I can't probably change it, I want to see if I can make it as non-intrusive for that end-users as possible. Dec 8 '21 at 19:31
  • @WayfaringStranger If this is what you want to prevent, add biometrics. While biometric devices are relatively easy to trick into believing fake inputs, these methods are unlikely to be tried by regular people.
    – JohnEye
    Dec 8 '21 at 20:10
  • @JohnEye That would do it, for sure. But for this application, that would be too invasive for the end-users (students; I'll update the question for context). Dec 8 '21 at 20:18
1

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

4
  • The private key on a SIM card definitely isn't available to the phone apps, that's the whole point of the SIM card. Approved operations with that key, yes; the key itself, no. Brute-force attacks are addressed by the bad PIN counter on the SIM.
    – MadHatter
    Dec 7 '21 at 12:15
  • "Approved operations with that key" are to my knowledge only for the purposes of the MNO, not for the public. If the encryption function of the SIM was available through an API to the outside (keeping the private key securely in the SIM), then I would try to attack the key by a known-plaintext attack through the API (brute-force if necessary, as the phone is in my own hands I have time). The bad PIN counter of the SIM likely would not help against that. But this is a discussion which should be on the Security Stack Exchange, not here. Dec 7 '21 at 14:07
  • I can't agree with a lot of that, but your closing point is right on; sorry about that.
    – MadHatter
    Dec 7 '21 at 14:24
  • Thanks for the answer. If the approved operations are indeed limited to MNO operations, then that's really unfortunate for this application. I'm happy to move this question to Security, if that's the better place for it. Dec 7 '21 at 15:50
0

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.

6
  • 2
    Step 1: how on earth does the company know the submitted public key corresponds to a private key generated on-chip, instead of (say) on my desktop, where I have many copies of it?
    – MadHatter
    Dec 8 '21 at 6:40
  • All of security is a question of how paranoid are you. You have no assurances unless security personnel watches the process. In a perfect world I would likely prescribe a trusted user interface with watermarks and a human verifiable graphic depicting the hash of the key being submitted to be verified by security personnel. Look to the trusted platform spec on how this might be achieved. But on average, unless your users are adversarial to you or security researchers, this isn't needed. Pam from accounting isn't likely that tech literate and John the engineer can be told he will be fired.
    – foreverska
    Dec 8 '21 at 16:01
  • "All of security is a question of how paranoid are you" the less-pejorative way of putting it is that all security is meaningless without a threat model. In this case, the OP has specifically stated that his threat model includes employees duplicating access tokens. It's not enough to say "fire John the engineer if he duplicates a token".
    – MadHatter
    Dec 8 '21 at 16:25
  • OP also asks for near perfect security from a highly imperfect security device. My point is, you have readily available security measures meant for this. Use them and accept their risks. If you want some assurances that the key is not copied, generate they key yourself and have the user import it to their keystore. But it exists in memory during that process so that can be pwned too. Unless there is a perfect tunnel from server to TZ and you can verify the TZ app has not been tampered. Your budget and paranoia will determine how secure is good enough. A phone will always be imperfect.
    – foreverska
    Dec 8 '21 at 16:35
  • This is an intriguing option. Are HSM's a common feature on smartphones? I hadn't investigated them before this answer. Dec 9 '21 at 15:42
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.