Why Health Implants Should Be Open Source

0


As medical implants become more common, sophisticated, and versatile, it is essential to understand the code that executes them. A pacemaker or an insulin-releasing implant can save lives, but they are also vulnerable not only to malicious attacks, but also to faulty codes.

For commercial reasons, companies have been reluctant to open their code to researchers. But with lives at stake, we must be allowed to peek under the hood.

In recent years, several researchers have revealed deadly vulnerabilities in the code that runs certain medical implants. The late Barnaby Jack, for example, has shown that pacemakers can be “hacked” to deliver deadly electric shocks. Jay Radcliffe demonstrated a wireless way to get an implanted insulin pump to deliver a lethal dose of insulin.

But “bugs” in the code are also a problem. Researcher Marie Moe recently discovered this firsthand, when her Implantable Cardiac Defibrillator (ICD) unexpectedly went into ‘safe mode’. This caused his heart rate to drop by half, with drastic consequences.

It took months for Moe to figure out what was wrong with his implant, and it was made more difficult because the code running in the ICD was proprietary or closed source. The reason? Reverse engineering closed source code is a crime under various laws, including the United States’ Digital Millennium Copyright Act 1998. This is a copyright infringement, theft of intellectual property and may be a violation of patent law.

Why researchers can’t just look at the code

Beyond legal restrictions, there’s another reason researchers can’t just look at the source code the same way you might take your lawn mower apart. It takes a very talented programmer using expensive software to reverse engineer the code into something readable. Even then, it is also not a very precise process.

To understand why, it helps to know a little more about how companies create and ship software.

Software starts out as a set of requirements – software has to do it; it must look like this; it must have these buttons. Then the software is designed – this component is responsible for these operations, it passes data to this component, and so on. Finally, an encoder writes the instructions to tell the computer how to create the components and in detail how they work. These instructions are all source code – human readable instructions using English-style verbs (read, write, quit) mixed with a variety of symbols that both the programmer and the computer understand.

So far, the source code is easily understood by a human. But this is not the end of the process. Before software is shipped, it undergoes a final transformation: it is converted into machine code. It now looks like a lot of numbers. The source code has disappeared, replaced by the machine code. It’s now a bit like the inside of your car stereo; it “does not contain any repairable parts”. Users are not expected to play with machine code.

The alternative

The alternative to closed-source software is open source, which is available for free both as source code (published on websites) and as binaries or machine code. The philosophy of open source software is that there are no secrets and no property. In the MIT license, which is just one type of open-source license, anyone can download and use the software, and anyone can contribute to it, as long as the messages embedded in the source code are kept by its various authors.

The biggest difference between open-source and close-source is money. Closed-source software developers get paid because they have a monopoly on their software, and software sales generate income. Open source software developers must find another source of income.

You might think that no one can make money with open source software, but that’s not entirely true. Many businesses thrive on the distribution and support of open source software. Because open source software is written by programmers, usually for programmers, it is not as polished and easy to use as proprietary software. This gives a role to companies like RedHat, IBM, Oracle, Google and Mozilla, which make the experience of open source software more enjoyable.

Closed source or open source?

The argument has been raging for decades and focuses on issues of code quality and security. Supporters of open source subscribe to the ‘more eyes the better’ argument. If a programmer can see your code, the reasoning goes, he will find the bugs and tell you about them. The same argument is used to support the proposition that open source software is more secure.

Both claims are difficult to prove. Security vulnerabilities in openSSH (an open source tool for securing connections) are constantly being discovered, and the Heartbleed attack of 2014 was based on bugs in code that have been around for over 12 years. On the other hand, a vulnerability was recently discovered in a Windows automatic printer driver installer (closed source) that had been in the code for almost 20 years.

Closed-source advocates say their code is better because professionals (not hobbyists and volunteers) get paid to read the code and find bugs. Open source people point out that many closed source products (such as Windows, Microsoft Office, and Adobe Acrobat) are so big that no one, paid or not, understands all of the code.

Another argument in favor of closed source software is that bugs and especially security vulnerabilities (which do not affect the user) can remain hidden indefinitely. This is called “security through obscurity”. If you cannot see the errors, they cannot be used in cyber attacks. The opposite principle is that an effective security system is not based on secrecy; only a good design and a secret key.

How the code is fixed

When it comes to fixing code, the real difference between open source software and closed source software is who can modify, fix, or exploit bugs when they are detected. If it is closed source code, the user should report the bug to the author or software vendor. They then reproduce the crash, open their private code repository, find a way to fix the bug, and write a fix. Problems arise when products are no longer supported or companies extend “security through obscurity” to the point of ignoring, discrediting, or even prosecuting those who report defects.

On the other hand, when it comes to open source software, you can report the flaw to the team of volunteers who maintain the project through the public code repository (such as GitHub, SourceForge, or GoogleCode). Then if someone is working on the project (many projects are abandoned and not supported at all) they can fix the bug and then you can download and install the updated version. Of course, there is always the possibility that a malicious programmer could add “features” such as malware and backdoors to the software, although if others are working on the project, they should detect such tampering.

Implant makers should open source software

Having open source software running closed hardware is nothing new. The Raspberry Pi, for example, uses a proprietary Broadcom graphics processing unit (GPU), the internal components of which are kept secret. Broadcomm has released just enough information to allow any programmer to use the chip while maintaining a monopoly on the hardware design. In theory, nothing prevents implant manufacturers from doing the same.

The reason why they should do this depends on the real world experience. When someone’s pacemaker misbehaves, doctors, medical technicians, and their programmers don’t have the luxury of waiting for a manufacturer to release a fix or update. They need the fix immediately. This is why manufacturers only use light security on these products. When your doctor needs access to your device, there is no time to deal with cryptographic keys and authentication protocols. At most, they have time to find your device’s default serial number and password in your medical records.

Although this is a security flaw, the same imperative medical argument applies to the source code. If your device goes crazy, your programmer should be able to find the code quickly i.e. open source repository. When lives are on the line, there is no time for secrecy. Just publish the code.


Share.

Comments are closed.