Encryption support for lofi(7D). 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. materials/lofiadm.1m 2. materials/lofi.7d