cornelinux / yubikey-luks Goto Github PK

Hi,

I have an idea to have the secret stored on Yubikey, but better than chal-resp method used by your scripts protect the secret by PIN. It would be a great protection against breaking password by torture. You have just 3 attempts to enter the PIN correctly, so you would have to withstand just 3 rounds of torture since Yubikey PIV would be locked after the 3rd attempt.

I spent some time to figure out, how to do that. Seems Yubikey has not functionality which would allow you to store raw PIN protected secret. However, I think I found the solution.

It uses PIV. PIV has slots which hold RSA secret keys. Yubikey allows you to use the keys for decryption. The decipher operation is protected by PIN. Yubikey can import and generate the keys, but it has no interface to read the keys back.

The idea is:

1. generate and store the RSA2048 key in selected slot
2. use the public-key to encrypt the random secret
3. drop public key
4. store the encrypted secret as an raw data object for given slot. AFAIK the slot-objects are used for storing certificates, but they can hold any data in general.

If you wan to get the secret, you read the encrypted secret and let Yubikey decipher. It needs PIN. It should be safe, since we don't know even the RSA public-key (dropped in step 3), so we don't even know the public RSA parameters like modulus. Due to this, I think it would be safe even with RSA512!

I create short app, which can do that:
https://github.com/smrt28/yk-secret-tool

It needs a relatively new libykpiv which is not in my distro (Ubuntu 18). So, you will need the repo. from yubico or compile from sources:
https://github.com/Yubico/yubico-piv-tool

It works with Yubikey 4. NEO doesn't have RETIRED slots which it uses, but you can use YKPIV_KEY_AUTHENTICATION slot (-s 21 yk-secret-tool argument - see piv.c ykpiv_select_slot() function) but I didn't try it since I'm not the NEO owner.

Example:
Setup 1st slot by random secret:

$ ./yk-secret-tool -a setup -s 1
Generating key and setting secret to slot 1...
Done

Fetching the secret:

$ ./yk-secret-tool -a fetch -s 1
Yubikey PIN:
4f9a6acb66abceb989f4e46de860428760152afd46124bb05216fd92ddc7598a

Is it interesting for you?

This is probably a noob question. I'm trying to get a "headless" kali box setup with LUKS FDE. I would like to have the pre-boot authentication only need the yubikey to be present and not need any user input. I see it mentioned with the ykfde (agherzan/yubikey-full-disk-encryption) package that it can be done. Can I accomplish this with the cornelinux/yubikey-luks package? If so how, I'm hitting a stump figuring it out. Thanks!

With the new Ubuntu 18.10, the hook script does not start anymore.
The cryptsetup hook is called and I have to enter the password manually.

I've tried to purge and reinstall the package, but nothing has happened.

Is there a simpler way to add an additional yubikey. I'd like a backup yubikey but privacyidea seems like overkill. I'd like to have the ability to simply add another yubikey.

The boot is interrupted and requires an input (just pressing the RETURN).
But I would like an unattended boot.

This is on a new bookworm install.

Currently suspending machine with unlocked disk leaves it unencrypted. There are however luksSuspend and luksResume commands which overcome this.

Actual implementation in initramfs already exists and it integration will be beneficial for yubikey-luks:
https://github.com/zhongfu/ubuntu-luks-suspend
https://github.com/nailfarmer/debian-luks-suspend

With the change of the keyscript, we need to be able to run a smooth update on debian/ubuntu.
Otherwise updating to a newer version, will result in LUKS not being accessable with the yubikey.

We need to parse /etc/crypttab for the occurrance of luks and add the keyscript.

luks,keyscript=/usr/share/yubikey-luks/ykluks-keyscript

I can only suspend my system once after a reboot. The next time I try to suspend, I get the error:

umount: /run/initramfs/dev: target is busy.
umount: /run/initramfs: target is busy.

This doesn't happen if I disable the yubikey-luks-suspend service, so I'm guessing it's something related to that

This week I have discovered the yubikey-luks package inside debian/ubuntu. I'm reading up a bit on how the mechanism works. Now I'm left with the following question. IIUC the resulting response is - in its basic configuration - solely dependent on the password entered which is used as challenge. This means, that if you use this mechanisms on multiple PCs, capturing the result on one PC gives you the passphrase to use on other PC's.

Could we include something unique/identifying of the LUKS partition (e.g. partition UUID) to make the response of the challenge - and therefore the response - distinct for each PC?

update I am having second thoughts about using the UUID, as it is likely changeable, so would corrupt the key slot. I am still curious to your opinion on this.

update to add reasoning:

In the end, you receive a consistent response from the security key, so whatever you do, you cannot protect from capturing the final secret value that unlocks the LUKS partition. This is not a goal.

However, you can avoid that you can discover the secret with only the security key accessible. Including a piece of unique/distinct LUKS/partition information in the challenge, means that you need to have access to the partition at least once - in addition to having access to the security key.

Is there any chance that there's a way to make it so busybox/dropbear and yubikey-luks can play nice together? I had my system set up so it would allow an ssh sign into the luks encrypted disk. Once I set up the yubikey to work for the luks disk, I can no longer use the ssh connection to unlock the disk. I can connect, and type in cryptroot-unlock, but then it will time out before anything happens. I've looked through all the initramfs hooks, but I'm not entirely sure how to fix this. Do you have any recommendations? Thanks.

