Sunday, December 21, 2014

Some thoughts on trust, and the Abbott Libre "spyware"

Trust 

Just as health care, Internet and its latest fad, cloud computing, is based on trust.
Labeled for reuse by Google Image Search


In health care, the patient trusts doctors to have his best interest in mind. It's fuzzy, human, philosophies may differ and at times, it fails. It is usually only as a "best effort". Doctors aren't supposed to inject methotrexate telling you it is just penicillin. Big pharma isn't supposed to sell you penicillin marked as ciclosporin despite the fact that it would be a very profitable business. There are a ton of safety mechanism to prevent that from happening. Sometimes, doctors misbehave (as they did in the famous Tuskegee syphilis experiment). Sometimes "big pharma" hides significant side-effects (see the Vioxx case for example). In the vast majority of cases, however, you can trust your doctor to focus on your health and pharmaceutical companies to have the mandatory quality controls in place.

In principle, our relationship with technology and software is also based on trust. You don't expect your TV to spy on your potential porn watching habits. But then, it happens (LG TVs). You don't expect to spend your IT security money on software that is actually intended to make you less secure. Yet, it happens (RSA Security BSafe). I could literally fill dozens of pages with similar horror stories. At that is not counting the obviously unintentional bugs that have huge consequences such as the "go-to-fail" SSL bug. Effective regulation is extremely hard, in part because the field moves at such a quick pace that no one has time to verify, in part because most programs in use today are formally unprovable and, of course, also because governments will actively undermine any eventual really secure implementations of security.  A certain amount of trust is however necessary and expected. When Microsoft sells you a word processor, they don't covertly export your invoices to your competitor. If they decide to store them in or upload them to the cloud, they usually tell you so. Of course, it is not always black or white (see this for example), the average user's informed content isn't always that informed because most of today's IT technology is indistinguishable from magic for many people, but at least this is the idea. A respectable program does or tries to do what it claims to do and that's it. Programs that don't behave is such a way fall into a few categories, usually called spyware or malware.

Breach of trust, can of worms


In this case, Abbott, knowingly or unknowingly opened a whole can of worms.

1 - they shipped a program that executes significant undocumented actions: it could even be argued that the program exports more data than what it provides to its user and that Abbott keeps more data about the user than the user himself is allowed to keep. A legitimate question would be: what is the main purpose of that program? Provide data to diabetic patients or collect a huge amount of data for Abbott?

2 - they apparently went to some length to hide what they were doing from the normal user hidden directory, remote connections encrypted while local weren't, a strange "meter must always be connected" requirement, absolutely no visual feedback of what was going on, etc...

3 - they explicitly stated they weren't doing what they were doing. that part could actually be a first - I don't remember RSA Security stating something like "our random generator is not intentionally weakened by the NSA" in their license agreement. It sounds like pure "ass covering" in case something goes wrong, but is bizarre. "I do not have a gun and do not plan to rob the bank at the corner of the street, officer". Then a robbery happens. It could be accidental, or it could be intentional.

I can imagine the following internal discussion. "We should insert that disclaimer" says the legal department. "Well, we're doing just that...." says developer. "That a very important part of our plan, will users realize it" says manager? "Ugh... ugh... it's encrypted and hidden but..." says programmer. "Users have other worries, ship it" says manager.

4 - they appear to be intentionally violate EU data confidentiality and retention laws (unless they have an explicit agreement to do what they do) not only within the EU itself, but by exporting sensitive health data as well. This is so blatant that I am really puzzled by this. They must have applied for some kind of approval at least?

What could go wrong?

If all of the above behaviors become the norm, I can guarantee rough sailing ahead. If illegal, obfuscated and undocumented behaviors are OK, the door is open for virtually anything.

What about covertly collecting information about competitor software? While we are at it, why shouldn't they also export my Dexcom data for example? If it is hidden well enough, who will know? In the same vein, why wouldn't the next version of my Dexcom software install a proxy on my computer, grab the data Abbott is exporting, and also benefit from the data trove? Note: the good side of the above point is that if you plan to run a crowd sourced research project, are running your own trials or developing a competitor, you could simply ask the user "can we change your Libre upload URL to our server?" Think about it for a minute... What would make uploading my Dexcom data as well more unethical than what is done already? Then, of course, Dexcom could discover the export, be annoyed by it and fight back. I could, right now, devise a small piece of software that covertly corrupts the data I send to Abbott in a believable way. If a grass-root community is p***** at Abbott, it could probably derail its big data analysis plans by corrupting data en masse. Where does this stop?

Then, what about covertly interfering with the competition hardware or software? It could be done very, very discretely as the recent advanced persistent threats have shown. Let's put my black hat on for a minute and assume I am working for an hypothetical Abbroche company intent on killing its awful Dextronic competitor.

First, I'd implement a modular architecture that can be remotely updated. This could be quite open. Then, at some point, I could covertly or even openly, collect information about which competitor product is present on the user machine. Doing it openly is justifiable (for compatibility purpose for example) but could bite back later in terms of traceability. A second step could be, having identified the exact version/hardware of what I am dealing with, assuming I need significant resources to carry on the attack, to send small chunks of encrypted data that would progressively build a local payload. At some point, when I am ready to execute my attack, I would make an ephemeral decryption key available, would decrypt the payload in RAM, tamper with, for example, the competitor firmware or the data it works on. Dextronic devices could begin failing, sensor data could be misrepresented, or worse. If the above attack comes over a few months, through a chain of compromised servers in China or eslewhere, "attribution" as the FBI likes to say, will be extremely hard.

In fact, it is almost impossible to defend against such a nightmarish scenario, regardless of the constraints the regulators put on the systems. Even if the regulators go for a complete check and make sure everything works in the framework of "best practices", it remains likely to fail. Even huge organizations and companies whose core business is IT security or defense keep failing... Abbott has, at this point, not made such an attack more likely from a technical point of view.

