Friday, February 07, 2014

Something you have (and some other things you have)

The trinity of 'Something you know, something you have, and something you are' is the default model for describing authentication options.

The three are traditionally described as follows

  1. The 'know' factor is a secret like a password or a PIN. 
  2. The 'have' factor is some physical object in your possession. 
  3. The 'are' factor is a biometric like finger or retina print.
Think about the 'have'. It's clearly not enough to merely have possession of a SecureId or smart phone. You have to demonstrate (or prove) possession of that object. Typically, possession is proved by entering in some OTP, or responding to a challenge sent to that object. 

Now consider the 'know'. When I enter a password to login, what am I doing other than proving possession of (the knowledge of) the shared secret?

And for the 'are' factor, when I enter Canada using a Nexus kiosk, what am I doing other than proving possession of my retinas?

Would it not be simpler to model all authentication operations as 

Something you have (with various proof mechanisms) 

We are headed to a future where the things we have (see this) will be more and more involved in our authentication. While the phone may have primacy at the moment, over time it will become just one of many devices floating around us with an opinion on our status & presence (and an ability to assert it). 

So perhaps the ultimate model for describing authentication is 

Some things you have (with various proof mechanisms) 

You can take it with you (if you have a super long ethernet cable)

In a post titled 'Can you take it with you? Uninstalling the internet of things', Stacey Higginbotham considers how the installed base of home automation gear will impact moving households.
of the installed $250 thermostats or the $60 light bulbs, what comes with you if you have to move
Well clearly the fridge is coming with.

Two commenters propose what seems to me the smartest (as it minimizes effort) route


Bob Sanders' comment hilites a procedure & mechanism that I don't think has received sufficient attention as yet.

What would it look like for the new owner to 'establish his own credentials'? What accounts need be created? What assistance would the new owner be given - without the inevitably discarded original owners manual?

How would the privacy of the previous owner be ensured? Should all data be erased and the new owner start from a (freshly) blank slate? But as there can be value in historical data (why are my heating costs significantly more than the previous owner's? etc) could we contemplate moving overly some suitably anonymized version of the data (presuming consent)?

Beyond the devices themselves, what of the IFTTT-type rules that the previous owner might have defined for their operation? A lighting system is much more valuable with appropriate customized themes, such as 'Watching a movie'. Are these rules & patterns transferable to the new owner?

It seems to me that transitioning a device from one user to another is a special case of the more general mechanism of how to bind a fresh from factory device to its first user - and the associated questions.

  • How are these two identities associated?
  • How and where is the user's consent captured?
  • How is that consent manifested? How is it revoked?
  • How is the device added to the home network? 
Bob posed his question in terms of 'credentials', but those are I think simply a manifestation of the more fundamental identities involved. 

Tuesday, December 17, 2013

An IoT continuum

Currently, the burden falls on us humans to 1) sense the world around us 2) analyze that sensory data & decide how to best deal with it 3) act on that world accordingly

The Internet of Things will change that - evolving from systems that help us with #1 to eventually helping us deal with #2 & #3.

Consider a story, loosely based on reality, with progressively greater assistance provided to the handsome protagonist

  1. I look out the window and see snow coming down hard. I decide to leave early for a trip to the airport. Once in the car, I engage the 4-wheel drive.
  2. I get an SMS from a weather alert service notifying me of snow squalls in the area. I decide to leave early for a trip to the airport. Once in the car, I engage the 4-wheel drive.
  3. I get an email recommending I leave now for my trip to the airport - given snow squalls in the area. Once in the car, I engage the 4-wheel drive.
  4. I get an email recommending I leave now for my trip to the airport - given snow squalls on my typical route. As I turn the ignition key, the car auto engages the 4-wheel drive.
  5. My Home Concierge recommends I leave now for my trip to the airport - given snow squalls on my preferred route. Once I confirm the change, the car turns itself on, pre-warms the cabin, and auto engages the 4-wheel drive.
If the Internet of Things can get my two teenage sons to have the driveway shoveled - I won't even get my shoes wet.


Monday, November 18, 2013

Things that go bump in the night

