15

I am using full disc encryption on my portable computer (running Ubuntu). The setup requires me to enter a password during the boot sequence to access fully encrypted hard drive. There is no additional encryption of my home directory or even a login for X session required (I'm the only user).

When I move around with my computer, I usually do not turn it off completely, only suspend it. This operation starts a screen lock on the X session before the PC is suspended. There are other text consoles available that do require login with my username and password (but no SSH server).

I've seen people (usually with setup that encrypts only their home directory) that wipe the disc encryption key from memory when the screen is locked. I find this solution quite drastic, since sometimes I want to leave some programs running on the background that need access to the disc or my home directory (e.g. a file downloading in a browser while I go for a lunch and lock my screen).

In case my PC would be stolen, is there a way an attacker would be able to gain access to the files on my computer without my password? Generally, the screen locking is frowned upon as a weak security measure because "it's just a screen lock", yet I failed to come up with any reasonable scenario how a potential thief would be able to gain access to my data if he would steal my suspended computer with a locked screen. He doesn't have any way to control my computer without my login password and any attempt to power it off and look at the hard drive directly would leave him with encrypted drive inaccessible without my disc encryption password.

Can anyone point out any weakness in this setup, and if you do, how to make it secure?

  • 7
    What's the point in having boot-controlled encryption if you never "unboot"? – Lightness Races in Orbit Oct 19 '15 at 13:55
  • 7
    @LightnessRacesinOrbit The point would be to stop a thief who's more interested in the laptop than in the data from gaining persistent access to that data. – Xander Oct 19 '15 at 14:27
  • @BoundaryImposition It protects against an attacker booting the system from an alternative OS or pulling out the hard drive, as explained in the question. – Micheal Johnson Mar 27 '17 at 8:33
  • @MichealJohnson: I'm saying the OP should implement the additional encryption mentioned in the question as not being in use. Arguably. – Lightness Races in Orbit Mar 27 '17 at 9:47
20

Can anyone point out any weakness in this setup, and if you do, how to make it secure?

Hardware solutions exist which can grab your system's memory without needing your login. And that's pretty much the weakness - if someone can get access to your system's memory, those passwords (or, at worst, the keys formerly unlocked by those passwords and still in use) can be captured by your opponent, who will then use them to access your (probably imaged) disk at will.

So it's a question of your risk profile and how paranoid you are. If you're running the Silk Road, then you shouldn't ever step away from a running laptop (and, quite frankly, after you shut it down you should shake it around and let it cool for a few hours before walking away from it.) If you're working for Shower Widgets International, you probably don't have so much to worry about. If you're a grad student... then you need to worry again.

  • 2
    I'm a grad student, and I don't understand why the paper you linked to shows that I need to be more paranoid. Can you please explain? – Kevin Oct 19 '15 at 20:03
  • 1
    @Kevin probably my bad; that paper has been described as a "research project" and for some reason my brain mis-remembered that as being a grad student project. Looking twice at the authors, I think my brain was wrong. That being said, I wouldn't be surprised if CS/EE graduate programs were the sort of place where nifty ideas for grabbing memory crop up and get tested... – gowenfawr Oct 19 '15 at 20:42
  • Also, IIRC firewire devices have free access to host memory, and there's even existing software available that'll get you in to many OS versions, so definitely within reach for CS/EE students. Not sure if eg. newer hardware has anything to mitigate this, for example something like IOMMU between firewire DMA and host memory. – Aleksi Torhamo Oct 19 '15 at 21:02
  • I see your point about not stepping from my laptop at all if I'm really paranoid... as mentioned below, there is always the possibility that the boot manager will be tampered with to get my password... That leads me to believe that the best way would be to carry the boot USB drive always with me and keep turning my PC off if I was really paranoid. – grepe Oct 20 '15 at 15:54
8

You mentioned you are running Ubuntu. I do not know which version it is but there has been a vulnerability in Ubuntu 14.04 LTS in which an attacker does not even need to brute-force your password and can bypass the lock screen by simply holding the enter key for about 30 seconds (Ubuntu Fixes Security Flaw in 14.04 LTS Lock Screen) and there are solutions to bypass lock screens as mentioned in the other answer.

He doesn't have any way to control my computer without my login password and any attempt to power it off and look at the hard drive directly would leave him with encrypted drive inaccessible without my disc encryption password.

No, you're not safe if the attacker is skilled and equiped: You may read about cold boot attacks.

  • That new lock screen was released in April 2014, more than a year ago (nearly a year and a half). I find it quite unlikely that there are still critical bugs like this in open source software. – Tim Oct 19 '15 at 13:39
  • 1
    @Tim Yes, as mentioned in my answer :) The OP did not mention his Ubuntu version and not all users run their updates :) – user45139 Oct 19 '15 at 13:41
  • 2
  • 1
    @Tim: I think JWZ's point is that a body of very widely used code exists to do this job which has not had any vulnerabilities found in it. However it keeps getting replaced by newly written code - with new security bugs - for cosmetic reasons. You can't assume OSS contains no critical bugs - especially if it uses a huge mass of libs because pretty trumps proven. – RedGrittyBrick Oct 19 '15 at 15:45
  • 1
    @Tim the OP is running Ubuntu; so in this situation it doesn't matter how secure or insecure Windows is - it matters if Ubuntu (and the components it's based on) is secure and has a good security track record. And exactly in the department of screen locks there have been numerous vulnerabilities in e.g. Gnome and Unity in the past (which were in part caused by inherent design flaws), so relying on such a screen lock for your valuable encrypted data might not be a good idea. Btw. I use Gnome screen lock myself, but I don't have sufficiently valuable data on my laptop (I hope). – oliver Oct 23 '15 at 11:11
1

Beside already mentioned cold boot attacks, there is always the possibility that the hardware or the initial boot loader is tampered such that it records you disc encryption password. You need to protect both.

Your laptop could be turned off and tampered while you are away, as you come back you would wonder a little bit, but just boot it normally. On the next occasion, the laptop is stolen or the stored and otherwise transferred password just used to encrypted the stored data.

If you have not protected the BIOS / the boot order, it is not that complicated to boot an alternative system and to modify the usually not encrypted or otherwise integrity-protected boot loader. Using an external boot loader or TPM could reduce this risk.

See also Laptop tampering and boot loader for some ideas.

  • If he returns to find his laptop has been rebooted he should promptly toss it in the garbage. I am going to use Van Eck en.wikipedia.org/wiki/Van_Eck_phreaking to get his master disk password without even touching the laptop. – emory Oct 19 '15 at 23:20
  • If a rootkit or a boot-time keylogger is installed, it doesn't really matter whether you rely on your screen lock for security or not, you're boned anyway. – Dmitry Grigoryev Oct 20 '15 at 7:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.