14

Let's say I have to leave my computer unattended and turned off for a while with some strangers, is it possible for someone to clone my HDD and SSD data?

Gem
  • 265
  • 2
  • 4
  • 13
    Have you read anything about disk encryption? – user Jul 01 '21 at 13:15
  • The only thing I know about that is Windows BitLocker, and I dont have that turned on – Gem Jul 01 '21 at 13:16
  • 2
    That's what you typically use to prevent people from being able to copy and read through your disks. – user Jul 01 '21 at 13:17
  • 19
    What you are describing is known as an `evil maid attack`. As the other commenters have said, the defense against this type of attack is full disk encryption. See https://security.stackexchange.com/questions/223597/what-is-the-physical-security-evil-maid-threat-model-of-a-modern-hardened-lapt and https://security.stackexchange.com/questions/159173/what-exactly-is-an-evil-maid-attack for more info. – mti2935 Jul 01 '21 at 13:29
  • 11
    If anyone is looking for a quick TL;DR answer, the answer is simply "nothing". – RockPaperLz- Mask it or Casket Jul 02 '21 at 04:17
  • 2
    There is nothing stopping them from cloning all of your HDD/SSD. However, you can make it **impractical** for them to read the cloned data with full disk encryption. – MonkeyZeus Jul 02 '21 at 13:42
  • 1
    How about steel-reinforced concrete walls, a heavy door, a complex lock, video surveilance, armed security people and a strict access protocol? ... and sometimes even measures like these fail. Encrypt your data! – fraxinus Jul 02 '21 at 17:39

6 Answers6

45

Nothing

On a bit-level, nothing stops an attacker with local access from copying the bits on your hard drive or SSD. In fact, there is hardware designed to create exact images of disks and SSDs, though this is usually done for forensic purposes.

How useful those bits are depends on how your hard drive is set up. Without any encryption applied, the attacker can use the filesystem present on the disk image to read the files - just how your computer would do it. Even without an intact filesystem, techniques like "file carving" can be used, where common headers for files are searched. Basically, you look for something that looks like the beginning of an image, and then attempt to read the next sectors as if they were an image. And in the end, you may end up with a usable image, or junk.

This can be protected against with encryption. Generally, there are two kinds of common encryption methods: File-based encryption and full-disk encryption. File-based encryption means the contents of some files are encrypted, and full-disk encryption means everything on the whole volume is encrypted.

