"Even if entropy is low are - how are you going to randomly select a person, and know their serial ID ? Unless you know what units are distributed to what hospitals/doctors - at exact times - at exact shipments and then from the sample delivered know the exact unit given to any person at any particular time."
A sufficiently low entropy serial number would mean you don't need to know those things. Because it is low entropy.
1) if a person has diabetes [in this context]
2) if you know where this person lives
3) if you know a person uses a remote insulin delivery pump
4) if you know the model of the device
5) if entropy of serial numbers, for this specific device, is low enough
6) if you are able place a device within range to where this person is living for a sustained period
7) if you are able to ensure remote wireless control is on for this period
8) if you are able to then hack the device [edit: remove - in order to find the exact serial number of the device]
9) if you are able to then change the insulin delivery such that it injects too much or too little
10) if the person is unaware of such a change through external bio-identifiable changes [ http://en.wikipedia.org/wiki/Diabetes_mellitus#Signs_and_sym... ]
11) if the person consequentially is unable to reach medical assistance within such a period in order to receive more or less insulin resulting in their death
12) if you are able to remove any evidence of tampering with their device without being caught
yes, then this is a concern and low entropy is relevant. But pragmatically and realistically - if you can do all this - then you could execute a murder anyway :P
Also, point 8 makes absolutely no sense.
"but your dealing with minute hardware where every single ms of processing power counts. Simple encryption should be utilized [but then this might be easily hacked anyway ?] but for units placed inside the body [pacemakers and the like] - splitting the units resources between keeping the patient alive vs. encryption for wireless protocols seems to weigh more heavily on the former than the later given how unlikely - for the majority of the world - these 'attacks' are going to be."
So your solution is to increase security such that it compromises the functionality of the device itself through it's utility ? High security, poor battery life ? High security, high replacement cost ?
"Point 5 is the only one that I am concerning myself with." - and delivering insulin isn't important ?
Get realistic - security loopholes are only as important as what you are trying to practically protect and at what cost with what risk. This is what I am trying to make evident.
The assumption that every single manufacturer in the medical industry hasn't considered security of remote devices seems a far stretch to me given the prominence of medical litigation and the fact your dealing with someones life. Is a high security cost, high device cost, low battery life and therefore low adoption for patients and community accessibility acceptable? No, it's not.
The world is not based on everyone wanting to kill each other because entropy of serial numbers [which you nor I have any idea about] are low so they can hack insulin devices and kill someone. That said - it needs to be fixed with a balance to risk and all these other factors.
"2. "all he requires to perpetrate the hack is the target pump's
serial number."
Do we know how much entropy is in those? They could very
well be sequential or date derived.
Allow me to be perfectly blunt to get across my point once and for all: I don't give a shit about insulin. I don't give a shit about insulin pumps. I care misconceptions about security, and improper security implementation. This article serves as nothing to me other than a vehicle to discuss these things.
Most importantly: I am more concerned with your apparent suggestion that "a serial number is probably a sufficient shared secret" than I am with anything in the story. Serial numbers, as a general rule, make terrible shared secrets.
where have I made any such "apparent suggestion" in any of my comments. i haven't - i've stated that, and at least I believed I made quite clear, that the risk and practicality of using this hack is negligible. i haven't stated that it does not exist or that it should not be fixed. to the contrary - it should be fixed.
you're focusing on a singular aspect in a vacuum. "improper security implementation." - yes in this singular vacuum - you're correct and that's great - it's a concern. But what point is there focusing on security implementations in a vacuum when your dealing with real devices on real people and the practicality of using such improper implementations. The entire BlackHat conference is about exposing hacks in vendor-neutral software and devices that affect the real world. As I stated:
"Get realistic - security loopholes are only as important as what you are trying to practically protect and at what cost with what risk. This is what I am trying to make evident."
i'm focusing on the practicality in the real world as is the entire point of the BlackHat Security Conference. Arguably any device which opens itself to wireless communication could be hacked - and a device like this should have some cryptographic system requiring two separate keys - but at what practical cost is my point.
as hanslemen says in his article - the easiest way to resolve this is just to build in upper and lower limits of insulin delivery. at least you can't kill someone - but I acknowledge that even controlling it is a concern.
[peace, not trying to get all up and hot in here :)]