mhogomchungu/zuluCrypt

[Feature request] Yubikey as a challenge:response 2FA

bungabunga opened this issue ยท 30 comments

Would you consider adding an option to have Yubikey (models 4, 5 and Neo) as a challenge:response 2FA with LUKS containers?

Pros:

  • having a device with secure element as a 2FA is more secure than keyfiles because keyfiles can be stolen (even from USB key) if the computer gets a trojan.
  • Yubikey already works as a challenge:response 2FA with LUKS with linux full-disk encryption so I guess implementing it in zuluCrypt (full-disk + container encryption) shouldn't be very hard.
  • although Yubikey firmware is closed source computer software for Yubikey is open source.
  • Yubikeys are widely used globally, some even consider Yubikey a security standard.

I guess you'd say: but I don't have a Yubikey! Well, I made a similar feature request in the past for Keepass4Android and the developer said the same. Then I made a ticket in Yubico customer support asking them for a free Yubikey for the developer. They responded in just few hours and he got his Yubikey in one week. So I guess they're pretty interested for devs to program with their device.

Thanks!

Will add support for it if i get my hands on one.

How much do they cost?

Different Yubikeys 5 cost from 45$ to 60$

If you'd like I could make a customer support ticket for you? (don't worry they won't send the key to me, they'll contact you)

Will appreciate that.

I am in Tanzania and its somewhere on the middle-eastern side of Africa.

They may need to know this before committing themselves to sending one just in case they dont ship to this side of the world for whatever reason.

ok, let's first try this way:

hi, @yubichris, would you be able to help this developer with a free Yubikey to get it integrated into his software?

zuluCrypt is a one of a very few front ends to cryptsetup (and TrueCrypt/VeraCrypt also) and it allows easy management of encrypted block devices on linux. I think it is in Yubico's best interest for Yubikeys to get integrated.

Thanks!

If i can make it work with zuluCrypt then i will also make it work with SiriKali[1]

[1] https://mhogomchungu.github.io/sirikali/

Happy to help! Open a support case at yubi.co/support (select "I need technical support") and let us know what model(s) you need for testing. My team can send you a coupon code to order on Monday. If you provide the 5 digit ticket number I'd be happy to make sure the request is expedited.

@bungabunga

What models should i ask for?

@mhogomchungu

Yubikey 5 or smaller 5 Nano if you want a USB-A key

or Yubikey 5C / 5C Nano if you want a USB-C one.

The blue ones don't support challenge:response protocol.

https://www.yubico.com/store/

I just sent the request and the ticket number is #72472]

An update.

I have received an email with a coupon code.

i'm very happy for you. it's a great device, i hope it would serve you well as a developer.

and a special thanks to @yubichris!

An update.

Its on its way and it will arrive on Thursday, 30/05/2019.

Screenshot_20190526_080809

An update:

I just received it.

IMG_20190528_140324

Thank you guys.

very happy to help!

The git version can now unlock volumes using yubikey's challence-responce feature.

Where the option is in zuluCrypt-gui is in the attached image below.

By default, zuluCrypt will sends the challenge using /full/path/ykchalresp -2 -i - command and sends the returned value to zuluCrypt-cli.

There is an option in the config file(~/.config/zuluCrypt/zuluCrypt.conf) to change the slot to send the challenge.

Will appreciate if you can confirm that it works.

Screenshot_20190528_211703

unfortunetly I don't have the knowledge to buld an app (any!) from source without detailed instruction.

What distribution are you using?

Ubuntu 19.04.

  1. What package manager do you use to install/uninstall packages?
  2. Uninstall all zuluCrypt packages you have installed. There will be a bunch of them so make sure all are gone.
  3. Go here[1] and download the following packages: libzulucrypt1_5.5.0.1559142707.2451082c-0_amd64.deb, zulucrypt-cli_5.5.0.1559142707.2451082c-0_amd64.deb and zulucrypt-gui_5.5.0.1559142707.2451082c-0_amd64.deb.
  4. Install them in the order i gave them above. You should be able to install them simply by clicking on each package.
  5. Test the feature if it works or not.

[1] https://build.opensuse.org/package/binaries/home:mhogomchungu/zuluCrypt/xUbuntu_19.04

installed. made a test LUKS container. added YC/chal-rsp password. could not open it with zuluCrypt but can open it with yubikey-luks.
"volume could not be opened with the presented key"

tried to get some logs with Debug Window opened but there was nothing useful there.

You created a test volume with yubikey-luks and zuluCrypt cant open the test volume?

I hit the problem a few times while developing the feature and i discovered the problem and either yubikey-luks missed it or were ok with ykchalresp behavior.

ykchalresp tool adds a new line character at the end of its output probably to make it easier for people who run the tool from the command line and zuluCrypt removes the new line character it thinks its a mistake to pass it on.[1]

yubikey-luks gets a response here[2] and with my limited understanding of bash scripts, i dont see any attempt at removing the new line character and i think the incompatibility between the two tools is here.

I may add a switch to support yubikey-luks behavior but the problem remains of what behavior should be the default.

[1]

if( s.success() ){
auto m = s.std_out() ;
m.replace( "\n","" ) ;
return m ;

[2] https://github.com/cornelinux/yubikey-luks/blob/5df2b95c30fc963bc76291de487b5654e558baf9/yubikey-luks-open#L53

  1. Go to the previous link at[1] and redownload and reinstall the 3 packages(libzulucrypt1, zulucrypt-cli and zulucrypt-gui)

  2. Go to $HOME/.config/zuluCrypt/ and then add to a config file named zuluCrypt.conf the following line: RemoveYkchalrespNewLineCharacter=false.

  3. Start zuluCrypt and check if it can now unlock the test volume.

[1] https://build.opensuse.org/package/binaries/home:mhogomchungu/zuluCrypt/xUbuntu_19.04

I suspect this[1] bug report is primarily caused by yubikey-luks script passing forward the new line character appended by ykchalresp.

This[2] projects removes the trailing new line character[3] like zuluCrypt by default.

[1] cornelinux/yubikey-luks#10
[2] https://github.com/agherzan/yubikey-full-disk-encryption
[3] https://github.com/agherzan/yubikey-full-disk-encryption/blob/4a87009c7562480b1e46a44129315134b39afcbc/src/ykfde-open#L141

I tried what you suggested but without luck. the container still doesn't open.

I also installed ykfde and added a yc/chrsp password to the test volume that way. it also doesen't open via zuluCrypt but it opens with ykfde-open command.

  1. Run ykchalresp tool manually and give it a challenge and then take its response.
  2. Add the response to the test volume.
  3. Use zuluCrypt to unlock the test volume and report if it succeeded or not.

These different wrappers to ykchalresp may be doing things differently and we should first establish that zuluCrypt can work with ykchalresp tool.

what do you mean by "2. Add the response to the test volume"?

[ink@mtz ~]$ ykchalresp -2 xyz
b3d684977f20dadf981418192c8ef5f89160fab8
[ink@mtz ~]$ 

In the above example, i sent a challenge "xzy" to slot 2 of yubikey and the yubikey responded with
b3d684977f20dadf981418192c8ef5f89160fab8 and this response is the key to add to your LUKS volume because it is the value zuluCrypt uses.

Test zuluCrypt by comparing it to a direct usage of ykchalresp and not by checking if it can unlock volumes created by other tools because they may interacting with ykchalresp differently from the way zuluCrypt is doing.

This "ykfde" sends the challenge to ykchalresp and gets the response here[1] but hashes the response here[2] for a reason i can not figure out just by looking at the code. This tool then uses the result of its own hash and not the result returned by ykchalresp.

[1] https://github.com/bpereto/ykfde/blob/4a74a1f483533de6a2ebd5c65d888d1be3995ac3/bin/ykfde.c#L325
[2] https://github.com/bpereto/ykfde/blob/4a74a1f483533de6a2ebd5c65d888d1be3995ac3/bin/ykfde.c#L331

ah, then the problem with yubikey-luks is that I use the hardening as suggested here. options CONCATENATE=1 and HASH=1 in /etc/ykluks.cfg
i don't know about the ykfde.

Closing this one as "fixed".

Thank for the feature request and many, many more thanks to yubikey for offering a few device to test on.