Full disk encryption on a tablet device

I’m trying to setup fedora 40 KDE spin on a Dell 7210 tablet. Coming from the Lenovo world, I was quite surprised that there is no hardware based disc encryption for this device.
So I decided to run a standard setup with LUKS encryption. That worked fine, but I can’t unlock LUKS without a keyboard attached. There is no on-screen keyboard available at the unlock screen.
A possible solution could be unl0kr for postmarketOS. There is even a COPR version for it. But I don’t think someone should rely on an anonymous source for such a security related tool.

Any suggestions for a workaround?
Do you have a suggestion for a different encryption solution?
Is there another solution that brings an on-screen keyboard to the LUKS unlock screen on fedora?

1 Like

This is a tough one. . . A workaround would be to utilize an Key file on a USB drive to unlock the device with. Can be easily setup with LUKS.

Another way (I have not tested this. . . ) Would be to modify plymouth and dracut for a virtual keyboard. I think there are plugins for this. Would need to do more research.

1 Like

This is not an answer to your request, but as it might be relevant for you: if I get you right, you mean that the device has no AES hardware implementation? If that is what you mean, I suggest to verify that with lscpu | grep aes → if there is an output (which means the term aes is contained), you have aes. If not, you don’t. I ask to verify as the architecture of ARM differs in many respects from x86_64 (in terms of how/where it implements things), which can lead to the false presumptions about availability of some instruction sets like aes.

If you have no aes, I suggest to use adiantum rather than aes-xts (which is the current default for Fedora disk encryption) because it makes a big difference in performance and thus use of power (battery): aes is not well on software but designed for hardware implementations. adiantum is to mitigate that issue. It is official part of the kernel and widespread on low-end Android devices (this is what Google developed it originally for).

However, since no one had yet the time to implement this in a GUI way, using adiantum would make it necessary that you prepare you encrypted devices in advance to the setup. Some details here:
https://bugzilla.redhat.com/show_bug.cgi?id=2077532

You might note the performance comparison in the github ticket on hardware without AES hardware. This also indicates a massive safe of battery lifetime given that, obviously, the same MB/s is achieved with less cpu power.

@py0xc3 Sorry, I may not have expressed myself correctly. I mean Hardware Full Disk Encryption (FDE) according to the ATA or NVMe standard. On all Lenovo devices I’ve had so far, there was a BIOS option to enable encryption directly in the controller of the SSD via a boot password. For me, this was a sufficient replacement for software-based encryption such as LUKS. My Dell does not seem to have this option.

1 Like

Ah, ok. Then forget my post :wink:

Cryptsetup (LUKS) handles a lot of those features now with the latest versions. Either way i need to look into the Plymouth plugins for you. I would still strongly consider setting up the --key-file with LUKS as a way to have quick access to unlock the machine to get you to the Graphical Login. This way you have the password and the keyfile.

Thanks for your response. That was very helpful.
I didn’t realize that you can use multiple authentication methods for LUKS. I am currently reading through the documentation. Since I want to get a new FIDO stick for passkeys anyway, I could add this as a third unlock option. The Dell device also has an integrated smartcard reader. That would be the fourth option. That gives me enough options to get by without an on-screen keyboard.

Yeah, sorry I did not get back to this sooner yesterday, but I could not find a viable solution or any one I could test and verify it’s codebase (like your link). I honestly would not trust a solution that wouldn’t come from the Distro or Luks team for a virtual keyboard.

1 Like

This feature has a very poor track record for security,
For example one manufacturer was shown to have used the same AES key on all drives. For example Flaws in self-encrypting SSDs let attackers bypass disk encryption | ZDNET

Personally I would use luks even if a drive claims encryption support.

1 Like

@barryascott Back in 2018, I followed these reports closely and looked into the security gaps. There were some simple workarounds (master + user password) for some SSDs. But since then, all manufacturers have delivered updates with fixes.
Even if there was still a gap somewhere: Exploiting OPAL gaps requires specialist knowledge. For me, it’s enough if a random thief can’t read my data. Even with LUKS, I can’t get perfect protection on a tablet. As I wrote above, there is no on-screen keyboard for entering a LUKS password. So I have to find a solution to unlock with a keyfile on a USB stick. This is not perfectly secure either.

Well, I agree that it’s not perfectly secure, because the USB would need to be readable and the keyfile (whatever you choose. . . Picture, binary file, .txt etc ) available for the process to unlock the drive. I assume a FIDO2 or Yubi key would provide more security while the other is more obfuscation than secure.

The keyfile is more “convenience” than secure, while a FIDO2/YubiKey could offer a higher level of security.

During my research I found conflicting information. Some sources claim that a FIDO2 key needs a pin to unlock. This brings me back to my missing on-screen keyboard.
Some sources say that there is a special mode which enables a presence-only unlock. This means that touching the FIDO stick is enough to unlock the LUKS partition. I do not yet understand how this mode works and how it reduces the overall security of the FIDO2 stick. I assume that after activation, a PIN is no longer requested for all possible use cases of the stick.