[dm-crypt] Managing wrapped key ciphers with cryptsetup

[dm-crypt] Managing wrapped key ciphers with cryptsetup

[Hendrik Brueckner]

Hi Milan,

thanks for your thoughts.  Let's start a new thread here and
keep some facts from the old one.

On Wed, Apr 26, 2017 at 08:46:38PM +0200, Milan Broz wrote:
> On 04/26/2017 04:45 PM, Hendrik Brueckner wrote:
> > On Tue, Apr 25, 2017 at 07:09:35PM +0200, Sven Eschenberg wrote:
> >> Am 25.04.2017 um 18:30 schrieb Milan Broz:
> >>> On 04/25/2017 06:16 PM, Sven Eschenberg wrote:
> >>>
> >>> Crypto API stores the key in memory as well (even the round keys etc), obviously.
> >>>
> >>> We have already support for kernel keyring in dm-crypt (so the key will
> >>> not be directly visible in dmsetup table), this will be supported in next major
> >>> version of cryptsetup/LUKS.
> >>>
> >>> But as you said, if you have access to the kernel memory, it is there anyway...
> > 
> > a colleague of mine and I investigated in this kind of topic. For strong
> > security, having the clear key accessible in the memory is not an option.
> > Of course, the alternative, is to deal with hardware security modules (HSM)
> > to perform the cryptographic operations by having the clear never leaving
> > the HSM.
> > 
> > We worked on this area and provided some cryptsetup enhancements to support
> > wrapped keys for disk encryption to prevent having keys in clear text in the
> > memory of the operating system.  Recently, we submitted this merge request:
> > https://gitlab.com/cryptsetup/cryptsetup/merge_requests/19
> 
> Anyway, I will handle that merge request later but in short - your
> approach works only IBM zSystem (no other system implements this
> wrapped encryption, so it is very platform specific).

The approach depends on a cipher that supports secure keys where a
"secure key" is a key that is wrapped by the master key of a hardware
security module (HSM).
The merge request introduces a generic interface for dealing and using
these "wrapped key ciphers".  This is not specific to IBM z Systems.

The protected key AES implementation provided by the paes kernel module
is, of course, specific to a HSM: the CryptoExpress cards and some
performance improvements provided by z Systems.  But a paes like module
that uses secure/wrapped keys could be written for any HSM.

> 
> LUKS1 is portable format, we cannot bind the format to specific hardware.

We considered that point in the merge request.  It keeps LUKS1 as a
portable format, there are no changes on the LUKS1 format or header.
Of course, there are some differences when using wrapped keys, but these
have been addressed without affecting the on-disk-format structure.

> 
> So do not expect this to be merged as it is and specifically not to
> LUKS1 format I consider stable and where it major advantage is
> portability among all possible Linux distributions and architectures.

I think that it is necessary to take some time for review and to have
constructive feedback discussions.  Regarding the portability, the
changes do not affect the portability because we had that in mind from
the beginning.

> 
> Anyway the discussion could be interesting.

Of course, I think it is and I would be glad when we can work together
on a solution.

> But I do not think
> the mainframe approach can be applied to low-end systems where this kind
> of FDE is mostly used. The FDE threat model is also usually focused
> to offline systems (stolen disk) so here we do not need to care
> if key is in memory when system is online.

Trying to obtain the key (in its clear text format) from memory is just
one case. The other case, you already mentioned, is about offline disks.
The approach we pursued with wrapped keys is that the wrapped volume
encryption key is stored on the disk instead of its clear text form.
For stolen disks, even if the volume encryption key could be accessed,
it is still wrapped by the HSM's master key.  Hence, access to the HSM
is required to decrypt disk data.


Thanks and kind regards,
   Hendrik

-- 
Hendrik Brueckner
brueckner@linux.vnet.ibm.com      | IBM Deutschland Research & Development GmbH
Linux on z Systems Development    | Schoenaicher Str. 220, 71032 Boeblingen


IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[Sven Eschenberg]

Hi Hendrik,

The protability of the on disk format includes, that I can basicly 
reimplement cryptsetup from scratch, without relying on the current 
status quo. Moreover I even don't need to use kernel crypto stuff at all 
to i.e. create a decrypted image of the data.
Your HSM specific changes would be tied into cryptsetup, but if I 
followed the current specification, and had the corresponding HSM, I 
still would need the 'specifics' regarding the HSM and how to use it, to 
set up the actual mapping.

If you got some spare time:
https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf

If the new format comes to life and allows for plugins, then if I 
reimplemented cryptsetup and had no suiting plugin for a HSM or say a 
cryptocard or whatever, I can not setup the mapping. But I'd know that I 
am prone to fail, since I lack the plugin I am supposed to use.

