[dm-crypt] LUKS/cryptsetup with HSM

[dm-crypt] LUKS/cryptsetup with HSM

[Sharma, Manjari]

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

Hi Cryptsetup team,

This is Manjari Sharma from SafeNet. SafeNet is the largest company exclusively focused on the protection of high-value information assets. I'm trying to integrate our HSM with LUKS so that the encryption keys are protected in an HSM.

Could you please help to provide some pointer. I could not find anything relevant after searching for hours, all I can be assured of is that it can be done.

Your help would be highly appreciated.

Thanks,

Kind Regards,
Manjari

The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.

\r

[-- Attachment #2: Type: text/html, Size: 2845 bytes --]

Re: [dm-crypt] LUKS/cryptsetup with HSM

[Arno Wagner]

Hi,

you cannot protect the encryption keys in an HSM. To be effective,
they need to be known to the kernel and are hence exposed to
root, see also FAQ Item 6.10. This is a fundamental limitation 
of software-nased encryption. 

Or maybe you want to _store_ the _passphrases_ in an HSM when not 
in use? In that case youmay want to feed them to cryptsetup via 
stdin, as described in the man-page.

Arno



On Thu, Mar 06, 2014 at 08:17:59 CET, Sharma, Manjari wrote:
> Hi Cryptsetup team,
> 
> This is Manjari Sharma from SafeNet. SafeNet is the largest company
> exclusively focused on the protection of high-value information assets. 
> I'm trying to integrate our HSM with LUKS so that the encryption keys are
> protected in an HSM.
> 
> Could you please help to provide some pointer. I could not find anything
> relevant after searching for hours, all I can be assured of is that it can
> be done.
> 
> Your help would be highly appreciated.
> 
> Thanks,
> 
> Kind Regards,
> Manjari
> 
> The information contained in this electronic mail transmission 
> may be privileged and confidential, and therefore, protected 
> from disclosure. If you have received this communication in 
> error, please notify us immediately by replying to this 
> message and deleting it from your computer without copying 
> or disclosing it.
> 
> 

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] LUKS/cryptsetup with HSM

[Alex Elsayed]

That may not be strictly true going forward - in particular, the combination 
of the keyctl API (see "trusted keys"[1]) and the "trusted kernel" work[2] 
(or possibly whatever name Phoronix comes up with if someone thinks Matthew 
Garrett is bluffing) mean that "known to the kernel" == "accessible to root" 
may not always hold.

An alternate dmsetup syntax that uses a key in a kernel-side keyring might 
be all that's needed for such a thing.

[1] 
https://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/tree/Documentation/security/keys-trusted-encrypted.txt
[2] http://thread.gmane.org/gmane.linux.kernel/1656312

Arno Wagner wrote:

> Hi,
> 
> you cannot protect the encryption keys in an HSM. To be effective,
> they need to be known to the kernel and are hence exposed to
> root, see also FAQ Item 6.10. This is a fundamental limitation
> of software-nased encryption.
> 
> Or maybe you want to _store_ the _passphrases_ in an HSM when not
> in use? In that case youmay want to feed them to cryptsetup via
> stdin, as described in the man-page.
> 
> Arno
> 
> 
> 
> On Thu, Mar 06, 2014 at 08:17:59 CET, Sharma, Manjari wrote:
>> Hi Cryptsetup team,
>> 
>> This is Manjari Sharma from SafeNet. SafeNet is the largest company
>> exclusively focused on the protection of high-value information assets.
>> I'm trying to integrate our HSM with LUKS so that the encryption keys are
>> protected in an HSM.
>> 
>> Could you please help to provide some pointer. I could not find anything
>> relevant after searching for hours, all I can be assured of is that it
>> can be done.
>> 
>> Your help would be highly appreciated.
>> 
>> Thanks,
>> 
>> Kind Regards,
>> Manjari
>> 
>> The information contained in this electronic mail transmission
>> may be privileged and confidential, and therefore, protected
>> from disclosure. If you have received this communication in
>> error, please notify us immediately by replying to this
>> message and deleting it from your computer without copying
>> or disclosing it.
>> 
>> 
> 
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> 

Re: [dm-crypt] LUKS/cryptsetup with HSM

[Arno Wagner]

