[dm-crypt] pashphrase management question

[dm-crypt] pashphrase management question

[ClEmFoster]

hello,

The setup:

I work in an environment that has a whole disk encryption requirement for
VMs.  If the VM is restarted an admin has to hit the console and type in
the passphrase to boot.  This is OK, we don't reboot much, and security
guys are happy.  The problem is they are going to start requiring that
these machines also receive a passphrase change every 3 or 6 months.  That
brings me to the question.

cryptsetup for luks requires an existing passphrase to add/change another.
 Physical interaction to change passphrase is not very realistic for 100+
machines.  Ideally I would like to change the password via an automated
system.  Currently we are evaluating Chef, Ansible, and Puppet, has anyone
here been able to manage luks passphrases over many machines?  If so some
friendly guidance would be greatly appreciated.

Thanks

Travis

Re: [dm-crypt] pashphrase management question

[Michael Kjörling]

On 26 Oct 2016 10:43 -0600, from clemfoster@lookafish.com (ClEmFoster):
> The problem is they are going to start requiring that
> these machines also receive a passphrase change every 3 or 6 months.

Not sure what threat model that is meant to protect against, but...


> cryptsetup for luks requires an existing passphrase to add/change another.
>  Physical interaction to change passphrase is not very realistic for 100+
> machines.  Ideally I would like to change the password via an automated
> system.

Perhaps unless you are running an ancient cryptsetup, and assuming
that you really are working with LUKS (not plain dm-crypt), the manual
page explicitly states that the passphrases do not need to be provided
interactively:

       luksChangeKey <device> [<new key file>]

              Changes an existing passphrase. The passphrase to be changed
              must be supplied interactively or via --key-file. The new
              passphrase can be supplied interactively or in a file given as
              positional argument.
              /.../
              <options> can be [--key-file, --keyfile-offset, --keyfile-size,
              --new-keyfile-offset, --new-keyfile-size, --key-slot].

That should be all you need.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] pashphrase management question

[ClEmFoster]

On Wed, October 26, 2016 2:39 pm, Michael Kjörling wrote:
> On 26 Oct 2016 10:43 -0600, from clemfoster@lookafish.com (ClEmFoster):
>
>> The problem is they are going to start requiring that
>> these machines also receive a passphrase change every 3 or 6 months.
>
> Not sure what threat model that is meant to protect against, but...


Agreed, but I have no say in this requirement.


>
>
>
>> cryptsetup for luks requires an existing passphrase to add/change
>> another. Physical interaction to change passphrase is not very realistic
>> for 100+ machines.  Ideally I would like to change the password via an
>> automated system.
>
> Perhaps unless you are running an ancient cryptsetup, and assuming
> that you really are working with LUKS (not plain dm-crypt), the manual page
> explicitly states that the passphrases do not need to be provided
> interactively:
>
>
> luksChangeKey <device> [<new key file>]
>
> Changes an existing passphrase. The passphrase to be changed
> must be supplied interactively or via --key-file. The new passphrase can be
> supplied interactively or in a file given as positional argument. /.../
> <options> can be [--key-file, --keyfile-offset, --keyfile-size,
> --new-keyfile-offset, --new-keyfile-size, --key-slot].
>
>
> That should be all you need.

I did read that in the man page, but if you want a passphrase changed in
that manor then you have to put the new and old passphrase in a file plain
text.  Unless I am missing something.  I was hoping to fine some way to
encrypt it before passing it in.  like you can do with other applications.


>
>
> --
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
> “People who think they know everything really annoy those of us who know
> we don’t.” (Bjarne Stroustrup)
> _______________________________________________
> dm-crypt mailing list dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
>
>


Thanks

Travis

Re: [dm-crypt] pashphrase management question

[ClEmFoster]

On Wed, October 26, 2016 3:21 pm, Sven Eschenberg wrote:
>

>
> Am 26.10.2016 um 23:08 schrieb ClEmFoster:
>
>> On Wed, October 26, 2016 2:39 pm, Michael Kjörling wrote:
>>
>
>>> luksChangeKey <device> [<new key file>]
>>>
>>> Changes an existing passphrase. The passphrase to be changed
>>> must be supplied interactively or via --key-file. The new passphrase
>>> can be supplied interactively or in a file given as positional
>>> argument. /.../ <options> can be [--key-file, --keyfile-offset,
>>> --keyfile-size,
>>> --new-keyfile-offset, --new-keyfile-size, --key-slot].
>>>
>>>
>>>
>>> That should be all you need.
>>>
>>
>> I did read that in the man page, but if you want a passphrase changed
>> in that manor then you have to put the new and old passphrase in a file
>> plain text.  Unless I am missing something.  I was hoping to fine some
>> way to encrypt it before passing it in.  like you can do with other
>> applications.
>>
>
> That makes absolutely no sense to me. Why would you want to encrypt a
> passphrase? Or in other words, what's wrong with binary files? Or don't you
> want to store the files on disk? Then be reminded: STDIN and STDOUT are
> files, and can be connected to pipes.
>

