4

I am currently writing an essay and one part is a discussion about the effects of encryption on an Operating System/Computer/Infrastructure in general.

However, I am struggling to see how a computer would be affected by encryption, whether it be full disk encryption or container based, beyond the performance of the system degrading slightly.

I am writing this in reference to encryption using software like TrueCrypt.

There does not seem to be any other kind of impact on the system itself. Most papers and articles all seem to point to and focus on the performance aspect.

Am I missing something obvious?

Any pointers would be appreciated.

7

There are several major impacts, not all of them relevant to all users.

  • Performance (based on throughput, i.e. MB/s - the more data you're moving in a given timeframe, the more encryption has to happen in that timeframe - when the encryption can no longer keep up, your data moves more slowly); if you use symmetric AES encryption with software that uses AES-NI instructions on a CPU with AES-NI instructions, this is more or less negligible even at GB/s rates.
  • Data loss risk: Any sector going bad on an unencrypted disk leaves the rest of the data available. On an encrypted system, if that sector contains your key, and the encryption was done properly, you just lost all your data unless you have a backup of your key.
    • So have a backup of your key!!!
      • and keep it secure!!!
    • This is highly desirable for fast easy disk wipes.
  • Certain backup factors - if you use liveCD/USB versions of drive image software like Paragon, Acronis, Ghost, etc., then that software can no longer do a normal, compressed, filesystem-aware backup. It must do a sector-by-sector image of the entire hard drive, since with good encryption, the "free space" is encrypted as well.
  • Partition management - just like with backups, liveCD/USB versions of GParted or Partition Magic can no longer modify the size of your partitions, since it can't move data around within your filesystem.
4

You are correct about performance. With symmetric key encryption, the performance hit should be very small.

The other effect is to render useless some operating system features. The one that comes immediately to mind for encrypted files (not full-disk encryption) is the content indexing and searching feature of Windows. If a file is encrypted, its contents are opaque to the operating system. Although it's a different concept, the same is true of grep and Linux systems.

4

Performance was once the biggie, but there's also the impact on low-level access and operations.

A good aspect to explore might be DRM. DRM is bad (or good) because it makes it hard to access your data in ways that you desire to. Almost always, there are very good reasons that you might want to access information in a non-standard or out-of-band way that the encryption system does not permit. For debugging, information transfer, monitoring, administration, maintenance...

As I understand it, the introduction of DRM into Windows added a significant burden for system designers, who, in order to get the "compatible" badge, had to create non-tappable video paths (that is, no test points or exposed wire, no data tracks running along the surface of the PCB, no exposed data pins on chips: how did they debug the signals in these devices?); and reading hardware that could not easily be reprogrammed (so no upgradable firmware, no replaceable proms...).

The requirement of full end-to-end security is that even when someone has access to your machine, they cannot access the data you send through those channels. Unfortunately, the MS approach was to protect Hollywood data (video bus), but leave user-data (cables to hard drive, keyboard, mouse, etc) in the clear, unprotected. Thus, DRM is useless for protecting user-data.

Another good thing to explore is failure modes. Prior to encryption, anything that went wrong with my hard drive (board failure, corrupt sectors, etc) I felt confident that I could resolve and repair - and time and again, I had recovered my data. But after encryption, when my boot sector (which held the encryption key) was overwritten on my encrypted drive, I lost decades of work and it cannot ever be recovered. Unlike any normal drive corruption, you cannot use any recovery tool known to man to recover data from damaged keys.

Offline and out-of-band tools cannot work on an encrypted datastream. You cannot perform partial offline backups of the partitions: you can only copy the entire encrypted partition, or mount it to copy folders. You cannot fsck an unmounted encrypted disk, view it with hex editors, virus scan it, run a meta-analysis to see how many png headers are on the drive, etc: you must mount it.

You cannot packetshape encrypted transmissions, inspecting packets to ensure that the most important traffic makes it through while unimportant emails and stuff get pushed to the back of the queue. You cannot filter encrypted emails for spam, viruses, or other unwanted content.

Can you debug an encryption application? If yes, then what's the point in encrypting, if another app can just hook it? If no, then how can you detect and fix bugs in it?

So: in sum, I'd argue that over and above the effect on server load, the effect on administrative tasks is greater.

There's also a false sense of security. If you have encryption on your system, you feel safe. Nobody can steal your data. Except, to use the data, you must mount it... so the data is available in the clear while it is mounted, available to read or send over any internet connection by any malware your system picks up. It's only actually protected when it's off! A server that's on 24/7 and has its encrypted partition constantly mounted, has gained exactly zero benefit from this protection.

All this said, I am an absolutely vehement proponent of encryption. I feel it should be built into everything, and should default to on for all forms of communication, even in the absence of confirmed identity.

2

Some questions that you can answer in your essay:

  • Who owns the data? Who should own the data?

    The user? The computer's owner (e.g. the user's employer)? The administrator? The operating system vendor? The hardware vendor? "Holywood"? (This ties in with @dewi-morgan's answer about DRM)

  • Who is responsible for ensuring legitimate users can access the data? E.g. making backups of the data AND making backups of the keys? And who is responsible for ensuring only legitimate users can access the data? To what degree are these two requirements compatible?
  • Which relations of trust are required? Do user and business have a choice and knowledge about whom they trust (and to what scope)?

    This issue is highlighted in the HTTPS model of trust, but it also occurs within the scope of file and disk encryption.

    (Within HTTPS a naive user assumes he only needs to trust the web server he communicates with (e.g. his bank); however, the user unknowingly trusts the browser's vendor, the computer's OS vendor, the computer's owner, a host of root CAs, the governments of the browser's and OS' vendors and of the (root) CA's. The model of trust of file and disk encryption does not include (root) CAs, but you can find most of the other entities.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.