Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Javier Martinez Canillas]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

On 08/07/2017 06:56 PM, Roberts, William C wrote:

[snip]

>>>
>>> I'm basing that on page 107 of, "A Practical guide to TPM 2.0". This
>>> seems to be non-sensitive with respect to how they define privacy, so
>>> using the storage hierarchy seems reasonable to me.
>>>
>>
>> I see. I also read that chapter and thought the opposite, that it's more better to
>> use the endorsement hierarchy, because it addresses privacy (and so if the disk is
>> stolen, it can't be tracked to a specific TPM). But maybe I'll misunderstood the
>> information in that chapter so I'll read it again.
> 
> That scenario never really crossed my mind. I guess in theory it would be possible to trace it,
> But if you stole the hard-drive, you likely already know what machine it came out of. Unless
> It was just some random out of the machine already.
> 

Indeed. After reading that chapter again and also from your comments, I changed
it to use the storage hierarchy instead. Thanks a lot for your feedback!

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Javier Martinez Canillas]

[-- Attachment #1: Type: text/plain, Size: 8887 bytes --]

Hello Sebastien,

On 08/16/2017 07:25 PM, Raveau, Sebastien wrote:
> Hi Javier,
> 
> Thanks for your reply and apologies for the delay in mine.
> 

No worries, email is async anyways. I really appreciate your feedback.

> 
> 
> On 2017/08/03 14:21 PM, Javier Martinez Canillas wrote:
>> Yes, approach I mentioned does not attempt to protect from an evil maid
>> attack. Since if someone is able to get physical access to your computer, she
>> can change the initramfs which isn't measured so unlocking the LUKS volume
>> becomes trivial.
> 
> Perhaps I am the one missing something, apologies if I am, but isn't protecting
> against evil maid attack the whole point of disk encryption? :-)
> 

I think it really depends on your threat model. A colleague usually says that
security is not binary but instead a sliding scale of risk management.

IOW, the fact that only having the /root volume encrypted doesn't defend for
the evil maid attack doesn't mean that is not useful for other use cases, e.g:

1) A server that can be booted without typing a pass-phrase to unlock a LUKS
   volume but if the hard disk is stolen, can't be mounted on another machine.

2) A Virtual Machine image that if stolen can't be mounted in another machine. 

> 
> 
>> AFAICT this is an issue regardless of how the data is protected by the TPM
>> (e.g: using a sealed data object or storing it in an NV area), at some point
>> the key has to be decrypted and stored at least in RAM for unlocking the LUKS
>> volume. So I don't see how storing in an NV area will make a difference for
>> the attack you are mentioning (sorry if I'm missing something).
> 
> An issue regardless indeed; I was not suggesting that defending against such
> attacks can only be done with NV areas, just that there are more risks in doing
> so with sealed data; apologies for the confusion.
>

That's where I disagree. I don't see why storing in a NV area will make it more
secure that sealing the data. If you trick the system to unseal the data, then
you can also trick it to read from the NV area.
 
> Not recommending you do this but just in case it helps somehow in the future:
> technically the key does not have to be stored in RAM, you could have disk
> encryption/decryption done entirely in TPM, just very slowly. There are high
> performance alternatives with the key held in CPU (see "TRESOR Runs Encryption
> Securely Outside RAM" [1] for example) or GPU but both of those introduce other

Thanks for the pointer.

> challenges like reliability vs suspend/resume, and can hardly be locked down as
> much as a proper Hardware Security Module... Not to mention the (in)security of
> the transport between TPM and CPU/GPU: the LPC/I2C/PCIe/etc bus to either might
> be sniffed and the trip to the latter most likely includes a RAM stopover. Not
> that I would put this kind of attack and other considerations that require
> decapping, lasers, etc in the same category as the common Insider Threat alone
> with your machine just for a couple of minutes; just saying that it would be a
> lot of work for too little gain security-wise (GPU crypto is still interesting
> throughput-wise).
> 

Yeah, that's what I meant by a scaling risk management. If someone is the kind of
target for this type of attack (or something like differential power analysis to
extract data from the TPM) then they shouldn't rely only on the TPM, but instead
use many factors for authentication.

> 
> 
>> The suggestion here [0] is to have a small initramfs whose sole task is to
>> get a secret from the TPM and then store the secret in the Linux kernel, so
>> latter another initramfs is only able to unlock a volume but no to get the
>> secret.
> 
> Isn't this moot if an attacker has access to the decrypted files? I mean, if I
> can modify the initramfs to get local and/or remote shell, I do not care about
> the LUKS key anymore :-)
> 

Yes, but I think there's a difference between having access to the files of the
decrypted volume and having access to a boot partition that isn't encrypted in
the first place. That blog post was talking about the latter.

> 
> 
>> Another option is to have an encrypted boot partition, and make the
>> bootloader unlock the boot partition using the TPM. That way an attacker
>> won't be able to tamper with the system since the boot-loader is already
>> measured and the LUKS master key will be sealed to this PCR state.
> 
> That might work but it is tackling the exact same problem with the exact same
> solution, just at a different stage of the boot process: not only would it

I think I missed some information in my first email. The idea is to seal the LUKS
master key against PCR7 which is used to measure the UEFI Secure Boot policy and
keys on shim. That avoid unsealing the LUKS master key if Secure Boot was disabled
or the used keys were replaced.

So the difference is that the boot-loader will be signed while the initramfs isn't.

> require duplicating LUKS (or GPG to keep the boot partition unencrypted notably
> if it doubles as an EFI partition, but that would then also require modifying
> kernel/initramfs upgrade tools as well) into the boot loader, there would be
> even more mistakes you would have to avoid making; for example you would have
> to worry not only about the initramfs dropping to a shell (due to adding things
> like "single" to an unmeasured command line, to errors triggered on purpose or
> simply to bugs such as [2] not that long ago), you would also have to worry
> about the freedom your own unmodified boot loader might leave attackers (e.g.
> you might have forgotten to measure menu.lst/grub.cfg, or you measure it but
> a time-of-check vs time-of-use race condition allows the attacker to replace it
> as in [3], or attackers can do too much from the boot loader shell, or you have
> disabled that but bugs still lead to a rescue shell as in [4], etc).
> 

Agreed, that's why sealing against PCR7 and using the TPM with Secure Boot is the
least error prone approach and what we are exploring now.

> 
> 
>> I added support for tpm2_create to get the data to be sealed from the
>> standard input and for tpm2_unseal to write the unsealed data to the standard
>> output. That way the secret never is stored in a media
> 
> Nice, thanks!
> 
> I would just add "memset(outData.t.buffer, 0, outData.t.size);"... I see
> cryptsetup calls crypt_safe_free() on passwords and keys to zero out memory
> copies once they are not needed anymore, but then again I am not sure what
> happens in the pipe. Your secret might end up stored in pipefs "media" ;-D
> 
> It's probably nothing but I'll investigate, always good to know :-)
> 

