-----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.
>> On 06/26/2017 05:28 PM, Rusty Bird wrote:
>>>>>> 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?
>
>> 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.
>>>> 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...
>
> 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.
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-----
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/02923dcb-7034-8a86-d0fd-48bcbbfa6a23%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
0x031F9AE5.asc
Description: application/pgp-keys
0x031F9AE5.asc.sig
Description: PGP signature