My daughter's best friend's family (let's call them the Smiths) recently moved to the other side of the country (unfortunately selfishly bringing their daughter). My daughter is saddened by this.

To some extent, I see my role as trying to minimize large-scale sadness increases for my children (also my wife I guess though that definitely wasn't in our vows so that's mostly bonus the way I see it).

Consequently, I'm looking for any mechanisms that might help my daughter with the change.


Might technology help?

The girls are already using explicit connectivity technology, some iOS app called Bump & numerous 2-hour FaceTime sessions in which mine and the Smith's households' respective dogs are forced to appear on camera in humiliating costumes.

Explicit mechanisms are definitely important for keeping remote friends feeling connected, but so also can be implicit or passive mechanisms - such as the Good Night Lamp.

According to Forbes
The Good Night Lamp is a simple set of lamps – one big, one or more little. When the big one is turned on, the little ones turn on. When the big one is turned off, its junior partners also turn off. More junior lamps can be added to the network, but that, at heart, is the whole offer. There is nothing to tinker with or customize – it is a simple point of presence, sent over the Internet.
This would be perfect for the girls. But unfortunately there are no Good Night Lamp kits available for purchase - they're sold out after their initial run.

Coincidentally, I have a Smartthings kit of various things - can I not use Smartthings to duplicate the GNL use case?

Use Case
When my daughter performs some explicit action, turn on/off bedside lamp of her friend in Vancouver. And vice versa. 
Tools

My Smartthings kit includes 
  • Hub
  • Multi
  • Presence
  • Outlet
  • Motion
Implementation

Temporarily putting aside the two household aspect, I could use a Hub, Multi and Outlet to satisfy the use case within my own house - using IFTTT to tie it all together.


When the Multi switch is closed (the two halves placed together), the Outlet is turned on, and so any light plugged into turned on as well. And vice versa.

To deal with two different households, I could purchase another Smartthings Hub, Multi, and Outlet - ship them to the Smiths and then duplicate the above rules, although inter-household and not intra.

This would work, but at the cost of me bearing the full financial burden (and the Smith girl is missing a friend too right?) of effectively purchasing two Smartthings kits and distributing the various pieces over the country. 

Preferable (to me if not the newly trendy, sodden and real estate-indebted Smiths) would be a model where it is the Smiths that purchase the second Smartthings kit - and yet we are still able to apply the above logic, albeit based on explicit authorization rules (the Smiths can control my outlet, and I can control their outlet) rather than implicit logic (all the things belong to me).

For Smartthings to support this would require
  1. an invitation mechanism whereby I can request the Smiths to assign me permissions over their household things
  2. an authorization UX whereby I can assign the Smiths permissions to control my household things
  3. an authorization framework by which the permissions of a given 'turn on Outlet' request from a household to the Smartthings cloud platform can be checked.
OAuth,OpenID Connect & UMA (User Managed Access) are identity & authorization standards that were designed to meet these sorts of requirements. 

Of course, this sort of 'identity interoperability' across two smart households begs the question - shouldn't this work across different Home Automation platforms? What if the Smiths were to purchase WigWag and not Smarthings? This sort of cross-platform interoperability neeedn't even imply a WigWag hub controlling a Smartthings Outlet - the interoperability could happen between the two respective clouds using HTTP & APIs.









Friday, November 15, 2013

Client authentication in MQTT

As leveraged by Paul Freemantle, the latest working draft of MQTT allows for (if not defines how to) use of OAuth access tokens in authenticating the client to the server/broker.
The CONNECT Packet contains Username and Password fields. Implementations can choose how to make use of the content of these fields. They may provide their own authentication mechanism, use an external authentication system such as LDAP or Oauth [sic] tokens, or leverage operating system authentication mechanisms.
The spec also allows for client authentication through VPN or SSL. And also it seems inserting arbitrary credentials in the application payload as well.
An implementation might allow for authentication where the credentials are flowed in an Application Message from the Client to the Server.
Separate from the interoperability challenge presented by so many different client authentication mechanisms, there is (to my mind) a more fundamental issue with MQTT's client authentication model.

There are both ClientID and Username params allowed on the CONNECT message. This would allow for separate identification of both the MQTT client and any user that that client was sending messages on behalf of. This seems appropriate - allowing for a single client to potentially represent different users over time. But there is only a single Password (or equivalent) parameter on the CONNECT and it appears to serve double duty for both authentication of the client and also any user.

Because there is only one Password parameter, it seems you can't authenticate both the client and a user simultaneously on the same CONNECT.

If you did need to authenticate both client & user simultaneously, it would seem you would need to do something like

  1. use client-authn SSL to authenticate the client & use the Password field for the user, or
  2. use the Password field for client & some application message param for the user (or vice versa?)

Choice is good except when it isn't.....

If MQTT allowed for a 'client_pwd' (name it what you will) to be paired with the existing Clientid parameter, and thereby distinguish between credentials for the client (client_pwd) and the user (Password), then the whole situation would be cleaner.

Even cleaner would be to define a new CONNECT field called 'access_token', and use that instead of forcing OAuth tokens into the existing parameters (which can be problematic as Paul discovered).
I couldn't encode the token as the password, because of the way Mosquitto and mosquitto_pyauth call my code. I ended up passing the token as the username instead. I need to look at the mosquitto auth plugin interface more deeply to see if this is something I can fix or I need help from Mosquitto for.




Thursday, November 14, 2013

OAuth binding for MQTT

Paul Freemantle blogs about some experimenting he has done around using OAuth within MQTT - specifically using an OAuth access token in the place of a username password.
I've been thinking about security and privacy for IoT. I would argue that as the IoT grows we are going to need to think about federated and user-directed authorization. In other words, if my device is publishing data, I ought to be able to decide who can use that data. And my identity ought to be something based on my own identity provider.
Choir member here appreciating the sermon.

Paul appeared to focus on how the MQTT client, once having obtained an OAuth access token reflecting the relevant user's consent to some set of operations (captured in a scope), used that token on its CONNECT messages to a MQTT broker. In the end, he used the existing MQTT username parameter to carry the token.

Coincidentally, I was thinking about the same integration yesterday, though focussed less on how to bind the tokens to the MQTT messages and more on how we might leverage MQTT's existing pub/sub model to get the token to the Client.

Something like
  1. Client send the username/password on MQTT CONNECT message
  2. Client sends SUBSCRIBE message for a topic of 'access_token/#'
  3. MQTT broker responds with a PUBLISH message carrying the access token.
  4. Client discards password, stores access token
On subsequent interactions (as long as the token hadnt expired) with the broker, the client would use the token instead of the username/password combination.

The above pattern, namely the client directly exchanging a username/password for an access token, mirrors the OAuth Resource Owner Credentials grant type - allowed for in OAuth but not recommended.

There are definite advantages to instead leveraging a web browser (as Paul indicated he had used) for the token issuance, including

  1. password need not be presented to broker
  2. allows for federated user authentication (ie at some other IdP)
  3. allows for a detailed & granular consent UI
But perhaps the above issuance model would be easier to layer onto simple MQTT clients - leveraging as it does the existing flow.






Wednesday, October 30, 2013

Smartthings - binding thing to user

Some 'things' need to be bound to a user identity in order to allow for differentiated authorizations or reporting.

Follows is how this binding works for Smartthings

I placed my order at Smartthings.com. When the package arrived, it included a registration code. I assume all the thing serial numbers (or equivalent identifiers) is indexed by that code as part of the packaging & shipping process.

Though I'm not sure, I don't believe the registration code was bound to my account at issuance time (even though it could have been because I was logged in at the time). Binding will happen post shipping.




I then download and install the Smartthings app (here Android). Below is the initial login screen


After logging in, I am prompted to plug in the Smartthings hub, connect it by ethernet to the home router, and then enter the registration code into the app


User account is bound to code, and code is bound to device identifiers - so consequently user account can be bound to device identifiers.

It is through the temporary identifier of the code that Smarthings is able to know that a given motion sensor is under my account and so apply a permissions model based on this binding, ie I can manage them but nobody else (unless I stipulate so). Even more basic, when the Smartthings cloud receives sensor data from a particular thing/hub combination, it is able to associate that data with my account.

I recently purchased a Fitbit Aria scale. The Aria used a completely different mechanism to associate the scale with my existing Fitbit account. Area seems ripe for usability testing.

Friday, October 18, 2013

Assurance over time

Consider a traditional authentication event.

The user logs in at a given time t0 and establishes some initial level of assurance. As time goes by, that assurance drops, the rate dependent on the context, ie public kiosk, etc.

 A graph of assurance over time looks something like

 

To prevent this decline, you can require that the user re-authenticate whenever the assurance hits some threshold at






















An alternative to using explicit additional logins (as above) is to maintain assurance above at by monitoring implicit factors such as location, continuous typing, facial recognition, etc

Nb: the 'how' of detecting & monitoring these passive or implicit factors clearly demands some new pieces on the network. Depending on where this functionality sits, we may also need new mechanisms & protocols for communicating the information around.






















From the user's PoV, this passive model has advantages - minimizing as it does the pain of explicit logins.

Ultimately, using a combination of explicit & implicit authentication factors appears to be emerging as the optimal balance of security & usability.

I don't even drink milk!

Along with the smart toaster, a fridge that can sense when the household is about to run out of milk and send a compensating order to the local supermarket is presented as home automation's killer app.

Couple of things
  1. Ahem, Webvan?
  2. Lactose intolerance is a serious health issue for many
Now a fridge that could monitor 'beer' metrics - that's a use case!

And it's more interesting from an identity perspective. 

Any fridge can order milk. Only fridges that exceeds the local age of majority can order beer or wine.

Or more precisely, only fridges acting on behalf of a human who exceeds the local age of majority can order beer or wine.

That demands an identity model in which
  1. The fridge can obtain an identity token for individual users - these to be attached to the 'Buy beer' API calls to the local depanneur
  2. The token contains (or references) the user's 'age' attributes 
  3. The token is issued from an identity provider that is accredited to issue age attributes
  4. The depanneur can validate the token as coming from a trusted authority, look at the age attribute, and so determine that the fridge's request can be authorized.
OpenID Connect is tailor made for the above set of requirements.