Giter Site home page Giter Site logo

clevis's Introduction

build

Clevis

Welcome to Clevis!

Clevis is a pluggable framework for automated decryption. It can be used to provide automated decryption of data or even automated unlocking of LUKS volumes.

Encrypting Data

What does this look like? Well, the first step is encrypting some data. We do this with a simple command:

$ clevis encrypt PIN CONFIG < PLAINTEXT > CIPHERTEXT.jwe

This command takes plaintext on standard input and produces an encrypted JWE object on standard output. Besides the plaintext, we need to specify two additional input parameters.

First, is the pin. In clevis terminology, a pin is a plugin which implements automated decryption. We simply pass the name of a pin here.

Second, is the config. The config is a JSON object which will be passed directly to the pin. It contains all the necessary configuration to perform encryption and setup automated decryption.

To decrypt our JWE, we simply perform the following:

$ clevis decrypt < CIPHERTEXT.jwe > PLAINTEXT

Notice that no additional input or interaction is required for the decrypt command. Let's look at some more concrete examples.

PIN: Tang

Tang is a server implementation which provides cryptographic binding services without the need for an escrow. Clevis has full support for Tang. Here is an example of how to use Clevis with Tang:

$ echo hi | clevis encrypt tang '{"url": "http://tang.local"}' > hi.jwe
The advertisement is signed with the following keys:
        kWwirxc5PhkFIH0yE28nc-EvjDY

Do you wish to trust the advertisement? [yN] y

In this example, we encrypt the message "hi" using the Tang pin. The only parameter needed in this case is the URL of the Tang server. During the encryption process, the Tang pin requests the key advertisement from the server and asks you to trust the keys. This works similarly to SSH.

Alternatively, you can manually load the advertisement using the adv parameter. This parameter takes either a string referencing the file where the advertisement is stored, or the JSON contents of the advertisement itself. When the advertisement is specified manually like this, Clevis presumes that the advertisement is trusted.

PIN: TPM2

Clevis provides support to encrypt a key in a Trusted Platform Module 2.0 (TPM2) chip. The cryptographically-strong, random key used for encryption is encrypted using the TPM2 chip, and is decrypted using TPM2 at the time of decryption to allow clevis to decrypt the secret stored in the JWE.

For example:

$ echo hi | clevis encrypt tpm2 '{}' > hi.jwe

Clevis store the public and private keys of the encrypted key in the JWE object, so those can be fetched on decryption to unseal the key encrypted using the TPM2.

PIN: Shamir Secret Sharing

Clevis provides a way to mix pins together to provide sophisticated unlocking policies. This is accomplished by using an algorithm called Shamir Secret Sharing (SSS).

SSS is a thresholding scheme. It creates a key and divides it into a number of pieces. Each piece is encrypted using another pin (possibly even SSS recursively). Additionally, you define the threshold t. If at least t pieces can be decrypted, then the encryption key can be recovered and decryption can succeed.

Here is an example where we use the SSS pin with both the Tang and TPM2 pins:

$ echo hi | clevis encrypt sss \
'{"t": 2, "pins": {"tpm2": {"pcr_ids": "0"}, "tang": {"url": "http://tang.local"}}}' \
> hi.jwe

In the above example, we define two child pins and have a threshold of 2. This means that during decryption both child pins must succeed in order for SSS itself to succeed.

Here is another example where we use just the Tang pin:

$ echo hi | clevis encrypt sss \
'{"t": 1, "pins": {"tang": [{"url": "http://server1.local/key"}, {"url": "http://server2.local/key"}]}}' \
> hi.jwe

In this example, we define two child instances of the Tang pin - each with its own configuration. Since we have a threshold of 1, if either of the Tang pin instances succeed during decryption, SSS will succeed.

Binding LUKS Volumes

Clevis can be used to bind a LUKS volume using a pin so that it can be automatically unlocked.

How this works is rather simple. We generate a new, cryptographically strong key. This key is added to LUKS as an additional passphrase. We then encrypt this key using Clevis, and store the output JWE inside the LUKS header using LUKSMeta.

Here is an example where we bind /dev/sda1 using the Tang pin:

$ sudo clevis luks bind -d /dev/sda1 tang '{"url": "http://tang.local"}'
The advertisement is signed with the following keys:
        kWwirxc5PhkFIH0yE28nc-EvjDY

Do you wish to trust the advertisement? [yN] y
Enter existing LUKS password:

Upon successful completion of this binding process, the disk can be unlocked using one of the provided unlockers.

Network based unlocking

If you want to use network based unlocking you will need to specify rd.neednet=1 as kernel argument or use --hostonly-cmdline when creating with dracut.

If you're using Tang with TLS (Example: '{"url": "https://tang.remote"}'), the folder /etc/ssl should be included in the initramfs image, --include /etc/ssl /etc/ssl --force when creating with dracut.

Unlocker: Dracut

The Dracut unlocker attempts to automatically unlock volumes during early boot. This permits automated root volume encryption. Enabling the Dracut unlocker is easy. Just rebuild your initramfs after installing Clevis:

$ sudo dracut -f

Upon reboot, you will be prompted to unlock the volume using a password. In the background, Clevis will attempt to unlock the volume automatically. If it succeeds, the password prompt will be cancelled and boot will continue.

Unlocker: Initramfs-tools

When using Clevis with initramfs-tools, in order to rebuild your initramfs you will need to run:

sudo update-initramfs -u -k 'all'

Upon reboot, it will behave exactly as if using Dracut.

Unlocker: UDisks2

Our UDisks2 unlocker runs in your desktop session. You should not need to manually enable it; just install the Clevis UDisks2 unlocker and restart your desktop session. The unlocker should be started automatically.

