RFC: Revision of /home encryption on SFOS

@olf, thank you for your thorough assessment. I will respond point by point below. In general, when proposing the solution I kept it to what I think is realistic and doable within reasonable timeframe (few weeks), at least in the first working form with TEE (or Secure Element, SE) support. As for infrastructure, most of the infrastructure is there (LVM and cryptsetup), just the rest needs rework.

But that would have to be a Free Software TEE, otherwise most people will not trust it. Do you trust Qualcomms binary BLOB TEE?

We are using the BLOBs anyway and I would trust it for this application. As for others, don’t know and can’t make choice for them.

USB/NFC tokes being inconvenient for the average user

When designing an approach, we just need to keep those options in mind. I am not planning to spend time on this, but it would be fine if someone interested in it could easily implement such solution. Risk perception is different for different users and implementation should be ideally flexible enough.

IMO, first and foremost we should push Jolla to enable the use of alphanumeric LUKS passphrases, which has been suggested long ago and is a rather minor change. This would enable users who want to input “high entropy passphrases” to do that easily.

Easiest way to push is to write new app that can be used instead. I haven’t found sources for that GUI, I suspect it is closed source (anyone knows the license? github url for it?). Now regarding “high entropy passphrases” and “easily”:

According to https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#5-security-aspects:

"Plain dm-crypt: Use > 80 bit. That is e.g. 17 random chars from a-z or a random English sentence of > 135 characters length.

LUKS1 and LUKS2: Use > 65 bit. That is e.g. 14 random chars from a-z or a random English sentence of > 108 characters length."

I would argue we are in between those two cases, see below. In general, it is advisable to read that section leading to entropy estimation.

For me, typing 16-17 random chars does not sound “easy”.

BTW, “For opening LUKS container: a. get user password from user’s input b. generate user key from password and salt” is exactly what Cryptsetup-LUKS does (with a volume specific salt), then using this “user key” for en- and decryption of the specific LUKS-volume. You just want to add another indirection with an additional key from a different source.

Yes, LUKS does that precisely. This is done to make brute force attack harder. On my PC, it is 133000 iterations. How many iteration does it do on phone? I would expect way less. Which means that brute force attack would be that many times easier. And which indicates that we have to look on the higher estimates for that password length.

Idea behind iterations used in my scheme was to tie it your phone. If LUKS password is 32 byte, brute forcing that becomes impractical. By being able to make iterations on your phone only via TEE (or SE) only, makes your simple password way harder to attack via iterations.

As I once pointed out, I am convinced, that the enhancements you are aiming at are absolute overkill with the current state of security in SailfishOS and its infrastructure

Taking into account length of reasonable LUKS passwords, I would argue that there is no point in stopping mid-way and adding just alphanumeric passwords. As for going for overkill, argument is to fix it properly when fixing and then deal with other issues.

The attacks via stores are different to the attack considered here. Ironically, work on Chum repos actually improves store attacks somewhat. But it is not a subject for disk encryption, I think.

In principle, it is defence against someone stealing yor phone and passing it over to those who specialize on ID theft. I don’t know how large fraction of stolen devices are going through break in treatment. Maybe none. But I don’t want to keep a device way open welcoming parsing the files/accounts in such case.

Jolla better invests their time to alleviate the real, pressing security issues SFOS and its infrastructure have, instead of designing, implementing and deploying an overly complex crypto scheme.

This initiative is not from Jolla, so maybe their investments do go in the right targets. As for being overly complex, I don’t think it is. Let’s see if I am right in amount of work estimate.

I am surely becoming bashed again for this …

I hope not. As your feedback is very constructive and to the point. Thank you!

For other comments by others - I will come back to them later, as soon as I get time.

3 Likes

data is encrypted only if phone is switched off… but honestly, how often do we have it at that state

If your device is protected by PIN and gets stolen, easiest way to get data is to reboot it into recovery and dump fcontainer to SD card. Then brute force open it and go through your storage . This proposal makes it unfeasible . Obviously , if you don’t have lockscreen protection, no encryption on rest is needed (or effective ).

