4 ms·

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, b

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.

couchand 7y ago
OTOH if the OEM can't code the CRC right, one might be better off packing their own parachute...
- Odenwaelder 7y ago
  No, you're not better off. If you want to get a medical product like this licensed, you have to prove that you performed rigorous, multi-staged testing and document all your development including all emerging risks. I have participated in such licensing efforts and I doubt that an open source project has the means of providing such rigorous testing.
  - stefan_ 7y ago
    The result of this diligent process, of course, is how a broken CRC16 routine got shipped in this medical product. It's the most trivial thing. Copy a public domain CRC16 routine, add a unit test with a test vector.
    - joezydeco 7y ago
      Can you be sure it wasn’t a badly implemented form of obsfucatiom? It certainly slowed down the reverse engineers. If they didn’t get to the object code what would the next step have been? Cryptographic analysis?
      - stefan_ 7y ago
        5 of the bits were never set in their "obfuscated" variant? If you want to obfuscate CRC16 you would just choose a randomized starting value.
        joezydeco 7y ago
        I didn't say it was implemented well. Perhaps they should changing shift operators would quietly change the values without any disturbance to checksum integrity.
  - mikelward 7y ago
    Tidepool is indeed working on FDA approval for Loop. https://www.tidepool.org/blog/tidepool-delivering-loop https://www.tidepool.org/blog/tidepool-delivering-loop
zaroth 7y ago
You can read about the “We Are Not Waiting” movement and the ethical considerations of doing this research, writing the software, and documenting and even to an extent productizing the software for mass consumption. 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.
- Odenwaelder 7y ago
  Thank you for your reply, very interesting! I have no doubt that this project is great help to many people, and it's a shame that any medical device of this kind is closed source. Being involved in the development of medical software, I know how important testing is, and given the chaos that reigns in some open source projects, I'd be wary of hacking a medical device. I see both sides and surely it's a balancing act.
mox1 7y ago
The other unfortunate side-effect of this research is that they just explained in detail how to hack into an un-suspecting users pump. Imagine the other version of this story, where an advanced attacker does all of this, because "Prominent Political Figure X" wears this insulin pump...
- rtkwe 7y ago
  This isn't enough to attack the pump in that way you'd still have to defeat the pairing step to make the pump accept commands from a transmitter.
- bleair 7y ago
  Aside from all the technical arguments, why don’t more devices give me clear explicit control (pairing, even if I want to allow remote control) and even better transparent indication of how the device is running
  - emiliobumachar 7y ago
    To what extend would you be willing to write down a living will exonerating the manufacturer and be extra clear with your loved ones that you're choosing to take a risk?
rstuart4133 7y ago
> but I'd be wary of hacking insulin pumps, let alone using them. If you have type 1 diabetes hacked insulin pumps or otherwise, the disease will kill you prematurely. It's a question of "when" rather than "if". Mostly this is because the disease requires constant attention - attention of the sort humans aren't good at providing, even if their life depends on it. Listen to this talk about OpenAPS. See where she says so has to wake up on average 200 times a month - or any 6 times a night, every night, regardless of whether she's pulled at 24hr day or had a good night out to monitor her levels: https://www.youtube.com/watch?v=p76hGxv3-HE I know the authorities will find it an anathema, but this is a very good argument for allowing the development of open source medical devices outside of the current regulations. The existing system is about controlling the private sector - making sure someone doesn't kill someone for the sake of a quick dollar. Open source turns that equation on it's head. No one is selling anything - so there is no quick buck to be made. It's just sane, sensible people trying to stay alive, and are very, very aware if they get it wrong it will kill them. While there is a cost advantage as the talk makes plain this isn't what motivated them. Their hashtag spells out the motivation: #WeAreNotWaiting. Waiting means a chance of dying. A capitalist system that has to be tightly constrained by government regulation to prevent it from killing too many people turned out to be far slower than open source doing the same thing. Again, listen to the talk. Listen to the lengths the people who use OpenAPS went to make sure their novel devices didn't kill them. Learn how they voluntary pooled millions of device hours of data, and made it open available so they could all learn from it. Unlike you, I'd trust OpenAPS firmware long before I trusted some closed source solution on the promise that "we are making money from it - trust us". Thanks all the same, but I'll prefer to trust the people who would be killed by it if they get it wrong.