Now, in contrast, if you hack the HSM supprt into cryptsetup, there's no 
on disk indication and that is not really portable anymore.

Regards

-Sven

Am 27.04.2017 um 17:09 schrieb Hendrik Brueckner:
> Hi Milan,
>
>>
>> LUKS1 is portable format, we cannot bind the format to specific hardware.
>
> We considered that point in the merge request.  It keeps LUKS1 as a
> portable format, there are no changes on the LUKS1 format or header.
> Of course, there are some differences when using wrapped keys, but these
> have been addressed without affecting the on-disk-format structure.
>
>
> Thanks and kind regards,
>    Hendrik
>

Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[Arno Wagner]

I think hardware-specific stuff has no place in cryptsetup.
Get a kernel-driver and then create a wrapper that feeds
the key to cryptsetup, anything else is a bad design.

And if you want a system that is secure against root, then 
do not use Linux. Seriously.

Regards,
Arno


On Thu, Apr 27, 2017 at 22:06:35 CEST, Sven Eschenberg wrote:
> Hi Hendrik,
> 
> The protability of the on disk format includes, that I can basicly
> reimplement cryptsetup from scratch, without relying on the current status
> quo. Moreover I even don't need to use kernel crypto stuff at all to i.e.
> create a decrypted image of the data.
> Your HSM specific changes would be tied into cryptsetup, but if I followed
> the current specification, and had the corresponding HSM, I still would need
> the 'specifics' regarding the HSM and how to use it, to set up the actual
> mapping.
> 
> If you got some spare time:
> https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf
> 
> If the new format comes to life and allows for plugins, then if I
> reimplemented cryptsetup and had no suiting plugin for a HSM or say a
> cryptocard or whatever, I can not setup the mapping. But I'd know that I am
> prone to fail, since I lack the plugin I am supposed to use.
> 
> Now, in contrast, if you hack the HSM supprt into cryptsetup, there's no on
> disk indication and that is not really portable anymore.
> 
> Regards
> 
> -Sven
> 
> Am 27.04.2017 um 17:09 schrieb Hendrik Brueckner:
> >Hi Milan,
> >
> >>
> >>LUKS1 is portable format, we cannot bind the format to specific hardware.
> >
> >We considered that point in the merge request.  It keeps LUKS1 as a
> >portable format, there are no changes on the LUKS1 format or header.
> >Of course, there are some differences when using wrapped keys, but these
> >have been addressed without affecting the on-disk-format structure.
> >
> >
> >Thanks and kind regards,
> >   Hendrik
> >
> _______________________________________________
> 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

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[Hendrik Brueckner]

On Fri, Apr 28, 2017 at 09:22:22AM +0200, Arno Wagner wrote:
> I think hardware-specific stuff has no place in cryptsetup.
> Get a kernel-driver and then create a wrapper that feeds
> the key to cryptsetup, anything else is a bad design.

That's actually what we did with the paes reference implementation.
There are kernel drivers that abstract the HSM-specifics.  From a
user perspective, for example, cryptsetup, the secure (wrapped) key
is passed to the paes cipher (in-kernel crypto API).  The paes cipher
uses information from the secure key to find a HSM that is capable
to perform crypto operations with that key. There is no need for the
user to perform any HSM action.

I am about to reply on Sven's mail, covering some more details that
I do not want to repeat here.

> 
> And if you want a system that is secure against root, then 
> do not use Linux. Seriously.

Of course, if users becomes root (or gain superuser capabilities),
they are able to access the data and obtain the wrapped key.
Secure keys (the wrapped keys with that we deal) cannot be un-wrapped.
That means, at least, root cannot obtain the inner clear key.

So with the wrapped key concept, you can harden your environment against
offline attacks.  With the wrapped key support, you also get a
2-factor-authorization for free: there is something to know,
that's the passphrase, and there is something you own, that's the HSM.
Only if both factors are there, you can decrypt the data.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueckner@linux.vnet.ibm.com      | IBM Deutschland Research & Development GmbH
Linux on z Systems Development    | Schoenaicher Str. 220, 71032 Boeblingen

Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[Arno Wagner]

