Anti Evil Maid Idea

[jonbrown...@gmail.com]

I was wondering how much additional security this could give AEM if it supported adding Fido U2F as 2FA. it wouldn't require external services like TOTP and other variations. Additionally it would dramatically slow down an offline attack and greatly increase the cost to do it.

What do you think?

[Jean-Philippe Ouellet]

If I understand correctly, it would be completely useless.

The point of AEM is ultimately to somehow authenticate the computer to
the user, rather than the more common direction of authenticating the
identify of a user to the computer (which IIUC is all that U2F can
provide, where in the U2F case "computer" is usually intended to be
some remote web service).

There is some discussion of how one-time-passwords could be used as a
defense against evil maid attacks on page 37 of the Qubes arch spec
[1], but this does not generalize to all 2-factor auth mechanisms.
Specifically, it relies on the ability to produce successive and
predictable secrets, whereas U2F relies on correctly replying to
signing challenges.

Unless you can come up with some cryptographically-sound way to
integrate the information provided by a 2nd factor as a hard
requirement to complete the secrets-unsealing-at-boot process, then
the evil-maided computer could simply say "Yup, everything is okay,
thanks" and you'd be none the wiser.

[1]: https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf

On Tue, Dec 20, 2016 at 10:22 AM, <jonbrown...@gmail.com> wrote:
> I was wondering how much additional security this could give AEM if it supported adding Fido U2F as 2FA. it wouldn't require external services like TOTP and other variations. Additionally it would dramatically slow down an offline attack and greatly increase the cost to do it.
>
> What do you think?
>

> --
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c3c106c8-d308-48a7-b1cc-240246a0f2d0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jean-Philippe Ouellet]

On Tue, Dec 20, 2016 at 4:00 PM, Jean-Philippe Ouellet <j...@vt.edu> wrote:
> Unless you can come up with some cryptographically-sound way to
> integrate the information provided by a 2nd factor as a hard
> requirement to complete the secrets-unsealing-at-boot process, then
> the evil-maided computer could simply say "Yup, everything is okay,
> thanks" and you'd be none the wiser.

And even then, the existence of a 2nd factor does not somehow make the
computer more trustworthy. The existence of some external token says
nothing about whether or not your computer has been modified.

What 2fa in the context of evil maid attacks is specifically just
eliminating the fact that there is a static password to be exfiltrated
via an evil-maided computer, optimistically seeking to somehow
diminish the usefulness of a captured and recovered passphrase (by
re-encrypting your actual disk encryption key under a different
passphrase for use on subsequent boots). It does now somehow detect
that your computer has been evil-maided, nor prevent it from being so.

(Also, sorry for top-posting last time.)

[Jean-Philippe Ouellet]

On Tue, Dec 20, 2016 at 4:09 PM, Jean-Philippe Ouellet <j...@vt.edu> wrote:
> It does now somehow detect that your computer has been evil-maided, nor prevent it from being so.

"does now" should be "does not"

It's been a rough day >_>

[Jean-Philippe Ouellet]

On Tue, Dec 20, 2016 at 10:22 AM, <jonbrown...@gmail.com> wrote:

> it wouldn't require external services like TOTP and other variations.

The reason TOTP isn't useful is not specifically because it requires
an external service, but because the passphrase to be used on the next
boot is not known the previous time the computer is running, so it can
not re-encrypt the disk with the next passphrase. (Or really,
re-encrypt the key that key that encrypts disk - re-encrypting the
whole disk is simply too large of an operation.)

The reason things like HOTP or S/KEY are viable is because each next
passphrase is predictable when knows the secrets they are derived
from.

[Marek Marczykowski-Górecki]

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

In addition to all the points you've raised, there is one more: it's
hard to make OTP really one-time in AEM threat model. If someone gets
physical access to your hardware, he/she can make an offline copy of the
(encrypted) hard drive. And then, when you enter your OTP and it gets
intercepted by evil-maid type attack, it doesn't matter that the
password can't be used again on your machine. It will work for the
offline disk copy made earlier. If you combine it with some TPM-based
sealing, you only raise the bar by requiring the decryption happen on
the same hardware.

The key point of *AEM* is authentication computer to its user (before
entering the password), not the other way around.

Adding some sort of 2FA may make sense, but it's orthogonal to AEM.

- --
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

iQEcBAEBCAAGBQJYWaeGAAoJENuP0xzK19csDVcH/RRxgHGZmTPZ6GTWWF0Pm7Ch
Keijenz6RYeTGEJx7Uvbfog7VKvd7u9TJQW4zsxGl6FjU6Vu7zSHtJgoLD1Vc65P
d3dFbnrTL76CPELe9gTnxngBKTZstWGxOFGB3m7Tiwrs2/fl9BRoIyEI9vE43DWK
bbRhnupK7kYJidCGDugmprVBqoIYvm24fLUDbO9rY1eJYp5nqrtO13U7HBto4w+V
Z2QzUFKZsXZzyl4d/3kil97rwMCIedFds7lgDSQ9dupEkTRiF2L7TZnBgOCL2iLA
sUKTD89O4cMDwNSC8DQneWNxJh+3lh+esJGU5gGIF9/DD0l73ZuSBO2sQhwGIDM=
=qhNk
-----END PGP SIGNATURE-----