Re: Disk encryption advice...
On 10/08/2010 04:27 PM, Perry E. Metzger wrote: > I have a client with the following problem. They would like to > encrypt all of their Windows workstation drives, but if they do that, > the machines require manual intervention to enter a key on every > reboot. Why is this a problem? Because installations and upgrades of > many kinds of Windows software require multiple reboots, and they > don't want to have to manually intervene on every machine in their > buildings in order to push out software and patches. > > (The general threat model in question is reasonably sane -- they > would like drives to be "harmless" when machines are disposed of or if > they're stolen by ordinary thieves, but on the network and available > for administration the rest of the time.) > > Does anyone have a reasonable solution for this? 1) Thanks for being explicit about the threat model and objectives. As is so often the case, what the client wants is probably not exactly what the client is asking for. 2) In this case, I reckon the client would be content to encrypt _everything of value_ on the drive ... even if this is not quite the entire drive. In particular: On every normal boot, the machine boots into a preliminary kernel that uses key A to request key B over the network. Key B is the disk key, which then gets stored in some guaranteed-volatile place that will survive a chain-boot but not survive anything else. Then the pre-kernel chain-boots Windows. To be clear: The entire Windows partition is encrypted, but the pre-kernel lives in a tiny partition of its own that is not encrypted. If the machine is stolen, it is immediately harmless because it is no longer connected to the network. If the machine is to be disposed of *or* if theft is detected or suspected, then the keyserver that hands out disk-keys will stop serving the key for that machine, so even if it is reconnected to the network somehow it is still harmless. For icing on the cake, the keyserver can check IP addresses, virtual circuits, etc. ... to check that a machine that is supposed to be on the secure wired network has not suddenly relocated to the insecure wireless network that serves the lobby and leaks out into the parking lot. If the network is down and somebody wants to boot his machine anyway, he can type in the key by hand. 3) The same effect can be achieved using a hypervisor / VM approach, rather than chain-booting. The same effect can be achieved by messing with grub, although that would be more work. The same effect can be achieved by messing with coreboot, but that would be even more work. 4) If the customer absolutely insists that "the entire Windows drive" be encrypted, just add another drive, perhaps a very small flash drive. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Disk encryption advice...
On Fri, 8 Oct 2010, Perry E. Metzger wrote: I have a client with the following problem. They would like to encrypt all of their Windows workstation drives, but if they do that, the machines require manual intervention to enter a key on every reboot. Why is this a problem? Because installations and upgrades of many kinds of Windows software require multiple reboots, and they don't want to have to manually intervene on every machine in their buildings in order to push out software and patches. (The general threat model in question is reasonably sane -- they would like drives to be "harmless" when machines are disposed of or if they're stolen by ordinary thieves, but on the network and available for administration the rest of the time.) Does anyone have a reasonable solution for this? Use a VM based solution where the Windows images are stored on a NAS that uses disk encryption (and requires an admin when it would reboot), yet the Windows based VM's would need no disk encryption supported whatsoever. My laptop for instance is running Fedora with whole disk encryption, and I run various Windows VM's that have their image stored on that encrypted disk. Paul - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
RE: Disk encryption advice...
> -Original Message- > From: owner-cryptogra...@metzdowd.com [mailto:owner- > cryptogra...@metzdowd.com] On Behalf Of Perry E. Metzger > Sent: Friday, October 08, 2010 3:28 PM > To: cryptography@metzdowd.com > Subject: Disk encryption advice... > > I have a client with the following problem. They would like to encrypt all of > their Windows workstation drives, but if they do that, the machines require > manual intervention to enter a key on every reboot. Why is this a problem? > Because installations and upgrades of many kinds of Windows software > require multiple reboots, and they don't want to have to manually intervene > on every machine in their buildings in order to push out software and > patches. > > (The general threat model in question is reasonably sane -- they would like > drives to be "harmless" when machines are disposed of or if they're stolen > by ordinary thieves, but on the network and available for administration the > rest of the time.) > > Does anyone have a reasonable solution for this? > > -- > Perry E. Metzger pe...@piermont.com This is a fairly well known problem for which many vendors have solutions of varying quality. I'll summarize a few approaches. In general you want to have the window between the time a pre-boot authentication (PBA) bypass is set and the time of the reboot that consumes the bypass be as small as possible. Alternatively (my preferred) you want to have a pre-boot environment that can make a secure check to see if it is still on a safe/secured network and if it is, bypass PBA. This way PBA is bypassed any time the system is in a safe facility. 1) Some type of bypass file placed by the managing system that, if present on reboot tells the system to bypass the pre-boot authentication. The file should be settable only through an administrative function configured on management consoles, not locally. Ideally it should be protected by some crypto scheme. Checkpoint, McAfee, PGP for sure have this feature, but I believe most big vendor-owned solutions have it. I don't much care for *how* they implement it. PGP has a command-line command that sets the reboot flag, so a simple administrative-level cmd script can do it. The file may have a counter that is decremented (Checkpoint does) or it may need to be reset each time. I recommend that you deploy the bypass file as part of the patching process so the window is small as possible with only the known number of required reboots allowed. 2) Some systems can be configured to boot to Windows, and use Windows' IP stack to check for some conditions on the network. If the conditions are met, the system stays at the Windows prompt; if the conditions are not the system insitigates PBA and shuts down. On next boot it will be at the PBA prompt. I know of some vendors that do this, but do it really naively. One actually does nothing more than ping a series of IP addresses and if *any* of them respond they assume they are on the right network. Yes, they pin their network location awareness on the fact that nobody could ever think to spoof an ICMP echo response. I discourage this mode in general, even if done well because it depends on a fully booted windows box before it can check. I configured a small lab network to trivially bypass the ping test. 3) There is one vendor that has worked on this problem very hard over the last couple years to leverage vPro and Intel's secure wake-on-lan, and pre-boot environment to provide secure challenge-response based network awareness. If they determine they are on a secure network, they will continue past the boot prompt and if they determine they are not they'll either sit at the prompt or shut down. Oddly enough that company, McAfee, was recently bought by Intel. McAfee's leveraging of Intel's on-board security hardware was the main deciding factor in that purchase, or so I believe. Disclaimer: My company isn't a McAfee disk encryption customer. I don't work for either company. I just happen to have dug pretty deeply into disk encryption companies and products over the last couple years and my opinion is that McAfee did it right and the others are playing catch up. Off topic rant: None of the other security vendors seemed the least bit interested in the on-board security features Intel was building into systems, largely because if vendors built product around it, it might make them too interchangeable; replaceable. McAfee was different. Intel got tired of waiting for vendors to kick-start their products, so Intel bought the company that had gotten the furthest with Intel's tools. Personally, I'd hate to be competing with Intel/McAfee on the disk encryption or systems management front right now. Of course, they've still got plenty of latitude to screw it all up. Eric Lengvenis InfoSec Arch., VP - The Cryptography Mailing List Unsubscribe by sending "
Re: Disk encryption advice...
On Fri, Oct 08, 2010 at 04:27:57PM -0400, Perry E. Metzger wrote: > I have a client with the following problem. They would like to > encrypt all of their Windows workstation drives, but if they do that, > the machines require manual intervention to enter a key on every > reboot. Why is this a problem? Because installations and upgrades of > many kinds of Windows software require multiple reboots, and they > don't want to have to manually intervene on every machine in their > buildings in order to push out software and patches. > > (The general threat model in question is reasonably sane -- they > would like drives to be "harmless" when machines are disposed of or if > they're stolen by ordinary thieves, but on the network and available > for administration the rest of the time.) > > Does anyone have a reasonable solution for this? Commercial products have a mode in which you can drop the requirement for a key for one reboot. Presumbly the key is then erased. This may a reasonable compromise. The devil is in the details. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Photos of an FBI tracking device found by a suspect
On Fri, Oct 08, 2010 at 05:45:16PM -0400, Perry E. Metzger wrote: > On Fri, 8 Oct 2010 16:13:13 -0500 Nicolas Williams > wrote: > > On Fri, Oct 08, 2010 at 11:21:16AM -0400, Perry E. Metzger wrote: > > > My question: if someone plants something in your car, isn't it > > > your property afterwards? > > > > If you left a wallet in someone's car, isn't it still yours? > > Yes. However, that's an accident. If you deliberately leave a package > on someone's doorstep, they then own the contents. (In fact, if > someone mails you something, US law is very clear that it is yours.) I covered that, didn't I? > I'd be interested in hearing what a lawyer thinks. Indeed, but I'm pretty sure the FBI wouldn't lose that question. If the surveillance subject said "it's mine now" they could probably arrest him, and the legal question can get settled later, possibly in a protracted appeals battle that would likely ultimately favor the FBI anyways. Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Photos of an FBI tracking device found by a suspect
On Fri, 8 Oct 2010 16:13:13 -0500 Nicolas Williams wrote: > On Fri, Oct 08, 2010 at 11:21:16AM -0400, Perry E. Metzger wrote: > > My question: if someone plants something in your car, isn't it > > your property afterwards? > > If you left a wallet in someone's car, isn't it still yours? Yes. However, that's an accident. If you deliberately leave a package on someone's doorstep, they then own the contents. (In fact, if someone mails you something, US law is very clear that it is yours.) I'd be interested in hearing what a lawyer thinks. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Photos of an FBI tracking device found by a suspect
On Fri, Oct 08, 2010 at 11:21:16AM -0400, Perry E. Metzger wrote: > My question: if someone plants something in your car, isn't it your > property afterwards? If you left a wallet in someone's car, isn't it still yours? And isn't that so even if you left it there on purpose (e.g., to test a person's character)? But this is not the same situation, of course, since the item left behind is an active device. If your planting of the device violates the target's rights you might (or might not) lose ownership of the device, along with other penalties. The FBI is a state actor though, so the rules that apply in this case are different than in the case of a tracking device planted by a private investigator, and those might be different than the rules that would apply if the device's owner is a private actor not even licensed as a PI. IOW: ask a lawyer. But I strongly suspect that the answer in this case is "the FBI still owns the device", and "the question is not moot" (as it might be if the device had stopped working then fallen off the car (e.g., after hitting a number of nasty potholes). I mean, I seriously doubt that relevant laws would be written as to grant the subject ownership of devices planted as part of a legal surveillance of them, and though it's possible that judge-made law would conclude differently, I doubt that judges would make such law. Nico -- - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Disk encryption advice...
I have a client with the following problem. They would like to encrypt all of their Windows workstation drives, but if they do that, the machines require manual intervention to enter a key on every reboot. Why is this a problem? Because installations and upgrades of many kinds of Windows software require multiple reboots, and they don't want to have to manually intervene on every machine in their buildings in order to push out software and patches. (The general threat model in question is reasonably sane -- they would like drives to be "harmless" when machines are disposed of or if they're stolen by ordinary thieves, but on the network and available for administration the rest of the time.) Does anyone have a reasonable solution for this? -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Photos of an FBI tracking device found by a suspect
Original post with nicer pics: http://www.reddit.com/r/reddit.com/comments/dmh5s/does_this_mean_the_fbi_is_after_us/ Semi-relevant government pricelist: http://www.google.co.uk/search?q=st820ec+site:.gov -a -- alec.muff...@gmail.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Photos of an FBI tracking device found by a suspect
On Oct 8, 2010, at 11:21 16AM, Perry E. Metzger wrote: > My question: if someone plants something in your car, isn't it your > property afterwards? > > http://gawker.com/5658671/dont-post-pictures-of-an-fbi-tracking-device-you-find-on-a-car-to-the-internet See http://www.wired.com/threatlevel/2010/10/fbi-tracking-device/ for even more disturbing aspects of the story -- they operated by intimidation (to say nothing of apparent ethnic and religious profiling). --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: English 19-year-old jailed for refusal to disclose decryption key
On Thu, 7 Oct 2010, Nicolas Williams wrote:
If decryption results in plaintext much shorter than the ciphertext -much
shorter than can be explained by the presence of a MAC- then it'd be fair to
assume that you're pulling this "trick".
Not to argue with your overall point re: crypto not protecting citizens from
their states, but I disagree with the above in the case of truecrypt, which is
what was being discussed.
I have many unencrypted drives (or partitions) that are only partially
full. It's quite plausible that an encrypted drive would not be very
full. ("I thought I might need more space later." or "well, I had all
of this space...")
Moreover, possession of software that can do "double encryption" could be
considered probable cause that your files are likely to be encrypted with it.
There's a lot of software I use daily which has features I never touch. I use
the alpine MUA, but I never have it fetch mail from a POP server, I don't use
message scroing, etc. Maybe the suspect selected truecrypt because it works on
all of linux, MacOS and Windows, unlike so many other such tools. And is free,
unlike BestCrypt. There are many plausible reasons for selecting that tool
that have nothing to do with the double encryption feature.
-- Sam
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Computer "health certificate" plan: Charney of DoJ/MS
Before people get too far into conspiracy theories with this, I should point out that health certificates have been part of corporate Windows environments for years (I don't know how many exactly, I think it's been since at least Server 2003). The intent of health certs is that it allows the IT department to manage PCs by allowing checks that they have the latest AV updates installed, the corporate desktop background and Windows theme, the corporate mail client in an up-to-date version, and so on. In other words it's a configuration management solution. Think cfengine with certs. In this case it looks like a MS spokesperson has decided that the existing cfengine-with-certs approach used in corporate environments would work on an ISP-wide or even nation-wide level. It's no conspiracy theory, just a case of either cluelessness about scaling issues or misreporting of a blue-sky, what- if proposal. I'd guess it's the latter. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: English 19-year-old jailed for refusal to disclose decryption key
On Oct 7, 2010, at 1:10 PM, Bernie Cosell wrote: a 19-year-old just got a 16-month jail sentence for his refusal to disclose the password that would have allowed investigators to see what was on his hard drive. What about http://www.truecrypt.org/docs/?s=plausible-deniability Could this be used? Sure. And the technology used would have no effect on the standard ... used in court: I think you're not getting the trick here: with truecrypt's plausible deniability hack you *CAN* give them the password and they *CAN* decrypt the file [or filesystem]. BUT: it is a double encryption setup. If you use one password only some of it gets decrypted, if you use the other password all of it is decrypted. There's no way to tell if you used the first password that you didn't decrypt everything. So in theory you could hide the nasty stuff behind the second passsword, a ton of innocent stuff behind the first password and just give them the first password when asked. In practice, I dunno if it really works or will really let you slide by. You're thinking too much about the technology. The court demands a company turn over its books. The company denies it keeps any books. Sure - massive fines, possible jail sentences for the principals. Alternatively, the company turns over fake books. There is evidence that the books are fake - they show the company only did 2000 transactions last year, but somehow the company paid a staff of 200 to take phone calls last year. Or the books don't show any payments for things that we see sitting in the warehouse. Or maybe there are just purely statistical anomalies: The variation in income from week to week is way out of the range shown by other businesses. Or there's just someone who swears that these are not the books he's seen in the past. Same outcome for the company. Maybe the high-tech cheats let you get away with stuff; maybe they don't. Then again, maybe the fake paper books let you get away with stuff, and maybe they don't. Technology lets you play some games more easily, but it's not magic pixie dust that immunizes you from reality. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