On Mon, May 15, 2017 at 15:56:54 CEST, Hendrik Brueckner wrote:
> On Fri, Apr 28, 2017 at 09:22:22AM +0200, Arno Wagner wrote:
> > I think hardware-specific stuff has no place in cryptsetup.
> > Get a kernel-driver and then create a wrapper that feeds
> > the key to cryptsetup, anything else is a bad design.
> 
> That's actually what we did with the paes reference implementation.
> There are kernel drivers that abstract the HSM-specifics.  From a
> user perspective, for example, cryptsetup, the secure (wrapped) key
> is passed to the paes cipher (in-kernel crypto API).  The paes cipher
> uses information from the secure key to find a HSM that is capable
> to perform crypto operations with that key. There is no need for the
> user to perform any HSM action.
> 
> I am about to reply on Sven's mail, covering some more details that
> I do not want to repeat here.

Ok, I will try to answer to that one then.
 
> > And if you want a system that is secure against root, then 
> > do not use Linux. Seriously.
> 
> Of course, if users becomes root (or gain superuser capabilities),
> they are able to access the data and obtain the wrapped key.
> Secure keys (the wrapped keys with that we deal) cannot be un-wrapped.
> That means, at least, root cannot obtain the inner clear key.
> 
> So with the wrapped key concept, you can harden your environment against
> offline attacks.  

I don't think so. LUKS does that pretty well already and unless
there is some major flaw in it, offline attacks should be infeasible.

That is unless somebody uses a laughably simple passphrase that is.
But anybody that does that will do other things that break security
as well from my experience. So I have to admit I do not see the
point. (Well, I do see the point, because people that do these
stupid things may still buy a HSM and actually be a bit more 
secure for it...)


> With the wrapped key support, you also get a
> 2-factor-authorization for free: there is something to know,
> that's the passphrase, and there is something you own, that's the HSM.
> Only if both factors are there, you can decrypt the data.

Yes, that works. But why use LUKS here? In order to get the most
of the HSM, the HSM actually needs to do the decryption itself 
and all the LUKS header and key-slot overhead is redundant or 
may even make things less reliable.

In particular, LUKS has this hard requirement that you need 
header backups to be reliable. A HSM does usually have its
of backup-scheme (often k-out-of-n chipcards or the like) and
when integrating with LUKS, that suddently may not be enough 
anymore.

Why not just implement your own tool that has a cryptsetup 
compatible commandline syntax? That would still give you
the Linux integration and I think that may serve your 
purpose better. You would also not be dependent on 
cryptsetup for any API changes in your drivers.

Regards,
Arno
-- 
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

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[Hendrik Brueckner]

Hi Sven,

On Thu, Apr 27, 2017 at 10:06:35PM +0200, Sven Eschenberg wrote:
> 
> The protability of the on disk format includes, that I can basicly
> reimplement cryptsetup from scratch, without relying on the current
> status quo. Moreover I even don't need to use kernel crypto stuff at
> all to i.e. create a decrypted image of the data.

Let' me first explain a bit about the differences of wrapped key and
clear key:

- The cipher implementation is different because it must handle wrapped
  keys.
- The key generation (and derivation) is different because the clear key
  must be exposed only in its wrapped format.
- Particular clear key handling needs to be adapted to also work with
  wrapped keys. For example, this becomes necessary when computing a
  hash over the clear key.

To distinguish between clear and wrapped keys, you can use the name of
the cipher. That will be the indication for different key handling.
Then, you can think of two different cipher types: clear key cipher and
wrapped key cipher, each having its own key handling/management functions.

In the patches for crypsetup, we introduced the crypt_is_wrapped_key_cipher()
function to test for a wrapped key cipher and, then, perform some "wrapped
key specifics".  The "wrapped key specifics" are a set of callback functions
that must be implemented to support a wrapped key cipher. For example, we
added callback functions, crypt_generate_wrapped_volume_key() or
crypt_validate_wrapped_volume_key().
So you can provide any kind of wrapped-key cipher implementation which can
be platform-independent.

With the paes wrapped key cipher, we then simply provided the callback
implementation.  The callback implementation might use a kernel or library
or whatever interface.  For the paes reference implementation, we decided
to use a kernel interface which abstracts and wraps all the stuff that one
might consider HSM-specific.


> Your HSM specific changes would be tied into cryptsetup, but if I
> followed the current specification, and had the corresponding HSM, I
> still would need the 'specifics' regarding the HSM and how to use
> it, to set up the actual mapping.
[...]
> Now, in contrast, if you hack the HSM supprt into cryptsetup,
> there's no on disk indication and that is not really portable
> anymore.

As mentioned above, we focussed on a generic wrapped key cipher concept,
to abstract the HSM-specifics from cryptsetup, making them depend on the
wrapped key cipher. The portability of the existing functionality is not
affected because there is distinction between clear and wrapped key ciphers.
The LUKS on-disk-format structure is not touched by adding or changing any
members. The indication that a wrapped key instead of a clear key is used
for decryption is solely based on the name of the cipher. So if one would
write cryptsetup from scratch, it then needs to take care to handle the
wrapped key specifics.