Interesting, thanks a lot for bringing this up. I'll take a look to it as well.

> 
> 
>> That's certainly an advantage, although it's not a use case I'm interested in
> 
> Fair enough :-)
> 
> 
> 
>> I think that measuring the initramfs is tricky since any random package can
>> update the initramfs and so relying on the initramfs being measured could be
>> fragile IMHO.
> 
> I have to admit that I have a /boot and /actualboot just in case I am not
> familiar enough with all the intrinsics of the various distros I use: the
> former keeps software upgrades happy but resides in the encrypted / and once I
> have checked that nothing went wrong I apply the changes to the latter...
> 
> I have yet to find a initramfs-modifying package that did not trigger my
> initramfs-tools hook though; wouldn't it work just as well on Red Hat?
>

Yes, it would but we decided that it's fragile since you need to re-seal
everything, and instead will explore to encrypt /boot as mentioned.
 
> Maybe I am missing something, but it seems to me that not measuring the
> initramfs defeats the whole purpose of using the TPM: is the threat profile

Indeed, it's an important attack vector. I hope my explanation about sealing
against PCR7 and encrypting /boot and only be able to decrypt using a signed
bootloader better explains why we could protect against this without the need
to measure the initramfs.

> limited to someone stealing the disks without stealing the computers as well,
> nor ever coming back once they realise the disks are encrypted? :-)
>

We preferred to do it in small steps, so this initial solution as you mentioned
has limited use cases (although even for those people are interested and it is
better than nothing). And even for full disk encryption (including /boot), you
need the ability for user-space to unlock the LUKS volume so this will be part
of the final solution.

Again, thanks a lot for your comments and feedback.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Raveau, Sebastien]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

Hi William,

> > For example if I copy your exact /boot onto another disk, copy your LUKS
> > header into a tiny partition just for your initrd to retrieve the sealed
> > keys, and add my own root partition unencrypted but with the same UUID as
> > that of your crypt_root then I am likely to end up with a fully functional
> > system of my own where your keys are unsealed.

> The keys themselves I would imagine are being loaded into the TPM on boot
> since they are Not persistent, those keys shouldn't be able to be unwrapped
> by a separate TPM.

Of course :-) I was referring to me using your own TPM against you.

Best regards,

Sebastien
Please consider the environment before printing this email. This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies under the control of BAE Systems PLC, details of which can be found at http://www.baesystems.com/Businesses/index.htm.

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Raveau, Sebastien]

[-- Attachment #1: Type: text/plain, Size: 6558 bytes --]

Hi Javier,

Thanks for your reply and apologies for the delay in mine.



On 2017/08/03 14:21 PM, Javier Martinez Canillas wrote:
> Yes, approach I mentioned does not attempt to protect from an evil maid
> attack. Since if someone is able to get physical access to your computer, she
> can change the initramfs which isn't measured so unlocking the LUKS volume
> becomes trivial.

Perhaps I am the one missing something, apologies if I am, but isn't protecting
against evil maid attack the whole point of disk encryption? :-)



> AFAICT this is an issue regardless of how the data is protected by the TPM
> (e.g: using a sealed data object or storing it in an NV area), at some point
> the key has to be decrypted and stored at least in RAM for unlocking the LUKS
> volume. So I don't see how storing in an NV area will make a difference for
> the attack you are mentioning (sorry if I'm missing something).

An issue regardless indeed; I was not suggesting that defending against such
attacks can only be done with NV areas, just that there are more risks in doing
so with sealed data; apologies for the confusion.

Not recommending you do this but just in case it helps somehow in the future:
technically the key does not have to be stored in RAM, you could have disk
encryption/decryption done entirely in TPM, just very slowly. There are high
performance alternatives with the key held in CPU (see "TRESOR Runs Encryption
Securely Outside RAM" [1] for example) or GPU but both of those introduce other
challenges like reliability vs suspend/resume, and can hardly be locked down as
much as a proper Hardware Security Module... Not to mention the (in)security of
the transport between TPM and CPU/GPU: the LPC/I2C/PCIe/etc bus to either might
be sniffed and the trip to the latter most likely includes a RAM stopover. Not
that I would put this kind of attack and other considerations that require
decapping, lasers, etc in the same category as the common Insider Threat alone
with your machine just for a couple of minutes; just saying that it would be a
lot of work for too little gain security-wise (GPU crypto is still interesting
throughput-wise).



> The suggestion here [0] is to have a small initramfs whose sole task is to
> get a secret from the TPM and then store the secret in the Linux kernel, so
> latter another initramfs is only able to unlock a volume but no to get the
> secret.

Isn't this moot if an attacker has access to the decrypted files? I mean, if I
can modify the initramfs to get local and/or remote shell, I do not care about
the LUKS key anymore :-)



> Another option is to have an encrypted boot partition, and make the
> bootloader unlock the boot partition using the TPM. That way an attacker
> won't be able to tamper with the system since the boot-loader is already
> measured and the LUKS master key will be sealed to this PCR state.

That might work but it is tackling the exact same problem with the exact same
solution, just at a different stage of the boot process: not only would it
require duplicating LUKS (or GPG to keep the boot partition unencrypted notably
if it doubles as an EFI partition, but that would then also require modifying
kernel/initramfs upgrade tools as well) into the boot loader, there would be
even more mistakes you would have to avoid making; for example you would have
to worry not only about the initramfs dropping to a shell (due to adding things
like "single" to an unmeasured command line, to errors triggered on purpose or
simply to bugs such as [2] not that long ago), you would also have to worry
about the freedom your own unmodified boot loader might leave attackers (e.g.
you might have forgotten to measure menu.lst/grub.cfg, or you measure it but
a time-of-check vs time-of-use race condition allows the attacker to replace it
as in [3], or attackers can do too much from the boot loader shell, or you have
disabled that but bugs still lead to a rescue shell as in [4], etc).



> I added support for tpm2_create to get the data to be sealed from the
> standard input and for tpm2_unseal to write the unsealed data to the standard
> output. That way the secret never is stored in a media

Nice, thanks!

I would just add "memset(outData.t.buffer, 0, outData.t.size);"... I see
cryptsetup calls crypt_safe_free() on passwords and keys to zero out memory
copies once they are not needed anymore, but then again I am not sure what
happens in the pipe. Your secret might end up stored in pipefs "media" ;-D

It's probably nothing but I'll investigate, always good to know :-)