Hello there! I was checking your scripts and I noticed that you pass the password to the ykchalresp bin as part of its command line, thus exposing it to the system:

If you run top or htop you will see the password shows up there. The same happens in the initram script, but on that scenario is not so dangerous. However, on the already booted up scenario, having the password shown as part of the command is VERY dangerous.

I haven't used ykchalresp but a better approach would be to pass the password like: printf "%s" "$P1" | ykchalresp -2 - or something like that (we need to test this).

The slot and the luks partition in yubikey-luks-enroll should be configurable.

First, thank a lot for this wonderful project.

I need to use 1FA and I noticed that the apt package doesn't yet support it.
I'm currently building the deb file from master branch but I'd like to install normally using apt.

When will the new version be available on the apt library?

Thanks

Build fails with following error:

make builddeb NO_SIGN=1
make debianize
make[1]: Entering directory '/home/box-admin/yubikey-luks'
rm -fr DEBUILD
mkdir -p DEBUILD/yubikey-luks-0.5.1
cp -r *  DEBUILD/yubikey-luks-0.5.1 || true
cp: cannot copy a directory, 'DEBUILD', into itself, 'DEBUILD/yubikey-luks-0.5.1/DEBUILD'
(cd DEBUILD; tar -zcf yubikey-luks_0.5.1.orig.tar.gz --exclude=yubikey-luks-0.5.1/debian  yubikey-luks-0.5.1)
make[1]: Leaving directory '/home/box-admin/yubikey-luks'
(cd DEBUILD/yubikey-luks-0.5.1; debuild -uc -us)
/bin/sh: 1: debuild: not found
make: *** [Makefile:18: builddeb] Error 127

How difficult would it be to modify this to work on Devuan, which is Debian minus systemd?

This looks like a great tool, and I have a yubikey just sitting around, but when I built and tried to install the deb, it failed because it couldn't find systemd.

Any chance this could be adapted for non-systemd systems?

I followed this tutorial trying to use it for LVM volume to be setup as luks-encrypted volume with Yubikey:
https://deisi.github.io/posts/luks_mi_yubikey/

I stucked when I noticed yubikey-luks-enroll tries to access /dev/sda3 by default. I'm also somehow shocked for some reason this tool tries to access /dev/sda3 without given explicit reason to do so. My machine even has no sda3 at all on the one hand and on the other hand such a tool should not assume such things, when mistakes could lead to data-loss!

But back to main question, how can I use this to decrypt single-volume by device? This would also be a use-case for luks+yubikey encrypted external USB-Drives for example.

I may just be doing something wrong in my setup but I am trying to use the 1FA mode with 8 SSD's at boot. I am running a freshly installed Debian stable (bullseye) installation

Using the following ykluks.cfg file:

# If you change this file, you need to run 
#   update-initramfs -u
WELCOME_TEXT="Please insert HSM to boot device..."
# Set to "1" if you want both your password and Yubikey response be bundled together and writtent to key slot.
CONCATENATE=0
# Set to "1" if you want to hash your password with sha256.
HASH=0
# Generated with pwgen -s 128 (this code is different than what I use on the system but the same length)
YUBIKEY_CHALLENGE="YH3hzaphiGX0noE6XuCOhtkqeh2zbemKezASnqMiKoflsFJQr8x1wblOhWO18dBWl4sIw5HYhGiV5QwnXZfLzoBRJaG0lCEosz5Rvg8PgcZOsAiczj1gnG4FPX9rtRh2"

I have tried three crypttab configurations, one where only one drive decrypts on boot which works as expected, one where I am using the yubikey-luks keyscript with all drives at boot, and then another that attempts to use ykluks with decrypt_keyctl to cache the result for the other drives.

First configuration:

sda3_crypt UUID=56e8721e-dfa2-4b8e-9ff7-c6f1ae921cd6 none luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript

This works as you would expect, on boot, the system automatically queries the yubikey and then decrypts the main drive. I however want to decrypt all drives at boot if possible so I modified the crypttab to look like the following:

sda3_crypt UUID=56e8721e-dfa2-4b8e-9ff7-c6f1ae921cd6 none luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
zfs_drive_1 UUID=7238e9b5-00b7-4df4-a879-dcd315c6bc83 none luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
zfs_drive_2 UUID=1ad2085d-b501-489b-bc8d-56830e13fd16 none luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
zfs_drive_3 UUID=c7dc8717-b671-46cd-b08d-2d303dd43feb none luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
zfs_drive_4 UUID=857426a7-b72b-4dc8-8919-e1c25af119ee none luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
zfs_drive_5 UUID=c3d90f0f-d6e7-4069-8165-dce62e727e45 none luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
zfs_drive_6 UUID=634cb46b-0a97-4e55-8bd4-48c08547bbc7 none luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
zfs_drive_7 UUID=4fcc39ab-6046-4485-b499-53c9de279df4 none luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript

This I would think would be the default configuration however the behavior when running on this mode is that the password for one of the drives is asked (usually zfs_drive_1 or zfs_drive_2) and if I enter the manual password it would then decrypt all the rest of the drives and boot without any further prompts. The expected behavior is that the system just boots without user interaction, this will be important as this system will be a headless server.

