Support disk encryption

[PhoenixLandPirate]

Phones should be able to have encryption.

[Flohack74]

Uh this will be a though one... At boot time you need to present a kind of GUI to enter the passphrase. So most of the system needs to have booted already. Maybe this is possible before mounting userdata, but its definitely smth that needs proper planning =)

[NeoTheThird]

I agree, but it should be on the wish list. We're claiming to focus on security and privacy after all ;)

[NeoTheThird]

Encrypting the home folder would probably suffice, though.

[nanu-c]

Yes please

[dobey]

Encrypting the home folder is probably not that easy to do either, and will likely break libertine or just regular chroots.

[PhoenixLandPirate]

There is a forum post about how to do this, it does seem to have a few issues atm, but people are enjoying home encryption.

https://forums.ubports.com/topic/1012/one-method-to-encrypt-home-phablet/26

[joshbowyer]

Bumping as this is going to be pretty crucial for a mobile device. I read that PostmarketOS handles this by having a virtual keyboard loaded with the init, if that was done then the typical LUKS passphrase request on boot should be handled fine, right?

[Flohack74]

Well if you know how we can show a virtual keyboard without the Android display drivers running then it would be fine yes ;)

[joshbowyer]

Would VESA display drivers not work for that step?

[Flohack74]

No. Android devices do not have an open display stack. Thats one of the complications of our efforts, we need to use all closed-source vendor-dependent code for the copyrighted/IP-driven parts of the phone, mostly GPU and radio, but also sensors and camera. Thats all totally incompatible with normal Linux software and needs adaption layer (libhybris) but also it needs running services. If you want to go in-depth, ask yourself the question, how you would avoid making your drivers open-source when using Linux kernel and not violate the GPL? Exactly, put the drivers as services into userspace (needs a running service), and make only a shim driver into the kernel. Voila, copyrighted code in a Linux kernel environment :)

[Flohack74]

Thats how it works in reality for us:

[Flohack74]

You see that the LXc container needs to be started, so unless this is up and running no cannot get any user input for entering a password. However, since userdata is stored in a bindmounted folder, one could convert this into using an image file, and encrypt that one. Thats a bit closer to what you want to achieve.

[joshbowyer]

Screw Google lmao

Ok, what about for open phones then? (Pine, Librem, future projects)? Could there be an implementation for encryption in Settings that is available on free hardware but grayed out on closed hardware/android?

So basically add luks support as normal but disallow if eg. android is detected

[Flohack74]

Yes for the Non-Android phones its totally possible.

[dobey]

You see that the LXc container needs to be started, so unless this is up and running no cannot get any user input for entering a password. However, since userdata is stored in a bindmounted folder, one could convert this into using an image file, and encrypt that one. Thats a bit closer to what you want to achieve.

This isn't quite true. Recovery can obviously provide UI elements without that. However, our recovery is rather simplistic still, and I think on some devices it is problematic to rebuild it. Though, for the devices where we can rebuild, it would indeed be possible to provide UI for entering the PIN/passphrase to unwrap the key and decrypt. Just the same as Android does on older devices.

However, we still have the problem here that the key and data have to be stored on the same device, and the bootloader can't be locked again, so if someone does gain access to the device, the wrapped key can be brute forced externally, leading to eventual decrypting of the data.

There is also no trivial and automated way to back up and restore all user config/data, in case it needs to be destroyed on the device due to PIN/passphrase failure count at decrypting stage and such.

Everyone likes to think "oh, I can use LUKS with dm-crypt and everything is now safe, so you should do that like a traditional PC Linux!" but in reality full disk encryption is a much more complex issue to solve.

[sgon00]

Hi, I am new to ubuntu touch and have never used any linux OS on phones before. I found this issue by googling "ubuntu touch luks". Any updates on this issue?

Without LUKS encryption, people will be able to check my files when they get my phone and this is really insecure. The reason why I want a linux phone is because I don't want people to steal my privacy. I don't trust vendor's ROM and I think vendor will be able to unencrypt my files even if my Android fs is fully encrypted.

Can I at least create a luks partition in gparted (or some kind of partition tools, i am not sure if gparted available in ubuntu touch or not) and mount it?