> That's certainly an advantage, although it's not a use case I'm interested in

Fair enough :-)



> I think that measuring the initramfs is tricky since any random package can
> update the initramfs and so relying on the initramfs being measured could be
> fragile IMHO.

I have to admit that I have a /boot and /actualboot just in case I am not
familiar enough with all the intrinsics of the various distros I use: the
former keeps software upgrades happy but resides in the encrypted / and once I
have checked that nothing went wrong I apply the changes to the latter...

I have yet to find a initramfs-modifying package that did not trigger my
initramfs-tools hook though; wouldn't it work just as well on Red Hat?

Maybe I am missing something, but it seems to me that not measuring the
initramfs defeats the whole purpose of using the TPM: is the threat profile
limited to someone stealing the disks without stealing the computers as well,
nor ever coming back once they realise the disks are encrypted? :-)



[0] https://mjg59.dreamwidth.org/48897.html
[1] https://en.wikipedia.org/wiki/TRESOR
[2] http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetup_initrd_shell.html
[3] https://www.usenix.org/conference/woot12/workshop-program/presentation/mulliner
[4] http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html

--
Best regards,
Sebastien
Please consider the environment before printing this email. This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies under the control of BAE Systems PLC, details of which can be found at http://www.baesystems.com/Businesses/index.htm.

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 3164 bytes --]



> -----Original Message-----
> From: Javier Martinez Canillas [mailto:javierm(a)redhat.com]
> Sent: Thursday, August 3, 2017 5:25 AM
> To: Roberts, William C <william.c.roberts(a)intel.com>; tpm2(a)lists.01.org
> Subject: Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2
> 
> Hello Bill,
> 
> On 08/02/2017 08:00 PM, Roberts, William C wrote:
> 
> [snip]
> 
> >>>
> >>
> >> Yes, maybe I'm failing in the terminology. My understanding is that
> >> the TPM2 on
> >> TPM2_Create() creates a key pair, seals the passed data using this
> >> key, wraps the key using the parent key and finally returns that wrapped key
> pair to caller.
> >>
> >> Since the key pair is needed to be loaded for unsealing, I need to
> >> store it in a place so they can latter be used for unsealing.
> >
> > In theory you can store that anywhere, the easier it is to get to the
> > more prevalent someone can hose all of your data. The LUKS partition
> > metadata seems reasonable, if they can delete that, they could hose
> > your hard drive data anyways. A permeant entity in the TPM is also an option.
> >
> 
> Exactly, that's what my reasoning as well. Good that you confirm my
> understanding and we are in the same page then.
> 
> >>
> >>>  and using the
> >>>> endorsement hierarchy by default.
> >>>
> >>> I don't see the privacy concerns offhand, as no one is receiving a
> >>> digital
> >> signature from the private key generated?
> >>
> >> That's why I'm storing it in an accessible place, since it can't be
> >> used without the TPM2. I just wanted to confirm if my understanding of the
> specs were correct.
> >>
> >>> I think the storage hierarchy is more appropriate, but again I may
> >>> be missing
> >> something.
> >>>
> >>
> >> Can you please elaborate on why do you think the storage hierarchy
> >> (TPM_RH_OWNER) is more appropriate? That's why I asked the question,
> >> because reading the specs were not clear to me which one is meant to
> >> be used for this use case.
> >
> > I'm basing that on page 107 of, "A Practical guide to TPM 2.0". This
> > seems to be non-sensitive with respect to how they define privacy, so
> > using the storage hierarchy seems reasonable to me.
> >
> 
> I see. I also read that chapter and thought the opposite, that it's more better to
> use the endorsement hierarchy, because it addresses privacy (and so if the disk is
> stolen, it can't be tracked to a specific TPM). But maybe I'll misunderstood the
> information in that chapter so I'll read it again.

That scenario never really crossed my mind. I guess in theory it would be possible to trace it,
But if you stole the hard-drive, you likely already know what machine it came out of. Unless
It was just some random out of the machine already.

> 
> > This is all caveated with I am pretty new to TPM as well, so someone
> > more knowledgeable may see things differently.
> >
> 
> No worries, certainly have more experience than me so I really appreciate your
> feedback!
> 
> Best regards,
> --
> Javier Martinez Canillas
> Software Engineer - Desktop Hardware Enablement Red Hat

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 6216 bytes --]