With both of these, the problem now becomes key management. For full-disk encryption solution like BitLocker, keys can be generated with a passphrase and an additional TPM component. For file-based encryption, as it is used on modern Android phones, you can either use a similar approach, or use individual keys for each file, depending on your requirements.

  • 3
    You can actually lock a disk with a password without even needing to use encryption. It's obviously not useful to an attacker who can remove the physical platters in a lab, but it's fine against someone who is going to plug in the SATA port and try to read off data. – forest Jul 02 '21 at 02:04
  • 1
    @forest undeniably true, but of dubious value to suggest when encryption is so widely and trivially available – Billy left SE for Codidact Jul 02 '21 at 07:15
  • 3
    I'd suggest to change the answer's title from `Nothing` to `Encryption` because it does stop an attacker from getting a *usable* clone drive – usr-local-ΕΨΗΕΛΩΝ Jul 02 '21 at 07:20
  • 15
    @usr-local-ΕΨΗΕΛΩΝ Technically, encryption doesn't stop anybody from copying a disk (which is what OP asked). It's still possible - just pointless. IMO that's a less confusing way of explaining it because it doesn't make it seem like encryption somehow magically changes how the drive works. – gronostaj Jul 02 '21 at 07:55
  • 6
    @usr-local-ΕΨΗΕΛΩΝ the question didn't ask about usefulness. And an encrypted image _could_ still be useful to the attacker, if they can get at the key or even bruteforce a weak password. Yes, the latter will be expensive if a long key and good deriving function is used, but not out of reach for some actors – _once you have a copy_ of the disc contents, that can be distributed to a server farm. – leftaroundabout Jul 02 '21 at 08:26
  • 8
    @usr-local-ΕΨΗΕΛΩΝ I purposefully phrased it that way, to drive the point home that cloning can't be prevented. –  Jul 02 '21 at 11:47
  • @forest You need a BIOS/UEFI that supports it in general to then be able to provide the ATA password pre-boot. Also the fact that tools exists that claim to be able to defeat those passwords makes it less interesting. – user1532080 Jul 02 '21 at 14:59
  • How does the TPM component make it more secure? – starbeamrainbowlabs Jul 02 '21 at 16:01
  • @gronostaj Not quite pointless. If you really want to break the encryption cloning the disk can parallelize brute-force attacks. As usual, the key may be secure but attackers can always try to attack the passphrase. For ordinary attackers this may end up being useless as well but state actors may have the resources to do this. – slebetman Jul 02 '21 at 21:16
  • 1
    @starbeamrainbowlabs, the TPM stores the encryption key out-of-reach from the general-purpose CPU. In a good implementation, even code running as root/administrator/etc can't get keys out of the TPM -- at least, not if they're sealed to only run when the system is in a specific state, and that state can involve things like "booted past a bootloader the user entered a correct password into". – Charles Duffy Jul 03 '21 at 00:02
  • 1
    (That said, I'm more familiar with using TPM-backed keys for authentication/signing purposes than for encryption -- in which case the TPM itself can do the signing operation completely onboard so the CPU never sees the key at all; encryption cases have different needs, because the TPM is too slow to do all the actual encryption/decryption itself, so one ends up using the TPM to decrypt the real key, and then needs to be careful about how aforementioned real key is handled; the powered-off case is an easy one even then, though -- it's attack by a user who can read RAM that's harder to avoid) – Charles Duffy Jul 03 '21 at 00:05
9

Physical access is usually a huge security issue, depending also on your threat model or, in other words, what the attacker is willing to do with your machine.

Full disk encryption is a great security control if your machine is stolen (while turned off), to prevent the attacker from reading the contents of your HDD. You will never use the stolen machine anymore, it's gone. But if the attacker is able to compromise your machine, for example by replacing the disk and the OS (and show a fake prompt), or by installing a hardware keylogger, etc. and then you are going to use that machine again, then full disk encryption won't help. In theory some encryption methods don't protect integrity, so a very skilled (and lucky I guess) attacker could even be able to change some data on your encrypted HDD. And some encryption methods don't encrypt everything, but there might be unencrypted stuff on your disk (like bootloaders, etc.) that could be compromised (unless you have secure boot turned on, I guess).

If the attacker in your scenario is only going to turn on the PC, see it's encrypted, and give up, then full disk encryption is going to be enough. You might also want to disable boot from external devices, and password-protect the firmware. However if the attacker you are dealing with is willing to disassemble your machine, replace hardware, or spend a lot of time and resources to pull off the hack, then full disk encryption won't help you much (but it's always a good thing to have by default, anyway!)

reed
  • 15,398
  • 6
  • 43
  • 64
  • 1
    Eh. Bootloaders may not be _encrypted_, but in a Secure Boot system they're _signed_, so even though they're readable, they can't be modified and continue to work. – Charles Duffy Jul 03 '21 at 00:58
  • BITD when I was working COMSEC the typical defense against physical access was intrusion detection along with automatically "zeroizing" any writable media (writing patterns of 0s and 1's repeatedly). – T.E.D. Jul 04 '21 at 18:25
  • "But if the attacker is able to compromise your machine," - which is a REALLY different question if the machine uses a TPM to make sure that the keys are not stored in a retrievable way. – TomTom Jul 04 '21 at 20:20
4

Time.

Yes, someone could clone your entire hard drive, but this usually takes a long time. An attacker would have to open your computer's case, remove the drive, plug it into a dock, clone its contents, then return it to the case and hope you don't notice. Or alternatively, boot your computer using removable media, and then clone the drive over the network or to some other form of removable storage. Either way, it takes a fair amount of time and effort, so the attacker would have to be confident that you're not returning any time soon.

Far more convenient would be browsing the drive and cherry-picking files that look interesting. That requires a different level of access, but less time.

Both attack vectors can be impeded by encryption, as mentioned by others. The cherry-picking method can also be impeded by obfuscation, such as hiding your top secret files in a directory named "Financial Reports, 2004-2005" (unless, of course, your top secret files actually ARE financial reports, in which case you should hide them under "Pirated episodes of My Little Pony"). Encryption can definitely help here, too, but remember that someone who has access to your computer also has access to the post-it notes stuck to your screen, so be very careful with your password.

rosuav
  • 239
  • 1
  • 3
  • 2
    A quick look around some recent articles and forums shows that a 500GB drive can be cloned in less than 30 minutes. When you say "this usually takes a long time", can you quantify that a bit? You are saying that time is the biggest factor, but 30 minutes is not a lot of time. And time would be a "detection" control, not a "prevention" control, which is what is being asked. So, no, time does not prevent disk copies. – schroeder Jul 02 '21 at 11:43
  • 1
    "and hope you don't notice" -- is this a requirement? Once the data is copied, does it matter if it is noticed? And how much evidence might there be? At most, scratches around the screws, if you happen to look under your laptop for them. – schroeder Jul 02 '21 at 11:44
  • 1
    @schroeder : it depends. If your situation is that you go to a bathroom break and are afraid that a friend or a family member or a collage will use that opportunity to snoop around, then 30 minutes is a very long time nobody would risk. – vsz Jul 02 '21 at 22:54
  • @schroeder I mean notice them in the act. If you left your PC somewhere and you come back to find someone with a screwdriver leaning over it, you're going to be suspicious. – rosuav Jul 03 '21 at 00:59
  • Not sure what hardware is cloning that 500GB drive in 30 minutes, but (a) my drives are all >1TB, and the time goes up linearly with the capacity; (b) if you're doing it over network then it's capped on network speed too; (c) there's also the time to set everything up. – rosuav Jul 03 '21 at 01:01
  • Right, you've just described "detection" not "prevention". And you still haven't described what you mean by "a lot of time". Since the OP is not specific about the time, making an answer all about time without any context really isn't helpful. And laptop drives (which is what was mentioned) are on average between 500GB-1TB, so that's why I used 500GB drives in my quick research. If you have over 1TB drives in your laptop, then you are a corner case. – schroeder Jul 03 '21 at 12:13
  • Since the OP wasn't specific about time, vague approximations are all that there can ever be. Given sufficient time, even encryption can be broken. All it does is buy you *more time*. So my answer is still valid, since the functional difference is still a practical one. – rosuav Jul 04 '21 at 14:00
3

Yes, it is possible to clone drives using some external connector (SSD/HDD usb connectors/Tableau Hardware) and software (osf/winhex). Cloning can be done in both states. It takes 30 - 40 min depends on size of hard drive and respective machine.

Bitlocker (whole disk encryption) can help to manage risks.

RockPaperLz- Mask it or Casket
  • 3,114
  • 21
  • 50
Test
  • 31
  • 1
3

Physical Security

An often overlooked part of Information Security. Lock the PC down by disabling external ports (USB, Serial, etc), and physically secure the PC so they cant take it or open it. Have a chassis intrusion switch that is tied to an alarm, and put the machine in a secure enclosure.

us_system_integrator
  • 31
  • 2
0

You could protect the drive with a password (I mean a bios unlock password, sometimes called DriveLock or ATA password, not a bitlocker-type full disk encryption). Such drives won’t accept any commands until unlocked. However it’s not very reliable and replacing the drive logic board is know in some circumstances to dwarf this protection.

FDE alone won’t protect attackers from copying the disk image, but they might not be able to get the encryption key.

eckes
  • 962
  • 8
  • 19
  • 1
    "However it’s not very reliable" - it actually is if you use encoding discs. Which are standard in enterprise. Replacing the board will mean the drive has a different encryption key... and can not read the data. This (hardware level drive level encryption) is also amazing for a millisecond delete - the drive just generates a new key, all the old data is irrevocably lost. STANDARD in enterprise drives, pretty much all drives have a version supporting this. – TomTom Jul 04 '21 at 20:22
  • You are thinking of self encrypting drives, thats yet another feature (and also not reliable since drives are k own to lie about it). SED is also used by BitLocker if the drive claims to support it, – eckes Jul 04 '21 at 20:31
  • 1
    "also not reliable since drives are k own to lie about it"-they may, but the datasheets of suppliers do not. As in: Can you imagine how much legal problems you get when you lie on a datasheet as producer? And data gets stolen... – TomTom Jul 04 '21 at 20:34
  • Check for example the paper from Meijer and van Gastel “Self-encrypting deception” – eckes Jul 07 '21 at 17:50
  • Just went through it and I would not consider ANY of the given examples in that paper relevant. As in: all are not meant to be server level safe drives - heck, I was not even aware they do support encryption (the Samsung Pro) and most are cheap end user stuff. I was talking about things like this: https://www.seagate.com/files/staticfiles/support/docs/manual/Interface%20manuals/100515636c.pdf, which are SOLD self encrypting - in special versions that cost a little more than the normal one. – TomTom Jul 07 '21 at 17:56