safer typing in public places

[pixel fairy]

just lined the sides of the lid of my laptop with velcro, and stapled the other end to cloth to fold over the keyboard while the lid is lowered. this allows for safer typing in public places. seems to work really well, but waiting on a friend to come over for a real test. see pic (remember to use dispvm!)

theres still audio and keyboard timing attacks. going to try playing randomly generated keyboard noises to turn on while typing and see if this can fool a directional mic. if so, that should cover cellphones mics and the like, but not for example a bugged hotel room.

we would need qubes on a small device you can slide fingers around quietly. personally, i find it easy to use my phone under my t-shirt or blanket (in a hotel room) or just covering half the screen with fingers. only did a couple times because i dont believe anyones after, or that ive ever been in a bugged hotel room. but, i know its a known issue in china. if that tablet liberm is selling runs qubes, problem solved :)

i think for most of us, the most sensitive thing we type is the login passphrase, and the disk encryption passphras(es) when booting (two if you also use on disk fde) so, there should be little exposure to begin with, especially if you change the login password often enough.

has anyone here experimented with bluetooth locks? it seems like a lot of extra scary code to run in dom0, but i like the idea of auto shutdown if device loses range. or maybe after a timeout period of some trigger?thats another discussion.

[pixel fairy]

in our test, it was still pretty easy to see at 5 and 7 oclock, probably because were both really skinny. a couple more strips in front on the sides fixes that.

[Jean-Philippe Ouellet]

On Tue, Nov 29, 2016 at 11:18 PM, pixel fairy <pixel...@gmail.com> wrote:
> has anyone here experimented with bluetooth locks? it seems like a lot of extra scary code to run in dom0, but i like the idea of auto shutdown if device loses range. or maybe after a timeout period of some trigger?thats another discussion.

Does not need to be dom0! (nor do I believe should it be!)

You may pass your bluetooth device to another VM (via PCI) and use a
trivial qrexec service in dom0 to trigger the shutdown.

[Andrew]

Jean-Philippe Ouellet:

Hi,

I've already packaged a Bluetooth dead man's switch with just such an
architecture as you describe, keeping (nasty) BlueZ in a domU. Please
note that I've made no progress on the improvements (I'll get there,
eventually... feel free to improve it yourself!).

See: https://groups.google.com/forum/#!topic/qubes-users/ZG9SK48pl0I

Andrew

[Foppe de Haan]

why not just learn a new keyboard layout, like colemak/workman/norman? Seems less of a hassle, besides being beneficial from a speed/ergonomics perspective.

[pixel fairy]

On Wednesday, November 30, 2016 at 2:26:30 PM UTC-5, Foppe de Haan wrote:
> why not just learn a new keyboard layout, like colemak/workman/norman? Seems less of a hassle, besides being beneficial from a speed/ergonomics perspective.

the same methods of video (and audio) analysis would still apply.

this isnt much hassle unless you do sensitive work in public places. otherwise, you only need the lid down long enough to type your screen saver password.

[Manuel Amador (Rudd-O)]

On 11/30/2016 04:18 AM, pixel fairy wrote:
> has anyone here experimented with bluetooth locks? it seems like a lot of extra scary code to run in dom0, but i like the idea of auto shutdown if device loses range. or maybe after a timeout period of some trigger?thats another discussion.

On your Bluetooth VM (usually a USBVM), run Blueproximity, and have
Blueproximity invoke a custom /etc/qubes-rpc/pixelfairy.Lock service on
dom0 which you will need to write yourself. It's a one-liner service:

loginctl lock-sessions

To invoke it from the Bluetooth VM, you need to ask Blueproximity to run
the command:

/usr/lib/qubes/qrexec-client-vm "$bluetoothvm" pixelfairy.Lock

Once you have given the Bluetooth VM permission ("yes to all") to invoke
the locker, it should work automatically every time you walk away.

The reverse is also possible — you could have a similar service that
unlocks the screen by running loginctl unlock-sessions.

--
Rudd-O
http://rudd-o.com/

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

But the later may be unwise - USB VM should be considered untrusted, so
giving it permission to unlock the computer doesn't look good. Unless
you take some measures to limit that ability. For example do some
challenge-response[1] with the device triggering the unlock operation,
so USB VM would not be able to do that without the device actually being
present (assuming that device is safe enough to not be cloned, and
resistant to proxy attacks etc.). But better don't do that.

[1] https://www.qubes-os.org/doc/yubi-key/

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJYP2WYAAoJENuP0xzK19csbs4H/Aw4aVz/upAYoHv68WCxAnk/
NpUPPRyhiz51Kle695445LdwK7P4viqtzooL7YofVgDvbrrVYJyWBtyoWarRswsk
EKRGLUCM6KIboAd30rlFs3G/H+QTOb9EEbIhxO90dWnE88rBm/TGViXi4b9c9uVq
3q5OxKAs7l4iBfMONKVMexSjVP36hD4+/79xnYja6+QUCuCPXG26oYe/dBYNkgqD
+eXbDAvsy4vvw5do++S2HgI3n1cB08cp3tFuUgLOSCRdrD59O1f70WNgkMmBSHQc
gpqbuBTmfLYCxHQspku4gRdVFpE43VSB6YBAmoaY+m8z9DaeQE9hTFjAYN/4gmo=
=PkgG
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Wed, Nov 30, 2016 at 5:54 PM, Manuel Amador (Rudd-O)
<rud...@rudd-o.com> wrote:
> On your Bluetooth VM (usually a USBVM), run Blueproximity, and have
> Blueproximity invoke a custom /etc/qubes-rpc/pixelfairy.Lock service on
> dom0 which you will need to write yourself. It's a one-liner service:

You may also wish to have dom0 periodically try to invoke a service in
the bluetoothvm which interacts somehow with the bluetooth device,
such that a denial of service on your bluetooth vm (e.g. crashing
blueproximity) does not lead to a failure to lock.

What period this polling needs to happen at to lock your device in a
reasonable time if your bluetooth vm does stop operating correctly is
up to you.