On Sun, Mar 09, 2014 at 21:45:38 CET, Alex Elsayed wrote:
> That may not be strictly true going forward - in particular, the combination 
> of the keyctl API (see "trusted keys"[1]) and the "trusted kernel" work[2] 
> (or possibly whatever name Phoronix comes up with if someone thinks Matthew 
> Garrett is bluffing) mean that "known to the kernel" == "accessible to root" 
> may not always hold.

True, but doing that would be exceedingly stupid. 

For one thing, unless you have hardware-based encryption that does not 
allow reading of the key-setup and keys are transported in there in 
encrypted form only, root _can_ get the keys, it would just be a little 
more effort. (Backgroung: A TPM is not a high-performance encryption 
module that you could pass all your HDD accessses through...)

Second, a key generated and protected by a TPM does not allow backup. 
(Or if it does, security is lost in a single-user scenario.) Suddenly 
access to all your data depends on your TPM surviving. It dies, all 
your data is lost. (Who here had a mainboard die? Right.) Not even 
remotely professional. Also, if you do not have a TPM, you just need 
to patch your kernel to get full access, and the protection-level 
without TPM is laughable. Do not even get me started on what is wrong
with requiring vendor-signed kernel binaries.

Third, the single system security perimeter in a UNIX system is the 
protection of root. Comprimising root's ability to get at everything 
compromises the UNIX protection model.

It also does not work with LUKS, as the master-key is in the header.
If you insist shooting yourself in the foot by having a single-device
dependency for access to your crypto-keys, LUKS does not support you 
in that. 

Not that I have not seen a lot of utter stupidity going on in the 
Linux space recently. This is just one more instance of people
that do not get it.
 
Now, what does a proper HSM do here to prevent the single-device 
dependency (which is an absolute faux pas in professional IT)?
Simple: It can store the key on secure smartcards with a threshold
scheme. For example, you have 8 smartcards, and 5 are needed to
reconstruct the key on a different instance of a HSM from the same
vendor. (Still a single-vendor dependency, but at least you can
put 2 or so HSMs in storage for use in emergency data recovery, and 
this is being done in practice.) The 8 smartcards get into safes 
under the authority of different people in different places and 
knowledge who has these smartcards gets restricted. This gives 
you a pretty good key backup. Note that the distribution of the 
key over several people is absolutely critical for security.
Also note that nothing of the distribution goes over the net
or via software. The 8 smartcards all have to go into a smartcard
reader that is part of the protected HSM.

The take-away message is that hardware-based security is neither
cheap nor easy to do and that a TPM is basically only suitable to
enforce DRM and the like, but is not a real HSM at all. 

> An alternate dmsetup syntax that uses a key in a kernel-side keyring might 
> be all that's needed for such a thing.

"may". With great restrictions and an unacceptable reliability and
security model. 

Arno
 
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/tree/Documentation/security/keys-trusted-encrypted.txt
> [2] http://thread.gmane.org/gmane.linux.kernel/1656312
> 
> Arno Wagner wrote:
> 
> > Hi,
> > 
> > you cannot protect the encryption keys in an HSM. To be effective,
> > they need to be known to the kernel and are hence exposed to
> > root, see also FAQ Item 6.10. This is a fundamental limitation
> > of software-nased encryption.
> > 
> > Or maybe you want to _store_ the _passphrases_ in an HSM when not
> > in use? In that case youmay want to feed them to cryptsetup via
> > stdin, as described in the man-page.
> > 
> > Arno
> > 
> > 
> > 
> > On Thu, Mar 06, 2014 at 08:17:59 CET, Sharma, Manjari wrote:
> >> Hi Cryptsetup team,
> >> 
> >> This is Manjari Sharma from SafeNet. SafeNet is the largest company
> >> exclusively focused on the protection of high-value information assets.
> >> I'm trying to integrate our HSM with LUKS so that the encryption keys are
> >> protected in an HSM.
> >> 
> >> Could you please help to provide some pointer. I could not find anything
> >> relevant after searching for hours, all I can be assured of is that it
> >> can be done.
> >> 
> >> Your help would be highly appreciated.
> >> 
> >> Thanks,
> >> 
> >> Kind Regards,
> >> Manjari
> >> 
> >> The information contained in this electronic mail transmission
> >> may be privileged and confidential, and therefore, protected
> >> from disclosure. If you have received this communication in
> >> error, please notify us immediately by replying to this
> >> message and deleting it from your computer without copying
> >> or disclosing it.
> >> 
> >> 
> > 
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> > 
> > 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] LUKS/cryptsetup with HSM