This unlocker works almost exactly the same as the Dracut unlocker. If you insert a removable storage device that has been bound with Clevis, we will attempt to unlock it automatically in parallel with a desktop password prompt. If automatic unlocking succeeds, the password prompt will be dismissed without user intervention.

Unlocker: Clevis command

A LUKS device bound to a Clevis policy can also be unlocked by using the clevis luks unlock command.

$ sudo clevis luks unlock -d /dev/sda1

Unbinding LUKS volumes

LUKS volumes can be unbound using the clevis luks unbind command. For example:

$ sudo clevis luks unbind -d /dev/sda1 -s 1

Listing pins bound to LUKS volumes

The pins that are bound to a given LUKS volume can be listed using the clevis luks list command. For example:

$ sudo clevis luks list -d /dev/sda1

Installing Clevis

Please don't install Clevis directly. Instead, use your preferred distribution's packages.

Fedora 24+

This command installs the core Clevis commands, the Dracut unlocker and the UDisks2 unlocker, respectively.

$ sudo dnf install clevis clevis-dracut clevis-udisks2

Manual compilation

As remarked in the previous section, it is suggested not to install Clevis directly. However, in case no Clevis packages exist for your Linux distribution, the steps to manually compile and install Clevis are next ones:

  • Download latest version of the binaries (not that the latest version could change):
$ wget https://github.com/latchset/clevis/releases/download/v19/clevis-19.tar.xz
  • Untar the binaries file:
$ tar Jxvf clevis-19.tar.xz 
  • Create build directory and change path to it:
$ cd clevis-19
$ mkdir build
$ cd build
  • Execute meson to setup compilation:
$ meson setup ..
  • Compile with ninja command:
$ ninja
  • Install with ninja install command (you will need root permissions for it):
$ sudo ninja install

clevis's People

Contributors

abrychcy avatar bviktor avatar crodjer avatar dannf avatar diabonas avatar jbaublitz avatar jlebon avatar jmarcelletti avatar jpds avatar jvymazal avatar ly4096x avatar maage avatar martinezjavier avatar maxistarling56 avatar mtottenh avatar mvollmer avatar noahbliss avatar npmccallum avatar oldium avatar puiterwijk avatar rmetrich avatar rpigott avatar sarroutbi avatar sergio-correia avatar somewhere-or-other avatar tavril avatar therealjuanmartinez avatar tmzullinger avatar travier avatar yo-404 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

clevis's Issues

clevis-luks-udisks2: /usr/bin/clevis-decrypt: line 48: cat: command not found

I'm running Ubuntu 18.04 on my laptop, and I gess Debian will have the same problem.

clevis-luks-udisks2 is added to the desktop session and is started when logging in.
But after plugging an encrypted volume in I get asked for the password.
Log were not really helpful, so I started clevis-luks-udisks2 in a shell session.
This is the output I got:

$ /usr/lib/x86_64-linux-gnu/clevis-luks-udisks2
/dev/sdb1       SLOT    0
/dev/sdb1       META    Success
/usr/bin/clevis-decrypt: line 48: cat: command not found
/usr/bin/clevis-decrypt-tang: line 90: cat: command not found
/dev/sdb1       RCVR    Success (0)
/dev/sdb1       SLOT    1
/dev/sdb1       SLOT    2
/dev/sdb1       SLOT    3
/dev/sdb1       SLOT    4
/dev/sdb1       SLOT    5
/dev/sdb1       SLOT    6
/dev/sdb1       SLOT    7

The offending line is something like this:

    exec "$cmd" < <(echo -n "$hdr."; cat)

On Ubuntu the command lives in /bin/cat - on CentOS we have it in both /bin and /usr/bin.
Additional logging in /usr/bin/clevis-decrypt shows that we have PATH=/usr/bin.
So on Ubuntu we can't decrypt the volume. If I replace cat with /bin/cat
in both scripts encryption works for me.

I'm not sure what the right fix is - as a workaround I did the change noted above.
But is it really correct to have only /usr/bin in the path?