I think keyfile and Passphrase are being confused here.

This whole disk OS is not booted yet when an admin has to type in the
passphrase.  Once the OS is running it is true a keyfile could be used but
then it would also have to be rotated.  I am looking to change the
passphrase on a 100+ machines utilizing some kind of automated system.  If
I didn't have an IDM I could generate the hash for any given user and
automation could edit the shadow file.  I was looking for something
similar, where I didn't have to have a plain text passphrase sitting on a
central server.

>
>>
>>>
>>>
>>> --
>>> Michael Kjörling • https://michael.kjorling.se •
>>> michael@kjorling.se “People who think they know everything really
>>> annoy those of us who know we don’t.” (Bjarne Stroustrup)
>>> _______________________________________________
>>> dm-crypt mailing list dm-crypt@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>
>>>
>>>
>>>
>>
>>
>> Thanks
>>
>>
>> Travis
>>
>>
>> _______________________________________________
>> dm-crypt mailing list dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>>
>
> -Sven
> _______________________________________________
> dm-crypt mailing list dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
>

Travis

Re: [dm-crypt] pashphrase management question

[Michael Kjörling]

On 26 Oct 2016 23:21 +0200, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
>>> luksChangeKey <device> [<new key file>]
>> 
>> I did read that in the man page, but if you want a passphrase changed in
>> that manor then you have to put the new and old passphrase in a file plain
>> text.  Unless I am missing something.  I was hoping to fine some way to
>> encrypt it before passing it in.  like you can do with other applications.

How about placing it in the LUKS container itself? You already have
access to anywhere between gigabytes and terabytes of random access
read/write encrypted storage, so might as well make use of it.


> That makes absolutely no sense to me. Why would you want to encrypt
> a passphrase? Or in other words, what's wrong with binary files?
> Or don't you want to store the files on disk? Then be reminded:
> STDIN and STDOUT are files, and can be connected to pipes.

An alternative approach would be to create a temporary LUKS or
dm-crypt container with a random key, store the passphrase files
within that container, and when you are done, throw away the keys to
that and delete the file from the file system. That way, even if
someone gets full plaintext access to the outer container, and even if
they are able to determine that you stored the passphrase in some
particular location on disk, that data will still be unreadable.

Or, if you don't want everything under the lock and key of symmetric
encryption, take Sven's suggestion of pipes, and tie GnuPG with
asymmetric encryption into the chain. That's the beauty of the Unix
philosophy that every tool does one thing and does it well, instead of
having monoliths that try to do everything and end up doing a
half-baked job of most of it.

We can perhaps help with the technical parts (though it would be nice
if you tell us up front what you have considered and rejected, and
why), but if we don't know what threat model is being protected (or
attempting to protect) against, it's impossible to judge how well
those meet the requirements. **If you don't even know yourself what
the threat model for this is, then I suggest being up front with the
people mandating this and asking them exactly what scheduled LUKS
container passphrase changes is meant to protect against.**

Something tells me that adding a handful of bits of entropy to the
passphrase, or increasing the iteration count (especially since you
say you reboot only rarely), is a better solution to whatever the
problem is.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] pashphrase management question

[Robert Nichols]

On 10/26/2016 11:43 AM, ClEmFoster wrote:
> hello,
>
> The setup:
>
> I work in an environment that has a whole disk encryption requirement for
> VMs.  If the VM is restarted an admin has to hit the console and type in
> the passphrase to boot.  This is OK, we don't reboot much, and security
> guys are happy.  The problem is they are going to start requiring that
> these machines also receive a passphrase change every 3 or 6 months.  That
> brings me to the question.

Are "they" aware that anyone who has had read access to the device
with the LUKS container has had an opportunity to copy the LUKS
header, and can always use that LUKS header with the old passphrase
to unlock the container (perhaps after spending however much time
and processing power is needed to crack that passphrase offline).

For that matter, anyone with root access to the VM while the LUKS
container is unlocked can easily obtain the master key
(dmsetup table --showkeys /dev/{whatever}) and can always access
the LUKS container with that.

Changing the passphrase doesn't protect against any of that.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] pashphrase management question

[Arno Wagner]

