Tuesday, October 07, 2014

As long as X is true .....

When my Samsung Gear watch is within BLE range of my Samsung S5, I need not enter my screen unlock pattern in order to get into the phone. The S5 interprets the proximity of the Gear as a proxy for my own proximity, and so deduces that it is myself handling the phone and not somebody else. 

This is an example of what appears to be an emerging model for authentication, which I’ll give the pretentious name of ‘conditional session persistence’ and characterize as

‘As long as X is true, no need to Y’

where ‘X’ is some condition - the continued state of which protects the user from having to perform ‘Y’, generally some sort of explicit login operation.

For my Gear & S5 use case, the X condition is ‘the Gear is within BLE range of the S5’ and the ‘Y’ is ‘demonstrate knowledge of secret unlock pattern to access phone’.

This authentication model is appearing elsewhere.

Screen Shot 2014-10-06 at 12.47.17 PM.pngThe Nymi wristband records the user’s ECG and sends it to a companion app on a paired device for it to be compared to the previously recorded ECG pattern. If the biometric comparison is successful, then the companion application responds back to the Nymi that it should unlock a previously registered crypto key and use that key to authenticate to resources and services. To ‘authenticate’ to the Nymi the user must touch a finger of the other hand to the top of the wristband - this creates an electrical loop that allows the ECG to be recorded. Once recorded and successfully compared, the ECG is not measured again, at least not until the wristband is removed from the user’s wrist. As long as the wristband stays on the user’s wrist the Nymi remains willing to assert the user’s identity by presenting the key (or presumably separate keys for different resources). Once removed from the wrist, then the user is required to re-authenticate once more via their ECG.

The Apple Watch is reported to use the same model.

Screen Shot 2014-10-06 at 12.03.26 PM.pngOn the back of the case, a ceramic cover with sapphire lenses1 protects a specially designed sensor that uses infrared and visible-light LEDs and photodiodes to detect your heart rate.

Via the 4 sensors on the back, the Watch will be able to determine when it is removed from the wrist after an initial authentication (by PIN it seems but it’s not inconceivable that it uses the heart rate as a biometric?). As long as the Watch stays on the user’s wrist the original authentication remains valid and the Watch can be used to, for instance, buy over-priced coffees from hipster barristas.

What is novel in this new model is of course the ‘As long as X is true’ clause - some sort of continuous check of the user’s context that serves to better bind them to the original authentication.  

Contrast this new model with traditional web-based authentication, in which, after the user presents some password (inevitably derived from their favourite sports teams name) the authentication server sets some session cookie

‘As long as T seconds haven’t expired, no need to Y’

In this model, nothing binds the user to the authenticated browser session and so prevents somebody else from hijacking that session - (which if of course is why those who (perversely) login to their banks and other sensitive resources from public kiosks are reminded to sign out when done).

Even in this new model, there will be differences in the certainty with which the persistence of X can be determined - the Nymi and Apple Watch, because they more tightly bind the user to the authenticating device, would likely offer more assurance than the Samsung Gear (I can take the Gear off my wrist and the S5 will be oblivious).

Of course, the ‘As long as X’ condition is only viable if there are local sensors able to monitor the state of X - whether Bluetooth proximity, or skin contact, or heart rate measurement, or future buttock-to-sofa contact etc. 

But fortunately the things that we are more and more surrounding ourselves with, even if primarily intended for some other purpose (think light bulbs, thermostats, and garage doors), will provide those sensors and so the ability to monitor all the different X’s we can think up.


Gluu said...

What you are expressing is security policies. A lot of work needs to be done on how people can intuitively express policies. At the high end (government or military for example), there is a structure policy language called XACML. Below that, many applications code security policies into the application. IOT is pushing the boundaries of policy management to the consumer, especially as there is a requirement for policy enforcement when a device is not connected to the cloud (your phone and watch don't even have an IP connection). The Gluu Server implements the UMA Protocol (User Managed Access), a profile of OAuth2 for authorization. If you have lots of policies, it becomes hard to manage them in all your different policy enforcement points (like your phone, your browser, your car, the locks on your house, access to the wifi etc. etc... you need a central place to manage policy. OVer time these security standards will take hold, as will good user interfaces to enable people to control access to their physical and digital stuff.

Paul Madsen said...

Thanks for the comment Gluu. Thanks for the tip on XACML, will look into that......