0

For future refence:
In light of answers and critique, my question should have been:
1. How does one make sure a physical attacker with access to a powered, but locked FDE PC fails his/hers attempt to clone the harddrives by somehow trigging a computer shutdown. But, in light of answers, it became clearer that "tripwire" shutdown is not essential in the goal of defending FDE.


I am looking and praying for a software that will shutdown computer if it is not approached correctly. An ideal functionality example: the computer is locked, but if the mouse gets moved or any key excepct e.g. "s" is pressed the computer will force shutdown.

edit: there is clearly a market for this, no? An unmonitered, powered computer obviously means full-disk encryption is eliminated. The mightiest of defenses laid on its knees, with nothing but a windows password left to savagely hack.

edit2: (lack the rep to comment) shutdown if X failed pass attempts is good, but if the attacker goes straight for reading the harddrives with external hardware he/she will only move the mouse to check the state of the PC. To clarify, I'm not sure, but I assume there are tools to clone hardrives with a PHYSICAL presence from a powered computer, despite it being locked, if this is impossible correct me.

Edit: 3 I think a rephrase is in order. How would I protect myself from a physical attacker with harddrive cloning tools?

Jeff, how can a clone be a clone with encrypted PC being on/off (=decrypted/encrypted)? Or have I misunderstood how cloning with FDE works? I assume that to successfully clone a FDE PC it must be powered and decrypted, if it is off/encrypted obviously the clone data will be garbled?

Karalga, TPM was a good heads up, I'd never heard of it before, but it makes a lot of sense. As for protection against Van Eck phreaks and such I take my tin-foil hat off to whoever goes that far.

9
  • What use case do you have that you would want this? It seems like a bad idea User Interaction wise.
    – LvB
    May 22, 2015 at 14:16
  • An attacker with physical access would probably not even use a mouse. just send hardware commands directly (much faster and harder to detect). A emote Attacker would probably also not use the mouse, just send terminal commands. in short why would anyone use the mouse?
    – LvB
    May 22, 2015 at 14:38
  • 1
    "How would I protect myself from a physical attacker with harddrive cloning tools?" Full disk encryption, naturally, same as if the machine is off. A clone is a clone. Maybe you meant "how do i keep my FDE key protected when the machine is turned on"?
    – Jeff Meden
    May 22, 2015 at 15:25
  • 1
    I think the question goes even further - how do I secure a machine in an entirely hostile environment? Some solution of TPMs, full hardware verification (so that nothing can be swapped), and some physical protection against eavesdropping on the memory...
    – Karalga
    May 22, 2015 at 15:38
  • 1
    @Manumit you're asking a tough question, where there is no silver bullet answer to be given. It would really help if you could rework the text and title of your entire question at this point, and explain precisely what threats you're facing and what properties you want to guarantee. This would help people write answers that provide you with tangible advice and clear limits on what you can hope to achieve. May 22, 2015 at 17:01

5 Answers 5

1

OK I have been noodling on this for long enough to take a swing at what I think the OP is asking.

Tripwire security

I would classify the functionality "shut down unless user does one very specific thing" as a pretty conventional tripwire. An application for most operating systems would be trivial (but unique) to code like this: on event keypress "d" disarm; else on event mouse-move|keypress shutdown. This guards against one thing: anyone trying to log in who doesn't know about the tripwire. Security by obscurity like this is regarded as thin, at best. As soon as knowledge spreads about circumventing your tripwire, it will be useless. It is better handled by a meaningful and readily-changed token, aka a password.

Cloning Tools

A cloning tool needs to run as a trusted executable on the host OS in order to gain decrypted access to the hard drive in a FDE situation. This would mean they attacker would need to use either valid admin level login credentials or one or more vulnerabilities that grant admin level access in the OS. You can guard against this by keeping patches up to date, executable whitelisting, auth by smartcard or 2FA, and any number of other traditional hardening measures, best applied in layers to create defense in depth. No hardware cloning tools would be useful since they plug in directly and the data on the disk is still encrypted even when the machine is on. Hopefully no decryption keys are on the drive with the encrypted data, otherwise power state is irrelevant and the encryption might as well be a caesar cipher.

