The earlier the stage of boot, the more you have to duplicate functionality provided by the later stages of boot. If /boot is encrypted, then the GUI is GRUB (the boot loader), and it is very limited. If /boot is not encrypted, then the GUI is talking directly to the frame buffer (video memory). This code has to be put into the kernel image or initial RAM disk. There is no GNOME or Wayland at this point, because they are in the partition that has yet to be decrypted.
It is easier to leave more of the operating system unencrypted if you want more friendly passphrase entry GUIs.
The ext4 file system supports file level encryption. Maybe it is possible to encrypt just /home and /tmp, but that leaves /var and swap unencrypted. Swap can be disabled, or enabled with encryption at a later stage of boot with some extra code.
So I guess the good news is that even if we do not get full disk encryption (without requiring a USB keyboard), we will at least be able to encrypt our files.
Hm. Valid points. When you boot fde on a regular pc there is no virtual keyboard
Does someone know how android resolves this? I guess that they also do not start their whole java virtual machine before. Could this maybe be stolen? If not TWRP also has keyboards - could one steal from there?
Most important for me would be to in fact save folders like /home /etc and /var. But I guess if you do the hassle to implement fde you would do it right. I also donât mind having fde as a feature which comes 6 months later, but it defenitely has to be there, as I donât want to travel with an unencrypted phone and also donât want to use my old android phone for my whole life when traveling.
Regarding the opengpg card - if you use it for fde, would you really decrypt the card? The benefit would be having the lock of the card and maybe using smaller passwords? Or would you use the card without password and have the opengpg card decrypt the phone on boot in case itâs plugged in?
Who said it wouldnât support non-ASCII characters? By âminimalâ I meant it wouldnât depend on lots of high-level GUI libraries and daemons, not that it wouldnât contain all the necessary keys.
It might be easier on some level, but it seems like a messy solution.
Even GRUB supports loading a background image from a file. It doesnât seem too far-fetched to me to render an on-screen keyboard at a similar stage in the boot process, or load a pre-rendered one. The graphical representation is probably the easy part. I think the hard part would be driving the touch screen in order to get some coordinates when the user presses the âkeysâ. (Hereâs a Q&A that seems to confirm my suspicion about this.)
Gnome and Wayland would be total overkill just to input one passphrase.
Apparently some devices with UEFI firmware have an on-screen keyboard built into the firmware. The Librem 5 will not have UEFI firmware, so a general-purpose pop-up keyboard would probably be a very complicated thing to replicate. However, the firmware might be a sensible place to implement a single-purpose keyboard that is only used to unlock the rest of the boot process.
GNOME might be overkill, but there are all sorts of preferences/settings that factor into a text entry box and keyboard, virtual or physical. Key layout, language, repeat delay, haptic feedback, sound feedback (no sound driver in GRUB), accessibility settings (high contrast / invert colors, larger font), how soon to mask hidden inputs using *'s, etc. If any of these are needed, then these have to be duplicated. Android phones seem fine with not including any user preferences into the bootup passphrase box, but that sounds like an accessibility bug to me. I guess some disabled people cannot use encryption on Android.
As long as this operating system is used only for the Librem 5, then bringing in a single touch screen driver might work, as a fork. But if they want to upstream it, then someone has to make it work with other devices. At least there is some motivation to do this upstream, but they have to like the solution. If /boot is unencrypted, then the touch screen driver and sound driver are available via the kernel, which saves a bit of work.
If youâre referring to anything I said, I think âresearchâ is overstating it a little!
These donât seem particularly onerous to me, though I speak without much experience.
These, on the other hand, seem like a problem. It would be an accessibility bug to exclude these.
Youâre right about that. I had anticipated that it would need to be modular and capable of supporting more than one kind of touch screen, and that it may even make more sense to just establish a brand new project with the explicit goal of supporting touch devices, if the architecture of existing projects is too difficult to adapt cleanly. But I didnât really think through the implication of having to implement dozens of different drivers. I think youâve persuaded me that it may be more sensible to just use Linux. And if youâre using Linux then it makes sense to use the Linux you already have installed. And if youâre using the Linux you already have installed, then it makes sense to use some of the other components from that installation.
The alternative is to push the complexity into device-specific firmware and have it abstracted to a nice, standard interface. But I think a lot of people prefer to have as little firmware as possible, and it would still be duplicated effort if there is already a perfectly good touch screen driver in Linux.
So⌠any news on this? Itâs pretty much a make-or-break feature. I get it that some people value the Free aspects of the phone more than privacy or security, but having not having encryption on this a phone like this is like having a big bomb-proof bunker with 4 inch thick doors and faraday cage walls but no roof.
I have not seen any evidence that suggests that it has been implemented, but I expect that by the time that they get half way through the preorder queue, there will be a solution by then. If you preordered in 2018 or later, then you will probably get encryption out of the box, or someone would have created something custom to implement it. But if you ordered within the first few months of the crowdfunding campaign, then you might have the phone before that feature gets added. But realistically, if you get the phone that early, you might be using 2 phones for a while for other reasons, unless your smartphone needs are fairly basic.
One thing is for sure, there are enough security conscious software developers using the Librem 5 that full disk encryption will only be a matter of time. This phone has a smartcard feature, so when they utilize that, then I expect a better solution than what you find on most smartphones.
If the new partner announced in this news post follows through, then I would expect a thorough security solution in time:
If this AES is a hardware AES support, then i think, the full disk encryption is feasible, because dont need using the power hungry software AES (or any strong encryption) algorithm.
But, i afraid for the âDRM support:â title, because i dont known, the AES is usable for any application (the LUKS module) or just usable via DRM calls as embedded function?
I dont know, because i dont known how is working this CPU.
I do not think that they would go to the expense of adding RSA/AES and only have it function for DRM scenarios. They are likely advertising that their cryptographic acceleration is fit for use with DRM too. The i.MX6 has cryptographic acceleration. I expect that will still be the case with the i.MX8. The true random number generator is actually important for performance as well.
Here they are using openssl to benchmark AES acceleration:
Not sure why you guys think that hw crypto acceleration is a must for encryption to work on a phone. Basically, the amount of data that gets written to disk should be so low that it should not make any practical difference if itâs just software crypto or hardware-assisted.
Even a dated Allwinner A20 chip can do more than 10 MB/s using aes-xts-512 without hw acceleration (it has hardware acceleration but only for aes-cbc which is why it should not be used).
Some people consider that a hardware random number generator (HRNG) hidden inside closed hardware is a bad idea - as it canât truly be audited for backdoor (intentional flaw) or quality (unintentional flaw).
For a mobile phone perhaps it is unavoidable as alternative HRNG might not be available or might be impractical. Maybe a feature for L5v2? (The Librem Key already has a low bandwidth HRNG so maybe that is good enough once the integration between the L5 and the Librem Key is there - or a similar alternative.)
When I get my L5, Iâll have to try rngd.
This does work with the ARM CPU in the Raspberry Pi (apart from the general disclaimer above about closed HRNG).
I think that most prudent code that touches hardware random number generators will add software whitening. Basically, combining the hardware output with other sources of randomness or near randomness. If you are unsure about a backdoor, just ensure that it is statistically random and XOR the output with a different HRNG that is also proven to be statistically random.