[Arno Wagner]

Oh, and before I forget: With a TPM as key-storage, you are
completely at the mercy of the hardware manufacturer. How bad 
an idea that is can be nicely seen in the recent discussion of
Intel trying to forece use of RDRAND as the only randomness 
source in the Linux kernel:

https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J

Arno


On Sun, Mar 09, 2014 at 22:57:36 CET, Arno Wagner wrote:
> On Sun, Mar 09, 2014 at 21:45:38 CET, Alex Elsayed wrote:
> > That may not be strictly true going forward - in particular, the combination 
> > of the keyctl API (see "trusted keys"[1]) and the "trusted kernel" work[2] 
> > (or possibly whatever name Phoronix comes up with if someone thinks Matthew 
> > Garrett is bluffing) mean that "known to the kernel" == "accessible to root" 
> > may not always hold.
> 
> True, but doing that would be exceedingly stupid. 
> 
> For one thing, unless you have hardware-based encryption that does not 
> allow reading of the key-setup and keys are transported in there in 
> encrypted form only, root _can_ get the keys, it would just be a little 
> more effort. (Backgroung: A TPM is not a high-performance encryption 
> module that you could pass all your HDD accessses through...)
> 
> Second, a key generated and protected by a TPM does not allow backup. 
> (Or if it does, security is lost in a single-user scenario.) Suddenly 
> access to all your data depends on your TPM surviving. It dies, all 
> your data is lost. (Who here had a mainboard die? Right.) Not even 
> remotely professional. Also, if you do not have a TPM, you just need 
> to patch your kernel to get full access, and the protection-level 
> without TPM is laughable. Do not even get me started on what is wrong
> with requiring vendor-signed kernel binaries.
> 
> Third, the single system security perimeter in a UNIX system is the 
> protection of root. Comprimising root's ability to get at everything 
> compromises the UNIX protection model.
> 
> It also does not work with LUKS, as the master-key is in the header.
> If you insist shooting yourself in the foot by having a single-device
> dependency for access to your crypto-keys, LUKS does not support you 
> in that. 
> 
> Not that I have not seen a lot of utter stupidity going on in the 
> Linux space recently. This is just one more instance of people
> that do not get it.
>  
> Now, what does a proper HSM do here to prevent the single-device 
> dependency (which is an absolute faux pas in professional IT)?
> Simple: It can store the key on secure smartcards with a threshold
> scheme. For example, you have 8 smartcards, and 5 are needed to
> reconstruct the key on a different instance of a HSM from the same
> vendor. (Still a single-vendor dependency, but at least you can
> put 2 or so HSMs in storage for use in emergency data recovery, and 
> this is being done in practice.) The 8 smartcards get into safes 
> under the authority of different people in different places and 
> knowledge who has these smartcards gets restricted. This gives 
> you a pretty good key backup. Note that the distribution of the 
> key over several people is absolutely critical for security.
> Also note that nothing of the distribution goes over the net
> or via software. The 8 smartcards all have to go into a smartcard
> reader that is part of the protected HSM.
> 
> The take-away message is that hardware-based security is neither
> cheap nor easy to do and that a TPM is basically only suitable to
> enforce DRM and the like, but is not a real HSM at all. 
> 
> > An alternate dmsetup syntax that uses a key in a kernel-side keyring might 
> > be all that's needed for such a thing.
> 
> "may". With great restrictions and an unacceptable reliability and
> security model. 
> 
> Arno
>  
> > [1] 
> > https://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/tree/Documentation/security/keys-trusted-encrypted.txt
> > [2] http://thread.gmane.org/gmane.linux.kernel/1656312
> > 
> > Arno Wagner wrote:
> > 
> > > Hi,
> > > 
> > > you cannot protect the encryption keys in an HSM. To be effective,
> > > they need to be known to the kernel and are hence exposed to
> > > root, see also FAQ Item 6.10. This is a fundamental limitation
> > > of software-nased encryption.
> > > 
> > > Or maybe you want to _store_ the _passphrases_ in an HSM when not
> > > in use? In that case youmay want to feed them to cryptsetup via
> > > stdin, as described in the man-page.
> > > 
> > > Arno
> > > 
> > > 
> > > 
> > > On Thu, Mar 06, 2014 at 08:17:59 CET, Sharma, Manjari wrote:
> > >> Hi Cryptsetup team,
> > >> 
> > >> This is Manjari Sharma from SafeNet. SafeNet is the largest company
> > >> exclusively focused on the protection of high-value information assets.
> > >> I'm trying to integrate our HSM with LUKS so that the encryption keys are
> > >> protected in an HSM.
> > >> 
> > >> Could you please help to provide some pointer. I could not find anything
> > >> relevant after searching for hours, all I can be assured of is that it
> > >> can be done.
> > >> 
> > >> Your help would be highly appreciated.
> > >> 
> > >> Thanks,
> > >> 
> > >> Kind Regards,
> > >> Manjari
> > >> 
> > >> The information contained in this electronic mail transmission
> > >> may be privileged and confidential, and therefore, protected
> > >> from disclosure. If you have received this communication in
> > >> error, please notify us immediately by replying to this
> > >> message and deleting it from your computer without copying
> > >> or disclosing it.
> > >> 
> > >> 
> > > 
> > >> _______________________________________________
> > >> dm-crypt mailing list
> > >> dm-crypt@saout.de
> > >> http://www.saout.de/mailman/listinfo/dm-crypt
> > > 
> > > 
> > 
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> 
> -- 
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
> ----
> A good decision is based on knowledge and not on numbers. -  Plato
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato

Re: [dm-crypt] LUKS/cryptsetup with HSM

[Alex Elsayed]

I'm going to go point-by-point on this; response inline.

Arno Wagner wrote:

> Oh, and before I forget: With a TPM as key-storage, you are
> completely at the mercy of the hardware manufacturer. How bad
> an idea that is can be nicely seen in the recent discussion of
> Intel trying to forece use of RDRAND as the only randomness
> source in the Linux kernel:
> 
> https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J
> 
> Arno

This, I am in complete agreement on... for closed hardware. However, I 
firmly believe that "the perfect is the enemy of the good". An open-hardware 
device doing something similar to a TPM (even over the same APIs, perhaps) 
would resolve the above, and would be a useful tool - and while no software-
based encryption will be able to conceal the key as completely as hardware-
based encryption, hybrid approaches can increase the cost metric.

> On Sun, Mar 09, 2014 at 22:57:36 CET, Arno Wagner wrote:
>> On Sun, Mar 09, 2014 at 21:45:38 CET, Alex Elsayed wrote:
>> > That may not be strictly true going forward - in particular, the
>> > combination of the keyctl API (see "trusted keys"[1]) and the "trusted
>> > kernel" work[2] (or possibly whatever name Phoronix comes up with if
>> > someone thinks Matthew Garrett is bluffing) mean that "known to the
>> > kernel" == "accessible to root" may not always hold.
>> 
>> True, but doing that would be exceedingly stupid.

Yes and no. It may not provide the full benefit of fully hardware-based 
encryption (as long as that is open-hardware, or it's _just as bad_ by your 
above point), but it _can_ improve some properties over purely-software 
approaches. Hybrid techniques can be valuable because an incremental 
improvement is still an improvement. 'Perfect' isn't a goal; it's a 
strawman. 'Better' is a goal.

>> For one thing, unless you have hardware-based encryption that does not
>> allow reading of the key-setup and keys are transported in there in
>> encrypted form only, root _can_ get the keys, it would just be a little
>> more effort. (Backgroung: A TPM is not a high-performance encryption
>> module that you could pass all your HDD accessses through...)

The "trusted keys" API means that the key is never seen in an unsealed state 
by userspace - that mitigates a various avenues to obtain it. See below 
regarding "incompatible with LUKS" for further explanation.

>> Second, a key generated and protected by a TPM does not allow backup.
>> (Or if it does, security is lost in a single-user scenario.) Suddenly
>> access to all your data depends on your TPM surviving. It dies, all
>> your data is lost. (Who here had a mainboard die? Right.) Not even
>> remotely professional. Also, if you do not have a TPM, you just need
>> to patch your kernel to get full access, and the protection-level
>> without TPM is laughable. Do not even get me started on what is wrong
>> with requiring vendor-signed kernel binaries.