What Abbott has done, is breach the only tenuous lifeline we could hang on to: trust.

Trust that a piece of software or hardware produced by a respectable company tries to do what it claims to do and sticks to that. Trust that when potentially controversial or intrusive actions are taken, an effort is made to inform the user and to obtain his consent.

"do you agree to upload your data securely to Abbott for research and product improvement purposes? Y/N"

How hard is it to implement that simple dialog or tick box?


What really amazes me here is that, if Abbott had asked if I wanted to upload some of my data to their servers, I would have said yes. If Abbott had asked if I was running another CGM and wanted to upload that as well, I would have said yes. If Abbott had asked for correlated BG meter results, I would have said yes. But the fact that I would have - in all my wisdom ;-) - said yes doesn't mean that I believe all diabetics or diabetic parents should do the same.

Abbott seems to want our data: fine.

Ask for it. Don't damage the image of what seems to be a great product with spyware.

Friday, December 19, 2014

Abbott Libre: uploading your life to the US, behind your back...

In "something every Libre user should know" I showed how the Abbott Freestyle Libre software was automatically connecting to an Abbott R&D center in the US and conjectured that Abbott was uploading our data to its cloud, right under our nose.

That prompted me to read the Abbott's License Agreement which sounds reassuring.

The remaining question was then, of course, what is Abbott uploading to its servers? I was committed to find out.

A big lie it is!


The previous traffic dumps (please note that no "hacking" of any kind is involved: I am just monitoring what goes out of my computer and network) showed that Abbott was using SSL to connect to its R&D Center and upload what looked like a significant data package. The upload site is actually defined in an .INI file in a "hidden"directory on your computer (Windows based PC in this case). The traffic is encrypted through SSL and, as such, supposed to be inaccessible to an eventual eavesdropper. This, of course, piqued my curiosity more than anything else: what did Abbott have to hide?

Finding out was relatively easy, as soon as I could find the time. It could have been harder if Abbott had implemented its "secure" exchange a bit better, but let's not forget that they are a medical device company, likely to somewhat blindly using secure standards without fully understanding them.

I set up a proxy and routed the Libre software traffic through it. This is a perfectly straightforward operation: your employer, security software or ISPs do that all the time. The Libre software happily established a connection with my proxy and my proxy established a connection with the Abbott research center. In that particular case, I wanted the Libre software to establish a secure connection with my proxy and my proxy to establish a secure connection with the Abbott upload center.

During the time spent on my proxy, the transaction wasn't encrypted.

So, what happens? In one single post, gzipped data is uploaded to the Abbot server (the connection is keep-alive, just in-case)

POST https://libreupload.freestyleserver.com/sutter/upload/universal HTTP/1.1
Content-Type: application/json
Content-Length: 734986
Connection: Keep-Alive
Accept-Encoding: gzip, deflate
Accept-Language: en-US,*
User-Agent: Mozilla/5.0
Host: libreupload.freestyleserver.com

And the server thanks you...

HTTP/1.1 200 OK
Date: Fri, 19 Dec 2014 21:42:31 GMT
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Length: 16

{"success":true}

The payload


As you can see, the server payload is quite large (seeing through the gzip compression is trivial) and contains a ton of data.


The data is neatly organized in json format (a common format to exchange data on the Internet). You'll see below how it is organized


Device settings limits itself to what I would call standard diagnostic information. This is what I would have accepted Abbott to upload to its servers.


The header part reports both the software and the device unique identifiers. That part if, of course, a bit (cough, cough) problematic... While the software didn't appear to report explicit user ID in the transactions I monitored, I did not dump my initial setup and all my connections to the Abbott server right from the start. Abbott could have sneaked a ton of info under my nose during the first few days. However, since Abbott only sells its devices through direct sales, it can certainly connect the serial numbers of its readers to UIDs. Abbott might at some point claim that they do not, but they haven't done much to earn our trust until now, did they?  It would be very surprising, even incompetent, if that correlation was impossible. 


The measurement log is literally a complete window on your diabetic life. Note: I did not make use the full data entry capabilities of the Abbott reader but it seems that Abbott is also interested in what you eat, how you exercise, what drugs you take and what your state of mind is (custom note). While I have not verified that all this information was actually uploaded to Abbott servers, this is obviously available for upload, should they be entered. I would advise against entering notes that are too personal. "Great night of sex leads to lows" would probably amuse some of the employees in the Abbott research center.


They upload all your Glucose entries: scheduled ones (the 15 minutes values) and unscheduled ones (the spot checks you do when you want them)



The eventual alerts, including ondemandalarm.low and projectedhigh. Note: that part is actually very interesting from a user point of view as it shows that the Abbott software is already ready for an eventual full CGM Implementation. 

And, of course, insulin entries.



Summary


  • The Abbott Freestyle Libre reader covertly uploads all your diabetes tracking information to its US servers. The user is not offered the option to opt out. Configuration files are hidden. Uploads are encrypted.
  • That information is can be tracked accurately through the use of UIDs.
  • That information goes well beyond pure glucose values information (insulin, exercise, medications and even your thoughts can potentially be uploaded).
  • The Abbott Freestyle Libre license agreement explicitly states that the above does not happen.


Additional thoughts



Had I been asked, I would have gladly shared some, but probably not all, our information with Abbott. The fact that it is done covertly, in flagrant contradiction with the Abbott license agreement itself, is completely dishonest.

