Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
lofi(7d) crypto support [PSARC/2007/001 Timeout:
01/09/2007]
Posted:
Jan 2, 2007 10:20 AM
|
|
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
_______________________________________________
loficc-discuss mailing list
loficc-discuss at opensolaris dot org
http://opensolaris.org/mailman/listinfo/loficc-discuss
|
|
