RJ> The DAR Tiger Team apparently considered the physical RJ> movement of media, including flash drives, as Data at RJ> Rest.
I defined the three states because I find (in my own muddled little brain) that it made sense for clarifying the various attack scenarios. RJ> I don't see a lot of difference between moving an RJ> encrypted file via a flash drive, and moving a previously RJ> encrypted file as an attachment to an e-mail message RJ> - both would seem to be Data in Transit, at least to me. In a purist networking sense, sneakernet is just an overlay network, so in one sense you're correct. Or, to be precise, transporting an encrypted file via some removable media would be equivalent to emailing a *currently* encrypted attachment. If you're emailing an unencrypted attachment, though, you're vulnerable to eavesdropping or a MITM attack; whereas you can MITM the guy carrying the USB drive, but all you're going to get is the storage media with encrypted contents. RJ> But others might want to reserve the Data in Transit term to RJ> plaintext data that is being sent over an encrypted (and RJ> perhaps authenticated) session/channel Ah, a wrinkle. Well, true, there is a defense in depth difference between transporting plaintext data through an encrypted channel and transporting encrypted data through an encrypted channel. However, I'll stick to my definition because in order for the data to be compromised, in either case, the session has to be compromised first. When considering how to protect Data in Transit, you should be concerned primarily with maintaining the secure channel. RJ> Unfortunately, these definitions, or at least the way I was using RJ> them, do not adequately cover the "ALL THE REST" kinds of data that RJ> are the most troublesome - the temporary files, not-yet-scrubbed RJ> free space that previously contained sensitive data, the page file, RJ> hibernation file, and other typically "unseen" data. I don't have RJ> a good name for this kind of data - I wish someone would RJ> invent one. How about "Exploitable Ancillary Data" (EAD)? If you're using my (admittedly broad) definition of "Data in Use", you're right, these would be subclasses of "Data in Use", depending upon what layer the data is actually "in Use" at -> by (my) definition, it's not encrypted data on disk, but it can be unencrypted in swap, or in local disk cache, or on processor cache, resident memory, etc. There are a *lot* of vulnerability spaces here. Given a significant enough boundary on processing power, I suppose the ultra-paranoid could say that all I/O sessions should also be encrypted end-to-end, so that you can't MITM data passing from the paging file to resident memory, etc., but I'm personally of the opinion that this is using a bazooka to try and kill a butterfly. But I digress. RJ> I would argue that Data at Rest problem is adequately solved by RJ> existing FDE solutions, at least if the disk encryption key is RJ> protected by a two-factor hardware cryptographic token, preferably RJ> using a strong ECC algorithm for the wrapping, and with a RJ> hardware-enforced limit on the number of incorrect PINs that can RJ> be entered. I agree. If you're using my version of "data in use", you also cover some of the vulnerabilities of "data in use" with an FDE solution. There is, however, administrative overhead to this solution. Two-factor authentication mechanisms come with their own overhead, however, and may not be feasible for organizations above a certain size. (I know someone who works at JPL who pretty much spends all of his time dealing with RSA SecureID tokens). Plus, you don't want anyone to do this: http://worsethanfailure.com/Articles/Security_by_Oblivity.aspx RJ> However, this solution DOESN'T protect the data from the some RJ> other user who has access to the computer, whether that user be the RJ> system administrator, someone with a Guest account, or perhaps RJ> your teenage game-playing son or daughter; nor does it protect RJ> against any malware that might be running. Yes, that was more or less the reason why I said that given today's OS market, it is essentially impossible to really secure data in use. RJ> And BTW, I am not convinced that a virtual partition is sufficient RJ> to solve either of these problems, although a RAM drive would help RJ> a lot if temporary files could be confined to it reliably. And I RJ> disagree that it is unnecessary or undesirable to encrypt the OS RJ> files in an FDE solution. So do I. The ease of management and the benefits of just encrypting the entire drive make this a no-brainer, IMO. RJ> Unless you use something like Tripwire to hash all of the OS files RJ> against a digitally signed record, it is difficult or impossible RJ> to be certain that someone or something hasn't covertly buried RJ> some data in a file that is not likely to ever be used, e.g., one RJ> of the Windows update rollbacks. One of the pretty obvious steps towards improving OS security is to keep hashes of the OS operational files. Of course, you have to have a reasonable method for making this usable; if after every Windows Update Vista's UAC popped up 132 times with the dire "THIS FILE HAS CHANGED" warning... Regarding the "Data in Use" section: RJ> That's close, but to my mind it doesn't quite deal with the RJ> case where there are multiple processes running simultaneously, RJ> e.g., in user space and system space, or two different users RJ> running simultaneously, and it implies a degree of memory RJ> protection that is clearly out of scope for most commercial RJ> operating systems. Unfortunately, this is true, memory protection is horrendous, which is why in 2007 and we still have buffer overflows... but I can't imagine an operating system that won't have multiple processes running in both user and system space; so... really... to solve the problem of protecting data while it's in use, you have to beat on your OS vendor. Any steps you take here are going to be constrained by the fact that whatever bolt-on solutions you build or acquire, you're still dependent on the OS to handle moving the data off the disk, launch the process to convert it to plaintext, and drop it to the location that you're going to read/use/manipulate it. RJ> It also doesn't deal with various kinds of observable data, RJ> including Simple Branch Prediction Analysis attacks, where a spy RJ> process running on behalf of one user or process can determine the RJ> encryption key being used in a different process by means of a RJ> timing attack. Now you're getting really tricky. Side channel and timing attacks are going to be the hardest to defend. In the particular case of timing attacks, the only way to offer any sort of defense against them is to deliberately salt decryption processes with lag. Given that encryption/decryption is already a performance issue, intentionally making your algorithm less efficient (and to a random degree!) isn't going to be a really suitable solution. Again, I think the right way to solve this is at the OS level. If you segregate user-level processes from system processes and arrange it so that user-level processes can't monitor each other, you mitigate this somewhat, since a side-channel attacker would need to operate in system space to get useful information. Admittedly, you still have to protect the system, but you're going to have to do that anyway. re: "Data in Transit" RJ> I think most people would tend to separate the security of the RJ> information flowing over some kind of a transport medium RJ> (electronic or not) from the issue of the security of the RJ> information once it arrives; the assumption being that such data RJ> is more easily intercepted off the wire than by prying it out of RJ> the computer. You're right, that paragraph was written poorly. My intention was to say precisely that. RJ> But if the problem is limited to detachable/removable media, RJ> then various solutions can be used to bind or seal the encrypted RJ> data to the host computer so that it can't be decrypted on an RJ> unauthorized computer, even if he has possession of the data and RJ> the cryptographic token, and knows the PIN. Assuming the attacker can't reverse-engineer the binding. Hm. I'm going to have to muse over this one for a few days before I decide whether or not I agree with you here :) RJ> I agree, although most of the security mechanisms actually RJ> being used today are not strong enough cryptographically to RJ> protect the data for more than a few years. RSA-1024 is on RJ> the verge of being broken today, and will surely be possible RJ> within the next decade. And using AES-256 with an 80-bit RJ> equivalent public key algorithm, or a 32-bit equivalent RJ> password, worse yet, doesn't make any sense at all. SHA-1 is creaky, MD-5 is basically broken, and yeah, people still use them. Bad IT people! No biscuit! Joking aside, though, workable tools are there. As long as you're keeping abreast of which algorithms are still considered reasonably secure, you should be okay (at least, until the quantum computing nuts actually figure out how to use qbits). I will say, though, that security solutions that don't let you "drop in" different algorithms should be generally considered poor solutions. If you're locked into a particular cryptographic algorithm and some enterprising crypto geek publishes a weakness at a Black Hat conference, you have to dump your solution and start over again, hardly economically feasible. RJ> I'm not quite as pessimistic. In the case of our Hydra PC RJ> token, the red light isn't just a small LED that could easily RJ> be overlooked - it lights up the transparent end-cap with a RJ> very bright red light that is about 1/2" by 1" and is pretty RJ> obvious. This sounds workable. Generally speaking, I'm not fond of solutions that require the user to do much, but this sounds better than most. RJ> One of the most serious and inexplicable omissions in Outlook RJ> and Exchange (all versions) is the ability to easily screen RJ> incoming e-mail based on whether it is encrypted and/or RJ> signed. Speaking from experience, very little about Exchange makes sense to me; from the storage model to the client model and most everything in between. I cordially loathe Exchange. :) _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