As far as the dissimulation and the security of the process is concerned, I do not know if I must laugh or cry. It seems to have been implemented by a one-eyed guy targeting what he expected to be a blind audience. This is not unusual in the world of medical devices, where compliance with a certain set of rules, defined - at least in the field of IT security - by one-eyed regulators, is generally poorly implemented. While I will obviously NOT check other aspects of Abbott's security, in the wake of the Sony disaster, this is not very encouraging. I would have enjoyed a bit of a challenge, not a 30 minutes 40 tons truck drive through bales of hay.

As far as the data grab is concerned, while the implementation here is extremely heavy handed, this is a general trend. One very ironic aspect of it is that while Abbott only gives the user the opportunity to look at a limited history of his own diabetes, it stores and will store a much longer history on its own servers.





Wednesday, December 17, 2014

How much faster is the Freestyle Libre compared to the Dexcom G4 (non AP)?

One of the aspects of the Libre we subjectively noticed as soon as we started using it is that it seemed to react more quickly than the Dexcom when the glucose levels were changing. We noticed it on the first day and that was still the impression we had at the end of our 14 days test.

This being said, impressions can be misleading. Allow me a little rant here: the Internet is full of advice for Type 1 Diabetics, often offered in good faith by T1Ds trying to help others, but rarely supported by hard cold facts. Irrational stuff such as "my BGs are always higher on full moons" or "my CGM is always spot-on when I don't eat cheese" can often be read on boards (OK, I am possibly exaggerating a bit, but not by much...)  But the truth is that my own impressions are in no way more valid than the absurd statements above if they aren't grounded in factual reality. Since I don't have Libre sensors at the moment and can't productively continue my technical investigations, I decided to document that impression of responsiveness a bit more extensively.

The Method


As you probably all know, the Dexcom G4 provides a sensor glucose value every 5 minutes, the Libre has spot checks available every minute and an "historical" value is computed every 15 minutes from the stored spot values. That is that value that you are able to download from the Abbott software.

These differences in time scale make a direct measurement to measurement accuracy test a bit tricky from a methodological point of view. I am sure the marketing departments of either company could come up with a flawed comparison if they were going head to head. Since I needed to have a sufficient number of data points for a correct comparison, I decided to compare the Dexcom 5 minutes data with the Libre historical 15 minutes data. 

I also needed to exclude problematic measures from the comparison. The Libre missed a couple of hours when my son forgot to scan himself at school. The Dexcom lost signal from time to time, one of the sensors fell off, it had its restart, etc... I could, however, find a continuous 8000 minutes run where both sensors were operating simultaneously without any specific issues.

Then, I had to deal with the issue of having two possibly incomplete time series sampled at a different frequency. The way I chose to deal with that problem was to create two virtual sensors that sample the data every minute, fill-in the measured data for both sensors and interpolate the intermediate measures (linear interpolation). You can see the result of that interpolation below - the virtual Libre 1 minute sensor is in green, the virtual Dexcom 1 minute sensor is in Red.

As you can see, both sensors were well behaved during that particular period. The good news is that, globally, they saw the same thing. This is confirmed by a Pearson coefficient of correlation of 0.926 between the two virtual sensors over the whole period. 

The result

 

In order to estimate the difference in reaction time of the sensors, I assumed the Libre sensor was indeed faster based on our impressions and, of course, on the correlation with BG meter measurements during the test. Note: I am not publishing a direct Dexcom vs Libre vs meter MARDs at this point as I would not want to give a false impression based on a single Libre sensor.



















The short story is that the Libre was consistently faster than the Dex throughout the test. But how much faster?

The best way to find out is simply to shift our virtual sensors in time, minute by minute, and see at what shift we we get the best correlation between the two data streams. Remember that we are not trying to find out which sensor was the most correct in absolute terms, but just trying to establish without a doubt if our initial impression of speed can be factually confirmed.

The answer can be found below: the optimal correlation between the two sensors occurs if you either delay the Libre signal or advance the Dexcom signal by 9 minutes. Yes, the correlation differences are, relatively speaking, small. But keep in mind that these differences only come from periods where IG is changing. The 8000 minutes involved contain long stretches of relatively stable IGs where, of course, reaction time has no impact. The clear peak and dome like aspect of the time dependent correlation curve removes any doubt about the validity of the result.


In other words, the Libre will generally inform you of a change in interstitial glucose 9 minutes before the Dexcom does. In practice, that really makes a difference, especially if you take into account the fact that the Libre spot checks also seem to be ahead of the Libre historical data (maybe more about this later.)

Why is that so?

 

The Dexcom (non AP) algorithm is relatively well understood, thanks to the abundant literature on the topic and the fact that raw data can be intercepted. I won't go into details here, but we can say that it is delayed, in addition to the physiological BG-IG delay, by design. That design is a design that is constrained by the possible inaccuracies of a single Dexcom sensor measurement and it relies on the averaging of data and the application of a calibration "curve". It definitely seems that the Libre sensor provides more reliable data, but that is a complex issue that requires digging a bit deeper in the accuracy of spot checks. Indeed, it could be argued that the processing of immediate data into historical data could retroactively improve the apparent accuracy of the Libre. However, the Libre individual spot checks taken in real time correlate very well with the historical data - they are, as stated above even faster - and that seems to indicate that Abbott is clearly ahead either in its sensor reliability on a single measure or in its algorithms. Dexcom as just filed a request with the FDA for a sensor production process modification, let's hope this leads to an improvement in reliability.

Friday, December 12, 2014

Freestyle Libre: software to meter communications and sensor expiration.

Abbott Freestyle Libre local communications