Um, keyslots. There's always the flexibility to kick out the TPM key, and 
even resolve the old "can't move TPM-encrypted drives between machines" 
issue by creating a new keyslot, sealed with the new machine's TPM. Heck, 
also add a completely non-TPM one you keep on a thumb drive in a safe 
deposit box for unexpected machine failure.

>> Third, the single system security perimeter in a UNIX system is the
>> protection of root. Comprimising root's ability to get at everything
>> compromises the UNIX protection model.

Not wholly correct - in the presence of virtualization, particularly 
container-based virtualization, this has long been untrue.

In addition, your wireless card is almost certainly running an RTOS on an 
embedded ARM and your motherboard may have IPMI in which case it also has 
its own OS (The one on an ASUS board I have is a tiny Linux system on a 
cramfs, in fact. It has SSH running.). So if your assertion is wholly true, 
it's rather thoroughly compromised already.

The distinction made with the trusted keys/trusted kernel stuff is between 
root (which may be anyone who can manage a privilege escalation attack) and 
owner-with-physical-access.

>> It also does not work with LUKS, as the master-key is in the header.
>> If you insist shooting yourself in the foot by having a single-device
>> dependency for access to your crypto-keys, LUKS does not support you
>> in that.

Not really. There are a number of ways to integrate it - Currently, we 
derive the slot key, and use it to decrypt a copy of the master key. If the 
_copy which the slot key decrypts_ is sealed, you load it into the kernel's 
keyring and reference it on the dmsetup line. That permits it to be per-
keyslot, work with passphrases and keyfiles without a care in the world, and 
still prevent the master key from ever being exposed to userspace in the 
clear during normal operation. Even adding another TPM-locked keyslot 
wouldn't need the raw key, since the kernel permits exporting trusted keys 
in their sealed form - you just do that, encrypt with the new slot key, and 
you're golden. Making a new _non_-tpm-locked slot would require the key be 
in the clear, but that's a pretty obvious consequence of it being non-tpm-
locked.

>> Not that I have not seen a lot of utter stupidity going on in the
>> Linux space recently. This is just one more instance of people
>> that do not get it.

I suppose we'll just have to disagree there.

>> Now, what does a proper HSM do here to prevent the single-device
>> dependency (which is an absolute faux pas in professional IT)?
>> Simple: It can store the key on secure smartcards with a threshold
>> scheme. For example, you have 8 smartcards, and 5 are needed to
>> reconstruct the key on a different instance of a HSM from the same
>> vendor. (Still a single-vendor dependency, but at least you can
>> put 2 or so HSMs in storage for use in emergency data recovery, and
>> this is being done in practice.) The 8 smartcards get into safes
>> under the authority of different people in different places and
>> knowledge who has these smartcards gets restricted. This gives
>> you a pretty good key backup. Note that the distribution of the
>> key over several people is absolutely critical for security.
>> Also note that nothing of the distribution goes over the net
>> or via software. The 8 smartcards all have to go into a smartcard
>> reader that is part of the protected HSM.

Yes, but the above that I describe can also be used as such. After all: what 
I describe isn't "just use the TPM"; it's "use the TPM as _a second 
factor_". The first factor - the keyfile needed to even get at the sealed 
copy of the master key - can use such a system if you want.

Besides, since what I described _is_ compatible with keyslots, you're still 
not subject to lock-in.

>> The take-away message is that hardware-based security is neither
>> cheap nor easy to do and that a TPM is basically only suitable to
>> enforce DRM and the like, but is not a real HSM at all.

A hardwired smartcard with the ability to chain assertions is useful for a 
good deal more than that.

>> > An alternate dmsetup syntax that uses a key in a kernel-side keyring
>> > might be all that's needed for such a thing.
>> 
>> "may". With great restrictions and an unacceptable reliability and
>> security model.

I hope my above points show that the restrictions, reliability, and security 
model can be somewhat better than that.

