keysource=raw,file:///root/.crypted.aes-256 -> invalid all zeros key 0

[FransUrbo]

I have an old OpenSolaris (snv_101b) where I created a pkcs#11 key (don't know how to do that on Linux, or what other type of raw type I can use):

turbo@opensolaris:~$ pktool genkey keystore=file outkey=.crypted.aes-256 keytype=aes keylen=256
turbo@opensolaris:~$ md5sum .crypted.aes-256 
9552e5fcf71a0d530bc08ef4404ba47a  .crypted.aes-256

Copying that over to the Linux test machine:

debianzfs-scst:~# ll .crypted.aes-256 
-r-------- 1 root root 32 Apr 28 21:48 .crypted.aes-256
debianzfs-scst:~# md5sum .crypted.aes-256
9552e5fcf71a0d530bc08ef4404ba47a  .crypted.aes-256

When creating a filesystem, I get:

debianzfs-scst:~# zfs create -o encryption=aes-256-gcm -o keysource=raw,file:///root/.crypted.aes-256 share/tests/crypto4
cannot create 'share/tests/crypto4': invalid all zeros key 0

And changing key don't work either:

debianzfs-scst:~# zfs create -o encryption=aes-256-gcm share/tests/crypto4
Enter passphrase for 'share/tests/crypto4': 
Enter again: 
debianzfs-scst:~# zfs key -c -o keysource=raw,file:///root/.crypted.aes-256 share/tests/crypto4
cannot change wrapping key for 'share/tests/crypto4': invalid all zeros key 0

[FransUrbo]

I've been looking into fixing this and found http://opencryptoki.sourceforge.net/ which might be possible to use. At least it have the C_Initialize and the other C_* functions needed (used by SUNW_C_GetMechSession() which I found in pkcs11SUNWExtensions.c in the OpenSolaris11 code).

However, looking quickly at the example program (http://www.ibm.com/developerworks/security/library/s-pkcs/sampleprog.html), it's used (at least started/initialized) slightly different. Maybe not a biggie, but if someone have a better idea (before I spend to much time with this), that would be good.

[lundman]

format accepts three values:
    raw: the raw key bytes
    hex: a hexadecimal key string
    passphrase: a character string that generates a key

locator accepts two values:
    prompt: You are prompted for a key when the dataset is created or mounted
    file:///filename: the key file location in a file system
    pkcs11: A URI describing the location of a key in a PKCS#11 token
    https://location: The key file location on a secure server

This tells me that we aren't quite right. The fix to passphrase,file= submitted recently should actually be raw,file. The key is read byte-for-byte and used as is.

The passphrase,file= should be changed to read the file, then call int crypto_pass2key() to generate a key from the input.

hex,file needs to read the file, then call hexstr_to_bytes(). Which already exists in libzfs_crypto.c.

Now the two tricky ones are pkcs11, and https. If it was just http I would be inclined to just write a function for it, but the SSL part does add extra work.

Most likely additional dependency then would be OpenSSL, as it quite often installed on the system and handled both pkcs11 and https.

However, such dependency is quite annoying, as not everyone needs pkcs11 and https. It would be better then, that autoconf would detect usable openssl and only use it if so. Otherwise return error for pkcs11 and https locators.

[FransUrbo]

I sent a fix for #24, which fixes http. And it seems that curl takes care of https automatically - I had a broken cert chain in my local webserver, and I was refused that keyfile. But it worked through http just fine (even though the key was sent in the clear, it DID work :). So there is no need to do anything special regarding https...

hex I haven't tried (I'm unsure how to create a file/value with hex values).

[lundman]

Yeah but curl isn't currently a dependency. So you probably have it on your platform alright, but it is not optional in autoconf.

If you are going to pull in PKCS support, from say, openssl, then curl is no longer needed

[FransUrbo]

If you look at the commit, I've added all that to, including the dependency in rpm.spec. And OpenSSL needs to be compiled in a special way to get PKCS#11 support.