Re SD card encryption : one step in a time :). That you probably don’t want to tie to device, so long alphanumeric password would be in use. In some respect , SD card issue is separate and can be tackled by separate app… Haven’t thought about it much as I backup usin kopia these days.

Re GUI: as I suspect current GUI is closed source , new one is needed anyway .

It has some home encryption support via cryptsetup, but it is somewhat different .

1 Like

I run systemd-homed on my home PC and its LUKS2 encrypted. So there is encryption. But i have no idea what it uses to encrypt the data with (ie my password or if it does something else).
But i suspect you already looked into that. :slightly_smiling_face:

This may have already been discussed but if the salt is stored in /etc (which is not encrypted) and the k is known then the effective key is still just as weak as the x digits that went into it originally and 6 digits even if they are alphanumeric is practically non-existent keyspace, current recommendations are minimum 12 characters (and that is considered weak).

Edit: That being said I understand that typing a full passphrase for a LUKS volume on a cellphone would be a royal pain in the rear but allowing for the false perception of security is not a solution to this, if it is possible to have the key stored in the SoC and retrieved by say biometrics that may be a solution though I expect a lot of people won’t like that one a lot either.

Edit 2: You could use something like an (NFC) yubikey to store the key maybe…

1 Like

I agree with all these points.

Until software audits of existing subsystems pass muster, the passphrase initiative would get us actual mileage.

As to the usability of longer passphrases, poems work for me. Typing them with your thumbs is a bit of a pita, but …

The jolla folk are certainly putting more and more emphasis on the sandboxing efforts for apps which also seems to be a thing that might mitigate the dangers from the remote apps angle?

Still, thanks for the effort, y’all!

EDIT: should https://forum.sailfishos.org/t/urgent-but-simple-to-implement-additions-on-encryption-in-sfos not be considered in this attempt at recommendations?

EDIT2: and as remote points out in the first edit: The Endless Conundrum of creating a secure PinePhone | Dalton Durst has a really nice summary of the problem domain… especially the two passphrase idea, long LUKS passphrase on boot, shorter key for unlock screen.

EDIT3: um, no one mentioned a detached LUKS header? Did I miss something, just re-read the thread… but that might be a luks2 thing and we’re using luks1?

3 Likes

Security is definitely in Aurora/Rostelecom’s remit though I can’t imagine them wanting >8 char passwords. I think they’re the main reason we got encryption in the first place.
Rostelcom won’t be interested in more Android blobs as their whole point of using SFOS is to not use Android/iOS.

I believe SFOS was only broken by hackers going through the Recovery Console and downloading the encrypted partition. This just bypasses any limits on attempts.
We ideally should be able to re-lock our bootloaders – with this being toggle-able from within Settings. It’s notable that unlock-friendly phone manufacturers don’t offer this as bugs could lead to a bricked phone.

Increasing the key complexity helps but is much more annoying for users.
Security measures should be both optional and potentially bulletproof. I personally don’t need encryption. [Nor do I want to have to log-in to my own phone.]

Failing relocked bootloaders, those who need high security could insist on alphanumeric pass + fingerprint scanner (+ dongle?) ie something you know, something you are, something you have.

There’s also the case for having two levels of lockout. The standard 30s lockout and something like a “Going through TSA” lockout. The latter would eg wipe the salt and it could only be recovered with fingerprint/dongle etc.

Edit: clarified Aurora vs user priorities. @rinigus : didn’t realise you were planning on coding this yourself! Awesome if it works.

@poetaster: when designing GUI, I would take make it modular. If you prefer to enter just password without TEE/SE backing, no problem. I envision having options with users selecting a way to encrypt. Also, encryption should be optional, some may prefer not to have it at all.

@David: note that fingerprints are also backed by the BLOBs. Indeed, having unlocked bootloader makes it harder, but it is still possible to keep data safe on rest.

I will look into TEE/SE backing and then will see how to make GUI for encryption setup and settings. Then will have to test it on my development device and hopefully all works as planned.

1 Like