Finally, I thought that perhaps it's running into an issue querying the yubikey so frequently so perhaps we could cache the result using the decrypt_keyctl keyscript however the system will no longer boot with the following crypttab:

sda3_crypt UUID=56e8721e-dfa2-4b8e-9ff7-c6f1ae921cd6 zfs_pool: luks,discard,keyscript=decrypt_keyctl,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
zfs_drive_1 UUID=7238e9b5-00b7-4df4-a879-dcd315c6bc83 zfs_pool luks,discard,keyscript=decrypt_keyctl
zfs_drive_2 UUID=1ad2085d-b501-489b-bc8d-56830e13fd16 zfs_pool luks,discard,keyscript=decrypt_keyctl
zfs_drive_3 UUID=c7dc8717-b671-46cd-b08d-2d303dd43feb zfs_pool luks,discard,keyscript=decrypt_keyctl
zfs_drive_4 UUID=857426a7-b72b-4dc8-8919-e1c25af119ee zfs_pool luks,discard,keyscript=decrypt_keyctl
zfs_drive_5 UUID=c3d90f0f-d6e7-4069-8165-dce62e727e45 zfs_pool luks,discard,keyscript=decrypt_keyctl
zfs_drive_6 UUID=634cb46b-0a97-4e55-8bd4-48c08547bbc7 zfs_pool luks,discard,keyscript=decrypt_keyctl
zfs_drive_7 UUID=4fcc39ab-6046-4485-b499-53c9de279df4 zfs_pool luks,discard,keyscript=decrypt_keyctl

This will result in the error cryptesetup: ERROR: sda3_crypt: invalid value for keyscript options, skipping I am not sure if it's possible to chain multiple keyscripts or how you would properly do it.

For added clarity, I would do an sudo update-initramfs -u between each change of crypttab. I built yubikey-luks against the current master branch so its not the stale version in the stable repos.

If anyone has this working on multiple drives has any ideas about what I should be doing please let me know!

Hello

I have read about challenge-response authentication on the Wikipedia and as I understood it is based on pre-shared-key(both laptop and yubikey have the same key into their memory). Thus, if an attacker got physical access to laptop he/she is able to read pre-shared-key from laptop HDD and decrypt the disk.

Is it true or I just have wrong understanding about this authentication type?

Hi,
on clean new installation of Ubuntu 24.04 yubikey-luks initramfs unlock script does not work.

after insatlation (sudo apt-get install yubikey-luks -y)
I am able to enroll keys in key slots. (both for default system partition (/dev/nvme0n1p3), and for external USB pen drive I used for test /dev/sda3). with yubikey-luks-enroll.
I am able to use yubikey-luks-open for external pendrive (/dev/sda3) I used for testing.
So making key slots and using chalange-responses from yubi keys works.
However after reboot of system OS in LUKS unlock screen, no yubikey-luks welcome text is shown and unlock for keyslots containing enrolled keys are not working. Only those I made with luksAddKeys and therefore with passwords only are working.
I am using same laptop as for previous 18.04-23.10 where everything worked ok. (Dell XPS 13 9350)
Did not work first time (depending on automaticall add keyscript to crypttab - that worked for me before)
Did not work after manual sudo update-initramfs -u
Did not work after adding to /etc/crypttab cryptroot /dev/nvme0n1p3 none luks,keyscript=/usr/share/yubikey-luks/ykluks-keyscript and doing sudo update-initramfs -u again.
Both yubikeys NFC5c I have are initialized for ch-response (ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64 -oserial-api-visible)
Thanks in advance for any advice, thx.

First, thanks for all the awesome work that went and goes into making this.

Everything works except:
The issue is that YUBIKEY_CHALLENGE="mypassword" is not working as expected.
I am always asked for my password and having this line there or not does not make a difference for me.
Am I missing anything?

Hi,

We recently implemented HMAC SHA1 in OnlyKey, it is fully compatible with Yubikey's HMAC SHA1 challenge and response. We have integrated support with KeePassXC keepassxreboot/keepassxc#3352 and are looking to integrate with other projects as well. The only change required is to allow OnlyKey's USB VID/PID to be used in addition to the already allowed Yubikey USB VID/PIDs. Would you be willing to add support for OnlyKey?

Thanks!

Hi,

ykluks-keyscript currently can't work with non-root encrypted volumes (you can't call it as the keyscript= parameter from /etc/crypttab.

I've made a pull request #13 with a change to fix it - simply checks two places for the initramfs-tools functions so it can run under both initramfs root and normal root.

Thanks

A

Since there is no recent package for Ubuntu Vivid in ppa:privacyidea/privacyidea I tried to build yubikey-luks from source but the process fails with a gpg error.

$ make builddeb 
make debianize
make[1]: Entering directory '/home/tristank/Dokumente/Code/github/yubikey-luks'
rm -fr DEBUILD
mkdir -p DEBUILD/yubikey_luks.orig
cp -r * DEBUILD/yubikey_luks.orig || true
cp: Kopieren eines Verzeichnisses, »DEBUILD“, in sich selbst (»DEBUILD/yubikey_luks.orig/DEBUILD“) ist nicht möglich
(cd DEBUILD; tar -zcf yubikey-luks_0.3.3.orig.tar.gz --exclude=yubikey_luks.orig/debian  yubikey_luks.orig)
make[1]: Leaving directory '/home/tristank/Dokumente/Code/github/yubikey-luks'
(cd DEBUILD/yubikey_luks.orig; debuild)
parsechangelog/debian: Warnung:     debian/changelog(l1): unbekannter Schlüsselwert Uegency
LINE: yubikey-luks (0.3.3-1) trusty; uegency=low
parsechangelog/debian: Warnung: unbekanntes Informationsfeld »Uegency« in den Eingabedaten in ausgewertete Version des changelogs
 dpkg-buildpackage -rfakeroot -D -us -uc
parsechangelog/debian: Warnung:     debian/changelog(l1): unbekannter Schlüsselwert Uegency
LINE: yubikey-luks (0.3.3-1) trusty; uegency=low
parsechangelog/debian: Warnung: unbekanntes Informationsfeld »Uegency« in den Eingabedaten in ausgewertete Version des changelogs
dpkg-buildpackage: Quellpaket yubikey-luks
dpkg-buildpackage: Quellversion 0.3.3-1
dpkg-buildpackage: Quelldistribution trusty
dpkg-buildpackage: Quellen geändert durch Cornelius Kölbel <[email protected]>
 dpkg-source --before-build yubikey_luks.orig
dpkg-buildpackage: Host-Architektur amd64
parsechangelog/debian: Warnung: yubikey_luks.orig/debian/changelog(l1): unbekannter Schlüsselwert Uegency
LINE: yubikey-luks (0.3.3-1) trusty; uegency=low
parsechangelog/debian: Warnung: unbekanntes Informationsfeld »Uegency« in den Eingabedaten in ausgewertete Version des changelogs
 fakeroot debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
   dh_clean
 dpkg-source -b yubikey_luks.orig
parsechangelog/debian: Warnung: yubikey_luks.orig/debian/changelog(l1): unbekannter Schlüsselwert Uegency
LINE: yubikey-luks (0.3.3-1) trusty; uegency=low
parsechangelog/debian: Warnung: unbekanntes Informationsfeld »Uegency« in den Eingabedaten in ausgewertete Version des changelogs
dpkg-source: Warnung: kein Quellformat in debian/source/format angegeben, lesen Sie dpkg-source(1)
dpkg-source: Warnung: Quellverzeichnis »yubikey_luks.orig« lautet nicht <Quellpaket>-<UpstreamVersion> »yubikey-luks-0.3.3«
dpkg-source: Warnung: .orig-Verzeichnisname yubikey_luks.orig.orig ist nicht <Paket>-<Ursprungsversion> (yubikey-luks-0.3.3.orig erwünscht)
dpkg-source: Information: Quellformat »1.0« wird verwendet
dpkg-source: Information: yubikey-luks wird unter Benutzung des existierenden yubikey-luks_0.3.3.orig.tar.gz gebaut
dpkg-source: Information: yubikey-luks wird in yubikey-luks_0.3.3-1.diff.gz gebaut
dpkg-source: Information: yubikey-luks wird in yubikey-luks_0.3.3-1.dsc gebaut
 debian/rules build
dh build
   dh_testdir
   dh_auto_configure
   dh_auto_build
make[1]: Entering directory '/home/tristank/Dokumente/Code/github/yubikey-luks/DEBUILD/yubikey_luks.orig'
builddeb      - building debian package for Ubuntu 14.04LTS
ppa-dev       - upload to ppa launchpad. Development
ppa      - upload to ppa launchpad. Stable
make[1]: Leaving directory '/home/tristank/Dokumente/Code/github/yubikey-luks/DEBUILD/yubikey_luks.orig'
   dh_auto_test
 fakeroot debian/rules binary
dh binary
   dh_testroot
   dh_prep
   dh_auto_install
   debian/rules override_dh_install
make[1]: Entering directory '/home/tristank/Dokumente/Code/github/yubikey-luks/DEBUILD/yubikey_luks.orig'
dh_install
install -D -o root -g root -m755 hook debian/yubikey-luks/usr/share/initramfs-tools/hooks/yubikey-luks
install -D -o root -g root -m755 script-top debian/yubikey-luks/usr/share/initramfs-tools/scripts/local-top/yubikey-luks
install -D -o root -g root -m755 script-bottom debian/yubikey-luks/usr/share/initramfs-tools/scripts/local-bottom/yubikey-luks
install -D -o root -g root -m755 key-script debian/yubikey-luks/usr/share/yubikey-luks/ykluks-keyscript
install -D -o root -g root -m755 yubiky-luks-enroll debian/yubikey-luks/usr/bin/yubikey-luks-enroll
make[1]: Leaving directory '/home/tristank/Dokumente/Code/github/yubikey-luks/DEBUILD/yubikey_luks.orig'
   dh_installdocs
   dh_installchangelogs
parsechangelog/debian: Warnung:     debian/changelog(l1): unbekannter Schlüsselwert Uegency
LINE: yubikey-luks (0.3.3-1) trusty; uegency=low
parsechangelog/debian: Warnung: unbekanntes Informationsfeld »Uegency« in den Eingabedaten in ausgewertete Version des changelogs
   dh_pysupport
dh_pysupport: This program is deprecated, you should use dh_python2 instead. Migration guide: http://deb.li/dhs2p
   dh_perl
   dh_link
   dh_compress
   dh_fixperms
   dh_installdeb
   dh_gencontrol
parsechangelog/debian: Warnung:     debian/changelog(l1): unbekannter Schlüsselwert Uegency
LINE: yubikey-luks (0.3.3-1) trusty; uegency=low
parsechangelog/debian: Warnung: unbekanntes Informationsfeld »Uegency« in den Eingabedaten in ausgewertete Version des changelogs
   dh_md5sums
   dh_builddeb
dpkg-deb: Paket »yubikey-luks« wird in »../yubikey-luks_0.3.3-1_all.deb« gebaut.
 dpkg-genchanges  >../yubikey-luks_0.3.3-1_amd64.changes
parsechangelog/debian: Warnung:     debian/changelog(l1): unbekannter Schlüsselwert Uegency
LINE: yubikey-luks (0.3.3-1) trusty; uegency=low
parsechangelog/debian: Warnung: unbekanntes Informationsfeld »Uegency« in den Eingabedaten in ausgewertete Version des changelogs
parsechangelog/debian: Warnung:     debian/changelog(l1): unbekannter Schlüsselwert Uegency
LINE: yubikey-luks (0.3.3-1) trusty; uegency=low
parsechangelog/debian: Warnung:     debian/changelog(l8): unbekannter Schlüsselwert Uegency
LINE: yubikey-luks (0.3.2-1) trusty; uegency=low
parsechangelog/debian: Warnung: unbekanntes Informationsfeld »Uegency« in den Eingabedaten in ausgewertete Version des changelogs
dpkg-genchanges: kompletter Quellcode beim Hochladen hinzufügen
 dpkg-source --after-build yubikey_luks.orig
parsechangelog/debian: Warnung: yubikey_luks.orig/debian/changelog(l1): unbekannter Schlüsselwert Uegency
LINE: yubikey-luks (0.3.3-1) trusty; uegency=low
parsechangelog/debian: Warnung: unbekanntes Informationsfeld »Uegency« in den Eingabedaten in ausgewertete Version des changelogs
dpkg-buildpackage: Alles hochzuladen (Originalquellen enthalten)
Now running lintian...
E: yubikey-luks changes: bad-urgency-in-changes-file unknown
W: yubikey-luks source: debhelper-but-no-misc-depends yubikey-luks
W: yubikey-luks source: ancient-standards-version 3.8.3 (current is 3.9.6)
W: yubikey-luks: syntax-error-in-debian-changelog line 1 "unbekannter Schl??ssel Uegency ??? wird nach XS-Uegency kopiert"
W: yubikey-luks: syntax-error-in-debian-changelog line 8 "unbekannter Schl??ssel Uegency ??? wird nach XS-Uegency kopiert"
W: yubikey-luks: syntax-error-in-debian-changelog line 14 "unbekannter Schl??ssel Uegency ??? wird nach XS-Uegency kopiert"
W: yubikey-luks: syntax-error-in-debian-changelog line 20 "unbekannter Schl??ssel Uegency ??? wird nach XS-Uegency kopiert"
W: yubikey-luks: binary-without-manpage usr/bin/yubikey-luks-enroll
Finished running lintian.
Now signing changes and any dsc files...
 signfile yubikey-luks_0.3.3-1.dsc Cornelius Kölbel <[email protected]>
gpg: »Cornelius Kölbel <[email protected]>« übersprungen: Geheimer Schlüssel ist nicht vorhanden
gpg: /tmp/debsign.8GZyL5gc/yubikey-luks_0.3.3-1.dsc: clearsign failed: Geheimer Schlüssel ist nicht vorhanden
debsign: gpg error occurred!  Aborting....
debuild: fatal error at line 1295:
running debsign failed
Makefile:16: recipe for target 'builddeb' failed
make: *** [builddeb] Error 29

Any suggestions?

I've put the following as suggested in the README into my /etc/crypttab:

...,keyscript=/usr/share/yubikey-luks/ykluks-keyscript

The Yubikey integration works fine, fortunately. Though, it won't accept my other passphrase which has nothing to do with the Yubikey.

Plugging out the Yubikey does not help. (I did a cold boot after that.)
Also, just pressing Enter without having anything typed already challenges the Yubikey. It's still showing Please insert yubikey and press enter or enter a valid passphrase in this case.

Any help?

I took a look in the keyscript already, but without knowing anything about the integration with LUKS I can't tell if this is a bug or a mis-configuration.

Environment:
Ubuntu 18.04
yubikey-luks: master

Hi,

as part of the pull request #25, I have tried to build the deb package - as stated in the README.md - with:

make builddeb

I get the following error:

Now signing changes and any dsc files...
 signfile yubikey-luks_0.5.1-1.dsc Cornelius Kölbel <[email protected]>
gpg: skipped "Cornelius Kölbel <[email protected]>": secret key not available
gpg: /tmp/debsign.iyH37NeU/yubikey-luks_0.5.1-1.dsc: clearsign failed: secret key not available
debsign: gpg error occurred!  Aborting....
debuild: fatal error at line 1295:
running debsign failed
Makefile:16: recipe for target 'builddeb' failed
make: *** [builddeb] Error 25

The full build log is attached [1].

Attachment:

1. build.log

I have an encrypted luks1 /boot partition. I enter a password to get to the grub boot menu.
Then when I select a Kernel I have to provide a different and long passphrase which unlocks my root partition. (luks 2)
The /boot has a second slot which is a key file in the root partition to avoid having to unlock the /boot partition again after already unlocking it in grub stage 1.
I wanted to use the yubikey to unlock the root partition, but I am not getting prompted for the yubikey and it does not work.
Does anybody know if this is possible?
I do not plan to use the yubikey to unlock the /boot partition for grub stage 1, because this is not possible as far as I know.

Currently only response for a challenge is used as LUKS passphrase which makes user provided challenge/password redundant in case of bruteforce attack. Also yubikey responses have limited character set, i.e. bd438575f4e8df965c80363f8aa6fe1debbe9ea9 (no uppercase).

Combining provided challenge with response as LUKS passphrase will increase its security without any downsides.

Before:
LUKS passphrase=bd438575f4e8df965c80363f8aa6fe1debbe9ea9
After:
LUKS passphrase=PaSwOrDbd438575f4e8df965c80363f8aa6fe1debbe9ea9

As someone who set this up on one machine a while ago - so already has a Yubikey set up - and installing on a freshly-built system, it's not clear what needs to be installed for this to work.
The list I have found is the following packages:

• git (for the original clone)
• make
• devscripts (for debuild)
• dh-exec
• yubikey-personalization for the ykchalrespand ykinfo files.

I'll draft some doc for this soon and create a PR (likely tomorrow), though any other dependencies I missed (or got pulled in elsewhere) would be appreciated.

Should be able to change the challenge, so that we get some kind of one time password effect.
At the moment the process results in one static password to unlock one key slot.

Per the documentation, modifying the WELCOME_TEXT variable in /etc/ykluks.cfg allows users to personalize the prompt.

When booting in CLI mode (GRUB_CMDLINE_LINUX_DEFAULT="" in /etc/default/grub), newlines (\n) in WELCOME_TEXT are recognized and the text is written over multiple lines.

This does not seem to work in GUI boot (GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"), as the newline appears as a litteral \n. Is there a way to get multiline text this way?

Thank you

Edit: Adding a litteral newline in the variable works

WELCOME_TEXT="First Line
Second Line"

But there seems to be a maximum length of the text for the GUI boot. If the WELCOME_TEXT is too long then the GUI boot just goes "Maximum number of tries reached" without giving the user a chance to do anything.

Hi,
everything works fine for my root partition. Now I wanted to use the Yubikey to also unlock another luks partition on my machine. However, at boot, I can only use my Yubikey for the root partition but for the other one I have to enter my normal luks password. There is also no prompt to use the Yubikey for the second one.
What am I missing?

Here is my crypttab:

sda3_crypt UUID=9c4dd479-834a-4784-9c49-6444ea59d1b3       none luks,keyscript=/usr/share/yubikey-luks/ykluks-keyscript
nvme0n1p1_crypt UUID=e7dc86cd-4a4a-48cd-923d-535924fca7e0  none luks,keyscript=/usr/share/yubikey-luks/ykluks-keyscript

For sda3_crypt (my root partition) I am able to use my Yubikey, but not for nvme0n1p1_crypt. I have enrolled the Yubikey for both partitions.

Here is the output of luksDump:

$ sudo cryptsetup luksDump /dev/nvme0n1p1
LUKS header information
Version:       	2
Epoch:         	6
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	e7dc86cd-4a4a-48cd-923d-535924fca7e0
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2i
	Time cost:  7
	Memory:     1048576
	Threads:    4
	Salt:       f5 d1 02 27 2c ba 2f 6b 95 81 d9 12 1c 61 94 9e 
	            ee 5d 02 6c 3b 7e 46 fc 72 bb e1 c8 7c df dc 59 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
  1: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2i
	Time cost:  7
	Memory:     1048576
	Threads:    4
	Salt:       a6 a5 c1 30 cb 7e 2f b0 4b bb b9 c2 39 e1 25 15 
	            d2 6f 8c 0e 02 3d f8 c4 99 7c 88 27 9a 04 e0 ae 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:806912 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
  7: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2i
	Time cost:  7
	Memory:     1048576
	Threads:    4
	Salt:       de 9a 79 1e bf 0d 95 86 bf b2 3b 2b 1d 4e 4a 48 
	            0f 31 af 59 98 cf 6d 42 3d e0 78 64 64 e8 20 1e 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:290816 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
  8: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2i
	Time cost:  6
	Memory:     1048576
	Threads:    4
	Salt:       26 2e ea 72 62 e2 72 e6 10 cc e2 78 bb 13 08 6a 
	            11 e2 46 45 bd 7a 21 4d 91 dd 42 02 52 55 c9 45 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:548864 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 137104
	Salt:       20 79 4f 46 12 6f b7 5f 20 ad da 53 fe c0 13 b5 
	            35 e1 a8 fd 7b d4 8c 95 bd 51 fb 0e cf da 66 9a 
	Digest:     22 bc 49 71 f5 6f 45 5e 0f f1 f1 21 5f 0f f3 72 
	            5c 30 1a 78 db c0 4b 06 37 99 d6 19 db ae c0 6d 

Hi there,

I'm runing a home server with ubuntu 14.04 lts and native zfs. There are two luks encrpyted hdds in a raid-1 structure (mirror). The hdds will be auto opened (decrypted and mounted) with a keyfile on startup. To achieve better security I want the drive only to be opened when my yubikey is attached and after a password is entered. Is this possible with your solution? If so, how?

Regards

Hello team,
I recently add a second disk to my laptop and automatically decrypt it at boot with the decrypt_derived mechanism and until, I can not use my yubikey as, it only decrypts the historical disk and I have to manually decrypt the second one by using he rescue password.
Is it a bug or should I use a specific procedure to manage my 2 disks with the yubikey
Thanks for your answer
Ronan

Hello everybody,

since it seems that @cornelinux does not have the time to keep working on this, I'm pinging here everybody with open MR (@superteece @finlstrm @pstray @erolg @Vincent43 @Gargravarr2112) and contributors (@scratchhax @CristianCantoro @michael-k @markchalloner @magenbrot @awnz @EdwardBetts).

My suggestion would be to create a fork of the repo where we can work on the open issues and merge requests. Then we contact the Debian maintainers to switch to this fork to get an updated version into the Debian universe. I would not want to do it alone and also future updates would benefit from some more people with write access to the forked repo.

Alternatively, @cornelinux could of course also decide to include more people with write access to maintain the repo in place?

Any suggestions welcome!
Cheers,
Patrick

The Makefile target "debianize" contains:

mkdir -p DEBUILD/${SRC_DIR}
cp -r * DEBUILD/${SRC_DIR}

This resuilts in an error on Ubuntu: cannot copy a directory, 'DEBUILD', into itself

Consider changing the cp to:
cp -r ${ls |grep -v DEBUILD}

... or something that does that.

I might be reading the code wrong, but in its current form isn't this creating the passphrase using an ascii representation of the hex code output from the Yubikey? Doesn't that need to get converted to binary before being used as a key? As it is now, I think the passphrase is using a long string of ascii characters [0-9] and [a-f] (lowercase) rather than an actual binary string.

Scenario: Mount luks file using a detached header:

/sbin/cryptsetup --verbose luksOpen --type luks2 --header luksheader.img /dev/loop8 mybackup

Enrolling a yubikey key slot appears to work OK:

yubikey-luks-enroll -d luksheader.img -s 1

However, we cannot actually open the volume with yubikey-luks-open, because we can't currently pass both the header and the volume through to cryptsetup.

System startup usually works very well with Yubikey-luks, but when I try to suspend I get the following errors.

The first one is:

$ sudo  /usr/lib/yubikey-luks-suspend/yubikey-luks-suspend 

gzip: stdin: not in gzip format
cpio: premature end of archive
Press ENTER to continue.

Because my initramfs not gunzip file.

$ file /boot/initrd.img-4.15.0-43-generic 
/boot/initrd.img-4.15.0-43-generic: ASCII cpio archive (SVR4 with no CRC)

Its OK. Then I changed the line with this (cpio --quiet -id) < "${INITRAMFS}"

Then my laptop starts to suspend normally (it could wake up without yubikey) because of the line.
When I comment out the line and suspend proccess getting started with the following error:

chroot: failed to run command ‘/suspend’: No such file or directory

I figured out that my initramfs dont have suspend script (which is copied with initramfs hook)

Here is the update-initramfs log: https://gist.github.com/erolg/17d52e92195f8a3d251895ff54ab23b5

And here is my crypttab
cryptedlvm UUID=83feeca9-f770-4883-96fc-3d15d98190bd none luks,discard

update-initramfs seems to be OK. But there is no suspend script in the image.

erol@kfir:/tmp$ cat initrd.img-4.15.0-43-generic | cpio -idmv

.
kernel
kernel/x86
kernel/x86/microcode
kernel/x86/microcode/AuthenticAMD.bin
56 blocks

I can't figure out why there is no suspend script in the image? Do you have any opinion?

Btw thank you for this great project!

I made a LUKS container protected with yubikey-luks that I want to open on a running system but the yubikey-luks-open command is not working (command not found).

I'm running Ubuntu 19.04 with yubikey-luks installed from a system repo.

Hi Patrick,

thanks again for you great efforts!
What happens is: "Yubikey not available or timed out waiting for button press"

I am looping over the yubikey-luks-open script until the encrypted drive is open and afterwards I would love to run some other (backup) scripts.
We are running into that part that makes some problems I guess:

R="$(printf %s "$P1" | ykchalresp -"$YUBIKEY_LUKS_SLOT" -i- 2>/dev/null || true)"
if [ "$DBG" = "1" ]; then echo "Yubikey response: $R"; fi

if [ -z "$R" ]; then
    echo "Yubikey not available or timed out waiting for button press"
    exit 1
fi

On the one hand it seems like there is no value for "$R" but otherwise setting DBG=1 echos the Yubikey response: $R" correctly.

Could it be, that there should be some implementation of sleep or wait?
Many thanks again!
FONDSMATIVE

P.S.:

Part of the 'looping script'

n=5 #max 5 trys
c=0

until $(grep -qs ${_mntd} /proc/mounts) || true
do    
    ${_yubikey} 
    wait $!

    if grep -qs "${_mntd}" /proc/mounts; then
   	sudo ${_mnt} --uuid ${_uuid} ${_mntd} &> /dev/null
        exit 0
    else
	echo "SOMTHING WENT WRONG.."  	
	echo "TRY AGAIN..."
       
    fi

    (( c+=1 ))
   
    if (( c < n ))
    then
        continue
    else
        break
 	echo "SOMTHING WENT WRONG... SORRY"
    fi
done 

It seems that a Yubikey keyslot can only be used to unlock on bootup, but not to manage LUKS once logged in, such as adding and changing keys. This would mean that you must keep a password-only LUKS keyslot to manage keys, which seems to defeat the purpose of the added security of a Yubikey. Unless there is a detail I am missing?

yeah, it is really annoying if the debian package has no man page ;-)

Hello!

I found an issue related to identifying Yubikey when I'm trying to open a LUKS disk at boot.
When I add more entries to fstab I will get "Yubikey core error: no yubikey present" error message.

The issue happens with:

fstab

/dev/mapper/luks        /               ext4	errors=remount-ro   	0	1
UUID=XXXXX              /boot           ext4	defaults	        	0	2
UUID=YYYYY              /boot/efi       vfat	umask=0077	            0	1
UUID=ZZZZZ              /mnt/disk1      ext4	defaults,nofail,noatime	0	2
/dev/mapper/cryptodisk  /mnt/disk2     ext4	defaults,nofail,noatime	0	2

crypttab
cryptodisk UUID=WWWWW none luks,discard,keyscript=/usr/share/yubikey-luks/ykluks-keyscript

The issue solved by commenting out external disks:
fstab

/dev/mapper/luks        /               ext4	errors=remount-ro   	0	1
UUID=XXXXX              /boot           ext4	defaults	        	0	2
UUID=YYYYY              /boot/efi       vfat	umask=0077	            0	1
#UUID=ZZZZZ              /mnt/disk1      ext4	defaults,nofail,noatime	0	2
#/dev/mapper/cryptodisk  /mnt/disk2     ext4	defaults,nofail,noatime	0	2

OS: Debian GNU/Linux 12 (bookworm)
Kernel: 6.1.0-18-amd64
Package: 0.5.1+29.g5df2b95-6.1

Could you help to fix this please?
Thank you!

Have a nice day!

I'm trying to get 1fa to work with Ubuntu but there seems to be some problem. Booting with the Yubikey installed still requires that I type the challenge password. For what it is worth, I have a Yubikey 4.

Following is my /etc/ykluks.cfg file:

# If you change this file, you need to run 
#   update-initramfs -u
WELCOME_TEXT="Please insert yubikey and press enter or enter a valid passphrase"
# Set to "1" if you want both your password and Yubikey response be bundled together and writtent to key slot.
CONCATENATE=0
# Set to "1" if you want to hash your password with sha256.
HASH=0
YUBIKEY_CHALLENGE="<password>"

My only change from the package supplied configuration is to set YUBIKEY_CHALLENGE. Is there some error in my file or is this a bug?

Hello,
im using this setup on my new Laptop which overall works fine.
But if i try to use the suspend skript i get cpio errors.
cpio: Ungültige Nummer kI������ cpio: Ungültige Nummer I������ cpio: Ungültige Nummer ������� cpio: Ungültige Nummer ������� cpio: Ungültige Nummer ������ cpio: Ungültige Nummer �����V cpio: Ungültige Nummer ����V cpio: Ungültige Nummer ���V� cpio: Ungültige Nummer ��V� cpio: Ungültige Nummer ��V� cpio: Ungültige Nummer �V� cpio: Ungültige Nummer �V� cpio: Ungültige Nummer V�� cpio: Ungültige Nummer �� cpio: Ungültige Nummer ��� cpio: Warnung: 20414 Bytes Müll (junk) übersprungen zs1|3t��6/�(s�����o�hdƤ��jl�t�Pʈ� �P��E�Y@lj ˏ9��&�!�<7�bzs�ǂ ��v��!kI��������V���_��G��OQ�:�fZ-����ܤGn
������B�
/C̊�)S�������x�q2�ș�ˎ��F��"��|� hLQ1q���2"��3s����A;k�.���t��: unbekannter Dateityp cpio: Vorzeitiges Ende der Datei Press ENTER to continue.
The cli gets flooded with that. After i press enter it just gets back to the login screen. Suspend doesnt engage.
The Error translates (i think) to cpio: malformed number.
Im running the Kernel 5.10.0-19-amd64.

The yubikey-luks-suspend.service does not work with Ubuntu 18.04.

The system does not accept the passphrase.

We should make the suspend configurable. So that you can decide if you want the need to provide the yubikey for wakeup or not. (I personall would prefer "or not" ;-)

Is it possible to change the lockscreen text, which mentions that in addition to a password a Yubikey is needed?

If someone finds out your password and the lockscreen tells him that he will also need your Yubikey to login, he could force you to hand it over to him. As an improvement of security there should be an option to remove this message from lockscreen.

Thanks!