Of course, to decrypt the data using the wrapped key, the platform
must support the wrapped key cipher and a HSM must be available.
But I do not think that this is a portability issue of cryptsetup in
general, it is rather an environment issue or requirement.  Because a 
driver is required to access the disk, the cipher (aes, blowfish, ...)
must be available to actually decrypt data.  With wrapped key ciphers,
particular environment requirements are added.


Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueckner@linux.vnet.ibm.com      | IBM Deutschland Research & Development GmbH
Linux on z Systems Development    | Schoenaicher Str. 220, 71032 Boeblingen

Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[David Niklas]

On Mon, 15 May 2017 21:28:13 +0200
Arno Wagner <arno@wagner.name> wrote:

> On Mon, May 15, 2017 at 15:56:54 CEST, Hendrik Brueckner wrote:
> > On Fri, Apr 28, 2017 at 09:22:22AM +0200, Arno Wagner wrote:  
> > > I think hardware-specific stuff has no place in cryptsetup.
> > > Get a kernel-driver and then create a wrapper that feeds
> > > the key to cryptsetup, anything else is a bad design.  
> > 
> > That's actually what we did with the paes reference implementation.
> > There are kernel drivers that abstract the HSM-specifics.  From a
> > user perspective, for example, cryptsetup, the secure (wrapped) key
> > is passed to the paes cipher (in-kernel crypto API).  The paes cipher
> > uses information from the secure key to find a HSM that is capable
> > to perform crypto operations with that key. There is no need for the
> > user to perform any HSM action.
> > 
> > I am about to reply on Sven's mail, covering some more details that
> > I do not want to repeat here.  
> 
> Ok, I will try to answer to that one then.
>  
> > > And if you want a system that is secure against root, then 
> > > do not use Linux. Seriously.  
> > 
> > Of course, if users becomes root (or gain superuser capabilities),
> > they are able to access the data and obtain the wrapped key.
> > Secure keys (the wrapped keys with that we deal) cannot be un-wrapped.
> > That means, at least, root cannot obtain the inner clear key.
> > 
> > So with the wrapped key concept, you can harden your environment
> > against offline attacks.    
> 
> I don't think so. LUKS does that pretty well already and unless
> there is some major flaw in it, offline attacks should be infeasible.
> 
> That is unless somebody uses a laughably simple passphrase that is.
> But anybody that does that will do other things that break security
> as well from my experience. So I have to admit I do not see the
> point. (Well, I do see the point, because people that do these
> stupid things may still buy a HSM and actually be a bit more 
> secure for it...)
> 
> 
> > With the wrapped key support, you also get a
> > 2-factor-authorization for free: there is something to know,
> > that's the passphrase, and there is something you own, that's the HSM.
> > Only if both factors are there, you can decrypt the data.  
> 
> Yes, that works. But why use LUKS here? In order to get the most
> of the HSM, the HSM actually needs to do the decryption itself 
> and all the LUKS header and key-slot overhead is redundant or 
> may even make things less reliable.
> 
> In particular, LUKS has this hard requirement that you need 
> header backups to be reliable. A HSM does usually have its
> of backup-scheme (often k-out-of-n chipcards or the like) and
> when integrating with LUKS, that suddently may not be enough 
> anymore.
> 
> Why not just implement your own tool that has a cryptsetup 
> compatible commandline syntax? That would still give you
> the Linux integration and I think that may serve your 
> purpose better. You would also not be dependent on 
> cryptsetup for any API changes in your drivers.
> 
> Regards,
> Arno

So,
1. User enters actual key
2. HSM gets actual key
3. HSM sends fake key to kernel
4. kernel gets fake key
5. kernel sends (de|en)cryption request (key, data)
6. HSM preforms verification of key
7.a. HSM returns key error
7.b. HSM (en|de)crypts data
8. HSM sends data to kernel (data)
Or, even better, esp. for long uptime machines!
8. HSM sends data to kernel with *new* fake key (key, data)


Sincerely,
David

Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[Hendrik Brueckner]

Hi Arno,