>> Arno
>>  
>> > [1]
>> > 
https://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/tree/Documentation/security/keys-trusted-encrypted.txt
>> > [2] http://thread.gmane.org/gmane.linux.kernel/1656312
>> > 
>> > Arno Wagner wrote:
>> > 
>> > > Hi,
>> > > 
>> > > you cannot protect the encryption keys in an HSM. To be effective,
>> > > they need to be known to the kernel and are hence exposed to
>> > > root, see also FAQ Item 6.10. This is a fundamental limitation
>> > > of software-nased encryption.
>> > > 
>> > > Or maybe you want to _store_ the _passphrases_ in an HSM when not
>> > > in use? In that case youmay want to feed them to cryptsetup via
>> > > stdin, as described in the man-page.
>> > > 
>> > > Arno
>> > > 
>> > > 
>> > > 
>> > > On Thu, Mar 06, 2014 at 08:17:59 CET, Sharma, Manjari wrote:
>> > >> Hi Cryptsetup team,
>> > >> 
>> > >> This is Manjari Sharma from SafeNet. SafeNet is the largest company
>> > >> exclusively focused on the protection of high-value information
>> > >> assets. I'm trying to integrate our HSM with LUKS so that the
>> > >> encryption keys are protected in an HSM.
>> > >> 
>> > >> Could you please help to provide some pointer. I could not find
>> > >> anything relevant after searching for hours, all I can be assured of
>> > >> is that it can be done.
>> > >> 
>> > >> Your help would be highly appreciated.
>> > >> 
>> > >> Thanks,
>> > >> 
>> > >> Kind Regards,
>> > >> Manjari
>> > >> 
>> > >> The information contained in this electronic mail transmission
>> > >> may be privileged and confidential, and therefore, protected
>> > >> from disclosure. If you have received this communication in
>> > >> error, please notify us immediately by replying to this
>> > >> message and deleting it from your computer without copying
>> > >> or disclosing it.
>> > >> 
>> > >> 
>> > > 
>> > >> _______________________________________________
>> > >> dm-crypt mailing list
>> > >> dm-crypt@saout.de
>> > >> http://www.saout.de/mailman/listinfo/dm-crypt
>> > > 
>> > > 
>> > 
>> > _______________________________________________
>> > dm-crypt mailing list
>> > dm-crypt@saout.de
>> > http://www.saout.de/mailman/listinfo/dm-crypt
>> 
>> --
>> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email:
>> arno@wagner.name
>> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D
>> 9718 ----
>> A good decision is based on knowledge and not on numbers. -  Plato
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] LUKS/cryptsetup with HSM

[Arno Wagner]

On Tue, Mar 11, 2014 at 00:49:11 CET, Alex Elsayed wrote:
[...]
> >> For one thing, unless you have hardware-based encryption that does not
> >> allow reading of the key-setup and keys are transported in there in
> >> encrypted form only, root _can_ get the keys, it would just be a little
> >> more effort. (Backgroung: A TPM is not a high-performance encryption
> >> module that you could pass all your HDD accessses through...)
> 
> The "trusted keys" API means that the key is never seen in an unsealed
> state by userspace - that mitigates a various avenues to obtain it.  See
> below regarding "incompatible with LUKS" for further explanation.

I think that is just not true. Or rather the key is never seen by
userspace if userspace does not try to see the key. That is a bit
different.

How are you going to protect the key-setup for software encryption 
(or hardware encryption where you can read the key) from root? As in 
"root that can do arbitrary things to the kernel image and reboot"? 
And don't try to sell me "trusted boot". That one is nonsense.

> >> Second, a key generated and protected by a TPM does not allow backup.
> >> (Or if it does, security is lost in a single-user scenario.) Suddenly
> >> access to all your data depends on your TPM surviving. It dies, all
> >> your data is lost. (Who here had a mainboard die? Right.) Not even
> >> remotely professional. Also, if you do not have a TPM, you just need
> >> to patch your kernel to get full access, and the protection-level
> >> without TPM is laughable. Do not even get me started on what is wrong
> >> with requiring vendor-signed kernel binaries.
> 
> Um, keyslots. There's always the flexibility to kick out the TPM key, and 
> even resolve the old "can't move TPM-encrypted drives between machines" 
> issue by creating a new keyslot, sealed with the new machine's TPM. Heck, 
> also add a completely non-TPM one you keep on a thumb drive in a safe 
> deposit box for unexpected machine failure.

True. But if you do that before your TPM dies, you have lost 
protection because userspcae does get so see the key when
you make that non-TPM keyslot. 

If you do it after the TPM dies... oh, wait.
 
Of course, if done very carefully, this can work. But it strikes 
me as rather hard to get it right. 

> >> Third, the single system security perimeter in a UNIX system is the
> >> protection of root. Comprimising root's ability to get at everything
> >> compromises the UNIX protection model.
> 
> Not wholly correct - in the presence of virtualization, particularly 
> container-based virtualization, this has long been untrue.

