Tuesday, October 28, 2014

Less is more

I attended GigaOM's Structure Connect conference in San Francisco last week. The event was great, lots of interesting discussions & panels.

I was in a 'Securing the IoT' breakout session where one of the GigaOM analysts made the assertion (paraphrasing)
Developers need better training on security, they need to take more responsibility for securing their applications.
This actually runs completely counter to what I've been seeing as the overarching trend around application security, namely that developers need to take (or even be given) less responsibility for securing their applications - not more.

If their app has to handle $$, do developers directly track currency exchange rates? No, they find an API that does that and so removes them from a task secondary to that of the application itself. The currency API abstracts away from the developer all the messiness - they make a simple REST call and get back a tidy bit of JSON to parse & use.

From the developers point of view, why would security be different? Do they want to deal with the specific details of supporting different authentication protocols, crypto etc. Or would they prefer to focus on adding features and functionality to their apps?

The trend towards lightening the security load for developers manifests in various ways

  • Social 'Login with X' SDKs - the large social providers make it as easy as they can for native application developers to hook into their identities. For instance, Facebook Login promises
The Facebook SDK for iOS provides various login experiences that your app can use to authenticate someone. This document includes all the information you need to know in order to implement Facebook login in your iOS app.
Google has the comparable the Google+ Sign-In, the documentation for which asserts
Avoid the hassle of creating your own authentication systemGoogle+ Sign-In mitigates data-breach risks and reduces the burden and costs of identity security. The Google authentication window creates a trusted link between you, your users, and their Google account.


  • REST gateways - many enterprise REST APIs are fronted by a gateway that intercepts incoming calls from clients and applies processing before delivering the call on to the actual API. The API developer need not directly deal with the authentication tokens attached to the original call, insulated from that burden by the gateway. Instead the gateway 
  • IDaaS - or Identity as a Service, is the trend of enterprises moving out to the Cloud certain identity & authentication mechanisms (just like many other enterprise functions are being outsourced). Rather than directly dealing with user provisioning, federation, or password vaulting etc the enterprise subscribes to the services of an IDaaS provider. The IDaaS takes on the full burden of the complexity of dealing with multiple protocols, business partners, customers, SaaS etc and offers back to the enterprise developer a much simpler integration proposition.
The above are all examples of freeing application developers from having to bear full responsibility for securing APIs & native applications. And last I checked, both will be relevant for the Internet of Things. Freed from the burden of security, IoT developers will be able to focus their attention where they should - namely creating new & interesting visual paradigms for my wearable step data.



Wednesday, October 08, 2014

Social Media 2 Factor authentication


Premise

A user can authenticate to a web application (or a federation server) by sending an update (tweet, Facebook update, etc) with a randomly generated hashtag previously delivered to the user in the login interface. 

The fundamental requirement is that 

  1. the user be able to demonstrate ownership of the social account previously connected to their account at the authentication server by including a challenge string in a tweet, update etc
  2. the authentication server be able to determine that a particular challenge string was added to a tweet, update etc associated with a particular social account 

User Experience


Step 1 :


User binds their social account to the authentication server

Screen Shot 2014-05-22 at 3.12.58 PM.png

Alternatively, the ‘binding’ could consist solely of the user telling the authentication server their Twitter handle.

Step 2:


Later, User visits login page

User logs in with first factor, ie password, or SSO

Login UI displays randomly generated challenge string
Screen Shot 2014-05-22 at 3.33.01 PM.png

Authentication server stores away challenge string against that user’s account

Alternatively, the challenge mechanism could be via Twitter, ie the authentication server sends the user a tweet, and the User response would be a RT.

Step 3:


User sends tweet , including challenge hashtag from Step 2

Screen Shot 2014-05-22 at 3.35.27 PM.png

The response format & channel will depend on the nature of the challenge and how the user’s social media account were bound to the account at the authentication server.

Step 4:

After displaying the hashtag challenge to the user , the authentication server polls the user’s tweet stream (or equivalent) on some schedule for a tweet (or post) containing the challenge hashtag.

If such a tweet is found within some time period, the authentication page displays successful login.

Discussion


  1. The default would be for the user to manually type the challenge string into their tweet. Might it be possible for the authentication server to instead/also display a QR code, for the user to scan and so launch their mobile Twitter client with the tweet ready to send?
  2. Instead of a string, the challenge could consist of a link to a specific picture or some other media
  3. If the user has previously authorized other applications to be able to send tweets on their behalf, then those other applications would potentially be able to send a response tweet, but only if they were able to know the challenge. Consequently, the authentication model is likely only relevant for a 2nd factor, as having the user first authenticated with the other factor would prevent other applications from knowing the challenge string.
  4. if the authentication server were able to determine how many applications the user has granted the ability to tweet on their behalf, then conceivably it could factor that into it’s assessment of assurance
  5. There could be a viral component to the marketing of the authentication service, as the user’s followers would see the authentication tweets
  6. Is there a risk of violating Twitter ToS?

A symmetrical NAPPS model


The NAPPS WG in the OIDF is defining a framework for enabling SSO to native applications.

One challenge has been in supporting 3rd party native applications from large SaaS that already have an OAuth & token infrastructure (Salesforce as an example).

For this sort of SaaS, NAPPS has to allow the SaaS's existing OAuth AS to issue the token ultimately used by the app on the API calls.

The NAPPS spec is evolving to dealing with such applications in almost exactly the same way as it does native applications that call on-prem APIs built by the enterprise.

Fundamentally, for both categories of native applications, the enterprise AS issues to the Token Agent an identity token JWT, this handed to the application through the mobile OS bindings. The app exchanges this JWT for the desired access token to be used on API calls - the only difference is the AS at which the JWT is exchanged.

Local native apps
  1. app requests tokens of TA, includes generated nonce
  2. TA uses its RT to send request + nonce to AS
  3. AS returns PoP JWT
  4. TA hands over PoP JWT to app
  5. App exchanges JWT, shows PoP
  6. AS returns token(s) to app
3rd party native apps 
  1. app requests tokens of TA, includes generated nonce
  2. TA uses its RT to send request + nonce to AS1
  3. AS1 returns PoP JWT, targeted at AS2
  4. TA hands over PoP JWT to app
  5. App exchanges PoP JWT against AS2, shows PoP
  6. AS2 returns token(s) to app
Step 5 in the 3rd party sequence implies a federated trust model - the SaaS AS2 must be able to trust & validate the JWT issued by the enterprise AS1.


The above model is attractive for the symmetry it provides between both application categories.

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.

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.