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…
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?
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?
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.]
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.
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
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
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.
@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.
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.
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.
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.
@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:
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.
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.
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.”
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. @llelectronicsupdated 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).
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.
Please stop with this constant refrain. As a developer I get reasonable support from Jolla in exchange for reasonable effort on my part. I think recent efforts (to 4.1) demonstrate the willingness and stuff like the move to github and obs resurrection are signs of progress.
@olf, while I share many of your experiences, let’s get thread back on track in terms of discussion of encryption implementation. Your points, as well as response of @Thaodan and @poetaster are sufficient and if there is a wish to discuss general community meetings and community interaction with Jolla, please consider opening separate thread. Otherwise we get side tracked and loose the focus. Hence I am not going to reply to the points raised regarding communication between parties and I am sorry that my hesitance regarding raising the issue on the meeting. Still don’t know exact question to ask, but will deal with it if I find it necessary closer to the meeting.
@Thaodan - had to lookup NIH to realize what it means in addition to https://www.nih.gov/ . Find it funny when this term is used together with systemd as a part convincing to use systemd for everything. In principle, unlocking and managing LUKS is far from rocket science and probably the hardest part is now to hook it to GUI. @vknecht pointed to PostmarketOS postmarketOS / osk-sdl · GitLab that I will look into. As Jolla has closed-source implementation of unlocking UI, would have to find some alternative. Not sure I want to use OSK-SDL fully and whether it is able to show up during a boot - this will have to be tested. As pmOS doesn’t use systemd, they have to implement full stack. We are probably on “simpler” position.
Note that Ubuntu Touch and Droidian devs are also looking for LUKS unlocking implementation. So, there is a general interest in getting it done. Let’s see if we can come up with something multiplatform as well.
It seems that you’re feeling frustrated. I’ve been there (I too originally came from the community), Do rest assured that our intention is to work with the community.
I’ll try and answer some points - I apologise if I miss any context and I’m very much just getting up to speed with community life after a long hiatus working on other personal projects. Please be gentle
I think you should also bear in mind that Jolla, as an organisation, has commercial interests and is not a pure open source project so we do acknowledge that these limit our ability to share future plans and we’re also very limited in the resources (basically time) that any individual can allocate to the community - I think all of us do at least some of community work on our own time and as community members.
Formalising things is a double-edged sword. It makes it clear how to get things done and can also be seen as a barrier.
As Thaodan said - we, as sailors, need to ensure that what we communicate is in fact what’s being planned, usually by another busy team. This needs us to ask around and often discuss what to say.
Questions are not a one-way street. We would like discsussion so asking for people to be present to ask their questions (or to nominate a proxy to do it for them) happened when people would ask questions and not be present for the discussion afterwards - that’s reasonable isn’t it?
As an aside these community meetings are not far off what I (as a community guy) tried to get way back in MeeGo times.
So you would like us to track these promises to respond in a more formal manner? I’ll discuss it internally
Seriously, I agree and will ask Sim who chairs the meetings to say how he handles this.
(Actually someone made a suggestion… would you like to take on that role/responsibility? Serious offer.)
This usually is a response to questions about future plans or dates (like Qt6 etc). Of course keeping packages updated is in our plans - but plans change all the time and making public statements about them and then failing to meet those dates would result in more ‘feedback’ so we tell you why we don’t comment on them… and people ask anyway… sigh
It’s going to vary and some is not going to be what may be hoped for (especially when it’s about plans, like VoLTE, XMPP as above). Also bear in mind that we don’t and can’t plan externally. There are simply too many commercial considerations that affect prioritisation and direction.
Saying sailors “usually” offer “nothing constructive” seems a bit harsh don’t you think?
Aside if you want to follow the work then please see the public git repos in the relevant packages.
We do take extensive code from the community - I think Damien is a great example of that.
Sometimes however I think we need to find a way to say “sorry, that approach doesn’t fit” and sometimes it’s difficult to find a way to say that. Maybe we should hire the old Linus?
In your previous point you say “only to use the community as paying beta testers” and now we should “extract so much out of the community”? It’s a hard balance isn’t it.
Contributing code to packages and an OS is hard. It takes a lot of time and energy - and often specialised knowledge.
Quite a few people who work for Jolla would differ - because that’s how they came to work for Jolla
Community contributions are not just code for the OS - look at what @piggz and @rinigus have done with the OBS and Chum recently - look at what @Basil has done for years with OpenRepos.
Anyway, I suppose I’m trying to show you the other perspective. The passion (and frustrations) that comes in from the Jolla side (do you seriously think that individual sailors don’t want to share our plans and shout about what we’re working on?) . The community and company may not always be perfectly aligned and there may be miscommunication on both sides - but there is a real caring on both sides.
so we tell you why we don’t comment on them… and people ask anyway… sigh