Security Summit November 2009: ZFS Crypto

 

Security Summit November 2009: ZFS Crypto

A Security Summit was held on Tuesday November 3rd, 2009 in Baltimore, Maryland. It ran during LISA '09which runs from November 1-6.

Discussed was security in large system installations with speakers from CTO, technical leaders, customers and community members.

Kicking off the 4th session was a presentation on ZFS Crypto: Data encryption for local, NAS and SAN. The presentation slides are in PDF format.

ZFS Theme

The original overall theme behind the creation of ZFS had been "to create a reliable storage system from inherently unreliable components". This theme is now changing "to create a secured reliable storage system from inherently unreliable components". Universal encryption in conjunction with data integrity had traditionally been considered "too expensive"... the implementation of ZFS helps to demonstrate that this may not be the case any longer.

ZFS Data Integrity

All data in ZFS is written via Copy on Write algorithm, meaning old data is not overwritten, providing for guaranteed data integrity (as long as the underlying hardware does not "lie" when something says it was written.) No RAID write hole in ZFS and no journaling required.

End to end checksums are used for user data as well as meta-data which describes the user data layout, protecting data end-to-end - from disks on remote storage all the way to the host.

ZFS Commands

The ZFS command structure is centered around two basic commands:

• zpool - controls storage pools
• zfs - administer file systems, zvols, and dataset properties

ZFS Crypto Requirements

The requirements driving cryptography extensions to ZFS includes:

• Retain Copy-on-Write semantics
• Integrate into ZFS admin model
• Backward compatibility to existing ZFS pools
• NIST 800-57 Key management recommendations
• Key management delegation to: users, virtualized, and multi-level security environments
• Flexible software encryption policy
• Separate key use vs key change
• Support software only solution 
• Support single disk laptop use cases
• SPARC, Intel, and AMD hardware support
• Support hardware crypto (OpenSPARC T2, Sun PCI-Express CA-6000 cards)
• Local and Remote Key Management

ZFS Encryption Policy

The encryption policy is on the ZFS Data Set (looks like a file system) level.

• Encryption policy set on creation time of the data set
• AES-128, AES-192, or AES-256 available initially
• Encryption sets are to be extensible
• Encryption and Key Management policies are both inherited and delegatable
• Encryption Key is randomly generated
• ZFS checksum is forced to 256SHA for encrypted datasets
  

Key Management

The key management process is flexible

• Wrapping keys can be done by user or admin via: passphrase, raw or hex key, or hardware like smart card
• Weapping key is inherited by child datasets
• Clones share original dataset key, but can have new keys

Key Change or ReKey

U.S. Government NIST 800-57 regulation require a key change every 2 years.

• Wrapping Key change does not re-encrypt old data
• Changes just Wrapping Key users/admins provide
• New data encryption key from change time forward
• New property "rekeyed" to show time of last change
• Key Change or ReKey is an on-line operation
• Internal "libzfs"  C API and scriptable "zfs" interface for external key management

Where's the decrypted data?

Data in DRAM memory (primary cache) is decrypted, data in SSD (secondary cache) or on disk is encrypted.

• ZFS Intent Log is always encrypted 
• ZFS ARC cache holds large amounts of decrypted data (/dev/kmem privileges required to see it)
• Control of decrypted data in caches are controllable by dataset (or filesystem)
• The "Primarycache" (DRAM) and "Secondarycache" (SSD) can be tuned to none, metadata, or all

Use Cases

Various "use cases" are listed in the presentation slides.