I haven’t got to it yet, but I wanted to find out what it would take to decouple the initial pin input at boot from subsequent input. It seemed, since the process at boot also requires sim card unlocking, that it might be a natural place to decouple. That would allow having passphrase for luks and pin / unlock meet different criteria. Ok, but I’m working on chum/obs stuff (etc) … going as fast as I can :slight_smile:

Original plan for TEE or SE backed encryption for key storage didn’t work out. Namely, when decrypting there is always a check for some data properties at the end of decryption operation. So, I cannot use nested decryption for rate limitation of the brute force attack.

However, it is possible to use approach based on Android disk encryption pipeline. Namely, process the user-provided password using scrypt an salt and then, instead of using it encrypt/decrypt, just sign it with some hardware backed key. Interestingly, there is a key property MIN_SECONDS_BETWEEN_OPS which can be used for limiting number of tries per second. As a result, whole scheme is way easier and no nested encryption is needed:

  • scrypt user provided password with salt → result K1 32 bytes
  • sign K1 with RSA key, hardware backed → result K2 256 bytes
  • scrypt K2 with salt to get 32 bytes → result K3, 32 bytes
  • use K3 as LUKS password

I composed an Android tool based on available AOSP tools and libraries used for encryption (regular and disk). Project at GitHub - rinigus/hwcrypt: Encryption using hardware backed keys .

Now will have to write integration with SFOS.

4 Likes

This should used systemd-cryptenroll[1] when we are at a more recent systemd version.

Everything else just creates unnecessary maintenance overhead. Systemd-crpytenroll allows us to plugin into the Android keystore once we add support for it and allows better integration than by creating a tool around systemd. Also there is no need for the specific quirks in the handling that unlocks volume since the plugin is responsible for those.


[1] systemd-crypenrolll(1)

1 Like

@Thaodan: thanks for feedback. Let me start by stating that I, as a community member, have no idea on Jolla’s plans regarding disk encryption. As improvement has been requested for a while with no response, I could only assume that priorities are different. Hence decided to fix it myself.

It is interesting that you mention systemd encryption support with what sounds as a plan to implement support via that. Which is nice. To integrate it with Android hardware assisted keystore, Android utility or daemon is needed. This can be done now with hwcrypt that I composed on the basis of Android utilities/libs. Now, on systemd side, it would just have to use this utility. I presume some process separation is needed as Android and systemd use different libs.

