[dm-crypt] Mechanics

[dm-crypt] Mechanics

[julie_nuckey]

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

I'm trying to understand the mechanics of how dm-crypt and cryptsetup work, in particular how data such as the password/key-file data is passed from user mode to kernel mode, and also generally what does what when setting up an encrypted volume.

 

As I understand it, dm-crypt is a pure kernel-mode application that does the encryption and decryption of data on the fly. It works independently of any on-disk format such as metadata like that used by LUKS. Have I got that right?

 

And cryptsetup is the pure user-mode application and this can work in "plain" mode, ie without LUKS, or in LUKS mode. Is that right? So how does the password/key get from cryptsetup (user mode) to dm-crypt (kernel mode) and does it differ depending on whether I'm using plain or LUKS mode? Does it use tables? Is the password/key written to the tables?

 

In LUKS mode, does cryptsetup generate the master key? In user mode? Does cryptsetup create/edit the metadata?

 

Thanks in advance for any clarification anyone can provide.

 


Trend Micro EMEA (GB) Limited, a Limited Liability Company. Registered in England No. 06766734. 
Registered office: Eversheds House, 70 Great Bridgewater Street, Manchester, M1 5ES
Trend Micro (UK) Limited, a Limited Liability Company. Registered in England No. 3698292. 
Registered Office: Pacific House, Third Avenue, Globe Business Park, Marlow, Bucks, SL7 1YL 
Telephone: +44 1628 400500 Facsimile: +44 1628 400511

This communication and any accompanying files and attachments are intended only for the recipient to whom it is addressed. 
If you have received this communication in error, please immediately notify the Sender. You are further notified that any disclosure, 
copying or other distribution of this communication, including its attachments is strictly prohibited.

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

Re: [dm-crypt] Mechanics

[Arno Wagner]

On Wed, Dec 02, 2009 at 12:20:31PM +0100, julie_nuckey@trendmicro.co.uk wrote:
>
> I'm trying to understand the mechanics of how dm-crypt and cryptsetup
> work, in particular how data such as the password/key-file data is passed
> from user mode to kernel mode, and also generally what does what when
> setting up an encrypted volume.
> 
>
> 
> As I understand it, dm-crypt is a pure kernel-mode application that does
> the encryption and decryption of data on the fly. It works independently
> of any on-disk format such as metadata like that used by LUKS. Have I got
> that right?

Yes. It will happily de-/encrypt random data. No checking at all, not
a single bit of metadata. Incidentially a dm-crypt volume (after
an encrypted overwrite) is indistinguishable for a volume wiped
with cryptographically strong randomness. In fact I use dm-crypt
to wipe disks: 
 1.) Set-up with random key (from /dev/random)
 2.) Overwrite with weak randomness or zeros.
  
 
> And cryptsetup is the pure user-mode application and this can work in
> "plain" mode, ie without LUKS, or in LUKS mode. Is that right? So how does
> the password/key get from cryptsetup (user mode) to dm-crypt (kernel mode)
> and does it differ depending on whether I'm using plain or LUKS mode? Does
> it use tables? Is the password/key written to the tables?
 
My guess would be that the key data is basically the same as for
directly using ciphers in the kernel. Some call will transfer them.
No idea about the details, but dm-crypt is basically a device mapper
target and should use the same mechanisms. The device mapper page
at http://sources.redhat.com/dm/ may have more information.
   
> In LUKS mode, does cryptsetup generate the master key? In user mode? Does
> cryptsetup create/edit the metadata?

Yes, AFAIK. The kernel does not understand LUKS.
  
> Thanks in advance for any clarification anyone can provide.

Side note: What about linebreaks? It is not nice to have to reformat
your message before answering...


Arno


-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Mechanics

[julie_nuckey]

Thanks for the information, but I was hoping for a little more detail.

I really want to know if it possible for the password/key to be exposed in the process
of transferring it from user mode to kernel mode, or if it could remain in memory as
a result, that's why I'm asking about the mechanics of what happens between cryptsetup
(user mode) and dm-crypt (kernel mode).

In "plain" mode the password must be passed to the kernel, but in LUKS mode, the 
password is used to decrypt the master key which is in the kernel. If cryptsetup is 
user mode only, what exactly does the kernel mode decryption of the master key? Can't
be dm-crypt as this doesn't know anything about LUKS.

BTW, sorry about the missing line breaks, don't know what happened there. I'll remember
to put in hard ones in future.


-----Original Message-----
From: dm-crypt-bounces@saout.de [mailto:dm-crypt-bounces@saout.de] On Behalf Of Arno Wagner
Sent: 02 December 2009 12:21
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Mechanics