In a recent post I wondered if SSL was required to protect local communications between the Freestyle Libre software and its meter. It would be a nice touch if it was used but, of course it is not (objectively, it doesn't matter - if your PC is compromised, there is no need to eavesdrop on your meter).

The Freestyle Libre software is interesting, in the sense that it somewhat breaks the mold of the typical diabetes tracking software that is either borderline patronizing or a bit hardcore for the average user, contributing to the "downloading of results" ceremony during the quarterly endocrinologist visit.

It's also very unusual in the sense that it requires the reader to be connected to the PC (and therefore, in most cases, that an upload to Abbott occurs) to access reports. The software doesn't even bother to store results locally but fortunately offers a decent export functionality...

Server and Client


That peculiar philosophy and the SSL upload mystery prompted me to have a deeper look a couple of days ago. How does this work?

It's fairly simple. When the reader is connected, it starts a server to which the local software connects. the parameters are in a config file in the installation directory (the default log path, loglevel and flages may have been changed here)

[General]
initialTcpPort=5347
tcpPort=5347
Flags=1
MalUUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
logLevel=1
logFilePath=C:/temp/mas.freestylelibre.log

The license information and the upload server are also specified in a config file, in the hidden "C:\ProgramData\Abbott Diabetes Care" folder. Please note that when I say "hidden", I mean that it is usually not visible to the non-technical user, not that it is intentionally hidden by Abbott.

[General]
app_license_path_string=C:/Program Files (x86)/FreeStyle Libre/license_en_GB.pdf
app_locale_string=en_GB
sutter_upload=https://libreupload.freestyleserver.com/sutter
installDir=C:\Program Files (x86)\FreeStyle Libre
Version=1.0

There is no need to use any fancy USB monitor to have a look at what is going on as all communications between the software client and the hardware server happen through sockets over that USB connection. Note: on the current Windows operating systems, traffic sniffers such as wireshark won't see the locahost to localhost connection and you will need to use a raw socket sniffer such as rawcap to catch the transactions.

Easy stuff


At that point, things become quite easy - you simply connect the reader and capture the transfer, then interpret the capture file with wireshark.


After an initial handshake and some setup exchanges, the reader delivers all the available data to the software client which then uses that data to generate the report. The 612 bytes records, which include some header and can be considered as 572 bytes records are transferred to the client. Just as it is the case with the sensor itself, the Libre operates on a circular Last In Last Overwritten buffer and that is why you can only keep and interpret a limited amount of data in that software.

There are several types of records, for immediate spot checks glucose values, historical glucose values, insulin, meal and exercise data, notes, error conditions, etc... The bad news is that the data delivered to the PC software is already processed (among other things by the active copy of the calibration data) and, in that sense, not helpful to interpret the raw sensor data collected by NFC.

The good news is that it is quite easy to interpret, This could be useful, for example, for someone developing an import module for a more generic diabetes tracking software. Since it is not my goal and I am perfectly happy with the official data export Abbott makes available, I will just go over the basics very quickly.

For an export record that reads like this


The data packet contains (important info highlighted)

There are a few peculiarities and different types of records. I will not go through all of them as I don't really use the insulin/food/exercise/note logging features or the internal glucose meter. Once you have a general idea on how to capture the data and a few test cases in your reader, unlocking the code is trivial.

One interesting side effect of that circular buffer architecture is that you can actually lose spot checks if you do too many of them and the table overflows. It is also unclear why Abbot would duplicate some information, such as the date in the above example but they may have their reasons.

The life of a servant is to follow orders.

That is also true for the server in the Abbott meter. You can send commands to it and retrieve explicit info or flash a new firmware if needed. Again, my goal here is not to explain how to patch your Libre receiver and I will simply show the simplest command that you can send to the reader to change its date - time.


In typical socket fashion, your post a raw packet containing your command and its parameters.

000c : 12
000b : 11
07de : 2014
0001 : 01 H
0012 : 18 min
001A: 26 sec

Again, it is easy to experiment with the local software and interpret the packets sent with each command if you are interested. This is left as an exercise for the reader, as they used to say...

Extending the sensor?

Some potentially bad news: while my sensor kept delivering data for a while after it had officially expired (20042 measures - Running Time : 13 days 22 hours 2 minutes - the clock of the device drifts a bit), it did stop a day later (21449 measures). The battery could deliver a 42 miliamp peak current at 1.59 V, an apparently higher load than the first one. That seems to mean that the sensor either expires by itself (or is actively stopped by the meter) but that also means that the battery does not seem to be the limiting factor (with the usual caveat that measuring the remaining capacity of a battery is tricky and that we now only have a sample of 2)

Running Time : 14 days 21 hours 29 minutes

Immediate Values
________________

0 : 91c3ecb45800 -8 min
1 : a083ed845800 -7 min
2 : 9fc3ed685800 -6 min
3 : 9c03ee509800 -5 min
4 : 9b43ee389800 -4 min
5 : 9b83ee209800 -3 min
6 : 9c03ef089800 -2 min
7 : 9e03eff09700 -1 min
8 : 8d83e7701a80 <<now>>
9 : 9643e8305a00 -15 min
10 : 9743e9ec5900 -14 min
11 : 9903eaac5900 -13 min
12 : 96c3ea745900 -12 min
13 : 9383eb3c5900 -11 min
14 : 9243ec0c5900 -10 min
15 : 8f83ece09800 -9 min


Historical Values
_________________

0 : 84c3eafc5800 -75 min
1 : 85c3e97c5900 -60 min
2 : 7003e9e85900 -45 min
3 : 7683e8205a00 -30 min
4 : 9543e9ec5900 -15 min
5 : 1b44e7201b80 <<last>>
6 : 7a04e7241b80 -465 min
7 : 7104e7341b80 -450 min
8 : 2204e73c1b80 -435 min
9 : f1c3e62c1b80 -420 min
10 : e7c3e9485a00 -405 min
11 : df83e8985a00 -390 min
12 : d403e8bc5a00 -375 min
13 : c143e6741b80 -360 min
14 : 5503e8ec5a00 -345 min
15 : 2c43e6ac1b80 -330 min
16 : 2703e95c5a00 -315 min
17 : 43c3e8385a00 -300 min
18 : 7cc3ec009900 -285 min
19 : 8683ee389800 -270 min
20 : a3c3efc89700 -255 min
21 : b6c3f0449700 -240 min
22 : ca03f2b4d600 -225 min
23 : f983f330d600 -210 min
24 : 1704f4fcd500 -195 min
25 : be43f4c4d500 -180 min
26 : 99c3f49cd500 -165 min
27 : e003f580d500 -150 min
28 : d283ed789700 -135 min
29 : c803ec505800 -120 min
30 : 9083eb805800 -105 min
31 : 9a03ebcc5800 -90 min

This being said, extending the sensor never was my goal and I definitely can't complain about its stickiness or performance during those 14 days.


Wednesday, December 10, 2014

FRENCH VERSION: Abbott Freestyle Libre: une chose que tous les utilisateurs de Libre devrait savoir

Note: une traduction rapide de mon billet en anglais sur le sujet. Si je suis francophone de naissance, j'écris et je pense habituellement en anglais - mes excuses pour les fautes de frappe, d'orthographe ou de grammaire qui pourraient s'être glissées ici.

La face cachée du Libre

Dans mes billets précédents, j'ai décrit, en termes très élogieux, les performances du lecteur Freestyle Libre d'Abbot. En tant qu'outil de suivi de glycémie, il est très impressionnant. Cependant, je ne suis pas aussi favorable en ce qui concerne l'éco-système. Le logiciel qui accompagne le Libre est certes innovant mais il a aussi une face cachée.

Si vous avez utilisé le logiciel qui accompagne le libre, vous aurez certainement remarqué que vous devez connecter le lecteur à votre ordinateur pour accéder aux rapports. En jetant un coup d'oeil aux fichiers installés avec ce logiciel, on remarque la présence de ceci


Il s'agit de la librairie de base d'Open SSL. Cette librairie est utilisée pour sécuriser les communications Internet et est même, dans ce cas, une version à jour qui corrige une vulnérabilité récente (par rapport à la date de publication du logiciel de Libre). N'est il pas merveilleux qu'une société qui s'occupe du traitement de nos données médicales se tracasse autant de notre sécurité?

Mais, au fait, à quoi sert cette librairie? Des connexions TCP/IP peuvent certes être établies est sécurisées localement, par exemple sur l'USB (c'est d'ailleurs ce qu'utilise le logiciel utilise pour communiquer avec le lecteur du Libre - mais ce n'est pas sécurisé). N'y voyons pas nécessairement malice. Mais restons curieux...

Le logiciel du Libre à la moulinette de Wireshark

Lançons un moniteur de processus et Wireshark et voyons ce qui se passe.


On peut voir que deux sessions sont démarrées. La première se connecte à l'adresse 50.57.212.161 and commence à télécharger des informations de ce serveur. Ce comportement est automatique au démarrage du logiciel. Le logiciel Dexcom Studio fait exactement la même chose et télécharge des données anodines du site de Dexcom (de façon transparente et non sécurisée). Ce n'est pas très grave, c'est un comportement typique de la plupart des logiciels actuels. Là où cela devient plus intéressant, c'est au niveau de la deuxième connexion, qui est initiée lorsque le lecteur est connecté au PC - regardez ce qui se passe ci-dessous.


Dès que le lecteur est connecté, une nouvelle session est ouverte vers l'adresse 74.205.93.86 et, dans ce cas, le trafic consiste essentiellement en des uploads (TCP Send). En d'autres termes, des données provenant de votre ordinateur (probablement du lecteur) sont envoyées à l'extérieur.

C'est quoi ce b.....?

Il semble bien qu'Abbott soit un peu curieux!

50.57.212.161 est hébergé aux Etats-Unis, chez le FAI "Very Curious Art"...


"Art le très curieux" - cela serait ironique et amusant si Abbott envoyait nos données chez ce bon vieux Art. Mais il semble que cette pointe d'humour leur ait échappé et ils se contentent d'envoyer les données vers 74.205.93.86, le "Abbott Diabetes Care R&D hosting center".


Comme le logiciel utilise SSL, il est difficile de savoir précisément ce qui est envoyé  (ce n'est pas impossible en utilisant une attaque Man-In-The-Middle locale) mais, au vu de la taille des données transférées, on pourrait imaginer qu'Abbott envoye vos données sur ce serveur américain. Vos données incluent potentiellement
  • vos valeurs de glycémie
  • votre traitement et le timing de vos injections (si vous les encodez dans votre lecteur)
  • vos repas et exercices (si vous les encodez dans votre lecteur)
  • l'identification du patient
  • des données système sur le senseur, température, taux d'erreurs
Potentiellement, une foultitude d'informations que vous pourriez considérer comme confidentielles.

Légalité? Consentement? Consentement informé?

Je ne suis pas juriste, je n'ai donc pas d'avis très informé sur le sujet. Je suis un citoyen Européen, et je vis dans l'Union Européenne. Je ne me souviens pas avoir explicetement autorisé Abbott à exporter mes données personnelles de santé vers des serveurs situés aux USA. Il se pourrait que j'aie implicitement vendu mon âme au diable en acceptant la license d'utilisation du logiciel (voir update 1 ci-dessous) mais, même dans ce cas, on ne peut parler de consentement informé dans le sens où il est habituellement compris dans le domaine médical. Il se pourrait qu'Abbott n'envoie que des données techniques sur les paramètres de fonctionnement du système. Il se pourrait qu'ils utilisent des données médicales de milliers de patient dans le cadre d'une étude qui a été approuvée... A ce stade, je ne sais pas...

Quoi qu'il en soit, je pense qu'il aurait été correct de la part d'Abbott d'informer l'utilisateur de l'existence de ces transferts au préalable ou d'autoriser ceux-ci sur une base "opt-in" uniquement.

Si cette situation vous embête, une solution rapide (mais probablement pas définitive) consiste à demander à votre firewall de bloquer ces transferts, par exemple de la façon suivante


Update 1: le CLUF d'Abbott précise clairement qu'Abbott ne reçoit pas les données de l'utilisateur et n'y accède pas. Cela ne rend cet upload secret que plus intéressant! De quoi ont-ils absolument besoin?

Update 2: j'ai reçu de nombreuses réactions à ce billet. Je souhaite préciser, à l'intention des utilisateurs non techniques, que l'information donnée ci-dessus ne prouve pas sans l'ombre d'un doute qu'Abbott uploade vos données personnelles sur leur site R&D. L'information donnée ici prouve simplement qu'Abbott y transfère des données chiffrées, sans aucun retour visuel ou information à l'utilisateur. La question principale est actuellement: pourquoi envoyer secrètement des données aux USA?

Tuesday, December 9, 2014

Abbott Freestyle Libre: something every Libre user should know!

The Dark Side of the Libre

In previous posts, I have written in glowing terms about the performance of the Abbott Freestyle Libre. As a glucose monitoring tool, it is extremely impressive. However, I am not too impressed (to say the least) with the ecosystem. While the Libre software is, in some ways, quite innovative, it has its dark side.

Users can't fail to notice that, in order to access reports, the Libre software must be started and the Libre reader must be connected to your computer. A casual look at  the files installed in the FreeStyle Libre folder shows this, among other files



That's the Open SSL shared library. This library is used to secure Internet communications and is actually (relative to its build date) updated for the latest SSL vulnerability known at the time. Isn't it nice to see a medical device company caring about the safety of our medical data?

But what is it used for? TCP/IP connections can be established and secured locally over USB. Nothing wrong with that even though it may seem a bit like overkill in this case. Could there be more to it? Let's find out...

UPDATE: since this article was written, I have decrypted the transfer. See here and here for more details about the content

"wiresharking" the Libre software

Let's fire up Process Monitor and Wireshark, start the Libre Software and find out.

As you can see, two remote sessions are started. The first one connects to 50.57.212.161 and starts downloading some information from that server. This session starts as soon as the Libre software is started, regardless of the presence of the Libre reader. The Dexcom Studio software essentially does the same thing, downloading harmless data and linking to the Dexcom web site (in an unsecured way). That's no big deal, most software today is connected to remote sites, if only to check for latest news and update availability. The data transfer for that session is mostly "download" - from the web to your computer. But look at this below (already apparent in the procmon capture above)


As soon as you connect your Libre Reader, a new session is opened, to 74.205.93.86 and, in that case, the traffic consists mostly of TCP Send, in other words, data from your computer (presumably the reader) to a remote address.

WTF, I hear you say?

It seems Abbott is a bit nosy here!

50.57.212.161 is hosted in the US, on the aptly named "Very Curious Art" ISP



The "Very Curious Art" name would be funny in a "gotcha" kind of way if that's where our data went to. But Abbott doesn't seem to have enough sense of humor for that kind of pun and the snoops are actually located at 74.205.93.86, the Abbott Diabetes Care R&D hosting center.


Because of the use of SSL, it is a bit hard (but not impossible with a local Man In The Middle attack) to know what Abbott is actually uploading there, but given the size of the data transfers, I would assume Abbott is simply covertly uploading your results to its servers in the US. Results that potentially include
  • glucose values
  • insulin values and treatment options
  • exercise and meal values
  • patient identification
  • system related data such as sensor error rates, temperatures, etc...
That's potentially a ton of information!


UPDATE: since this article was written, I have decrypted the transfer. See here and here for more details about the content

Is this legal? Have I given my consent? Have I given my informed consent?

Frankly, I don't know. I am a European Union citizen, living in the European Union, and I don't remember having explicitly authorized Abbott to send my health data to its own servers in the US. It can be that I have implicitly agreed to that data export by clicking on the license agreement (which I did not read, like everyone else) but that certainly wouldn't pass as informed consent or opt-in. It could be that Abbott only sends technical information back to its servers (but then, it could probably do it in smaller transfers). It could be that Abbott anonymizes everything it exports properly (you never know). Abbot might have good intentions, might be in the process of running a huge scale study on diabetics for which it has received approval. But I certainly would have appreciated to have received adequate information and to have been offered the opportunity to opt-out.

If that bothers you, a quick solution (but probably not a permanent one) is to use your firewall to block connections to those addresses - for example


Thanks for reading!

Update 1: I have now read the license and Abbott clearly states they don't have any access to our data.  Sounds fine, but that makes what they are uploading even more interesting in a way: what do they absolutely need?

Update 2: I have received quite a few reactions to this post. I'd like to clarify a bit for readers who don't have a TCP/IP or IT Security background. The technical information given above proves that the Libre software phones "home" in the US and uploads _something_ on their server. It doesn't prove that it uploads your data: it could upload engineering data from the sensor, integrity checks, etc... In fact, they could even covertly intercept your banking information or browsing habits, etc... and upload them (they don't do that I am sure). That's the main issue at this point: covertly uploading _something_ without being upfront about it (if only with a single message in the software) .

Update 3: the upload URL is located in the config file that can be found in the "hidden" ProgramData folder - in my case

C:\ProgramData\Abbott Diabetes Care 

in the FreeStyle Libre.ini file. Pointing that URL to an internal address, or entering bogus or empty data should also disable the upload.

[General]
app_license_path_string=C:/Program Files (x86)/FreeStyle Libre/license_en_GB.pdf
app_locale_string=en_GB
sutter_upload=https://libreupload.freestyleserver.com/sutter
installDir=C:\Program Files (x86)\FreeStyle Libre
Version=1.0

Friday, December 5, 2014

14 days with the Dexcom G4 (non AP) and the Freestyle Libre

14 days later
  • Important warning: this comparison is based on one Freestyle Libre sensor and two Dexcom G4 sensors. IT IS NOT STATISTICALLY SIGNIFICANT. If we had started with a bad Libre sensor, and if we had been running the supposedly improved 'AP' algorithm, our first impressions could have been different. 
  • Disclosure: we are 100% self-funded both for the Dexcom and the Libre. While I did purchase and sell some Dexcom shares this year, I currently have no financial interest or link with either Dexcom or Abbott.
  • Summary: the Libre outperformed the Dexcom G4 in almost every aspect. If we did not need night time autonomous alerts, we would have simply put the Dexcom G4 in a drawer.
 
Now that I have said that, more details.

We've collected a lot of data over the 14 days we ran both systems in parallel but giving objective numerical data is going to be a bit harder that I expected. I am still thinking on the best approach as there are a few issues that could bias the comparison in favor of one system or the other. The problems are mostly due to the different sampling frequencies of the devices. The Libre provides a new "spot-check" value every minute, the Dexcom every five minutes. However, the Libre "historical data" is smoothed on a 15 minutes basis. Comparing a meter test to an "historical" Libre data point is unfair to the Libre since, in practice, it reacts much faster to changes in glucose level when asked a spot check. In fact, it reacts so quickly that it is possible to see the changes induced by a meal or exercise in near real time. Looking at the last Dexcom trend value recorded prior the meter BG test is slightly unfair for the G4 as it is already a bit behind and this makes matters worse. Looking at the first value recorded post meter BG is also unfair if that value was used for calibration. I think I will proceed along the following lines: for every meter test, compare with the closest Libre spot check and the value that the Dexcom would have displayed at that exact moment. This is probably the most functional approach: when you want or need a meter test, you are likely to spot check and/or glance at the G4 receiver, possibly taking into account the slope of the curve.



The global view and general impression


\
This is a global overview of the last 13 days of the period.  I dropped the first day since both sensors misbehaved to some point (the Libre stayed too low for about 10 hours, the G4 behaved somewhat erratically). The Libre historical data is in red, the G4 is in green and the meter checks are black dots. Be careful not to draw very specific conclusions based on this graph: the time scale is huge compared to the daily charts we normally use. I will show event oriented smaller charts in the future.  

As you can see, both sensors saw roughly the same story: if you are interested in tracking your diabetes globally or reflect on the day's patterns, both systems are definitely up to the job and, on average, will not mislead you.

Each system has its character: the Libre is almost always faster than the G4 (this is by-the-way the reason why a pure accuracy comparison would give a very bad image of the Dexcom G4) . It is also, as already noted, more "trigger happy". Give the Libre a rising glucose level, see it shoot happily for the stars. We ended up liking that pessimistic mood as it was both an early warning and a motivation to control the situation. It's more emotional than rational but we felt happy to have been warned, happy when the meter confirmed the rise but also showed that it wasn't as bad as expected and, we felt a bit annoyed at the Dexcom that would have eventually warned us too late. Therefore, even if the Libre we had seems to have a tendency to overshoot highs a bit, we liked it better than the Dexcom that was slightly more accurate in its high values, but delayed. 

The Dexcom felt sluggish compared to the Libre and had a tendency to linger in lows, long after they had been addressed and corrected. Again, we preferred the Libre: it picked up corrections faster and was less stressful than the G4.

The sensors weren't perfect: the Libre missed a single clinical, meter confirmed, low on the third day. It wasn't far off but still in the OK zone. The Dexcom had a several misses that we found extremely annoying. For example, not to be outdone by the Libre, the Dexcom missed a bad low on day 12. There were more incidents, not visible on this chart as the calibration and interpolation between pre-calibration and post calibration data makes the Dexcom look better than it was. Since a single unattended error can mean trouble, we wouldn't run a totally automated artificial pancreas that aims for our level of control on either sensor alone. Of course, the Dexcom had its usual share of "compression events" leading to annoying false lows. The Libre had no visible compression event in this run (it is not however totally immune to them as I have noticed running a Libre sensor on myself). .

Two sensors are definitely better than one: with two sensors running simultaneously and a bit of attention (the clinical lows missed by one of the sensors), we really could have stopped pricking. In fact, during the second week, we took most of our decisions, including insulin shots, on the basis of the sensors alone and, to tell the truth, mostly on the Libre. We kept the two mandatory/recommended G4 calibration finger pricks and that was it. If we did a few additional checks, it was more out of curiosity than out of need. Unfortunately, running two different sensors simultaneously on a self funded basis wouldn't be possible for most diabetics and insurance or social security will find the idea hard to swallow... There was, however, an unexpected downside to running two sensors: we had learned to live with the Dexcom 15 minute delay and we mentally compute where we will soon be, based on the value displayed and the look of the curve. But having two devices show significant differences because of timing issues are definitely disturbing at first (for example post-meal, where the Dexcom would show 80 mg/dL stable and the Libre would show 125 mg/dL rising because it already had picked up the post-prandial increase). By the second week, we had adapted and usually considered what the Libre showed us to be what the future held for the Dexcom.

Overall, we trusted the Libre more than the G4:  the ability to see a trend that generally agreed with the Dexcom, while at the same time being ahead and spot-checking generally very close to the meter was a confidence booster. I plan to look at certain occurrences in detail and give some numerical data later, as soon as I have a bit of time.

An elephant in the room? No, there are more!  

There is, of course, an elephant in the room: while the Libre continuously monitors your glucose, it doesn't actively tell you about it. No alarms on lows you might be unaware of, no alarms on fast post-prandial rises (or for that matter, clogged infusion sets). The lack of alerts will be a deal-breaker for those of us who rely extensively on that functionality.

But, and this is where the situation becomes extremely frustrating, there are other elephants. 

The Dexcom data lives in the short term past. If it is all you know, you get used to it, adapt and interpret. But once you have tasted the Libre, this becomes very hard to accept. It's just like having two PCs side by side, one running Windows XP with 2GB RAM and a decent hard drive and one running Windows 7 with 16GB RAM and a SSD... In theory, the AP Dexcom firmware improves things a bit. I will of course test it as soon as it becomes officially available in Europe (note: a big public "Thank You!!!" to the two readers who offered to ship me an upgraded Dexcom receiver from the US so I could test it - there are amazing people in the diabetes community)

And then, the practical issues

Both sensors had a difficult start, for about 12 hours. The second Dexcom sensor was a bit better in that respect, not spectacularly accurate during startup, but not misbehaved either. The Libre told us once that it could not deliver a reading. The Dexcom went '???' a few times. The Libre insertion was painless, but the small trauma of the injection could be felt for about a day. The Dexcom's insertion was slightly more painful (we've had totally pain free ones) but couldn't be felt afterwards. The wound of the Libre was much cleaner and neater after 14 days than the Dexcom's after 9 days. I had hoped to run the Dexcom for 14 days - despite several adjustment and adhesive/tegaderm repair sessions, it proved impossible: the sensor fell off during the Saturday tennis practice. What became obvious is that living with a Dexcom isn't always easy: you've got to make it stick; it has to be dried now and then; after a few days, it is adhesion check and repair time; it needs tegaderm, hypafix, mastisol, skintac (which causes allergies with my son); it may require to undress carefully; you may need small scissors for repairs; you have to be careful with calibrations if you want to get the most out of it; the receiver has to be with the user at all times, etc...