> -----Original Message-----
> From: Javier Martinez Canillas [mailto:javierm(a)redhat.com]
> Sent: Thursday, August 3, 2017 6:21 AM
> To: Raveau, Sebastien <sebastien.raveau(a)baesystems.com>; Roberts, William C
> <william.c.roberts(a)intel.com>; tpm2(a)lists.01.org
> Subject: Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2
> 
> Hello Sebastien,
> 
> Thanks a lot for your feedack.
> 
> On 08/03/2017 12:33 PM, Raveau, Sebastien wrote:
> > Hello Javier, Robert, everyone,
> >
> > I very much appreciate the effort but I believe there are problems with this
> particular approach:
> >
> >>>> Do you think what I described is the correct approach? Specially I
> >>>> would like to know your opinion about storing not only the pub but
> >>>> also the priv key in the LUKS volume header (since both are needed
> >>>> for unsealing)
> >
> > I would not store anything in the LUKS header because it needs to be measured
> and tightly coupled with the mounting process to ensure that you are not being
> tricked. For example if I copy your exact /boot onto another disk, copy your LUKS
> header into a tiny partition just for your initrd to retrieve the sealed keys, and
> add my own root partition unencrypted but with the same UUID as that of your
> crypt_root then I am likely to end up with a fully functional system of my own
> where your keys are unsealed.

The keys themselves I would imagine are being loaded into the TPM on boot since they are
Not persistent, those keys shouldn't be able to be unwrapped by a separate TPM.

> 
> Yes, approach I mentioned does not attempt to protect from an evil maid attack.
> Since if someone is able to get physical access to your computer, she can change
> the initramfs which isn't measured so unlocking the LUKS volume becomes trivial.
> 
> AFAICT this is an issue regardless of how the data is protected by the TPM (e.g:
> using a sealed data object or storing it in an NV area), at some point the key has
> to be decrypted and stored at least in RAM for unlocking the LUKS volume.
> 
> So I don't see how storing in an NV area will make a difference for the attack you
> are mentioning (sorry if I'm missing something).
> 
> The suggestion here [0] is to have a small initramfs whose sole task is to get a
> secret from the TPM and then store the secret in the Linux kernel, so latter
> another initramfs is only able to unlock a volume but no to get the secret.
> 
> Another option is to have an encrypted boot partition, and make the bootloader
> unlock the boot partition using the TPM. That way an attacker won't be able to
> tamper with the system since the boot-loader is already measured and the LUKS
> master key will be sealed to this PCR state.
> 
> >
> > It is also crucial to remove access to unsealed data or unlocked NVRAM
> > indices as soon as they are not needed anymore. For example if your
> > initrd takes issue with my trick above, I imagine it would drop to a
> > root shell which would still give me access to your unsealed keys
> > unless you
> 
> I absolutely agree, that's why I added support for tpm2_create to get the data to
> be sealed from the standard input and for tpm2_unseal to write the unsealed
> data to the standard output. That way the secret never is stored in a media:
> 
> https://github.com/01org/tpm2-
> tools/commit/686951ed0b300871d979ad6b2f3e82527ed86106
> https://github.com/01org/tpm2-
> tools/commit/8aa7f644386d611b0f83060e1a70d97096ba4967
> 
> remove access asap. This is very easily achieved with a NVRAM index by defining
> it with the READ_STCLEAR flag and a size 0 read right after the normal read, but
> you could achieve the same result by further extending (with whatever
> measurement just to invalidate it) one of the PCRs the
> 
> Correct, the same can be achieved in both cases.
> 
> data is sealed/locked with; of course in both cases you also have to make sure to
> wipe asap all copies of unlocked/unsealed data that you might have made.
> >
> > Personally I would recommend using NVRAM indices as opposed to sealed
> data, for three reasons:
> > 1/ No need to write to the encrypted storage medium, so that for
> > example you can have TPM(s) unlock a live CD like
> > https://lists.debian.org/debian-live/2007/02/msg00090.html
> 
> That's certainly an advantage, although it's not a use case I'm interested in.
> 
> > 2/ Chicken & egg problem if you store sealed data files into the
> > places that need to be measured, e.g. my own original approach was to
> > store inside the initrd but I needed to measure that. Granted,
> > nowadays I could add the sealed data as an initrd overlay and you
> > could measure only
> 
> I think that measuring the initramfs is tricky since any random package can update
> the initramfs and so relying on the initramfs being measured could be fragile
> IMHO.
> 
> chosen parts of the LUKS header but meh, it feels like leaving the door ajar for
> vulnerabilities.
> > 3/ I can't seem to find a reason justifying the unnecessary risk added by
> introducing a key pair between the TPM's Hardware Security Module function
> and LUKS's key derivation function; why not have the TPM decrypt the LUKS
> master key for you, or simply hold in NVRAM a (fully random) passphrase for one
> of the LUKS key slots? Both usable only when the right conditions are met of
> course.
> >
> 
> Sorry, I'm not sure I followed the last paragraph. I think we are mixing two things
> here: a) what to protect using the TPM and b) how to protect it (sealing vs NV
> area).
> 
> So in summary, the only advantage I see in using NV areas over sealing data is (1).
> But I think that it also has disadvantages, because it's true that most TPM have a
> lot of NV memory just to store many keys, but still the areas have to be managed
> and also I think that one of the improvements of TPM2 over TPM1.2 is that the
> secret can be easily stored outside of the TPM without making this less secure.
> 
> [0]: https://mjg59.dreamwidth.org/48897.html
> 
> Best regards,
> --
> Javier Martinez Canillas
> Software Engineer - Desktop Hardware Enablement Red Hat

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Javier Martinez Canillas]

