[GSoC] Progress report: Anti Evil Maid enhancements

[Patrik Hagara]

Hi!

As some of you may already know, I have been accepted into the Google
Summer of Code program to work on improving Qubes' Anti Evil Maid suite
to provide resistance against shoulder surfing and/or video
surveillance. The project proposal I submitted can be found archived on
this (qubes-devel) mailing list or in my GitHub repository [0].

It looks like I have managed to just slightly overestimate the time
needed to write the code for all the additional features and options for
AEM package. :)

Right now, I would say the first version of my code changes is almost
finished. Small bugs here and there are to be expected, but unless my
mentor (Rusty Bird) or anyone else has objections, I would consider the
new AEM workflow to be finalized.

Any and all code reviews are welcome! The changes I made are stored in
my fork of AEM repository [1].

For now, the next steps I am planning are to:
* verify all the added features work as intended (lots of reboots)
* check for any regressions (even more rebooting)
* document the new AEM setup, upgrade and usage procedures

Again, I would love to hear feedback -- and not just from my mentor! ;)


Cheers,
Patrik



[0] https://github.com/phagara/gsoc2017-qubes-aem-proposal/releases
[1] https://github.com/phagara/qubes-antievilmaid

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Patrik,

Sorry that it took me a while to respond to your first "offical" :)
progress report. This email has some general stuff, but I'll post more
here or on GitHub later this week.

> Right now, I would say the first version of my code changes is almost
> finished.

I'll summarize part of my mental image of this first version (also for
the benefit of casual readers), please correct me if it's wrong.

There are now two new AEM setups: Setup A has TOTP and encrypted
keyfile secrets on the only AEM stick; setup B has TOTP and fallback
text/image secrets on a primary, and the encryted keyfile secret on a
secondary AEM stick. (Is there any attack where a TOTP secret adds
additional security in setup A? If not, it should only be done for
setup B, right?)

But given setup B's very subtle security benefits [1] and tough UX -
now that its (necessary) complexity of implementation has been proven,
which I severely underestimated, I keep agonising if your original,
simpler proposal would be the better trade-off after all... Somehow I
had focussed too much on the time setup B would take to implement
(which seemed okay as a stretch goal), and not enough on the
substantial increase in tricky code paths that future developers
working on AEM will have to understand. With probably even more to
come, e.g. fallback support when the secondary stick is not at hand,
or other corner cases that tend to turn up in testing. Not to mention
the user-facing things like documentation and usage messages.

I'm mortified to ask you this so late, but what do you think about
scrapping the setup B and TOTP related parts? And considering them
research showing that your original design approach was tasteful and
mine was overly complicated. Or am I too squeamish about the amount of
code?

(CCing Marek, who ultimately decides what goes into the AEM repo, to
see if he has an opinion on this issue.)

Rusty


1. https://groups.google.com/d/msg/qubes-devel/0kOgeiTstJ8/GQrAkGpwCQAJ
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZOFf1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfoRUQAIdog9F0MNDQRgOQsvD1EraX
iGEyc4nrpdTS/cVM8TLHQK+dMcZzcRomV2MfZ7a/OME0J3npf51nLO6M1agpwkuu
z0b4COEMtZnyBjb+0z5NDwxGDRBfphI7gUJZZugRJtwNTKUsTxfpBOKBR6Kf55zk
yBQ1U/t33bmiWZkHpxuGXsH4bt3VwrB4BGCDglcapQmou6uhI2Nf0e1YJERgXDyI
Ovg8fHTQu18eeKilu+Cw3nxrARoS4pe//SwUXg9M/NKsMZiYjnpfD4tk8XaCFxb5
V0RCZScozjETW4SCyHNkRnl0s5Qdfs0v6X4t4DQ205E4hIYWFV3ak0I1ucd1uxKE
orWEAzddOCIvPFojOzT07VD0g2KQNsovD7VeVO3m0m93n0D6nhHG89/GS9JMg8bX
KkWIWNoqM3F0tmyhFEihEG/noKRoEacxivVa75xFcHvqcBjC03DWrrvO9TJZ1beI
2XTB/imyFSVYsOJxmrssxzjmtthpZMiatVx5y9q1GN9zuE6XkDrsemcWoLEtlljf
qvZHYcSoc5fmWJn20udX4ms9Pp5yJJcp6WtyoSFglvKiUmb+vA2R9+MjKxRPI9CJ
deaF64QtIa9qTlKwG0BhgizRIdhAyZCvEmTv3+1ynXL6YpCjxW248S25yazbwh6S
lKAehptBjTa4nkk4uWs2
=WEkf
-----END PGP SIGNATURE-----

[Patrik Hagara]

On 06/07/2017 09:45 PM, Rusty Bird wrote:
> Hi Patrik,
>
> Sorry that it took me a while to respond to your first "offical" :)
> progress report. This email has some general stuff, but I'll post more
> here or on GitHub later this week.
>
>> Right now, I would say the first version of my code changes is almost
>> finished.
>
> I'll summarize part of my mental image of this first version (also for
> the benefit of casual readers), please correct me if it's wrong.
>
> There are now two new AEM setups: Setup A has TOTP and encrypted
> keyfile secrets on the only AEM stick; setup B has TOTP and fallback
> text/image secrets on a primary, and the encryted keyfile secret on a
> secondary AEM stick.

Yes, that is correct.


> (Is there any attack where a TOTP secret adds additional security i> setup A? If not, it should only be done for setup B, right?)

One possible attack scenario I thought of is for an evil maid attacker
to configure the machine to disregard user's AEM boot device and instead
boot attacker-controlled kernel. This kernel would then pretend to have
successfully unsealed the LUKS key file -- the user has no way of
knowing and will thus enter the key file passphrase, which would
subsequently get captured for the attacker (along with a copy AEM boot
stick contents).

Now the user would have to immediately and completely destroy their
computer, even if they are sure nobody has _seen_ them typing the
passphrase. I would consider this to be a regression from status quo.

With the additional usage of TOTP, this kind of attack will be apparent
to the user (wrong TOTP code => do not enter key file passphrase).

The attacker can still, of course, learn the key file passphrase via an
observation attack and then seize the AEM stick -- but this is true even
for both the "setup B" with two sticks (which would always be carried by
the user together, ie. no added complexity to the seizure process) and
current "plain" AEM setup.

> But given setup B's very subtle security benefits [1] and tough UX -
> now that its (necessary) complexity of implementation has been proven,
> which I severely underestimated, I keep agonising if your original,
> simpler proposal would be the better trade-off after all... Somehow I
> had focussed too much on the time setup B would take to implement
> (which seemed okay as a stretch goal), and not enough on the
> substantial increase in tricky code paths that future developers
> working on AEM will have to understand. With probably even more to
> come, e.g. fallback support when the secondary stick is not at hand,
> or other corner cases that tend to turn up in testing. Not to mention
> the user-facing things like documentation and usage messages

Yes, the code got fairly complex pretty quickly. And there is still
number of cases my code does not cover yet (plus a few bugs I found in
the meantime). :-\

> I'm mortified to ask you this so late, but what do you think about
> scrapping the setup B and TOTP related parts? And considering them
> research showing that your original design approach was tasteful and
> mine was overly complicated. Or am I too squeamish about the amount of
> code?
>
> (CCing Marek, who ultimately decides what goes into the AEM repo, to
> see if he has an opinion on this issue.)

Personally, I would be OK with abandoning the two sticks scenario (but
keeping TOTP as written above). I would say it was a worthwhile
experiment that just fell short on both UX and security (due to code
complexity) and, as you stated, would be hard for future developers to
understand/maintain. Also, I would imagine users would have a hard time
comprehending the resulting lengthy documentation, even if well-written.

I am eager to hear Marek's thoughts on this issue you brought up.

Thank you for the feedback! :)


Cheers,
Patrik

[Marek Marczykowski-Górecki]

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

Yes, IMO this case is important - it was exactly the reason why AEM was
developed in the first place - to somehow authenticate machine to the
user, before entering the passphrase.

> The attacker can still, of course, learn the key file passphrase via an
> observation attack and then seize the AEM stick -- but this is true even
> for both the "setup B" with two sticks (which would always be carried by
> the user together, ie. no added complexity to the seizure process) and
> current "plain" AEM setup.

Yes, this attack is possible because all the user enters is a static
secret. I was thinking for some time about a scheme where user enters
also something dynamic - OTP (not necessary TOTP) - either in addition
to normal passphrase or, instead of. But it's tricky how to do it
properly.
One idea is to have LUKS keyfile encrypted with the next OTP (in
addition to other protections like being sealed to PCR values of TPM).
And after successful user authentication, prepare it for the next boot
(since you have access to decrypted disk now, you can access OTP key to
generate next OTP). In practice probably not just one encrypted keyfile,
but few of them (like 5) using consecutive OTPs to allow some window if
you accidentally press a button on OTP token (or a button in mobile
app).
This idea have at least few weaknesses:
- each boot require some write on AEM media, which means a) it can't be
read-only, b) in case of flash it will reduce its lifetime (to make
password really one-time, already used encrypted keyfiles should be
wiped - probably using shred or sth like this)
- if someone copy AEM stick _before_ observing proper successful boot,
he/she can replay it, because copy of AEM will still have "old" OTP
valid (a keyfile encrypted with it)
- similar to the above - it is not resistant against brute-force
attack; 6 digit code (or even 8) is not so long, even if you force
reboot every few tries and somehow prevent offline cracking (dumping
unsealed but still encrypted LUKS keyfile from RAM)
- the boot procedure more and more rely on security of some additional
device

Some of it may be possible to improve using monotonic counter from TPM
(I assume there is something like this). Maybe some
challenge-response could be performed here (after authenticating machine
to the user), with usage of TPM monotonic counter, instead of "just" OTP?

Anyway, this looks like a major change that will require some more
thinking about its design first.

I also think the setup A, with TOTP is overall better than setup B after
considering all factors here (UX, complexity, security gains).

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

iQEcBAEBCAAGBQJZOIIiAAoJENuP0xzK19csnQgH/jT4zY1JRQfHIWg515BPcvVG
q70Gh6yltLiJF0DuRqZQk8JhjZFu9w8JWDP7RKcsdhVQC6b41OLA00EyBd7mGQIk
cr3Ao07xRuDY8CybOSO51Hs4yiL+YdLOE4F1Vf/8XBlF8K5oNWTwVSHviPTbXuWt
D4Fzv24iA1P7e7gBBV6UONGjIl4/Md4nkFbRpV6H8iMiLGLmFFjKhn04Ioo18wXx
HliIgJcb1hb29XAAJrWYIQY+HPIQe0TiWdA7On1j4PAaWE+gBxmj8+2N1MqmTwLJ
R8nbO1kJGlPSC0EHjWT/sBoVdjsuenY6jcjYumzPqL9fEUJ8moFpo/8aYZA2SvI=
=Rmyr
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

Hell yeah!

Of all the times I've had tunnel vision while trying to keep AEM
attacks and defenses straight, this takes the crown. This and ...

> > With the additional usage of TOTP, this kind of attack will be apparent
> > to the user (wrong TOTP code => do not enter key file passphrase).
>
> Yes, IMO this case is important - it was exactly the reason why AEM was
> developed in the first place - to somehow authenticate machine to the
> user, before entering the passphrase.
>
> > The attacker can still, of course, learn the key file passphrase via an
> > observation attack and then seize the AEM stick -- but this is true even
> > for both the "setup B" with two sticks (which would always be carried by
> > the user together, ie. no added complexity to the seizure process) and
> > current "plain" AEM setup.

... the fact that I could have sworn there was a scenario where some
sequence of events involving retroactive access to a recording of a
passphrase being entered made a difference between setup A and B, but
now I can't bring back anything from memory that isn't flawed or
completely unrealistic - I'm taking these as signs that it's very good
to have someone new working on AEM, and with great attention to
detail. Also, that I should make it a habit to write this shit down.

Glad you both see it this way. The simple design (with TOTP) it is then.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZOJZOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfTRoP/R2eLPabGOlimqbi76QOgTKh
BE44YFi0NHVBY3UcY5tm49e+PtleP11z/nYB0biEIgex4BnGFhAZnr8OLm30TgmX
BJzdWfMEcsRjDPPBKncXqtGLjXVYowJWpA7ilMIva33n2gYYC36FVPTDyBErhcx+
XboI+PRIVGdL4R7N9xBCtM3hf8hgJXAoMRc15oTvp++dbpLMX9I5ixHUEMGErIQC
EAPZGyl56cgpolQtubb1Pt5YjOqsXVzy+3Dt6WQgVVWmyOs8rHl+9YXpnjTglPyw
tQ9Ae+YsE4g9DvrUjF3drYkmCC4WvbJntqtpMVuHz5AkvtSp+/ZP/+Yx+mEU/avf
TcnK8AAtKImZIzrHd4a/vIP6+mCy/YwOvbSlzMDENpDpzBOQraijFUtMsy7f3ZP9
GyOC4FVoD7HYdcPqpfiOhXapu/f/UvYThB1/lWm+Mh2vBCzI8qX7qqudP78p7xXN
5B43XF7H7vrT30vLeevaWPFsYmjmpEOhthOAf4170V52rVGyDvWti/bnKQn/jTvS
JdZiHz7IINAuIEfc3AE1cxa2cxA1Dxwygi9EcNXPcJm41qbM4L+Dk9bLP/N8cz/N
ZM0kl9Nnx4flE6ngGpMpy0FS8L2bRajKsJjR0dgJWVIyJMIm82strj4fUTGfiRY7
fY/9MAz0bnexOJYEW/Fz
=tAfh
-----END PGP SIGNATURE-----

[Patrik Hagara]

On 06/08/2017 12:45 AM, Marek Marczykowski-Górecki wrote:> I was

thinking for some time about a scheme where user enters
> also something dynamic - OTP (not necessary TOTP) - either in addition
> to normal passphrase or, instead of. But it's tricky how to do it
> properly.
> One idea is to have LUKS keyfile encrypted with the next OTP (in
> addition to other protections like being sealed to PCR values of TPM).
> And after successful user authentication, prepare it for the next boot
> (since you have access to decrypted disk now, you can access OTP key to
> generate next OTP). In practice probably not just one encrypted keyfile,
> but few of them (like 5) using consecutive OTPs to allow some window if
> you accidentally press a button on OTP token (or a button in mobile
> app).
> This idea have at least few weaknesses:
> - each boot require some write on AEM media, which means a) it can't be
> read-only, b) in case of flash it will reduce its lifetime (to make
> password really one-time, already used encrypted keyfiles should be
> wiped - probably using shred or sth like this)

A few notes regarding this point:
ad a) the boot-time sealing script already expects AEM media to be
writable if secrets fail to unseal, does it not?
ad b) wiping one-time key files might prove problematic with
(unencrypted) flash media due to their wear-leveling algorithms.

> - if someone copy AEM stick _before_ observing proper successful boot,
> he/she can replay it, because copy of AEM will still have "old" OTP
> valid (a keyfile encrypted with it)

This weakness is impossible to prevent in every scenario I have been
able to think of so far. :( The upside is that the attacker will need to
posses (a copy of) the AEM stick _and_ know the passphrase(s) used _and_
gain physical access to the computer -- essentially adding one more
factor (possessing AEM boot files) compared to the existing implementation.

> - similar to the above - it is not resistant against brute-force
> attack; 6 digit code (or even 8) is not so long, even if you force
> reboot every few tries and somehow prevent offline cracking (dumping
> unsealed but still encrypted LUKS keyfile from RAM)
> - the boot procedure more and more rely on security of some additional
> device
>
> Some of it may be possible to improve using monotonic counter from TPM
> (I assume there is something like this). Maybe some
> challenge-response could be performed here (after authenticating machine
> to the user), with usage of TPM monotonic counter, instead of "just" OTP?

How about storing the key file itself inside the TPM? This may (or may
not) open some new possibilities while, apparently, not extending the
attack surface since the raw LUKS key file already passes through the
TPM before being encrypted by the user.

Should the TPM not be trusted enough to handle disk encryption key
material, then _two_ user encryption passphrases would be required in
order to prevent TPM from learning the LUKS key file contents while
still attesting the correct machine state by being able to unseal it --
ie. enc(seal(enc(keyfile))).

What are your thoughts on this?


Cheers,
Patrik

[Marek Marczykowski-Górecki]

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

On Thu, Jun 08, 2017 at 11:19:22AM +0200, Patrik Hagara wrote:
> On 06/08/2017 12:45 AM, Marek Marczykowski-Górecki wrote:> I was
> thinking for some time about a scheme where user enters
> > also something dynamic - OTP (not necessary TOTP) - either in addition
> > to normal passphrase or, instead of. But it's tricky how to do it
> > properly.
> > One idea is to have LUKS keyfile encrypted with the next OTP (in
> > addition to other protections like being sealed to PCR values of TPM).
> > And after successful user authentication, prepare it for the next boot
> > (since you have access to decrypted disk now, you can access OTP key to
> > generate next OTP). In practice probably not just one encrypted keyfile,
> > but few of them (like 5) using consecutive OTPs to allow some window if
> > you accidentally press a button on OTP token (or a button in mobile
> > app).
> > This idea have at least few weaknesses:
> > - each boot require some write on AEM media, which means a) it can't be
> > read-only, b) in case of flash it will reduce its lifetime (to make
> > password really one-time, already used encrypted keyfiles should be
> > wiped - probably using shred or sth like this)
>
> A few notes regarding this point:
> ad a) the boot-time sealing script already expects AEM media to be
> writable if secrets fail to unseal, does it not?
> ad b) wiping one-time key files might prove problematic with
> (unencrypted) flash media due to their wear-leveling algorithms.

Good points.

