I want to use a bluetooth keyboard during initram

Question

I use encryption on my hard drive. To boot I need to type a password during initram to decrypt the root partition. I'm running Archlinux on a tablet PC without physical keyboard (only Bluetooth). For now I need to carry a USB keyboard with me in case I need to reboot.

Note that I'm not always connected at boot (so early-ssh or mandos are not viable solutions).

Does anyone know how to use bluetooth at boot ? Has anyone tried ?

Solutions for Debian and derivated are also welcome, though I like Arch's way.

PS : I assume this may seem illogical to weaken the security of my device (see comment), but I'm a movable target and I harldy have to type this password. Moreover, were I so concern about security I wouldn't draw my bluetooth keyboard at all, I just don't want the drive to be readable once the pc down.

Solution 1

i can give you an outline here on how to do it, but not a spcific step-by-step, at least i am try.

• You should change the /etc/mkinitcpio.d/linux.preset file to include the right module and files that is needed for the bulethooth keyboard to work. ( you probably edited this file to include the encryption of the HD)
• Afterwards you should create the new initramfs file with mkinitcpio -p linux (you probably wnat to change the current one at /boot/initramfs-linux.img (you can see which one is it by explore your /boot/grub/menu.lst file), to be /boot/initramfs-linux.img.bck.

see this link from the Arch wiki on how to create this file.

Solution 2

It would be simpler to have the root filesystem unencrypted and just delay mounting the encrypted /home till after the OS is up.

If you only encrypt /home and not the rest of the system, some potentially sensitive files will be exposed: temporary files in /tmp (which can be alleviated by using tmpfs for /tmp) and /var/tmp, log files in /var/log, email in /var/mail, printed files in /var/spool/lp or /var/spool/cups, etc. (Note that confidential content in deleted files might still be recovered, too.)

Don't forget to encrypt your swap. Unless you want to hibernate, you can use a random key for the swap.

Comments

[Admin]

So, I'd like to point out, that the encryption on your bluetooth keyboard is likely far weaker than your hard disk encryption, and further that Bluetooth sniffing from over one mile has been demonstrated, on the cheap

[Admin]

you should add the bluethooth support to your initramfs, it is done with mkinitcpio at Arch linux. see here: wiki.archlinux.org/index.php/Mkinitcpio

[Admin]

@derobert Recent versions of Bluetooth have working crypto. I don't know if keyboards offer this. And Bluetooth security depends on having secure crypto and secure pairing; I don't know what pairing you can get on a Bluetooth keyboard.

[Admin]

@Gilles I guess this involves lots of config and executables to have it run in initram... Question still pending.

[Admin]

This isn't so hard really - especially in Arch - your initramfs is just a disk image. So whatever it is you need on your regular system to get bluetooth up and running is what you need in your initramfs. That's all. Maybe look at the following for some idea of you navigate your way around. I suspect that it's even easier if you systemd as init. Do mkinitcpio --hookhelp systemd for more info there.: unix.stackexchange.com/questions/123303/…

[Admin]

Would be best if there existed virtual keyboards for text consoles, working with frame buffers. I see none alas.

[derobert]

That has some drawbacks. Its very easily to accidentally disclose something private when it gets written to, e.g., /tmp or /var/tmp; logs in /var/log may need secrecy too, etc. You can run rootfs readonly, but not /var. And you'll need /var mounted to get bluez up, I suspect.

[MP0]

Thanks! I did have this reasonning but I'm missing a way to manage the keyboard (and for now I don't have a clue how to do it apart from using bluez, with all the trouble it brings)

[Gilles 'SO- stop being evil']

@derobert It's ok to have an unencrypted OS if you configure it carefully and are aware of the limitations, assuming that it's your own user's data that you want to keep confidential. Often /var/log is somewhat privacy sensitive but not otherwise confidential. /tmp is easily handled by making it tmpfs (which is a good idea anyway). The printer spooler is one thing to watch for.

[derobert]

@Gilles: Print spooler is definitely an easy one to overlook. Same with cron and at jobs (remember at jobs copy a lot of environment info automatically). Databases (e.g., MySQL, Pg) are also usually in /var. Also /var/log/auth.log may contain passwords (accidental entry into username field), strikes me as confidential. Locate database is also in /var (exposes confidential file names). Very hard to get right.

[user2914606]

and don't forget all the goodies in /etc. e.g. /etc/shadow, /etc/passwd...