[-- Attachment #1: Type: text/plain, Size: 5419 bytes --]

Hello Sebastien,

Thanks a lot for your feedack.

On 08/03/2017 12:33 PM, Raveau, Sebastien wrote:
> Hello Javier, Robert, everyone,
> 
> I very much appreciate the effort but I believe there are problems with this particular approach:
> 
>>>> Do you think what I described is the correct approach? Specially I
>>>> would like to know your opinion about storing not only the pub but
>>>> also the priv key in the LUKS volume header (since both are needed
>>>> for unsealing)
> 
> I would not store anything in the LUKS header because it needs to be measured and tightly coupled with the mounting process to ensure that you are not being tricked. For example if I copy your exact /boot onto another disk, copy your LUKS header into a tiny partition just for your initrd to retrieve the sealed keys, and add my own root partition unencrypted but with the same UUID as that of your crypt_root then I am likely to end up with a fully functional system of my own where your keys are unsealed.

Yes, approach I mentioned does not attempt to protect from an evil maid attack.
Since if someone is able to get physical access to your computer, she can change
the initramfs which isn't measured so unlocking the LUKS volume becomes trivial.

AFAICT this is an issue regardless of how the data is protected by the TPM (e.g:
using a sealed data object or storing it in an NV area), at some point the key
has to be decrypted and stored at least in RAM for unlocking the LUKS volume.

So I don't see how storing in an NV area will make a difference for the attack
you are mentioning (sorry if I'm missing something).

The suggestion here [0] is to have a small initramfs whose sole task is to get
a secret from the TPM and then store the secret in the Linux kernel, so latter
another initramfs is only able to unlock a volume but no to get the secret.

Another option is to have an encrypted boot partition, and make the bootloader
unlock the boot partition using the TPM. That way an attacker won't be able to
tamper with the system since the boot-loader is already measured and the LUKS
master key will be sealed to this PCR state.

> 
> It is also crucial to remove access to unsealed data or unlocked NVRAM indices as soon as they are not needed anymore. For example if your initrd takes issue with my trick above, I imagine it would drop to a root shell which would still give me access to your unsealed keys unless you 

I absolutely agree, that's why I added support for tpm2_create to get the data
to be sealed from the standard input and for tpm2_unseal to write the unsealed
data to the standard output. That way the secret never is stored in a media:

https://github.com/01org/tpm2-tools/commit/686951ed0b300871d979ad6b2f3e82527ed86106
https://github.com/01org/tpm2-tools/commit/8aa7f644386d611b0f83060e1a70d97096ba4967

remove access asap. This is very easily achieved with a NVRAM index by defining it with the READ_STCLEAR flag and a size 0 read right after the normal read, but you could achieve the same result by further extending (with whatever measurement just to invalidate it) one of the PCRs the 

Correct, the same can be achieved in both cases.

data is sealed/locked with; of course in both cases you also have to make sure to wipe asap all copies of unlocked/unsealed data that you might have made.
> 
> Personally I would recommend using NVRAM indices as opposed to sealed data, for three reasons:
> 1/ No need to write to the encrypted storage medium, so that for example you can have TPM(s) unlock a live CD like https://lists.debian.org/debian-live/2007/02/msg00090.html

That's certainly an advantage, although it's not a use case I'm interested in.

> 2/ Chicken & egg problem if you store sealed data files into the places that need to be measured, e.g. my own original approach was to store inside the initrd but I needed to measure that. Granted, nowadays I could add the sealed data as an initrd overlay and you could measure only 

I think that measuring the initramfs is tricky since any random package can update
the initramfs and so relying on the initramfs being measured could be fragile IMHO.

chosen parts of the LUKS header but meh, it feels like leaving the door ajar for vulnerabilities.
> 3/ I can't seem to find a reason justifying the unnecessary risk added by introducing a key pair between the TPM's Hardware Security Module function and LUKS's key derivation function; why not have the TPM decrypt the LUKS master key for you, or simply hold in NVRAM a (fully random) passphrase for one of the LUKS key slots? Both usable only when the right conditions are met of course.
>

Sorry, I'm not sure I followed the last paragraph. I think we are mixing two things
here: a) what to protect using the TPM and b) how to protect it (sealing vs NV area).

So in summary, the only advantage I see in using NV areas over sealing data is (1).
But I think that it also has disadvantages, because it's true that most TPM have a
lot of NV memory just to store many keys, but still the areas have to be managed and
also I think that one of the improvements of TPM2 over TPM1.2 is that the secret can
be easily stored outside of the TPM without making this less secure.

[0]: https://mjg59.dreamwidth.org/48897.html

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Javier Martinez Canillas]

[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]

Hello Bill,

On 08/02/2017 08:00 PM, Roberts, William C wrote:

[snip]

>>>
>>
>> Yes, maybe I'm failing in the terminology. My understanding is that the TPM2 on
>> TPM2_Create() creates a key pair, seals the passed data using this key, wraps the
>> key using the parent key and finally returns that wrapped key pair to caller.
>>
>> Since the key pair is needed to be loaded for unsealing, I need to store it in a
>> place so they can latter be used for unsealing.
> 
> In theory you can store that anywhere, the easier it is to get to the more prevalent someone
> can hose all of your data. The LUKS partition metadata seems reasonable, if they can delete
> that, they could hose your hard drive data anyways. A permeant entity in the TPM is also
> an option.
>

Exactly, that's what my reasoning as well. Good that you confirm my understanding
and we are in the same page then.
 
>>
>>>  and using the
>>>> endorsement hierarchy by default.
>>>
>>> I don't see the privacy concerns offhand, as no one is receiving a digital
>> signature from the private key generated?
>>
>> That's why I'm storing it in an accessible place, since it can't be used without the
>> TPM2. I just wanted to confirm if my understanding of the specs were correct.
>>
>>> I think the storage hierarchy is more appropriate, but again I may be missing
>> something.
>>>
>>
>> Can you please elaborate on why do you think the storage hierarchy
>> (TPM_RH_OWNER) is more appropriate? That's why I asked the question,
>> because reading the specs were not clear to me which one is meant to be used
>> for this use case.
> 
> I'm basing that on page 107 of, "A Practical guide to TPM 2.0". This seems to be non-sensitive
> with respect to how they define privacy, so using the storage hierarchy seems reasonable to
> me.
>

I see. I also read that chapter and thought the opposite, that it's more better to use
the endorsement hierarchy, because it addresses privacy (and so if the disk is stolen,
it can't be tracked to a specific TPM). But maybe I'll misunderstood the information in
that chapter so I'll read it again.

> This is all caveated with I am pretty new to TPM as well, so someone more knowledgeable may see
> things differently.
> 

No worries, certainly have more experience than me so I really appreciate your feedback!

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Raveau, Sebastien]

[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]

Hello Javier, Robert, everyone,

I very much appreciate the effort but I believe there are problems with this particular approach:

> >> Do you think what I described is the correct approach? Specially I
> >> would like to know your opinion about storing not only the pub but
> >> also the priv key in the LUKS volume header (since both are needed
> >> for unsealing)

I would not store anything in the LUKS header because it needs to be measured and tightly coupled with the mounting process to ensure that you are not being tricked. For example if I copy your exact /boot onto another disk, copy your LUKS header into a tiny partition just for your initrd to retrieve the sealed keys, and add my own root partition unencrypted but with the same UUID as that of your crypt_root then I am likely to end up with a fully functional system of my own where your keys are unsealed.

It is also crucial to remove access to unsealed data or unlocked NVRAM indices as soon as they are not needed anymore. For example if your initrd takes issue with my trick above, I imagine it would drop to a root shell which would still give me access to your unsealed keys unless you remove access asap. This is very easily achieved with a NVRAM index by defining it with the READ_STCLEAR flag and a size 0 read right after the normal read, but you could achieve the same result by further extending (with whatever measurement just to invalidate it) one of the PCRs the data is sealed/locked with; of course in both cases you also have to make sure to wipe asap all copies of unlocked/unsealed data that you might have made.

Personally I would recommend using NVRAM indices as opposed to sealed data, for three reasons:
1/ No need to write to the encrypted storage medium, so that for example you can have TPM(s) unlock a live CD like https://lists.debian.org/debian-live/2007/02/msg00090.html
2/ Chicken & egg problem if you store sealed data files into the places that need to be measured, e.g. my own original approach was to store inside the initrd but I needed to measure that. Granted, nowadays I could add the sealed data as an initrd overlay and you could measure only chosen parts of the LUKS header but meh, it feels like leaving the door ajar for vulnerabilities.
3/ I can't seem to find a reason justifying the unnecessary risk added by introducing a key pair between the TPM's Hardware Security Module function and LUKS's key derivation function; why not have the TPM decrypt the LUKS master key for you, or simply hold in NVRAM a (fully random) passphrase for one of the LUKS key slots? Both usable only when the right conditions are met of course.

To be completely honest I have to warn that NVRAM size is not infinite; personally I have always found there to be plenty of space (kilobytes vs 32 bytes per fully-random "passphrase" to match the entropy of AES-256 keys) left but I don't know if there are TPMs out there with too little NVRAM (depending on how many combinations of bootstraps and LUKS root partitions your users might want to support) or none at all.

Best regards,

Sebastien
Please consider the environment before printing this email. This message should be regarded as confidential. If you have received this email in error please notify the sender and destroy it immediately. Statements of intent shall only become binding when confirmed in hard copy by an authorised signatory. The contents of this email may relate to dealings with other companies under the control of BAE Systems Applied Intelligence Limited, details of which can be found at http://www.baesystems.com/Businesses/index.htm.

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 5323 bytes --]



> -----Original Message-----
> From: Javier Martinez Canillas [mailto:javierm(a)redhat.com]
> Sent: Monday, July 31, 2017 5:29 PM
> To: Roberts, William C <william.c.roberts(a)intel.com>; tpm2(a)lists.01.org
> Subject: Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2
> 
> Hello Bill,
> 
> Thanks a lot for your feedback.
> 
> On 07/31/2017 10:27 PM, Roberts, William C wrote:
> >
> >
> >> -----Original Message-----
> >> From: tpm2 [mailto:tpm2-bounces(a)lists.01.org] On Behalf Of Javier
> >> Martinez Canillas
> >> Sent: Wednesday, July 26, 2017 12:25 PM
> >> To: tpm2(a)lists.01.org
> >> Subject: [tpm2] feedback on unlocking LUKS volumes using a TPM2
> >>
> >> Hello folks,
> >>
> >> As mentioned before, I'm exploring on using a TPM2 chip to unlock a
> >> root LUKS volume so users don't need to type a passphrase as long as
> >> their systems have not been tampered with.
> >>
> >> Since I'm still new to TPM2, I wanted to share what I did in case
> >> people more familiar with the TCG specification could provide their feedback.
> >>
> >> First some context:
> >>
> >> We have a plugable framework for automated decryption that's called Clevis
> [0].
> >>
> >> Clevis has a number of "pins", where each pin implements an automated
> >> decryption support using a different {en,de}cryption backend. It also
> >> has infrastructure to {en,de}crypt data, unlock LUKS volumes and
> >> create complex security policies.
> >>
> >> Clevis relies on the José project [1], which is an C implementation
> >> of the JOSE (Javascript Object Signing and Encryption) standard [2].
> >> It also uses the LUKSMeta project [3] to bind a pin to a LUKS volume,
> >> by storing the JWE (JSON Web
> >> Encryption) [4] in the LUKS header so the data can later be decrypted
> >> and the volume unlocked.
> >>
> >> So I created a TPM2 pin [5] for clevis to reuse all this existing infrastructure.
> >>
> >> But I'm mostly interested for your feedback on the TPM2 bits, what I
> >> basically do is something like this:
> >>
> >> - Create an authorization policy based on a set of PCR ids
> >> - Create a primary key
> >> - Create an object and pass as data to be sealed a JWK (JSON Web Key) [6]
> that is
> >>   used to encrypt the LUKS volume master key.
> >> - Create a JWE that contains the encrypted LUKS key and also information on
> how
> >>   to decrypt it. The information that's needed to unseal the JWK from the
> TPM2 is:
> >>
> >>     - hierarchy used for the primary key and object
> >>     - the hash and key algorithms used
> >>     - PCR bank and ids for policy session
> >>     - the public and private key pair for the sealed object
> >>
> >> The user can choose most of the parameters when using the clevis tpm2
> >> pin, but these are the default used:
> >>
> >> - Endorsement hierarchy seed for the primary key and sealed object
> >> - SHA-256 for primary and object name computation
> >> - ECC as algorithm type for generated key
> >> - SHA-1 PCR bank for PCR policy
> >>
> >> Do you think what I described is the correct approach? Specially I
> >> would like to know your opinion about storing not only the pub but
> >> also the priv key in the LUKS volume header (since both are needed
> >> for unsealing)
> >
> > I'm not following what you're saying about storing the keypair here
> > for unsealing, shouldn't those keys be generated in the tpm and bound to a pcr
> policy?
> >
> 
> Yes, maybe I'm failing in the terminology. My understanding is that the TPM2 on
> TPM2_Create() creates a key pair, seals the passed data using this key, wraps the
> key using the parent key and finally returns that wrapped key pair to caller.
> 
> Since the key pair is needed to be loaded for unsealing, I need to store it in a
> place so they can latter be used for unsealing.

