How hard can it really be to implement a minimal on-screen keyboard at an early stage of boot?
For a start you have to contend with people whose passphrase includes non-ASCII characters or indeed who don’t use ASCII at all. In other words, a minimal keyboard may lock you out of the device.
Maybe a minimal keyboard is OK in the Anglosphere but even then some Anglophones might like to be tricky. 
1 Like
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.
2 Likes
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.
It looks like the Ubuntu Touch folks were considering the use case of an on-screen keyboard to unlock full-disk encryption, and drew a blank.
4 Likes
Thanks for the research.
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.
I would not care. Even if it were a klingon keyboard. as long as it has enough symbols for a not too long strong password.
So Ascii keyboard would be totally fine. Simply choose a password with that character set.
But doing any keyboard at that stage is hard. Even getting the touch functionality run I guess is tricky.
1 Like
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.
2 Likes
The question is “when,” not “if.”
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:
2 Likes
I see this In the I.MX8M CPU sheet: “DRM support for RSA, AES, 3DES, DES”
( Source: https://www.nxp.com/docs/en/data-sheet/IMX8MMCEC.pdf )
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:
1 Like
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).
4 Likes
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.
2 Likes
rngd seems to do statistical tests for goodness on the data stream coming from the HRNG also (reporting the results hourly in /var/log/syslog).
That link is incorrect. Don’t know whether the forum software broke it. Let me try:
Looks like the forum did something to the single quote that is in the URL. Somehow you got it to work. Thanks!
I do not understand if purism uses a full disk encryption by default.
Kyle answered the question for performance of LUKS here:
I guess this answers the topics original question
3 Likes