On Mon, May 15, 2017 at 09:28:13PM +0200, Arno Wagner wrote:
> On Mon, May 15, 2017 at 15:56:54 CEST, Hendrik Brueckner wrote:
> > On Fri, Apr 28, 2017 at 09:22:22AM +0200, Arno Wagner wrote:
> > > I think hardware-specific stuff has no place in cryptsetup.
> > > Get a kernel-driver and then create a wrapper that feeds
> > > the key to cryptsetup, anything else is a bad design.
> > 
> > That's actually what we did with the paes reference implementation.
> > There are kernel drivers that abstract the HSM-specifics.  From a
> > user perspective, for example, cryptsetup, the secure (wrapped) key
> > is passed to the paes cipher (in-kernel crypto API).  The paes cipher
> > uses information from the secure key to find a HSM that is capable
> > to perform crypto operations with that key. There is no need for the
> > user to perform any HSM action.
> > 
> > I am about to reply on Sven's mail, covering some more details that
> > I do not want to repeat here.
> 
> Ok, I will try to answer to that one then.
> 
> > > And if you want a system that is secure against root, then 
> > > do not use Linux. Seriously.
> > 
> > Of course, if users becomes root (or gain superuser capabilities),
> > they are able to access the data and obtain the wrapped key.
> > Secure keys (the wrapped keys with that we deal) cannot be un-wrapped.
> > That means, at least, root cannot obtain the inner clear key.
> > 
> > So with the wrapped key concept, you can harden your environment against
> > offline attacks.  
> 
> I don't think so. LUKS does that pretty well already and unless
> there is some major flaw in it, offline attacks should be infeasible.

By off-line attacks we mean off-line attacks with a stolen key.

> 
> That is unless somebody uses a laughably simple passphrase that is.
> But anybody that does that will do other things that break security
> as well from my experience. So I have to admit I do not see the
> point. (Well, I do see the point, because people that do these
> stupid things may still buy a HSM and actually be a bit more 
> secure for it...)

Simple passphrases are one thing and, of course, they break security.
And a careless use of HSMs does even make the situation not better.

Please do not frown on using HSMs at the first glance. They are a common
infrastructure piece, at least in our environment. Also consider companies
in the financial sector, that might have to use HSMs because of regulatory
policies. Just to make clear, our focus is on the enterprise level.


> 
> > With the wrapped key support, you also get a
> > 2-factor-authorization for free: there is something to know,
> > that's the passphrase, and there is something you own, that's the HSM.
> > Only if both factors are there, you can decrypt the data.
> 
> Yes, that works. But why use LUKS here? In order to get the most
> of the HSM, the HSM actually needs to do the decryption itself 
> and all the LUKS header and key-slot overhead is redundant or 
> may even make things less reliable.
> 
> In particular, LUKS has this hard requirement that you need 
> header backups to be reliable. A HSM does usually have its
> of backup-scheme (often k-out-of-n chipcards or the like) and
> when integrating with LUKS, that suddently may not be enough 
> anymore.

As for the redundant security provided by LUKS in connection with
wrapped key we thought about that. But we came to the conclusion
that we valued management compatibility over a bit of redundancy.

But also keep in mind, that there is and must be a separation of
concerns: security operators managing the HSM and system administrators
taking care of the Linux instances. The security operator has to take
care for installing, backing up, and recovering of HSM master-keys
(that is the k-out-of-n chipcards stuff). The system administrator has
to take care to backup and recovery the wrapped key.  The wrapped
key is not stored on the HSM. The effective key can be just obtained
with a master key on the HSM.

Besides that, "redundancy" provides 2-factor authentication - which is nice.
And those who do not care about 2FA can use a standard passphrase or can
store it in a not so secure file (e.g. in the boot partition) and enjoy that
the disk can be automatically opened on systems where the HSM is available.

> 
> Why not just implement your own tool that has a cryptsetup 
> compatible commandline syntax? That would still give you
> the Linux integration and I think that may serve your 
> purpose better. You would also not be dependent on 
> cryptsetup for any API changes in your drivers.

You are right. We could. Yet we like LUKS :-) and LUKS is the de-facto 
standard for Linux disk encryption.  So our goal is to keep the
management burden of disks encrypted with a wrapped key to a minimum.
We made an effort to make the usage of such disks as similar as possible to
existing schemes (the only difference being a new cipher name) such that it
can without change be used in existing management frameworks /distributions.
Besides we do not want to fork yet another management discipline.


Kind regards,
  Hendrik

Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[Arno Wagner]