> > - if someone copy AEM stick _before_ observing proper successful boot,
> > he/she can replay it, because copy of AEM will still have "old" OTP
> > valid (a keyfile encrypted with it)
>
> This weakness is impossible to prevent in every scenario I have been
> able to think of so far. :( The upside is that the attacker will need to
> posses (a copy of) the AEM stick _and_ know the passphrase(s) used _and_
> gain physical access to the computer -- essentially adding one more
> factor (possessing AEM boot files) compared to the existing implementation.

_IF_ monotonic counter in TPM can be used also to seal something, then
it should be possible to mitigate this attack too: once you advance such
counter, you will not be able to unseal key sealed to the old one.
But this will only work if such operation is possible with TPM (I don't
know).

> > - similar to the above - it is not resistant against brute-force
> > attack; 6 digit code (or even 8) is not so long, even if you force
> > reboot every few tries and somehow prevent offline cracking (dumping
> > unsealed but still encrypted LUKS keyfile from RAM)
> > - the boot procedure more and more rely on security of some additional
> > device
> >
> > Some of it may be possible to improve using monotonic counter from TPM
> > (I assume there is something like this). Maybe some
> > challenge-response could be performed here (after authenticating machine
> > to the user), with usage of TPM monotonic counter, instead of "just" OTP?
>
> How about storing the key file itself inside the TPM? This may (or may
> not) open some new possibilities while, apparently, not extending the
> attack surface since the raw LUKS key file already passes through the
> TPM before being encrypted by the user.

AFAIK there is very little storage inside TPM and it have even more
limited write count than standard flash memory. Also, for this to work,
it would require that TPM allow you to access the key only when you boot
valid OS - so, not only seal (encrypt) the key to PCR values, but also
make it condition to read some NVRAM part. AFAIR such thing isn't
supported - you can only protect some parts of NVRAM with SRK.
So this probably will not work.

> Should the TPM not be trusted enough to handle disk encryption key
> material, then _two_ user encryption passphrases would be required in
> order to prevent TPM from learning the LUKS key file contents while
> still attesting the correct machine state by being able to unseal it --
> ie. enc(seal(enc(keyfile))).

If we don't trust TPM here, the whole AEM makes very little sense...
Note that malicious TPM may not only steal values sent to it, but also
lie about PCR values, effectively making you enter valid passphrase into
superseded password prompt.

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

iQEcBAEBCAAGBQJZOTuBAAoJENuP0xzK19csUrkH/3UFP3fMM5RsbWEKzh5MgD4e
x3ShFO/POYtul3FwWv+SehIRYCcjTI5WVVFFkF7tDRMgIMToI1ME/rkcC+0HlOQB
oF+ANZxMKHawlPHC9jFZas/GDitTVQdILyUgneiy1/np5hqY4AkzRQiSLgyEYt4n
b0bZmRrSJcT1u3Y32Szt4DSqYDkMo72riJ2TX4witGpc2IfrXmal/bWiLlbLkhfP
G3PxhcnIKgCe7VnKKjbr0YkUpGL/4DzjtfKSxaGf+UmThLB8USAqwuvypcdWJLlA
jxsjymkZfrFHKbYY83lrkRP9ni2tQWnnXE9YJwqeLJBQygYO861x5P3HaO19D8A=
=Noq7
-----END PGP SIGNATURE-----

[Patrik Hagara]

On 06/08/2017 01:56 PM, Marek Marczykowski-Górecki wrote:>>> - if

someone copy AEM stick _before_ observing proper successful boot,
>>> he/she can replay it, because copy of AEM will still have "old" OTP
>>> valid (a keyfile encrypted with it)
>
>> This weakness is impossible to prevent in every scenario I have been
>> able to think of so far. :( The upside is that the attacker will need to
>> posses (a copy of) the AEM stick _and_ know the passphrase(s) used _and_
>> gain physical access to the computer -- essentially adding one more
>> factor (possessing AEM boot files) compared to the existing implementation.
>
> _IF_ monotonic counter in TPM can be used also to seal something, then
> it should be possible to mitigate this attack too: once you advance such
> counter, you will not be able to unseal key sealed to the old one.
> But this will only work if such operation is possible with TPM (I don't
> know).

Yes, the Trusted Computing Group's TPM specification version 1.2 (not
1.1, however) does mandate at least four 32-bit monotonic counter to be
available, with enough storage endurance to survive at least 7 years of
counter increments every 5 seconds. See the "Part 1 - Design Principles"
document [0], section 17 "Monotonic Counter".

However, while both the tpm_tis kernel driver and TrouSerS user-space
library (along with tpm-tools) claim to support TPM 1.2 spec, I was
unable to find any reference to monotonic counters in either (though
maybe I just wasn't looking hard enough).

>>> Some of it may be possible to improve using monotonic counter from TPM
>>> (I assume there is something like this). Maybe some
>>> challenge-response could be performed here (after authenticating machine
>>> to the user), with usage of TPM monotonic counter, instead of "just" OTP?
>
>> How about storing the key file itself inside the TPM? This may (or may
>> not) open some new possibilities while, apparently, not extending the
>> attack surface since the raw LUKS key file already passes through the
>> TPM before being encrypted by the user.
>
> AFAIK there is very little storage inside TPM and it have even more
> limited write count than standard flash memory. Also, for this to work,
> it would require that TPM allow you to access the key only when you boot
> valid OS - so, not only seal (encrypt) the key to PCR values, but also
> make it condition to read some NVRAM part. AFAIR such thing isn't
> supported - you can only protect some parts of NVRAM with SRK.
> So this probably will not work.

I'll look into this.

>> Should the TPM not be trusted enough to handle disk encryption key
>> material, then _two_ user encryption passphrases would be required in
>> order to prevent TPM from learning the LUKS key file contents while
>> still attesting the correct machine state by being able to unseal it --
>> ie. enc(seal(enc(keyfile))).
>
> If we don't trust TPM here, the whole AEM makes very little sense...
> Note that malicious TPM may not only steal values sent to it, but also
> lie about PCR values, effectively making you enter valid passphrase into
> superseded password prompt.

Of course, you're right.


Cheers,
Patrik


[0] https://trustedcomputinggroup.org/tpm-main-specification/

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Marek Marczykowski-Górecki:

> On Thu, Jun 08, 2017 at 11:19:22AM +0200, Patrik Hagara wrote:
> > How about storing the key file itself inside the TPM? This may (or may
> > not) open some new possibilities while, apparently, not extending the
> > attack surface since the raw LUKS key file already passes through the
> > TPM before being encrypted by the user.

Wait, what? Does this refer to a hypothetical change to AEM? In the
current WIP version, the keyfile is encrypted before sealing and
decrypted after unsealing. (Using scrypt - if we trusted the TPM to
handle the raw keyfile, we could just use SRK password protection
instead.)

> AFAIK there is very little storage inside TPM and it have even more
> limited write count than standard flash memory. Also, for this to work,
> it would require that TPM allow you to access the key only when you boot
> valid OS - so, not only seal (encrypt) the key to PCR values, but also
> make it condition to read some NVRAM part. AFAIR such thing isn't
> supported - you can only protect some parts of NVRAM with SRK.
> So this probably will not work.
>
> > Should the TPM not be trusted enough to handle disk encryption key
> > material, then _two_ user encryption passphrases would be required in
> > order to prevent TPM from learning the LUKS key file contents while
> > still attesting the correct machine state by being able to unseal it --
> > ie. enc(seal(enc(keyfile))).
>
> If we don't trust TPM here, the whole AEM makes very little sense...
> Note that malicious TPM may not only steal values sent to it, but also
> lie about PCR values, effectively making you enter valid passphrase into
> superseded password prompt.

If I understand it right and sending the raw (or brute forcable)
keyfile to the TPM is being considered, IMO we should urgently avoid
that. Of course a malicious or exploitable TPM can be used to mount an
evil maid attack, but trusting the TPM with the keyfile aggravates a
probably much more common threat: For example, any computer acquired
during a regular search and seizure, and then possibly lying around in
an evidence locker for a few years anyway, could be decrypted as soon
as forensics finds a way to peek into the TPM.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZOVWlXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf7kcQAIa4azJ4Z8V5N7c3DjqVnltO
L9QTiv6jvxQg8XHQrKyxpnXKVZ3BuTR2g996C6oAe2IHNoACEWGPNzTsM3O7Ea9o
6aNfVPcDY7bgk5j5fqmlpKy8Sn2t/Ab++OFASNBr8V6wre1r8ANACF9BaMVbaDKz
E2CJyMFSP2zW/DFFv83fFlXoNxtdmM7lfFTYiJTAg2x60/NVqq1zR/ONK/QBSbMr
310RpBzH0l4N6SKg8AckBJICDFus1yeAY8niWUQXpdltG56gv9hyh0CzKRPWve5+
WKxF/1se4A8lMldXBNKYDyr/vdwsTMbfZrSBsW0hg2k3v0rxWCmSIT3UrDZNO6nT
Sa7jKyzTSMzlRES0+PKJusP0G+ScIIrq6l1sueLfxbPo84A3Bdz78LduS69Ffd2F
ERcmKfSwlmACjSZSOWzxMe9Vca9GpOABxx5RC3eUIuxTYTJ6WxcNFyigPd4+R8Y9
2EtGkqAzGHyRDpS2Tpy+WBsrC8UPMmc/pMWNh5VPd8U/eJp/w9P9D88s6LhIWXJX
4OgGNsAi0w2qIsNc7dCIUJddsLvu1j/OHyhXp+MisvOGzRQcrfTUY5ncf8xMKWEj
k3tq2h1fezHtAVPqEpoim2jCIqW0cjkok+lLVfQXYAYNZ6s0OGihRmrL2L6tR5nK
KaJkV0nubCCK1oyffeKZ
=1jna
-----END PGP SIGNATURE-----

[Patrik Hagara]

On 06/08/2017 03:48 PM, Rusty Bird wrote:
> Marek Marczykowski-Górecki:
>> On Thu, Jun 08, 2017 at 11:19:22AM +0200, Patrik Hagara wrote:
>>> How about storing the key file itself inside the TPM? This may (or may
>>> not) open some new possibilities while, apparently, not extending the
>>> attack surface since the raw LUKS key file already passes through the
>>> TPM before being encrypted by the user.
>
> Wait, what? Does this refer to a hypothetical change to AEM? In the
> current WIP version, the keyfile is encrypted before sealing and
> decrypted after unsealing. (Using scrypt - if we trusted the TPM to
> handle the raw keyfile, we could just use SRK password protection
> instead.)

Oh right, sorry for the mistake -- the key file is indeed first
encrypted and only then passed through TPM for sealing.

>> AFAIK there is very little storage inside TPM and it have even more
>> limited write count than standard flash memory. Also, for this to work,
>> it would require that TPM allow you to access the key only when you boot
>> valid OS - so, not only seal (encrypt) the key to PCR values, but also
>> make it condition to read some NVRAM part. AFAIR such thing isn't
>> supported - you can only protect some parts of NVRAM with SRK.
>> So this probably will not work.
>
>>> Should the TPM not be trusted enough to handle disk encryption key
>>> material, then _two_ user encryption passphrases would be required in
>>> order to prevent TPM from learning the LUKS key file contents while
>>> still attesting the correct machine state by being able to unseal it --
>>> ie. enc(seal(enc(keyfile))).
>
>> If we don't trust TPM here, the whole AEM makes very little sense...
>> Note that malicious TPM may not only steal values sent to it, but also
>> lie about PCR values, effectively making you enter valid passphrase into
>> superseded password prompt.
>
> If I understand it right and sending the raw (or brute forcable)
> keyfile to the TPM is being considered, IMO we should urgently avoid
> that. Of course a malicious or exploitable TPM can be used to mount an
> evil maid attack, but trusting the TPM with the keyfile aggravates a
> probably much more common threat: For example, any computer acquired
> during a regular search and seizure, and then possibly lying around in
> an evidence locker for a few years anyway, could be decrypted as soon
> as forensics finds a way to peek into the TPM.

Yes, that sounds like a realistic threat and should be avoided.


Cheers,
Patrik

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rusty Bird:

> In the current WIP version, the keyfile is encrypted before sealing
> and decrypted after unsealing. (Using scrypt - if we trusted the TPM
> to handle the raw keyfile, we could just use SRK password protection
> instead.)

Sorry, I have to retract the part that says SRK password protection
for the keyfile is (in theory) an alternative: The SRK password
applies to the unseal operation for the TOTP secret as well, so the
user has to enter it before they know that the computer is in a good
state. But then the attack Patrik pointed out as the motivation for
adding TOTP in the first place would still succeed.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZOhRnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfRbIP/0+t8tRzYEGvEbk60Oyzs9ra
/JFsJxbRVefL1qMkKN2gDnohJZ9uwDbVOzzzBduvZPQwnELtTG+p73fM2Hh63BhG
DTQgMfhwuvenwkvvlUD4DEQW9rpJvnMh1JbdyI5AnpaYavrz61XjmK34zmvPxCzS
OENhsrWMKmTKgZ5Vhb93qURkj+zYLhKSoBYbY7jb2KPPQfLOAteHsFl4DMfSXZop
MJbFZGL3m9o7Bl3b/ZPyCb9lnCoQ5y8PFome5jD9+N4FCvwyfwnQlLN6J5DL7oWz
EwL6mNvTMPkAtgmPsP6djBmKIWWy4nogndPQSpQVim2OWYnFD3XYBV5pOlygyN2U
2T32c5dvjB68UjZQBEvfECpMCtLZVXUnPpdT6zYKyqVGqh7Aucuh3e48noec9HgN
/3iw363CvHnn9oLWpESNy4RxfbpHth/kXPTFUWU6NN4ksXb1JCD4yZGjXQEki2DP
F1mA3zZb5SBP0jcLPFFYgxI2rRfmxsJLm/WHcE5HckUl448nEPqFjn0NUUfgSE0B
OL5EP00L3gCWq1bbYarZNWZuoAVkLNGX4aFXnSPa3nP8OvScCvZKyDVrhLqFsAmn
96ggE1kTE2S69EyF2wt09M+qIVW9NrEN7/y2UNfgxww7DHSrNUGuCcxyreEdkA20
AEEP8Pnme1dBigypwv+S
=N6wp
-----END PGP SIGNATURE-----

[Patrik Hagara]

On 06/09/2017 05:22 AM, Rusty Bird wrote:
> Rusty Bird:
>> In the current WIP version, the keyfile is encrypted before sealing
>> and decrypted after unsealing. (Using scrypt - if we trusted the TPM
>> to handle the raw keyfile, we could just use SRK password protection
>> instead.)
>
> Sorry, I have to retract the part that says SRK password protection
> for the keyfile is (in theory) an alternative: The SRK password
> applies to the unseal operation for the TOTP secret as well, so the
> user has to enter it before they know that the computer is in a good
> state. But then the attack Patrik pointed out as the motivation for
> adding TOTP in the first place would still succeed.

I think using a SRK passphrase is irrelevant in this scenario.

Say the attacker managed to compromise the computer so that it always
boots attacker-controlled kernel. User gets prompted for the SRk
passphrase and complies, but the TPM will fail to unseal anything since
the PCRs wouldn't match -- ie. no correct TOTP code displayed.

The same would be true even if the well-known SKR (ie. no passphrase)
was used (which is, to my knowledge, already considered secure paired
with removable AEM devices). And it would have better UX -- one less
(near-useless, in this case) passphrase to remember/type.

However, it is true that the attacker will have the ability to copy
contents of the real AEM stick and on subsequent evil maid attack will
be able to unseal both the TOTP seed and encrypted LUKS key file -- and,
assuming they also managed to snoop the key file encryption passphrase,
will gain access to the encrypted drive.

Compared to a scenario in which TOTP is not used, the one described here
has one, albeit small, advantage -- if the user is fully confident that
nobody has _ever_ had the chance of snooping on their LUKS key file
passphrase, they can simply stop using the existing key file and
provision a brand new one.

I am not sure whether leveraging the TPM's existing monotonic counter
can avoid the problem, since there seems to be no TPM facility to unseal
a blob if and only if a counter value sealed along with it matches the
TPM's internal counter value _and_ unconditionally increment the counter
should unsealing succeed -- this would (unless I made a mistake
somewhere) fully prevent key file replay attacks and force the attacker
to use the captured AEM media contents _immediately_, before the user
notices and artificially increments the TPM counter (rendering the
captured data useless) or simply performs a normal AEM boot (even if
unaware of the ongoing attack).

Such feature probably could be implemented in software, since it's code
would affect a PCR and thus the sealing key. Hmm...


Cheers,
Patrik

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Patrik Hagara:

Oh, I was originally talking about a theoretical setup where SRK
sealing _is_ the only "encryption", with nothing host-side like scrypt
before or afterwards. Where there would be no extra keyfile passphrase
whatsoever. It's a terrible idea...

But yes, a different theoretical seal-then-encrypt setup would not be
vulnerable to an evil maid attack per se, and indeed the SRK password
would be irrelevant (and a nuisance) then, as you say.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZOnoSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfLe8P/0uCwnDRrtDaGfQdwwT9JWxM
W6kUrlhnC8w/+QtOdb3uEtJ4dUfFGfG32LVyEm4fjDmhHh0SJOCi813wZ6EcFmwT
ttVU65gpnsnU9jNaAhZFioYH0c+0ceU2pqQVtLT6lhH4V1p1qRXLtBsjs4QReZE5
aLCMqxzFwFlpU9jBx9BDrwzta+Mcwy+mI5OLpEzsk3MTXySu7vnknxjMDg2IKWRR
a0ukidsRKqHFFYJerxrRXv9/yqsmJh4WIoo7kgFMOBkiimNlE1nvbWUGPAyqXdnw
pkVLi6WtQrqlB98gtsOCusaipuMwYdE2wr9FJ30X+4S+nQR9uSydP/gPvUsbLq6I
hhYB6Lnb5OJ0+xpFrwzxo3URaSVvITsgChsbOXDgCAxbuNalOs/ejr7BZs9yo5IB
n32MERB88QZm6f+wVN2ZWztN18yrftxWqTWT/EaZFCgahQSkehkeqSqOKsQR/vWr
OcUVor56/+1g4EwkJzgkldTCrke/Sxhtke67dMcazGVwy5qFfuHKf0MvjVyBoTbm
n4IKX6lvNw14wSbWVbPV4nDN5RQ3+eUQxI2mlcqrDMVOnad0LlxXyM8TFt3n8PMB
ZfVqlZDd6poGIr1TMVqtCsAXMVAgzY6hWDPEvWWjl1KspoiNzqVEjUbExPy3VHg6
eFXFEEgKlQS/BUtJpyjO
=Gk6N
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rusty Bird:

Just to really be clear, my error was to think of the SRK passphrase
as a passphrase needed specifically to unseal the keyfile, when in
reality it is a passphrase common to first unsealing the TOTP secret
and then the keyfile.

Eek, I'll stop bumping the thread now.

> But yes, a different theoretical seal-then-encrypt setup would not be
> vulnerable to an evil maid attack per se, and indeed the SRK password
> would be irrelevant (and a nuisance) then, as you say.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZOoucXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfSB4QAIZQFutZ8TK9o3A704uqOsQm
YkRirmbgWfq6ToN+sRM8wEPWC7VJNvlqYQkFluKddSCpkZ8xqS2nd82lHlvubI9h
qymdVJJvX72oEyaJDx3GDbxNST3FziHRrtxiOHd4CsZH1Xj+bW0VDKuCxA/QzE3i
mlzRxzJRgsntYip2bPX3JNIRc1vxHVCtJuHP4qIqljlvIBfhm5i3yiovCAVLwEJT
j+mtJXIA9GlV6XqKiOVGD3gwDZZtT6J9MzgvtJ5BAVO4p3Lt5GYaQccwJDwk0Uop
BAMgZyD88ydx/je57DZnsdkYJE5V166dFIORkwxDSw0ZXwrVfTQngbKmX4dWD4xQ
lV5n4q1f6hxe4MGLzOzZKxYfDS0HpnLrZTHZIvyydSbwI4Mmn15u2pMFdzeB7cUN
e50/wA2rvzpnA6fv/oCt3WWBOuH0MQ8QmzvnH55XrEVvzuyzQqc/wM+At6I5UxXv
a1ZfDXH+PEfjW8HKYprgvHgW1sK6RYJnt4gICpSBvj2mbSITHIdm1fMAFzwW1LLc
bFrrqH1IzH/Eu+bgpWh2dg3oETRHIcioqbd89aa/lJU28fm5JdY45t4JT39dznag
5SQNw3PhuW0buNFk6lY+slhLaaCpbxI/rO05YjRA1UiJURp49MF+ja9na8FENGjf
5EyUfgj0gKIKaN3Hz0Gj
=npak
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Patrik Hagara:

> Any and all code reviews are welcome! The changes I made are stored in
> my fork of AEM repository [1].

- - Please don't feel obligated to read this on a weekend :) -

One thing I noticed is that a comment in anti-evil-maid-unseal
mentions setting up /tmp/keyfile in /etc/crypttab. But adding the
kernel command line parameter "rd.luks.key=/tmp/keyfile" to
/etc/grub.d/19_linux_xen_tboot would have the advantage of working
even if dracut is in no-hostonly mode (e.g. on portable Qubes
installations), where /etc/crypttab is ignored.

There's a bug in systemd < 227, so to test this on R3.2 you'd either
have to patch [1] and rebuild systemd-cryptsetup-generator, or use
"rd.luks.key=YOUR-LUKS-UUID=/tmp/keyfile", which avoids the buggy code
path. But it won't be an issue on R4.0.

Rusty


1. https://github.com/systemd/systemd/commit/c802a7306bdc3e82378a87acd9402bbabe9f6b28
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZPDYoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfyOIP/3Olk10ev81PbGUpBnuCPZkE
wN14R+NDAahhukDMH4BAO0X9Po1AfQyyObP3tncZCIXt/rHfn40oqR/25r486TDV
pbe6lO2alDlvjCc19cmnlOefcJxJAfdTOdy/aOGlQLcaDhGbksD2rSro2AclefDa
irhY6p1cfxRhMvWj753ql7pGJHMlCpU4EFe6HT0JLYAAz6X447KuZbwOvZkp7laB
0gfAHGJXrUCcziTIAbivYUl84TNW7HOjPQmt5/MXrR/aTHycKSUgil6kvJhxM3+a
mhcABVKO5Bjs0tYLsv+bC6r/dOr0ECvOV7PC/0C51m9gA9mGeItff73UIoRxmVw/
1LyZE+zwrOR2yKHih6C4iUzsLJ+hvUOQi1QW6nGnyhKTrMXUEqIyLO+akN4ABVJY
BcX4c1cXxba/4RDFy3og0/ZhaWfpSsFGx4jSAY3AKjQYF7x70CJAwGvSXJmMGMG4
eJO9dmvZc4PHqiC/mdZOSUJA2cqOv5VPJk6bfHj4EbFhe+mWOZjb5SJCkF0X6To1
OEAnb7Zl99dRkiTnNtZKQlycEl+pOt4r8uSh9ndOTK+jlRiCZsnRFZSd8AQfcbL9
Gv+Rjfh3Z4behFUgXJjPc9Fr4fQLwLEA034RSbW3fzhLpBC8WTqAL9PRKvvhoLN1
AXIJAmRzzgISwtLl702Z
=9qf/
-----END PGP SIGNATURE-----

[Patrik Hagara]

On 06/10/2017 08:10 PM, Rusty Bird wrote:
> Patrik Hagara:
>> Any and all code reviews are welcome! The changes I made are stored in
>> my fork of AEM repository [1].
>
> - Please don't feel obligated to read this on a weekend :) -

:)

> One thing I noticed is that a comment in anti-evil-maid-unseal
> mentions setting up /tmp/keyfile in /etc/crypttab. But adding the
> kernel command line parameter "rd.luks.key=/tmp/keyfile" to
> /etc/grub.d/19_linux_xen_tboot would have the advantage of working
> even if dracut is in no-hostonly mode (e.g. on portable Qubes
> installations), where /etc/crypttab is ignored.

Yes, this would be the better solution, thanks!


Cheers,
Patrik

[Patrik Hagara]

On 06/09/2017 10:19 AM, Patrik Hagara wrote:
> I am not sure whether leveraging the TPM's existing monotonic counter
> can avoid the problem, since there seems to be no TPM facility to unseal
> a blob if and only if a counter value sealed along with it matches the
> TPM's internal counter value _and_ unconditionally increment the counter
> should unsealing succeed -- this would (unless I made a mistake
> somewhere) fully prevent key file replay attacks and force the attacker
> to use the captured AEM media contents _immediately_, before the user
> notices and artificially increments the TPM counter (rendering the
> captured data useless) or simply performs a normal AEM boot (even if
> unaware of the ongoing attack).
>
> Such feature probably could be implemented in software, since it's code
> would affect a PCR and thus the sealing key. Hmm...

Unfortunately, it seems monotonic counters are designed to only be
manipulated (create/increment/destroy) by the OS and thus the TrouSerS
project chose not to provide any APIs to perform those operations. This
trousers-users mailing list thread [0] contains additional information
(details the limitations), posted by the late Hal Finney.

Given that information and the fact that Linux does not currently make
any use of the available TPM monotonic counter facility and neither does
it expose any TPM-backed virtual counters to the user-space, I've been
thinking whether it would be possible (and secure) to use TPM NVRAM
instead of a proper monotonic counter -- eg. allowing writes to the
NVRAM area (to increment the "counter") only if a correct authorization
key is provided (stored on the LUKS-encrypted root partition), but
otherwise being freely readable (protected only by the optional & in
this threat model useless SRK passphrase).

Qubes would increment the NVRAM "counter" on each successful AEM boot
(since it will know the correct authorization key) and push a new sealed
one-time LUKS key file (tied to the counter's new value) to the AEM stick.

The initramfs would, upon next boot, read both the sealed LUKS key file
(unsealing it, along with stored counter value) and the publicly
readable counter value from TPM -- and, assuming the values match,
continue booting. An attacker cannot circumvent this check -- changing
the code will result in different PCR hash and thus the key file failing
to unseal.

Old sealed key files are also of no use to the attacker, since every
successful OS boot will increment the counter and the attacker wouldn't
know the authorization key (since it's stored only on the encrypted
disk) -- replay attacks prevented.

Also, should the user notice that their AEM stick is missing and the
computer is powered on, the stick's contents can effectively be rendered
useless by manually triggering a counter increment operation (and
subsequently booting from a backup AEM stick, since the primary stick's
TOTP seed is now assumed compromised). Not sure whether anything can be
done in case the computer is off (other than not letting go of it until
the counter increment is performed using a backup AEM media).

However, being no cryptographer, I'm not confident whether the scheme
proposed above is secure or would actually work in practice (or is
possible at all).

As a side note, I've noticed that the tpm-luks [1] project (although
using TrustedGRUB) is able to preemptively recompute PCRs after kernel
upgrades (using yum/dnf post-transaction hook) and migrate the sealed
data over to the new PCR values. This, although apparently not providing
any additional security, would be a nice UX enhancement -- user does not
have to check/remember whether the kernel was upgraded ("AEM secret
failed to unseal? Oh, _maybe_ there was a dom0 kernel update...") -- the
computer will always*, unless compromised, unseal their AEM secrets.

* except when changes to grub/Xen/kernel/initramfs/LUKS header are made
manually, outside of package manager (but this can be fixed by manually
triggering the migration before reboot) or the CPU/TPM has been replaced


Cheers,
Patrik


[0] https://sourceforge.net/p/trousers/mailman/message/18737249/
[1] https://github.com/shpedoikal/tpm-luks

[Patrik Hagara]

On 06/13/2017 12:45 AM, Patrik Hagara wrote:
> Unfortunately, it seems monotonic counters are designed to only be
> manipulated (create/increment/destroy) by the OS and thus the TrouSerS
> project chose not to provide any APIs to perform those operations. This
> trousers-users mailing list thread [0] contains additional information
> (details the limitations), posted by the late Hal Finney.
>
> Given that information and the fact that Linux does not currently make
> any use of the available TPM monotonic counter facility and neither does
> it expose any TPM-backed virtual counters to the user-space, I've been
> thinking whether it would be possible (and secure) to use TPM NVRAM
> instead of a proper monotonic counter -- eg. allowing writes to the
> NVRAM area (to increment the "counter") only if a correct authorization
> key is provided (stored on the LUKS-encrypted root partition), but
> otherwise being freely readable (protected only by the optional & in
> this threat model useless SRK passphrase).

I found out that implementing a secure counter in NVRAM would require
having a TPM owner password set -- otherwise an attacker can simply
undefine and create a new NVRAM area with chosen counter value -- while
the owner password is currently assumed to be well-known (ie. "not
used") for dictionary attack lock reset and reading the TPM public
endorsement key.

This might not be an issue, since the TPM pubEK is used only by the
tpm_id script for creating per-TPM directory on AEM media; and the
dictionary attack lockdown requires multiple incorrect password entries
in a short period of time to trigger (at least for the particular TPM I
have available).

Still, an attacker with physical access could perform a full TPM reset
(without knowing the existing owner password, by using the "physical
presence" authorization) and then create a new counter in NVRAM with a
chosen value... And since we do not want to prompt the user for TPM
owner password during boot (risk of snooping) _and_ the attacker is
assumed to possess a full copy of the AEM stick _and_ knows all
passwords used during a typical MFA AEM boot, they can successfully
unseal, decrypt and use the LUKS key file. :(

However, I think an extra signing key can be generated inside the TPM
and used to sign the counter value (with the corresponding public key
stored on AEM stick _and_ measured into a PCR). This signing key should
then get wiped from the TPM if the attacker performs a reset.

I already have a PoC for the above (except the signing key pair for TPM
reset attack) with a world-readable 4-byte counter stored in NVRAM that
requires an authorization password for writes (this pw is stored on the
encrypted root partition, counter gets auto-incremented on each AEM boot
and key file re-generated). I will push those changes to my fork after
some cleanup and a re-test (most likely tomorrow). Should someone figure
out any other way to circumvent this, please let me know. :)


-- Patrik

[Patrik Hagara]

On 06/16/2017 09:32 PM, Patrik Hagara wrote:
> I will push those changes to my fork after
> some cleanup and a re-test (most likely tomorrow).

Single-use key file code committed [0] and I'm going to check whether
clearing the TPM invalidates PCR-sealed data or not. If it does, then
generating an extra signing key will not be needed.


-- Patrik


[0]
https://github.com/phagara/qubes-antievilmaid/commit/4b398390b5335222c6d6a9799df3230755fc8d4b

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Patrik Hagara:

> Single-use key file code committed

Whee, I finally get it... Seeing how it all fits together, it looks
really cool!

What do you think about making replay protection a self-contained
secret? If we'd change it from a counter (shared between the combined
counter+keyfile secret and NVRAM) to a per-boot random string stored
in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a
hash_ -- then AFAICT the attacker still wouldn't be able to malleate
the secret in any meaningful way, and:

- - secret.fresh.sealed (the first to be unsealed) could be used to
replay-protect all types of AEM secrets, not just keyfiles

- - If secret.fresh.sealed is in fact stale, the keyfile would never
have to be unsealed into memory, where it's susceptible to a cold
boot attack (probably even if the tmpfs file is shredded, due to
buffers)

- - It seems like this approach should simplify the implementation? No
concat/split code, fewer special cases (e.g. all AEM setups would
have the same always-reseal workflow)

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZRpsMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfwXMP/3e3eas+5uDtq98w5A+fwW+W
A56dVp/e1e8TqsumtHxlmo3rZ2IF6nfvFwjwcKAvQ200KTj0nBvBposXXM5GD2i0
hskpLzEkq2Dapbgnyqd9RWUiQ57ieOWg5qXJmS61q4q9njTgSbIhtnyxgFczqmAb
nwc6q/H2eAia4hE0A40aMKOby8T89l4VYo0Czipz8zEZqGtnRRI2yCyhDZLu+eR8
raV9kggH6g/oJjmr+jTnOx1SHUFSVieOns4RfzoaTxV0y86TPknc5QG80/IheP3d
AqvEUd6P4MYdngZoL7Txwh0VNE4WwK8qn64bPX27jEJIXZuWxn01P9rQee2dYAJZ
SD4JG5/NtYBCopFmZJ2zZ54PjfreO/SoUrlk6CB2ZKF/JLc91qi/2xsrYZIwSPCj
Bdr84aUhb3T5I9kBaLM6eX19CZeqFa2bzSfSa1IedS5lqUcGnJddn2zHn3PSjUBp
9g1AVEkF9fhHjPvdBHmHYiyKRMDLW7+FzdCSNNt2vocfGNJu4fyNdGl2AYanuUrk
BjhnP+lotYtAUzIwH+l+SX9HhxWF0uBT/7pjj7rFwvs6Ku4LvUXYDFDkEL1DB6ep
fDDxuCzSt2iaMNiWKOvTk0YVrotWeuFXi3TAvgKYgozJqPdjeUzOqZPzsWJTxS43
1FSOyp4hlxs8lxu4JIeC
=VnBP
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rusty Bird:

> Patrik Hagara:
> > Single-use key file code committed
>
> Whee, I finally get it... Seeing how it all fits together, it looks
> really cool!
>
> What do you think about making replay protection a self-contained
> secret? If we'd change it from a counter (shared between the combined
> counter+keyfile secret and NVRAM) to a per-boot random string stored
> in a separate secret.fresh[.sealed] file, and stored in NVRAM _as a
> hash_ -- then AFAICT the attacker still wouldn't be able to malleate
> the secret in any meaningful way, and:
>
> - secret.fresh.sealed (the first to be unsealed) could be used to
> replay-protect all types of AEM secrets, not just keyfiles
>
> - If secret.fresh.sealed is in fact stale, the keyfile would never
> have to be unsealed into memory, where it's susceptible to a cold
> boot attack (probably even if the tmpfs file is shredded, due to
> buffers)
>
> - It seems like this approach should simplify the implementation? No
> concat/split code, fewer special cases (e.g. all AEM setups would
> have the same always-reseal workflow)

Hmm, replay protection would be incompatible with the use case in
which a backup AEM stick is stashed away somewhere. So it probably
shouldn't be enabled in non-MFA setups after all, or at least not
unconditionally.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZRqF6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrflCQP/i4NBM8yXNzZ9jLrMxpbwiUz
nw3zWkm/NrjTEE6lWob7dFS8CN8lMkapt3x7fx90uky0XGcsNVSfghxcF+yjaOuo
Ni9wuvkfCAYDfrcTaUHZV2M21sHlxIM+dagmZqMPFlJt9LTu6Ju0P+nExQvZ7C0w
ZM7h2MFX7X89g+ESo5j/ZQQwghXh9NTOjpxC4UUTfsWwyCLROmrvmbvpWBwUa7m3
nWAfFL1qUnIENtrlHvq/fKmkIVpVRHmU8Gbhy1u5wH23aTAk5XqGBriw2HM7WdML
oS37e15uymf4TxqSl9Ehwc9gHdLHrWVaEgImrIc1buEQZppSl3iQy98YGP3FfpWQ
qEwrURqHc45r4gfz2VwRo6XTJ18tgL7dGr+JfQJIY3pwQO4SSdL9ZPSPIITdlR9C
zoe33FCqdg1HlcW+PLAVV8MV3KKaSilxI1wGRinhYKQUpKvnOnmUQRjMBZNY2o+9
xqFsLIfglhUzE4u9noE1IREudWSB+hBaFRncAdg7SgZOvV9oEJsVYA+rVdF9reBA
1oUo37qShLMfD9Cilos/hgvO5hJ+41VND3GFyhrhoQ6b/25PmnhVIEAWXLtPWj7V
mdaHVqYaHK/p/eDfeHCiPBHMAGrFk+97cnD2wW+Ds7vQGufvxDbiK73zSFK+sMCq
VyqfZcTnHUygcP26Dm+U
=rDb3
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Patrik Hagara:

> The initramfs would, upon next boot, read both the sealed LUKS key file
> (unsealing it, along with stored counter value) and the publicly
> readable counter value from TPM -- and, assuming the values match,
> continue booting. An attacker cannot circumvent this check -- changing
> the code will result in different PCR hash and thus the key file failing
> to unseal.

One possible attack would be to patch out this check in memory as soon
as the kernel has started up, i.e. after SINIT has already measured the
initramfs, using DMA from a malicious PCI (ExpressCard, Thunderbolt)
device. Similar to TRESOR-HUNT [1], in spirit.

But I don't think this invalidates your implementation, which at least
requires the attacker to have such a device at hand.

Rusty


1. http://old.iseclab.org/papers/acsac2012dma.pdf
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZRtO+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfJgYP/3KQ3OkTteHGTqMX7Rj7NLhI
8P6s6xHSXOkd2jTK9Ss4bT3aCSsoYPUcOXrUSRf/wYhPCuIqP9OXCpOxyzC2V567
VnTzjCEEt27W/F43skNRygRVIIfkw7OBFNpHPgj9HkeaDprM4csI3mQ0wElIMx7Y
cL+f0ymSFTJCL5G4/sfhzixVmL+yjDbZYjDoIaiI8no563t6DVvz2UdjpF5vEpX2
gyj1InqTJ0aiHrGPDTGnVQbZ5SbIFCcAW5gIL50cW7RVbw3xHGo5lgR3hHtx0hn/
6fvhrFCJIxhJCba1NmDQ5uz6Ybjr1AU2Dx4fr+SQ/TKtkSCaZ1cu6vpg+mCjJxQb
v8ZLRsQDkcE8k9diLCXyQcXVkLBKdX+xJMnem0+y2VEdgd86lr8HK45uptrtwsWe
aepeyHZlbem4qBZA4pzIdAwHPfbZzH3oQCcGRkdspBpS7Ls2BMUf38HJklM+MVPO
fMFVUM2peEpmpzsdumJcS3RlF/VpQT5fzZwbPxhQMRmJnJyvfRvh+9BqRDRus0SC
Lifp8k3ldhzh3U+VWcRH5N64wDUaEIpBwbrj+SNuHwVYWggsY1aDFNIwdyFCCJne
fbc+ovHRKSrzC2xcWVsXtDQnxieHqX9oXWd7BGh/CfUcddXcHQ/L2o5qi4FTnX5p
qfkOdzlliBvDp0UPVQQg
=wHwZ
-----END PGP SIGNATURE-----

[Patrik Hagara]

Anti-replay secrets could be compatible even with backup AEM sticks,
just by having separate secrets for each AEM device. However, always
resealing would not work for read-only media.

For cold boot attacks, a good solution would be to encrypt the whole
memory using eg. TRESOR (storing encryption key in CPU debug registers),
with no perceptible performance penalty on Qubes 4.0 compatible CPUs, as
most/all Intel processors with VT-d also have AES-NI. Not sure whether
encrypting RAM from Linux would be enough or whether we would need to
implement the encryption in earlier boot stage (tboot or Xen).

I guess your last point is valid, we can seal the actual secrets
(txt/png/keyfile) just once and always reseal only the "freshness"
token. I'll have to think more about this, but so far I didn't find any
obvious flaw with this approach.

As for the DMA attack mentioned in your later e-mail, shouldn't the
IOMMU (which is required for Qubes 4.0) automatically protect against
that (as it gets activated by Xen)?


Cheers,
Patrik

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Patrik Hagara:

Oh, right! NVRAM has enough space.

> However, always resealing would not work for read-only media.

And read-only media could theoretically become more attractive in R4, if
hypervisor vulnerabilities (=> updates => resealing) are going to affect
Qubes less frequently.

OTOH, making replay protection _optional_ would complicate the code yet
again. For example, tagging a particular text secret as "don't display
if secret.fresh.sealed is missing", similar to the current counter +
keyfile concatenation.

:/

> For cold boot attacks, a good solution would be to encrypt the whole
> memory using eg. TRESOR (storing encryption key in CPU debug registers),
> with no perceptible performance penalty on Qubes 4.0 compatible CPUs, as
> most/all Intel processors with VT-d also have AES-NI. Not sure whether
> encrypting RAM from Linux would be enough or whether we would need to
> implement the encryption in earlier boot stage (tboot or Xen).

There's an old ticket [1] for TRESOR -- targeting disk encryption keys
only, but even that is "far in the future"...

> I guess your last point is valid, we can seal the actual secrets
> (txt/png/keyfile) just once and always reseal only the "freshness"
> token. I'll have to think more about this, but so far I didn't find any
> obvious flaw with this approach.
>
> As for the DMA attack mentioned in your later e-mail, shouldn't the
> IOMMU (which is required for Qubes 4.0) automatically protect against
> that (as it gets activated by Xen)?

I might totally have the wrong picture here, but can't the rogue PCI
device (which would not be assigned to any VM) access all of dom0's
memory? [2] Or are there more fine-grained restrictions?

Rusty


1. https://github.com/QubesOS/qubes-issues/issues/716
2. https://github.com/QubesOS/qubes-issues/issues/2454#issuecomment-262663371
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZR6rVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfffYP/j/ZVRZf74Gb6pYbo3pEfjK/
IxOtXgiIX0idGLH6sWCWY5YXFBbvKpHQgmT3I3O006f4H2myQWWEL94y6NlPpAon
usG81GPmSRLWDwgHoGSeMhZN1ZA2Ds6TAPuf7vE5iFKMnXJSirnOAKRxIOdGtpWC
+BtkfIEh/PvZN/ka7dnmn/GDck7asxLBTaCPWutdr5MOrP/P+GoXO6u8XRvyVC7B
+pVSFI1+ndPYof0vmS5iSH+FIfb2X/bvcU/j7stoabagUrVkhetjtpTNGdVojW1l
20RwFWcldjFvhcwmLxiZ3UagWdWYikK983NWnqUeNyHnCLKxdm2h5sZAoXfM6Bsv
Vm6cbeMMM2stbVx79Ji0NuCIyiq7zQ7e5Z966dpOkHiI414shPW2jHnXIxN/fm4h
iiRujNccfsMpZdAVPNswJfCBk8dbLISZYnJDwfGPBXrJKuFUgqbZKX6dutjJWvAo
uUORC0VARPlxcZk7PhxdKblrV6E4IRsMSNiPbBCK2suIlfomSiVTnq2HL9hIcGGO
jQXI/cTc+QQsDve1uWt+doxOftcbqsLqttUpRPqnYd2lMTj8h2R+gqFdwWcjNMfP
O1TMpbIpFTtHeVc1fueRtt3scKPaIvym5SdZh1S17RcdLMuuwfl/VKmxE8ki679Y
BEjDL1owE4dj88LH2cSY
=JWUA
-----END PGP SIGNATURE-----

[Patrik Hagara]

I've read some more about Intel TXT and tboot... and it seems that cold
boot attacks could be ruled out as any abrupt shutdown will trigger a
secure RAM scrub (via BIOS ACM, a different thing from the SINIT ACM
module). However, I'm not 100% sure whether whole RAM gets wiped or just
the TXT-related bits -- couldn't find that explicitly stated in neither
TXT nor tboot docs. :-\

And since the BIOS ACM is a binary blob, the only way to find out will
be to actually perform a cold boot attack...

>> I guess your last point is valid, we can seal the actual secrets
>> (txt/png/keyfile) just once and always reseal only the "freshness"
>> token. I'll have to think more about this, but so far I didn't find any
>> obvious flaw with this approach.
>
>> As for the DMA attack mentioned in your later e-mail, shouldn't the
>> IOMMU (which is required for Qubes 4.0) automatically protect against
>> that (as it gets activated by Xen)?
>
> I might totally have the wrong picture here, but can't the rogue PCI
> device (which would not be assigned to any VM) access all of dom0's
> memory? [2] Or are there more fine-grained restrictions?

You're probably right. In which case, encrypting the whole (not just
dom0) RAM would most likely be the only option.

Considering the ability of DMA to modify memory, unsealing the
"freshness" token before the actual secrets would not provide any
meaningful security and the resulting AEM code would be pretty similar
in size anyway. :(


One significant issue I've encountered this week is that the TPM
dictionary attack lock actually triggers after a few reboots (due to
tpm_id and tpm_resetdalock calls with well-known owner secret)... This
can be solved by storing the owner password on the encrypted root
partition and calling tpm_resetdalock with that on each MFA AEM boot.
However, the tpm_resetdalock binary does not support passing the owner
password via STDIN or CLI argument -- I'll have to write my own utility
just for that (adding it to the tpm-extra package) or get upstream to
fix that (as some other binaries in tpm-tools package support that).
What are your thoughts on this? The alternative would be for the user to
remember to run tpm_resetdalock (manually entering owner pw) before each
reboot or every-so-often (the actual threshold for DA lockout is
manufacturer-specific).

Other than that, I've only made some small fixes and improvements to the
code. Mostly stuff I noticed during my testing (I'm starting to hate
rebooting, heh).


Cheers,
Patrik

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Patrik,

Yes, it would be interesting to test this on e.g. a popular ThinkPad
with 16 GB RAM. There are some bootable memory scrapers [1] if anyone
doesn't know what to do with all their liquid nitrogen...

> >> I guess your last point is valid, we can seal the actual secrets
> >> (txt/png/keyfile) just once and always reseal only the "freshness"
> >> token. I'll have to think more about this, but so far I didn't find any
> >> obvious flaw with this approach.
> >
> >> As for the DMA attack mentioned in your later e-mail, shouldn't the
> >> IOMMU (which is required for Qubes 4.0) automatically protect against
> >> that (as it gets activated by Xen)?
> >
> > I might totally have the wrong picture here, but can't the rogue PCI
> > device (which would not be assigned to any VM) access all of dom0's
> > memory? [2] Or are there more fine-grained restrictions?
>
> You're probably right. In which case, encrypting the whole (not just
> dom0) RAM would most likely be the only option.
>
> Considering the ability of DMA to modify memory, unsealing the
> "freshness" token before the actual secrets would not provide any
> meaningful security and the resulting AEM code would be pretty similar
> in size anyway. :(

Reading memory (with a DMA attack, a cold boot attack on transplanted
RAM modules, or a cold boot attack in the same system if SCLEAN really
doesn't wipe all memory) still seems like it could sometimes be more
straightforward than writing memory (with a DMA attack). And it's kind
of neat to be able to protect text secrets, in the absence of these
memory attacks.

I don't know. But we can always revisit the whole separate freshness
secret thing later. Maybe somebody will weigh in on read-only media
support in the meantime?

> One significant issue I've encountered this week is that the TPM
> dictionary attack lock actually triggers after a few reboots (due to
> tpm_id and tpm_resetdalock calls with well-known owner secret)...

Would removing the 'tpm_resetdalock -z' calls in -unseal and tpm_z_srk
improve the situation? Looks like it's counter-productive in setups
with an owner password.

Also, -seal could avoid the tpm_z_srk call if $CACHE_DIR exists, and
in this case set $Z based on whether $SRK_PASSWORD_CACHE exists.

> One significant issue I've encountered this week is that the TPM
> dictionary attack lock actually triggers after a few reboots (due to
> tpm_id and tpm_resetdalock calls with well-known owner secret)... This
> can be solved by storing the owner password on the encrypted root
> partition and calling tpm_resetdalock with that on each MFA AEM boot.
> However, the tpm_resetdalock binary does not support passing the owner
> password via STDIN or CLI argument -- I'll have to write my own utility
> just for that (adding it to the tpm-extra package) or get upstream to
> fix that (as some other binaries in tpm-tools package support that).
> What are your thoughts on this? The alternative would be for the user to
> remember to run tpm_resetdalock (manually entering owner pw) before each
> reboot or every-so-often (the actual threshold for DA lockout is
> manufacturer-specific).

If it turns out to be necessary, TPM utilities can read from stdin --
but only when /dev/tty is inaccessible (like in a systemd context):

# mv /dev/tty{,.bak}; echo password | tpm_whatever; mv /dev/tty{.bak,}

> Other than that, I've only made some small fixes and improvements to
> the code. Mostly stuff I noticed during my testing (I'm starting to
> hate rebooting, heh).

Don't worry, at some point that hatred will turn into a very relaxing
despair.

Rusty


1. https://citp.princeton.edu/research/memory/code/
(https://web.archive.org has archived the tarballs etc.)
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZUSgvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfG4IQAJUfw6EFEApg4+1YqEqlp5r3
YnGcs3utH+z2LdKmJMeY5BGieQAhTzQpjR4Wq8glE4q3bxTS7jI3j481TWWTMbX3
oBIoKTSv98k/2wxwc+ytcPymghZnc8VtLnyIzz9SUjiOsK+zl4ZiVXABb+2ZlUO2
eXl8sO6/fGDUrL3t7MWLH9rCSPpYHu19QhGzo6+iY/EbrBSIyG16OSymUwo5/eEO
PYqr9PkPTMoslNfMbJzGBYTE4/GG1FbZ5Gv2COO6iaDnDLb5qmhf91aWrRhOWIe9
VDxRSG4ykOdU6n/w7omD4V5gAyiI5+MOAPzuwlvPZhWn4gbftQXKSpQBZAq8bF7r
Pv+pknirzqLLNH23lsOxr54Uy1uDvDIJ43r2EIKhxKtEKlBhSLlLV8gUEnYHlO4k
t3G6G68mXKqqrCiRJqmOR+ZXehF/3Nra+EqzmmKya2aArtEAu6h3OJhyeTCREmkJ
ex5naHNsKZ7hvjZmKfA7XiTaUZeUnJ0+X62S72EwrI6PjCaX7JhhY55YulxUlWXr
hS53QFp98pinLR4o88wTNymJJyt+j3b+FQOc5S+8KiXfch0up0vNZ/5fyTXTceu+
VeNd3oefXtL+TkwdACbIj912qpQKBMs/uJSEz1TvdebGzm9QxDZRLA/j9z0kMfWY
vIR3EAUy+0N4UGLcilTb
=sHGZ
-----END PGP SIGNATURE-----

[Andrew Morgan]

I have a Thinkpad T540p with 16GB of RAM. Let me know if you need any
testing done :)

[Andrew Morgan]

(For some reason your reply doesn't show up in mailing list, so replying
with it quoted below)

On 06/27/2017 02:38 PM, Rusty Bird wrote:> Andrew Morgan:
>> On 06/26/2017 08:28 AM, Rusty Bird wrote:
>>> Hi Patrik,
>>>

>>>> I've read some more about Intel TXT and tboot... and it seems that cold
>>>> boot attacks could be ruled out as any abrupt shutdown will trigger a
>>>> secure RAM scrub (via BIOS ACM, a different thing from the SINIT ACM
>>>> module). However, I'm not 100% sure whether whole RAM gets wiped or
just
>>>> the TXT-related bits -- couldn't find that explicitly stated in neither
>>>> TXT nor tboot docs. :-\
>>>>
>>>> And since the BIOS ACM is a binary blob, the only way to find out will
>>>> be to actually perform a cold boot attack...
>>>
>>> Yes, it would be interesting to test this on e.g. a popular ThinkPad
>>> with 16 GB RAM. There are some bootable memory scrapers [1] if anyone
>>> doesn't know what to do with all their liquid nitrogen...
>

>> I have a Thinkpad T540p with 16GB of RAM. Let me know if you need any
>> testing done :)
>

> Whoa, really? That would be cool! No pun inte-- oh, who am I kidding.
>
> On video, it looks like the T540p has one RAM module sort of on top of
> another, covering half of the lower module. Do you think there's still
> enough vertical space between them to cool down the whole lower
> module? If not, could it fracture from thermal stress? (And how
> annoyed would you be if "something like that" happened...)
>
> Rusty
>

Heh, I need to stop replying to emails in the wee hours of the
morning... Thought you just needed a script tested or whatnot.

That being said, while it is my main work laptop, t if all that happened
was the RAM cracked it wouldn't be too expensive to replace. Anything
else would be bad though, since I'm doing my own GSoC project on here :P

What may be tricky is what to do after the DRAM contents have
been frozen. Does one just plug it in to a running Desktop system and
execute some software to scan the contents?

Laptop RAM wouldn't fit in a normal desktop, so I'd need to get an
adapter or use another compatible laptop (may have one).

This article states that cold boot attacks against DDR3 systems are
much less feasible than DDR1/2. Would it even work if we tried?

https://darkwebnews.com/security-guide/cold-boot-attacks-unencrypted-ram
-extraction/

Open to ideas :)

Andrew Morgan

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Andrew Morgan:

> On 06/26/2017 08:28 AM, Rusty Bird wrote:
> > Hi Patrik,
> >

> >> I've read some more about Intel TXT and tboot... and it seems that cold
> >> boot attacks could be ruled out as any abrupt shutdown will trigger a
> >> secure RAM scrub (via BIOS ACM, a different thing from the SINIT ACM
> >> module). However, I'm not 100% sure whether whole RAM gets wiped or just
> >> the TXT-related bits -- couldn't find that explicitly stated in neither
> >> TXT nor tboot docs. :-\
> >>
> >> And since the BIOS ACM is a binary blob, the only way to find out will
> >> be to actually perform a cold boot attack...
> >
> > Yes, it would be interesting to test this on e.g. a popular ThinkPad
> > with 16 GB RAM. There are some bootable memory scrapers [1] if anyone
> > doesn't know what to do with all their liquid nitrogen...
>
> I have a Thinkpad T540p with 16GB of RAM. Let me know if you need any
> testing done :)

