SoylentNews is people
SoylentNews
Eduard Marin and Dave Singelée, researchers with KU Leuven University, Belgium, began examining the pacemakers under black box testing conditions in which they had no prior knowledge or special access to the devices, and used commercial off-the-shelf equipment to break the proprietary communications protocols.
From the position of blind attackers the pair managed to hack pacemakers from up to five metres away gaining the ability to deliver fatal shocks and turn off life-saving treatment.
The wireless attacks could also breach patient privacy, reading device information disclosing location history, treatments, and current state of health.
[...] "Using this black-box approach we just listened to the wireless communication channel and reverse-engineered the proprietary communication protocol. And once we knew all the zeros and ones in the message and their meaning, we could impersonate genuine readers and perform replay attacks etcetera."
(Score: 5, Interesting) by bradley13 on Saturday December 03 2016, @05:24PM
The signals are not encrypted; there is no security to hack. This is a design decision. The manufacturers have some command protocol that they developed and use; while this may not be publicly documented, it is hardly secret: monitor the signals used, and you can figure it out. This doesn't take a "security researcher", all it takes is a kid with the right radio kit.
Consider: you have a pacemaker with a secure interface. You have a heart problem, and are taken to the nearest hospital. How does that hospital get the private key required to talk to your pacemaker? Which is the lesser risk to the patient's health: leaving the interface open, or securing it?
Everyone is somebody else's weirdo.
(Score: 3, Insightful) by RamiK on Saturday December 03 2016, @07:14PM
How does that hospital get the private key required to talk to your pacemaker?
0. Pacemakers shouldn't have built-in keys.
1. As part of the installation procedure, you create your own private key and install it as root trust in the pacemaker.
2. Using your private key, you log-in to the admin interface and install the hospital's public key for special and speicic operations (turn pacemaker on\off & logs...) but not the right to replace the private key. You do this with all the area's hospitals. A key ring might also work here.
3. If the hospital loses their key, they issue a revocation certificates to a prearranged key repository. You \ your IoT pacemaker occasionally pulls updates from there.
So, this way you're not depended on the manufacturer keeping their key secure. If you don't trust a specific hospital or care provider, you don't have to give them some or all rights. If you're traveling somewhere, you check up on the local hospital's sites and install their keys. If you're too lazy, you can just install some kind of state \ insurance \ manufacturer's run keyring's and you'd still benefit from being able to remove them if they're ever compromised. You can time limit certain keys - like say, you're going up on a plane and decide to give access to the airline for the duration of the flight....
In short, the GnuPG model.
compiling...
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @08:02PM
Unfortunately, it is difficult to have enough precognition to determine where you will end up in an emergency (not to mention the staff's familiarity with whatever tech you happen to be using). Hospitals on divert can have you end up in the strangest places, including a hospital several hours away if you happen to live in the boonies.
It might be wiser to have keys available to ambulance services instead of hospitals for just this reason. Still reasonably secure, but the keys can travel to the patient instead of vice-versa.
(Score: 2) by RamiK on Saturday December 03 2016, @10:06PM
staff's familiarity with whatever tech you happen to be using
This kind of key system will need to go through the FDA anyhow so it implies standardizing pacemaker protocols around it in the same way GSM is standardized.
It might be wiser to have keys available to ambulance services instead of hospitals for just this reason. Still reasonably secure, but the keys can travel to the patient instead of vice-versa.
Redundant with a local keyring. Ambulances and paramedics need certifying anyhow. Might as well give them a key and have them register as part of the keyring.
compiling...
(Score: 2) by maxwell demon on Saturday December 03 2016, @08:03PM
So, please tell me, what is the hospital you'll be delivered to in case of an emergency while on your next travel? Do you search out every hospital along your travel route to register all their keys?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @08:16PM
MD here. Upvote parent, this is the correct answer.
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @11:31PM
System designer here. Public key server or possibly a public block-chain (depending on merits of centralized vs decentralized) is the right answer. Don't let MDs decide technical issues outside their field of expertise is another correct answer.
(Score: 2) by RamiK on Saturday December 03 2016, @09:53PM
A time limited travel-route \ country wide keyring while traveling would be a quick fix. Maybe a small bar-code on a necklace or bracelet that you get before heading out that has the time limited key on it it... People with chronic conditions (allergies, chronic heart, pancreatic, renal problems...) deal with these sort of headaches all the time where they might be admitted to the care of doctor that doesn't have their medical records.
compiling...
(Score: 0) by Anonymous Coward on Saturday December 03 2016, @11:52PM
The most critical messages should be encrypted using symmetric cryptography. The passkey would be stored in software and carried by the patient in his/her wallet or house key ring. They would also be registered with the patient's health care provider(s).
Of course critical messages would include changing the passkey, and some way to do a secure ping to verify that the key is correct (the answer would be yet another numeric code, whose correct value would also be stored on the passkey card; failure would produce a non-matching code, indistinguishable in appearance from a correct value).
Status and other routine messages could be unencrypted, to give attackers less opportunity to monitor encrypted traffic.
This is all pretty much common sense.
(Score: 2) by Dogeball on Sunday December 04 2016, @03:36PM
Option 1) Tatoo the access code on the patient.
Option 2) Interact using a manufacturer-signed device that is provided to paramedics (I assume non-hackers need a specific device or software to control the settings anyway)
Option 3) Patient carries device or app paired to their pacemaker
Option 4) Hospital has ability to cut the damn device out and defibrilate the normal way.
It is emminently possible to make bad things as difficult as possible while making good things able to be done: this is called safety engineering.