On Wed, Dec 02, 2009 at 12:20:31PM +0100, julie_nuckey@trendmicro.co.uk wrote:
>
> I'm trying to understand the mechanics of how dm-crypt and cryptsetup
> work, in particular how data such as the password/key-file data is passed
> from user mode to kernel mode, and also generally what does what when
> setting up an encrypted volume.
> 
>
> 
> As I understand it, dm-crypt is a pure kernel-mode application that does
> the encryption and decryption of data on the fly. It works independently
> of any on-disk format such as metadata like that used by LUKS. Have I got
> that right?

Yes. It will happily de-/encrypt random data. No checking at all, not
a single bit of metadata. Incidentially a dm-crypt volume (after
an encrypted overwrite) is indistinguishable for a volume wiped
with cryptographically strong randomness. In fact I use dm-crypt
to wipe disks: 
 1.) Set-up with random key (from /dev/random)
 2.) Overwrite with weak randomness or zeros.
  
 
> And cryptsetup is the pure user-mode application and this can work in
> "plain" mode, ie without LUKS, or in LUKS mode. Is that right? So how does
> the password/key get from cryptsetup (user mode) to dm-crypt (kernel mode)
> and does it differ depending on whether I'm using plain or LUKS mode? Does
> it use tables? Is the password/key written to the tables?
 
My guess would be that the key data is basically the same as for
directly using ciphers in the kernel. Some call will transfer them.
No idea about the details, but dm-crypt is basically a device mapper
target and should use the same mechanisms. The device mapper page
at http://sources.redhat.com/dm/ may have more information.
   
> In LUKS mode, does cryptsetup generate the master key? In user mode? Does
> cryptsetup create/edit the metadata?

Yes, AFAIK. The kernel does not understand LUKS.
  
> Thanks in advance for any clarification anyone can provide.

Side note: What about linebreaks? It is not nice to have to reformat
your message before answering...


Arno


-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 
_______________________________________________
dm-crypt mailing list
dm-crypt@saout.de
http://www.saout.de/mailman/listinfo/dm-crypt

Trend Micro EMEA (GB) Limited, a Limited Liability Company. Registered in England No. 06766734. 
Registered office: Eversheds House, 70 Great Bridgewater Street, Manchester, M1 5ES
Trend Micro (UK) Limited, a Limited Liability Company. Registered in England No. 3698292. 
Registered Office: Pacific House, Third Avenue, Globe Business Park, Marlow, Bucks, SL7 1YL 
Telephone: +44 1628 400500 Facsimile: +44 1628 400511

This communication and any accompanying files and attachments are intended only for the recipient to whom it is addressed. 
If you have received this communication in error, please immediately notify the Sender. You are further notified that any disclosure, 
copying or other distribution of this communication, including its attachments is strictly prohibited.

Re: [dm-crypt] Mechanics

[Milan Broz]

On 12/02/2009 02:51 PM, julie_nuckey@trendmicro.co.uk wrote:

> I really want to know if it possible for the password/key to be exposed in the process
> of transferring it from user mode to kernel mode, or if it could remain in memory as
> a result, that's why I'm asking about the mechanics of what happens between cryptsetup
> (user mode) and dm-crypt (kernel mode).

- passphrase (or password) is processed only in userspace, never sent in open form
to kernel

- all communication (configuration) of dm-crypt device (the mapped keyslot is
temporary dmcrypt device also) is through dm-ioctl calls

- you must provide key (part of mapping table) in this call in text format
(see "dmsetup table --showkeys) for dm-crypt to configure requested crypto mapping

that key is basically (simplified)
 1) hashed passphrase in plain mode or
 2) LUKS PKBKDF2 derived key for mapping keyslot area (for temporary keyslot device) or
 3) master key for real LUKS device mapping (read and un-obfuscated from keyslot area)

Just to add:
- only root can use dm-ioctl and only root can use cryptsetup for these operations
- cryptsetup locks its memory to prevent swapping sensitive data
- all sensitive data are erased before returning memory (both in kernel and userspace)
 
> In "plain" mode the password must be passed to the kernel,

Not exactly. It is hashed passphrase sent to kernel dm-crypt.

> but in LUKS mode, the 
> password is used to decrypt the master key which is in the kernel. If cryptsetup is 
> user mode only, what exactly does the kernel mode decryption of the master key? Can't
> be dm-crypt as this doesn't know anything about LUKS.

cryptsetup (userspace) creates temporary dm-crypt mapping over keyslot area with derived key
generated from passphrase (see above), then read this new dm-crypt device to get data
(and applies AF over it to get master key candidate)

Please read the LUKS documentation and source for exact description (and archive of this list)
http://code.google.com/p/cryptsetup/wiki/Specification

Milan
--
mbroz@redhat.com

Re: [dm-crypt] Mechanics

[Arno Wagner]