2
  • I have a happy list of to-do's and to-learn now.
    – Manumit
    May 22, 2015 at 17:49
  • I have encrypted SWAP with fsutil behavior set encryptpagingfile 1 Is this enough to deterr memory extraction?
    – Manumit
    May 22, 2015 at 18:47
2

Cloning an FDE disk yields another FDE disk. It'll be encrypted so, not much in the way of worries there.

The scenario where a copy of all the unencrypted data from an FDE disk is pilfered (is probably what you are actually wanting to know about) must take place through the operating system or with the decryption key.

Operating systems are generally secure, but they are not perfect. However, a locked operating system that is not being used by an authorized user tends to be very difficult to break.

There are some potential weaknesses with FDE and TPM, in terms of vulnerability to cold boot attacks, etc. where an attacker with unhampered physical access could attempt to steal the decryption key.

So here's some advice:

1) Truly make it more difficult for an attacker to gain unhampered physical access: A) remove, block, and secure (epoxy) all data ports, make sure no new device can be introduced. B) remove all CD drives, floppy drives, etc. C) physically secure the computer in a locking security cabinet and lock the chassis. D) ensure the wires to peripherals cannot be accessed, otherwise someone can just cut the wire and connect the leads to their own usb device. E) hire people with firearms that will defend your stuff.

2) Secure the computer's configuration: A) secure the bios with a password. B) do not allow boot from any device other than the primary hard drive. C) understand the difference between pre-boot authorization and transparent operation mode for your FDE implementation and make sure you pick the one that leaves you less vulnerable to having your decryption key hijacked. some people like the security of keeping the decryption key separate from the computer. others want it to stay on(in) the computer (via TPM chip) so it doesn't have potential external exposure.

Finally, there is a fundamental flaw in your thinking about getting to the 'shutdown' to protect your FDE system. RAM may be volatile but it's not as volatile as you might think. The decryption key for your drives, using a cryogenic technique on your RAM, can be potentially recovered for hours after a system shutdown. Aside from the recommendations above, you could look into acquiring a computer that implements memory scrambling to help defeat cold boot attacks (apparently, some of the Intel processors have this as a feature).

3
1

I do not know what OS you are using, but if you are so security conscious I suppose that you lock your computer before leaving it. Therefore, to connect, one should try a few password.

Failed connections should be logged, and you have plenty of log monitoring software offering active response upon log events. With such a software, you can for instance decide that after three failed connection attempts the system will automatically try to send you an email/SMS before shutting itself down.

1

Just dipping my toes in here for a second.

Sometimes a mouse can move a minuscule amount by itself due to the surroundings (ghosts, furnace/AC blower, rumbling traffic outside or worst case a real mouse).

I frequently find my PC on after I have it in sleep mode overnight and I know there was no one on it as I live alone.

A slight movement for whatever reason can "wake" the PC when that mouse moves. That would be overkill to force it to shutdown JUST because the mouse became active. You might as well shutdown everytime you're done with your computer.

1
  • Part of the reasonig why you never ever do this ;)
    – LvB
    May 22, 2015 at 15:34
0

There is never a need for this type of behavior. Physical access to a machine can be regulated with a safe. and the Machine itself can be build with Keyboard support disabled. (why would you need that on a 'service' machine anyway) All that remains is network access and that can be controlled through other means. (SSH with certificates / Firewall / IP whitelisting / CLient side SSL certificates)

In short this is not needed ever.

2
  • I guess people here have never done User Machine Interaction.(or there would not be a down vote)
    – LvB
    May 22, 2015 at 15:34
  • I think the downvote is because "your question is wrong" is not really an answer. Upvote bc that's not your fault.
    – Jeff Meden
    May 22, 2015 at 15:38

Not the answer you're looking for? Browse other questions tagged .