Ability to prevent encryption to become enabled

Feature Requests
#22

I’d like to add to the ‘discussion’ that even if you think encryption isn’t important, if you don’t encrypt your data and even if no one is interested in you in particular, a malicious entity could still use your unencrypted data as a stepping stone to someone else who does encrypt their data (or who is actually even at high risk). For example, I could be a complete nobody, but a friend or even just a contact of mine could (unbeknownst to me) be a target of political persecution. The malicious entity can’t access my friend’s data because it’s encrypted, but they can just spy on my unencrypted phone to find out a lot of information about my friend. I would therefore be directly responsible for any damage the malicious entity does to my friend. Do you really want to have the ‘choice’ to expose your friends to those who want to hurt them?

Well, to me that just shows it’s a good lock. I wouldn’t want anyone who stole my phone being able to steal my data (or impersonate me) because there was a backdoor in case I forgot my own password. Is that a downside? Yes, in the same way as it is a downside that you’ll have to walk home from the pub if you lost your bike key, or that you can’t get in your house if you lost the key, or that your money is inaccessible is you forgot the pincode for your bank. Losing important data is a valid concern, so just make backups and you won’t lose data in the (unlikely) case you forget your own password.

Side note: just yesterday I came across a truly bizarre rant-video (with hundreds of thousands of views) on YouTube of someone who bought a permanently locked (i.e. stolen) original Jolla Phone on eBay and was furious that he couldn’t get the data off it with a single click - and that was just pin-locked, not even encrypted. For some reason he seemed to think that Linux being ‘open’ source meant that you wouldn’t need a password. Most of the comments displayed the same lacking-in-brain-cells thinking.

2 Likes
#23

This is a very annoying known bug (one time I was busy rebooting my phone for about half an hour because it kept running into the same bug), but it’s not a bug with the encryption. It’s a bug with the boot process not waiting until a specific service is started, so sometimes the service is ready and the unlocking works, but sometimes the service isn’t ready and the unlocking doesn’t work. You can tell it’s the boot process itself, because on a ‘correct’ boot, it takes some time for the unlock screen to pop up, whereas on a ‘bad’ boot, the unlock screen shows up almost instantly after the Jolla/Sailfish splash screen. Having an encrypted device makes the bug more obvious, but the encryption itself isn’t at fault.

#24

The point is “everybody’s mileage varies”: I never lost a mobile phone (out of > 10) or had one stolen in 30 years, but forgetting passphrases happened many times to me.

Technically spoken, it is a question of risk assessment: Forgetting passphrases is a high risk, losing a phone or get it stolen a very low one, obviously.

Consequently, encryption is evil (for me).

5 Likes
#25

For example, I could be a complete nobody, but a friend or even just a contact of mine could (unbeknownst to me) be a target of political persecution. The malicious entity can’t access my friend’s data because it’s encrypted, but they can just spy on my unencrypted phone to find out a lot of information about my friend. I would therefore be directly responsible for any damage the malicious entity does to my friend.

This is completely unrelated to your own device encryption, if you’re looking for a way to connect with your friends in a way that mobile network providers don’t know about it, look for a ‘platform’ that supports such a feature, nothing mainstream does currently (maybe if all your group re-sign to signal without phone numbers, but in the end ISP data from both ends will be enough to connect the dots, still nothing to do with encryption of /home)
I really dgaf about encryption when everyone uses 5-12 digits, you can break this even as AI hobbyist, no need to hire CIA/FBI, you’d need to type 16+ chars alphanumeric(plus special chars) password every time you unlock your device to have any security from state actors, luks with 5-12 digits is a joke, but whatever makes you feel safe
Edit: oh and then these ‘secure’ platforms send notifications of new IM with content unencrypted to apple/google to send over to you, I think all the popular platforms got their pants down with that, if you want security, throw your mobile phone away

1 Like
#26

May be I am wrong but this is not a key but a pin to key that is much stronger.

#27

There was a howto on dumping the relevant parts through adb and then breaking sfos luks encryption on sfos (though author only used 0000 as proof of concept), if people are using digits only, even 12-16 is doable by an AI enthusiast, you’d need full a-Z with special chars and 12+ to actually secure anything

#28

Once again: please leave the decision to the user!

I have been using PGP and other tools for more then 20 years but I want to decide when and where. I already had some data completely lost due to encryption problems (not with SFOS). But I never lost my phone (yet…) I don’t even have a lock PIN or finger sensor active, I just switch on my phone and it works.

2 Likes
#29

The problem with leaving the encryption decission to the user makes for Jolla much more work.

every phone and every image need to be tested in 2 conditions:

without encryption
and
with encryption

I am pretty sure, Jolla will never go this way.
Encryption of a mobile device is a must in 2024.

its the same, when you ask, that you want to have decission that your credit card doesn’t have a pin.

3 Likes
#30

Seeing as I don’t have a PIN on my credit card, I suppose I can feel free to reject mandatory phone encryption.

Also, Jolla tests their stuff?

2 Likes
#31

can someone correct any or all of the statements below? i think they are right, but i could easily be wrong

  1. this is about device encryption, which is purely about data at rest. things like security online, data snooping, and attacks without physical access are out of scope.
  2. the only possible benefit of encryption is preventing an attacker who has already stolen the physical device from copying the data off the device without the pin code
  3. if someone can unlock the device without the pin code, then there is no benefit to the encryption whatsoever
  4. there is a nice tutorial on how to break SFOS encryption
  5. therefore, encryption on SFOS is just security theatre