Living with a Dexcom G4  is, of course, much better than living with 10+ finger pricks per day. But it is always a bit a matter of comparison...

On the other hand, the Libre had zero practical issues. While we put a tegaderm on it after a week because there was some slight peeling on the edges, it was excessive caution: we had to pull hard to take it off on day 14. You load the sensor, "fire" it, and then forget about it for 14 days. That scenario is, by the way, repeating itself with the 10 days old Libre sensor I am wearing as I write this. Max inserted it into my arm in about two seconds, I forgot it was there after 12-16 hours and, it has since been running with a MARD of 7-8% relative to a BG meter.

Let me finish on two totally subjective impressions:

Max (my son, nearly 14yo, T1D) told me this: "It's really strange, I found the Dexcom wonderful when it arrived, now it looks a bit lame and old."

As far as I am concerned (51 yo, not T1D, possibly at the edge of T2D, on the correct side for now), wearing the Libre is like having glucose sensing as a sixth sense. I could very well see myself wearing this permanently, just as some wear a fitbit. The info it provides on the impact of my eating habits is tremendously interesting and useful. Correction: if we didn't have to go through some hoops to get the sensors and kits (the Libre is not yet available in Belgium but fortunately we are a mixed Belgian-French family), I WOULD wear one permanently. 

I have never felt the urge or even desire to wear a Dexcom...