Thanks a lot.

[Flohack74]

@sgon00 I am afraid this is also not possible, you cannot really interfere with the partitioning of the device, that might render it unbootable (Android bootloader needs to be used and makes assumptions about your partitions). It still remains the question how you gonna display the "Enter passphrase to unlock data" Dialog when booting. As long as this is not solved, none of the encryptions makes sense, whetever you could create it or not.

[nanu-c]

We can go the PostmarketOS way and include an SDL-OSK in the initramfs:

https://gitlab.com/postmarketOS/osk-sdl https://wiki.postmarketos.org/wiki/Osk-sdl

[fredldotme]

If not in the initramfs then at least at early boot, so that Jumpercable devices also work.

The thing though is that, from an architecture perspective, we really need to consider the big picture more than just "let's ship something for users to be happy quickly". There are logistical reasons not to support more than one way of encrypting the device. I'm more than happy to brainstorm ideas, but in the end this really needs to be carefully crafted, else we're stuck with maintaining two possibly incompatible encryption methods.

[Flohack74]

@nanu-c problem is not all devices use initramdisk now ^^ like Android 9 decided to directly mount / and load init from there. Just as an example.

[pdolinic]

We can go the PostmarketOS way and include an SDL-OSK in the initramfs:

https://gitlab.com/postmarketOS/osk-sdl https://wiki.postmarketos.org/wiki/Osk-sdl

A device without full-disk-encryption is unfortunately not usable by those who want to use it for a 2nd phone and know the risks of having secrets extracted. I would be willing to donate to your project, but this won't happen unless I can use it as a daily driver.

[jonathango1]

Is there any reason not to encrypt only /home so that the system itself is already loaded and the virtual keyboard can be displayed? That's how Sailfish OS does it, as far as I know.

It may not be equally secure as full disk encryption, but definitely better than the current situation. In fact, the lack of being able to encrypt my data is currently the main reason for me not to use Ubuntu Touch as a daily driver yet. I would even donate some money for the work.

[fredldotme]

To calm down those who cannot switch due to lack of trust in the concept of still-unencrypted home data:

I have a plan, but that requires focal and we're not there yet. As soon as we have a UI/UX for it in our hands we can talk, but it needs someone to prepare for dragons in the overal utility of the OS for some time.

EDIT: Specifically it needs an actually usable build of fscrypt but that in turn means building with Go and there a lot of dependencies are missing (I tried, I failed).

[simpz]

Aw, really sad on this one. I just started testing Ubuntu Touch and assumed encryption would just be there on a mobile OS. Was looking to replace the now removed Full Disk Encryption in Android with something that would have this.

Just registering as another interested party on this.

[nanu-c]

What do you mean by lot's of dependencies @fredldotme ?

nanu@Maulwurf:~/go/src/github.com/google$ git clone git@github.com:google/fscrypt.git
Klone nach 'fscrypt' …
remote: Enumerating objects: 3742, done.
remote: Counting objects: 100% (523/523), done.
remote: Compressing objects: 100% (212/212), done.
remote: Total 3742 (delta 297), reused 424 (delta 284), pack-reused 3219
Empfange Objekte: 100% (3742/3742), 3.00 MiB | 1.29 MiB/s, fertig.
Löse Unterschiede auf: 100% (2292/2292), fertig.
nanu@Maulwurf:~/go/src/github.com/google$ cd fscrypt/
nanu@Maulwurf:~/go/src/github.com/google/fscrypt$ make
fatal: Keine Namen gefunden, kann nichts beschreiben.
go build --ldflags '-s -w -X "main.version=v0.3.3" -extldflags ""' -trimpath -o bin/fscrypt ./cmd/fscrypt
# github.com/google/fscrypt/pam
pam/constants.go:51:10: fatal error: security/pam_modules.h: No such file or directory
   51 | #include <security/pam_modules.h>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:94: bin/fscrypt] Fehler 2