On Thu, Oct 27, 2016 at 01:17:42 CEST, Robert Nichols wrote:
> On 10/26/2016 11:43 AM, ClEmFoster wrote:
> >hello,
> >
> >The setup:
> >
> >I work in an environment that has a whole disk encryption requirement for
> >VMs.  If the VM is restarted an admin has to hit the console and type in
> >the passphrase to boot.  This is OK, we don't reboot much, and security
> >guys are happy.  The problem is they are going to start requiring that
> >these machines also receive a passphrase change every 3 or 6 months.  That
> >brings me to the question.
> 
> Are "they" aware that anyone who has had read access to the device
> with the LUKS container has had an opportunity to copy the LUKS
> header, and can always use that LUKS header with the old passphrase
> to unlock the container (perhaps after spending however much time
> and processing power is needed to crack that passphrase offline).
> 
> For that matter, anyone with root access to the VM while the LUKS
> container is unlocked can easily obtain the master key
> (dmsetup table --showkeys /dev/{whatever}) and can always access
> the LUKS container with that.
> 
> Changing the passphrase doesn't protect against any of that.

This is probably just the usual "cargo-cult" security, i.e.
follow the ritual (a.k.a. "Process") without question,
because that would require understanding.

Regular passphrase changes on storage-encryption make 
absolutely no sense and gives you absolutely no
protection benefit (unless you have told somebody
that should not know, in which case you need to change 
them immediately).

I would try to give "them" a definition of the LUKS
passphrase that does not make it a "password" or 
"login credential", and with a bit of luck you can
negate thereby prevent the usuall "password" process
and its requirements from applying. 

One approach would be to make this a "technical secret" 
or the like. After all, they probably to not require, 
say,  passphrases protecting certificates to be changed 
regularly, because that would be relatively difficult.

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] pashphrase management question

[Sven Eschenberg]

Am 27.10.2016 um 09:55 schrieb Arno Wagner:
> On Thu, Oct 27, 2016 at 01:17:42 CEST, Robert Nichols wrote:
>> On 10/26/2016 11:43 AM, ClEmFoster wrote:
>>> hello,
>>>
>>> The setup:
>>>
>>> I work in an environment that has a whole disk encryption requirement for
>>> VMs.  If the VM is restarted an admin has to hit the console and type in
>>> the passphrase to boot.  This is OK, we don't reboot much, and security
>>> guys are happy.  The problem is they are going to start requiring that
>>> these machines also receive a passphrase change every 3 or 6 months.  That
>>> brings me to the question.
>>
>> Are "they" aware that anyone who has had read access to the device
>> with the LUKS container has had an opportunity to copy the LUKS
>> header, and can always use that LUKS header with the old passphrase
>> to unlock the container (perhaps after spending however much time
>> and processing power is needed to crack that passphrase offline).
>>
>> For that matter, anyone with root access to the VM while the LUKS
>> container is unlocked can easily obtain the master key
>> (dmsetup table --showkeys /dev/{whatever}) and can always access
>> the LUKS container with that.
>>
>> Changing the passphrase doesn't protect against any of that.
>
> This is probably just the usual "cargo-cult" security, i.e.
> follow the ritual (a.k.a. "Process") without question,
> because that would require understanding.
>
> Regular passphrase changes on storage-encryption make
> absolutely no sense and gives you absolutely no
> protection benefit (unless you have told somebody
> that should not know, in which case you need to change
> them immediately).

I might be wrong, but changing the passphrase could make sense if (and 
only if) you switch the actual encryption key along with it by 
reencrypting the whole device. Aside from that changing passphrases 
seems a little pointless.
>
> I would try to give "them" a definition of the LUKS
> passphrase that does not make it a "password" or
> "login credential", and with a bit of luck you can
> negate thereby prevent the usuall "password" process
> and its requirements from applying.
>
> One approach would be to make this a "technical secret"
> or the like. After all, they probably to not require,
> say,  passphrases protecting certificates to be changed
> regularly, because that would be relatively difficult.
>
> Regards,
> Arno
>

Regards

-Sven

Re: [dm-crypt] pashphrase management question

[Robert Nichols]

On 10/27/2016 05:24 AM, Sven Eschenberg wrote:
>
>
> Am 27.10.2016 um 09:55 schrieb Arno Wagner:
>> Regular passphrase changes on storage-encryption make
>> absolutely no sense and gives you absolutely no
>> protection benefit (unless you have told somebody
>> that should not know, in which case you need to change
>> them immediately).
>
> I might be wrong, but changing the passphrase could make sense if (and only if) you switch the
> actual encryption key along with it by reencrypting the whole device. Aside from that changing
> passphrases seems a little pointless.

You are correct, but cryptsetup-reencrypt is a lengthy process,
during which the slightest glitch can cause you to lose everything.
It's not the sort of thing you want to be doing routinely.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] pashphrase management question

[ClEmFoster]

All,

    Thanks a lot for all your input.  I have already started the process
of having a more informed conversation with security about what we are
trying to protect, from, and how.

I really do appreciate all the feedback.

Thanks

Travis