Air gaps, revisited: change and obsolescence

I previously wrote about the importance of air gaps for security of networked systems. It’s worth noting another reason why an air gap can be useful: to avoid obsolescence. This aspect came to mind when I ran across a piece of hardware that I used for music recording. I quickly figured out that it wasn’t usable any more, which was surprising and a little weird.There haven’t been any changes in what I think of as the hardware and software that I use; but there have been some changes in what you might call the infrastructure or the plumbing, and those changes have been sufficient to cause a problem.

This kind of situation can arise in many ways, but we can take my specific device as an example. At a high level, it functions as a translator between two different ways of connecting devices, called MIDI and USB. The details of those standards don’t matter for this discussion, we can just think of them as different languages. My musical devices have MIDI ports, while my laptop has USB ports. There’s also a little complexity because there are lots of MIDI ports but many fewer USB ports, so the device is a kind of “mixer” as well as doing the translation.

Why, we might ask, is this device no longer usable? Neither MIDI nor USB has changed, at least not in any crucial way that affects this interconnection situation. None of my musical instruments have changed at all. My laptop hardware hasn’t changed, and the only software changes have been upgrading the operating system when the manufacturer recommended them. Explaining this situation requires understanding four different issues and their interactions.

First, it’s important to notice that my laptop is like many other generic work laptops: it’s asked to do many different tasks, in many different environments. It’s not dedicated to doing only the music recording work. Because my laptop is exposed to many different tasks and many different environments, I have to be concerned about keeping its software up to date. The laptop manufacturer fixes problems on a continuing basis, particularly newly-exposed security issues. In principle I could avoid all of these software updates, but it would be unwise to do so – I would be asking for trouble, going around with a laptop full of known bugs and vulnerabilities.

The second ingredient in the problem is an aspect of computers and software that is mostly hidden from users: drivers. Drivers are small specialized programs, and understanding their role requires stepping back a little to see the big picture of software and hardware. The programs running on my laptop interact with the outside world via fairly generic commands – they aren’t written in terms of specific pieces of attached hardware. In particular, the people who built my audio recording software didn’t know what kind of audio hardware I would use. Indeed, I might well use some piece of hardware that didn’t even exist when that software was written. Instead, pretty much any kind of hardware has an associated driver. The driver serves to translate generic actions into specific actions (and vice-versa). In our example of audio recording, the driver for the USB/MIDI device would translate actions by the recording software into actions for that specific device (and vice-versa).

Now we know about operating systems getting updated and about drivers, so we can explain the third ingredient in our problem: these two issues interact. Specifically, as the operating system changes, the device manufacturer needs to revisit the driver to ensure that it still works. Sometimes there’s an obvious need to change and retest the driver, because there’s been a change to how the operating system and driver interact. But even if there isn’t any change required, the whole driver has to be retested when the operating system changes – just to be sure that it all still works correctly. Software is notorious for the problem that seemingly-small, seemingly-harmless changes turn out to have large harmful effects – something I discuss in my book Bits to Bitcoin. So when the operating system changes, it’s not really sensible to just assume that everything will be fine.

The fourth and final ingredient in the problem is more related to economics than to computer science. I only paid the device’s manufacturer once, when I first bought the hardware. Although the manufacturer has done a reasonable job of updating and retesting the driver as the operating system has changed, they inevitably reach a point where they are unwilling to continue paying this expense. In principle, they should discontinue this support only when they aren’t making too many customers unhappy. The manufacturer usually plans the transition hoping that most of their customers will have moved on to newer devices with better features. But even if customers are still happily using the old device, the manufacturer will want to end the continuing cost of support before they have spent so much on those costs that the original device sale was unprofitable.

Let’s review the combination of these ingredients: there’s a changing operating system that requires ongoing driver changes, and a business model that offers the manufacturer no ongoing revenue to pay for those changes. It’s not surprising that the end result is that there comes a point at which the laptop operating system changes but the driver isn’t updated to match. At that point, the laptop owner (that’s me) has a choice: forego the operating system upgrade to keep the interface, or forego the interface to get the operating system upgrade.

The only sensible way to forego the operating system upgrade is if the operating system can be kept away from external threats (viruses etc.) as well as ensuring that it won’t need to interact with newer services or devices that depend on newer features. The best way to ensure all of those aspects is to isolate it from the rest of the world – but not the interface devices and associated musical equipment – with an air gap. The laptop stops being an all-purpose device interacting with the world; instead, it becomes a dedicated device for a recording studio that is separated from the world by an air gap.

If I’m not willing to give up the laptop by making it a part of an isolated recording environment, I have to give up on the USB/MIDI interface. It’s simply not supported in the updated operating system that I need to run. I can take my chances with the device, because it’s entirely possible that it will still work. After all, just because there are sometimes weird problems with software changes, that doesn’t mean that every software change causes weird problems. However, if anything breaks or works differently, I will be out of luck. Realistically, if I want to continue using my laptop in the wider world (with no air gap protecting it) I’ll have to buy a new USB/MIDI interface that has drivers on the laptop’s current operating system.

It’s worth noting that in a certain twisted way this kind of air gap is still a security mechanism. But instead of defending against an unknown attacker who is somehow seizing control of networks to mess with my stored data, this is a case where I’m “defending” against the operating system vendor. And rather than attacking me, they’re trying to help me (which in turn brings to mind a classic joke about the untruth of the phrase, “I’m from the government and I’m here to help you.”). If I don’t want their “help,” I have to isolate my computer physically – just as I have to isolate at least some of my backup data if I want to defend it against some kinds of sophisticated attacks.

Leave a Comment