* [dm-crypt] Mechanics @ 2009-12-02 11:20 julie_nuckey 2009-12-02 12:20 ` Arno Wagner 0 siblings, 1 reply; 5+ messages in thread From: julie_nuckey @ 2009-12-02 11:20 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dm-crypt] Mechanics 2009-12-02 11:20 [dm-crypt] Mechanics julie_nuckey @ 2009-12-02 12:20 ` Arno Wagner 2009-12-02 13:51 ` julie_nuckey 0 siblings, 1 reply; 5+ messages in thread From: Arno Wagner @ 2009-12-02 12:20 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dm-crypt] Mechanics 2009-12-02 12:20 ` Arno Wagner @ 2009-12-02 13:51 ` julie_nuckey 2009-12-02 14:29 ` Milan Broz 2009-12-02 15:42 ` Arno Wagner 0 siblings, 2 replies; 5+ messages in thread From: julie_nuckey @ 2009-12-02 13:51 UTC (permalink / raw) To: arno, dm-crypt 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dm-crypt] Mechanics 2009-12-02 13:51 ` julie_nuckey @ 2009-12-02 14:29 ` Milan Broz 2009-12-02 15:42 ` Arno Wagner 1 sibling, 0 replies; 5+ messages in thread From: Milan Broz @ 2009-12-02 14:29 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [dm-crypt] Mechanics 2009-12-02 13:51 ` julie_nuckey 2009-12-02 14:29 ` Milan Broz @ 2009-12-02 15:42 ` Arno Wagner 1 sibling, 0 replies; 5+ messages in thread From: Arno Wagner @ 2009-12-02 15:42 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-12-02 15:42 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-12-02 11:20 [dm-crypt] Mechanics julie_nuckey 2009-12-02 12:20 ` Arno Wagner 2009-12-02 13:51 ` julie_nuckey 2009-12-02 14:29 ` Milan Broz 2009-12-02 15:42 ` Arno Wagner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.