Whoa, really? That would be cool! No pun inte-- oh, who am I kidding.

On video, it looks like the T540p has one RAM module sort of on top of
another, covering half of the lower module. Do you think there's still
enough vertical space between them to cool down the whole lower
module? If not, could it fracture from thermal stress? (And how
annoyed would you be if "something like that" happened...)

Rusty

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZUtBzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfgNcP/1dqZSSqO1Ov/39Yyy75bCUD
ZJ/9xDzSmhF2YZ8K+ZiXs8Ny2Q7Q3/zFXwlcBYwQkG/Z5gmYDFckmYqLtAeioGy4
iel3ipn/TXNQIEjvxu7wZVa3OjYliSqCt5r5+nXj/haZoNxGk6l3j/bGjp7JBQib
sVjifT0QLi91DfJkSnbTn52OYjKIzvWHYwChJHM/9BksAqRetFILHSuBzwwevP5j
+n6EjvkRDBQSmGkeu6GqXY14QroWEsBKnnSvbX1hnKM3CEiZ9tR/eN3zaHNP8Ltt
IX7nPtHlMHgxT/Vj+29p5u4JqwbRld4QNhB2tNUH82jSkxWggT67/CKr/MDwPZPI
FBLA2REI+Uirc5y+X4fIBQpJyKjLRJRwZAEDIJULi/c8RH4SuBnVbhV8Jpqz+Tjx
dF7uFiD0lTXkMTT6mRDNA8KGgiZf28MdEEmoSWLqUW6kARigqcShy05TPdjTL8N9
E3VDjQSNotMt389HLMB8oTr90fasaOP/+wKTRcdjUpIPMREMDPEelMvoRAYMMT8j
9+wNnFtL9ewhj1LarWf5250W8da5jEgC6LdZzPBWFTjqjJBejwRmDVyA0Ty8aSDD
MU3QuWqAvqcggdHC+jcaB1ifjYvWfKoGSXDBZZhYNWZlIH7EXouQogUdfhEeqocf
GhvRO6G0X2+NwHNlPihX
=iroP
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Andrew Morgan:

> (For some reason your reply doesn't show up in mailing list, so replying
> with it quoted below)

Aaaaah what is the matter with Google Groups and my e-mail address.

> Heh, I need to stop replying to emails in the wee hours of the
> morning... Thought you just needed a script tested or whatnot.
>
> That being said, while it is my main work laptop, t if all that happened
> was the RAM cracked it wouldn't be too expensive to replace. Anything
> else would be bad though, since I'm doing my own GSoC project on here :P

I probably wouldn't try this with my main system. There could be other
issues, such as condensation.

> What may be tricky is what to do after the DRAM contents have
> been frozen. Does one just plug it in to a running Desktop system and
> execute some software to scan the contents?

For the SCLEAN test, it would all happen inside a single notebook:

1. Boot in AEM mode, without dom0_mem=max:4096
2. Turn off swap space and shut down all VMs
3. Run some small program in dom0 that allocates as much memory as
possible and fills it with a pattern
4. Cool down RAM modules, unplug disk, and power cycle
5. Boot memory scraper from another disk, and see if the pattern is
still present - if it is, SCLEAN has been ineffective

> This article states that cold boot attacks against DDR3 systems are
> much less feasible than DDR1/2. Would it even work if we tried?
>
> https://darkwebnews.com/security-guide/cold-boot-attacks-unencrypted-ram
> -extraction/

