Replies to This Discussion

Permalink Reply by AndyRozman on June 9, 2009 at 12:46am

You can try... but be prepared to fail... It's easier to "hack" meter2PC protocol, because it's simple, and even with that you have some unidentified variables, but with device as complex as Pump or CGMS, different types of data, you can have quite a problems...
And I am almost sure that wireless communication has at least some protection here...

Plus firms couldn't use data you gained, which would mean you would have to rewrite pump software from scrach (since you don't have original firmware code).

Andy

Permalink Reply by Tony Elmquist on June 9, 2009 at 6:22am

Something to do in my copious free time ;) I'm most interested in seeing if I can figure out how my sensor and CGM communicate... probably won't, but it's fun to ponder. Wonder what sort of encryption might be in the sensor data stream...? I'm no tinfoil-hat-wearer, but it'd be nice to know that the status of my blood is semi-private... :)

Permalink Reply by Jake Falk on July 8, 2009 at 9:00pm

I'd be interested in knowing as well. If I have some spare time at work I should dig out the spectrum analyzer and see if I can pick anything up.

I also have thought about having a go with the firmware on my animas 1250. the interface design is next to awful compared to modern cellphones. maybe when its time for a new pump.

Permalink Reply by SS on January 9, 2010 at 7:45pm

Cool - it would be fun to check it out w/ a spectrum analyzer.
(And then of course decipher it, hack the pump, tie in some ghetto logic somehow - nothing to it (hehe/just kidding, but it's fun to think about).

The fcc doc (from the fcc site below, and attached) tells us the frequency (and also how these companies hate competition!).
http://hraunfoss.fcc.gov/edocs_public/Query.do;jsessionid=LJ1KF4spH...!199172167!784297639?numberFld=&numberFld2=&docket=&dateFld=&docTitleDesc=dexcom

(It operates "...on only one frequency (402.142 MHz +/-40 kHz), occupying only 120 kHz of bandwidth, at a power level less than that permitted in the MICS band (-20dBm conducted), and for only 6-9 milliseconds every five minutes")

Attachments:

• FCC-06-1A1.doc, 72 KB

Permalink Reply by Gil DePaula on July 31, 2010 at 9:15am

Guys,
I know the protocol used by the MiniMed Guardian RT CGM and the Insulet OmniPod systems.

I can't confirm nor deny that the data is encrypted or if it's just transmitted over a single frequency. I can say that there are several safety features, including an ID number being attached to the message so the receiving device knows it's intended for it, and not its neighbor, in an "OmniPod User's Convention". :)

The keys are the frequencies and the protocol/message formats, which I'm not about to reveal since it's the companies' proprietary information AND because what you're trying to do could lead to someone's death, including your own.

Just remember that the SW in these products went through YEARS of testing by different people/groups/companies, and then through the scrutiny of the FDA and other countries health regulatory agencies, all in an effort to ensure nobody would get hurt by it.

I don't mean to patronize you on what's dangerous or not, but I'm concerned that if you can figure the data out and make that public, someone it's going to end up using that knowledge to deliver a 50 U bolus, instead of 5 U, just because they were careless.

If it happened, would you like to live for the rest of your lives with that thought in your mind? Those are the things that SW/HW/Mech engineers working on medical devices have to to be concerned about.

Have fun, but please know your limits.

Cheers,
Gil

Permalink Reply by scrain777 on March 1, 2011 at 4:58am

I heard a talk by David Kotz recently where he was talking about this. Seems there is a lot that needs to be done to make these things secure. He mentioned some work where researchers demonstrated ability to cause a heart attack by hacking the wireless protocol of a pacemaker. Maybe you do want that tinfoil hat....

Permalink Reply by Gil DePaula on March 1, 2011 at 9:06am

Yep. I can see that happening and that's why I'm against this game. I know that sometimes I sound a little apocalyptical, but if someone breaks the receive/transmit protocol of an insulin pump maker, and that knowledge ends up in the wrong hands, could the knowledge be used by someone to randomly send bolus commands at an ADA conference? Ok, maybe it sounds like a bad sci fi book/movie, but just never say never.

Permalink Reply by bewest on March 5, 2011 at 2:32pm

The communication protocol has redundancy and identity
checks that insure intent. In fact, in order to use the
protocol, you also need to know the code printed on my
pump. As a pump user, I'm satisfied by this level of
security. If someone intends to do harm to me, on a
practical level this is a rather difficult way do so. Are
there really groups of people out to do me harm using a
tiny radio to give me too much insulin? How much TV have
you been watching? The device should insure that whoever
meant to administer a drug really meant to, and at some
point had physical access to the device. I'm not sure how
much more is really reasonable. It might be nice to
change the IDs so that you can revoke someone's access
later, but this doesn't seem like an effective argument
for keeping the protocol proprietary.

When I walk into any given doctor's office, their first
question is "is the pump working?". The more experienced
the doctor, the faster they ask this question. Their
definition of "working" is quite wide, ranging from site
problems to pump software malfunctions. They generally
don't trust the device, partially because it's operation
is so opaque.

Obscuring the protocol from those looking to verify the
absence or presence of defects in the device, or from
effectively auditing the therapy the device provides is
dangerous. It prevents the peer review process from
building trust in this otherwise elegant technology and
puts people in the position of having to experiment
without sufficient technical details.

When I dose insulin giving the pump, it performs
calculations according to a model with many factors that
influence how much insulin is given. Anytime I take
insulin, whether or not a pump is used, I'm essentially
making a prediction about what will happen over the
subsequent hours. How much of a drug to administer is
ultimately my decision. Unfortunately, access to the logs
shaping and recording those decisions are secret, actually
hampering my ability to make better decisions, or even
communicate what happened effectively to caregivers.

Every day the protocol is kept proprietary is a day that
no one can verify that the device works without
the manufacturer's help. For many people, despite the
software that manufacturer's provide, this involves
spending hours reading a tiny screen over the phone, or
transcribing into another computer. In addition, it puts
users in a lurch when the company is unable to devote
enough resources to solve problems. EG, for a while it
was impossible to buy a new computer (Windows 7/Vista?)
that worked with Medtronic's software. If the
communication protocol were open this never would have
happened.

The risk that someone might die by accidentally mis-using
the protocol is not a problem of security, it's a problem
of adequate peer review, exaggerated by a failure to share
critical information. A user of a medical device should
never be prevented from accessing his or her own medical
data. Programming errors are solved by peer review and
test suites, not by obscurity masquerading as security.

From my perspective, the risk of reduced health outcomes
because I lack access to sufficient data is much larger
than accidentally dosing myself with buggy software. IE:
accidentally giving too much insulin because the software
I was using failed to provide enough of or the right
information to me is *much more real* than some hypothetical
software accidentally giving me too much insulin because
of a programming error. The risk that doctors will make a
decision because they don't trust the device is more real
than the risk of a hypothetical programming error.

What's really shameful is that it's easier to download
data from my meter, which has much fewer responsibilities.
It's easier to download data from my iphone, which has no
responsibility for my health, than it is my pump, which I
depend on every day. If I don't trust the meter, or if
the company fails to provide a windows update, I can
download it's diagnostic data and verify it myself.

-bewest

Permalink Reply by Gil DePaula on March 6, 2011 at 9:44am

After figuring out the protocol, if you first "listen to/sniff" a message/response exchange between the hand-held controller and the wearable insulin delivery device, then you will know the delivery device's ID and the current messaging sequence number, as they are part of the messages. After that, on your PC/transmitter, you would build a bolus message with that pod's ID and the correct sequence number, and send it to the delivery device.

I agree that the risk of of software bug is MUCH larger than that of a security breach, of course. But it's still EXTREMELY small because of the MANY passes/tests/safety features that are in place in such devices.

Do you also take your car's braking system apart and verify it before driving the car? No.
Come on, confess. You're just a techie geek (like me) and you just have this uncontrollable urge to figure these things out. :) Just keep the info well protected once you figure it out, which I'm sure you will.

Permalink Reply by bewest on March 6, 2011 at 11:49am

Doctors routinely make decisions throughout therapy that
are driven by how reliable they feel the device is. They
aren't being provided with sufficient information to make
the best decisions. The risk of making poor therapy
decisions due to a failure of a manufacturer to provide
for every possible use case (an impossible expectation) is
very real. The question is not how many people might be
harmed by hypothetical security breaches or software bugs,
but how many people have been harmed because the
manufacturer's software doesn't satisfy their use case or
simply failed to communicate therapy details, ie, the
known logs, effectively? If the protocol were open,
someone could at least have a chance at providing the
auditing the data that better regulates therapy. In situ,
FDA and manufacturer testing mean nothing. FWIW, at my
work we face the same question from our customers: "how do
we know it does what you say it does?"

When a patient develops problem, and the doctor spends 6
months trying to figure out what kind of problem the pump
is having, isn't that more dangerous than a hypothetical
security breach or a hypothetical programming error?

This is an issue of ethics, not some desire to poke
around. The pancreas does an amazing job at regulating
insulin. Insulin is a powerful and dangerous drug that we
are terrible at administering. It's amazing insulin
therapy works at all, and the amount of information I'm
given to actually drive dosing decisions vs the amount of
information available is shocking. It forces me and many
other pump users to model the interactions in our heads,
or on scratches of paper, or in spreadsheets. All of
these methods introduce opportunities for all kinds of
errors.

Just to be clear, is anyone denying that there are serious
problems with getting the right kind of information at the
right time when dosing insulin? Communicating pump
therapy data with caregivers? The forums are filled with
horror stories using all kinds of software, and the hours
of effort people go through to put together spreadsheets.
For users of Linux of Mac there are even fewer options,
and even more effort required. Even if you manage to get
everything working, you might buy a new version of Windows
that locks you out of your own data again. Meanwhile we
blindly trust the device to do the right thing, even as we
fail to fully understand the control we have over the
pump. For these people, there is a health toll paid
every day via sub-optimal or *incorrect* therapy decisions
made due to the lack of information and the opacity of the
device's activity.

To this day, each time I dose insulin, the pump treats it
as a one time event, and fails to show a comprehensive
model of what might be happening. Which is more
dangerous: a hypothetical security breach, software bug, or
incorrect dosing because the device failed to communicate
the right details to me?

Since I happen to be a software engineer, I happen to have
many of the skills necessary to solve some of these
problems and unfortunately there is a real need. The idea
that the method to retrieve diagnostic information is secret
from me, the user, becomes a moral issue under this lense.
I don't particularly want to write software formatting
bytes on a wire, I'd much rather be writing software for
my work: far more lucrative. But if there is no
software that is even capable of maintaining a simple
ascii record of therapy details, then I am left with no
choice but to provide it myself. Because I believe it's
immoral to bar users from access to their own medical
data, it'll be published open source once it's working. I
just don't view the risk of accidental or malicious harm
as seriously as the risk or poor health from poor
or misguided software.

It would be arrogant for a single company to think that it
can provide one piece of software that will work for
everyone, especially when medical devices are their core
competency. They generally acknowledge this by publishing
software requirements. The issue is that a patient should
always have access to their data; via proprietary software
or not. The idea here is that it's dangerous to keep this
stuff secret from patients.

-bewest

PS
I'm so grateful to Gil for providing his perspective. The
devices themselves are quite elegant and so far have been
a pleasure to work with.

I don't mean to criticize the efforts manufacturers have
put into their products, but despite being a software
engineer and having access to many computers, I've never
actually seen Carelink run successfully (eg, it cannot
download both my OneTouch Ultra and my pump data).
Someone recently pointed out that it might be good for
type 2 diabetics who don't have a need for near-real-time
information. Does anyone involved in building/designing
this software actually have type 1 diabetes? Last time I
forgot my password and the password they generated for me
failed. I generated new passwords every hour for four
hours before they let me log in. Software is hard to get
right. Optimizing for slightly different use cases can
get you very different results. I also generally only use
Ubuntu inside a VM on mac, partly for security reasons,
but mostly because I love xmonad, so it's quite an ordeal
just to get their software to run at all.

Speaking of software security and fantasies, the greatest
risk is not from some group of terrorists or saboteurs
high jacking the wireless protocol, but from internet
bandits taking over via the combination of MSIE+JAVA
holes. A bot-net is far more likely than saboteur. The
irony is that there's more focus on IE security that
pump security. Really now, let us return to core
principles. Obscurity is not security.

Permalink Reply by David on March 6, 2011 at 8:34am

You're not apocalyptic, you're accurate! However, whether or not this information is publicly released doesn't mean that the information isn't being acquired in private. "Breaking" a protocol that doesn't have some cryptographic security and authentication in place is unlikely to be very difficult. I highly doubt that some engaging discussion is going to influence that outcome.

Since the perceived risk today is low there is no regulation by the FDA or FCC on the amount of security required on wireless medical device communication. But as scrain777 mentioned, there is already industry awareness of the lack of security in many new wireless medical devices on the market. That should also be apparent by the number of people simply discussing it on this forum. In the future, the risk will rise and I'm sure the industry will eventually respond.

As far as it sounding like a bad sci-fi book/movie, imagine how easy it will be to do this once software-defined radios become commonplace. At that point you wouldn't even have to build a radio to communicate with the device, you'd just have to load in the right software to your mobile phone to do it all. Of course, by that stage, I hope there will be no technological reasons (like lack of battery power or excessive cost) to forgo adding crypto to all devices.

Hopefully the standardization of WBAN protocols will provide vendors with some enticing options for power-efficient, secure communications.

Permalink Reply by Craig on August 24, 2009 at 9:13pm

I want to hack my device. But not for fun. I just think that the user interface sucks. I just posted this before I read your post:

"...my Minimed Paradigm, shows me when i'm trending up or down, but there is no alarm or vibrate to call it to my attention. So, an hour passes - my BG increases by say 100 points - and bang, I'm over 200. What's the point of the thing if it doesn't warn me about trends? Seems like a minor hack to add a rising or falling trend alarm."

What do you guys think? Is it doable?

• ‹ Previous
• 1
• 2
• 3
• …
• 8
• Next ›
• Page