[andrewstuart2]

So, run it over a VPN.

I'm not saying that they shouldn't add security to their protocol, but I can think of several ways off the top of my head to stay secure. The application-layer protocol doesn't have to be the one to implement it, network-level encapsulation can help you there.

I'm not sure how old the protocol is, but perhaps it was more important to get it working and wrap it in a VPN and then iterate on that design.

[maffydub]

Agreed.

It looks as though the researchers saw that as a possibility too:

"It is possible to temporarily mitigate the flaw by implementing the following workaround: Researchers have demonstrated that ITP can be operated over TLS/DTLS, using certificate-based authentication to ensure the security and integrity of the protocol."

I don't really understand why this is only a "temporary mitigation", though, rather than a reasonable long-term solution. Can anyone enlighten me?

Maybe the extra technical complexity of setting up these certificates is deemed too great, and the likelihood of people getting it wrong too high?

[tptacek]

Why is that a "temporary" fix? Segregating insecure protocols to VPNs, encrypted tunnels, and backchannel networks is one of the oldest most time-honored tools in the security design toolbox. Not only is it a real fix, but it's probably the right fix.

[toomuchtodo]

If systems are life critical, you go so far as to use leased lines or other physical layer segregations. Treat it like a refinery, transformer substation, or natural gas pipeline terminal SCADA system.

EDIT: Easy on the downvotes folks. If you disagree, engage me in discourse. As an infrastructure/network/devops/it generalist role, I have seen terrible things happen when you don't properly segregate critical systems from public networks.

http://scadastrangelove.blogspot.com/

[jarman]

Especially considering that protocol will be bound to expensive, long-living and heavily certified hardware, so it will stay there for decades.

[thirsteh]

You must not have gotten the memo: Google exposed some of their corporate systems to everyone, therefore VPNs are now useless and have always been useless.

:)

[jasonjei]

Agreed. Trusting VPNs to be totally secure, especially on a big organization like a hospital, seems insane. At the surgery level, you want to make sure the malware infected laptop or some open wireless access point doesn't come up with more creative surgeries.

[jasonjei]

I guess my confidence in the telerobot is lowered by the fact that the protocol doesn't ensure authenticity of surgery instructions. It leads me to believe what other flaws (including those outside the scope of security) exist.

Hopefully, we're still testing these surgeries on mice and not men.

[andrewstuart2]

A VPN with only two valid certificates means that the guy holding the other cert (assuming you have one of them) is definitely who he says he is.

[jasonjei]

You are right, but I'm alluding to the intrinsic security flaw of the robot. What other flaws could exist? They need not be security related.

[pavel_lishin]

Yeah, I sure would hate for a cosmic ray to flip a bit while an instruction is en route, and instead of gently cutting out my appendix, having the robot suddenly deprive me of a kidney.

[tedunangst]

How likely is that, versus the possibility that the surgeon operator has an aneurysm or seizure mid procedure. Or the nurse hands the surgeon the wrong chart?

[tedunangst]

Are you confident that telesurgery developers are better at encryption and authentication than VPN developers?

[jasonjei]

No, did I imply so? Just saying that I have very little confidence in the bot. I'm saying the intrinsic security flaw of the robot allows me to believe there are more serious defects. These do not need to be security related. The test cases not passing could lead to death.

I've made no commentary on VPN. Just commenting the communication protocol without augmentations (VPN, TLS, certificate, or otherwise) instills little confidence in the rest of the product. I wouldn't want to be operated under the bot.

[tedunangst]

I'm afraid I don't see the connection between the decision not to implement encryption and the presence of death causing defects.

[jasonjei]

> I'm afraid I don't see the connection between the decision not to implement encryption and the presence of death causing defects.

That's fine. Everyone is entitled to his/her opinion. I view the failure to implement encryption as a fatal error and an indication the code audit hasn't been thorough. Given that this is a telesurgery product, I'm quite confident encryption, trust, and authenticity are central to safe medical procedures carried over network. Otherwise, why would we bother with TLS when we access our online banking?

I'm just not confident I would want to undergo a surgery with a telesurgery robot with the "decision not to implement encryption."

[athenot]

VPN may sound archaic to those outside of health, but there are quite a few intra- and inter-hospital links that rely on VPN. Even with hospital SaaS vendors, it's not uncommon.

It's not like surgery robots move around the network and come online at unexpected locations. Those installations are planned ahead and the IT considerations are part of that deployment. Also, encryption is important but so is available bandwidth and bandwidth quality: a jittery link could be as dangerous as a compromised one.

[higherpurpose]

The same VPNs that use weak DHE crypto?

https://weakdh.org/

[juliangoldsmith]

Just use IKEv2, and you won't be affected. Or just don't use MODP1024.

[icebraining]

An even simpler approach would be to connect both ends with spiped: http://www.tarsnap.com/spiped.html