With t=0 seconds between power off and power on (what they call "warm
reset" in the quoted paper [1]), they say it worked even with DDR3
RAM. But it's good to know that transplanting DDR3 RAM turned out to
be pointless! Thanks for the link.

Rusty


1. https://www1.cs.fau.de/filepool/projects/coldboot/fares_coldboot.pdf
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZVAEBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfaGQP/3sZguIoGBYlV0XklUvd2VYM
po6okxWjvmAh35d/TRFvkIkKVLmCmq62+kZ2HQDhjebuQm4se+9TJDphyhUHecDx
IVjIZei68F+ln9ziTBPz4ctymTmDZjdEO9NFeKv/ZQqgmOZvr2JNN+wKJKz/T57b
vnvLyp2ubb+oXQ+wJ3NcGudnhjQqbDYsgQmWCkXmUcMsI3BT/4KHNB1SDgpvmDBk
8ic6/ViyrZXqsJSZf7qZOT2dZ+5OcBSZgYp6MKRRsCo3vJOqKfSscr+f3QCdnU5I
HlBEgoWIkiSWLLOxcNYUvksUHy52kz3vr24TmYgK0G0ewblqKQeem/7PJCIZJ2M3
FZC0Q2E2Tzj7BLL4Rfdkyh+O/EDMiwI43Qr1was9bADQ/L2z8qMlsODafzb6pz+X
5KDf9gNJRjOGUV+r6I39PCz9TLO+zrBNUUJCVC8C8CL0fKHy06EPh0m9LXxehDt1
bwHR3vPFMj4+87MoWH+fWgqkogEM+VVoNTTaxOWM2jPF2EJ4bje7MxCfOdb2+qqM
7MBpBJVoQ7YRhVxtWGMOmJN3EkijajD3scEpaN9Li8mAh8PzFdvOTXFzXehOVUma
usvUzPf0nJmFkDL1q/K1tL5RyEgLvH/ypZPs65ArOJNDlBhBQI3wfucHDLMDWUNG
K6BZSGXO+IE1bkqcrVME
=bvnr
-----END PGP SIGNATURE-----

[Patrik Hagara]

OK, let's go with the freshness token then.

>> One significant issue I've encountered this week is that the TPM
>> dictionary attack lock actually triggers after a few reboots (due to
>> tpm_id and tpm_resetdalock calls with well-known owner secret)...
>
> Would removing the 'tpm_resetdalock -z' calls in -unseal and tpm_z_srk
> improve the situation? Looks like it's counter-productive in setups
> with an owner password.

There's also the tcsd_changer_identify scripts with call to tpm_id which
gets executed every time the tcsd service is starting (via ExecStartPre
tcsd.service unit drop-in). The tcsd_changer_migrate drop-in will also
call tcsd_changer_identify itself if not already migrated. That's one or
two tpm_id calls which contribute to dictionary attack lock. And I see
no way to get rid of this completely. :-\

<rant>
Anyway, why should having a non-zero owner password prevent you, a local
user, from reading the TPM's public endorsement key? TCG claims it's due
to anonymity concerns (as the pubEK uniquely identifies the TPM), but
the same can be done by querying (via /sys or whatever) the serial
number of any other HW component (mobo, HDD, battery, ...) or just the
specific HW configuration/topology (model numbers, which bus/port the
devices are connected to, etc.). It makes sense for remote attestation
(and the spec already has a Direct Anonymous Attestation protocol to
solve this) but not much for local usage.
</rant>

> Also, -seal could avoid the tpm_z_srk call if $CACHE_DIR exists, and
> in this case set $Z based on whether $SRK_PASSWORD_CACHE exists.

Yeah, I'd rather just call tpm_resetdalock here with a password read
from the (now unlocked) disk...

>> One significant issue I've encountered this week is that the TPM
>> dictionary attack lock actually triggers after a few reboots (due to
>> tpm_id and tpm_resetdalock calls with well-known owner secret)... This
>> can be solved by storing the owner password on the encrypted root
>> partition and calling tpm_resetdalock with that on each MFA AEM boot.
>> However, the tpm_resetdalock binary does not support passing the owner
>> password via STDIN or CLI argument -- I'll have to write my own utility
>> just for that (adding it to the tpm-extra package) or get upstream to
>> fix that (as some other binaries in tpm-tools package support that).
>> What are your thoughts on this? The alternative would be for the user to
>> remember to run tpm_resetdalock (manually entering owner pw) before each
>> reboot or every-so-often (the actual threshold for DA lockout is
>> manufacturer-specific).
>
> If it turns out to be necessary, TPM utilities can read from stdin --
> but only when /dev/tty is inaccessible (like in a systemd context):
>
> # mv /dev/tty{,.bak}; echo password | tpm_whatever; mv /dev/tty{.bak,}

That's... not nice.

Reading the TPM 1.2 spec again, I've noticed there's a way to delegate
owner's authority for execution of (a specific subset of) owner-only TPM
commands (ie. generate a new password that would only be usable for
resetting the DA lock and nothing else). While there's no tool for that
in tpm-tools package, it should not be that hard to write one using the
TSS API provided by TrouSerS. Additionally, this would get rid of the
/dev/tty issue and reduce the impact of potential password leak -- only
this limited password will be stored on (encrypted) disk, not the full
owner pw.

>> Other than that, I've only made some small fixes and improvements to
>> the code. Mostly stuff I noticed during my testing (I'm starting to
>> hate rebooting, heh).
>
> Don't worry, at some point that hatred will turn into a very relaxing
> despair.

I hope not. :)


Cheers,
Patrik

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Patrik!

I just noticed that qubes-devel seems to break your PGP/MIME
signatures. Inline PGP works better on Google Groups based mailing
lists. (The CCs have all been fine, of course.)

To avoid implementation complexity here: What do you think about
unconditionally requiring the freshness token in all AEM setups, and
(as a stretch goal) skipping the token _update_, both on the AEM
medium and in NVRAM, if the medium is read-only? IMO it's not crucial
to implement this read-only check in AEM 4.0.

Sounds good.

> > If it turns out to be necessary, TPM utilities can read from stdin --
> > but only when /dev/tty is inaccessible (like in a systemd context):
> >
> > # mv /dev/tty{,.bak}; echo password | tpm_whatever; mv /dev/tty{.bak,}
>
> That's... not nice.

I forgot to mention that this line is only for testing!

Inside of the anti-evil-maid-(un)seal.service systemd units, /dev/tty
is already inaccessible, so 'echo password | tpm_whatever' should
work. (When the anti-evil-maid-seal script is invoked manually, the
'echo password' input will be ignored and tpm_whatever will display
its own prompt.) See e.g. the tpm_sealdata commands in the (un)sealing
code.

> Reading the TPM 1.2 spec again, I've noticed there's a way to delegate
> owner's authority for execution of (a specific subset of) owner-only TPM
> commands (ie. generate a new password that would only be usable for
> resetting the DA lock and nothing else). While there's no tool for that
> in tpm-tools package, it should not be that hard to write one using the
> TSS API provided by TrouSerS. Additionally, this would get rid of the
> /dev/tty issue and reduce the impact of potential password leak -- only
> this limited password will be stored on (encrypted) disk, not the full
> owner pw.
>
> >> Other than that, I've only made some small fixes and improvements to
> >> the code. Mostly stuff I noticed during my testing (I'm starting to
> >> hate rebooting, heh).
> >
> > Don't worry, at some point that hatred will turn into a very relaxing
> > despair.
>
> I hope not. :)

Hmm on the bright side, the restart-a-thon is a pretty decent password
trainer.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZWsUSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf3rsQAJaJ9pSt/K/aIhx0eRQdyYCs
4DEaXV/BeCw65BZVwGOuPUVSLs6LK4eIYpbkK8rQwYxcK8l3SPBrp4MPQX1IzNrQ
APCmqkfS3OH4w5na0on29Hf4YPP+NHKDbCy94nnE+JfnpFLHuSnyEOdVF8JZfJgR
CTvZF6WuoTQk9/Y0FLb99+C1wvmi4i8734CezMhIooxnN5kZJEeFwr6itbdW5zor
BQdEf0pwMR1ZEPOd1NX2HtZt7KPpMLs7YyXlsoDjT6ziTINkDW2Ib+PzA8aWzZE5
yutVb6ruhfpIGmYSJuBvVGb6w3OhDgmFSqR+5A7KKAq4XbSbYBQAZOJP/1KHGFIo
3mfrPgaQZyxqY79X8abZzTO+aELPWOSDYFXbeSImAi2lvkIs65d5L4hD5fciuyqJ
frT7aSMJtzpS3beaKsKHP2CvNvFXfLA+tYIJ/FkmhtANNdw0+ILpvZTDiBR7UyTg
0ZB3WKCcbyvLHEE3NhRtSntKyGzONH7Kgqcd/iQEGXABWpPVXAI8aHv00yz1oDdi
D/Xj4OT/CFSs6Nt9BfP+ImpjC/CgYqFl7UTtDlUZpqjHbNCJOpIFGDQ4utgscIrl
6c2tAbUV1tY12JOr9Q/gVBfuwnpGk9JnQq+vmdA5mWLGqXhsdLgvfS/v7m78Y3Ky
/mpjzmKpg5ZlspBEx18/
=5ldV
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

On 07/04/2017 12:28 AM, Rusty Bird wrote:
> Hi Patrik!
>
> I just noticed that qubes-devel seems to break your PGP/MIME
> signatures. Inline PGP works better on Google Groups based mailing
> lists. (The CCs have all been fine, of course.)

Thanks for letting me know! Hopefully fixed now.

Hmm, that could work.

Oh, right! Somehow I missed this fact (/dev/tty inaccessible in
services). Still, the workflow outlined right below is IMO better
(perhaps as a stretch goal?).

>> Reading the TPM 1.2 spec again, I've noticed there's a way to
>> delegate owner's authority for execution of (a specific subset
>> of) owner-only TPM commands (ie. generate a new password that
>> would only be usable for resetting the DA lock and nothing else).
>> While there's no tool for that in tpm-tools package, it should
>> not be that hard to write one using the TSS API provided by
>> TrouSerS. Additionally, this would get rid of the /dev/tty issue
>> and reduce the impact of potential password leak -- only this
>> limited password will be stored on (encrypted) disk, not the
>> full owner pw.
>
>>>> Other than that, I've only made some small fixes and
>>>> improvements to the code. Mostly stuff I noticed during my
>>>> testing (I'm starting to hate rebooting, heh).
>>>
>>> Don't worry, at some point that hatred will turn into a very
>>> relaxing despair.
>
>> I hope not. :)
>
> Hmm on the bright side, the restart-a-thon is a pretty decent
> password trainer.

Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZW39dAAoJEFwecd8DH5rl7gAP/iyTUcrFWGgdentz0j2Pb4eh
kTYpJyOzihYeIxuGfwfNNcZrBAe8Oiq0NrpMg42aR6+86b5aT/kBEgY0aYeoiAPR
/Zj31qxbJtdmsO4gVXBdcIpNoOWYPxES0pjTaoJ1DnO5hdx6SDYD8MC+IKjqJglP
n71c7u91+sZvjF/y0FB4wyjv/mRqjZWDpdfVn1R4EHjyPKEmBG9jrDC9jIT9lka5
Fjz7iz7OXDj/c12hDgm/5ffUR3D9T6GhlZsM9OhsQGrHatm+DSc8o5FXAFitm8Vl
+7nQVSFcBtHlinBnD9TZi/rM+UhahdwG74CokUz5oc6sRPGLGsBqWPdz7ZrJUWtP
+Wu1kBhYSs6Vyw3qYdA5egfteE3hwxJenZXJhOM0ahWS+idpB5F4Z9xOcsMiE0xd
oyUC4En9GFxuTIILV7dyiymPqmUhNHkD3wLDIDcD7e3bG/hKeW/YmKoWDot2eNSu
DHBiIlFYQM+DM4w1W1jVpq2VoOcgW0iVmc93qrL0rG7czwvEl1d5OUCifkMl/ZPh
Ub+CizLiBdT1ej9Qsa9onIrFxhPUFVQ8KRn6N/ecBxEsZSH70VJv4jIlBiC2CuD5
xsCQUsCvzgNcuO7fR70DzyrseUFZxnntB12TJrWncaGTNEtPbfOJD069jz6vwSwZ
poiB3kKo+ds7M6Nejcoo
=aCT9
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Patrik Hagara:

> On 07/04/2017 12:28 AM, Rusty Bird wrote:
> > Hi Patrik!

> >> OK, let's go with the freshness token then.
> >
> > To avoid implementation complexity here: What do you think about
> > unconditionally requiring the freshness token in all AEM setups,
> > and (as a stretch goal) skipping the token _update_, both on the
> > AEM medium and in NVRAM, if the medium is read-only? IMO it's not
> > crucial to implement this read-only check in AEM 4.0.
>
> Hmm, that could work.

How should portable Qubes installations be handled? We can't save the
owner password in the initramfs. But I was thinking, the function to
write a 256 bit value to NVRAM (at index n) can be used to store not
only the hashed freshness tokens for every AEM device (at index 1, 2,
3, ...), but also a randomly generated TPM identifier (at index 0)
that could actually replace all the tpm_getpubek stuff in tpm_id.

> > Inside of the anti-evil-maid-(un)seal.service systemd units,
> > /dev/tty is already inaccessible, so 'echo password | tpm_whatever'
> > should work. (When the anti-evil-maid-seal script is invoked
> > manually, the 'echo password' input will be ignored and
> > tpm_whatever will display its own prompt.) See e.g. the
> > tpm_sealdata commands in the (un)sealing code.
>
> Oh, right! Somehow I missed this fact (/dev/tty inaccessible in
> services). Still, the workflow outlined right below is IMO better
> (perhaps as a stretch goal?).
>
> >> Reading the TPM 1.2 spec again, I've noticed there's a way to
> >> delegate owner's authority for execution of (a specific subset
> >> of) owner-only TPM commands (ie. generate a new password that
> >> would only be usable for resetting the DA lock and nothing else).
> >> While there's no tool for that in tpm-tools package, it should
> >> not be that hard to write one using the TSS API provided by
> >> TrouSerS. Additionally, this would get rid of the /dev/tty issue
> >> and reduce the impact of potential password leak -- only this
> >> limited password will be stored on (encrypted) disk, not the
> >> full owner pw.

Conceptually, it's cleaner for sure. But I don't know if that makes it
worth the extra C code. If an attacker can access the encrypted disk
contents, the TPM owner password would probably be low on the list of
things to worry about?

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZXQYGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfk08P/A2F7FlABf7JCjmHmIdYlpfj
KNglHY53bt9JVksWmpXCqkeGjH2KVeqRtWAR9tbM9BeQktPDQCYY+PWv+oYSwSnT
8fYh4oHKlcc85adhHMYOFbfo7n4tqlTcsBdk4oFnlp1DDEZkKC+QwwPmIUfM+edz
uNvChVsU+V7nwgWBVgY7x1R08AcW/3pPXRUNF+MwjDyeXVCh0TxYI5zYJc5HLMiK
2kjQ8R1TFXriyVvJceC+9IVvJ5Kr/3KqshapCtUiGUG0KybM3RFPLvc5RXuG1aTO
hNhrfUs+VKTlrdD8TJAG2Amv0NTP6JGl+x2Evol2sT8/IwCJME6nJIBZfD+5AGm1
bffsApo8/2bxHTpwC8nP7vzT7WqNf1xvIktYzM+0vysdctKhuONoSbs+GYSZuQhp
6d51+fgZz1DX6sXrxsu9D+F6Qp7DFIZSiwzTdigIQ9cydyHNO2sD5iD0KR8Yl1Dn
7f+koFAgU4AOlNS0RBNXD3yHgx/Opr/WhTv3QQLkD88POzfJ9dIpWXo3GGgZ5qe7
AIZaw7tyLN4zTocXghx8ewbxTaE7CgqzceyCckjKcL/ajyEubq0a6LzwUlhVaL7u
VxmbQwMiPqaep18SSByhr3CFh/nfUg/4PaHbZDbgA7xQcHAPRRdPPbkGOjICY4Pe
D78wH8yzONOmH0k/HUyY
=VMqd
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

On 07/05/2017 05:30 PM, Rusty Bird wrote:
> Patrik Hagara:
>> On 07/04/2017 12:28 AM, Rusty Bird wrote:
>>> Hi Patrik!
>>>> OK, let's go with the freshness token then.
>>>
>>> To avoid implementation complexity here: What do you think
>>> about unconditionally requiring the freshness token in all AEM
>>> setups, and (as a stretch goal) skipping the token _update_,
>>> both on the AEM medium and in NVRAM, if the medium is
>>> read-only? IMO it's not crucial to implement this read-only
>>> check in AEM 4.0.
>
>> Hmm, that could work.
>
> How should portable Qubes installations be handled? We can't save
> the owner password in the initramfs. But I was thinking, the
> function to write a 256 bit value to NVRAM (at index n) can be used
> to store not only the hashed freshness tokens for every AEM device
> (at index 1, 2, 3, ...), but also a randomly generated TPM
> identifier (at index 0) that could actually replace all the
> tpm_getpubek stuff in tpm_id.

Assuming "portable Qubes installation" means sharing a storage media
containing installed Qubes OS between multiple machines -- we could
store a TPM (UU)ID to {owner,NVRAM} password mapping on the portable
encrypted root disk instead of a single password; plus per-machine
(per-TPM, rather) sealed AEM secrets (which in the current
implementation would get mixed up and overwrite each other if TPM has
owner password set up, but otherwise works already -- simply replacing
tpm_id with something not relying on pubEK will fix this, more below).

Neither the owner password nor the NVRAM area password are stored in
the initramfs, as that would be a security risk. They are stored only
on the encrypted root partition.

The TPM 1.2 spec mandates at least 512 bytes of NVRAM storage to be
available (actual storage is vendor-specific, no upper bound given).
Assuming 20 bytes per (sha1) hash that's only 25 values in the worst
case -- and this space is shared between all "applications", so Qubes
AEM should probably not take up all of it.

So far I've thought about storing a unique 20-byte value as a TPM
identifier (a randomly generated UUID hashed with sha1) and reserving
a few (say 2 or 4) 20-byte slots for freshness tokens, so that you
could have MFA-protected backup AEM stick(s). That's just 60-100
bytes. In principle similar to LUKS key slots stored in its header
(which has space for 8 keys).

What do you think?

Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZY5qsAAoJEFwecd8DH5rl6CUQAKuGo5KScXV11eXLJWVmHcf5
1ZO75U/Sx3nLnmbz4Crzr5ci0UpLMbIVnum+Aq82oou93la7NEX4EMhCaTQsILP3
tTVnPPw/hz8OSRptb1zV0RRFU243VvB5zmrVLvT8g/G0lfnTVmFhb448L/+WYB33
dw/V11e+JKfriG2ahnRRuK7yICXYsxz6TOiB7ZULbP0jMMB2b7W7VhC/5Pz51OzE
t0voS9K12NaRaARBjDA9f13XEkjzkbSA/LtA71PG3nzUpE+W8HUKFn6g800HnaE2
bWYf6O6lumRUyrqcHj425jpMu/vGlePH9FSiOTBm3BMuHjLPlHKOUkkVpukPMKUf
feXoVRX+aA2EmDLYFKac8myTz7hu6+k2UEP+zDH6B2RPTgHIe3xvANMi3ZL5cSf0
aLm9mwk/NtCoyibjtqZ3wDlmFGpVfYB/FqNiQNBN/x272OfAcNkInV9tFb7v173b
JYOp445v3/Oq8kvlc3Lrqhueqfv7o4AzFIuMWQsyYDvehiB4uVPbfInGAGWyoqgW
pLbMOo1pT0BJXaN+B9q9UwLmxZm7d1qJ7ZKuH1N/n71EIJ6qis+76V+2rppdPnhV
+7LVMK9pJQDSUw9isbIA5TSmq9WCcUqJLrtlY6zUC0kZqSQQY7pMxm8Mic4bIqqo
OlLYPgAXileuu7S0yp2j
=X/Y8
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Patrik!

> On 07/05/2017 05:30 PM, Rusty Bird wrote:
> > How should portable Qubes installations be handled? We can't save
> > the owner password in the initramfs. But I was thinking, the
> > function to write a 256 bit value to NVRAM (at index n) can be used
> > to store not only the hashed freshness tokens for every AEM device
> > (at index 1, 2, 3, ...), but also a randomly generated TPM
> > identifier (at index 0) that could actually replace all the
> > tpm_getpubek stuff in tpm_id.
>
> Assuming "portable Qubes installation" means sharing a storage media
> containing installed Qubes OS between multiple machines --