On Mon, May 29, 2017 at 15:48:06 CEST, Hendrik Brueckner wrote:
> Hi Arno,
> 
> On Mon, May 15, 2017 at 09:28:13PM +0200, Arno Wagner wrote:
> > On Mon, May 15, 2017 at 15:56:54 CEST, Hendrik Brueckner wrote:
> > > On Fri, Apr 28, 2017 at 09:22:22AM +0200, Arno Wagner wrote:
> > > > I think hardware-specific stuff has no place in cryptsetup.
> > > > Get a kernel-driver and then create a wrapper that feeds
> > > > the key to cryptsetup, anything else is a bad design.
> > > 
> > > That's actually what we did with the paes reference implementation.
> > > There are kernel drivers that abstract the HSM-specifics.  From a
> > > user perspective, for example, cryptsetup, the secure (wrapped) key
> > > is passed to the paes cipher (in-kernel crypto API).  The paes cipher
> > > uses information from the secure key to find a HSM that is capable
> > > to perform crypto operations with that key. There is no need for the
> > > user to perform any HSM action.
> > > 
> > > I am about to reply on Sven's mail, covering some more details that
> > > I do not want to repeat here.
> > 
> > Ok, I will try to answer to that one then.
> > 
> > > > And if you want a system that is secure against root, then 
> > > > do not use Linux. Seriously.
> > > 
> > > Of course, if users becomes root (or gain superuser capabilities),
> > > they are able to access the data and obtain the wrapped key.
> > > Secure keys (the wrapped keys with that we deal) cannot be un-wrapped.
> > > That means, at least, root cannot obtain the inner clear key.
> > > 
> > > So with the wrapped key concept, you can harden your environment against
> > > offline attacks.  
> > 
> > I don't think so. LUKS does that pretty well already and unless
> > there is some major flaw in it, offline attacks should be infeasible.
> 
> By off-line attacks we mean off-line attacks with a stolen key.

Your terminology is a bit off here: If an attacker has the key 
and uses it, that is not actually an attack. An attacker is 
perfectly allowed to present a key, just as anybody else is.
The only authorization here is whether somebody has the key,
and hence an attacker with the key is authorized.

> > That is unless somebody uses a laughably simple passphrase that is.
> > But anybody that does that will do other things that break security
> > as well from my experience. So I have to admit I do not see the
> > point. (Well, I do see the point, because people that do these
> > stupid things may still buy a HSM and actually be a bit more 
> > secure for it...)
> 
> Simple passphrases are one thing and, of course, they break security.
> And a careless use of HSMs does even make the situation not better.
> 
> Please do not frown on using HSMs at the first glance. They are a common
> infrastructure piece, at least in our environment. Also consider companies
> in the financial sector, that might have to use HSMs because of regulatory
> policies. Just to make clear, our focus is on the enterprise level.

I do certainly not frown on HSM usage at a "first glance". I 
am well aware of HSM uses and misuses and I have considerable
experience with enterprise IT security (and lack thereof). 
But LUKS is very explicitely targetted at non-HSM scenarios.

> > > With the wrapped key support, you also get a
> > > 2-factor-authorization for free: there is something to know,
> > > that's the passphrase, and there is something you own, that's the HSM.
> > > Only if both factors are there, you can decrypt the data.
> > 
> > Yes, that works. But why use LUKS here? In order to get the most
> > of the HSM, the HSM actually needs to do the decryption itself 
> > and all the LUKS header and key-slot overhead is redundant or 
> > may even make things less reliable.
> > 
> > In particular, LUKS has this hard requirement that you need 
> > header backups to be reliable. A HSM does usually have its
> > of backup-scheme (often k-out-of-n chipcards or the like) and
> > when integrating with LUKS, that suddently may not be enough 
> > anymore.
> 
> As for the redundant security provided by LUKS in connection with
> wrapped key we thought about that. But we came to the conclusion
> that we valued management compatibility over a bit of redundancy.

The HSMs you use do not have management capability? Have you
thought about getting better ones? They are expensive enough 
after all. On the other hand, if you want the sort-of "light
weight" management capabilities LUKS offer, you may lose most
of what the HSM gives you against internal attackers.
 
> But also keep in mind, that there is and must be a separation of
> concerns: security operators managing the HSM and system administrators
> taking care of the Linux instances. The security operator has to take
> care for installing, backing up, and recovering of HSM master-keys
> (that is the k-out-of-n chipcards stuff). The system administrator has
> to take care to backup and recovery the wrapped key.  The wrapped
> key is not stored on the HSM. The effective key can be just obtained
> with a master key on the HSM.

Well, that one is basically worthless, except for fulfilling the 
process. I do understand that sometimes you have to do that.
But the fact of the matter is that you have neither security 
against the security operator nor against the system administrator
if they are even marginally competent. That one can not be avoided,
no matter what you do, except for some very expensive solutions.

I am well aware that many enterprise security people try very
hard to ignore that little fact. But I really do not think that
LUKS should start to do "wishful thinking security", even if
that one is quite common in the enterprise space.
 
> Besides that, "redundancy" provides 2-factor authentication - which is
> nice.  And those who do not care about 2FA can use a standard passphrase
> or can store it in a not so secure file (e.g.  in the boot partition) and
> enjoy that the disk can be automatically opened on systems where the HSM
> is available.

