I was reading the other encryption thread and had a couple of related questions occur to me:
a) Why are governments/military so determined to use dedicated hardware to encrypt data. I could be wrong, but I’ve been around a few military systems and they all seem to use hardware. It would seem that with modern micros, software could do the job quite adequately.
b) Do any government orgs use PGP? I remember hearing about a US President (Carter or Clinton, I think) using PGP to digitally sign a bill regarding encryption export restrictions. This may have just been some kind of stunt.
WAG - software would make it easier for someone to ‘steal’ government-military encryption technology - software can be copied, can be recorded on very small media nowadays or transmitted easily.
Getting a piece of encryption hardware off the premises is harder.
Encryption in hardware is usually faster, cheaper and easier to analyze for failure modes. The last item is important and often overlooked in commercial products. There are also issues of maintaining isolation between unencrypted data and encrypted data. How do you prove that unencrypted data can never leak out of the system, even when components fail?
True enough and certainly an idea. Real crypto places are pretty strict about such things. I’d think the NSA or the like would be amazingly pissed if they caught you with a RAM-drive.
As mks57 notes, isolation is a big part of it. Often software encryption is entirely within the province of the operating system and works only in that context. Even in the case of persistent storage, the OS provides an encryption layer when reading and writing to a hard drive, but that layer is a software construct: if you take out the hard drive and stick it in another machine with another OS, is the data still secure? If the encryption is fortified or hardware-based (on-board the drive itself), the data is encrypted before transmission to the OS.
Think of those news reports you hear every now and then about a government employee who misplaces some laptop with a hard drive full of sensitive data, be it Social Security numbers or the CIA NOC List If you wanted to hack into the data, the first thing you’d do is take out the hard drive and try to see what’s on it. Unless the hard drive has on-board encryption, it’s much more vulnerable to being compromised.
So when you say “software can do the job adequately”, you’re right, it can–but only as long as the software is running.
I take your point about analyzing failure modes but it wouldn’t be that difficult to simply ban any and all software on a machine except for the crypto package. You could even back it up by removing/disabling the floppy/CD-ROM/USB ports. The network would still be a path, but I would think this sort of machine would be hooked to dedicated FO networks. The commercial products is a point, but the government surely has the skills to roll their own, with any reasonable amount of testing they desired.
Having plain-text suddenly spew out due to a malfunction could also happen with a hardware device. After all, you can’t really prove that it couldn’t ever happen, just that it hasn’t happened yet. This one seems a wash, to me.
I admit I’m stuck on the data separation issue. That seems a real problem. I think it is probably solvable but I’m very certain I’m not going to be the guy that does it.
Thanks, but I would disagree with some of this. I would do the same as you, pull the drive and try it in another machine. OTOH, if I write an encrypted file to a hard drive, (using PGP for example) it will still be encrypted regardless of what machine I put it in. Even if I get the drive with the keys I still don’t have the necessary pass-phrase.
I understand about having an encryption chip on the drive, but wouldn’t that be somewhat limiting? To change your encryption method you’d have to throw the drive away and get a new one. This idea reminds me a lot of the DRM techniques that MS Vista is requiring for High-def video. Maybe I should take a better look at this and try to find out how they’re using those chips.
Well, you’re in good company. First, you have to remember that knowing how to generate your own keys and encrypt a file using PGP places you in a category different than the majority of users, who comprise the target audience for most discussions about computer security standards. We’re talking about broader standards that might be more secure for users who mainly rely on whatever encryption layer the OS provides, usually a transparent one they may not even be aware of.
Second, yes: there’s always the chance of a unique and potentially catastrophic failure in any system, but we can establish pretty confidently through testing that it will be a much more uncommon occurrence than, say, Dirk leaving his laptop at a Starbucks. Even your encrypted PGP file could be vulnerable under certain circumstances (say, for instance, you saved the script that created your keys complete with passphrase in an unencrypted file on the same disk…don’t laugh, it happens). And no one can predict the future; Dirk might also figure out how to factor large integers quickly and thereby render all RSA-secured systems vulnerable in one fell swoop. Not impossible, but not likely, either. Chances are much better than Dirk will leave his password written on a post-it stuck to his laptop
You also have to decide which level of security you need/want. If someone has your encrypted files or even your (encrypted) keys, PGP is very good at making sure that the attacker can’t decrypt these. For many everyday uses that all we want. If you are a military user and you have really important secret data, you need a different level of protection. For example your software implementation of PGP has to work with your secret key. It might use lots of clever techniques to hide the key, but the bottom line is: The unencrypted value has to be available in some form for a short time. How safe is that value? Can any other running program read it? Can the OS? What happens when the OS decides to swap exactly the wrong piece of memory to disk at exactly the wrong time? …
Even if your solution works reasonably well in practice, proving that it’s safe or convincing a very cautious customer is a different thing.
Take a real life example: hardware security modules inside ATM’s. They’re the onboard computers present in all ATM’s that perform the encryption and decryption of your credit card data when you wish to take out some money. The HSM’s are configured so that they instantly flash themselves if they detect anomalous voltages on their input lines, and have several tamper proof features other than these.
The hard drive isn’t the only concern when encrypting data. For instance, suppose you use PGP on a standard PC. The OS could harbour a rootkit, spying on the user’s input, the PC itself could have been compromised so that unencrypred data is read from the IDE channels before encryption etc etc. With specialist hardware, you can specify exactly which channels are to carry encrypted data, and which are not, with the ones carrying encrypted data protected like the aforementioned HSM’s.
Yes. But for situations where specialist hardware is actually necessary (military, diplomatic, business etc.), this is not really a major inconvenience.
Sequent
I take your point about someone saving a file with their passphrase/keys in clear text. Yeah, it’s a lot more probable than someone breaking RSA. I’ve seen way too many security setups be avoided or disabled because they were onerous for the users to comply with.
Thank you, Sequent. You’ve given me something to think about.
Another issue would be random number generators. All encryption schemes need to generate random numbers at some point in the process; if you can recover what random numbers were used, you can crack the encryption. Most computers can produce pseudorandom numbers which are good enough for many purposes (say, making the AI in a game unpredictable), but for true random numbers, like you’d want for military-grade encryption, you need specialized hardware not found in most off-the-shelf PCs.
I disagree there are many decent sources of good random data on a off the shelf PC. You can do what PGP does when generating public private key pairs. Measure the time between key strokes and measure mouse activity. You can measure the time between hard disk interrupts. Additionally you could do things like measure the line in on the sound card. Look at the input from a web cam etc. There are lots of ways to get a few hundred bits per second of random data.
I understand your point on the OS being compromised in some way. What I really had in mind was a PC running some kind of open-source OS with the users being forbidden to change or add anything at all. A complete black-box where clear-text goes in and cipher-text comes out. This could be enforced by disabling or removing the CD, USB ports, floppy drives, etc. You would just need a network I/F to get your data into the thing.
As far as the anti-tamper mechanisms go, I would think a PC could be made extremely secure. Sealed boxes, alarm switches, and, in many communications centers, armed guards.
Speaking of the ATMs, don’t those things run some flavor of windows? I ask because I almost stuck my card in one a few days ago when I noticed the screen showed “Restoring Desktop.”
That’s dependent on having direct human interaction with the computer, which may or may not be available.
The web cam or sound card has to be looking at or listening to something that varies randomly. If it’s something internal to the system (watching a lava lamp, say), then that’s a specialized piece of hardware. If it’s something external, an eavesdropper could attack the system by looking at or listening to it himself.
I can’t think of any encryption algorithms that use a random number generator. Random number generators are often used to generate keying material, but that’s a different issue.
Things like encryption for web pages generate new keys each time you set up a new session. An early version of the netscape browser had a pretty week method of generating session keys. The key basically depended only on the time of day that the local computer reported which realistically narrowed the number of possible keys to a few thousand down that a third party that new the time of day to try.
The point being that encryption is a whole system and key generation is an integral part of that system.
The idea isn’t to make the crypto hardware difficult to access, but to be *impossible * to access. The self-destruct mechanisms make it excessively difficult for someone to say, yank an ATM out of a building with a backhoe and try to figure out the hardware in their secret lair.
If you wanted to hack into the data, the first thing you’d do is take out the hard drive and try to see what’s on it. Unless the hard drive has on-board encryption, it’s much more vulnerable to being compromised.