Yes, exactly that.

> we could
> store a TPM (UU)ID to {owner,NVRAM} password mapping on the portable
> encrypted root disk instead of a single password; plus per-machine
> (per-TPM, rather) sealed AEM secrets (which in the current
> implementation would get mixed up and overwrite each other if TPM has
> owner password set up, but otherwise works already -- simply replacing
> tpm_id with something not relying on pubEK will fix this, more below).
>
> Neither the owner password nor the NVRAM area password are stored in
> the initramfs, as that would be a security risk. They are stored only
> on the encrypted root partition.
>
> The TPM 1.2 spec mandates at least 512 bytes of NVRAM storage to be
> available

1280 bytes? [1]

> (actual storage is vendor-specific, no upper bound given).
> Assuming 20 bytes per (sha1) hash that's only 25 values in the worst
> case -- and this space is shared between all "applications", so Qubes
> AEM should probably not take up all of it.
>
> So far I've thought about storing a unique 20-byte value as a TPM
> identifier (a randomly generated UUID hashed with sha1)

Or just 'head -c 20 /dev/random' instead of 'uuidgen'.

> and reserving
> a few (say 2 or 4) 20-byte slots for freshness tokens, so that you
> could have MFA-protected backup AEM stick(s). That's just 60-100
> bytes. In principle similar to LUKS key slots stored in its header
> (which has space for 8 keys).
>
> What do you think?

You probably don't even have to define a maximum number of slots in
advance -- the TPM ID / AEM freshness tokens could start from some
constant NVRAM base address and (attempt to) go as high as needed. If
anyone really wants to manage a ridiculous number of AEM devices, why
not let them try. :)

Rusty


1. https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientTPMSpecification_1-20_1-00_FINAL.pdf
(bottom of page 14)
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZZMuaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfSNEP/jdYH7xcuf3TRxRyJGZuPRaV
Mkk+hHWBvTOlIatFUFZL987HexzSeZNR5QRk5xIUaCtwYVKEHb8/mI5ySPrUJCy5
LFeGGIRURFPsSePym+MwXXElcAzL1fTBbOEkkARtP2vyrfCt4w4OCHeDDF3MvheM
kWCOkZTHD+zzSqPzx+gs7lP80eYhXTNLZIMs/UcqRJA+aFmpxdf5KfcnoL9UjggE
iXBtPdL2gLu3S1M/h9CcHObpJusJ98GSmIQjSAcI44mLQdD5fONfDohpTVuXoG81
uYVdbZFDDCt26+ow2m+J+e1Qc/CsE7W42pRfEoD8We9I2wsGUya1fF8sGR8Nj89K
rAPuJeP+Os/THs+7yf3IsjeSJd8j9QX+4iZO6K5WVqosfakFu4Vk0rOlj6e2KoqM
8kWC251q06bT18+nZ9DwQuJ+Ua7gmX5AE6i9APWeTaOk6bFjp49fZO6TEhIlKv3y
EdJjqk4NTAR2LvmkECkWn0BZYWOPAE8hnIZwVJaf5r1US8O3zzOb7DE5G7MwizpW
ClxJAS82t3JFZLkgw3JuILROqhSe3QFXFY+CR1Q3jyIiX8lvaW5gk4lAICNrMWr6
LK9eA6E/9UQ4/J3bXimrtBhIyM7+hVdtTqLXZkyTSozkwh17kAf+PzE/5hen+SEr
IrhjZxQlOnRq7RpWGcKd
=MPqD
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

Hey!

First off, sorry for the delayed report this week! I was doing
"drawing board" work almost exclusively for the past ~three weeks
trying to wrap my head around all the outstanding issues and figuring
out some decent avenues for fixing them, so there was no code
committed and I felt like there was simply nothing "real" to report.
My mentor, Rusty, has encouraged me to write something up anyway, so
here goes. :)

First, there's the annoying problem of needing to (preferably
non-interactively) reset the TPM dictionary attack lock while having
an owner password set to not-well-known value. Although I've been able
to find a way of substantially reducing the number of "triggering" TPM
calls (by replacing tpm_id's tpm_getpubek call with a custom randomly
generated TPM ID stored in NVRAM), there still remain the incorrect
SRK password guesses while probing whether SRK password is set or not.

While the reduced amount of DA lock trips might work out just fine
under normal usage, the backup plan is to store TPM owner password on
the encrypted root partition and perform a DA lock reset after each
successful boot (eg. from the -seal script, which should now get
called every time due to the new "freshness tokens" discussed below).

Freshness tokens are the means of preventing an attacker who gains
access to a (copy of) AEM boot media _and_ who knows all the required
passwords but cannot gain access to the Qubes computer right away for
some reason. In such case, the user has a chance to either forcibly
invalidate the stolen AEM media and thus preventing attacker from
unlocking the encrypted computer (provided the user knows the AEM
media was stolen from them/copied); or, if they are not aware of the
fact that the attacker possesses a _copy of_ (since a missing primary
AEM stick would be pretty obvious) the particular AEM media they use
to boot Qubes on a regular basis, they can still (unknowingly) stop
the attacker in their tracks by simply rebooting often enough...

Another issue is the need of mapping particular AEM media to their
respective freshness token hash "slots" stored in the TPM NVRAM. I
decided to make this a simple AEM media label suffix to slot index
mapping, stored on the encrypted drive. This approach has the
advantage of easily replacing lost/destroyed AEM media (or perhaps
even read-only but outdated, but I haven't figured that one out yet)
- -- simply anti-evil-maid-install to a new media using the same label
and answer yes to the prompt warning you of the overwrite (the old
media will automagically become unusable).

As for storing the actual freshness token hashes in TPM NVRAM, for now
I'm planning to make it a fixed 8-slot memory area (much like LUKS key
slots) and addressing individual slots using offsets, since I've read
[1] that each NVRAM index definition wastes and extra 93 bytes of
overhead. Even Chrome OS decided to use just 2 NVRAM indices [2],
presumably due to the same reason (since you cannot set different
permissions for portions of a single index definition and they needed
that for the firmware/kernel spaces).

I've got most of the code written already, just need to finish the
- -unseal script bits and test it, then I'll push it to my fork --
should be in the following day or two, depending on how many bugs I
managed to write again.


Cheers,
Patrik


[1] (p. 37) https://www.cylab.cmu.edu/tiw/slides/challener-TPM.pdf
[2] https://www.chromium.org/developers/design-documents/tpm-usage

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZcAZRAAoJEFwecd8DH5rlY3UP/iKmN2zKmYyj4oIfHpbFTUGt
HmaEAtGU1PE1OrplB3bE9jTuY/8TvE3uQHMoCN4YaV//Oho79k8a3DtUWOitZwkR
bhUXyNjH2kFTX8Ckd+/pUvtNrzubj5Uj05TM1PG8KLIUjk0dgWmm11fk5LxektCq
d1KtGg5RrbStB/1/kcllm3SMVzQVhWXu4TgfMt/8HZ2xBqpuTarJQZNcRqfAIQHw
AONPtiQX8B15+V7brtJwRJE8WKrR+5NxDjtjaFEoTuM5g1AxLJ1aNj+cunYRR8LM
M3eZjVzPRFhbBMu+dvs8ML4seV4PdcWdmU/MkOhYJ6yc+WesliNPZXZ8Bkq4PZeQ
Kcfhl8/h+dMXeTzNUvWc7GJCl5tj1ycdJR1mxPbL8k1a7EsP9G+4n3XYpNYAg6XV
5XcenUNDngLUbf6mZWzk58j90DMBqns+DZrrOiVDmSoF2QW9WaiTdtxn5kPAbziL
jBAvXN3vvYgIlfB1dq6ZqYgoumHyGmY9dytMrde0En9eI7T4qbouuD8kg1Ve0UIP
3sOAzw//+ebumQdC8lGEA0OUjFI90d4bduqUdvo0EoFJ0OhYGAHySzZ3b7F/tXRB
UvuR9T/D/cOqluMbJ1Cqe7eVjdizhJbKo8sQsaUy8elkIBMAYVZED+UeqCsji1Tm
ecp6spib2RcvYcDtpZa1
=QM3b
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

On 07/20/2017 03:24 AM, Patrik Hagara wrote:
> I've got most of the code written already, just need to finish the

> -unseal script bits and test it, then I'll push it to my fork --
> should be in the following day or two, depending on how many bugs
> I managed to write again.

...or how many more hard-to-solve design issues I find.

Thinking about RO/RW AEM media gave me quite a headache. We want to
allow creating a RO AEM media that would ignore freshness tokens --
but then the attacker can trivially downgrade a seized media from RW
to RO and thus the freshness token hash in TPM NVRAM would never get
invalidated if the user doesn't notice (eg. attacker flipping the
switch on microSD to SD card adapter the user leaves in their laptop).

Extending a PCR with the media RO/RW status will prevent this
scenario, but also make it impossible for user to create a legit RO
AEM media by eg. flipping a physical RO/RW switch on an SD card or
copying an existing USB stick to a read-only CD... Unless there was a
way of sealing data to arbitrary PCR values regardless of the current
state -- and luckily, there is! Will need to write a custom tool for
that since tpm-tools' tpm_sealdata does not support sealing to other
than current PCR values.

And while we're at it, why not also extend the boot device label into
a PCR -- what if the attacker covertly changed the label and the user
then used this AEM media? There's risk of DoS attack by filling up the
NVRAM freshness token area, or worse, overwriting other AEM media's
freshness token hash (thus preventing it from being used).

Changes pushed, now to finally finish the unsealing script. Hopefully
I don't find any more issues.


Cheers,
Patrik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZdeXnAAoJEFwecd8DH5rl6R0P/2QkKp3H0edZYxnylJbqpr7C
5udtkIJgEJh+mLi4sbC8S1T24Sl9CVflK+H9a7UuTkGcV7AcM2YaPmpJzsBpqdp7
65F1MfhoDLtLQkXzg5AgBdNbIaLy1oTrinXCXOYRWoxuHqd2eHe5n0veW5iOvSjQ
2EBUJmv0/wKBYTRIH+nkAmIly1r759zSpJJi8tb0JtlwxARou45SJDYH3U//4jdi
TgclSxmx8HnJ5bGVH7dhOpShsSBKWWMLBMFRr/Acwi5rzpIpgVeAz3Wor3lXaJYo
veEbklhQnFDTQ2UYJ0FuuLdNLTATrgTOkaDb8GPLGPMbNAQdjqhGly5be/+WumPd
9lsftzJDygNpf2iyla6k+6/HeZVJ3ZeAu6aM5U8Sfawcoa0qBhMJmwP0YxZn5BV5
b2nlns9JSFMt/L6O2S0WrHnYDFQdE6bzmvNhUhS4BIbnnB5w/3BSHi5BKkB3ZEeR
4gb6SQ5ViElgiiFcjlFTEQ3MzaXTZ/ytCCunDCfOUTmXkEuZkBFz45bsKpdFklML
GbL5M2i+IrSvv0NS2f4inZn9N5W+fxY9/2852CwxRUPgPpFk3kdSSYQ2WJgm8WdU
TtEgOE+g8/eTCaxlDvv7O4UsHMgO3uYM8IfF+7dURhC4AbRLRSt59Baj615ELz6j
aL/BAfKgORG1+dqrAgzr
=aw1f
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Patrik!

> Thinking about RO/RW AEM media gave me quite a headache. We want to
> allow creating a RO AEM media that would ignore freshness tokens --
> but then the attacker can trivially downgrade a seized media from RW
> to RO and thus the freshness token hash in TPM NVRAM would never get
> invalidated if the user doesn't notice (eg. attacker flipping the
> switch on microSD to SD card adapter the user leaves in their laptop).
>
> Extending a PCR with the media RO/RW status will prevent this
> scenario, but also make it impossible for user to create a legit RO
> AEM media by eg. flipping a physical RO/RW switch on an SD card or
> copying an existing USB stick to a read-only CD... Unless there was a
> way of sealing data to arbitrary PCR values regardless of the current
> state -- and luckily, there is! Will need to write a custom tool for
> that since tpm-tools' tpm_sealdata does not support sealing to other
> than current PCR values.

I was wondering about RW->RO downgrades too (didn't realize you were
already working on this part...), and came up with the following
tweak: Currently, the unseal script will mount the device, do its
work, and unmount. But it could be rearranged to mount, copy the
sealed secrets to /tmp, immediately unmount, do its work, and at the
end, check if the user removed the device. If that's the case, the
unseal script can create a file in /run to skip -seal.service via
"ConditionPathExists=/run/...".

This would prevent the easy downgrade, and it seems pretty natural,
UX-wise, to remove the device early if you don't want to reseal.
Probably much less code, too?

> And while we're at it, why not also extend the boot device label into
> a PCR -- what if the attacker covertly changed the label and the user
> then used this AEM media? There's risk of DoS attack by filling up the
> NVRAM freshness token area, or worse, overwriting other AEM media's
> freshness token hash (thus preventing it from being used).

Booting from an attacker-modified AEM device is dangerous anyway, e.g.
there could be exploits against the ext4 filesystem driver.

But when extending a PCR with the label is only one or two lines of
code, why not indeed. :)

> Changes pushed

Thanks! I'll try them out later this week.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZdgbgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfKAEP/3wWtzWBPxtm9+dkHiW2For6
fcQ33sVCQkOY0r4UB0p8xFvvxLGfJBumXKw4Z6+vjv0Te4rqISKkc9WLqVFiU6Mb
PI1WSRMNH+KFnL6XVrFCy0+cuatuNB1txTtbelbzGvGYiprTAOgHFFylCh2pGpED
03hmTTHT89CN/B9/Tdu1zskvLXBZwO1k22ZfauFc8oV9qDeIJf+glz96wcKYekU+
pBag/J/SHtkEeFP5AI8qbz2F/MdhajPOPedYJgsIrcZko8pq5zgiiDMk445Hqr4v
GmExti5rOF9N+jDansPYvjROnerhabfxvwzOKFD776OjGEXaWkzqdOHrKE1JxgzM
sEXhxAbcTlySC/vw/6a8ta8MrfvfksFN+A7mW6djsI0QJ9Jt5uYBztNdaGbNjRrj
YGjhAby/N2NK3jlUcT7I/RNhh8TY5UpepdVvudT0+GN4M/cU9MH148wcI5Lua9b7
EgSsbdTV+uLiwULHItS20Mvm4/kSlPze7AGKQYqcVJKYUQ3ibwAFzNOzxGVrv0aM
3pWKurESTYSbA1XCpwtLW04p/p2Mr911REJuzoYtmVae6VWC4kI9lSduY5h/mb0e
tPnIsypc7TOcn8dbpnxq8Mn4TNXPRgnwGJ292L9Do1KIEKENgxKEREKJnxd2V4kz
jWSES6WQSAdu3kpQWOVR
=ACX1
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

Not sure about how natural it would feel... I'd say the best UX for
removal of AEM media would be to _wait_ for the user to decide, ie.
print a message and wait either until the device is removed or the
user decides not to do so via a key press (_not_ a timeout). Explicit
is better than implicit, as the Python saying goes.

>> And while we're at it, why not also extend the boot device label
>> into a PCR -- what if the attacker covertly changed the label and
>> the user then used this AEM media? There's risk of DoS attack by
>> filling up the NVRAM freshness token area, or worse, overwriting
>> other AEM media's freshness token hash (thus preventing it from
>> being used).
>
> Booting from an attacker-modified AEM device is dangerous anyway,
> e.g. there could be exploits against the ext4 filesystem driver.

Yes, but while the ext4 exploits are theoretical, the DoS I outlined
would be guaranteed to work.

> But when extending a PCR with the label is only one or two lines
> of code, why not indeed. :)
>
>> Changes pushed
>
> Thanks! I'll try them out later this week.

No rush, I'm still churning out small fixes.

After a code-prettifying pass though, I'd be interested in some code
review again. :)

Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZdjymAAoJEFwecd8DH5rlnfYQALvJ9KfaCAHc7CCmcouFtWgl
K5XLa3h83YL4GiH+JmV6YtxjsvwewpNwZadmSpx/pemAGIK8NVUyD4VH51twNs0D
0Kqamo9y0GVOonILzR2chXRu9woyZSxq/RQhsZb6sfDZxvs6cKFkPDrcFwC9KuRk
oWS/yHGEkFxUAqgLbMKcUa+ISCDcN9UEq9XEE8b5wOVB8V+QdCKseZonTjceVvec
C952TNBp45rWoygMIM+bDvLFcudsjFpNWteL31An2fWaOyNWNuWMgDZoJF2rqQKw
zBQK17JLGQaYZsBYzGXwIjTATzB6q333mL/t9qkLLf2tvsCEszDlhkTUwGHwLSZF
DS8nJe+kudIc3KUNBtgq3GzHys2FvY07P+NBDix9IYsTKLcdnxjEwR/A9OUAMcjc
0xUnN5KJoBpwe3ABwd/xp8wj37LxlVtpZTURxglbbQ/QBCzCwrtzFbrNS0JiNi5U
PQLIGoX9YLywD3bYyT9K5IL9ZNmbisAFzWyDwHShy+OoB3X1pwhXGJL0Xphqf5oc
IuDJglOTvXsPZEfhbrvHszcKBpEhJOTrmrEp+5j8EJIbqJ90UcH8b9btIbmBVBzp
dT7OWmQDu0ORkNRtbTwek9wr///+PIM/n13MdogmTv69Cxkvtwf5BVqld7Ox0Smz
mj8MKs4dkf/ffMRvYHWg
=09sQ
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Patrik Hagara:

> On 07/24/2017 04:40 PM, Rusty Bird wrote:
> > I was wondering about RW->RO downgrades too (didn't realize you
> > were already working on this part...), and came up with the
> > following tweak: Currently, the unseal script will mount the
> > device, do its work, and unmount. But it could be rearranged to
> > mount, copy the sealed secrets to /tmp, immediately unmount, do its
> > work, and at the end, check if the user removed the device. If
> > that's the case, the unseal script can create a file in /run to
> > skip -seal.service via "ConditionPathExists=/run/...".
> >
> > This would prevent the easy downgrade, and it seems pretty
> > natural, UX-wise, to remove the device early if you don't want to
> > reseal. Probably much less code, too?
>
> Not sure about how natural it would feel... I'd say the best UX for
> removal of AEM media would be to _wait_ for the user to decide, ie.
> print a message and wait either until the device is removed or the
> user decides not to do so via a key press (_not_ a timeout).

Definitely no timeout! But AFAICT an _additional_ key press isn't
needed either, because there are already some suitable sequence points
in (a slightly rearranged) -unseal for both schemes, static text and
2FA. Here's a drawing of the proposed -unseal sequence:


static: showing secret pressed Enter to hide secret
\ /
11111111111111111111 222222222 3333333333333333333
/ | \
2FA: showing OTP | keyfile pw entered
|
prompting for keyfile pw

phase 1: mount; copy sealed secrets to /tmp; unmount; check freshness
phase 2: noticeable use of secret; it's safe to remove the device
phase 3: inform -seal.service if sealing should be skipped; finish


