@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.
No, I donât want to duplicate it if I can avoid it. So far, hwcrypt implements missing functionality and is something that would be needed anyway if we want to use Android HW backed keystore to assist with LUKS password/passkey generation. Nothing duplicating here.
Now, ideally I should have systemd-ask-password daemon implemented in yamui or something else (OSK comes in here as an alternative) to provide UI for user interaction in the unlocking process. Here, Jollaâs solution is closed source and cannot be even checked/expanded, unfortunately. So, have to come up with something different.
If we want to let systemd to unlock the encryption, it can be done by
feeding LUKS pwd key location to systemd through boot argument
removing pwd key after unlocking
At least that is the scheme used for TPM2 password protected secrets. Except you donât even need to rm pwd key as it is done in initrd and before switching root.
For FIDO2 and others not asking for password, systemd can handle it all automatically. So, that would be easier.
As you see, main obstacle for me now is to get UI up where I can get user password.
As I plan to use Android Keystore as one of the mechanisms for LUKS unlocking, I have moved /home mounting further down in the boot sequence by changing /etc/fstab configuration as required for systemd.mount. As a result, also regular Silica UI can be used through hwcomposer. While there are limitations, they are relatively minor when compared to writing UI in something like minui.
@Thaodan - are you able to share systemd update plans? Asking in the context of UI for unlocking.
Alternative is to write systemd-ask-password agent that will fire up UI asking for password. That is not a rocket science either and as we can use systemd working implementations I think it will be similar time in doing this as a dedicated app.
I am inclined to go systemd-ask-password route. That would allow to have flexibility in unlocking volumes and for whatever passwords are needed while booting.
Question is just how to make systemd-ask-password UI streamlined and not confusing for users. Namely, we could have multiple passwords for LUKS volume opening requested at the same time:
password for generation keyfile using keystore. that one has to go
recovery or any other plain-text password
some password to unlock FIDO2 device or similar
As it is all coupled to password checking (read, it takes time), will have figure out how to make it reasonable for users. But that will come in the polishing phaseâŚ
I donât know nothing about encryption, but I wanna say: fingertip or face unlocking are most wunerable and stupid. When user is under arrest, cops can simple touch fingertip sensor to handcuffed guy. Same with face. So password and master delete pass is crucial.
so we tell you why we donât comment on them⌠and people ask anyway⌠sigh