One reason why people really concerned about security do not use
virtualization. Or rather are very careful that they have root
on the host system and are secure there and the they can mostly 
trust what is going in in their VMs. I really cannot go into detail 
(sorry, NDAs), but virtualization offers a lot less protection than
most people believe.
 
> In addition, your wireless card is almost certainly running an RTOS on an 
> embedded ARM and your motherboard may have IPMI in which case it also has 
> its own OS (The one on an ASUS board I have is a tiny Linux system on a 
> cramfs, in fact. It has SSH running.). So if your assertion is wholly true, 
> it's rather thoroughly compromised already.

No wireless card in any system I care to be secure and IPMI goes
into a physically seperated LAN on another trusted machine. But
this is a red herring: Viewed from this angle, these things
break the architecture. This is why they need to be regarded
separately. Saying "I have a wireless card or IPMI, so root is
compromised anyways" is not the right approach, even if technically 
true for some scenarios. I even have a JTAG adapter lying around 
here somewhere (never used so far), so technically all my hardware 
is completely compromised. But that is the wrong model.
 
> The distinction made with the trusted keys/trusted kernel stuff is between 
> root (which may be anyone who can manage a privilege escalation attack) and 
> owner-with-physical-access.

And I think it is flawed. Root can do a lot of things that are 
exceedingly hard or impossible to protect against and there is 
a reason root can do that: It is needed. The alternative is a 
locked-down device, where the system administrator is just any 
other user and has to either beg some higher authority for access
or physically go to the hardware. Not good at all. Your server 
is not an XBox.
 
> >> It also does not work with LUKS, as the master-key is in the header.
> >> If you insist shooting yourself in the foot by having a single-device
> >> dependency for access to your crypto-keys, LUKS does not support you
> >> in that.
> 
> Not really. There are a number of ways to integrate it - Currently, we 
> derive the slot key, and use it to decrypt a copy of the master key. If the 
> _copy which the slot key decrypts_ is sealed, you load it into the kernel's 
> keyring and reference it on the dmsetup line. 

So you have a patched version that breaks the LUKS semantics. 
That is not LUKS anymore.

> That permits it to be per- keyslot, work with passphrases and keyfiles
> without a care in the world, and still prevent the master key from ever
> being exposed to userspace in the clear during normal operation.  Even
> adding another TPM-locked keyslot wouldn't need the raw key, since the
> kernel permits exporting trusted keys in their sealed form - you just do
> that, encrypt with the new slot key, and you're golden.  Making a new
> _non_-tpm-locked slot would require the key be in the clear, but that's a
> pretty obvious consequence of it being non-tpm- locked.
> 
> >> Not that I have not seen a lot of utter stupidity going on in the
> >> Linux space recently. This is just one more instance of people
> >> that do not get it.
> 
> I suppose we'll just have to disagree there.

Sure. 
 
> >> Now, what does a proper HSM do here to prevent the single-device
> >> dependency (which is an absolute faux pas in professional IT)?
> >> Simple: It can store the key on secure smartcards with a threshold
> >> scheme. For example, you have 8 smartcards, and 5 are needed to
> >> reconstruct the key on a different instance of a HSM from the same
> >> vendor. (Still a single-vendor dependency, but at least you can
> >> put 2 or so HSMs in storage for use in emergency data recovery, and
> >> this is being done in practice.) The 8 smartcards get into safes
> >> under the authority of different people in different places and
> >> knowledge who has these smartcards gets restricted. This gives
> >> you a pretty good key backup. Note that the distribution of the
> >> key over several people is absolutely critical for security.
> >> Also note that nothing of the distribution goes over the net
> >> or via software. The 8 smartcards all have to go into a smartcard
> >> reader that is part of the protected HSM.
> 
> Yes, but the above that I describe can also be used as such. After all:
> what I describe isn't "just use the TPM"; it's "use the TPM as _a second
> factor_".  The first factor - the keyfile needed to even get at the sealed
> copy of the master key - can use such a system if you want.
> 
> Besides, since what I described _is_ compatible with keyslots, you're still 
> not subject to lock-in.

With hacked key-slot sematics, yes. Not with LUKS key-slot semantics.
 