This only covers the case where unsealing and the freshness check was
successful. But if not, and yet the user still wants to continue
booting with an RO AEM device for some reason, then we can simply rely
on the "Failed to seal ..." error message in -seal. (Which would only
have to be tweaked to require an Enter key press to continue booting,
so that it can't be missed.)

> Explicit is better than implicit, as the Python saying goes.

That's a solid guideline for code. But if I understand it right, it
can be problematic for UIs:

- - If dialog help messages explicitly cover all possible scenarios,
they quickly turn into this massive, fatiguing wall of text that has
to be read on every boot... IMO each idea to be conveyed in these
messages, and each word used to phrase it, should be treated as
costly (= taking time to read and comprehend, maybe even confusing
some users). Like Dijkstra's "lines [of code] spent", but for text.

- - If menus require an explicit choice between every possible option,
that's less efficient than defaulting to the most likely option (and
allowing the user to switch to the other options). For example,
imagine a version of Firefox that doesn't focus the address/search
bar on startup, but shows a series of Doom-style menu screens:

+-------------------+ +---------------+ +----------------------+
| | | | | |
| FIREFOX MAIN MENU | | OPEN A PAGE | | OPEN A PAGE ONLINE |
| | | | | |
| * Open a page | > | * online | > | from URL |
| Settings | > | from file | > | * via search engine |
| (...) | | | | |
| Quit | | | | |
| | | | | |
+-------------------+ +---------------+ +----------------------+

... and on and on. ;) I feel like the normal case should be
optimized to take as few steps as possible.

> >> And while we're at it, why not also extend the boot device label
> >> into a PCR -- what if the attacker covertly changed the label and
> >> the user then used this AEM media? There's risk of DoS attack by
> >> filling up the NVRAM freshness token area, or worse, overwriting
> >> other AEM media's freshness token hash (thus preventing it from
> >> being used).
> >
> > Booting from an attacker-modified AEM device is dangerous anyway,
> > e.g. there could be exploits against the ext4 filesystem driver.
>
> Yes, but while the ext4 exploits are theoretical, the DoS I outlined
> would be guaranteed to work.

True.

> > But when extending a PCR with the label is only one or two lines
> > of code, why not indeed. :)
> >
> >> Changes pushed
> >
> > Thanks! I'll try them out later this week.
>
> No rush, I'm still churning out small fixes.
>
> After a code-prettifying pass though, I'd be interested in some code
> review again. :)

Sure! It can wait until you think it's ready for review.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZd311XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfH2AP/2AJD+0gykgRmugSeKoTVBdm
TORsvNrs4trY+rjAEkso+8oagzHmGnaoRevh8LFIshCfIZnNvp1R+/CF8o2iyBlp
9FvQgCAXbMbtDcthorrG51ILPk2apshn2pbQlVf/YJmV2cJEdWKnGuIIxqzla5vq
rvudNrLMXEHBCT2ODurSgM24dxTe6Sr2K25gaxOM9XLE1OeCcncdLKxGrr6lzpbV
V7ZYnc7OKrJEG0Xa8nzR4Ut7v67DloNXzxHwDwfbK4/KjKIDQzhAJcvDnEzfzkcd
uzAaxWrQ5qXs+1K1XTQmVYfSalhOrmpRwcXfsQR6p0UL0RlEPci2cSkdp3kowq5L
in/ZP2aGPzmrF0RWlaJKXIBK56NDGm0Df/uTSiCJ4e6GlHQ6kxUXaPxDNmqKKW/L
l0PAonI9zJWOKXDjjr10fPjcDW+C/0jCsjsv3SEaa7vfin0kXqOSWg+eXuKUWtr+
776PK8bhws40uTzbPQ1DQ3tdRNgyX+J9BXSL8Xw6GDi2QGvJfbrT2EwLcdTYZe4t
QnyJPn3IsNlya0BNf+13s6O27H9mhYMoSPE80jGd3M/VD9ZZuyzdAS9hayqqpZeM
K5UEdfRu13CYCbIubvPiBZvP0ggU9ojiNjAAkfj8UlRp6QdqbLD0uye6C7f98DFo
yIlKP5LaZEXwWl3bOAP5
=awGI
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Rusty Bird:

Or did you mean the code-prettifying pass is already done? I
interpreted it the other way around, but now I'm not sure.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZd3/bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfVSQP/i1F3UNja6xt3BIFs5dcJ/ml
4V5I8N/M/GBIUlXw8YDXK6HGNroXHQN0gZ6dlWx3vm+zPMrAz+Nz2pQkoYck3yGC
49L85SqJplqpCBqIbgowtWKgBsPhsVrqJ1oWEFKc/xPG0GiwzglVI4rOcpV4qH42
74ZnCTpVdhCuVYxH3U3vtexFred3ZzQTHyFhEKfF8KoIOhZNiyDTxkiSUe+scFEI
eucVqnGkbMaBpYz0+fMccz44OuPy6aJfvFkOngsrjEIV4v2v1DW2cBLgLsxwb30T
zu/5yMHrmtGUZ5HQ0/VVuDYXqJIcn0LtPbuhEs/PPI1/ss+uMfPxn63cU/H7TFek
ID5t7XynuSrOG0IQXd+p2f7rqupLxDmq8+L1c7K0A9Q6xPqaEcHAtSf7305X5d6d
hwrr80+oIifFz+Mr9Ecx00c4anqtk+1ksccmfUSY6rLehj1tEF7o6BFHmZh8zmho
fZszu8YGXnZEUfMqIUd4HL7Ci1FxqGeOknjBiZ0Gb5BO7VKgpmvw59taGme1T8zv
qUNWzVtU9qHxEhIm8clhZepc7whVJc4XUpAiI8vqn00scpEJVF6YIlWE4hGJEov+
XkxIrwbV2owp7m5nALtXNxuiV8yZL7o1ac1Jf/Xdh/8KaoUIv29u86LeLiwUVm1e
MSJoE3bpy35Dkyn3gtGD
=GV+2
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

On 07/25/2017 07:28 PM, Rusty Bird wrote:> Rusty Bird:
>> Patrik Hagara:
>>> On 07/24/2017 04:40 PM, Rusty Bird wrote:
>>>> I was wondering about RW->RO downgrades too (didn't realize
>>>> you were already working on this part...), and came up with
>>>> the following tweak: Currently, the unseal script will mount
>>>> the device, do its work, and unmount. But it could be
>>>> rearranged to mount, copy the sealed secrets to /tmp,
>>>> immediately unmount, do its work, and at the end, check if
>>>> the user removed the device. If that's the case, the unseal
>>>> script can create a file in /run to skip -seal.service via
>>>> "ConditionPathExists=/run/...".
>>>>
>>>> This would prevent the easy downgrade, and it seems pretty
>>>> natural, UX-wise, to remove the device early if you don't
>>>> want to reseal. Probably much less code, too?
>>>
>>> Not sure about how natural it would feel... I'd say the best
>>> UX for removal of AEM media would be to _wait_ for the user to
>>> decide, ie. print a message and wait either until the device
>>> is removed or the user decides not to do so via a key press
>>> (_not_ a timeout).
>
>> Definitely no timeout! But AFAICT an _additional_ key press isn't
>> needed either, because there are already some suitable sequence
>> points in (a slightly rearranged) -unseal for both schemes,
>> static text and 2FA.

Oh, now I see what you mean! This may indeed provide satisfactory UX
and be simpler to implement.

>> I feel like the normal case should be optimized to take as few
>> steps as possible.

Agreed.

>>> After a code-prettifying pass though, I'd be interested in
>>> some code review again. :)
>
>> Sure! It can wait until you think it's ready for review.
>
> Or did you mean the code-prettifying pass is already done? I
> interpreted it the other way around, but now I'm not sure.

No, still working on it. :)

Would it be OK if I squashed all the commits so far into a single
large one (as there's already quite a lot of reverts and design
changes anyway). Should be much easier to review, too.

Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZd4NIAAoJEFwecd8DH5rlqdkQAI2Imd9t+H9eWFVN9rdH49kV
XB8sTmQSbobeLslsX0StqKJQ5MrnQxJ4datzjjBnXw0rGxlTM4W78i55HSQn8SYi
h8Wn8YUDqPnqRPvOLzwGJ+05nYGWKLGxnqhnRPwMJrbQDpthrdy8Cft0zEQBXYm/
aJ2cIg/gTJKJIf/q3u11/5ZqCTnFkBMZkPdXmiLZLiIN2wmAO1+Uy30QDz0pI/LX
ahxdT+JlakWYHEA+U66ZcvC/itpIZJD4hcFK3Iemk0JHngW1cHlGgC9uMgIZxupX
u9HFp/Q+YN1Mj+lkfQdnsjZ6tGssbV5pBgHU9Rn+1+nk+V8zmldzSq1jqIVc4Qs7
ZFns8VqLhdKiEAlRvlIC7SxpJlQpXAUmZUJX8KJMIUntqfS7xWvuIx6qJlXfnxW9
dw+WmTipPZdzybJXV2xaMIxwSjXLD1yvCMGwW5QFD7I2MSNyLyWVM4GaI2fB9bD3
CYZ/MErAUY3+EN4+hVnRKO0C80s/qTsWbDfm9AyrMXJ3I1KXR+zs7zjurp445+7G
0NMgWun/RmbH6+WNrYtUYg0dFjIBZTyjWspUkRKsucr5YQCxvrZ32xfV1W3ziozf
RvZ1TnLsypUwelRIRrSNHZwAz+SthudlPyEkqOmqrdjBEdTmEeVLK2PQDK7ySBYf
w4Am+qJbuplfchGNDBwl
=Dbzl
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Patrik Hagara:

> Would it be OK if I squashed all the commits so far into a single
> large one (as there's already quite a lot of reverts and design
> changes anyway).

Yes, please do.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZd5J7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfLTkP/RwyStNxTX3jGZiCIu3PjygX
rf4NQaBrMJO3kkPGd/iAylMEIxqC+aagiAk+VqfoM4GdVudQNfqD+oXO28ARZbBO
ds033AbccgK534fWsda2xrv1aprkfukshLffj4tmugs2CnqeQevkrpwKuAgs+aLr
n0odyTab3E448IhR9hC8u7MA725fujq1eKblB/unKRCIuQyAwZF0NPyPKCUTgWvg
SZxKpQV3AawPBnxTa/Jf5K/DD+jCJRS4qPa8qgaPyqOV+aP29ujjisVMFK0Pjfpr
sWU2tPkknuQ0ZILvU6cJHBHxy5QjBEjrgD3iQNpNAbkbNqXj6BPI8auPpi3WA4ZG
N69Ey6VLWjS2feEu2ej/EI1+4x9KhHg5yHiXGlIVL/QgEmOKDl7d1SqNvdPZEfbL
2gCDa1GXOCn165H0YJ07dGWAGyEjlI2jfmw5grvX/ujFI1hyoS809opb3zHSDf1a
/SxTLnBOBOwP0/p+D5mJavf4FXRi8bsXi+6YxYzO+12e8UmQemGjhveoFlXCt88r
Xo4pqMHEp9jIQTSwX4XebbOQRUjQb+INAYpmxL56Cpih4p1hGrRs2er9G2m/Dnrr
JZ+ReL8HYTt0yaTaTwWi+OzcKSQzGgCMeMAX8MRgbGNp/1hBtIihYSwxAgGB4Uv6
roTmLYHvGMb+8vGvOZKO
=fVGl
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

On 07/25/2017 08:48 PM, Rusty Bird wrote:
> Patrik Hagara:
>> Would it be OK if I squashed all the commits so far into a
>> single large one (as there's already quite a lot of reverts and
>> design changes anyway).
>
> Yes, please do.

Done, along with some refactoring (plus an implementation of your
RO/RW manual unplugging suggestion). Feel free to start reviewing. :)

I also took the liberty to remove Qubes 3.2 compatibility shims
(workarounds for old systemd and coreutils pkgs), so scream if you
cannot test on 4.0 yet. I'll be installing the 4.0 pre-release on a
spare drive over the weekend myself (ie. I haven't tested the current
commits yet, might be that some small bug sneaked in while refactoring).

Cheers,
Patrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZeJdtAAoJEFwecd8DH5rlwaEQAK0pHY5lQLVAv3NC8uhuLsq5
1JVD7Dn6vv4z6cYL30LxcwwLkuIacWPWs92Ja+lpqUxTTcoLzByl7DVwo3E2j5d7
aJ6yKpWTnd2MBvGaC7GO/yNMQ3tDEh2uAoSPm4eRhK5aHCdqO7d6KaUnbZba8WjJ
fITscsI/whr+YSwDS3ORmVcaikefGZSliHkEw3xogc6wKzAQYCfutFMpiVCsGUAP
Qc4w7naMruuO2p3ZnS0vtNI9Blvw8nIRm8Vd9XWaS4og4b+gFCAq/HBLNhTMjcnR
hetoB0B+s2O5E6QV6Vsl6km7fMY7WKtRfciIU2Ul0cVBc9weo7cz/sRGgMDYD23K
P6HjClS3FHC+zpYm+O3tm/KRq22BLPO1a/djeoz4yPCwKmF1TrW7LiHsEsj7GtxU
DD8ThUecScftKnJ82kPQqkBW8lFcOTnkZzzvJ1UuTCvGA/qyrfRcgaIMHlwhSzxH
xBIMHn1uiRn+JIuogxmn/WFy7lfU/LW5f5VWmHjwWDYaxcjtPEDsNzs9O7g4TmTn
ZDAIqTzbr52/zQRjyeHIMsgduafcWa7xUVq9KQtBPR9AT28GhZtrIWpxCFpOwLFP
XFwDwe+Wq9szKz0lZsYB3CtJkV6Ttlz2GMfIxCjS4eh0iF/5jsthxgHiM/g7OFZp
z9hUnAWk4wSDKsXCKPA7
=dw/8
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

On 07/26/2017 03:21 PM, Patrik Hagara wrote:
> On 07/25/2017 08:48 PM, Rusty Bird wrote:
>> Patrik Hagara:
>>> Would it be OK if I squashed all the commits so far into a
>>> single large one (as there's already quite a lot of reverts
>>> and design changes anyway).
>
>> Yes, please do.
>
> Done, along with some refactoring (plus an implementation of your
> RO/RW manual unplugging suggestion). Feel free to start reviewing.
> :)

Just a quick update: code review is in progress (see [1] for
comments), with various small changes and fixes being made [2].


Cheers,
Patrik


[1]
https://github.com/phagara/qubes-antievilmaid/commit/715abbc13a7d59b8d4a
72ec6696b621fa76e2a95
[2] https://github.com/phagara/qubes-antievilmaid/commits/master

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZggZiAAoJEFwecd8DH5rlmlYP/iB0sLyRTx3PMiKWyD4iiLNU
XRPGG0nBe9nfZopImFhjPbxAD51SI9z2qGg79g17sdcTP5HeJheO10ApwDSw9U9s
k9pfMVFq8Z9jK311IDvQRuD39MpKm7KmU5k2m+9omdvHnJaiREMGkxlQ+FmzzTVx
wBZSk2xVrboLLypdgCwImByExm6LQtS7tikC4ZWmHxE8Juwrl1+FinvTJdXEcRxF
IhKUStoVYbcYprDGpR5v4J7JmSV4QRIIM9uJiF3A/XOuwVSPCXkFYZHHw59hUm8l
SDdnHXM3AcVvwKC+l3B4uC12jwfmt3fyiQ6tjAyn9AVyN9YRAE32l6pTDIJaIHYp
t7m/NpWe+14rlvSYwA7Q34XdiHlgB4/6bj3YyB6twv+NU7TzEUstvcyuR8or5N2N
yRJxO6pHMUTgrdVri5CXII1w+HmjiWJsUXjK1eWWotJB2eduBKo+DIiw8i8S6HqZ
wiyH6op1CjO3tXFX+qeAQSwrUHs79lJEaygKk3B103RklWPFQLpDH9Y0qJ/qlQF/
s8HVWa9uXx2tLjbSo0kwQ031sOV+TxKWOANkczgUd86AmMVhYnU8Fqd1RtXTmjef
HCGmgBLuw0dXwK2rebcyNvUG6NtORPptzhwgDku6DuofkfPawZzI9237QY2JN/E2
vhwK3YvBx2trRoHLxJuG
=ouR+
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

On 08/02/2017 07:05 PM, Patrik Hagara wrote:
> On 07/26/2017 03:21 PM, Patrik Hagara wrote:
>> On 07/25/2017 08:48 PM, Rusty Bird wrote:
>>> Patrik Hagara:
>>>> Would it be OK if I squashed all the commits so far into a
>>>> single large one (as there's already quite a lot of reverts
>>>> and design changes anyway).
>
>>> Yes, please do.
>
>> Done, along with some refactoring (plus an implementation of your
>> RO/RW manual unplugging suggestion). Feel free to start
>> reviewing. :)
>
>
> Just a quick update: code review is in progress (see [1] for
> comments), with various small changes and fixes being made [2].
>
>
> Cheers, Patrik
>
>
> [1]
> https://github.com/phagara/qubes-antievilmaid/commit/715abbc13a7d59b8d
4a
>
>
72ec6696b621fa76e2a95
> [2] https://github.com/phagara/qubes-antievilmaid/commits/master

Finally managed to track down why unlocking disk with unsealed and
decrypted LUKS key file didn't work on a clean Qubes OS installation.

While starting to develop this feature, I added the key file path to
my /etc/crypttab and had forgotten about it. Fresh Qubes of course
didn't have this change. Combined with one weird systemd
incompatibility (the B point in this [1] forum post), it had caused
the key file to get completely ignored.

There are two ways to work around this issue [2], neither of which is
perfect [3]. Both solutions' downsides are pretty insignificant and
most likely not applicable to 99.99% of existing Qubes OS installations.

For now, I've decided to go with the second option (ignoring crypttab
even for hostonly dracut setups).

For any brave souls out there trying out Qubes 4.0 rc1 already, able
to compile their own packages using the qubes-builder and having Intel
TXT on their machines, you're welcome to try the latest commit from my
repo [4] and reporting back with any issues or comments (even unclear
documentation!).


Cheers,
Patrik



