Authentication vs. Repudiation in IoT and mHealth: weaknesses in Apple’s ResearchKit Microsoft’s HealthVault Google’s FitKit

It is commonly accepted that IoT has some challenges to overcome when it comes to Data Security.   And yet at the same time we see a lot of folks touting the intersection between Mobile Health (mHealth)  and IoT Sensor Networks as being a game changer in Healthcare.   It is creepy and irritating if someone accidentally (or intentionally) takes over control of the lights in your house.  It is a completely different matter if a Drilling Rig   or your pacemaker has random glitches  or worse – are intentionally hacked.    Mostly this gets dealt with by the very broad armwave of "Data Security" and "encryption"  but there's a bit more to it than that.  In particular we also have the issue of Data Authentication as well as "non-repudiation".

There are two types of encryption:

  • Public Key also sometimes called "trap door" or "assymetric key"– which is very hard if not impossible to break, but which is slow to encrypt and decrypt because it requires solving very complex math. 
  • Symmetric key or "Session key" – this is essentially a variant of the old "A" = "V", "B"="W" codes that kids play with.  Admittedly a more complicated version, but given a large enough set of messages and enough computing power, this can be cracked, and even cracked moderately quickly.

Things like SSL (HTTPS) use the two in combination: - SSL first uses the essentially impossible to crack Public Key to securely exchange "Session keys" that are then used to encrypt and decrypt information for the duration of that session. Digital Signatures are essentially a mechanism for quickly adding a Public Key encrypted "signature" string (essentially a digital fingerprint of the message being sent) to a set of data/message that then in turn may or may not be encrypted with a Session key.    Because the digital fingerprint is encrypted, any change to the message results in a fingerprint mismatch and thus it can be seen that the message was tampered with along the way.

So this provides a mechanism for Authentication –IF DONE RIGHT - (such as signing each distinct message, but that affects performance)!!!

And there is a flip side to this coin.   In say the case of a Chip Debit Card access to your bank account – the bank wants to prevent you from "repudiating" a transaction: "No I did not withdraw $10,000 in the Las Vegas last weekend" vs. "No I did not withdraw $10,000 in Byelorussia last weekend I never left the USA.   In a banking transaction there are other ways to deal with the non-repudiation:  did you go through Airport Security or the US Border control.    But when it comes to IoT and mHealth data – things quickly get much more complicated.

Most of the "Authentication" for IoT, and mHealth relies on SSL.   But there are some problems with this.  

  • One, we have recently seen a host of hacks of SSL – from Apple's "Goto Fail"  bugto the SSL hijacking that Lenovo's Superfish debacle uncoveredto the "HeartBleed" bug in Open Source SSL  that left 2/3 of the web vulnerable. 
  • Less well understood is the risk for sensor networks, be they IoT or Mobile Health (mHealth) – where the data being transmitted is quite "regularas in very predictable.  The movie The Imitation Game talked about this:  if you know approximately what the data is supposed to be in one case, you can crack the encryption key and then you can either eavesdrop OR inject false data into the stream.

It is this latter case that is a huge problem for Mobile Health (mHealth) apps and pretty much all of IoT.   Because if an app is sending:  Heartrate, BP, breathing rate – then by eavesdropping on the wireless data of even a few seconds of data, one can fairly easily determine your "Session Key".   That means that one can now inject false data into that stream.  Which takes us back to the Flashing of the House Lights…..  

Except that when that sensor network is tracking your heartbeat – all I have to do is inject an arrhythmia signal into the data being monitored, and the Cardiac surgeon monitoring your heart receives an alert, reads the bad data and sends a potentially fatal jolt back to your heart.    As a hacker I didn't have to hack the control to the pacemaker – which is getting more and more secure – I just had to fake the data going upstream.    And similarly on industrial and other sensor networks.

But wait!  Don't Apple's ResearchKit and Healthkitas well as MSFT's HealthVault and Google's FitKit help?

No not really.  

Google is the weakest using simply oAuth for protecting the "Data In Motion" (DIM)  and really does nothing for "Data At Rest" (DAR) since it assumes the data resides on the device.  Since oAuth relies on SSL –the "predictability" of the data makes it very vulnerable, as do bugs like the Heartbleed bugand the recent Superfish SSL Hijacking  .

Furthermore most of the protection is done by the app itself, and Google Apps are notorious for requiring permissions to access completely unrelated data:  say like a mapping app asking to access your contacts list.  And while this is ok for your mapping info – when it comes to medical data privacy, more than 45 of the states have DISTINCT patient data privacy laws.  So with Google, you are entrusting your data to the app developers and not any standards

Microsoft HealthVault similarly relies on SSL for DIM but it does do more powerful encryption and at least its data store is HIPAA compliant, and encrypted during Data At Rest behind a well monitored firewall.  While HIPAA is hardly a gold standard, it is a standard and having it encrypted DAR inmanaged and monitored datastore potentially is safer than relying on a mobile app developer to have gotten it right.  In part due to past history, there has been a reluctance by the market to adopt a solution where Microsoft Holds the Data… but the industry may well need to move to a managed data store to insure the DAR security that is necessary..

Apple is better than Google, but it too relies on security of the device itself:

"The signature is generated by the device (which should be tamper resistant, since it stores the private signature key)."
https://developer.apple.com/library/ios/documentation/HealthKit/Reference/HealthKit_Framework/index.html#//apple_ref/doc/uid/TP40014707

So if something like the GotoFail bug  allows for a virus to be installed on your iPhone…. Suddenly you are at risk because all of your data assumes that the iPhone itself is not vulnerable

With ResearchKit ,Apple walks even further away from providing a security infrastructure for the medical data

"Current Limitations

The ResearchKit feature list will continue to grow as useful modules are contributed by the community.

Keep in mind that ResearchKit currently doesn't include:

• Passive background data collection. APIs like HealthKit and CoreMotion already support this.

Secure communication mechanisms between your app and your server.

• The ability to schedule surveys and active tasks for your participants.

• A defined data format for how ResearchKit structured data is serialized. All ResearchKit objects

support NSSecureCoding, and sample code exists outside the framework for serializing them to

JSON.

• Automatic compliance with international research regulations and HIPAA guidelines. These are the

researcher's responsibility. [emph. Added]"

https://developer.apple.com/researchkit/researchkit-technical-overview.pdf

 

So essentially ALL THREE major vendors leave the hard part – namely HIPAA compliance, Digital Signature Compliance (21 CFR 11 ), and the 47 per state patient privacy regulations.    If you want to find out more about what these really entail, register for a Basic Account at https://www.clearroadmap.com/Home/GetAccess  and download the FREE mHealth Checklist.   This will give you some insight into what really is involved here.

 

Clearly the ability to insure data integrity is a much much harder problem than at first it seems.  Apple, Google and Microsoft have each taken different approaches to security for Data-In-Motion and Data-at-Rest. What seems to have been missed is that although the security focusses heavily on Data-In-Motion – we have seen no major breaches in this area.   Personal data that has been compromised has invariably been compromised as Data-At-Rest.   Whether the Microsoft approach of having a well monitored, encrypted and managed cloud based store – or whether the distributed but individually less protected approach of Apple and Google wins out remains to be seen.    But I have grave concerns about the security and privacy of smartphones and tablets as they are built and deployed today.
 

ClearRoadmap(TM) on-line tool launch, to enable medical device and mHealth navigation through US regulatory and reimbursement process. For mHealth, download our FREE mHealth Checklist.  Or Follow Us on Twitter @ClearRoadmap


-- Karl Schulmeisters, Co-Founder and CTO, Carver Global Health Group LLC| karl.schulmeisters@cg-hg.com