In theory you can store that anywhere, the easier it is to get to the more prevalent someone
can hose all of your data. The LUKS partition metadata seems reasonable, if they can delete
that, they could hose your hard drive data anyways. A permeant entity in the TPM is also
an option.

> 
> >  and using the
> >> endorsement hierarchy by default.
> >
> > I don't see the privacy concerns offhand, as no one is receiving a digital
> signature from the private key generated?
> 
> That's why I'm storing it in an accessible place, since it can't be used without the
> TPM2. I just wanted to confirm if my understanding of the specs were correct.
> 
> > I think the storage hierarchy is more appropriate, but again I may be missing
> something.
> >
> 
> Can you please elaborate on why do you think the storage hierarchy
> (TPM_RH_OWNER) is more appropriate? That's why I asked the question,
> because reading the specs were not clear to me which one is meant to be used
> for this use case.

I'm basing that on page 107 of, "A Practical guide to TPM 2.0". This seems to be non-sensitive
with respect to how they define privacy, so using the storage hierarchy seems reasonable to
me.

This is all caveated with I am pretty new to TPM as well, so someone more knowledgeable may see
things differently.

> 
> Best regards,
> --
> Javier Martinez Canillas
> Software Engineer - Desktop Hardware Enablement Red Hat

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Javier Martinez Canillas]

