1

This question already has an answer here:

Some background: My org is potentially involved in a legal dispute with a securities brokerage in a under-developed country with mediocre rule of law. The broker also is responsible for co-locating a machine used for trading at the exchange. The machine is owned by our org, but network administered by the broker and hosted at their rack.

Shortly after the incident in question the host blocked our network access to the machine. This is already a potential legal problem for them, as we've paid for hosting through the month. Also any reasonable person would conclude that we want access to our system logs to represent our side in the dispute.

Luckily for us, the relevant logs were already pulled out of the machine to off-site storage. Also in favor is that the machine has 256-bit AES full disk encryption. The disk contains our proprietary binaries (compiled with GDB symbols), and system logs, which are relatively transparent to any sophisticated actor.

Obviously I'd prefer our adversary not to have this information if possible. That would augur for formally petitioning to return our machine to us, before they have time to tamper or extract information. On the other hand the encryption is fairly strong, and the machine is powered off preventing a cold boot attack. Our adversaries capabilities fall well short of state actors or even first world tech orgs. That would augur for giving themselves time to dig themselves into a deeper hole. If they take the extra time to tamper with or destroy the machine, that would be a major point for our org in the dispute.

What's the general opinion of the community here? Do you think there's an obvious answer to this dilemma? Or if not do you see any pros or cons that I'm overlooking?

marked as duplicate by Anders, Steve, CaffeineAddiction, kasperd, Xander Feb 28 '17 at 22:28

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    Regarding FDE, how was your machine rebooted in the COLO? In other words, how was the key supplied when necessary to start the machine or decrypt data? Were you using disk encryption supplied by the hdd controller or something else? Was encryption handed transparently by the BIOS, or with participation of the OS? – trognanders Feb 27 '17 at 22:33
  • The accepted answer of my proposed duplicate question rather accurately describes your situation. – trognanders Feb 27 '17 at 23:00
  • 1
    Disk encryption was handled by Debian, and setup during partitioning at install. Encryption key was supplied at each reboot from a LOM virtual console. It's possible that the LOM could be compromised to log keystrokes, but the last reboot was weeks ago. The chance of malicious action at this date is very low probability, as it was well before the adversarial event. – user79126 Feb 27 '17 at 23:28
  • To be real, your data is probably pretty safe, but they have lots of time to brute force your passcode for the encryption. If an exploit to the disk encryption is found, later they will be able to use it. Do what you can to mitigate the threat, like revoking certificates and access keys. Try to regain possession of the machine asap. It might not be wise to ever use it again. – trognanders Feb 28 '17 at 5:52
  • 1
    I'm not sure what your question is exactly. What is your dilemma? Are you asking if your opponent can read your encrypted data? Or whether they can manipulate it? Or something else? – Out of Band Feb 28 '17 at 16:50