SoylentNews is people
SoylentNews
Karen Sandler of the Software Freedom Conservancy delivered a keynote presentation last week at linux.conf.au 2018 (LCA) in Sydney, Australia. Specifically she spoke about her multi-year odyssey to try to gain access to the source code for the pacemaker attached to her heart and upon which her life currently depends. Non-free software is having an increasingly (negative) impact on society as people entrust more of their lives to it. That software is found in an increasing number of places, both high and low, as all kinds of devices start to run fully networked microcomputers.
In her first LCA keynote 6 years ago, Karen first told the people of LCA about her heart condition and the defibrillator that she needed to have implanted. This year she described her continued quest to receive the source code for the software running in her defibrillator, and how far she has been able to get in obtaining the source code that she's been requesting for over a decade now.
Source : Karen Sandler Delivered Keynote at Linux.conf.au
(Score: 3, Insightful) by JoeMerchant on Saturday February 03 2018, @07:16PM (10 children)
So, defibs are not my area, but are you telling me that EMTs can currently access pacemakers and implantable defibrillators? Seems, unlikely.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Saturday February 03 2018, @10:15PM
There is no industry standard; each device maker has proprietary protocols/hardware.
In order to access all brands, the EMTs would need a communication/control device from each manufacturer.
So, no.
-- OriginalOwner_ [soylentnews.org]
(Score: 2) by HiThere on Sunday February 04 2018, @01:00AM (2 children)
No. I'm telling you they need access, not that they have access. Currently access needs to wait until the patient gets to the ER. And, to be honest, most EMTs don't have even the ability to understand what they could read off the device to understand just how urgent action is...but they need read access. And the ER needs read/write access. (Which is also not universally available.)
The thing is, if every cardiologist and his staff has access to the read/write passwords, then you can't depend on those for security anyway. You get security by making it a near field device. But sometimes *FAST* access is necessary, or people die. That fast access saved my wife a couple of times. And if you make access complex, then in an emergency it will be fouled up. Somebody will misremember or mistype the passcode, and the device will refuse to respond. If you're close enough to treat a person, though, you're close enough to use a near-field controller.
There are lots of arguments about how things should be more standardized, and the current system has lots of places where it could be improved, but adding passwords isn't one of them. Neither is allowing wi-fi access...proximity *should* be required. The comment that the current generation of devices allow it is...well, I just hope it's wrong.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by JoeMerchant on Sunday February 04 2018, @01:46AM (1 child)
I think you're even stretching it a bit there... I know that implantable devices are programmable by the office of the specialist who put it in and does followup, but... EMTs, ERs, even general hospital wards - I think you're smoking crack if you think any of those places would begin to try to access the programmable functions of an implant.
As for wifi or bluetooth access - there's a problem with 2.4GHz penetrating flesh, so, no... that's not likely, ever. There are some near body wireless standards that have come into practice in the last 10 years, and bedside devices can bridge from those to wifi, or internet, or whatever - so there's your nightmare scenario, but if you just switch off the bedside device when not in use, that's a big step toward security right there.
Bottom line is: millions of people have had these things for dozens of years, and nobody has been hacked dead (that we know of) yet, so the system as it is is working - even with its flaws and incongruities with accepted cybersecurity practices in other areas. Room for improvement? Absolutely - my first day at the implant company I raised a stink about their wireless comm 8 bit checksum - some professional witness type blew a line of BS at me about the billions of years it would take for an accidental programming event to happen, I blew back in his face about 30,000 devices in the field and with any kind of noisy comms you could be having multiple mis-programmings per day, we smiled - dropped it, and worked professionally side by side for about 18 months until one day we were called into a room with the programmer software team - it seems that there had been about a half dozen reports of "painful stim" during programming events, common wisdom was that for every report there were likely 10 more unreported events... so, anyway, somebody who reported one of these painful stim during programming events went missing 24 hours after their appointment, no foul play or device involvement likely, but it was enough to spook leadership into ordering an investigation and later remediation. Investigation found that the painful stim was the result of the programmer being withdrawn from the patient during programming before comms were complete - the 8 bit checksum for full power? 00000000. We found a workaround in the programmer that used a different sequence of commands which were not susceptible to the pull-away problem, and that 8 bit checksum software continued to be implanted in new patients for another ~5 years until the new model with a 16 bit checksum rolled out.
🌻🌻 [google.com]
(Score: 2) by HiThere on Sunday February 04 2018, @06:24AM
I don't know about the hospitals you've visited, but my wife was accessed in the ER more than once, and it was quite necessary that she not wait for being admitted, or worse, appointment with the cardiologist. It would have been a lot better if the EMTs could have read the device and, if nothing else, transmitted it on ahead to the ER. They really need to be able to do that.
As for wireless connection...I was accepting an earlier post that said the current devices had that kind of connection. The only kind I've seen involves placing the reader over the device, and that's the way it should be done. And passwords, etc., are a bad idea.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by PocketSizeSUn on Monday February 05 2018, @05:04PM (5 children)
Yes.
According to my friends that work in the ER.
When a patient comes in with heart problems and has an implanted device (brady or tachy) step #1 is to assume the device is malfunctioning and disable it.
No the ER does not have to communicate with the device to disable operation.
Disclaimer: Worked > 10 years on pacemakers and ICDs
(Score: 2) by JoeMerchant on Monday February 05 2018, @06:14PM (4 children)
O.K. - so you're talking about the magnetic switch disable mechanisms, not the coded computer communications programmers.... Yeah, those are semi-reasonably standard, place a strong-ish magnet over the implant and it stops.
The coded computer communication interfaces work on a variety of frequencies and encoding schemes, and you basically have to have a programmer that matches the model of the implanted device, and we're talking about many dozens of varieties of commonly implanted devices - that's what I can't see happening at most ERs across the country, even some of the bigger and better equipped ones.
🌻🌻 [google.com]
(Score: 2) by PocketSizeSUn on Wednesday February 07 2018, @12:00AM (3 children)
Yes. Agreed.
The ER will just keep the magnet on and wait for a specialist to investigate.
And realistically with ultra low power devices like pacemakers having non-trivial crypto is a pretty far off bet. Only option I can think of is using the programming head to dump power to the device so it can startup the crypto and proceed to communicate in a secure layer. It's also useful model for talking to EOS devices but I don't know if anyone is currently pursing that (it has it's problems too, implant depth being the biggest).
(Score: 2) by JoeMerchant on Wednesday February 07 2018, @01:08AM (2 children)
The low power thing is a concern (our 7 year life device gave up a few months for typical communications activities), but crypto like a one-time-pad would be effective and negligible impact.
🌻🌻 [google.com]
(Score: 2) by PocketSizeSUn on Friday February 09 2018, @09:58PM (1 child)
Out of band distribution and secrecy around a OTP stored in EPROM would be a logistical nightmare IMO.
Maybe you are thinking of adding packet scramble using a OTP per comms session? It's a little more secure than requiring the session key added to every packet... mostly it will obscure more of the command layout for a sniffer. As an active system there should be plenty of available entropy for randomizing the session key/OTP.
(Score: 2) by JoeMerchant on Saturday February 10 2018, @05:12PM
To me, the point of the OTP isn't to make it impossible for people who have managed to get a copy of the OTP - sure, make that hard, but to me the real thing gained is the defeat of replay attacks. Add a couple of bytes when comms are initiated to allow the implanted device to establish the session key, and from that point forward it's all masked by the OTP, based on the implant selected session key - replay won't work, and guessing at how the protocol works without a copy of the OTP is much, much more difficult / time consuming.
🌻🌻 [google.com]