To get systemd playing nicely with disk encryption on device, we need systemd password agent with GUI. Note that systemd currently doesn’t even support password protected TPM secrets (issue RFE: Allow passphrase in addition to TPM2 sealed secret in cryptsetup · Issue #19229 · systemd/systemd · GitHub). So, if you want to have it, you need to implement it in initrd on PC yourself. Which is easy to do, but not packaged usually. With this in mind, I guess that while you can hope to offload much to systemd, some kind of glue will be needed for user interaction.

In context of your reply, would be great to know what are Jolla’s plans and progress regarding disk encryption. It would be just plain silly to do things in parallel and I would like my time not to get waisted on working on something that will be trashed later. While I accept that there is always such risk, it is way higher when you work on Sailfish. Hence I wrote down RFC early and before implementing it giving time for Jolla to react. I am happy to work together with Jolla developers on it as long as we work on open source solution.

6 Likes

Sounds like a nice question for one of the next community meetings. Even thought i wouldn’t expect a proper answer.

As the was started already, let’s not wait till the next meeting

Please ask before the community meeting so you get the official answer.
My answer was my POV as a developer.

Thanks for linking and replying to the systemd issue.
Systemd already has way to offload similar things to a ui, the issue is “just” to define it.
Currently systemd already allows entering a passphrase when the device changes “to much” (see the manpage linked above). The next thing would be adding a counter for such things.

2 Likes

When I was resizing /home/root, I was thinking about, to put /home on my sdcard. I was warned, that there were files important for booting. So, for now, didnt tried.

├─mmcblk0p76 259:44 0 20G 0 part
│ ├─sailfish-root 252:0 0 8G 0 lvm /
│ └─sailfish-home 252:1 0 12G 0 lvm
│ └─luks-ad1111111122233344566 252:2 0 12G 0 crypt /home

mmcblk0rpmb 179:32 0 4M 0 disk
mmcblk1 179:64 0 119,1G 0 disk
└─luks-d0987654321 252:3 0 119,1G 0 crypt /run/media/defaultuser/1234567890

So, my sdcard is Luks with alphanumeric password, but it must mount later, after /home, when booting.
Most of my user-files are stored on the card.

I my case, you’re totally lost, if you try to reboot in recovery. It is not really diificult to encrypt the scard, or is it?

To switch off the phone in an airport, or during a police control is possible. If the mobile is stolen or lost,
its a little bit different, but the lockscreen seems ok first.

1 Like

@Thaodan, I very much appreciate that you take time and reply as developer your POV. It is very welcomed and helpful. As for asking at community meetings, maybe I should, but let’s see where I get before it.

Indeed, several mechanisms are there already with unlocking using systemd. Haven’t checked whether SFOS init scripts also use rd.luks.key= boot argument by systemd unlocking of LUKS as done on (some?) Linux distros and that can be populated by some secret unlocking mechanism. On PC, TPM2 secret, for example. On phone, that could be generated using hwcrypt together with user-provided password.

Just started looking into what is injected into boot sequence by SFOS disk encryption. @sledges gave some pointers on the last meeting, very helpful. Unfortunately, according to @sledges, several interesting bits are closed source - the ones involved in booting, for example.

Thanks! I was hoping that I could encrypt later in the boot sequence, but it does seem to happen rather early. Which may require some specialized UI for unlocking.

It sound like some (might be even “many”) people are not aware what the “community meetings” provide:

  1. Depleting the energy of community members by creating additional, formal hurdles and efforts for community members: One has to propose questions at the right place and timely in advance, plus be present at the community meeting, or it will be ignored completely.
  2. A way for Jolla to easily ditch questions from the community, without much visibility. Either by aforementioned formal hurdles, but also happens with most of the questions posed at the “community meetings” (e.g. by stating “We will discuss it internally” and no feedback is ever provided). And knowing that far less people read the “community meeting” logs than this forum.
  3. If all this distraction fails, because someone has the energy to run through steps 1 and 2 multiple times with their question, Jolla’s way out is what you already observed: “Even thought i wouldn’t expect a proper answer.
  4. Jolla stated, that one purpose of this forum is community interaction, and obviously some Jolla employees read and sometimes even post here. But again, this is usually nothing constructive, like @Thaodan’s “Wait and do it differently, we may come up with something using that, at some time in the distant future”. And we all experienced many times, that “Jolla time” often means “never” (XMPP support, VoLTE support etc.).

It seems to be an inherent part of Jolla’s company culture only to use the community as paying beta testers (and even that is handled very awkwardly), but ignore almost all other input. Especially developers output and enhancements, rangeing from the many, useful Patchmanager Patches which would have been so easy for Jolla to integrate to big, valuable contributions as e.g. @llelectronics updated QtWebkit (which was proposed at “community meetings” at least three times: Ignored the first time, “we will look at it” without feedback the second time, “Oh, we forgot to handle that internally” without further feedback the third time).

Jolla could extract so much out of the community and there are so many examples of companies doing that successfully (e.g., RedHat, SuSE), but for some reason they do not seem to be interested (consistently since 2013).

7 Likes

The point is that in the community meeting we can give answers that were discussed internally to be able to give definitive answers. I can just state my opinion on it on how I would to do it or why I see the issue but I can’t decide for my self what will happen.
I think you should know how such things work. Including that I come from the community originally, I value community communication and try to improve relations where I can.

The logs linked on top of every community meeting announcement clearly visible. In any case you have to read them no matter where you post them.

Now you just blatantly post a black picture on what I said. I said how I would do it - I want as everyone else the best solution we can get, so I wrote my idea for it that would result in less duplication and NIH.
I prefer to use existing upstream work before I do my own things.

3 Likes