> >> The take-away message is that hardware-based security is neither
> >> cheap nor easy to do and that a TPM is basically only suitable to
> >> enforce DRM and the like, but is not a real HSM at all.
> 
> A hardwired smartcard with the ability to chain assertions is useful for a 
> good deal more than that.

Are you really sure? My impression is it is not even really suitable
for enforcing DRM. I think the whole TPM idea has been fundamentally
broken from the start as it ignores reality. Sure, locking 
technolocically incompetent users into something, it can do to a 
degree, but for real_ security? If they had put in a high-performance
crypto-engine and had created a secure way to clone keys (e.g.
directly attached special smart-card slot), then we would have
a HSM-like device that is pretty secure as long as the
attacker does not get physical access. But this is an 
ElCheapo chip attached via a very slow interface. AFAIK, the
TPM cannot even detect when it is removed and placed into 
another system. Which is not that hard to do. 
 
> >> > An alternate dmsetup syntax that uses a key in a kernel-side keyring
> >> > might be all that's needed for such a thing.
> >> 
> >> "may". With great restrictions and an unacceptable reliability and
> >> security model.
> 
> I hope my above points show that the restrictions, reliability, and
> security model can be somewhat better than that.

Does not convince me so far. I have admittedly seen a lot of
severe stupidity in this area, up to some people claiming that
a normal "secure" smartcard or even a plain NIC EEPROM was a 
"mini HSM" and basing the security of some really critical 
systems on that.

So I am prejudiced here and extraordinary evidence is required
to convince me. Sorry about that.

Arno

 
> >> Arno
> >>  
> >> > [1]
> >> > 
> https://git.kernel.org/cgit/linux/kernel/git/rusty/linux.git/tree/Documentation/security/keys-trusted-encrypted.txt
> >> > [2] http://thread.gmane.org/gmane.linux.kernel/1656312
> >> > 
> >> > Arno Wagner wrote:
> >> > 
> >> > > Hi,
> >> > > 
> >> > > you cannot protect the encryption keys in an HSM. To be effective,
> >> > > they need to be known to the kernel and are hence exposed to
> >> > > root, see also FAQ Item 6.10. This is a fundamental limitation
> >> > > of software-nased encryption.
> >> > > 
> >> > > Or maybe you want to _store_ the _passphrases_ in an HSM when not
> >> > > in use? In that case youmay want to feed them to cryptsetup via
> >> > > stdin, as described in the man-page.
> >> > > 
> >> > > Arno
> >> > > 
> >> > > 
> >> > > 
> >> > > On Thu, Mar 06, 2014 at 08:17:59 CET, Sharma, Manjari wrote:
> >> > >> Hi Cryptsetup team,
> >> > >> 
> >> > >> This is Manjari Sharma from SafeNet. SafeNet is the largest company
> >> > >> exclusively focused on the protection of high-value information
> >> > >> assets. I'm trying to integrate our HSM with LUKS so that the
> >> > >> encryption keys are protected in an HSM.
> >> > >> 
> >> > >> Could you please help to provide some pointer. I could not find
> >> > >> anything relevant after searching for hours, all I can be assured of
> >> > >> is that it can be done.
> >> > >> 
> >> > >> Your help would be highly appreciated.
> >> > >> 
> >> > >> Thanks,
> >> > >> 
> >> > >> Kind Regards,
> >> > >> Manjari
> >> > >> 
> >> > >> The information contained in this electronic mail transmission
> >> > >> may be privileged and confidential, and therefore, protected
> >> > >> from disclosure. If you have received this communication in
> >> > >> error, please notify us immediately by replying to this
> >> > >> message and deleting it from your computer without copying
> >> > >> or disclosing it.
> >> > >> 
> >> > >> 
> >> > > 
> >> > >> _______________________________________________
> >> > >> dm-crypt mailing list
> >> > >> dm-crypt@saout.de
> >> > >> http://www.saout.de/mailman/listinfo/dm-crypt
> >> > > 
> >> > > 
> >> > 
> >> > _______________________________________________
> >> > dm-crypt mailing list
> >> > dm-crypt@saout.de
> >> > http://www.saout.de/mailman/listinfo/dm-crypt
> >> 
> >> --
> >> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email:
> >> arno@wagner.name
> >> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D
> >> 9718 ----
> >> A good decision is based on knowledge and not on numbers. -  Plato
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> > 
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato