qubes security best practices for sleep / screen-locked computer?

[Christopher Lee]

Hi,

I'd like to ask experienced Qubes people (Qubans?  Quboids? Qubies?) about their preferred practices for securing highly confidential data on a Qubes machine, specifically the scenario where it is asleep or running with the screen locked.  It seems that in this case the only thing stopping someone with physical access is the standard lock screen; if they can get past that (or directly look at the RAM etc.) they can get the same access that the logged-in user has.  If you have ever typed your unlock code in a public place (and the ubiquitous CCTV cameras) that seems very weak.  (By the way, when I wake my Thinkpad T430 Qubes R2B2 from sleep, I can see everything on my desktop for about a second before the lockscreen hides it.  Is there a way to fix that?).

For this reason, it seems that the most confidential data should not be stored in clear-text on the Qubes filesystem (or perhaps should not be stored there at all?).  I would be very interested to hear how people have solved this, and what they think of the following options:

* store data encrypted (with something like TrueCrypt) and only access it under safe circumstances for the minimum time necessary (presumably in an appVM with no network access)

* store data in an HVM whose (virtual) disk is whole-disk encrypted in the usual LUKS way.  I don't know whether this is better or worse than TrueCrypt in terms of possibly leaking traces of information that serious forensics could pick up.

* store data on an encrypted USB key, that you only plug in for the brief time needed.

* avoid using sleep, because it is just too vulnerable.

* avoid letting your computer lock its screen in a public place (which forces you to type your unlock password).

other ideas?

I will be very grateful for any suggested "best practices"!  My apologies if this seems like a newbie question, but I haven't found the answer in my qubes readings (including the excellent posts from Joanna)... maybe I missed something?

Yours with thanks,

Chris

[cprise]

I'm not sure this is such a risk especially if you touch type; the camera(s) would have to be very high resolution or aimed at your fingers. Two-finger typists may be more prone to giving away their passwords with their finger movements. But assuming it is a risk then the best mitigation may be temporarily switching to using a fingerprint sensor, or using some sort of two-factor authentication though I don't know how this is achieved.

You could also try configuring your system so it only locks the screen when the laptop is closed shut. Otherwise, the screen lock is pretty strong security provided no one analyzes you on camera, nor does a cold boot attack, nor a tempest-style attack (sniffing radio emissions from your keyboard).

Your ideas about alternate encryption schemes would not buy you any extra security if you have those extra containers mounted in insecure venues. In the qubes-dev list there has been some discussion about enhancing physical security to prevent coldboot attacks (access to RAM). But so far the best practice with qubes is to use the Anti-Evil Maid feature and shut down the computer when in doubt about physical security.

IMHO, qubes is mainly a mitigation against software/network-initiated attacks... it does very well in that respect. The AEM feature does give us a leg-up on physical attacks, but the fundamental problems of physical computer security remain for the most part.

[Abel Luck]

> * avoid letting your computer lock its screen in a public place (which
> forces you to type your unlock password).
>

I'd like to point the list to this new tool called You Won't Take Me Alive

https://github.com/iSECPartners/yontma

It is a system daemon that runs in the background when the lock screen
is active. If it detects certain events (AC Power removed, etc) it will
immediately put the computer into hibernation.

For now, it is Windows only, but as you can see there is great interest
in a Linux version.

https://github.com/iSECPartners/yontma/issues/2

~abel

[Christopher Lee]

On Saturday, June 1, 2013 11:36:54 AM UTC-7, cprise wrote:

Your ideas about alternate encryption schemes would not buy you any extra security if you have those extra containers mounted in insecure venues. In the qubes-dev list there has been some discussion about enhancing physical security to prevent coldboot attacks (access to RAM). But so far the best practice with qubes is to use the Anti-Evil Maid feature and shut down the computer when in doubt about physical security.

Agreed.  As I said in the OP, the whole point of the "extra container" is to not mount it 99.9% of the time, only when you actually need it and only in safe circumstances.

 

[Joanna Rutkowska]

But if somebody can compromise your Qubes system (so, say Dom0), then
she could (well her malware actually) just sit and wait silently until
you finally access those secret containers and provide the passphrase
via keyboard (and the malware will capture that).

As a general rule: if your client system is compromised then there is no
crypto/other scheme that could protect your data. Remember that the
malware can be your "eyes, ears, and fingertips", meaning it can observe
everything you would see on the screen, as well as generate
keystrokes/other events on behalf of you.

So, the only solution would be to change your screen lock passphrase
more often. Sure, that's inconvenient.

A better approach, but currently not supported in Qubes architecture,
would be to have deprivliged GUI domain (or multiple-role domains).
Tricky, but we might work on that sometime in R3 times.

joanna.

[Christopher Lee]

On Sunday, June 2, 2013 11:38:43 AM UTC-7, Joanna Rutkowska wrote:

But if somebody can compromise your Qubes system (so, say Dom0), then
she could (well her malware actually) just sit and wait silently until
you finally access those secret containers and provide the passphrase
via keyboard (and the malware will capture that).

Of course.  But that doesn't cover all scenarios, here are some silly examples (that might not be silly somewhere in the world):

* someone steals laptop while it's asleep (e.g. from user's home) or even awake (e.g. while user is working at a cafe, or on a bus etc.)

* user is arrested and laptop confiscated, either asleep or even awake.

Defense in depth seems like a natural corollary of security by isolation.

BTW, when my R2B2 install wakes from sleep, the unlocked screen is displayed for about a second before the screen lock kicks in.  That's not Qubes' fault, but doesn't exactly make the screen locker seem like high security.

Thanks for all your fantastic work on Qubes!!!!

-- Chris

[Joanna Rutkowska]

It's a known KDE bug that seems to be manifesting itself on some GPUs
only. I remember observing it on my previous Vaio laptop, but on my
current T430 I don't see it (I think). If this concerns you, there are a
few things you can do:

1) Switch to an empty virtual desktop ("space") before sleeping your laptop,

2) Switch to Xfce4 Desktop Environment in Dom0 (I would expect it
doesn't have such problem)

3) Complain to KDE devel list, although I don't think they would care,
as I did it some years ago with no result.

joanna.

[Christopher Lee]

Thanks for the great advice!

-- Chris