couchand 7y ago

OTOH if the OEM can't code the CRC right, one might be better off packing their own parachute...

Odenwaelder 7y ago
No, you're not better off. If you want to get a medical product like this licensed, you have to prove that you performed rigorous, multi-staged testing and document all your development including all emerging risks. I have participated in such licensing efforts and I doubt that an open source project has the means of providing such rigorous testing.
- stefan_ 7y ago
  The result of this diligent process, of course, is how a broken CRC16 routine got shipped in this medical product. It's the most trivial thing. Copy a public domain CRC16 routine, add a unit test with a test vector.
  - joezydeco 7y ago
    Can you be sure it wasn’t a badly implemented form of obsfucatiom? It certainly slowed down the reverse engineers. If they didn’t get to the object code what would the next step have been? Cryptographic analysis?
    - stefan_ 7y ago
      5 of the bits were never set in their "obfuscated" variant? If you want to obfuscate CRC16 you would just choose a randomized starting value.
      - joezydeco 7y ago
        I didn't say it was implemented well. Perhaps they should changing shift operators would quietly change the values without any disturbance to checksum integrity.
- mikelward 7y ago
  Tidepool is indeed working on FDA approval for Loop. https://www.tidepool.org/blog/tidepool-delivering-loop https://www.tidepool.org/blog/tidepool-delivering-loop

zaroth 7y ago

You can read about the “We Are Not Waiting” movement and the ethical considerations of doing this research, writing the software, and documenting and even to an extent productizing the software for mass consumption. 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.

Odenwaelder 7y ago
Thank you for your reply, very interesting! I have no doubt that this project is great help to many people, and it's a shame that any medical device of this kind is closed source. Being involved in the development of medical software, I know how important testing is, and given the chaos that reigns in some open source projects, I'd be wary of hacking a medical device. I see both sides and surely it's a balancing act.

mox1 7y ago

The other unfortunate side-effect of this research is that they just explained in detail how to hack into an un-suspecting users pump. Imagine the other version of this story, where an advanced attacker does all of this, because "Prominent Political Figure X" wears this insulin pump...

rtkwe 7y ago
This isn't enough to attack the pump in that way you'd still have to defeat the pairing step to make the pump accept commands from a transmitter.
bleair 7y ago
Aside from all the technical arguments, why don’t more devices give me clear explicit control (pairing, even if I want to allow remote control) and even better transparent indication of how the device is running
- emiliobumachar 7y ago
  To what extend would you be willing to write down a living will exonerating the manufacturer and be extra clear with your loved ones that you're choosing to take a risk?

rstuart4133 7y ago

> but I'd be wary of hacking insulin pumps, let alone using them. If you have type 1 diabetes hacked insulin pumps or otherwise, the disease will kill you prematurely. It's a question of "when" rather than "if". Mostly this is because the disease requires constant attention - attention of the sort humans aren't good at providing, even if their life depends on it. Listen to this talk about OpenAPS. See where she says so has to wake up on average 200 times a month - or any 6 times a night, every night, regardless of whether she's pulled at 24hr day or had a good night out to monitor her levels: https://www.youtube.com/watch?v=p76hGxv3-HE I know the authorities will find it an anathema, but this is a very good argument for allowing the development of open source medical devices outside of the current regulations. The existing system is about controlling the private sector - making sure someone doesn't kill someone for the sake of a quick dollar. Open source turns that equation on it's head. No one is selling anything - so there is no quick buck to be made. It's just sane, sensible people trying to stay alive, and are very, very aware if they get it wrong it will kill them. While there is a cost advantage as the talk makes plain this isn't what motivated them. Their hashtag spells out the motivation: #WeAreNotWaiting. Waiting means a chance of dying. A capitalist system that has to be tightly constrained by government regulation to prevent it from killing too many people turned out to be far slower than open source doing the same thing. Again, listen to the talk. Listen to the lengths the people who use OpenAPS went to make sure their novel devices didn't kill them. Learn how they voluntary pooled millions of device hours of data, and made it open available so they could all learn from it. Unlike you, I'd trust OpenAPS firmware long before I trusted some closed source solution on the promise that "we are making money from it - trust us". Thanks all the same, but I'll prefer to trust the people who would be killed by it if they get it wrong.