Aehm, a 2FA that you can circumvent is not a 2FA.

> > Why not just implement your own tool that has a cryptsetup 
> > compatible commandline syntax? That would still give you
> > the Linux integration and I think that may serve your 
> > purpose better. You would also not be dependent on 
> > cryptsetup for any API changes in your drivers.
> 
> You are right. We could. Yet we like LUKS :-) and LUKS is the de-facto 
> standard for Linux disk encryption.  So our goal is to keep the
> management burden of disks encrypted with a wrapped key to a minimum.
> We made an effort to make the usage of such disks as similar as possible to
> existing schemes (the only difference being a new cipher name) such that it
> can without change be used in existing management frameworks /distributions.
> Besides we do not want to fork yet another management discipline.

While I do understand that, I do not see any security 
improvements for LUKS. All I see is creating compatibility
with enterprise process situations. As this increases 
complexity with zero security, I am opposed, as this is a
net loss for LUKS.

Come to think of it, one thing you could do is maintain
a patch-set. That way, core-LUKS would not suffer and you 
would still get your "HSM LUKS".

Regards,
Arno
-- 
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

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[Hendrik Brueckner]

Hi Arno,

I appreciate to discuss about your HSM and security experiences.
However, I think the discussion drifts into a wrong direction.
So we discussed about HSMs; but I want to step back to focus on
the where and why we started:

Our goal is to never expose the effective key used to encrypt the data
on disk in plain text in the operating system memory.

This has value for different aspects:
- Nobody can steal the key and decrypt a disk being accessed from a
  different system.
- System dumps can be provided to service organizations without risking
  that a crucial secret becomes exposed.
- Password protection of keys being no longer the only protection mechanism.
  This allows to automatically unlock/open disks.

Support of not exposing keys in plain text requires hardware support. The
most commonly known hardware are HSMs that is why we tried to explain our
contributions using HSMs.

But other implementations are conceivable including TPMs, performing
encryption inside enclaves of Intel SGX, or CPU, or firmware (like it
is done with z Systems protected keys).

All these methods will face the same set of problems, for example, special
key formats require special key generation procedures, hashes of key
representation are no longer unique identifiers of the effective keys.
We have solved all of these problems.

Also we invite you to look at the code and let us know if you have better
suggestions on how to solve these problems.


On Mon, May 29, 2017 at 08:25:55PM +0200, Arno Wagner wrote:
> On Mon, May 29, 2017 at 15:48:06 CEST, Hendrik Brueckner wrote:
> > On Mon, May 15, 2017 at 09:28:13PM +0200, Arno Wagner wrote:
> > > On Mon, May 15, 2017 at 15:56:54 CEST, Hendrik Brueckner wrote:
> > > > On Fri, Apr 28, 2017 at 09:22:22AM +0200, Arno Wagner wrote:
> 
> > > That is unless somebody uses a laughably simple passphrase that is.
> > > But anybody that does that will do other things that break security
> > > as well from my experience. So I have to admit I do not see the
> > > point. (Well, I do see the point, because people that do these
> > > stupid things may still buy a HSM and actually be a bit more 
> > > secure for it...)
> > 
> > Simple passphrases are one thing and, of course, they break security.
> > And a careless use of HSMs does even make the situation not better.
> > 
> > Please do not frown on using HSMs at the first glance. They are a common
> > infrastructure piece, at least in our environment. Also consider companies
> > in the financial sector, that might have to use HSMs because of regulatory
> > policies. Just to make clear, our focus is on the enterprise level.
> 
> I do certainly not frown on HSM usage at a "first glance". I 
> am well aware of HSM uses and misuses and I have considerable
> experience with enterprise IT security (and lack thereof). 
> But LUKS is very explicitely targetted at non-HSM scenarios.

We all know there is no such thing as absolute security. All we can do is to
constrain the attack vector to a manageable size: That is manageable through
policies and trust and increasing the risk for the bad guys to be discovered.

Disallowing to store the dm-crypt effective key in plain text in the operating
system memory will just remove a few attack vectors and certainly increase
the risk of stealing data without being caught.

And operating system memory means not only the running instance. It also
applies to dumps of the OS memory that are handed over to other parties
for service. This in general exposes any contained key materials to good
and bad guys and requires lots of trust. This exposure of effective key materials
can be reduced with wrapped keys; so it is something that becomes manageable.

