|
|
|
|
|
by Odenwaelder
2612 days ago
|
|
I'd be interested how they test a Class C medical device that can kill you if you send the wrong commands. It surely is an amazing story and a great write-up, but I'd be wary of hacking insulin pumps, let alone using them. |
|
It is not a zero sum game. Not having this control over the pump can also kill you, because the systems that were available before this movement got started were so poor.
When the hacker community started putting together remote monitoring systems for the CGMs that allowed, e.g. parents to watch their kids at school, or through the night from the next room, that improved quality of life and maybe even saved lives.
Hackers have already tapped into the Medtronic pump to build the world’s first closed loop system. The OnniPod is just another pump in line to be reverse engineered.
If you saw first hand the quality of software being put out by Dexcom and Insulet, this work is serving as an important check&balance as well as pushing them to invest in R&D versus sitting back and milking their patents.
It’s also worth noting that the pod has important hardware safeguards that mitigate the impact of a software error on the remote control side. You can’t just send a message asking for 100 units of insulin because the hardware won’t dose it. You can also hear (and somewhat feel) each 0.05 unit of insulin being delivered as a click about once every 1.5 seconds.
And again I’ll reiterate that it’s not a zero sum game. The software and UI is so bad on the Insulet/Omnipod side that it’s easy to screw up a basal program, or when applying a temp basal on top of an extended bolus, or when changing a pod while an extended bolus is active. All these events can result in low blood sugar events that are potentially dangerous.
Efforts like Nightscout have actually saved lives and while they are not without risk (what thing worth doing is?), the T1D world has been measurably improved because of their efforts.
Finally I’ll says that the reverse engineering effort already uncovered one significant bug in the protocol that we know of. They didn’t delve into the details of the “nonce” but I’m willing to bet that imaging the chip was not actually necessary and that the “encryption” is some homebrew POS which is highly insecure. We deserve to know the protocol which is protecting the communication between the pod and the controller, for example is there a secure DH key exchange happening when a new pod is paired and initialized? Can a third-party controller potentially spoof commands to my kids’ pods? OmniPod would never disclose how this works, so I’m supppsed to just trust them.