[lundman]

Ah nice. I personally do not need pkcs support, but for completeness sake it should be done eventually. :) Carry on! :)

[FransUrbo]

So are you using passphrase,prompt then? Because with your latest fix, passphrase,file works fine (and with my fix, so does passphrase,http://.... and passphrase,https://....)

But for some reason I can't see, raw doesn't work. In any form...

[lundman]

Yeah, I can clean up raw and passphrase (since passphrase,file should generate passwords) tomorrow, unless you want a crack at it

[FransUrbo]

I don't have anything else to do, so I'll still do it. But before you fix it (don't have time to fix it now? :), have a look here and see if I managed to do it myself. Because, as I can see, it all looks good.

If locator==prompt
    if format==raw
        read STDIN
    else
        ask for pass
if locator==file
    load file
if locator==http/https
    use curl to retrieve file

/* have a raw key */

if format==raw
    use as is
if format==hex
    convert to bytes
if format==passhprase
    create salt
    convert pass 2 key

This looks exactly as it's supposed to be...

[FransUrbo]

Sorry, never mind! I'm an idiot. tmpkeydata and tmpkeydatalen was unset! Fix is simple:

FransUrbo/zfs@299adb1

with this, both of these works:

debianzfs-scst:!# zfs create -o encryption=aes-256-gcm -o keysource=raw,file:///root/.crypted.aes-256 share/tests/crypto/crypto7
debianzfs-scst:~# zfs create -o encryption=aes-256-gcm -o keysource=raw,http://celia/zfs.key share/tests/crypto/crypto8
debianzfs-scst:~# zfs get -H encryption,keysource share/tests/crypto/crypto7 share/tests/crypto/crypto8
share/tests/crypto/crypto7      encryption      aes-256-gcm     local
share/tests/crypto/crypto7      keysource       raw,file:///root/.crypted.aes-256       local
share/tests/crypto/crypto8      encryption      aes-256-gcm     local
share/tests/crypto/crypto8      keysource       raw,http://celia/zfs.key        local

[FransUrbo]

I now see that you want/think that 'passphrase,file' should generate a password. In my understanding, it shouldn't! It should use a passphrase from a file. As in, a "passphrase in clear text, located in a file"... And this is exactly how it works now. And if this is not it's intended behaviour, I'd much rather have it as is, than change it...

[lundman]

Well, from the Solaris manpage, when it says "passphrase: a character string that generates a key" when used with prompt, we get the string from user, then call crypto_pass2key to make a strong key from that string. It would then imply that passphrase,file does that same, get a string from file, call crypto_pass2key.
Whereas raw,prompt just take bytes from stdin, use as-is. And raw,file do the same but stdin->fopen.

[FransUrbo]

Right, see that now (fixing #21).

This example shows how to create an encrypted ZFS file system that prompts for a key that is stored at an http location.
# zfs create -o encryption=on -o keysource=passphrase,https://keys.example.com/keys/42 tank/home/fs1

But why would it 'prompt for a key', if the key 'is stored at an http location'??

How does it actually work on solaris? Only have an older OpenSolaris (which obviously don't have encryption) so I can't test myself. Does my examples work on Solaris with encryption, or does it ask for a pass even if 'passphrase,file'?

That is:

debianzfs-scst:~# makepasswd --chars=30 > /root/.crypted.pw
debianzfs-scst:~# cat /root/.crypted.pw
5NCnBHt2r2Ezozo3xCYpB0SXta5Jrh
debianzfs-scst:~# zfs create -o encryption=aes-256-gcm -o keysource=passphrase,file:///root/.crypted.pw share/tests/crypto/crypto9
debianzfs-scst:~# zfs get -H encryption,keysource share/tests/crypto/crypto9
share/tests/crypto/crypto9      encryption      aes-256-gcm     local
share/tests/crypto/crypto9      keysource       passphrase,file:///root/.crypted.pw     local