Yubikey support request about sedutil HOT 12 OPEN

FYI, I added support for yubikey (and TPM and USB) with this pull request:
#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.

from sedutil.

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.

from sedutil.

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.

from sedutil.

@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.

from sedutil.

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)

from sedutil.

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.

from sedutil.

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.

from sedutil.

@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?

from sedutil.

@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.

from sedutil.

@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 #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

from sedutil.

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

from sedutil.

This would be great feature :)

from sedutil.