Per-tenant encryption in HekaFS
When adding a tenant to a Hekafs cluster one can specify on-disk encryption with AES-CBC algorithm for this tenant.
In a console it can be specified by an option -C (--crypt) of hfs_add_tenant utility. In the web interface one should mark the "Encrypt" box when adding a tenant.
Once encryption is specified, a respective record key-ed with "crypt_username" will be created in the data-base which contains tenant's uid and gid ranges.
When starting a volume hfs_start_volume checks the encryption status for every tenant and pushes oplock translator to the server-side volfile, if encryption is on.
If encryption was specified for some tenant, then in mount time this tenant must provide a cipher key and a salt. Key and salt can be specified separately by different options, or in the same file in a hex form as key'd1'salt'd2', where d1 and d2 - 1-byte delimiters (usually '\n'). Also in mount time one should specify block size for encryption, if it is different from 4K (default value). See man hfs_mount for more details.
Block size is an (extended) attribute of encrypted file, so we need to specify it only for file creation.
If key and salt are specified, then hfs_mount will push a crypt translator with respective option strings to the client-side volfile.
To test encryption
1) have HekaFS sources: git://git.fedorahosted.org/CloudFS.git 2) switch to branch "aes" 3) build and run as usual 4) add a tenant to Hekafs cluster with encryption enabled 5) mount a Hekafs volume with key and salt specified (only 128, 192 and 256 bits keys can be accepted)
What is not yet implemented:
It would be nice to check tenant's encryption status (db_obj["crypt_username"]) in mount time to make sure that oplock and crypt translators are specified together. Otherwise crypt without oplock (as well as oplock without crypt) translator will work incorrectly. Any ideas on how to implement this gracefully are welcome.
Thanks, Edward.
On 03/06/2012 06:53 PM, Edward Shishkin wrote:
What is not yet implemented:
It would be nice to check tenant's encryption status (db_obj["crypt_username"]) in mount time to make sure that oplock and crypt translators are specified together. Otherwise crypt without oplock (as well as oplock without crypt) translator will work incorrectly. Any ideas on how to implement this gracefully are welcome.
When you say "incorrectly" do you mean it would throw errors? My guess is that the initial lock (via fgetxattr) would fail because the xattr isn't there, so the rest of the I/O would fail also. Or do you mean something else?
On 03/08/2012 03:29 PM, Jeff Darcy wrote:
On 03/06/2012 06:53 PM, Edward Shishkin wrote:
What is not yet implemented:
It would be nice to check tenant's encryption status (db_obj["crypt_username"]) in mount time to make sure that oplock and crypt translators are specified together. Otherwise crypt without oplock (as well as oplock without crypt) translator will work incorrectly. Any ideas on how to implement this gracefully are welcome.
When you say "incorrectly" do you mean it would throw errors? My guess is that the initial lock (via fgetxattr) would fail because the xattr isn't there, so the rest of the I/O would fail also. Or do you mean something else?
Hi Jeff,
The problems occur when crypt and oplock xlatorts are not installed together.
If crypt xlator will issue a request, and oplock is absent, then nobody will respond, and we'll wait infinitely.
On the other hand, if crypt xlator is absent and oplock is present, then also bad things will happen.
We can handle this situations on the low-level by issuing/checking special magics by crypt/oplock xlator at create, open, etc. time). However, it would mean additional complex code. So I wondered about high-level means to make sure that crypt and oplock are installed (or not installed) together.
Edward.
cloudfs-devel@lists.fedorahosted.org