3 Likes
#32

True, but the breakability depends on the quality of the lock code.
For convenience, most users will be using a rather short one, possibly numeric only.

This is what makes it easy to break. The technology as such is fine.

Therefore, your point 5 may be true in practice, but is not inherent to the design or tech. Point 3 is true but does not apply, the mentioned attack brute-forces the code.

1 Like
#33

True, and it only applies during the period where the device is freshly booted, until the Code is entered.

While the OS/UI are running, encryption does not really make a difference, and attack vectors become things like malicious apps, or breaking ssh access if that is enabled.
The developer/devel-su password is relatively weak per default (but random which is good), but can be set properly by the user.

#34

All 5 points are true, though one can argue, that if your passphrase provides at least 100 bit (better 120 bit) of entropy (> 30 / 36 digits, or > 16 / 18 ASCII-printable characters without whitespaces) points 4 and 5 are not valid.

3 Likes
#35

so, if my reasoning is valid…the encryption is absolutely useless. (i will politely ignore olf’s suggestion of a ~33 digit pin code). any casual thief will be stopped by a pin code, and any dedicated thief will not be stopped by the encryption.

=> i would say, therefore, that encryption should be disabled by default. at the very least, an opt-out should exist for even non-technical users.

it sounds like the main argument from folks on this thread is “not encrypting a mobile is low social status, and we will ridicule you if you do not encrypt”. this would be a reasonable argument, if encrypting actually did something good.

i would change my mind, of course, if it was hard to break.

1 Like
#36

i have a question- why isn’t there a separate password for unencrypting and unlocking?

  • 128-bit password that you need to enter to boot the phone
  • once booted, unlocking just requires a 5-digit pin and has nothing to do with encryption
  • ten failed attempts shuts down the device, and then you need the long password to boot

flashing another image that allows unlimited pin code attempts would be irrelevant, because you would need to unlock the storage with the long password before booting.

the password could be randomly generated at install. users would of course write down the 13+ character password, but as long as they don’t carry it with their phone, that’s fine. if they lose that password, they lose their data.

of course, the average user wouldn’t want to do this, but SFOS users are not average users. it would be opt-in, but it would be fairly convenient and, as far as i can tell, would actually do something.

1 Like
#37

I think the simple answer is: Deploying your own encryption solution is a bad idea, you either use trusted/tested solutions that have been audited, or you rely on security by obscurity, jolla don’t really have the manpower to deploy a custom solution like yours (if they botch it with couple of scripts and someone’s kid manages to skip it with a weird combination of swipes it’s a huge setback in the ‘security/privacy centered OS’ space they place themselves, why even commit super limited resources for a possible selfown like this, even if there is a way to bruteforce to skip your 10 pin lockout would be a disaster, in your own head I’m sure your solution is super easy to implement, in reality it will leave a ton of possible attack surfaces) and having to type 30+ digit pin on every boot is also a no-no for most users, so it would be working on a feature that maybe 1% of users will be even considering using, if they can get the device encryption right so it works out of the box for 99% users it doesn’t matter that all of them use 5-8 digit pin and it’s only theater, android has it, so it’s a must have, explain to graphene users their pins are useless (actually no, the titan chip promises from google they are free from bruteforce, you’re expecting jolla to develop software only solution when googol supposedly spent tons on HW module, surely this can be just implemented in SW)

2 Likes
#38

i hear you, but:

  • first, well, how could it be worse? jolla’s current solution is fully useless, except in making users feel better about it. the average SFOS user using encryption is already open to all the attacks you just said, and they don’t know it.
  • second…well, yea, it is pretty simple. i wouldn’t call it a custom encryption solution; i’m talking about using LUKS exactly the same way they are doing it now, only with a longer password. pin-unlock already exists without encryption. my only other proposal, which is quite separate and is not a necessary component, is to shutdown the phone on multiple incorrect attempts.

my proposal is literally just:

  1. prompt for a 13+ char password at installation, and use that for encryption at boot (and NOT for screen-unlock)
  2. add a device shutdown after a few pin fails

yea, i agree with that. this is a phone for amateur security+privacy enthusiasts, among others. it would have to be an opt-in.

like you say, android generally has real, reliable at-rest encryption. SFOS pretending that they also do is, in my opinion, misleading to the point of irresponsibility. look at all the users on this thread saying how important it is to use the fake encryption; they might take their device security more seriously if they didn’t rely on the smoke and mirrors.

(edit: jrg, yomark, chwissa, seven.of.nine, nthn…are you aware that SFOS encryption can be broken by an unsophisticated attacker? i haven’t tried it, but the community seems to accept this as a fact.)

#39

Could you try and report back how easy it was? I know it is somewhat easy to get the PIN from the LUKS headers, but how do you get the headers from locked/powered off device without any knowledge of the PIN or developer password?

#40

i dont have a spare device at the moment, and i dont use encryption. maybe someday when i buy a 10 V, i will ask someone else to pick the pin on my 10 III and not tell me it.

#41

I fully agree with @explit, an option to disable encryption would increase SFOS complexities much more. From my point of view the need for security & privacy by default for mobile devices is no discussion at all.

So I still have not read strong technical reasons in this Feature Request, i.e. reasons not based on personal experiences. And if you would like to modify your own SFOS image why not try the script by @teleshoes?