[1] https://fedoraforum.org/forum/showpost.php?p=1681988&postcount=43
[2]
https://github.com/phagara/qubes-antievilmaid/commit/715abbc13a7d59b8d4a
72ec6696b621fa76e2a95#commitcomment-23617394
[3]
https://github.com/phagara/qubes-antievilmaid/commit/715abbc13a7d59b8d4a
72ec6696b621fa76e2a95#commitcomment-23617493
[4] https://github.com/phagara/qubes-antievilmaid

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZj2x6AAoJEFwecd8DH5rlJnEQAI8+ouvRkXwzsz0CpN5UgOqB
1qmvua0NgBK1SC15gPeXjuOABXqO8IxJcVpuOoIL3wdZaHvvNgpGmXiKWUu6YTwi
h1yhS5w8/2rMhfLRT86AyP6H9SRwdC0DgrjCbBzsQtWZH4kBg8ItOK3q2XWrwhhC
3hckSJ4KbZNgT86q0PABCInLfDrxADiFnI+oOQBvHInq/hWuJRibDBWAnNG4AetA
KCkKpMGSSZTBzl6hBfczqtdWc/K7lIhPAO26ht87046ZRN+RjpOl588M2gsw2zYT
z3AHDQAY0+m8qAMv89luklyoYJCcg4RiMTOrPrGtBDFuHGB+rylUFDLujI+AaDH1
lLWNaPXBWUXsKBUqaHOWjP7ek+iK3Nl0yotqkngpiDZ+SNvrCCUa4xaG8j6NjVX6
jd8J/OsWzeiSDygzLKY4mitjNIT4d9yoHND4STte3UcWwAeq1vXlb4Ypvn7z7MNJ
w9ZDveawLv5Z6ZPLKMUsCml4JrGiLnK74jYi/GSMulB8ZMA2mfJGr9IAgMF8hp9b
+Aw2O0kkU3PMp5tTGgIsMAFI3nJcUN2TibiP5OA9898kVO0HXzpYFUfKhQATgjzf
g+1PIJwmO2WHvPGO1uYD0SwXyM7joXmg7z5lUEKqo40sU5nW3T/6qrpxymlP+Sy1
1AfgopK/R9mbwGrmvqgs
=SBa8
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Patrik Hagara:

> Finally managed to track down why unlocking disk with unsealed and
> decrypted LUKS key file didn't work on a clean Qubes OS installation.
>
> While starting to develop this feature, I added the key file path to
> my /etc/crypttab and had forgotten about it. Fresh Qubes of course
> didn't have this change. Combined with one weird systemd
> incompatibility (the B point in this [1] forum post), it had caused
> the key file to get completely ignored.
>
> There are two ways to work around this issue [2], neither of which is
> perfect [3]. Both solutions' downsides are pretty insignificant and
> most likely not applicable to 99.99% of existing Qubes OS installations.
>
> For now, I've decided to go with the second option (ignoring crypttab
> even for hostonly dracut setups).

So, to summarize, rd.luks.key works in both hostonly and non-hostonly
mode now, with this change? And rd.luks.options=discard (instead of
rd.luks.allow-discards) does too? If so, that seems very reasonable.

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZkIxHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf5RwP/2iVQGV6k44eq6JbpNJjoSMb
ViyTqTyJExL66GtDHQ684p36gD8/Pt+MXLLPHWm73sowQm1Sp1A74yr7m04WkW+q
9udraH6f3BWN8j+Jue0pxsPg5iONa/DF81+BDLRz8AitRftoUH9HClDJO0hxhNTd
nPgOlLSflZzfQFi5x31r8boXx1bSe9FxTXRy79sRb2WIAZMrkmTbwdk8c8Efe4Nb
nZYgd78V3f9Oo/xFfZtrYgo1fVC6r2sGSSFTYDizTwVUPu+cBXfND2NL/EwT9Hc5
gP2xy1FRClbA0OByDlHIf9Bm1NIaf11/IoUEuhXRyqhB5NUWpS3fSte2kjdbwDuf
kg/llsqChHa6X320NUsnJal/kd/939dmjsVHMXYp8ErJmk1iaF5ZflyRD9bvoKza
wqdY1DpQBfT4n8yZzbQ5kjqqH66GjlrsmjKDBGEf9gmH1jqJVMNs2uadkrtn8gf3
qd50nckperlBpAfHUKtndktnuNm1MgHnO6g8Icv1PNF/McWNEWDAIT32LVALOnfc
VQEMG1YLXTE/4bvpInUM7Gk2qkmwsv5Gt6E4j6ol7XGSQ84x5HpnZSQYLcWW5WCH
TDpzl6SgUxbxtVVJ23RGZ/kCnEcufd/+NaFAy4SzXnICkwEQOtidoKzJ2fjhFPRl
W+dnH3+KbAA3QbBXEu/1
=Fjbf
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

On 08/13/2017 07:28 PM, Rusty Bird wrote:
> Patrik Hagara:
>> Finally managed to track down why unlocking disk with unsealed
>> and decrypted LUKS key file didn't work on a clean Qubes OS
>> installation.
>
>> While starting to develop this feature, I added the key file path
>> to my /etc/crypttab and had forgotten about it. Fresh Qubes of
>> course didn't have this change. Combined with one weird systemd
>> incompatibility (the B point in this [1] forum post), it had
>> caused the key file to get completely ignored.
>
>> There are two ways to work around this issue [2], neither of
>> which is perfect [3]. Both solutions' downsides are pretty
>> insignificant and most likely not applicable to 99.99% of
>> existing Qubes OS installations.
>
>> For now, I've decided to go with the second option (ignoring
>> crypttab even for hostonly dracut setups).
>
> So, to summarize, rd.luks.key works in both hostonly and
> non-hostonly mode now, with this change? And
> rd.luks.options=discard (instead of rd.luks.allow-discards) does
> too? If so, that seems very reasonable.
>
> Rusty
>

Haven't tested the discard option yet as my 4.0 rc1 is on a HDD for
now but yes, that should work too.


Cheers,
Patrik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZkJdfAAoJEFwecd8DH5rlD8YP/2qug04xgTQzArQ/Hy1Xu9EA
Mu/eEscytBWnl19ej9VcmuZwOjfwhrAOo+LPJKJf3nETGB9Nn4TxXOyVmsjk9eod
WOaCQ6C/75HXxTD21KiiBhAOCZjiRm8fCSvFeUq7D9T/lx5hRazeWgWiDjD+6TqX
QvmPdsSwyJC3G73yDAJexF5Uii8zSj0WI3+8Crpl/xCK+TPGpjXlbeWXfmZZbEAc
JXNHel/PYKR3Rk35QmH2iFQeL3RtgzaxtIXPVhFXBhuNC0YU5xSpy8Z6A8BvSEkb
s9Ie9De1mDjO3TCdTeJorqBSX1VgsLUXnxAISy/2fq+5VcOG/fYLA2Lw2HflzFJ8
Rwx07Y0VwWHiGQb1jHTSpnPIWEXtDVAxmoSz8rdE4cNOHHyBoLEGfXBGOewsgfjG
cQhTsBpqmENDGTMrVn92ojOpS3BrlZg6vdObhZV18FS2WBXxGRxq0fdkVaBPYbZJ
eYZrw8SodjlnSMzZaTFoFvh5v8OPh4CAlIVACkS6vgn513phabeghCLVKYqOtHMW
cVm3b+JD9/y/+U+aS435U5Cw905yv/s8uclrPAv8pRBMXsC29GtDBjsPTNbrZkvF
c76GKAT5uJKho90qNM2e/iUEYxQI2ThiRLeO0tEpSEtSCkbSbzrXYzn94U/72WER
tEhlw6gWOc6zIXzPd7cv
=Kk4l
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

Hi!

I've updated the README a bit [1] to (hopefully) make some things
clearer. Also added a section on how to recover from compromises.

Rusty: do you think it's ready to be built and pushed into R4 testing
repos?


Cheers,
Patrik


[1]
https://github.com/phagara/qubes-antievilmaid/commit/11f518fce62aa6f962b
894094ef129b86dfbc6ae

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZlEIwAAoJEFwecd8DH5rljAQQAILfYkrbnZKxbsBy3MCMtaL6
cv1ARFZuR0307aMK3HO1Xe62rjQZsgcVSaM9RfjVkqCS8MQgzpAPRgJkeQvwXg4y
eMpX/ST9muu9hgkNPcg2/x6BxViOTvS+ZChKH0H6PSxOleWx0ZPWo2C7eno/8Aib
6GRTCEsan88ElyloZLcPbDaTMrbgpo1ytFMwFcMhlgXaAL8S3sgWgKZc9QY6O1qL
Mi9Sv027ZEtKgOt11gp8p+ZPqpJpxRGaZ8EPJtLgV4vNAUOkWELieJkuOinWTe9s
qm/qJYFka9VYJg4VnODDvius6PMaZ2DzJDgY0vvkRqVqKNiD/8xNpQZHsRLfXJHD
bb19s7rGQA3BGTFoUrt747LE6eWiMmOkbOQcB238RFbn1tQLk9tFFa4X17s5yQDt
VvFHfWUflCtvcuWZP+cwJE0mZW5YMhP8STmZtxfwIi40wn2bUpgL3EZ2wQnDeHn1
Mw88vyuKRm0EKAFbwaZ3V8KaSQSsM7JUQ+Cx7zS4akBc/JNEYIzfj7+XkEb63yrB
9MPqbkdVGuuELju1K7U8VtwsrCWNxIOCtn22qa2N+XxmvtSHUFAIuWiD98OfnjMH
vEaSUL8T/6si2FaTc8thKwyqx+eeWv92Tf8fydWnSoWHtxw3fqyEv328luH9H3Zj
WqUPW6lglqGcXfAF0AJO
=dwkX
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Patrik Hagara:

> I've updated the README a bit [1] to (hopefully) make some things
> clearer. Also added a section on how to recover from compromises.
>
> Rusty: do you think it's ready to be built and pushed into R4 testing
> repos?

Almost ready IMO. I have some more line comments, can you open a PR on
my qubes-antievilmaid fork? (Just so that I'm able to insert comments
into a flattened view of all commits.)

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZlGn/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrf7HAP/AwBCZ8ulOeKusfyxi2euc8w
8XThhrzzPpmzXqi73v8HOrXxrn99Yq+4JQ5w7AVSNFwmkTMkeSTgPk/qPseo1JCX
eaVMPwfzRTU6cWviZrsNpIth/5A73hke4eux3UivQqQkJjEzzNggxL4d2j3V/gL4
XcJJ/TS/DA1m3YsyyNdd4iDIujMQoZmikkt+JxHorhPoAWBEZd1CaBPrHgZwWLAa
lAf3PIihZtzrigd/aG6m03lhuhdUhfKxJU3vIIlnYVLD0D2LjNDHOvXMjmxsKTn+
sIaMsKYS7tWDlfazHavAo8xZFylh5fYQFhLWkaJwNAzHEenb8YF56A/R30uM5cNH
E2tIvBewdyepkDNf/ajVAy1Qs9Fm3fMyOKBMurY/X6H3vCCUOyXJn0lmD6N/cCJK
d0caNybEFU3V1QscIxUKAjodmqkeb16hJ1aQeEuBksN88dGQOmCKes0Ugv8HNAd/
hf28Ym4lQSwcI3mzlXpW02Lr1oY+NjWOUrDiJJmr3W3Kr73BiTH4U5iP6WYaWFB+
Ur9+Td9hUvw4MT8nOy3S+R9iLfC0POP/O3vfEe8U//PqJBvd5qrXkpdrg/dCxaq5
Iu2IbzwJrFke5e6563u8pcMxTAGg0ZNzUMPYLGAt3lIodBv3VYl4Gd5PaRcvHjo4
bzuKt1THhtNrnj2mtK7/
=XIQ/
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

On 08/16/2017 05:51 PM, Rusty Bird wrote:
> Patrik Hagara:

>> Rusty: do you think it's ready to be built and pushed into R4
>> testing repos?
>
> Almost ready IMO. I have some more line comments, can you open a PR
> on my qubes-antievilmaid fork? (Just so that I'm able to insert
> comments into a flattened view of all commits.)

Done.


Cheers,
Patrik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZlHFLAAoJEFwecd8DH5rlUZcP/j5pwQP3qz58K7HxmRK8vntr
/5XDDSbOPESCB12Li81Cg+OTeL+Ble9G1h+okhA0KFTV7Ho8XteFc8VJq0papG4f
Fl8VUjzJHVMbkFNpiW6v3A0sQiCcKIrkWLfB2bCw57qLiJLH9DGiO5utoIJ9/UzB
Qiypi+fqoOnxwy5FwS/pZmN+m2WA0vgheqlTBs3u9Bekyy3Ev0usy4DgLBKFBbo4
BIrM5RcMUTvlqFySY/2U9xxrTMOFtrn1v/wxeWSzdEOWJp3eed30c/R5SaWObHhI
lvWRBlW/vDUsDOygThaqxi44RlFb44YV1wTnL4t4o9KE3v92MyJNygYBozW6n0RM
gPPyX9kzAp8U+u+AfCVIOY0Pat3jmKbtKsIx633Zs6Umpx3ahsXYXy0hjMwjLIm1
dXbAWxMR0xKmiqaGFTFe8mV6Vl7UL2+v61B/qGk8pIg6XVKLwJvbBB9NqpCi0MP6
3pD+OaMsA4xXV9hAXohPO61akJp+oiOaYqeeAyHDQ7CnLd9nWx1u4LrwpPjvV7cn
yO1v+FXYQIkvH3qIEtDxNV1rEXRYwU07+IVzuak6KUt4sdqLeFY98Ha5F/N+UpqJ
D81nshtPhXNkhmpE0XSMlZv6dwKAVeNCaJngn78YQRsChqFI/SUEnQKAAm6A5yoj
zxtAcs5ON9MAKa3K4tUA
=dSQp
-----END PGP SIGNATURE-----

[Patrik Hagara]

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

Hey,

I've opened a pull request [1] to the AEM repository.

Again, enormous thank you to Rusty Bird for being a wonderful GSoC
mentor and helping me clean up the patches for submission. You are
awesome!


Cheers,
Patrik


[1] https://github.com/QubesOS/qubes-antievilmaid/pull/20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZnDJDAAoJEFwecd8DH5rlK5IQAMKSh+6fRkOVjwVGUZoRRagv
a7GY/7kJ2T7ZCkMf6Nlv9/PEndhOa6ZGNKXbVvqv4pX1/3z1g8MngOXDTQP73OvL
pHS4WDMpZkWkTfjaK07ihpehxbggu/jOfvfUf8wyRFj1PnLn3pdsbM/BqRKdXFcc
Pr8boZ/KAE32+MUEaT4I9LcHmGn3mBxAA6hiYUGQlWKqRIiNhBL9912Fj4bjQjRk
YWh5kfigbKLx8gU5+UdfknwMMZhLDWWzk5KGZBFGIen8XJJRYPVrFLxiOxweMyxD
aTh7jTpTYVlHkdpqrq9mSz9nr//0FC3ImytFjXvZK8MH/gqrfm1y87LyUL0laSj3
QmKBc81s23xTKrLW7oSvul1M+c4M7o2pxn5puJnZJhpWya6bfz8pEu4uCRVAMu9Z
jOyIF6IWMkBVocJaaZ2lSGmgNYlCnb1DYJ0wsUQktgtSEgSzxmUdPtqBuAdQn9+g
R9zYE1dzbyyY/4od7vekMeMMWRgaGawgHeLJv+qcROi9FYHvVWh1MIX+jaCyjFn+
XE73ewrdWcbtavAP0L+ds2QVw21QFBe+ASbiIZlmvyt1n3evFdvWVdsuDv89feyF
negiOWJE1sqpK4ytA53V0oBYKwS41KZlwn8WVgrdjY4qgbvTRcRuiM92Xzd0qDXk
jqBslNFhUNybfmtLSKZv
=RKId
-----END PGP SIGNATURE-----

[Rusty Bird]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Patrik,

> I've opened a pull request [1] to the AEM repository.
>
> Again, enormous thank you to Rusty Bird for being a wonderful GSoC
> mentor and helping me clean up the patches for submission.

Thank you for not going crazy from my nitpicking!

I encourage all AEM enthusiasts to review the code, and/or build the
packages and test them (on Qubes R4.0rc1 or later). And of course post
any feedback, either here or on GitHub, even if it's just "it works".

Rusty
-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJZnD76XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0
NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfn1UP/3F/L5leJMGIUxTa9U7EpQDm
2MOCP0rF5Mrfacq5a/mC1ZC8bInFNTpO85MACSq6pp7TSPZCGsCWLymx05dguuIL
UceeW70dZQI350T/wdYuUxtZLQNUfdIgzSm9kRJFEbe7Tt3WM/aSZTWas2WIoEAP
1pm/g41+vWZ5iPQXahcrpX45Of7ldqD4W+pS4/wlnw9mdqFWQfbDPZFWf4QRaMTu
f/FhoyE7yH0Z25J7CBlpwbz740r8M1+VYrkh0sEA3Wvp1gev5/BCYlgxatVal+kG
ikLzNuMPIcnPbTc6zuyQ/Kr3FmprHPHg6Q2Le/YyQqVwiSrv0OAFGjD9Bw9gtaoJ
6sUfdY0hhBZTX6eTCgyU2fdizgJ9xR0TB+nBjp3PASoo7EzLq1LpgcpXqXbnvREg
msKGf5Ex23yw69qHUTHu0EC9Nxu622M4RnSNYv93bJouY7pjSTIcr/q5SfyNmCrY
rUtCIL008GFzyHNcnlRv4v/KlZC5E1vgfX03dEnWl4UyA1hLsoXcUX+U8f2VkWLJ
DXbOxZfi8v5VMUd2AHRJM7s6yd0wuvTpARPmTb+GqzGpKSett6keQdoA8kN7MpO3
OUD9wn5LoM4oLg2rjP2HZSQVBOpY8DW1t4MgSgf06VUnFv5fC/n5n8Hc4wMO5JHX
Cc3rVHxjIxlzIQR5oQT2
=fcPT
-----END PGP SIGNATURE-----

[Rich Persaud]

OpenXT recently added TPM2 and forward seal (pre-computed PCR) support, currently in release candidate status.  This page has links to the relevant source and tickets, in case it's useful.  We found some device hardware quirks.  Questions/feedback welcome.

https://openxt.atlassian.net/wiki/spaces/DC/pages/81035265/Measured+Launch

Rich

[jonbrown...@gmail.com]

Have you guys and girls checked this talk exactly about how to use this to protect against AntiEvilMaid?

Here is the link to the video: https://www.youtube.com/watch?v=ykG8TGZcfT8

On Tuesday, June 6, 2017 at 10:10:18 AM UTC-5, Patrik Hagara wrote:

Hi!

As some of you may already know, I have been accepted into the Google
Summer of Code program to work on improving Qubes' Anti Evil Maid suite
to provide resistance against shoulder surfing and/or video
surveillance. The project proposal I submitted can be found archived on
this (qubes-devel) mailing list or in my GitHub repository [0].

It looks like I have managed to just slightly overestimate the time
needed to write the code for all the additional features and options for
AEM package. :)

Right now, I would say the first version of my code changes is almost
finished. Small bugs here and there are to be expected, but unless my
mentor (Rusty Bird) or anyone else has objections, I would consider the
new AEM workflow to be finalized.

Any and all code reviews are welcome! The changes I made are stored in
my fork of AEM repository [1].

For now, the next steps I am planning are to:
  * verify all the added features work as intended (lots of reboots)
  * check for any regressions (even more rebooting)
  * document the new AEM setup, upgrade and usage procedures

Again, I would love to hear feedback -- and not just from my mentor! ;)


Cheers,
Patrik



[0] https://github.com/phagara/gsoc2017-qubes-aem-proposal/releases
[1] https://github.com/phagara/qubes-antievilmaid