[-- Attachment #1: Type: text/plain, Size: 4199 bytes --]

Hello Bill,

Thanks a lot for your feedback.

On 07/31/2017 10:27 PM, Roberts, William C wrote:
> 
> 
>> -----Original Message-----
>> From: tpm2 [mailto:tpm2-bounces(a)lists.01.org] On Behalf Of Javier Martinez
>> Canillas
>> Sent: Wednesday, July 26, 2017 12:25 PM
>> To: tpm2(a)lists.01.org
>> Subject: [tpm2] feedback on unlocking LUKS volumes using a TPM2
>>
>> Hello folks,
>>
>> As mentioned before, I'm exploring on using a TPM2 chip to unlock a root LUKS
>> volume so users don't need to type a passphrase as long as their systems have
>> not been tampered with.
>>
>> Since I'm still new to TPM2, I wanted to share what I did in case people more
>> familiar with the TCG specification could provide their feedback.
>>
>> First some context:
>>
>> We have a plugable framework for automated decryption that's called Clevis [0].
>>
>> Clevis has a number of "pins", where each pin implements an automated
>> decryption support using a different {en,de}cryption backend. It also has
>> infrastructure to {en,de}crypt data, unlock LUKS volumes and create complex
>> security policies.
>>
>> Clevis relies on the José project [1], which is an C implementation of the JOSE
>> (Javascript Object Signing and Encryption) standard [2]. It also uses the LUKSMeta
>> project [3] to bind a pin to a LUKS volume, by storing the JWE (JSON Web
>> Encryption) [4] in the LUKS header so the data can later be decrypted and the
>> volume unlocked.
>>
>> So I created a TPM2 pin [5] for clevis to reuse all this existing infrastructure.
>>
>> But I'm mostly interested for your feedback on the TPM2 bits, what I basically do
>> is something like this:
>>
>> - Create an authorization policy based on a set of PCR ids
>> - Create a primary key
>> - Create an object and pass as data to be sealed a JWK (JSON Web Key) [6] that is
>>   used to encrypt the LUKS volume master key.
>> - Create a JWE that contains the encrypted LUKS key and also information on how
>>   to decrypt it. The information that's needed to unseal the JWK from the TPM2 is:
>>
>>     - hierarchy used for the primary key and object
>>     - the hash and key algorithms used
>>     - PCR bank and ids for policy session
>>     - the public and private key pair for the sealed object
>>
>> The user can choose most of the parameters when using the clevis tpm2 pin, but
>> these are the default used:
>>
>> - Endorsement hierarchy seed for the primary key and sealed object
>> - SHA-256 for primary and object name computation
>> - ECC as algorithm type for generated key
>> - SHA-1 PCR bank for PCR policy
>>
>> Do you think what I described is the correct approach? Specially I would like to
>> know your opinion about storing not only the pub but also the priv key in the
>> LUKS volume header (since both are needed for unsealing)
> 
> I'm not following what you're saying about storing the keypair here for unsealing, shouldn't those keys
> be generated in the tpm and bound to a pcr policy?
>

Yes, maybe I'm failing in the terminology. My understanding is that the TPM2 on
TPM2_Create() creates a key pair, seals the passed data using this key, wraps
the key using the parent key and finally returns that wrapped key pair to caller.

Since the key pair is needed to be loaded for unsealing, I need to store it in a
place so they can latter be used for unsealing.
 
>  and using the
>> endorsement hierarchy by default.
> 
> I don't see the privacy concerns offhand, as no one is receiving a digital signature from the private key generated?

That's why I'm storing it in an accessible place, since it can't be used without
the TPM2. I just wanted to confirm if my understanding of the specs were correct.

> I think the storage hierarchy is more appropriate, but again I may be missing something.
> 

Can you please elaborate on why do you think the storage hierarchy (TPM_RH_OWNER)
is more appropriate? That's why I asked the question, because reading the specs
were not clear to me which one is meant to be used for this use case.

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat

Re: [tpm2] feedback on unlocking LUKS volumes using a TPM2

[Roberts, William C]

[-- Attachment #1: Type: text/plain, Size: 3733 bytes --]



> -----Original Message-----
> From: tpm2 [mailto:tpm2-bounces(a)lists.01.org] On Behalf Of Javier Martinez
> Canillas
> Sent: Wednesday, July 26, 2017 12:25 PM
> To: tpm2(a)lists.01.org
> Subject: [tpm2] feedback on unlocking LUKS volumes using a TPM2
> 
> Hello folks,
> 
> As mentioned before, I'm exploring on using a TPM2 chip to unlock a root LUKS
> volume so users don't need to type a passphrase as long as their systems have
> not been tampered with.
> 
> Since I'm still new to TPM2, I wanted to share what I did in case people more
> familiar with the TCG specification could provide their feedback.
> 
> First some context:
> 
> We have a plugable framework for automated decryption that's called Clevis [0].
> 
> Clevis has a number of "pins", where each pin implements an automated
> decryption support using a different {en,de}cryption backend. It also has
> infrastructure to {en,de}crypt data, unlock LUKS volumes and create complex
> security policies.
> 
> Clevis relies on the José project [1], which is an C implementation of the JOSE
> (Javascript Object Signing and Encryption) standard [2]. It also uses the LUKSMeta
> project [3] to bind a pin to a LUKS volume, by storing the JWE (JSON Web
> Encryption) [4] in the LUKS header so the data can later be decrypted and the
> volume unlocked.
> 
> So I created a TPM2 pin [5] for clevis to reuse all this existing infrastructure.
> 
> But I'm mostly interested for your feedback on the TPM2 bits, what I basically do
> is something like this:
> 
> - Create an authorization policy based on a set of PCR ids
> - Create a primary key
> - Create an object and pass as data to be sealed a JWK (JSON Web Key) [6] that is
>   used to encrypt the LUKS volume master key.
> - Create a JWE that contains the encrypted LUKS key and also information on how
>   to decrypt it. The information that's needed to unseal the JWK from the TPM2 is:
> 
>     - hierarchy used for the primary key and object
>     - the hash and key algorithms used
>     - PCR bank and ids for policy session
>     - the public and private key pair for the sealed object
> 
> The user can choose most of the parameters when using the clevis tpm2 pin, but
> these are the default used:
> 
> - Endorsement hierarchy seed for the primary key and sealed object
> - SHA-256 for primary and object name computation
> - ECC as algorithm type for generated key
> - SHA-1 PCR bank for PCR policy
> 
> Do you think what I described is the correct approach? Specially I would like to
> know your opinion about storing not only the pub but also the priv key in the
> LUKS volume header (since both are needed for unsealing)

I'm not following what you're saying about storing the keypair here for unsealing, shouldn't those keys
be generated in the tpm and bound to a pcr policy?

 and using the
> endorsement hierarchy by default.

I don't see the privacy concerns offhand, as no one is receiving a digital signature from the private key generated?
I think the storage hierarchy is more appropriate, but again I may be missing something.

> 
> Thanks a lot!
> 
> [0]: https://github.com/latchset/clevis
> [1]: https://github.com/latchset/jose
> [2]: https://www.ietf.org/wg/concluded/jose
> [3]: https://github.com/latchset/luksmeta
> [4]: https://tools.ietf.org/html/rfc7516
> [5]: https://github.com/latchset/clevis/pull/17
> [6]: https://tools.ietf.org/html/rfc7517
> 
> Best regards,
> --
> Javier Martinez Canillas
> Software Engineer - Desktop Hardware Enablement Red Hat
> _______________________________________________
> tpm2 mailing list
> tpm2(a)lists.01.org
> https://lists.01.org/mailman/listinfo/tpm2

[tpm2] feedback on unlocking LUKS volumes using a TPM2

[Javier Martinez Canillas]

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]

Hello folks,

As mentioned before, I'm exploring on using a TPM2 chip to unlock a root LUKS
volume so users don't need to type a passphrase as long as their systems have
not been tampered with.

Since I'm still new to TPM2, I wanted to share what I did in case people more
familiar with the TCG specification could provide their feedback.

First some context:

We have a plugable framework for automated decryption that's called Clevis [0].

Clevis has a number of "pins", where each pin implements an automated decryption
support using a different {en,de}cryption backend. It also has infrastructure to
{en,de}crypt data, unlock LUKS volumes and create complex security policies.

Clevis relies on the José project [1], which is an C implementation of the JOSE
(Javascript Object Signing and Encryption) standard [2]. It also uses the LUKSMeta
project [3] to bind a pin to a LUKS volume, by storing the JWE (JSON Web Encryption)
[4] in the LUKS header so the data can later be decrypted and the volume unlocked.

So I created a TPM2 pin [5] for clevis to reuse all this existing infrastructure.

But I'm mostly interested for your feedback on the TPM2 bits, what I basically do
is something like this:

- Create an authorization policy based on a set of PCR ids
- Create a primary key
- Create an object and pass as data to be sealed a JWK (JSON Web Key) [6] that is
  used to encrypt the LUKS volume master key.
- Create a JWE that contains the encrypted LUKS key and also information on how
  to decrypt it. The information that's needed to unseal the JWK from the TPM2 is:

    - hierarchy used for the primary key and object
    - the hash and key algorithms used
    - PCR bank and ids for policy session
    - the public and private key pair for the sealed object

The user can choose most of the parameters when using the clevis tpm2 pin, but
these are the default used:

- Endorsement hierarchy seed for the primary key and sealed object
- SHA-256 for primary and object name computation
- ECC as algorithm type for generated key
- SHA-1 PCR bank for PCR policy

Do you think what I described is the correct approach? Specially I would like
to know your opinion about storing not only the pub but also the priv key in
the LUKS volume header (since both are needed for unsealing) and using the
endorsement hierarchy by default.

Thanks a lot!

[0]: https://github.com/latchset/clevis
[1]: https://github.com/latchset/jose
[2]: https://www.ietf.org/wg/concluded/jose
[3]: https://github.com/latchset/luksmeta
[4]: https://tools.ietf.org/html/rfc7516
[5]: https://github.com/latchset/clevis/pull/17
[6]: https://tools.ietf.org/html/rfc7517

Best regards,
-- 
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat