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.

  • 1
    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 – derobert Dec 1 '11 at 17:33
  • 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 – Hanan N. Dec 1 '11 at 20:03
  • @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. – Gilles 'SO- stop being evil' Dec 1 '11 at 23:24
  • @Gilles I guess this involves lots of config and executables to have it run in initram... Question still pending. – MP0 Dec 2 '11 at 18:10
  • 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/… – mikeserv Jun 9 '14 at 20:24

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.

| improve this answer | |
  • 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) – MP0 Dec 1 '11 at 21:08

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.

| improve this answer | |
  • 5
    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. – derobert Dec 1 '11 at 17:46
  • @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. – Gilles 'SO- stop being evil' Dec 1 '11 at 23:26
  • @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. – derobert Dec 1 '11 at 23:34
  • and don't forget all the goodies in /etc. e.g. /etc/shadow, /etc/passwd... – strugee Apr 13 '14 at 6:12

I guess it's related to the issue with the USB Bluetooth dongle, where the driver and firmware is loaded dynamically as a kernel module in later boot phase (HAL/UDEV?) and so the modules resides into the root filesystem which is unaccessible until mounted, sounds like a chicken-egg loop! Compiling the necessary drivers into the kernel should work, as you have the choice to compile drivers/firmwares as modules or statically inserted into the kernel (increasing its size).

Just check the instructions for your distribution about obtaining and recompiling the kernel, then check what module your usb bluetooth keyboard uses and select it in the kernel configurator.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.