From sacadmin Tue Jan 2 10:06:29 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l02I6Ttf018286; Tue, 2 Jan 2007 10:06:29 -0800 (PST) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6/Submit) id l02I6TQn018282; Tue, 2 Jan 2007 10:06:29 -0800 (PST) Date: Tue, 2 Jan 2007 10:06:29 -0800 (PST) From: Darren J Moffat Message-Id: <200701021806.l02I6TQn018282@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: loficc-discuss@opensolaris.org Subject: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] Status: RO Content-Length: 8920 Subject: PSARC FastTrack [01/09/2007]: lofi(7d) crypto support Template Version: @(#)sac_nextcase %I% %G% SMI 1. Introduction 1.1. Project/Component Working Name: lofi(7d) crypto support 1.2. Name of Document Author/Supplier: Author: Darren Moffat 1.3 Date of This Document: 02 January, 2007 4. Technical Description The lofi(7D) driver will gain the ability to encrypt/decrypt the raw blocks. This provides parity with Linux and MacOS X which both have encryption support in their equivalent to the lofi(7D) driver. The administration command lofiadm(7D) is extended to support requesting encryption and setting the key. The default output of lofiadm, with no arguments, shows which lofi devices map to which underlying files, this output will gain an additional column to indicate if encryption is enabled for that device mapping, the values yes or no will be used. The parsable output where a file or device is given does not change. Crypto algorithm support ------------------------ It is not desireable for lofi(7d) to have the encrypted data to take up more space than the clear text data would. For this reason it is not possible to use a separate digest/hmac algorithm as is commonly done in network protocols, eg aes for encryption and hmac-sha1 for integrity protecton of the cipher text. The encrypted block device support on other platforms does not provide any integrity protection support. This means that it is vulnerable to cipher text manipulation. While this is not trivial to do in a way that is advantageous to an attacked it is certainly possible and not just theoretical, and it does at least present a denial of service attack on the data. To ensure we have integrity protection lofi(7D) a future case will introduce a cipher suite that provides a non expanding ciphertext output that has a builtin integrity protection. We expect that that mode will be AES-XEX but are still researching at this time and want to ensure that XEX really does have the desired properties.. Initally however we will be using AES-CBC and like other platforms we won't have the integrity protection. Note that no upgrade will be possible between AES-CBC and AES-XEX (or what ever is selected). Disk format ----------- No indication of the algorithm or key is written to disk, this ensures that no additional space is needed by the lofi(7D) encryption support. This does however mean that no versioning of the on disk format is possible. If an incorrect key value is given then the lofiadm mapping will still succeed but any filesystem layered on it will fail to mount (since the data on the device will not appear to be a filesystem). Key Management -------------- The encryption key can be specified in one of five different ways: 1) Prompt for a passphrase. This is the default if encryption is requested but no key information is given. The passphase is used to generate a symetric encryption key using PKCS#5 PBKD2. 2) A "raw" AES of the appropriate length key in a file. 3) A reference to a PKCS#11 symetric key object If the key is in a "userland" PKCS#11 token such as that provided by pkcs11_softtoken, or a 3rd party smartcard device, and it is extractable it will be extracted in wrapped form and passed to lofi(7D). If the key is not extractable and we can't get the raw key attributes then we will not be able to use this key. If the key reference is for a kernel provided PKCS#11 device it will be used by reference only and not extracted. In this case the kernel crypto provider must support AES CBC. This is the same general model as ksslcfg(1M) uses for providing RSA keys to kssl. The genkey subcommand of pktool(1) can be used to generate these keys. 4) An wrapped AES key in a file. The AES key is unwrapped using an RSA key in a PKCS#11 token. This is needed to support smartcard based operations where the smarcard is not able to store symetric keys; either as a local policy choice or because the token is unable to do so. The smartcard applet used by the ISV Active Identity falls in to this category. It is also desireable to provide this method is a way to do key escrow without the need to escrow the symetric keys, instead the RSA encryption key is escrowed by the card management system (note none of this card management system or PKCS#11 access to smartcards is provided by this case or is it available in Solaris today, 3rd party products are required). 5) If the -e argument is given an ephemeral key is generated internally. The key is never given to the administrator. This means that after the device is detached from lofi (or the system reboots/crashes) the data placed on that device is not recoverable. This is intended only for encrypted swap. Encrypted Swap -------------- Support for encrypted swap devices by using lofi(7D) layered over the physical swap device/file. This support is only available when swap files are specified in vfstab(4) and is enabled by setting a mount option of "encrypted". Note if this support is used then the swap(1M) command will show an lofi device rather than the underlying swap file or device. This uses an emphermal key as described above. If using encrypted swap a separate dedicated dump device must be used since dumps on the encrypted partition are not supported - since dumps on lofi devices are not supported regardless of encryption. Once the device is in use by lofi(7D) it can not be used to dump on, lofi(7d) enforces this. This is not a perfect encrypted swap implementation but the exposed interface is intended to be stable and a possible future case may choose to implement encrypted swap using a method other than lofi(7D). Interaction with encrypted swap and suspend to disk --------------------------------------------------- We could in theory store the key in the TPM for machines that have one, but that is better left for a future case were we do fully encrypted boot support with ZFS and when we actually have support for using the TPM as a keystore. Microsoft Vista has this capability today with BitLocker. Suspend to RAM on x86 is not impacted by this case. Suspend to disk is impacted from a security view point both for encrypted swap and encrypted "disks" since we don't want to ever write the keys to disk in an unwrapped form. Ideally we should be "invalidating" the keys when we prepare for suspend or wrapping them and having some sort of password used on resume to unwrap them. That might require a quite extensive framework and is beyond the scope of this case. This the lofi module currently returns DDI_FAILURE if an attempt to detach it is made and mappings exist. We beleive this may be sufficient to ensure we don't suspend to disk with encrypted lofi devices active. This will be tested before integration and if it is not sufficient we will find a suitable method to ensure that if encrypted lofi mappings exist the suspend to disk will fail. Command Syntax -------------- See materials/lofiadm.1m Example Usage ------------- 1. Prompt for passphrase and derive key: # lofiadm -c aes-cbc-256 -a /dev/dsk/c0t0d0s7 Enter passphrase: 2. Raw AES key in file: # lofiadm -c aes-cbc -a /home/jru/private -k /rmdisk/jru/key 3. Key called 'mykey' in PKCS#11 token 'Sun Software PKCS#11 softtoken': # lofiadm -c aes-cbc -a /home/jru/private \ -T 'Sun Software PKCS#11 softtoken':::mykey Enter token PIN: 4. Key called 'finance' in any any available PKCS#11 token: # lofiadm -c aes-cbc -a /data/finance -T :::finance Enter token PIN: 5. AES key wrapped with PKCS#11 token object named 'ekey' # lofiadm -c aes-cbc -a /data/projectb -T :::ekey \ -k /rmdisk/mykeys/projectb Enter token PIN: Future work ----------- A future case will provide a PAM module and suitable configuration store so that users can have encrypted filesystems provided by lofi(7D) and UFS/PCFS mounted when they login. A future case will also provide users a way to mount and umount their encrypted images on demand using a GUI tool. The above two future projects are deliberately not part of this case so that the interface they present to the user can be compatible with the future ZFS crypto support. They may well deliver before ZFS crypto but at this time they are not sufficiently well specified to support ZFS crypto and lofi(7D) crypto. It is believed that this case is sufficiently complete and useful even if the above mentioned future work was never delivered. References ---------- 1. http://opensolaris.org/project/loficc/files/lofiadm.1m.diff materials/lofiadm.1m.diff 2. http://opensolaris.org/project/loficc/files/lofi.7d.diff materials/lofi.7d.diff 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From Darren.Moffat@sun.com Tue Jan 2 10:20:38 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l02IKbRe018691 for ; Tue, 2 Jan 2007 10:20:37 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l02IKZCl022340 for <@sunmail2.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 2 Jan 2007 18:20:36 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0JB90040O6YAWU00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 02 Jan 2007 10:20:34 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0JB9003BK6Y9ZV00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 02 Jan 2007 10:20:34 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l02IKXfq021503 for ; Tue, 02 Jan 2007 18:20:33 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JB9002016WH1F00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 02 Jan 2007 18:20:32 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JB900FUR6Y7ER10@d1-emea-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 02 Jan 2007 18:20:32 +0000 (GMT) Date: Tue, 02 Jan 2007 18:20:31 +0000 From: Darren J Moffat Subject: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] Sender: Darren.Moffat@sun.com To: PSARC-EXT@sun.com Cc: loficc-discuss@opensolaris.org Message-id: <459AA26F.2060503@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 8907 Template Version: @(#)sac_nextcase %I% %G% SMI 1. Introduction 1.1. Project/Component Working Name: lofi(7d) crypto support 1.2. Name of Document Author/Supplier: Author: Darren Moffat 1.3 Date of This Document: 02 January, 2007 4. Technical Description The lofi(7D) driver will gain the ability to encrypt/decrypt the raw blocks. This provides parity with Linux and MacOS X which both have encryption support in their equivalent to the lofi(7D) driver. The administration command lofiadm(7D) is extended to support requesting encryption and setting the key. The default output of lofiadm, with no arguments, shows which lofi devices map to which underlying files, this output will gain an additional column to indicate if encryption is enabled for that device mapping, the values yes or no will be used. The parsable output where a file or device is given does not change. Crypto algorithm support ------------------------ It is not desireable for lofi(7d) to have the encrypted data to take up more space than the clear text data would. For this reason it is not possible to use a separate digest/hmac algorithm as is commonly done in network protocols, eg aes for encryption and hmac-sha1 for integrity protecton of the cipher text. The encrypted block device support on other platforms does not provide any integrity protection support. This means that it is vulnerable to cipher text manipulation. While this is not trivial to do in a way that is advantageous to an attacked it is certainly possible and not just theoretical, and it does at least present a denial of service attack on the data. To ensure we have integrity protection lofi(7D) a future case will introduce a cipher suite that provides a non expanding ciphertext output that has a builtin integrity protection. We expect that that mode will be AES-XEX but are still researching at this time and want to ensure that XEX really does have the desired properties.. Initally however we will be using AES-CBC and like other platforms we won't have the integrity protection. Note that no upgrade will be possible between AES-CBC and AES-XEX (or what ever is selected). Disk format ----------- No indication of the algorithm or key is written to disk, this ensures that no additional space is needed by the lofi(7D) encryption support. This does however mean that no versioning of the on disk format is possible. If an incorrect key value is given then the lofiadm mapping will still succeed but any filesystem layered on it will fail to mount (since the data on the device will not appear to be a filesystem). Key Management -------------- The encryption key can be specified in one of five different ways: 1) Prompt for a passphrase. This is the default if encryption is requested but no key information is given. The passphase is used to generate a symetric encryption key using PKCS#5 PBKD2. 2) A "raw" AES of the appropriate length key in a file. 3) A reference to a PKCS#11 symetric key object If the key is in a "userland" PKCS#11 token such as that provided by pkcs11_softtoken, or a 3rd party smartcard device, and it is extractable it will be extracted in wrapped form and passed to lofi(7D). If the key is not extractable and we can't get the raw key attributes then we will not be able to use this key. If the key reference is for a kernel provided PKCS#11 device it will be used by reference only and not extracted. In this case the kernel crypto provider must support AES CBC. This is the same general model as ksslcfg(1M) uses for providing RSA keys to kssl. The genkey subcommand of pktool(1) can be used to generate these keys. 4) An wrapped AES key in a file. The AES key is unwrapped using an RSA key in a PKCS#11 token. This is needed to support smartcard based operations where the smarcard is not able to store symetric keys; either as a local policy choice or because the token is unable to do so. The smartcard applet used by the ISV Active Identity falls in to this category. It is also desireable to provide this method is a way to do key escrow without the need to escrow the symetric keys, instead the RSA encryption key is escrowed by the card management system (note none of this card management system or PKCS#11 access to smartcards is provided by this case or is it available in Solaris today, 3rd party products are required). 5) If the -e argument is given an ephemeral key is generated internally. The key is never given to the administrator. This means that after the device is detached from lofi (or the system reboots/crashes) the data placed on that device is not recoverable. This is intended only for encrypted swap. Encrypted Swap -------------- Support for encrypted swap devices by using lofi(7D) layered over the physical swap device/file. This support is only available when swap files are specified in vfstab(4) and is enabled by setting a mount option of "encrypted". Note if this support is used then the swap(1M) command will show an lofi device rather than the underlying swap file or device. This uses an emphermal key as described above. If using encrypted swap a separate dedicated dump device must be used since dumps on the encrypted partition are not supported - since dumps on lofi devices are not supported regardless of encryption. Once the device is in use by lofi(7D) it can not be used to dump on, lofi(7d) enforces this. This is not a perfect encrypted swap implementation but the exposed interface is intended to be stable and a possible future case may choose to implement encrypted swap using a method other than lofi(7D). Interaction with encrypted swap and suspend to disk --------------------------------------------------- We could in theory store the key in the TPM for machines that have one, but that is better left for a future case were we do fully encrypted boot support with ZFS and when we actually have support for using the TPM as a keystore. Microsoft Vista has this capability today with BitLocker. Suspend to RAM on x86 is not impacted by this case. Suspend to disk is impacted from a security view point both for encrypted swap and encrypted "disks" since we don't want to ever write the keys to disk in an unwrapped form. Ideally we should be "invalidating" the keys when we prepare for suspend or wrapping them and having some sort of password used on resume to unwrap them. That might require a quite extensive framework and is beyond the scope of this case. This the lofi module currently returns DDI_FAILURE if an attempt to detach it is made and mappings exist. We beleive this may be sufficient to ensure we don't suspend to disk with encrypted lofi devices active. This will be tested before integration and if it is not sufficient we will find a suitable method to ensure that if encrypted lofi mappings exist the suspend to disk will fail. Command Syntax -------------- See materials/lofiadm.1m Example Usage ------------- 1. Prompt for passphrase and derive key: # lofiadm -c aes-cbc-256 -a /dev/dsk/c0t0d0s7 Enter passphrase: 2. Raw AES key in file: # lofiadm -c aes-cbc -a /home/jru/private -k /rmdisk/jru/key 3. Key called 'mykey' in PKCS#11 token 'Sun Software PKCS#11 softtoken': # lofiadm -c aes-cbc -a /home/jru/private \ -T 'Sun Software PKCS#11 softtoken':::mykey Enter token PIN: 4. Key called 'finance' in any any available PKCS#11 token: # lofiadm -c aes-cbc -a /data/finance -T :::finance Enter token PIN: 5. AES key wrapped with PKCS#11 token object named 'ekey' # lofiadm -c aes-cbc -a /data/projectb -T :::ekey \ -k /rmdisk/mykeys/projectb Enter token PIN: Future work ----------- A future case will provide a PAM module and suitable configuration store so that users can have encrypted filesystems provided by lofi(7D) and UFS/PCFS mounted when they login. A future case will also provide users a way to mount and umount their encrypted images on demand using a GUI tool. The above two future projects are deliberately not part of this case so that the interface they present to the user can be compatible with the future ZFS crypto support. They may well deliver before ZFS crypto but at this time they are not sufficiently well specified to support ZFS crypto and lofi(7D) crypto. It is believed that this case is sufficiently complete and useful even if the above mentioned future work was never delivered. References ---------- 1. http://opensolaris.org/project/loficc/files/lofiadm.1m.diff materials/lofiadm.1m.diff 2. http://opensolaris.org/project/loficc/files/lofi.7d.diff materials/lofi.7d.diff 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack -- Darren J Moffat From sommerfeld@sun.com Tue Jan 2 11:01:10 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l02J1A6t019380 for ; Tue, 2 Jan 2007 11:01:10 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l02J19AM002535; Tue, 2 Jan 2007 11:01:09 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0JB900B1O8TWWR00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Jan 2007 11:01:08 -0800 (PST) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0JB9004AG8TT0620@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Jan 2007 11:01:05 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l02J12Y1014783; Tue, 02 Jan 2007 14:01:02 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l02J12dp020939; Tue, 02 Jan 2007 14:01:02 -0500 (EST) Date: Tue, 02 Jan 2007 14:01:01 -0500 From: Bill Sommerfeld Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <459AA26F.2060503@Sun.COM> To: Darren J Moffat Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <1167764461.20121.13.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> Status: RO Content-Length: 1448 On Tue, 2007-01-02 at 18:20 +0000, Darren J Moffat wrote: > We expect that that > mode will be AES-XEX but are still researching at this time and want to > ensure that XEX really does have the desired properties.. Initally > however we will be using AES-CBC and like other platforms we won't > have the integrity protection. Note that no upgrade will be possible > between AES-CBC and AES-XEX (or what ever is selected). huh? you can't provide integrity protection without some (worst-case) block-by-block expansion to add an integrity check word of some sort. you can avoid expansion from plaintext to ciphertext by using a keystream-based mode (counter mode, OFB, etc.,) or CBC plus ciphertext stealing, but you need additional check bits *somewhere* to provide integrity checks. > Disk format > ----------- > No indication of the algorithm or key is written to disk, this ensures > that no additional space is needed by the lofi(7D) encryption support. > This does however mean that no versioning of the on disk format is > possible. If an incorrect key value is given then the lofiadm mapping > will still succeed but any filesystem layered on it will fail to > mount (since the data on the device will not appear to be a filesystem). I don't see an actual spec for the on-disk format here. What's the actual encryption mode(s) used? Where do additional algorithm parameters (such as the CBC mode IV) come from? - Bill From James.Hughes@Sun.COM Tue Jan 2 15:39:01 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l02Nd1Va024998 for ; Tue, 2 Jan 2007 15:39:01 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l02Nd0R03325; Tue, 2 Jan 2007 16:39:00 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JB900001LP0T600@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Jan 2007 15:39:00 -0800 (PST) Received: from nwk-ea-fw-1.sun.com ([10.4.134.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JB900F9ULOZ6QE0@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Jan 2007 15:38:59 -0800 (PST) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l02Ncxjc004404; Tue, 02 Jan 2007 15:38:59 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JB900L01LNC0900@d1-sfbay-10.sun.com> (original mail from James.Hughes@Sun.COM); Tue, 02 Jan 2007 15:38:59 -0800 (PST) Received: from [10.192.2.200] ([192.18.45.134]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JB900DVWLOWNRBH@d1-sfbay-10.sun.com>; Tue, 02 Jan 2007 15:38:59 -0800 (PST) Date: Tue, 02 Jan 2007 15:36:16 -0800 From: james hughes Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <1167764461.20121.13.camel@thunk> Sender: James.Hughes@Sun.COM To: Bill Sommerfeld Cc: james hughes , Darren J Moffat , PSARC-EXT@Sun.COM, loficc-discuss@opensolaris.org Message-id: <19346D82-BFEC-4DDD-8952-631924EAE078@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> Status: RO Content-Length: 2335 On Jan 2, 2007, at 11:01 AM, Bill Sommerfeld wrote: > On Tue, 2007-01-02 at 18:20 +0000, Darren J Moffat wrote: >> We expect that that >> mode will be AES-XEX but are still researching at this time and >> want to >> ensure that XEX really does have the desired properties.. Initally >> however we will be using AES-CBC and like other platforms we won't >> have the integrity protection. Note that no upgrade will be possible >> between AES-CBC and AES-XEX (or what ever is selected). > > huh? you can't provide integrity protection without some (worst-case) > block-by-block expansion to add an integrity check word of some sort. The XEX does not provide actual integrity protection, it provides a significant improvement over CBC in that the attacker can not make understandable changes to the plaintext without having access to the key. In CBC the data is maleable. In XEX, the data can be randomized by an attacker, but not to any value the attacker can control. The XEX mode is currently being balloted out of the workgroup. This is indeed very close to becoming a standard. http://grouper.ieee.org/groups/1619/email/pdf00046.pdf > you can avoid expansion from plaintext to ciphertext by using a > keystream-based mode (counter mode, OFB, etc.,) or CBC plus ciphertext > stealing, but you need additional check bits *somewhere* to provide > integrity checks. > >> Disk format >> ----------- >> No indication of the algorithm or key is written to disk, this >> ensures >> that no additional space is needed by the lofi(7D) encryption >> support. >> This does however mean that no versioning of the on disk format is >> possible. If an incorrect key value is given then the lofiadm >> mapping >> will still succeed but any filesystem layered on it will fail to >> mount (since the data on the device will not appear to be a >> filesystem). > > I don't see an actual spec for the on-disk format here. There are no changes to the on disk format... > What's the actual encryption mode(s) used? Where do additional > algorithm parameters (such as the CBC mode IV) come from? I do not know how Darren is looking to do this, but a common way to get an implicit IV can be the sector number (offset) encrypted in ECB mode with the key and using that as the IV would be my expectation. > > - Bill > > > > From sommerfeld@sun.com Tue Jan 2 16:58:21 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l030wK9g027456 for ; Tue, 2 Jan 2007 16:58:21 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l030wH6u019827; Wed, 3 Jan 2007 08:58:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JB900705PD4BP00@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Jan 2007 16:58:16 -0800 (PST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JB90023MPD3OY30@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Jan 2007 16:58:15 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l030wDX4016843; Tue, 02 Jan 2007 19:58:13 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l030wBFT022885; Tue, 02 Jan 2007 19:58:11 -0500 (EST) Date: Tue, 02 Jan 2007 19:58:09 -0500 From: Bill Sommerfeld Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <19346D82-BFEC-4DDD-8952-631924EAE078@sun.com> To: james hughes Cc: Darren J Moffat , PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <1167785889.20121.102.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <19346D82-BFEC-4DDD-8952-631924EAE078@sun.com> Status: RO Content-Length: 954 On Tue, 2007-01-02 at 15:36 -0800, james hughes wrote: > > I don't see an actual spec for the on-disk format here. > > There are no changes to the on disk format... This case proposes to change the on-disk format of lofi backing files from always cleartext to occasionally encrypted, but does not describe *how* the encryption is to be performed. > > What's the actual encryption mode(s) used? Where do additional > > algorithm parameters (such as the CBC mode IV) come from? > > I do not know how Darren is looking to do this, but a common way to get > an implicit IV can be the sector number (offset) encrypted in ECB mode > with the key and using that as the IV would be my expectation. I am well aware that there are many ways of doing that. All I want is that the ARC-visible spec for this proposal include details which would allow for us to evaluate whether future proposed changes are consistent with our compatibility guarantees. From Bhargava.Yenduri@sun.com Tue Jan 2 18:22:54 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l032MqdC028643 for ; Tue, 2 Jan 2007 18:22:53 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l032MXGm023208 for <@sunmail3.sfbay.sun.com:PSARC-EXT@Sun.COM>; Wed, 3 Jan 2007 10:22:51 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JB900E09T9Y7Y00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 02 Jan 2007 18:22:46 -0800 (PST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JB9002OIT9YP480@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 02 Jan 2007 18:22:46 -0800 (PST) Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l032Mi03026724; Tue, 02 Jan 2007 18:22:44 -0800 (PST) Received: from [129.146.108.66] (bluesky.SFBay.Sun.COM [129.146.108.66]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l032MhP20553; Tue, 02 Jan 2007 18:22:43 -0800 (PST) Date: Tue, 02 Jan 2007 18:20:23 -0800 From: Krishna Yenduri Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <459AA26F.2060503@Sun.COM> To: Darren J Moffat Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <459B12E7.8080907@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060525 Status: RO Content-Length: 1207 Darren J Moffat wrote: > Key Management > -------------- > The encryption key can be specified in one of five different ways: > > 1) Prompt for a passphrase. > > This is the default if encryption is requested > but no key information is given. The passphase is used to generate > a symetric encryption key using PKCS#5 PBKD2. PKCS #5 requires a random salt to derive the key. This will prevent attacks based on precomputing all the keys from a dictionary of passwords. Solaris commands like encrypt(1) which use PKCS #5 store this salt in the output. But, we won't be able to store the salt in this case. One solution is to have a command line option to pass the salt in a file. > Encrypted Swap > -------------- > Support for encrypted swap devices by using lofi(7D) layered over the > physical swap device/file. This support is only available when swap > files are specified in vfstab(4) and is enabled by setting a mount > option of "encrypted". More of a design issue - Encrypted swap would need crypto services like kcfd to be available early on during boot. Currently this is not the case since cryptosvc depends on svc:/system/filesystem/minimal:default. -Krishna From Darren.Moffat@sun.com Wed Jan 3 02:30:10 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l03AUALT004440 for ; Wed, 3 Jan 2007 02:30:10 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l03AU15N024252; Wed, 3 Jan 2007 02:30:10 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBA0080JFU93Z00@nwk-avmta-2.sfbay.sun.com>; Wed, 03 Jan 2007 02:30:09 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBA0032DFU8PXC0@nwk-avmta-2.sfbay.sun.com>; Wed, 03 Jan 2007 02:30:09 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l03AU701009787; Wed, 03 Jan 2007 10:30:08 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBA00801FNH2S00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 03 Jan 2007 10:30:07 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBA00CJSFU5HH00@d1-emea-09.sun.com>; Wed, 03 Jan 2007 10:30:06 +0000 (GMT) Date: Wed, 03 Jan 2007 10:30:05 +0000 From: Darren J Moffat Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <1167764461.20121.13.camel@thunk> Sender: Darren.Moffat@sun.com To: Bill Sommerfeld Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <459B85AD.4070209@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 2294 Bill Sommerfeld wrote: > On Tue, 2007-01-02 at 18:20 +0000, Darren J Moffat wrote: >> We expect that that >> mode will be AES-XEX but are still researching at this time and want to >> ensure that XEX really does have the desired properties.. Initally >> however we will be using AES-CBC and like other platforms we won't >> have the integrity protection. Note that no upgrade will be possible >> between AES-CBC and AES-XEX (or what ever is selected). > > huh? you can't provide integrity protection without some (worst-case) > block-by-block expansion to add an integrity check word of some sort. > > you can avoid expansion from plaintext to ciphertext by using a > keystream-based mode (counter mode, OFB, etc.,) or CBC plus ciphertext > stealing, but you need additional check bits *somewhere* to provide > integrity checks. > >> Disk format >> ----------- >> No indication of the algorithm or key is written to disk, this ensures >> that no additional space is needed by the lofi(7D) encryption support. >> This does however mean that no versioning of the on disk format is >> possible. If an incorrect key value is given then the lofiadm mapping >> will still succeed but any filesystem layered on it will fail to >> mount (since the data on the device will not appear to be a filesystem). > > I don't see an actual spec for the on-disk format here. I don't think one would be needed since we don't actually store any additional information (unlike what Apple's File Vault does), but I think I understand what you are asking for. Note that I explicitly said that upgrade from AES-CBC to what ever future algorithm we choose, probably AES-XEX, will not be possible. For this reason there shouldn't be a compatibility issue for future algorithms. > What's the actual encryption mode(s) used? That is already specified in the paragraph you quoted above it is AES-CBC. > Where do additional > algorithm parameters (such as the CBC mode IV) come from? As Jim said the IV is implicit so we don't need to store it. I had initially intended just to use the block number but I will do as Jim suggested and have the IV being the block encrypted by the key in ECB mode since this is better. If that answers your questions Bill I'll update the spec. -- Darren J Moffat From sommerfeld@sun.com Wed Jan 3 10:07:39 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l03I7dCQ013504 for ; Wed, 3 Jan 2007 10:07:39 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l03I7dfB004574; Wed, 3 Jan 2007 10:07:39 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBB00L0910Q4500@nwk-avmta-2.sfbay.sun.com>; Wed, 03 Jan 2007 10:07:38 -0800 (PST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBB00C8C10PZS80@nwk-avmta-2.sfbay.sun.com>; Wed, 03 Jan 2007 10:07:37 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l03I7X2M019362; Wed, 03 Jan 2007 13:07:33 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l03I7WTJ026575; Wed, 03 Jan 2007 13:07:32 -0500 (EST) Date: Wed, 03 Jan 2007 13:07:32 -0500 From: Bill Sommerfeld Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <459B85AD.4070209@Sun.COM> To: Darren J Moffat Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <1167847652.26425.32.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> Status: RO Content-Length: 2680 On Wed, 2007-01-03 at 10:30 +0000, Darren J Moffat wrote: > > I don't see an actual spec for the on-disk format here. > > I don't think one would be needed since we don't actually store any > additional information. The encrypted on-disk format is a transformation of the original raw file; you need to specify precisely how that transformation is accomplished. You have not yet done that. > Note that I explicitly said that upgrade from AES-CBC to what ever > future algorithm we choose, probably AES-XEX, will not be possible. Can you be more specific? I don't see anything in the design which would preclude adding new algorithms or algorithm modes; the underlying limit is that you don't have anything to let the system tell whether the user supplied the correct key or to allow for graceful key rollover. I'd think you could rekey and/or change algorithm+mode by creating a new lofi device of the same size and use dd (or whatever) to copy from old to new. > > What's the actual encryption mode(s) used? > > That is already specified in the paragraph you quoted above it is AES-CBC. In this case I'll make an exception but in general I'm never convinced that something is really algorithm agile until they have at least two algorithms available and usable. > > Where do additional > > algorithm parameters (such as the CBC mode IV) come from? > > As Jim said the IV is implicit so we don't need to store it. I had > initially intended just to use the block number but I will do as Jim > suggested and have the IV being the block encrypted by the key in ECB > mode since this is better. > If that answers your questions Bill I'll update the spec. This is still too vague. The disk-block size isn't called out (and the spec needs to be clearer about disk-block vs crypto-block differences). I could assume 512 bytes but I shouldn't need to. Also, the exact way in which the disk-block number is encoded on input to ECB mode needs to be specified. Since some filesystem images -- including both ZFS and PCFS -- can be shared between platforms, this method should be both host-endian and host-bitness independent so that encrypted lofi backing files can be shared). In addition, I think we need a better customer-facing description of what security is and is not provided by this mechanism -- for instance, it's intended to provide confidentiality in the event that the underlying media is stolen, but not in the event that the underlying media is subject to arbitrary manipulation by an attacker. Also we need to document how to rekey, even if it's just a matter of creating a new lofi with the new key and copying from old to new. - Bill From Darren.Moffat@sun.com Wed Jan 3 10:19:12 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l03IJCTM013714 for ; Wed, 3 Jan 2007 10:19:12 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l03IJC3p006663; Wed, 3 Jan 2007 10:19:12 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBB00C0N1JZ1F00@brm-avmta-1.central.sun.com>; Wed, 03 Jan 2007 11:19:11 -0700 (MST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBB000FM1JY3K70@brm-avmta-1.central.sun.com>; Wed, 03 Jan 2007 11:19:11 -0700 (MST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l03IJ9v8010028; Wed, 03 Jan 2007 18:19:09 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBB00K011JAVR00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Wed, 03 Jan 2007 18:19:09 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBB00C4B1JWHH20@d1-emea-09.sun.com>; Wed, 03 Jan 2007 18:19:09 +0000 (GMT) Date: Wed, 03 Jan 2007 18:19:08 +0000 From: Darren J Moffat Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <1167847652.26425.32.camel@thunk> Sender: Darren.Moffat@sun.com To: Bill Sommerfeld Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <459BF39C.2010207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> <1167847652.26425.32.camel@thunk> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 3284 Bill Sommerfeld wrote: > On Wed, 2007-01-03 at 10:30 +0000, Darren J Moffat wrote: > >>> I don't see an actual spec for the on-disk format here. >> I don't think one would be needed since we don't actually store any >> additional information. > > The encrypted on-disk format is a transformation of the original raw > file; you need to specify precisely how that transformation is > accomplished. You have not yet done that. > >> Note that I explicitly said that upgrade from AES-CBC to what ever >> future algorithm we choose, probably AES-XEX, will not be possible. > > Can you be more specific? I don't see anything in the design which > would preclude adding new algorithms or algorithm modes; the underlying > limit is that you don't have anything to let the system tell whether the > user supplied the correct key or to allow for graceful key rollover. I need and that is by design. We are purposely NOT storing the algorithm mode or key length with the device. Rekey is not a goal of this project at least not at the lofi encrypting key level. If you want to rekey then rekey the wrapping key held in the PKCS#11 token. BTW this is no worse, and in fact slightly better, than what Apple is already shipping with FileVault. They do store a header and it has recently been used against them. Some of these problems are best solved by putting crypto into ZFS. The goal of this project is to ship what has being sitting around inside Sun for several years not to stop the bleeding that we have nothing where Linux and MacOS X and now HP-UX has something. > I'd think you could rekey and/or change algorithm+mode by creating a new > lofi device of the same size and use dd (or whatever) to copy from old > to new. Yes that should work. > This is still too vague. The disk-block size isn't called out (and the > spec needs to be clearer about disk-block vs crypto-block differences). > I could assume 512 bytes but I shouldn't need to. Okay I was assuming this was a given from the original lofi case and I didn't need to respecficy it. I agree about the disk-block vs crypto-block. > Also, the exact way in which the disk-block number is encoded on input > to ECB mode needs to be specified. Since some filesystem images -- > including both ZFS and PCFS -- can be shared between platforms, this > method should be both host-endian and host-bitness independent so that > encrypted lofi backing files can be shared). Good point, I'll make sure it is and update the spec to describe how this is done. > In addition, I think we need a better customer-facing description of > what security is and is not provided by this mechanism -- for instance, > it's intended to provide confidentiality in the event that the > underlying media is stolen, but not in the event that the underlying > media is subject to arbitrary manipulation by an attacker. Agreed but is this really architecture or advice for the man pages ? In other words does the ARC need to see this wording to approve this case ? > Also we need to document how to rekey, even if it's just a matter of > creating a new lofi with the new key and copying from old to new. Okay, that is the way it would be done. I can add an example to the man page on how to do this. -- Darren J Moffat From nw141292@binky.Central.Sun.COM Wed Jan 3 13:21:45 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l03LLj6x018556 for ; Wed, 3 Jan 2007 13:21:45 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l03LLgsV006142; Wed, 3 Jan 2007 13:21:43 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBB0050FA05K100@brm-avmta-1.central.sun.com>; Wed, 03 Jan 2007 14:21:41 -0700 (MST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBB00544A04C600@brm-avmta-1.central.sun.com>; Wed, 03 Jan 2007 14:21:40 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l03LLNCq023315; Wed, 03 Jan 2007 15:21:23 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l03LLMht023314; Wed, 03 Jan 2007 15:21:22 -0600 (CST) Date: Wed, 03 Jan 2007 15:21:22 -0600 From: Nicolas Williams Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <459BF39C.2010207@Sun.COM> To: Darren J Moffat Cc: Bill Sommerfeld , PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <20070103212122.GY26175@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> <1167847652.26425.32.camel@thunk> <459BF39C.2010207@Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 595 On Wed, Jan 03, 2007 at 06:19:08PM +0000, Darren J Moffat wrote: > >This is still too vague. The disk-block size isn't called out (and the > >spec needs to be clearer about disk-block vs crypto-block differences). > >I could assume 512 bytes but I shouldn't need to. > > Okay I was assuming this was a given from the original lofi case and I > didn't need to respecficy it. I agree about the disk-block vs crypto-block. The block size might be a good configurable option (e.g., to allow matching a ZFS filesystem/zvol's record size). OTOH, in this case more options -> worse UI. Nico -- From John.Plocher@sun.com Wed Jan 3 14:57:53 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l03Mvq6M021532 for ; Wed, 3 Jan 2007 14:57:52 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l03MveHO011947 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Wed, 3 Jan 2007 22:57:51 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBB00E03EGECI00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 03 Jan 2007 15:57:50 -0700 (MST) Received: from nwk-ea-fw-1.sun.com ([10.4.134.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBB005B8EGDC660@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 03 Jan 2007 15:57:49 -0700 (MST) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l03Mvndc002020 for ; Wed, 03 Jan 2007 14:57:49 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBB00G01EEXGC00@d1-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 03 Jan 2007 14:57:49 -0800 (PST) Received: from [129.146.58.87] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBB00MNEEGCBKSG@d1-sfbay-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 03 Jan 2007 14:57:48 -0800 (PST) Date: Wed, 03 Jan 2007 14:57:42 -0800 From: John Plocher Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <20070103212122.GY26175@binky.Central.Sun.COM> Sender: John.Plocher@sun.com To: Darren J Moffat Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <459C34E6.705@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> <1167847652.26425.32.camel@thunk> <459BF39C.2010207@Sun.COM> <20070103212122.GY26175@binky.Central.Sun.COM> User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) Status: RO Content-Length: 567 Re: Using the filesystem's underlying block/sector/whatever info as part of the crypto chain Naive question: Won't this break in situations where the encrypted data file is moved between dissimilar filesystems? Or am I misunderstanding that part of the conversation? Example: create the encrypted data in a file on a zfs filesystem, un-lofi-mount it, copy the encrypted data file to an USB keychain drive, take it home, move it onto a CDROM and then try to lofi mount it and read the unencrypted data... -John From nw141292@binky.Central.Sun.COM Wed Jan 3 15:24:34 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l03NOYTa022105 for ; Wed, 3 Jan 2007 15:24:34 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l03NOVt07556; Wed, 3 Jan 2007 16:24:31 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0JBB00L0AFOM6U00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 03 Jan 2007 15:24:22 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0JBB00MWZFOLHAB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 03 Jan 2007 15:24:22 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l03NO6ev023517; Wed, 03 Jan 2007 17:24:06 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l03NO6nf023516; Wed, 03 Jan 2007 17:24:06 -0600 (CST) Date: Wed, 03 Jan 2007 17:24:05 -0600 From: Nicolas Williams Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <459C34E6.705@Sun.Com> To: John Plocher Cc: Darren J Moffat , PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <20070103232405.GC26175@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> <1167847652.26425.32.camel@thunk> <459BF39C.2010207@Sun.COM> <20070103212122.GY26175@binky.Central.Sun.COM> <459C34E6.705@Sun.Com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 795 On Wed, Jan 03, 2007 at 02:57:42PM -0800, John Plocher wrote: > Re: Using the filesystem's underlying block/sector/whatever info as part > of the crypto chain > > Naive question: Won't this break in situations where the encrypted data > file is moved between dissimilar filesystems? Or am I misunderstanding that > part of the conversation? I imagine two approaches: 1) let lofi read/write from the backend in some specified block size, but use 512 byte (or whatever other appropriate constant) blocks for encryption 2) let the lofi block size be as specified (2) would have to be kept constant at all times for any one lofi device, else decryption will fail. This is what I meant by more options -> worse UI. If (1) can be done automatically, so much the better. Nico -- From Darren.Moffat@sun.com Thu Jan 4 03:07:15 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l04B7FMX003940 for ; Thu, 4 Jan 2007 03:07:15 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l04B70j3011599 for <@sunmail2.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 4 Jan 2007 11:07:14 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0JBC00E04C81IW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Thu, 04 Jan 2007 03:07:13 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0JBC00GAQC8045E0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Thu, 04 Jan 2007 03:07:12 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l04B7Bvx023948 for ; Thu, 04 Jan 2007 11:07:11 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBC00D01C6CUF00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 04 Jan 2007 11:07:11 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBC003GSC7TCD00@d1-emea-09.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 04 Jan 2007 11:07:06 +0000 (GMT) Date: Thu, 04 Jan 2007 11:07:05 +0000 From: Darren J Moffat Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <459C34E6.705@Sun.Com> Sender: Darren.Moffat@sun.com To: John Plocher Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <459CDFD9.3020000@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> <1167847652.26425.32.camel@thunk> <459BF39C.2010207@Sun.COM> <20070103212122.GY26175@binky.Central.Sun.COM> <459C34E6.705@Sun.Com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 1068 John Plocher wrote: > Re: Using the filesystem's underlying block/sector/whatever info as part > of the crypto chain > > Naive question: Won't this break in situations where the encrypted data > file is moved between dissimilar filesystems? Or am I misunderstanding > that part of the conversation? No it won't, break. Just like it would work today without crypto. Quoting from 1999/463: "lofi intentionally knows nothing about the filesystem above or below it." > Example: create the encrypted data in a file on a zfs filesystem, > un-lofi-mount it, > copy the encrypted data file to an USB keychain drive, > take it home, > move it onto a CDROM and then > try to lofi mount it and read the unencrypted data... That will work just fine. The block size that lofi(7D) works in is fixed as DEV_BSIZE (ie 512) as defined in (which lofi.c gets via ). Because this is they side we read/write to the underlying file it is also the size of chunks we do crypto on. -- Darren J Moffat From Darren.Moffat@Sun.COM Thu Jan 4 03:10:57 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l04BAujt003976 for ; Thu, 4 Jan 2007 03:10:56 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l04BAuv17291 for <@sunmail1brm.central.sun.com:PSARC-EXT@sun.com>; Thu, 4 Jan 2007 04:10:56 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBC00F0DCE7ZU00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Thu, 04 Jan 2007 04:10:55 -0700 (MST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBC00EI2CE6DO70@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Thu, 04 Jan 2007 04:10:54 -0700 (MST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l04BArSj002002 for ; Thu, 04 Jan 2007 11:10:53 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBC00G01CBMQV00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 04 Jan 2007 11:10:53 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBC003INCE4CC00@d1-emea-09.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Thu, 04 Jan 2007 11:10:53 +0000 (GMT) Date: Thu, 04 Jan 2007 11:10:52 +0000 From: Darren J Moffat Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <20070103232405.GC26175@binky.Central.Sun.COM> Sender: Darren.Moffat@Sun.COM To: Nicolas Williams Cc: John Plocher , PSARC-EXT@Sun.COM, loficc-discuss@opensolaris.org Message-id: <459CE0BC.1040600@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> <1167847652.26425.32.camel@thunk> <459BF39C.2010207@Sun.COM> <20070103212122.GY26175@binky.Central.Sun.COM> <459C34E6.705@Sun.Com> <20070103232405.GC26175@binky.Central.Sun.COM> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 1745 Nicolas Williams wrote: > On Wed, Jan 03, 2007 at 02:57:42PM -0800, John Plocher wrote: >> Re: Using the filesystem's underlying block/sector/whatever info as part >> of the crypto chain >> >> Naive question: Won't this break in situations where the encrypted data >> file is moved between dissimilar filesystems? Or am I misunderstanding that >> part of the conversation? > > I imagine two approaches: > > 1) let lofi read/write from the backend in some specified block size, > but use 512 byte (or whatever other appropriate constant) blocks for > encryption lofi always does the read/write in DEV_BSIZE (512) chunks and we always use the same size for crypto. > 2) let the lofi block size be as specified Not this case, it isn't needed for this case and I don't believe it has ever been needed for anything else. If you need variable size "records" use a ZVOL and when ZFS gets crypto you will get encrypted ZVOLs as well. > (2) would have to be kept constant at all times for any one lofi device, > else decryption will fail. This is what I meant by more options -> > worse UI. Indeed and that would mean adding a "header" to the file and then we go down the slippery slope of "well we might as well store other things in there". lofi never had a header and this case can do what it needs without one. Note that the existence of a header with security relevant information in it is part of what lead to the brute force attacks on Apples File Vault in MacOS X being easier than they would otherwise have been. > If (1) can be done automatically, so much the better. That what the code for lofi does today and what the current prototype for crypto does. It always DEV_BSIZE operations. -- Darren J Moffat From sommerfeld@sun.com Tue Jan 9 13:32:59 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l09LWwFt015145 for ; Tue, 9 Jan 2007 13:32:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l09LWY2Q017725; Tue, 9 Jan 2007 21:32:58 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBM00B01EIVK900@nwk-avmta-2.sfbay.sun.com>; Tue, 09 Jan 2007 13:32:55 -0800 (PST) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBM009VNEIU5W10@nwk-avmta-2.sfbay.sun.com>; Tue, 09 Jan 2007 13:32:55 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l09LWrtV025834; Tue, 09 Jan 2007 16:32:53 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l09LWq6S000656; Tue, 09 Jan 2007 16:32:52 -0500 (EST) Date: Tue, 09 Jan 2007 16:32:51 -0500 From: Bill Sommerfeld Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <459BF39C.2010207@Sun.COM> To: Darren J Moffat Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <1168378371.28869.12.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> <1167847652.26425.32.camel@thunk> <459BF39C.2010207@Sun.COM> Status: RO Content-Length: 782 On Wed, 2007-01-03 at 18:19 +0000, Darren J Moffat wrote: > > In addition, I think we need a better customer-facing description of > > what security is and is not provided by this mechanism -- for instance, > > it's intended to provide confidentiality in the event that the > > underlying media is stolen, but not in the event that the underlying > > media is subject to arbitrary manipulation by an attacker. > > Agreed but is this really architecture or advice for the man pages ? > In other words does the ARC need to see this wording to approve this case ? This is architecture. Because the IV is fixed for any given block, lofi may repeatedly encrypt different plaintext with the same {key, IV} combination, which is an "off label" use of the cipher mode. - Bill From Darren.Moffat@sun.com Thu Jan 11 01:31:59 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0B9VwDP002228 for ; Thu, 11 Jan 2007 01:31:58 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0B9Vt5P026881; Thu, 11 Jan 2007 09:31:57 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBP00K056H79900@nwk-avmta-1.sfbay.Sun.COM>; Thu, 11 Jan 2007 01:31:55 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBP00EWC6H6DTD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 11 Jan 2007 01:31:55 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0B9VruA011041; Thu, 11 Jan 2007 09:31:53 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBP00C016CAAO00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 11 Jan 2007 09:31:53 +0000 (GMT) Received: from [192.168.73.102] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBP0021J6H1UG10@d1-emea-09.sun.com>; Thu, 11 Jan 2007 09:31:50 +0000 (GMT) Date: Thu, 11 Jan 2007 09:31:49 +0000 From: Darren J Moffat Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <1168378371.28869.12.camel@thunk> Sender: Darren.Moffat@sun.com To: Bill Sommerfeld Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <45A60405.9050008@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> <1167847652.26425.32.camel@thunk> <459BF39C.2010207@Sun.COM> <1168378371.28869.12.camel@thunk> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 121 I'm extending the timer on this case a week to give me time to answer Bill's outstanding questions. -- Darren J Moffat From roland.mainz@nrubsig.org Thu Jan 11 23:57:15 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0C7vEwj004615 for ; Thu, 11 Jan 2007 23:57:14 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0C7vDKJ020534; Thu, 11 Jan 2007 23:57:13 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBQ00201WRD2300@nwk-avmta-2.sfbay.sun.com>; Thu, 11 Jan 2007 23:57:13 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBQ00KVXWRCK910@nwk-avmta-2.sfbay.sun.com>; Thu, 11 Jan 2007 23:57:12 -0800 (PST) Received: from relay12.sun.com (relay12.sun.com [217.140.40.34] (may be forged)) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0C7umxJ007561; Fri, 12 Jan 2007 00:57:12 -0700 (MST) Received: from mms12es.sun.com ([160.41.223.34] [160.41.223.34]) by relay12.sun.com with ESMTP; Fri, 12 Jan 2007 07:56:47 +0000 (Z) Received: from relay11.sun.com (relay11.sun.com [217.140.40.14]) by mms12es.sun.com with ESMTP; Fri, 12 Jan 2007 07:56:45 +0000 (Z) Received: from mail-in-12.arcor-online.net ([151.189.21.52] [151.189.21.52]) by relay11.sun.com with ESMTP; Fri, 12 Jan 2007 07:56:35 +0000 (Z) Received: from mail-in-08-z2.arcor-online.net (mail-in-08-z2.arcor-online.net [151.189.8.20]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 5A1F4F7B0E; Fri, 12 Jan 2007 08:56:35 +0100 (CET) Received: from mail-in-04.arcor-online.net (mail-in-04.arcor-online.net [151.189.21.44]) by mail-in-08-z2.arcor-online.net (Postfix) with ESMTP id 4BA25212FA7; Fri, 12 Jan 2007 08:56:35 +0100 (CET) Received: from jupiterb48.nrubsig.org (dslb-084-058-204-074.pools.arcor-ip.net [84.58.204.74]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 2DD361BF204; Fri, 12 Jan 2007 08:56:30 +0100 (CET) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id l0C7uSPA005254; Fri, 12 Jan 2007 08:56:28 +0100 (CET) Date: Fri, 12 Jan 2007 08:56:28 +0100 From: Roland Mainz Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] Sender: gisburn@jupiterb48.nrubsig.org To: Darren J Moffat Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <45A73F2C.4ABC82C9@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> Status: RO Content-Length: 1667 Darren J Moffat wrote: > > Template Version: @(#)sac_nextcase %I% %G% SMI > 1. Introduction > 1.1. Project/Component Working Name: > lofi(7d) crypto support > 1.2. Name of Document Author/Supplier: > Author: Darren Moffat > 1.3 Date of This Document: > 02 January, 2007 > 4. Technical Description [snip] > Command Syntax > -------------- > > See materials/lofiadm.1m > > Example Usage > ------------- > > 1. Prompt for passphrase and derive key: > > # lofiadm -c aes-cbc-256 -a /dev/dsk/c0t0d0s7 > Enter passphrase: > > 2. Raw AES key in file: > > # lofiadm -c aes-cbc -a /home/jru/private -k /rmdisk/jru/key > > 3. Key called 'mykey' in PKCS#11 token 'Sun Software PKCS#11 softtoken': > > # lofiadm -c aes-cbc -a /home/jru/private \ > -T 'Sun Software PKCS#11 softtoken':::mykey > Enter token PIN: > > 4. Key called 'finance' in any any available PKCS#11 token: > > # lofiadm -c aes-cbc -a /data/finance -T :::finance > Enter token PIN: > > 5. AES key wrapped with PKCS#11 token object named 'ekey' > > # lofiadm -c aes-cbc -a /data/projectb -T :::ekey \ > -k /rmdisk/mykeys/projectb > Enter token PIN: Is there any way to add support for 1) Kerberos5 and 2) Solaris's secure_rpc API ? Both may be very usefull if data need to be exchanged at sites which have one of these "secure authetification" schemes configured... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From Darren.Moffat@sun.com Fri Jan 12 02:51:37 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0CApbo2008004 for ; Fri, 12 Jan 2007 02:51:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0CApKsa022132 for <@sunmail3.sfbay.sun.com:PSARC-EXT@sun.com>; Fri, 12 Jan 2007 10:51:36 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBR00F0D4TYOK00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 12 Jan 2007 02:51:34 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBR00KZK4TWKD70@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 12 Jan 2007 02:51:33 -0800 (PST) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0CApWMr026847 for ; Fri, 12 Jan 2007 10:51:32 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBR002014OGCN00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 12 Jan 2007 10:51:32 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBR00MX84TSW300@d1-emea-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 12 Jan 2007 10:51:29 +0000 (GMT) Date: Fri, 12 Jan 2007 10:51:28 +0000 From: Darren J Moffat Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <45A73F2C.4ABC82C9@nrubsig.org> Sender: Darren.Moffat@sun.com To: Roland Mainz Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <45A76830.3050404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <45A73F2C.4ABC82C9@nrubsig.org> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 543 Roland Mainz wrote: > Is there any way to add support for 1) Kerberos5 and 2) Solaris's > secure_rpc API ? Both may be very usefull if data need to be exchanged > at sites which have one of these "secure authetification" schemes > configured... GSSAPI/Kerberos are network authentication protocols what we want here is access to an encryption key. Maybe I haven't had enough coffee yet today but I don't understand how you would use Kerberos or GSSAPI in this case, can you expand on the use case a bit more please. -- Darren J Moffat From nw141292@binky.Central.Sun.COM Fri Jan 12 09:52:04 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0CHq3pO014816 for ; Fri, 12 Jan 2007 09:52:04 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0CHpu5W004326; Fri, 12 Jan 2007 17:52:02 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBR00G0TOAM6200@nwk-avmta-1.sfbay.Sun.COM>; Fri, 12 Jan 2007 09:51:58 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBR00H3JOAL0J40@nwk-avmta-1.sfbay.Sun.COM>; Fri, 12 Jan 2007 09:51:58 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0CHpblo012552; Fri, 12 Jan 2007 11:51:37 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0CHpaXM012551; Fri, 12 Jan 2007 11:51:36 -0600 (CST) Date: Fri, 12 Jan 2007 11:51:36 -0600 From: Nicolas Williams Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <45A76830.3050404@Sun.COM> To: Darren J Moffat Cc: Roland Mainz , PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <20070112175136.GQ1010@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <45A73F2C.4ABC82C9@nrubsig.org> <45A76830.3050404@Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 976 On Fri, Jan 12, 2007 at 10:51:28AM +0000, Darren J Moffat wrote: > Roland Mainz wrote: > >Is there any way to add support for 1) Kerberos5 and 2) Solaris's > >secure_rpc API ? Both may be very usefull if data need to be exchanged > >at sites which have one of these "secure authetification" schemes > >configured... > > GSSAPI/Kerberos are network authentication protocols what we want here > is access to an encryption key. > > Maybe I haven't had enough coffee yet today but I don't understand how > you would use Kerberos or GSSAPI in this case, can you expand on the use > case a bit more please. No, I agree: there's no network protocol in lofi(7d), therefore there is no place for RPCSEC_GSS, the GSS-API, or raw Kerberos V here. There may be a protocol layered below lofi (lofi of an NFS-mounted file), or above lofi (sharing a filesystem on a lofi device), but lofi plays no role there. iSCSI is another story. Perhaps Roland was thinking of iSCSI? Nico -- From gww@eng.sun.com Fri Jan 12 10:02:57 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0CI2vFx015338 for ; Fri, 12 Jan 2007 10:02:57 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0CI2vo12535 for <@sunmail3.sfbay.sun.com:PSARC-EXT@sun.com>; Fri, 12 Jan 2007 11:02:57 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBR00701OSVKF00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 12 Jan 2007 10:02:55 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBR00EIDOSU08C0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 12 Jan 2007 10:02:55 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0CI2rgI028332; Fri, 12 Jan 2007 10:02:53 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0CHxsX0008047; Fri, 12 Jan 2007 09:59:54 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0CHxsn2008046; Fri, 12 Jan 2007 09:59:54 -0800 (PST) Date: Fri, 12 Jan 2007 09:59:54 -0800 (PST) From: Gary Winiger Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] To: Darren.Moffat@sun.com, Nicolas.Williams@sun.com Cc: roland.mainz@nrubsig.org, PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <200701121759.l0CHxsn2008046@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 483 > > GSSAPI/Kerberos are network authentication protocols what we want here > > is access to an encryption key. Perhaps the point Roland is making is like Apple Key Chain to have the lofi encryption key available if something like Kerberos or rpcsec_gss is used as the account authority. > iSCSI is another story. Perhaps Roland was thinking of iSCSI? Would that be to unlock a keystore on the machine when logging in that feeds the key to a crypto iSCSI protocol? Gary.. From Darren.Moffat@Sun.COM Fri Jan 12 10:10:03 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0CIA2oF015448 for ; Fri, 12 Jan 2007 10:10:02 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0CIA2o19149 for <@sunmail2.sfbay.sun.com:PSARC-EXT@sun.com>; Fri, 12 Jan 2007 11:10:02 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBR00L0DP4NJP00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 12 Jan 2007 10:09:59 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBR00HVFP4F0M40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 12 Jan 2007 10:09:59 -0800 (PST) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l0CI9oVW006126 for ; Fri, 12 Jan 2007 18:09:50 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JBR00C01P2T7800@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Fri, 12 Jan 2007 18:09:50 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JBR005B3P4EHA10@d1-emea-10.sun.com>; Fri, 12 Jan 2007 18:09:50 +0000 (GMT) Date: Fri, 12 Jan 2007 18:09:50 +0000 From: Darren J Moffat Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <200701121759.l0CHxsn2008046@marduk.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Gary Winiger Cc: Nicolas.Williams@Sun.COM, roland.mainz@nrubsig.org, PSARC-EXT@Sun.COM, loficc-discuss@opensolaris.org Message-id: <45A7CEEE.3050101@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200701121759.l0CHxsn2008046@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061128) Status: RO Content-Length: 1141 Gary Winiger wrote: >>> GSSAPI/Kerberos are network authentication protocols what we want here >>> is access to an encryption key. > > Perhaps the point Roland is making is like Apple Key Chain > to have the lofi encryption key available if something like > Kerberos or rpcsec_gss is used as the account authority. Apple Key Chain is nothing like Kerberos or GSSAPI. We have a keychain in Solaris from GNOME already. The hint in this case that there are follow on projects was a hint that I'm looking at this type of integration. I don't believe we need to provide that for this project to be complete. As it stands this project alone does not allow end users to mount file with lofi and have file system available, since the lofi mapping requires privileges normal users don't have. >> iSCSI is another story. Perhaps Roland was thinking of iSCSI? > > Would that be to unlock a keystore on the machine when logging in > that feeds the key to a crypto iSCSI protocol? iSCSI just needs some security, handwaving and saying that IPsec will solve it all doesn't cut it for many people (me included!). -- Darren J Moffat From gww@eng.sun.com Tue Jan 16 16:52:07 2007 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0H0q7Qw020430 for ; Tue, 16 Jan 2007 16:52:07 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id l0H0q6R07050 for <@sunmail3.sfbay.sun.com:PSARC-EXT@Sun.COM>; Tue, 16 Jan 2007 17:52:06 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBZ0000JMEU2M00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 16 Jan 2007 16:52:06 -0800 (PST) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBZ00GIUMETW640@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 16 Jan 2007 16:52:05 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0H0q3et027321; Tue, 16 Jan 2007 16:52:03 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l0H0qBGu012102; Tue, 16 Jan 2007 16:52:11 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l0H0qBRr012101; Tue, 16 Jan 2007 16:52:11 -0800 (PST) Date: Tue, 16 Jan 2007 16:52:11 -0800 (PST) From: Gary Winiger Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] To: Darren.Moffat@sun.com, gww@eng.sun.com Cc: Nicolas.Williams@sun.com, PSARC-EXT@sun.com, loficc-discuss@opensolaris.org, roland.mainz@nrubsig.org Message-id: <200701170052.l0H0qBRr012101@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 1130 > From Darren.Moffat@Sun.COM Fri Jan 12 10:10:03 2007 > Date: Fri, 12 Jan 2007 18:09:50 +0000 > From: Darren J Moffat > Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] > To: Gary Winiger > Cc: Nicolas.Williams@Sun.COM, roland.mainz@nrubsig.org, PSARC-EXT@Sun.COM, > loficc-discuss@opensolaris.org > Content-transfer-encoding: 7BIT > X-PMX-Version: 5.2.0.264296 > User-Agent: Thunderbird 1.5.0.8 (X11/20061128) > > Gary Winiger wrote: > >>> GSSAPI/Kerberos are network authentication protocols what we want here > >>> is access to an encryption key. > > > > Perhaps the point Roland is making is like Apple Key Chain > > to have the lofi encryption key available if something like > > Kerberos or rpcsec_gss is used as the account authority. > > Apple Key Chain is nothing like Kerberos or GSSAPI. I wasn't saying it did. I was suggesting that perhaps Roland's point was that if a Krb5 ticket or gss_sec certificate was obtained, that could be used to unwrap the encryption key. Since Roland hasn't followed up. I guess it's moot. Gary.. From nw141292@binky.Central.Sun.COM Tue Jan 16 17:54:33 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0H1sWkF023244 for ; Tue, 16 Jan 2007 17:54:33 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l0H1sL3O015384; Wed, 17 Jan 2007 09:54:29 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JBZ00407PAQGA00@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Jan 2007 17:54:26 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JBZ00GOCPAPWA80@nwk-avmta-2.sfbay.sun.com>; Tue, 16 Jan 2007 17:54:26 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l0H1rx68015886; Tue, 16 Jan 2007 19:53:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l0H1rwV6015885; Tue, 16 Jan 2007 19:53:58 -0600 (CST) Date: Tue, 16 Jan 2007 19:53:58 -0600 From: Nicolas Williams Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/09/2007] In-reply-to: <200701170052.l0H0qBRr012101@marduk.eng.sun.com> To: Gary Winiger Cc: Darren.Moffat@sun.com, PSARC-EXT@sun.com, loficc-discuss@opensolaris.org, roland.mainz@nrubsig.org Message-id: <20070117015358.GD1010@binky.Central.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200701170052.l0H0qBRr012101@marduk.eng.sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 945 On Tue, Jan 16, 2007 at 04:52:11PM -0800, Gary Winiger wrote: > > Apple Key Chain is nothing like Kerberos or GSSAPI. > > I wasn't saying it did. I was suggesting that perhaps Roland's > point was that if a Krb5 ticket or gss_sec certificate was > obtained, that could be used to unwrap the encryption key. > > Since Roland hasn't followed up. I guess it's moot. Distributing filesystem keys in network credentials. Sure, we could do that. It'd be a whole separate project though. Also, RFC1510/RFC4120 Kerberos V tickets don't have a way to deliver secret information to the _client_ other than the session key stored in the Ticket -- and that cannot be used as a filesystem key. That would have to wait for RFC1510ter (Kerberos five dot 2, so to speak). In any case, directly sharing your fs keys with a trusted third party, like a KDC, has its pluses, but we should probably consider other key escrow schemes as well. Nico -- From sommerfeld@sun.com Wed Jan 24 10:43:43 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0OIhhG0005749 for ; Wed, 24 Jan 2007 10:43:43 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0OIhgpB015908; Wed, 24 Jan 2007 10:43:43 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCD00105YOV0700@nwk-avmta-2.sfbay.sun.com>; Wed, 24 Jan 2007 10:43:43 -0800 (PST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCD00JDHYOU3E80@nwk-avmta-2.sfbay.sun.com>; Wed, 24 Jan 2007 10:43:42 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0OIheao024752; Wed, 24 Jan 2007 13:43:40 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0OIheFV013898; Wed, 24 Jan 2007 13:43:40 -0500 (EST) Date: Wed, 24 Jan 2007 13:43:39 -0500 From: Bill Sommerfeld Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/31/2007] In-reply-to: <45A60405.9050008@Sun.COM> To: Darren J Moffat Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: <1169664219.12336.31.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> <1167847652.26425.32.camel@thunk> <459BF39C.2010207@Sun.COM> <1168378371.28869.12.camel@thunk> <45A60405.9050008@Sun.COM> Status: RO Content-Length: 274 On Thu, 2007-01-11 at 09:31 +0000, Darren J Moffat wrote: > I'm extending the timer on this case a week to give me time to answer > Bill's outstanding questions. As I haven't seen an answer by this week's meeting, I've extended the timer until next week. - Bill From sommerfeld@Sun.COM Wed Jan 31 10:25:46 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l0VIPkcx023964 for ; Wed, 31 Jan 2007 10:25:46 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l0VIPi5j000896; Wed, 31 Jan 2007 10:25:45 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JCQ0000JWIXAJ00@brm-avmta-1.central.sun.com>; Wed, 31 Jan 2007 11:25:45 -0700 (MST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JCQ00MB9WIXXB00@brm-avmta-1.central.sun.com>; Wed, 31 Jan 2007 11:25:45 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l0VIPgVR023410; Wed, 31 Jan 2007 13:25:42 -0500 (EST) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l0VIPgIn023879; Wed, 31 Jan 2007 13:25:42 -0500 (EST) Date: Wed, 31 Jan 2007 13:25:41 -0500 From: Bill Sommerfeld Subject: Re: lofi(7d) crypto support [PSARC/2007/001 Timeout: 01/31/2007] In-reply-to: <1169664219.12336.31.camel@thunk> To: Darren J Moffat Cc: PSARC-EXT@Sun.COM, loficc-discuss@opensolaris.org Message-id: <1170267941.23158.1.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <459AA26F.2060503@Sun.COM> <1167764461.20121.13.camel@thunk> <459B85AD.4070209@Sun.COM> <1167847652.26425.32.camel@thunk> <459BF39C.2010207@Sun.COM> <1168378371.28869.12.camel@thunk> <45A60405.9050008@Sun.COM> <1169664219.12336.31.camel@thunk> Status: RO Content-Length: 429 On Wed, 2007-01-24 at 13:43 -0500, Bill Sommerfeld wrote: > I'm extending the timer on this case a week to give me time to answer > > Bill's outstanding questions. > > As I haven't seen an answer by this week's meeting, I've extended the > timer until next week. As this has been pushed out three weeks already with no answer seen, I've marked the case "waiting need spec" to more properly reflect the state. - Bill From Darren.Moffat@sun.com Tue Dec 18 10:06:22 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBII6MZt025454 for ; Tue, 18 Dec 2007 10:06:22 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id lBII66OM014541 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Tue, 18 Dec 2007 18:06:21 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT90032BBMIPH00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.com); Tue, 18 Dec 2007 10:06:18 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT90001HBMF6H50@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.com); Tue, 18 Dec 2007 10:06:16 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBII6FmE028092 for ; Tue, 18 Dec 2007 18:06:15 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT900K01BM9XY00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@Sun.com (ORCPT PSARC-EXT@Sun.com); Tue, 18 Dec 2007 18:06:15 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT900I95BME5U30@fe-emea-09.sun.com> for PSARC-EXT@Sun.com (ORCPT PSARC-EXT@Sun.com); Tue, 18 Dec 2007 18:06:15 +0000 (GMT) Date: Tue, 18 Dec 2007 18:06:14 +0000 From: Darren J Moffat Subject: Restarting PSARC/2007/001 lofi(7d) crypto support Sender: Darren.Moffat@sun.com To: PSARC-EXT@sun.com Cc: loficc-discuss@opensolaris.org Message-id: <47680C16.4020903@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 476 I'm restarting PSARC/2007/001 lofi(7d) crypto support (just in time before 2007 runs out :-). Given the closeness to holiday time I'm setting the timer to expire on Wednesday 9th January 2008. The updated spec and supporting material is in the materials/ subdir. The original materials have moved to materials.orig. The updated spec covers how this will "coexist" with the recently added compression support and how fleshes out the ondisk format. -- Darren J Moffat From Alok.Aggarwal@sun.com Tue Dec 18 10:44:44 2007 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id lBIIihGo027498 for ; Tue, 18 Dec 2007 10:44:43 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id lBIIiWNA025842 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 19 Dec 2007 02:44:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JT900J0RDEF0R00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 18 Dec 2007 10:44:39 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JT900DSODECD9C0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 18 Dec 2007 10:44:37 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBIIia7D016308 for ; Tue, 18 Dec 2007 18:44:36 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JT900I01CSU7700@mail-amer.sun.com> (original mail from Alok.Aggarwal@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 18 Dec 2007 11:44:36 -0700 (MST) Received: from sr1-ubrm-46 ([129.147.9.136]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JT900HYBDDGOAD0@mail-amer.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Tue, 18 Dec 2007 11:44:04 -0700 (MST) Date: Tue, 18 Dec 2007 13:44:03 -0500 (EST) From: Alok Aggarwal Subject: Re: Restarting PSARC/2007/001 lofi(7d) crypto support In-reply-to: <47680C16.4020903@Sun.COM> Sender: Alok.Aggarwal@sun.com X-X-Sender: aalok@sr1-ubrm-46 To: Darren J Moffat Cc: PSARC-EXT@sun.com, loficc-discuss@opensolaris.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47680C16.4020903@Sun.COM> Status: RO Content-Length: 1060 On Tue, 18 Dec 2007, Darren J Moffat wrote: > The updated spec and supporting material is in the materials/ subdir. > The original materials have moved to materials.orig. > > The updated spec covers how this will "coexist" with the recently added > compression support and how fleshes out the ondisk format. I can't seem to find a section that specifies exactly what the interaction between the encryption support and the compression support will look like. The lofiadm(1M) man page suggests that a new field "Encrypted" is being added to the display output. It seems it would be better to not add this field but rather extend the "Options" field that was recently added with the compression support to indicate whether a file is encrypted and with which algorithm. Also, adding the "Encrypted" field as the second field of the display output is likely to break existing scripts. The lofi(7D) man page indicates that the encryption metadata isn't stored with or in the lofi image - it looks like this is leftover from the original case materials. Alok From Darren.Moffat@sun.com Wed Jan 9 10:06:44 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09I6iAj029502 for ; Wed, 9 Jan 2008 10:06:44 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09I6ban018892 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 9 Jan 2008 10:06:44 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE00K4J2B74G00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 11:06:43 -0700 (MST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE00EY72B4MX30@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 11:06:40 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m09I6dJ4025192 for ; Wed, 09 Jan 2008 18:06:40 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUE0040121RLM00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 18:06:39 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUE009NQ2B2RV20@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 18:06:38 +0000 (GMT) Date: Wed, 09 Jan 2008 18:06:37 +0000 From: Darren J Moffat Subject: [Fwd: Re: [Fwd: Re: Restarting PSARC/2007/001 lofi(7d) crypto support]] Sender: Darren.Moffat@sun.com To: psarc-ext@sun.com Message-id: <47850D2D.4040509@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 1867 -------- Original Message -------- Subject: Re: [Fwd: Re: Restarting PSARC/2007/001 lofi(7d) crypto support] Date: Fri, 21 Dec 2007 08:43:30 -0800 From: Dina To: Darren J Moffat , Alok Aggarwal References: <476BB401.6010508@Sun.COM> Alok, Let me take care of your question in the immediate, I will followup on opensolaris later. The two features are mutually exclusive, unless I misunderstand your word "interaction", there is none. The user determines on the command line what he will be doing -C/-U for compression, and a bunch of other command line flags for encryption -c/-k/-T/-e. At command line parse time, there is one level of weeding out when creating the lofi. The other level of checking became necessary when we committed to adding the metadata section for encryption. For example, when the lofi image is mapped, then the first block needs to be read to see what's in those first bytes ... which I think you were calling the file signature. Based on what's there, the code needs to determine if it's compressed or encrypted and then branch off to do the right thing depending on what's found in those first few bytes. And there is also some distinction that happens in the strategy function. (So as of this moment, I'm still in merge-surgery ;) to get it all right. I try to spend as little time debugging as I can, so some things take me a bit longer on the front end.) For the other questions of yours, yep, "Options" instead of the old self-centered "Encrypted" is in there, and based on the comment about breaking existing scripts, the order is being changed so it's added after, not before. Thanks for that one. Alok, does that answer the questions for you? Have any others? I'll post this on the discussion site too, just swamped for now. -- Darren J Moffat From Darren.Moffat@sun.com Wed Jan 9 10:08:53 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09I8qg8029641 for ; Wed, 9 Jan 2008 10:08:52 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09I8qUd036413 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 9 Jan 2008 11:08:52 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE0081T2EPET00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Wed, 09 Jan 2008 10:08:49 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE002PU2EM7340@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.COM); Wed, 09 Jan 2008 10:08:47 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m09I8jW4025337 for ; Wed, 09 Jan 2008 18:08:45 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUE009012BHEO00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 09 Jan 2008 18:08:45 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUE009NX2DGRV20@fe-emea-10.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 09 Jan 2008 18:08:04 +0000 (GMT) Date: Wed, 09 Jan 2008 18:08:04 +0000 From: Darren J Moffat Subject: [Fwd: Re: [Fwd: Re: Restarting PSARC/2007/001 lofi(7d) crypto support]] Sender: Darren.Moffat@sun.com To: psarc-ext@sun.com Message-id: <47850D84.8060704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 2565 -------- Original Message -------- Subject: Re: [Fwd: Re: Restarting PSARC/2007/001 lofi(7d) crypto support] Date: Thu, 03 Jan 2008 15:38:05 -0500 (EST) From: Alok Aggarwal To: Dina CC: Darren J Moffat References: <476BB401.6010508@Sun.COM> <476BED32.4020002@sun.com> On Fri, 21 Dec 2007, Dina wrote: > Seems I'm not getting any opensolaris loficc emails, will fix later. > Very irritating.... > > > Alok, > > Let me take care of your question in the immediate, I will followup > on opensolaris later. > > The two features are mutually exclusive, unless I misunderstand your > word "interaction", there is none. The user determines on the command > line what he will be doing -C/-U for compression, and a bunch of other > command line flags for encryption -c/-k/-T/-e. At command line parse > time, there is one level of weeding out when creating the lofi. > > The other level of checking became necessary when we committed to > adding the metadata section for encryption. For example, when the > lofi image is mapped, then the first block needs to be read to see > what's in those first bytes ... which I think you were calling the > file signature. Based on what's there, the code needs to determine > if it's compressed or encrypted and then branch off to do the right > thing depending on what's found in those first few bytes. And there > is also some distinction that happens in the strategy function. The code also needs to prevent encryption of a file compressed with lofi and vice versa. We want to prevent this because, like you point out, the two features are mutually exclusive and they add their own headers. The fact that the two features are disjoint and encryption and compression can't be in play at the same time needs to be mentioned in the ARC case. > (So as of this moment, I'm still in merge-surgery ;) to get it all > right. I try to spend as little time debugging as I can, so some > things take me a bit longer on the front end.) > > For the other questions of yours, yep, "Options" instead of the old > self-centered "Encrypted" is in there, and based on the comment about > breaking existing scripts, the order is being changed so it's added > after, not before. Thanks for that one. The man pages need to be updated as well to reflect the change. > > Alok, does that answer the questions for you? Have any others? Not at the moment. > I'll post this on the discussion site too, just swamped for now. That would be good. Alok -- Darren J Moffat From Darren.Moffat@sun.com Wed Jan 9 10:11:41 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09IBf0n029772 for ; Wed, 9 Jan 2008 10:11:41 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09IBaEj020408 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Wed, 9 Jan 2008 10:11:41 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE0010P2JGHF00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 09 Jan 2008 10:11:40 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE00IK62J9PKB0@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 09 Jan 2008 10:11:34 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m09IBXWe025602 for ; Wed, 09 Jan 2008 18:11:33 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUE008012E08R00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 09 Jan 2008 18:11:33 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUE00DPV2IQH620@fe-emea-09.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 09 Jan 2008 18:11:14 +0000 (GMT) Date: Wed, 09 Jan 2008 18:11:14 +0000 From: Darren J Moffat Subject: PSARC/2007/001 lofi(7d) crypto support Sender: Darren.Moffat@sun.com To: PSARC-EXT@sun.com Cc: loficc-discuss@opensolaris.org Message-id: <47850E42.7050901@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 173 Given the updates from Dina and Alok that I've just forwarded to this case discussion on this case is now complete. This was approved at PSARC today. -- Darren J Moffat From Alok.Aggarwal@sun.com Wed Jan 9 10:22:51 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m09IMpHQ000377 for ; Wed, 9 Jan 2008 10:22:51 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m09IMoFl041155 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 9 Jan 2008 11:22:51 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUE0010D323TH00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 10:22:51 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUE00IUZ322PCC0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 10:22:50 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m09IMoDB015355 for ; Wed, 09 Jan 2008 18:22:50 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUE008010AWCI00@mail-amer.sun.com> (original mail from Alok.Aggarwal@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 11:22:50 -0700 (MST) Received: from sr1-ubrm-46 ([129.147.9.136]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUE00LZG31MI7D0@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 09 Jan 2008 11:22:34 -0700 (MST) Date: Wed, 09 Jan 2008 13:22:34 -0500 (EST) From: Alok Aggarwal Subject: Re: PSARC/2007/001 lofi(7d) crypto support In-reply-to: <47850E42.7050901@Sun.COM> Sender: Alok.Aggarwal@sun.com X-X-Sender: aalok@sr1-ubrm-46 To: Darren J Moffat Cc: psarc-ext@sun.com, loficc-discuss@opensolaris.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47850E42.7050901@Sun.COM> Status: RO Content-Length: 312 On Wed, 9 Jan 2008, Darren J Moffat wrote: > Given the updates from Dina and Alok that I've just forwarded to this > case discussion on this case is now complete. Have the case materials been also updated to reflect the offlist discussion? I see stale materials from Dec 18, 2007 in the case directory. Alok From Darren.Moffat@sun.com Thu Jan 10 02:09:21 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m0AA9KTs029785 for ; Thu, 10 Jan 2008 02:09:21 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m0AA99O1026630 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 10 Jan 2008 10:09:19 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JUF00L07AVJXP00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 Jan 2008 02:09:19 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JUF007HNAVHZID0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 Jan 2008 02:09:17 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m0AA9GvU012372 for ; Thu, 10 Jan 2008 10:09:16 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JUF00101A016M00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 Jan 2008 10:09:16 +0000 (GMT) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JUF008OJAVFKD00@fe-emea-10.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 10 Jan 2008 10:09:16 +0000 (GMT) Date: Thu, 10 Jan 2008 10:09:15 +0000 From: Darren J Moffat Subject: Re: PSARC/2007/001 lofi(7d) crypto support In-reply-to: Sender: Darren.Moffat@sun.com To: Alok Aggarwal Cc: psarc-ext@sun.com, loficc-discuss@opensolaris.org Message-id: <4785EECB.8060206@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <47850E42.7050901@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 378 Alok Aggarwal wrote: > > On Wed, 9 Jan 2008, Darren J Moffat wrote: > >> Given the updates from Dina and Alok that I've just forwarded to this >> case discussion on this case is now complete. > > Have the case materials been also updated to > reflect the offlist discussion? I see stale materials > from Dec 18, 2007 in the case directory. In progress. -- Darren J Moffat