Thursday, December 4, 2014

RAW Libre Data Update

Quick update on the Freestyle Libre raw data format.

I have made some progress in my investigations and have developed a couple of utilities. The screenshots below should be self-explanatory to developers. I will not, for the moment, post a detailed how-to. If you can't make sense of what is shown below, please wait.

Here's what happens after a read - the wrap around table of immediate values is updated. The <<now>> pointer indicates the value that will be updated next.


As a sanity check, here is what has happened after 18 minutes. The table of wrap around values has been completely updated and the pointer for the next immediate value is now 2 records ahead. (18=16+2). The table of historical values has also been updated (with a somewhat funky looking value this time). In general, the behavior is quite consistent, but I have interrupted transmissions from time to time and other quirks, mostly due to the fact that it is a bit hard to scan the back of your arm with a large phone NFC sensor that needs to be quite close and stable relatively to the sensor to get accurate or uninterrupted reads.


I have a couple of ideas about that data itself, but they aren't ripe enough to be posted publicly yet. Stay tuned.

Note: I really, really like the Libre. If Abbott could market it more widely and as a full featured CGM, I would definitely buy one. Meanwhile, given the uncertainty, I might simply build one for my private use.

Note 2: this blog is made in ... which means that I can't typically have a quick meeting in DC or San Diego ;-)

Tuesday, December 2, 2014

November 2014 results

November 2014

The November results are out. No dramatic changes since October.


At first sight, lows have increased significantly: there are three reasons behind that increase.

The first one is treatment related: we have increased our typical Lantus from 16-17 to 17-18 U. That led to a small increase in the late evening lows due to the Lantus peaks we observe. At the same time, it also led to a slight decrease in the early morning averages. If that was the only factor, I would probably lower the Lantus dose back to 17-18 U

The second one is sensor location related: the Dexcom sensor was moved from the back of the arm to the lower back and this led to more compression events. During the second half of the month, we ran the G4 concurrently with a Freestyle Libre(*) on the back of the arm. Significantly less lows were reported by the Libre.

The third one is exercise related:  we've added a few hours of tennis practice, some of them extremely intensive, and have increased our post-exercise lows a bit.

Highs above 150 mg/dl have also increased a bit: most of them occurred after the morning snack and would fall into the "user error" category, in other words, excessive snacking. While I am never happy with a high, especially if I woke up early to prevent a strong dawn phenomenon, they are understandable.

* yes, there will be more info about the Dexcom vs Libre comparison and the Libre raw data, hopefully soon.