nanu@Maulwurf:~/go/src/github.com/google/fscrypt$ code .
nanu@Maulwurf:~/go/src/github.com/google/fscrypt$ sudo apt-get install libpam0g-dev
[sudo] Passwort für nanu: 
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden NEUEN Pakete werden installiert:
  libpam0g-dev
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 113 nicht aktualisiert.
Es müssen 117 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 403 kB Plattenplatz zusätzlich benutzt.
Holen:1 http://at.archive.ubuntu.com/ubuntu jammy/main amd64 libpam0g-dev amd64 1.4.0-11ubuntu2 [117 kB]
Es wurden 117 kB in 0 s geholt (602 kB/s).
Vormals nicht ausgewähltes Paket libpam0g-dev:amd64 wird gewählt.
(Lese Datenbank ... 409401 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../libpam0g-dev_1.4.0-11ubuntu2_amd64.deb ...
Entpacken von libpam0g-dev:amd64 (1.4.0-11ubuntu2) ...
libpam0g-dev:amd64 (1.4.0-11ubuntu2) wird eingerichtet ...
Trigger für man-db (2.10.2-1) werden verarbeitet ...
nanu@Maulwurf:~/go/src/github.com/google/fscrypt$ make
fatal: Keine Namen gefunden, kann nichts beschreiben.
go build --ldflags '-s -w -X "main.version=v0.3.3" -extldflags ""' -trimpath -o bin/fscrypt ./cmd/fscrypt
go build --ldflags '-s -w -X "main.version=v0.3.3" -extldflags ""' -trimpath -buildmode=c-shared -o bin/pam_fscrypt.so ./pam_fscrypt
rm -f bin/pam_fscrypt.h
nanu@Maulwurf:~/go/src/github.com/google/fscrypt$ cd cmd/fscrypt/
nanu@Maulwurf:~/go/src/github.com/google/fscrypt/cmd/fscrypt$ go run .
fscrypt: no command was specified

Usage:
  fscrypt COMMAND [arguments] [options]

Commands:
  setup     - perform global setup or filesystem setup
  encrypt   - enable filesystem encryption for a directory
  unlock    - unlock an encrypted directory
  lock      - lock an encrypted directory
  purge     - Remove a filesystem's keys
  status    - print the global, filesystem, or file status
  metadata  - [ADVANCED] manipulate the policy or protector metadata

Options:
  --verbose                    Prints additional debug messages to standard output.

  --quiet                      Prints nothing to standard output except for errors. Selects the default for any options
                               that would normally show a prompt.

  --help                       Prints help screen for commands and subcommands.

exit status 1

[mr-gittes]

What's the status here on FDE / LUKS encryption?

Would it be possible to

1. put the UI into the Android bootloader, before loading the kernel?
2. get rid of Android HAL/LXC completely?

As an alternative, is that possible: LUKS encrypt an external sd card and mount it at boot, which can be decrypted on any other device/PC ? ... Things that are ignored to be implemented on plain (D)A(mn)Droid ..?

[pdolinic]

Come on guys we gotta push this. Neither Iphones nor GrapheneOS are the solution.

Maybe set up a donation fund so we can get additional developers hired?

[locness3]

However, we still have the problem here that the key and data have to be stored on the same device

Why would the key be stored on the device though? I am not very informed but this sounds like a weird way to do encryption. Could you explain how this would work and why it would require this?

Is there any reason not to encrypt only /home so that the system itself is already loaded and the virtual keyboard can be displayed?

If I read the thread correctly this has not been answered - so, is there any reason? Could this be prioritised over full encryption if it is easier to do ? I feel like this would be a very good step forward.

[sabirovrinat85]

Why would the key be stored on the device though?

It is master-key that would be stored, of course it'd encrypted by for ex. argon2id function, but when potential hacker has this key he can use guess/word/brute force attacks to try to decrypt master-key and therefore data. If using strong enough password, this can be of no issue, but anyway having master-key (and LUKS2 header detached on some external drive) just way safer. I myself see it as no problem, coz it is mobile device, so no one could insist that it has no useful data (as it'd be with some attached hard drive), just go with complicated password, that's it.

Is there any reason not to encrypt only /home?

You can encrypt only /home/USERNAME folder but security issue comes from swap space on devices memory - if you had time to turn off your device and data in RAM became really (impossible?) hard to extract to get the master-key, it can be stored (along with many other very sensitive stuff) in swap, which hacker could (and certainly would ) examine