"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 :)]