In clevis-luks-udisks2.c line 310 we have:

    if (chld == 0) {
        char *const env[] = { "PATH=" BINDIR, NULL };
        int r = 0;

If you agree I can prepare a pull request changing "cat" into "/bin/cat"
or extend the PATH definition.

What do you think we should do?

Support talking to tang on a Unix Socket

In non-boot cases we may want to use a local tang service (or proxy) and it would be much better if we could talk to it over a unix socket.
It also makes it nice for test suites so you never have to open ports.

LUKS encrypted disk and TPM2

I'm struggling with clevis 9 on CentOS7 right now (with some success) but some question is bothering me: i want to automatically boot host with luks-encrypted disk using TPM2. According to README it is possible. But will i be able to unencrypt this disk on same host booted from other source (other disk, pendrive)?

clevis-dracut fails on tpm2 decryption: tpm2_pcrlist: command not found

Hi,
I'm using Fedora 29 Beta and trying to setup luks v1 disk decryption at boot with clevis tpm2 module.
After fixing module-setup.sh as per issue #73 (removing clevis-decrypt-http and adding cryptsetup) I found the following error at boot:

dracut-initqueue[402]: /usr/bin/clevis-decrypt-tpm2: line 40: tpm2_pcrlist: command not found

So I added the following and regenerate initramfs:

    for cmd in clevis-decrypt-tpm2 \
	tpm2_createprimary \
	tpm2_unseal \
	tpm2_load \
	tpm2_pcrlist; do

	if ! find_binary "$cmd" &>/dev/null; then
	    ((ret++))
	fi
    done

    if (($ret == 0)); then
	inst_multiple clevis-decrypt-tpm2 \
	    tpm2_createprimary \
	    tpm2_unseal \
	    tpm2_load \
	    tpm2_pcrlist
    fi

Now I'm stuck with the following error:

dracut-initqueue[402]: Creating TPM2 primary key failed!

Binding volume works properly.
Currently I'm dual booting with Windows 10, with Bitlocker active, is this setup unsupported?

Best,
Federico Chiacchiaretta

tang installed in a docker container hangs

Hello,
I've installed tang on a server to listen on port 8080, and also deployed this docker container npmccallum/tang-docker-container on the same server, but mapped the docker port 80 to 8090 on the host.
Now, when I access tang installed on the host with 'curl http://localhost:8080/adv' it returns a json right away and finishes. If I try to reach tang on a docker container with 'curl http://localhost:8090/adv' , it returns an incomplete json and hangs in the middle of returning the json. Even if I connect and run bash on the docker itself and access port 80, I have the same hanging:

* About to connect() to localhost port 80 (#0)
*   Trying ::1...
* Connected to localhost (::1) port 80 (#0)
> GET /adv HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost
> Accept: */*
>
<unknown> GET /adv => 200 (src/tangd.c:85)
HTTP/1.1 200 OK
Content-Type: application/jose+json
Content-Length: 1904

{"payload":"eyJrZXlzIjpbeyJhbGciOiJFQ01SIiwiY3J2IjoiUC01MjEiLCJrZXlfb3BzIjpbImRlcml2ZUtleSJdLCJrdHkiOiJFQyIsIngiOiJBV0ZIbjJTb3ZRMHdXQW9LRldBTndEeFRPVk50aTNZUnQ2Mmx0dzBxR0tOZUM5QVpVWDM2enVZbW1aejZYSVBuSlYyUllFQnppN29DbmotamtxaURDNWZJIiwieSI6IkFMQl9XckgwdGxvLVZKS2syVXdGTHJZbkZDUjVROXNxa1A5WG8zSVB3VlNVeWhjOTJBazZBZVNTQ2VxeU80bzdNYzhyLUFSQlJ2eFljSXFSTThxWExQSVoifSx7ImFsZyI6IkVDTVIiLCJjcnYiOiJQLTUyMSIsImtleV9vcHMiOlsiZGVyaXZlS2V5Il0sImt0eSI6IkVDIiwieCI6IkFRYjEtS3pjNkpOLXpUYkloV1dUVUVlWk9YSWFPcXdsMHROYnRIRjBMQ1NnZXJLbHlqeFRJOUFlZ0tDVExaeDVZUXdfQVQtc0NVUy15ZFdLZUMzNXJJeGUiLCJ5IjoiQWZBdEM2Smd0dC10Z3FlTjE4bm1UTndoSS1mZDlQTzRYOTZMMENjR3k4UGtCNzhPd1ZLbEdSb0R1c29KVWplRDZJSHRDSFJLdGZaUG8zbFRFalRqYUVEMyJ9LHsiYWxnIjoiRVM1MTIiLCJjcnYiOiJQLTUyMSIsImtleV9vcHMiOlsidmVyaWZ5Il0sImt0eSI6IkVDIiwieCI6IkFBM1VxUlVnQkZpVGFnaDF4QzdjV29EZG9EMlRqS3JKMUZDVHJaM2JaMmYwcGFvalM1eUxMUFRCNXRMVDI2LW5oOVR6S0VIUnhvVEFNRUxzWEZwYnQtQTEiLCJ5IjoiQUZxMkVpYUY0QmNCdUQ3aFN1bXB4R2

You see the json above is incomplete?

Some extra information from the docker container:

18/10/18@18:20:40: START: http pid=223 from=::1

[root@d6d6ed9e8486 log]# ps -ef | grep 223
root       223     1  0 18:20 ?        00:00:00 tangd /var/cache/tang

[root@d6d6ed9e8486 log]# lsof -p 223
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
tangd   223 root  cwd    DIR   0,37       73 25209984 /
tangd   223 root  rtd    DIR   0,37       73 25209984 /
tangd   223 root  txt    REG   0,37    24224  4963530 /usr/libexec/tangd
tangd   223 root  mem    REG  202,1           4963530 /usr/libexec/tangd (path dev=0,37)
tangd   223 root  mem    REG  202,1           9180790 /usr/lib64/libdl-2.17.so (path dev=0,37)
tangd   223 root  mem    REG  202,1           9204500 /usr/lib64/libpthread-2.17.so (path dev=0,37)
tangd   223 root  mem    REG  202,1           9204575 /usr/lib64/libz.so.1.2.7 (path dev=0,37)
tangd   223 root  mem    REG  202,1           9180777 /usr/lib64/libcrypto.so.1.0.2k (path dev=0,37)
tangd   223 root  mem    REG  202,1           9146075 /usr/lib64/libc-2.17.so (path dev=0,37)
tangd   223 root  mem    REG  202,1           9180808 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 (path dev=0,37)
tangd   223 root  mem    REG  202,1          21120723 /usr/lib64/libhttp_parser.so.2.7.1 (path dev=0,37)
tangd   223 root  mem    REG  202,1          21120733 /usr/lib64/libjansson.so.4.10.0 (path dev=0,37)
tangd   223 root  mem    REG  202,1          21120735 /usr/lib64/libjose.so.0.0.0 (path dev=0,37)
tangd   223 root  mem    REG  202,1           9146051 /usr/lib64/ld-2.17.so (path dev=0,37)
tangd   223 root    0u  IPv6  40292      0t0      TCP localhost:http->localhost:34720 (ESTABLISHED)
tangd   223 root    1u  IPv6  40292      0t0      TCP localhost:http->localhost:34720 (ESTABLISHED)
tangd   223 root    2u  IPv6  40292      0t0      TCP localhost:http->localhost:34720 (ESTABLISHED)```

I see the same behavior on my clevis client. The tang on a host works, and the tang on a container hangs.
Any advise, please?

No requests to the tang server during boot

Hello,
I have bound by clevis luks volume with tang as described in many places. Tang and clevis are on different virtual boxes, Centos 7. As described - the password request appears during boot, but after long delay dracut fails and go to shell. During all this time there are no any requests in the interface on the tang server. Inside dracut shell routing is ok. And with curl I can get the answer from the tang server.

As I see inside /usr/lib/dracut/modules.d/60clevis/clevis-hook.sh only /usr/libexec/clevis-luks-askpass is called. It means that call to the tang server should be initiated by something other. How I can check it? Or what should be additionally configured?

thank you in advance for any comments

U2F Key Support?

There is issue #46 (Yubikey Support) but even cheaper U2F keys (without dedicated HMAC challenge-response mode) can also be used in a challenge-response scheme:

https://jbp.io/2015/11/23/abusing-u2f-to-store-keys.html

The basic idea is to store a U2F key handle in plaintext, and recover the public key from a signature (generated with the key represented by the handle) - the response is then the recovered public key.

Although the blog post links a proof-of-concept implementation it also contains a warning (calls it misuse) . But perhaps supporting something like this in clevis would still make sense.

password pin support

People are interested in the password pin support when clevis is used with sss. This ticket is to track the interest.

Fix clevis-hook.sh installation

As I learned from my first alpha tester, substitution in clevis-hook.sh does not happen. Suggested fix below.

--- a/src/dracut/Makefile.am
+++ b/src/dracut/Makefile.am
@@ -8,5 +8,5 @@ EXTRA_DIST=clevis-hook.sh.in
%: %.in
$(AM_V_GEN)mkdir -p $(dir $@)
$(AM_V_GEN)$(SED) \

  •           -e 's,@libexedir\@,$(libexecdir),g' \
    

--- a/src/dracut/clevis-hook.sh.in
+++ b/src/dracut/clevis-hook.sh.in
@@ -1,2 +1,2 @@
#!/bin/bash
-@libexec@/clevis-luks-askpass
+@libexecdir@/clevis-luks-askpass

Bashisms in tests/

Severity: minor

the scripts pin-http and pin-sss require bash, the given /bin/sh is not sufficient on systems where this is a different shell like in Debian.

(Feel free to ignore this, I'll happily address this in the Debian packaging)

Error/warn user if perfoming luks bind multiple times without specifying slot

After having performed multiple clevis luks bind, and expecting each luks to overwrite the other, I was very confused to see clevis unlock in a setup where unlock should fail.

However, luksmeta seems to explain it: multiple clevis slots had been created, so an old less secure slot was still present after binding to a more secure setting.

Suggested change: if clevis luks bind is executed without specifying slot, and there already is a clevis slot present, clevis luks bind should abort with an error message "Luks binding already present". (Or present a prompt asking user what to do, e.g. "Overwrite", "Abort").

$ sudo luksmeta show -d /dev/sda3
0   active empty
1   active cb6e8904-81ff-40da-a84a-07ab9ab5715e
2   active cb6e8904-81ff-40da-a84a-07ab9ab5715e
3   active cb6e8904-81ff-40da-a84a-07ab9ab5715e
4 inactive empty
5 inactive empty
6 inactive empty
7 inactive empty

clevis and clevis-decrypt: findexe() isn't properly parsing $PATH

Hi,

I believe that the findexe will miss the last $PATH value (unless $PATH ends with a ':'). The read -d: will toss the remaining output after the last ':', as shown below :

$ while read -d: var; do echo $var; done <<< "foo:bar:baz"
foo
bar
$

This is particularly important when called by clevis-luks-udisks2, since the PATH is forced to have a unique entry.

This is my clevis-luks-udisks2 output, caused by clevis unable to findexe clevis-decrypt :

[...]
/dev/dm-3       META    Success

Usage: clevis COMMAND [OPTIONS]

  clevis bind luks    Binds a LUKSv1 device using the specified policy
  clevis decrypt      Decrypts using the policy defined at encryption time
  clevis encrypt http Encrypts using a REST HTTP escrow server policy
  clevis encrypt sss  Encrypts using a Shamir's Secret Sharing policy
  clevis encrypt tang Encrypts using a Tang binding server policy

The following patch helped me to work around that :

diff --git a/src/clevis b/src/clevis
index 80ea9fe..18f4cf8 100755
--- a/src/clevis
+++ b/src/clevis
@@ -19,9 +19,12 @@
 #
 
 function findexe() {
-    while read -d: path; do
+    local ARRAY
+    IFS=':' read -a ARRAY <<< "$PATH"
+
+    for path in "${ARRAY[@]}"; do  
         [ -f "$path/$1" -a -x "$path/$1" ] && echo "$path/$1" && return 0
-    done <<< "$PATH"
+    done
     return 1
 }
 
diff --git a/src/clevis-decrypt b/src/clevis-decrypt
index 69cb9a5..19043c4 100755
--- a/src/clevis-decrypt
+++ b/src/clevis-decrypt
@@ -21,9 +21,12 @@
 SUMMARY="Decrypts using the policy defined at encryption time"
 
 function findexe() {
-    while read -d: path; do
+    local ARRAY
+    IFS=':' read -a ARRAY <<< "$PATH"
+
+    for path in "${ARRAY[@]}"; do  
         [ -f "$path/$1" -a -x "$path/$1" ] && echo "$path/$1" && return 0
-    done <<< "$PATH"
+    done
     return 1
 }

Yubikey support?

I have a POC clevis encrypt/decrypt stub that uses gpg to interact with a stored OpenPGP key on a yubikey, it's something that I've been toying around but it might make sense to include upstream. I'm more than happy to open a PR if there is any interest.

RootFS not being decrypted by clevis-dracut

Hey there,

I'm trying to automatically decrypt my LUKS root partition using clevis-dracut.
Unfortunately it's not working as I expect it.
My environment:

  • Fedora 28 Workstation (clevis packages from official Fedora repos)
  • initramfs regenerated by dracut -f -a clevis

On boot I still get the "normal" password prompt from plymouth.
After starting with rd.debug and rd.break=pre-mount I see in journal that the clevis script (placed in initqueue) is executed much later than systemd-ask-password-plymouth.service.

Am I doing anything wrong or is clevis currently broken with dracut?!

I'm currently playing around with integrating the systemd service into dracut to avoid this problem.

Edit: Removed relation to TPM because I think this is a general problem.

Unlocker for Debian/Ubuntu

Clevis already have support for Dracut, but Dracut is the initramfs manager on RedHat-like systems, Debian, Ubuntu and so on use another tool called initramfs-tools, so would be nice to have a hook for integrate with this tool.

"clevis luks bind" might choose a slot that luksmeta will reject

Version: 11

clevis-luks-bind used to let luksmeta choose the slot, but it now gives the choice to cryptsetup luksAddkey. This means that clevis-luks-bind might end up with a slot that already has luksmeta data in it, and luksmeta will fail.

It's quite easy to end up in this situation:

# clevis luks bind -d /dev/sdb tang '{"url": "http://192.168.100.1:88" }'
The advertisement contains the following signing keys:

2qt04UCwK6sXqTVV9R7Eou4lVXY

Do you wish to trust these keys? [ynYN] y
You are about to initialize a LUKS device for metadata storage.
Attempting to initialize it may result in data loss if data was
already written into the LUKS header gap in a different format.
A backup is advised before initialization is performed.

Do you wish to initialize /dev/sdb? [yn] y
Enter existing LUKS password: <wrong password>
No key available with this passphrase.
1
# luksmeta show -d /dev/sdb
0   active empty
1 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e
2 inactive empty
3 inactive empty
4 inactive empty
5 inactive empty
6 inactive empty
7 inactive empty
# clevis luks bind -d /dev/sdb tang '{"url": "http://192.168.100.1:88" }'
The advertisement contains the following signing keys:

2qt04UCwK6sXqTVV9R7Eou4lVXY

Do you wish to trust these keys? [ynYN] y
Enter existing LUKS password: <correct password>
Error while saving Clevis metadata in LUKSMeta!

I think it would be okay to let luksmeta simply bulldoze over existing data.

Ability to provide bind-luks answers via arguments and/or answer file

Having the ability to provide clevis bind-luks answers through some means other than answering interactive questions would be a huge benefit for automated enterprise environments. Specifically:

  • advertisement to trust (something like --trust=l3w1mHLN9Yz_KNJU4e4RifVMUr4 --trust=l3w1mHLN9Yz_KNJU4e4RifVMUr4,etc)
  • initialize luks-meta (--init-meta=yes)
  • existing LUKS passphrase (--passprhase=example)

And/or providing an answer file would be helpful, maybe a json file.

Add /dev/tpm* permissions to clevis user

Currently, TPM2 unlock doesn't work in the desktop use case because the user session doesn't have access to the TPM device node. I think it would be sufficient to add a udev rule for the clevis system user.

Improve clevis bind-luks error reporting

During testing, I've found that some LUKS clients are able to bind to a tang server, whereas others report:

[root@test03 ~]# clevis bind-luks /dev/vda2 tang '{"url": "http://fqdn"}'
The advertisement is signed with the following keys:
l3w1mHLN9Yz_KNJU4e4RifVMUr4

Do you wish to trust the advertisement? [yN] y
Error creating binding!

However, there is virtually no information as to why this failed. Please improve error reporting in clevis to provide more information as to why things failed.

Unable to use root volume on Ubuntu 18.04

On Ubuntu 18.04, I can get secondary volumes with clevis to work but root volumes are giving me issues unlocking at bootup since they still require a password, despite following documented steps. Anyone have an idea what is wrong or if this is a bug?

/etc/fstab

root@cisadmin-VirtualBox:~# cat /etc/fstab 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/sda5_crypt /               ext4    defaults,_netdev 0       2
# /boot was on /dev/sda1 during installation
UUID=45c8c1b2-3558-43d1-9e41-cf49dccf4ab2 /boot           ext4    defaults        0       2
/swapfile                                 none            swap    sw              0       0

/etc/crypttab

root@cisadmin-VirtualBox:~# cat /etc/crypttab 
sda5_crypt UUID=5ed3b55e-0e4a-41fb-99c5-fb1b467a738d	none	_netdev
root@cisadmin-VirtualBox:~#
root@cisadmin-VirtualBox:~# blkid
/dev/mapper/sda5_crypt: UUID="8d8941f6-af80-434a-9b48-40ed52cec6c6" TYPE="ext4"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/sda1: UUID="45c8c1b2-3558-43d1-9e41-cf49dccf4ab2" TYPE="ext4" PARTUUID="35fc3636-01"
/dev/sda5: UUID="5ed3b55e-0e4a-41fb-99c5-fb1b467a738d" TYPE="crypto_LUKS" PARTUUID="35fc3636-05"
root@cisadmin-VirtualBox:~# lsblk
NAME           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0            7:0    0  86.9M  1 loop  /snap/core/4917
loop1            7:1    0  34.7M  1 loop  /snap/gtk-common-themes/319
loop2            7:2    0 140.9M  1 loop  /snap/gnome-3-26-1604/70
loop3            7:3    0   2.3M  1 loop  /snap/gnome-calculator/180
loop4            7:4    0   3.7M  1 loop  /snap/gnome-system-monitor/51
loop5            7:5    0  14.5M  1 loop  /snap/gnome-logs/37
loop6            7:6    0    13M  1 loop  /snap/gnome-characters/103
sda              8:0    0    10G  0 disk  
├─sda1           8:1    0   476M  0 part  /boot
├─sda2           8:2    0     1K  0 part  
└─sda5           8:5    0   9.5G  0 part  
  └─sda5_crypt 253:0    0   9.5G  0 crypt /
sr0             11:0    1  1024M  0 rom   
root@cisadmin-VirtualBox:~# 
root@cisadmin-VirtualBox:~# cryptsetup luksDump /dev/sda5
LUKS header information for /dev/sda5

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha256
Payload offset:	4096
MK bits:       	512
MK digest:     	c5 9e 51 60 01 24 ec a9 58 99 9a 1d 68 7d a8 ae 74 dc 3f 95 
MK salt:       	a8 99 82 36 0a 62 83 49 fe 39 1d f2 17 35 0d 24 
               	80 57 66 93 53 99 74 c1 f3 03 86 1e 36 fd 0c f3 
MK iterations: 	94025
UUID:          	5ed3b55e-0e4a-41fb-99c5-fb1b467a738d

Key Slot 0: ENABLED
	Iterations:         	1504412
	Salt:               	a6 b9 ac e9 f9 77 94 74 cb 2b 35 b0 64 61 6f f9 
	                      	18 52 34 f7 b2 ed 6e 5e c6 52 4f 53 0a f4 9a 31 
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: ENABLED
	Iterations:         	1148494
	Salt:               	9d 6e b5 7a 02 d8 de a6 3d 82 4f 30 49 ca fb 02 
	                      	8d d0 76 c5 8d 0b bd 81 fe 41 c3 e6 03 81 fe c8 
	Key material offset:	512
	AF stripes:            	4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
root@cisadmin-VirtualBox:~# 

Support max attempts for pins that prompt for input

Currently the clevis pwd pin prompts forever. It does not terminate
on ^C or give up on empty input. This is reasonable behaviour for
early boot (disk unlock) use case but we need a way to limit
the number of attempts for other use cases, e.g. TLS private keys.

We could either add an "attempts" field in the JSON, understood by
"pwd" pin, or use an envvar. Maybe there are other options.

Other pins would probably want the same option, e.g. a TOTP pin.

Encrypt SSS index

Public indices can be used in a cheating attack. These should be encrypted.

KDF Timing Attack

The current method of measuring for KDF time would allow an attacker to detect provisioning and generate a significant number of interrupts to lower the number of iterations for a later brute force attack.

"Unbinding"

Is there a process for unbinding clevis from a LUKS partition?

Also, what about changing a Tang Server name or adding additional ones after you've already set it up on a single server initially.

Cheers

Issues registering with Tang server

Hi all.

I've just been building a new Tang setup, and having issues registering against out tang servers. I've built a fresh CentOS 7 VM as the client with Clevis installed on it, but when registering and i'm supposed to be prompted for the current LUKS password, it just skips/exits. (See attached screenshot)

clevis

Any suggestions?

I've tried rebooting a few times, and this machine can curl the /adv URL of the Tang server OK.

Integration with KMIP

Hi,
sorry for opening an issue as this is more a question than an issue but there is no user-mailing list :)

we have a kmip (https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip) capable solution for storing encryption keys. So I have the general question if this could integrate with clevis or if a future integration is on the roadmap for clevis. I would like to use it to a similar manner as root filesystems are unlocked using tang.

Greetings
Klaas

Clevis using TPM2 PIN not unlocking the LUKS device Automatically after unplugging and plugging device, unlike the case with Clevis using Tang PIN

I am using NUC8i7HVK with fimware TPM2, I have a LUKS device on which clevis using TPM2 PIN setup. Clevis is unable to unlock (decrypt) the device automatically, It is unlocking the device only when the unlock command is executed every time it is mounted. However, i am able to unlock the device automatically(unlock command run only once initially during the setup) even after rebooting or unplugging and plugging the device any number of times, with clevis using Tang PIN. Below are the binding and unlocking steps followed.

Using TPM2 PIN
$ sudo clevis luks bind -d /dev/sda1 tpm2 '{}'
$ sudo clevis luks unlock -d /dev/sda1

Using Tang PIN
$ sudo clevis luks bind -d /dev/sda1 tang '{"url": "http://localhost:80"}'
$ sudo clevis luks unlock -d /dev/sda1

Clevis bind should not silence character echo after ctrl-c

When running clevis bind luks cancelling out at the LUKS password prompt by hitting ctrl-c kills the character echo for the shell. The user must either kill the shell or blindly type reset to restore the terminal. Clevis commands should act like normal password prompts that are cancelled.

[root@happy ~]# clevis bind luks -d /dev/sda2 sss \
'{"t":1, "pins": {"tang": [{"url":"http://tang1.example.com"}, {"url":"http://tang2.example.com"}]}}'
The advertisement contains the following signing keys:

XXXXXXXXXXXXXXXXXXXXXXXX

Do you wish to trust these keys? [ynYN] y
The advertisement contains the following signing keys:

YYYYYYYYYYYYYYYYYYYYYYYY

Do you wish to trust these keys? [ynYN] y
Enter existing LUKS password: [root@happy ~]# [root@happy ~]# 

clevis-luks-askpass nc dependency failure (systemd late boot unlocking) on Ubuntu18

nc --send-only used in clevis-luks-askpass is not universal and fails upon boot (Ubuntu18).

sudo clevis-luks-askpass 
nc: invalid option -- '-'
usage: nc [-46CDdFhklNnrStUuvZz] [-I length] [-i interval] [-M ttl]
	  [-m minttl] [-O length] [-P proxy_username] [-p source_port]
	  [-q seconds] [-s source] [-T keyword] [-V rtable] [-W recvlimit] [-w timeout]
	  [-X proxy_protocol] [-x proxy_address[:port]] 	  [destination] [port]

The following change appears to resolve problem on my Ubuntu18:

#                echo -n "+$pt" | nc -U -u --send-only "$s"
                echo -n "+$pt" | nc -U -u -w2 "$s"

"clevis blah" exits successfully

# clevis blah

Usage: clevis COMMAND [OPTIONS]

  clevis decrypt      Decrypts using the policy defined at encryption time
  clevis encrypt http Encrypts using a REST HTTP escrow server policy
  clevis encrypt sss  Encrypts using a Shamir's Secret Sharing policy
  clevis encrypt tang Encrypts using a Tang binding server policy

# echo $?
0

TPM 2.0 support needs to be optional

We can't unconditionally install it because it only works where there is corresponding hardware. Thus, we need to detect the presence of tpm2-tools and conditionally install tpm2 support.

System fails to boot without wired network

Running Fedora 28 on an HP Spectre x360, boot fails because there is no wired network interfaces, but this should not be needed for tpm2 unlocking. Currently I have got it working by modifying /usr/lib/dracut/modules.d/60clevis/module-setup.sh as such:

depends() {
    echo crypt systemd #network
    return 0
}

cmdline() {
    #echo "rd.neednet=1"
    return 0
}

However, this is a hacky workaround and there are errors logged at every boot, it seems to work as expected but I have not done much testing.

Perhaps there is a better way to achieve this that I'm not seeing?

Or possibly the network dependencies should be removed in configurations that don't require them?

Integration with ignition for TPM2 provisioning, creation of encrpyted drives

Ignition is a distribution-agnostic first boot installer and configuration tool from CoreOS and is being integrated into the combined Fedora CoreOS / RHCOS platforms.

https://github.com/coreos/ignition
https://github.com/coreos/ignition/blob/master/doc/rationale.md

It would be useful to be able to integrate clevis into ignition (or visa versa) for dealing with TPM2 provisioning and dealing with disk encryption using TPM2 at install/creation time as part of the ignition provisioning process.

clevis-encrypt-sss strange bahavior

clevis-encrypt-sss prints something to the stdout when I specified that I do not trust these keys.

$ echo sadasds | clevis encrypt sss '{"t":1,"pins":{"tang":[{"url":"http://tang.srv"}]}}'
...
+ read -r -p 'Do you wish to trust these keys? [ynYN] ' ans
Do you wish to trust these keys? [ynYN] n
+ [[ n =~ ^[yY]$ ]]
+ exit 1
eyJhbGciOiJkaXIiLCJjbGV2aXMiOnsicGluIjoic3NzIiwic3NzIjp7Imp3ZSI6WyIiXSwicCI6InpIRUhVX2I3a2xuVUVMMUJLUkZ2aURSRVJSMlQxcm12bHoyVXlaLS1SVGMiLCJ0IjoxfX0sImVuYyI6IkEyNTZHQ00ifQ..rBvN-nYRDwZpObQ4.-CO_ELAzD4Q.nqd4BX4thkxCpxwEXV8_ww

When I choose "y" it behaves as expected.

Do you wish to trust these keys? [ynYN] y
eyJhbGciOiJkaXIiLCJjbGV2aXMiOnsicGluIjoic3NzIiwic3NzIjp7Imp3ZSI6WyJleUpoYkdjaU9pSkZRMFJJTFVWVElpd2lZMnhsZG1seklqcDdJbkJwYmlJNkluUmhibWNpTENKMFlXNW5JanA3SW1Ga2RpSTZleUpyWlhseklqcGJleUpoYkdjaU9pSkZRMDFTSWl3aVkzSjJJam9pVUMwMU1qRWlMQ0pyWlhsZmIzQnpJanBiSW1SbGNtbDJaVXRsZVNKZExDSnJkSGtpT2lKRlF5SXNJbmdpT2lKQlVFdEllalJtUzJSWU5IQlVURTUzYkVSeWFUUmZOSEk0Y21aZlJHRjROQzE1V2pKSVQxZGtkMFF3Ym05NmFHOVNaa2RUUmpOdFQxbG1SMk42ZDJVd1JVUmpZbEprV2xSamNtRkRWbGw2TFhoV2QydFZTRkZpSWl3aWVTSTZJa0ZNTlc5YVpDMUJablkzVUdGdFdGZGlUVmwyU21kRWNVOHlaVFJPVkd0UVdIcEdRM1UwV1cxUFVuVkxha0pYU0djeFUzUnhhR0Y2VDAxcE1uSldTMVZwUTJwalkzQjBZVE14ZEdOcE1URmlTVTA1ZVhCUWJYa2lmU3g3SW1Gc1p5STZJa1ZUTlRFeUlpd2lZM0oySWpvaVVDMDFNakVpTENKclpYbGZiM0J6SWpwYkluWmxjbWxtZVNKZExDSnJkSGtpT2lKRlF5SXNJbmdpT2lKQlVIazFkV1paVnpGcmJVSkllRzgyY0ZkQlR6azNaWGQ1U0daQk1rVjVXV015UWxkQ05FdzRjM1Z5VWkxeVEwcHlRMDFCTW5kcFVVNW9iMGhRY1RCUU4zcE1ZMDQ0Vmpkb2JVMWlRVXRqVkVoMWRIQmxkM3BOSWl3aWVTSTZJa0ZNUWtVMWExQlBPWHBOY0hWSmVtVlBPRWxtV1dVMFdrczNNV1p1T1VOQkxVaGhZa2t0VW1kdGVrOXVWR2sxVUVOWlJsbEtUWEZLVjBGQ2MxazNaMWhmZVdKbE5WOW5ZbWhuZEVSSVIzWkxXakZJWkRRNVNXY2lmVjE5TENKMWNtd2lPaUpvZEhSd09pOHZkR0Z1Wnk1emNuWWlmWDBzSW1WdVl5STZJa0V5TlRaSFEwMGlMQ0psY0dzaU9uc2lZM0oySWpvaVVDMDFNakVpTENKcmRIa2lPaUpGUXlJc0luZ2lPaUpCVVV0emRHOW1WRmRCVGpGR2JWaFFNMjVhTm5wM1lYSkZWa1ZKTm5OdGRIUTRSVmhRTkhJNWRISlJlVkJtTkdZeE5uSjFOV2R2WXpNMmNXMDNWMnRMYUc4dGJtWndNVlEwYVc1YVlsZFdSSGczT1RkQ1VEVnpJaXdpZVNJNklrRmhibGQxV1RCTk9FcFRNVUZsTUVKWlQyRllVaTFYVTJWMGIyMTFUM2RTVFV4ZlZHNWFTRkpJT0RaM1ZEUXplWGRaUW5vdFVXcHZjMmMzYmpOdVozRjZNVVJDUjJGdlRtVmtXWEI0TmpCMVgxQllUVVZvWW1JaWZTd2lhMmxrSWpvaU1WQmFiekJQZERSdVdtUkdWV3hJTUZsamJFWnRNamgwYjBOWkluMC4uRkZrWFp3d1pJWkstd1NPMi45V2Q0amN6b2F1ZFNqWmRLcDF1QWJBSHZOdlIwTnc3UmJjV0Fzci1jOV9uQXlISF9vbElMTkdQRjE2V2VWTmN6MnUxY2U0T3NBalNLVTBjaDJwdng1dy5XYklGSkNfRWI3RTJVSUlYMUlBWmt3Il0sInAiOiJ4U0EwczVMalNMUkF3dm9nYUxmZVZpZ3dqQy1fQXo2d3pobW94VTFKWUtNIiwidCI6MX19LCJlbmMiOiJBMjU2R0NNIn0..sRSXLAzoGTJwmnKg.qkyRpo_eye8.nUnjq61i2_ChjhzQuF5xmQ

Typo in manpages

More nitpicking ...

advertisment -> advertisement

Found by lintian in clevis-encrypt-tang.1 and clevis.1

Encrypting data with the tpm2 pin fails when using the clevis user on Fedora

To encrypt data using the tpm2 pin some temporary files have to be created. Currently, these are created using mktemp in the user $HOME with mktemp -d -p ~.

The Fedora clevis package, adds a clevis user whose home directory is /var/cache/clevis. But this, doesn't exist and so the following command fails:

$ echo foobar | sudo -u clevis clevis encrypt tpm2 '{}'
mktemp: failed to create directory via template ‘/var/cache/clevis/tmp.XXXXXXXXXX’: No such file or directory
Creating a temporary dir for TPM files failed!

The rationale for creating the temporary files at $HOME instead of /tmp, was to avoid exposing this unnecessarily. But mktemp by default creates the directories with u+rwx anyways so I think it shouldn't matter to have it at /tmp instead.

Regardless, it doesn't sound correct to have /var/cache/clevis as the clevis user's home dir, unless the tools make sure that this will always exist for the pins that want to use it.

Trouble unlocking multiple disks at boot

OS: Fedora 28
/etc/crypttab:

# <name>  <device>     <password>     <options>
shdd	UUID=3fa44569-ca47-472e-ab7d-3cec0b0523fe none luks # system doesn't boot and disks aren't unlocked if this is uncommented
externalssd	UUID=049078aa-f107-4903-a106-5228b4b125cf none luks #unlocks fine

I have two LUKS encrypted disks in my system, /dev/sdc1 and /dev/sda1. Before, I only had /dev/sdc1. In the single-disk configuration, the system would boot, the disk would be unlocked, and everything would proceed as normal. Now that I've bound a second disk (/dev/sda1), the system won't boot if both disks are in /etc/crypttab. if I only have /dev/sdc1 in /etc/crypttab it'll typically unlock, and boot. then if I do a clevis luks unlock /dev/sda1, that disk will unlock.

TL;DR: with two disks, both disks won't unlock and the system will fail to boot, with one, things go and the system boots just fine.

tpm2-tools version(s) compatibility

It would be great if the docs could specify which versions of tpm2-tools clevis tpm2 works with.

And maybe the tool could emit helpful information if executed on a non-compatible version.

( @martinezjavier which versions of tpm2-tools is clevis tpm2 pin working with? )

Typo fix: choosen -> chosen

From the nitpicking department, as noticed by Debian's "lintian" checker:

Apparently "choosen" in both doc/clevis-encrypt-tpm2.1 and doc/clevis.1 should be spelled "chosen".

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.