On Wed, Dec 02, 2009 at 02:51:47PM +0100, julie_nuckey@trendmicro.co.uk wrote:
> Thanks for the information, but I was hoping for a little more detail.
> 
> I really want to know if it possible for the password/key to be exposed in
> the process of transferring it from user mode to kernel mode, or if it
> could remain in memory as a result, that's why I'm asking about the
> mechanics of what happens between cryptsetup (user mode) and dm-crypt
> (kernel mode).

That really depens on how careful the user-space tool was designed
and what the attacker can do. I think cryptsetup uses locked memory
and wipes it afterwards. That is about all the user space application
can do.

Note however that a root attacker can get the key from kernel space
anyways. Some attacks on DVD encryption have used this (non Linux,
but same principle).

> In "plain" mode the password must be passed to the kernel, but in LUKS
> mode, the password is used to decrypt the master key which is in the
> kernel. 

The master key is on disk in the LUKS header. It is unpacked
by the userspace tool and then give to the kernel, just as a 
user-typed key would be.

> If cryptsetup is user mode only, what exactly does the kernel mode
> decryption of the master key? Can't be dm-crypt as this doesn't know
> anything about LUKS.

Indeed. See above.

> BTW, sorry about the missing line breaks, don't know what happened there. I'll remember
> to put in hard ones in future.

Thanks. Many browser-type mailers also have a config option to
do that automatically. If you have the option, go for <= 72 chars/line.

Arno
 






> 
> -----Original Message-----
> From: dm-crypt-bounces@saout.de [mailto:dm-crypt-bounces@saout.de] On Behalf Of Arno Wagner
> Sent: 02 December 2009 12:21
> To: dm-crypt@saout.de
> Subject: Re: [dm-crypt] Mechanics
> 
> On Wed, Dec 02, 2009 at 12:20:31PM +0100, julie_nuckey@trendmicro.co.uk wrote:
> >
> > I'm trying to understand the mechanics of how dm-crypt and cryptsetup
> > work, in particular how data such as the password/key-file data is passed
> > from user mode to kernel mode, and also generally what does what when
> > setting up an encrypted volume.
> > 
> >
> > 
> > As I understand it, dm-crypt is a pure kernel-mode application that does
> > the encryption and decryption of data on the fly. It works independently
> > of any on-disk format such as metadata like that used by LUKS. Have I got
> > that right?
> 
> Yes. It will happily de-/encrypt random data. No checking at all, not
> a single bit of metadata. Incidentially a dm-crypt volume (after
> an encrypted overwrite) is indistinguishable for a volume wiped
> with cryptographically strong randomness. In fact I use dm-crypt
> to wipe disks: 
>  1.) Set-up with random key (from /dev/random)
>  2.) Overwrite with weak randomness or zeros.
>   
>  
> > And cryptsetup is the pure user-mode application and this can work in
> > "plain" mode, ie without LUKS, or in LUKS mode. Is that right? So how does
> > the password/key get from cryptsetup (user mode) to dm-crypt (kernel mode)
> > and does it differ depending on whether I'm using plain or LUKS mode? Does
> > it use tables? Is the password/key written to the tables?
>  
> My guess would be that the key data is basically the same as for
> directly using ciphers in the kernel. Some call will transfer them.
> No idea about the details, but dm-crypt is basically a device mapper
> target and should use the same mechanisms. The device mapper page
> at http://sources.redhat.com/dm/ may have more information.
>    
> > In LUKS mode, does cryptsetup generate the master key? In user mode? Does
> > cryptsetup create/edit the metadata?
> 
> Yes, AFAIK. The kernel does not understand LUKS.
>   
> > Thanks in advance for any clarification anyone can provide.
> 
> Side note: What about linebreaks? It is not nice to have to reformat
> your message before answering...
> 
> 
> Arno
> 
> 
> -- 
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
> GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
> ----
> Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
> 
> If it's in the news, don't worry about it.  The very definition of 
> "news" is "something that hardly ever happens." -- Bruce Schneier 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> Trend Micro EMEA (GB) Limited, a Limited Liability Company. Registered in England No. 06766734. 
> Registered office: Eversheds House, 70 Great Bridgewater Street, Manchester, M1 5ES
> Trend Micro (UK) Limited, a Limited Liability Company. Registered in England No. 3698292. 
> Registered Office: Pacific House, Third Avenue, Globe Business Park, Marlow, Bucks, SL7 1YL 
> Telephone: +44 1628 400500 Facsimile: +44 1628 400511
> 
> This communication and any accompanying files and attachments are intended only for the recipient to whom it is addressed. 
> If you have received this communication in error, please immediately notify the Sender. You are further notified that any disclosure, 
> copying or other distribution of this communication, including its attachments is strictly prohibited.
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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