Yubikey support request

[TimFW]

I would love to see you offer yubikey support. Its now almost the defacto standard for two factor auth hw especially among individual-small to medium size businesses.

I, personally, would be more than happy to donate to DTA a number of new yubikey 4 sticks so that you can use for development testing and your own use afterwards. Being a individual I am only able to do so much but IMO that is the least I could do to say thank you for the work. I also know for a fact this would drive many people into using this software.

I seem to see the request for new functions most activity is for sleep function and can not help but think SOME of thpeople that want this possibly do not understand the security ramifications or complexity of this from a PBA level or possibly may be rather willing (not need) this level of security and care more for the convenience at the cost of some security. TPM are not full proof and intel has already shown its willingness to break/weaken encryption (breaking the rng) We use TPMs only for confirming the sealed hw pcr from tampering, never actual crypt paraphrase key file storage. Hibernation on a current opal 2 ssd is what 15 sec to bring back up. Battery life is already 2x that of just a couple years ago and most savings can be gotten from scrn off and cpu power management when at rest settings.

But the one area of hibernation when using a properly formed and length paraphrase is its reentering. When tired or in a rush this can be a bit of a issue. Yubikey would tech allow a shorter password and still add considerably more security and even more so if password length is not cut. I personally would still keep a very strong phrase but others may then go to a short pin and still have higher security. But I think this would also help those wanting the sleep function as they could set a shorter pin and thus log in much quicker than say a 21 character covering all various ascii groups.

Yubikey has supplied all the packages other than the standard crypto libraries which are already out there. It seems adding its function to your current linux PBA image would not be too extensive. It would work in challenge and response mode and most would likely use slot 2 for this as slot 1 is already preconfig for OTP with there server auth. There certainly have been numerous github projects that offer this for luks and linux login

I already created a full use rescue usb that includes on board copies of the pba images to give a full feature rescue one stop shop. Thank you for helping with that. I will have to see how this new updated now named SEDUTILs looks as it was the last version of MSED I am presently running. See you have added uefi support very nice as it has good timing with Qubes full change over to multiboot soon as right not their uefi is not as fully supported as legacy bios mode.

So the offer stands I am willing to donate a number yubikey 4 sticks to help get yubikey support for SEDUTILs dev work and use by the devs.

Cheers,

Tim

[snow3461]

Don't know if you have coding experience, but did you see #4 . @rookierks did is own implementation for archlinux. For source : https://aur.archlinux.org/packages/sedutil

Would love to see this implemented, but its out of my league. (Not enough knowledge)

[TimFW]

Sorry but I am just learning coding. Most of my time was spent in netsec. I finally decided I had to learn coding so I could make some changes I like but I am a super greenie. LOL

If I am understanding what rookierks did was to implement luks into the actual pba image and then basically use the Yubikey in C&R to unlock the challenge and then after proper unlocking save a new challenge. I would think for sure C&R mode is easiest way. I am looking into this and seeing if I can make it work of get rookierks to give me some pointers.

With that said all one has to do is a search of the security forums to see that yubikey is red hot in terms of use and wanted use. To me it is a perfect fit for sedutils. It greatly enhances the security model of SED in the one area we as users control. We can not control the black box so we have to trust it weather we like it or not. But we can certainly go from just something we know (paraphrase) to something we know and now something we have. Yubikey seems to offer a good deal of open source tools and code which I think is great and blends well with this project.

Thank you again for the help and pointing out the #4 and the link. It is very helpful.

[rookierks]

I'll try to summarize what I did.

LUKS is used to securely store your plaintext admin1 password, the same you provide to sedutil to unlock the SSD. This way you can fallback to plaintext password input if you don't have access to your yubikey or keyfile.

The yubiley is used in challenge-response mode using the second slot, you provide a challenge (pin/password) and you get a response. This response is used to unlock the LUKS volume which contains your plaintext admin1 password which is then used with sedutil.

There is another alternative, using a usb drive with a keyfile. The way it is implemented is: it will read a pre-defined amount of data from a pre-defined location on the usb drive. This will be used as a key file to unlock the LUKS volume and get access to your plaintext admin1 password which is then used with sedutil.

If a yubikey or the proper usb drive is not found it falls back to plaintext password.

You can have up to eight devices unlock the LUKS volume, as that is the number of LUKS keyslots.

Be aware that I did leverage all the infrastructure already in place in Arch Linux, all I did was write a custom hook that is added to the initramfs.

[TimFW]

Thank you very much for replying to thing. I take it I could use any of the tcg created users passwords to be sealed in the Luks file. Example I could create a user in the TCG credentials with full read write access to the encrypted section or even a specific partition inside. This is a great stop gap measure. I appreciate you sharing your work.

While this setup as you have stated is not ideal still it does add protection to one of the most used avenues for capturing passwords. Visual and keyloggers. As now you would need a dif password plus the key a person would hopefully one be able to get one or other other. A nice thing maybe to add would be that after a certain number of unsuccessful attempts it deletes the luks file. This would stop someone from trying to possibly brute force the luks if they did get the lubikey device but did not know the pin.

I am actually running Qubes OS. Its security focused OS with a modified Xen hypervisor as the backend with linux front end UI and a number of supporter pv-vm that are linux. As well as the typical H-VM. One of the reason I was so excited about your work is that I just finished successfully compiling and Archlinux pv-vm. So I can build your AUR package. Issue is I am very new to archlinux specifically doing a PKBUILD from repo. I will contact you via email with further questions if any or thru AUR as its not really directly related to the SEDUTIL app. Thank you again for giving further details. It helped me get a better understanding of how you have it functioning.

Back to my request for SEDUtils:

Ideally if DTA was going to do it I would hope they would follow the most complex but also far more secure way as laided out in the yubikey papers.

As I stated my offer stands to supply DTA with yubikeys for there devs. If I could offer more I would but as a individual there is only so much I can do. If I knew how to code I would help out there.

[rookierks]

A nice thing maybe to add would be that after a certain number of unsuccessful attempts it deletes the luks file. This would stop someone from trying to possibly brute force the luks if they did get the lubikey device but did not know the pin.

It is not possible to delete the luks encrypted file because it resides in the shadow mbr and that is read only, you can only modify it if you have the admin1 password. This is a good thing, assuming there are no security holes in the ssd's fw, then it prevents evil maid attacks on your pba image. It doesn't prevent tampering with the rest of the hardware though.

Besides, if someone got hold of your yubikey and your ssd I'd say it's game over, there is no need to run the pba script/program to unlock the luks encrypted file, it can be done on another machine.

[corporategoth]

FYI, I added support for yubikey (and TPM and USB) with this pull request: https://github.com/Drive-Trust-Alliance/sedutil/pull/86

Though you DO have to build your own PBA, and would have to do so each time you want to change things like the yubikeys supported or such things. If you are OK with that, it DOES work :)

I've tried it on both CentOS 7 and Arch Linux.

[ghost]

@corporategoth What is the status of your changes? Is it part of upstream now?
If it is not then how to use your fork? In original repo I can find image files (bootable).
But it does not look like we have something similar it in your repo.
Can you provide some short description how to setup PC with your version?

[ghost]

@corporategoth You branch cannot be compiled in CentOS 7

Probably I am doing somethign wrong but I read BUILDING doc and did all the same, but I got the following on buildpabroot:

Making the 64bit PBA Linux system
/usr/bin/make -j1 O=PBA64 HOSTCC="/usr/bin/gcc" HOSTCXX="/usr/bin/g++" silentoldconfig
make[1]: Entering directory `/root/Downloads/sedutil/images/scratch/buildroot'
  GEN     PBA64/Makefile
BR2_DEFCONFIG='' KCONFIG_AUTOCONFIG=/root/Downloads/sedutil/images/scratch/buildroot/PBA64/build/buildroot-config/auto.conf KCONFIG_AUTOHEADER=/root/Downloads/sedutil/images/scratch/buildroot/PBA64/build/buildroot-config/autoconf.h KCONFIG_TRISTATE=/root/Downloads/sedutil/images/scratch/buildroot/PBA64/build/buildroot-config/tristate.config BR2_CONFIG=PBA64/.config BR2_EXTERNAL=support/dummy-external HOST_GCC_VERSION="4 8" SKIP_LEGACY= /root/Downloads/sedutil/images/scratch/buildroot/PBA64/build/buildroot-config/conf --silentoldconfig Config.in
*
* Restart config...
*
*
* Interpreter languages and scripting
*
enscript (BR2_PACKAGE_ENSCRIPT) [N/y/?] n
erlang (BR2_PACKAGE_ERLANG) [N/y/?] n
gauche (BR2_PACKAGE_GAUCHE) [N/y/?] n
guile (BR2_PACKAGE_GUILE) [N/y/?] n
haserl (BR2_PACKAGE_HASERL) [N/y/?] n
jamvm (BR2_PACKAGE_JAMVM) [N/y/?] n
jimtcl (BR2_PACKAGE_JIMTCL) [N/y/?] n
lua (BR2_PACKAGE_LUA) [N/y/?] n
luajit (BR2_PACKAGE_LUAJIT) [N/y/?] n
micropython (BR2_PACKAGE_MICROPYTHON) [N/y/?] n
moarvm (BR2_PACKAGE_MOARVM) [N/y/?] n
mono (BR2_PACKAGE_MONO) [N/y/?] n
nodejs (BR2_PACKAGE_NODEJS) [N/y/?] (NEW) aborted!

Console input/output is redirected. Run 'make oldconfig' to update configuration.

make[1]: *** [silentoldconfig] Error 1
make[1]: Leaving directory `/root/Downloads/sedutil/images/scratch/buildroot'
make: *** [/root/Downloads/sedutil/images/scratch/buildroot/PBA64/build/buildroot-config/auto.conf] Error 2

It is on CentOS 7 1908 with all latest updates.

Also I have made small workaround: #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 10, 0)

I will try to build it on CentOS 8.

[ghost]

@r0m30 Is possible to implement USB drive support in upstream?

corporategoth solution does not look like something robust.

I can try but my knowledge is not enough for that.

For the moment I have applied fix from https://github.com/Drive-Trust-Alliance/sedutil/issues/160
And changed kernel version in DtaDevLinuxNvme.h to support latest CentOS 7.

And finally I prepared correct building script which is up to date and matches filenames in images directory:

echo
echo 'Building the PBA program'
cd ./LinuxPBA
rm -rf dist
make CONF=Release
make CONF=Release_x86_64
make CONF=Debug
make CONF=Debug_x86_64
cd ../images

echo
echo 'Building sedutil-cli'
cd ../linux/CLI
rm -rf dist
make CONF=Release_i686
make CONF=Release_x86_64
make CONF=Debug_i686
make CONF=Debug_x86_64
cd ../../images

echo
echo 'Getting TinyCore and syslinux'
./getresources

echo
echo 'Build the PBA kernels and root filesystems'
./buildpbaroot

echo
echo 'Build BIOS image'
./buildbios Release

echo
echo 'Build UEFI image'
./buildUEFI64 Release

echo
echo 'Build rescue 32'
./buildrescue Rescue32

echo
echo 'Build rescue 64'
./buildrescue Rescue64

[r0m30]

@hardhub Are you asking for usb SED support or USB yubikey support?

[ghost]

@r0m30 I mean to store key on flash USB drive to insert it on boot instead of typing password (or as option it can be both usb drive + password).
I think yubikey is another way to get the similar behavior. But I mentioned more common USB flash drives.

[alexdelorenzo]

This would be great feature :)

[alexisfrjp]

Just sharing here since it's the first link we get for "yubikey sedutil".

If you just have linux installed on your encrypted drive, LUKS/cryptsetup now supports Opal natively, no need for a PBA anymore. It means support for yubikey, keyfile on usb drive, ssh, anything LUKS can do.

• https://lore.kernel.org/cryptsetup/cd409f6c-5d51-482c-8a26-340822754ff1@gmail.com/T/
• https://alexdelorenzo.dev/articles/cryptsetup-luks-self-encrypting-drives

--hw-opal-only to get only Opal and no software encryption as usual with LUKS

The biggest advantage is that it looks like secure boot and sleep are supported too.

For any other OS(windows), you still need sedutil with a PBA.