NFC Ring is a crowd-funded project for producing a wearable ring with embedded NFC tags. It is meant to be general-purpose device with a variety of applications, ranging from casual to security critical: exchange contact information, unlock mobile devices or even control physical access to homes and cars, to cite a few example from the KickStarter page. Recent Twitter exchanges motivated this post discussing the nuts-and-bolts of using NFC tags for screen unlocking on mobile devices.
Unlocking with NFC, old-school
In one sense this is old news and already within reach using off-the-shelf components without writing a single line of code or soldering any wires:
- Windows supports smart card logon for domain-joined machines. Using third-party solutions such as the excellent eIDAuthenticate package allows doing the same for stand alone home PCs.
- Any credential provider in Windows also works for unlocking the screen. In other words smart cards can be used to unlock a machine that wakes up from hibernation or screen-saver, just as well as they can be used for logging into the OS after a fresh boot.
- Many smart cards are dual-interface; they can be accessed either by insertion into a wired reader that comes into direct contact with the metal surface or by holding the card against a contactless NFC reader.
- Recent generation laptops and tablets have integrated NFC readers, eliminating the need for separate smart card reader dangling off to the side. (Proof-of-concept featured earlier: reading smart cards using the NXP PN533 reader tucked under the keyboard rest of HP Envy Spectre laptops.)
Putting it all together: an NFC smart card unlocks a Windows laptop with integrated NFC reader.
Building for mobile
This is admittedly an outlier as far as “unlocking device with NFC” goes. First most users would interpret that scenario with mobile devices or Android tablets instead of traditional PCs. Windows 8 is trying to make inroads into the tablet market but WinRT sales have been disappointing. (iOS devices are out of the running since Apple has not yet figured out how to incorporate NFC yet.) Second, the NFC-enabled object in mind is often a compact token or tag instead of the vanilla plastic ID card– while this turns out to be a completely superficial distinction since the circuitry inside and RFID technology used are identical, there are fundamental engineering/physics reasons why larger objects are easier to work with. There are three challenges in designing a solution to unlock mobile device with a small NFC tag: tuning the antenna for good connection between tag-device, integrating with device OS to control screen state and crafting an authentication mechanism to verify that only authorized users in possession of the tag can access the device.
Engineering around antenna limits
In simple terms, the NFC ring is nothing more than an ordinary NFC tag in specific form factor. Already NFC tags have been incorporated into an impressive array of ordinary objects: keychains, refrigerator magnets, business cards, even cup holders. Some options are wearable, such as bracelets used for event ticketing– Outside Lands pass in 2012 was an NFC tag. The ring design however poses some formidable engineering challenges. First rings are typically made of metal, and having a large metal surface under/above an NFC tag prevents the ability of the tag to draw power from the field. This is typically solved by including a layer of ferrite below the tag, which increases the thickness of the sticker. A good example of this are NFC stickers on San Francisco parking meters, designed to launch the Pay-By-Phone application on compatible devices. Fundamentally this is a well-understood, solvable engineering problem. It involves practical trade-offs between ring dimensions and how much leeway users have in terms of location/distance when trying to use the ring against any given device.
Integrating with operating system
The story gets more complicated and platform dependent when considering the software side of the equation. Windows unlock with NFC works the hard way: that smart card is not merely unlocking the screen, it is performing full logon with public-key credentials. Doing that has side-effects beyond the local machine: for example it may involve talking to the domain controller to refresh Kerberos tickets. That constraints the solution space because NFC object in question must conform to the authentication model defined by Windows, by acting as a “credential” for an installed credential provider in the operating system. (Incidentally eIDAuthenticate used in the proof-of-concept adds that credential provider for stand alone machines. Domain-joined instances already have one for use with Kerberos.) That sounds like a very heavy-weight, over-engineered solution when the problem is framed as “make the screensaver go away.” But it highlights an important point: frequently the credentials used for unlocking the screen also serve other purposes. For example Android derives disk encryption keys from the PIN/pattern/passphrase used to unlock the screen. Unless alternative unlock mechanism via NFC can produce same credentials, it will not be interchangeable. Luckily disk decryption happens only once during boot process. All other times the user-entered code is not implicated in anything other than deciding whether it is safe to unlock the screen.
Managing screen state on Android
Instead of the complex credential providers architecture in Windows, Android has a simple elegant solution in the form of KeyguardManager and its replacement. These classes expose functionality for exiting the screen lock. Applications with the appropriate permission can invoke that API to unlock display based on any criteria, such as the presence of a particular NFC tag. There is a catch: NFC polling loop does not run when the screen is locked. This is in fact a security feature introduced in ICS release, in response to observations about the earlier Gingerbread behavior. In GB tags could be scanned and intents dispatched to application even when the screen was locked. (The screen had to be powered on; there is a different logic that powers off the NFC controller when display goes to sleep.) That made it too easy to have unintended actions happen by placing device in proximity to hostile NFC tags. Imagine web browser navigating to any page or having applications installed just by holding the phone against an appropriate tag.
Arguably ICS went overboard. At least some NFC intents are benign; the operating system could have continued processing NFC tags but suppressing intents unless the target application specifically opted into receiving them with locked screen. In any case that is not what the OS designers opted for, and this behavior can not be overridden by third-party applications. That means any screen unlock app that hopes to run on recent vintage Android has a serious problem because it will not be able to communicate with the magic tag when screen is locked– precisely when that communication is required. Existing applications in Play Store attempt to work around this by replacing the lock screen. But this is not a viable solution because the lock screen itself has useful functionality such as customizable gadgets, notifications and controls for audio player that can not be duplicated by a third-party application. Overcoming the limitation properly requires a change to the NFC stack itself to re-enable the polling loop or otherwise allows tag processing to continue. That option is only available to the OS provider or OEM/carrier making custom modifications to plain Android. That appears to be the path Motorola followed with the new Clip NFC system for MotoX phones.