@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.