> 
> > > > With the wrapped key support, you also get a
> > > > 2-factor-authorization for free: there is something to know,
> > > > that's the passphrase, and there is something you own, that's the HSM.
> > > > Only if both factors are there, you can decrypt the data.
> > > 
> > > Yes, that works. But why use LUKS here? In order to get the most
> > > of the HSM, the HSM actually needs to do the decryption itself 
> > > and all the LUKS header and key-slot overhead is redundant or 
> > > may even make things less reliable.
> > > 
> > > In particular, LUKS has this hard requirement that you need 
> > > header backups to be reliable. A HSM does usually have its
> > > of backup-scheme (often k-out-of-n chipcards or the like) and
> > > when integrating with LUKS, that suddently may not be enough 
> > > anymore.
> > 
> > As for the redundant security provided by LUKS in connection with
> > wrapped key we thought about that. But we came to the conclusion
> > that we valued management compatibility over a bit of redundancy.
> 
> The HSMs you use do not have management capability? Have you
> thought about getting better ones? They are expensive enough 
> after all. On the other hand, if you want the sort-of "light
> weight" management capabilities LUKS offer, you may lose most
> of what the HSM gives you against internal attackers.

As for HSM management: We do not suggest to let cryptsetup manage a HSM.
Each HSM comes with its own management tooling. Also note that the management
tooling can be located on separate management systems to prevent configuration
changes from within a Linux instance.

Our solution expects that a HSM or any other supportive hardware is already
set up (for example, access of the Linux instance to the HSM is configured
and the HSM master secrets are set).  We want cryptsetup only to use a
configured HSM or any other supportive hardware and tried to keep the
HSM/HW-specific interfaces as small as possible. Most are hidden inside
the cipher that deals with wrapped keys. Key generation, however, requires a
call to a special function (e.g. kernel, device driver) - and in our solution
this is encapsulated in generic callbacks where interfaces can be plugged-in.


> > > Why not just implement your own tool that has a cryptsetup 
> > > compatible commandline syntax? That would still give you
> > > the Linux integration and I think that may serve your 
> > > purpose better. You would also not be dependent on 
> > > cryptsetup for any API changes in your drivers.
> > 
> > You are right. We could. Yet we like LUKS :-) and LUKS is the de-facto 
> > standard for Linux disk encryption.  So our goal is to keep the
> > management burden of disks encrypted with a wrapped key to a minimum.
> > We made an effort to make the usage of such disks as similar as possible to
> > existing schemes (the only difference being a new cipher name) such that it
> > can without change be used in existing management frameworks /distributions.
> > Besides we do not want to fork yet another management discipline.
> 
> While I do understand that, I do not see any security 
> improvements for LUKS. All I see is creating compatibility
> with enterprise process situations. As this increases 
> complexity with zero security, I am opposed, as this is a
> net loss for LUKS.

Just to repeat what has been said before: we think it is of great value
to manage encrypted disks with a common tooling.  We are trying hard to
integrate a new encryption discipline in a compatible way with existing
tools (cryptsetup).  And we believe that the Linux _Unified_ Key Setup
approach is the right direction. Anyhow, we are open to suggestions to
even better integrate.

> 
> Come to think of it, one thing you could do is maintain
> a patch-set. That way, core-LUKS would not suffer and you 
> would still get your "HSM LUKS".

It is not about an "HSM LUKS". As mentioned in the beginning, our goal is
to not expose the effective key in plain text in the OS memory. We use
wrapped keys to achieve this goal and it is about to manage these wrapped
keys with LUKS the same way as LUKS does for keys in plain text format.

Thanks and kind regards,
  Hendrik

Re: [dm-crypt] Managing wrapped key ciphers with cryptsetup

[Milan Broz]

On 04/27/2017 05:09 PM, Hendrik Brueckner wrote:> 
> Of course, I think it is and I would be glad when we can work together
> on a solution.

Hi,

so I finally got through the discussion and the patches.

And no, I think this should not be a part of the cryptsetup core as it is.

I mentioned some reasons in the comment for merge request:
  https://gitlab.com/cryptsetup/cryptsetup/merge_requests/19

I understand that this is interesting for IBM to have supported
in enterprise distros. I would like to have some support
for this feature as well but not the way it will complicate code
for others and makes it HW-dependent for everyone.

I have mentioned some possible way how to do it in the comment as well.

(I think some external application linked to libcryptsetup,
and then handling your pAES algorithm and wrapped key just as
an another encryption algorithm is much cleaner.)

The pAES (and PKEY ioctls) are currently only available on IBM s390
(and I guess only on some models; guessing from Linux kernel sources),
so this is enterprise only thing.

BTW does Hercules emulator support this so a regular user
can try the HSM interface?
(I have probably access it to the real HW if needed but for other people.)

Thanks for patches and discussion anyway!

Milan