Ability to prevent encryption to become enabled

Feature Requests
#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.)

1 Like
#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?

#42

Forcing users to enter a passphrase many will have issues with remembering, is a recipe for disaster (i.e. a huge number of frustrated users and support-requests).

Thus IMO that is a no-go.

Forcing security upon users is always a bad idea, especially if for some of them the drawbacks outweigh the benefits: They will eagerly search for workarounds to bypass this security, see this thread for an example.

Backup the partition by adb tool to a PC: Its data is encrypted, the LUKS-headers are not.

  • Do give the users choice!
  • Do not patronise (i.e. disempower) users by forcing a kind of security upon them, which someone else deems adequate!
    Any such decision forced upon people will be inadequate for some.
  • That is bullshit: It is exactly the scheme Jolla has been supporting right from the start and still supports on devices with an initially unencrypted home-volume (Jolla C, Jolla Tablet, Sony Xperias initially flashed with SailfishOS < 3.3.0).
    Note that this discussion thread is only about the ability to not employ home-volume encryption during the initial startup (“startup-wizard”), it is not about reverting this procedure without re-running the startup-wizard (i.e. a “factory reset”).
3 Likes
#43

Exactly. And adding an option increases the testing complexities a lot.

#44

Yes I’m aware. My main motivation for using SFOS is to have a beautiful OS, that I can modify, tinker, SSH into, is a Linux, not to be part of the GAFAM ecosystem, not to have a contract with G++gol, not to have all these fu++ing apps that phone home permanently, is advertising free, is not an attack surface for main stream viruses… When being pressed to install this or that app for the electricity/cellphone/whatever provider, I tell them “sorry, not possible on my phone for technical reasons, it will not work. YOU have to make it work here and now or you lose a customer”. Last but not least this forum, and it’s a very interesting hobby. Since the Browser problem is solved 3 days ago, I’m happy!

4 Likes
#45

Incredible how people seem intent on pinning this on BIG BAD JOLLA, when it’s the exact same shit as on Android and iOS (and Windows and Mac and …). Someone who wants to break into your house will always be able to get in, but that doesn’t make a simple lock useless.

More than half of the devices on that list (C, Tablet and Xperia X) are no longer supported as of 4.6, and honestly haven’t received any real updates with fixes specifically for those models in years. XA2 and Xperia 10 no longer receive any real updates either and will be dropped in two years when Sailfish 6 is ready.

2 Likes
#46

This is nonsense, all supported devices receive the exactly same SailfishOS updates; WRT home-volume encryption specifically as well as the rest of the OS, only the hardware-adaptation layer differs between devices.

Nevertheless, the whole story about “much higher testing efforts” cannot be taken seriously, because not encrypting simply means not to use a whole lot of code (LUKS, in the Startup Wizard etc.), hence there is nothing to test, except for implementing the dialogue to omit home-volume encryption and test it once. Using home-volume encryption or not is surely expected to make no difference, because it is transparent to the rest of the whole system (OS, apps etc.); if something may have ill side effects it is code which employs the encryption (LUKS, in the Startup Wizard etc.), not not using this extra code.
By the way, I never had the impression that Jolla focuses much on testing lately (> 5 years), anyway.

P.S.: The information that SailfishOS 6 will be ready in two years is quite remarkable, just as stating that Jolla will drop support for the Xperia XA2 and Xperia 10 models with this release. Can you name a source for these statements?

1 Like
#47

I never had problems with the encryption in more than 5 yrs using SFOS. It’s ‘transparent’ and the UI/userspace ‘sees’ the home partition as a normal drive. I absolutely can’t understand what happened with this C2 fiasco. Did Jollaboys really test nothing practically? Didn’t they take 10 devices out of 1000 and tried to ‘real live’ setup them? If Jolla would have done so, they would have had the BUG (statistically) on 4-5 devices and could spare out the current mess.

#48
  • nah, im not laying blame on anyone. i am a jolla fanboy and i love+support what they do, especially with their limited resources.
  • i AM, however, making the case that the encryption happens to be useless, and maybe worse than useless since it makes users erroneously feel safe. in my opinion, they should make it opt-in and have a big caveat on it.
  • for whatever reason (maybe it’s because most android devices aren’t rooted or don’t allow bootloader images or whatever, i do not know), it does NOT seem to be the case that android device encryption can be easily broken. im sure some can, but i could not find a step-by-step tutorial to decrypt any of the devices i checked. (again, i could be wrong here, but at least a quick google didn’t turn it up)
  • apparently, many android devices DO offer optional long password encryption like what i am proposing. it might be worth considering for security enthusiasts.
  • so, in your analogy with the house, i would say the pin code is more like the simple lock on the door. the encryption is like another lock attached directly to that lock. if someone is going to bother entering recovery mode and mounting your partitions, they might as well flash the image to bypass the encryption.
  • => i think the casual attacker won’t see a difference between pin alone and pin+encryption, and neither will the dedicated attacker. MAYBE some theoretical script kiddie exists in between the two that will be willing to do recovery mode attacks, but not encryption attacks, but that’s hardly the convincing argument i think it would need to be to make the encryption non-useless
1 Like
#49

lol, not to sound snarky, but…QA is very easy when you’re not the one doing it…and you already know the issue you’re trying to find! :slight_smile:
i mean, i understand where you’re coming from, but it’s hard to overstate how difficult (and expensive) qa+testing can be, especially to someone who doesn’t work in the industry. i doubt that jollyboys-formerly-known-as-jolla has the amount of dedicated tester man-hours that even they think is sufficient.

edit: i’m also not saying that your criticism is invalid, just that underestimating the challenges of qa, and the hindsight bias, may be coloring your position a little

4 Likes
#50

Agreed and the issue/bug itself is also a bit special:

A corner-case, rather rare use case was buggy: the First Boot, that is executed exactly once during the lifetime of the device.
Whatever testing you do, it’s usually on a set-up, running phone going through all the commonly used functions.

It just happened now that a relatively large number of users were “forced” to execute that rarely-used function, so a large number were bitten by the bug (not all of them either!).

Of course the situation was escalated by the fact there was/is no way to recover “in the field”.

Imagine the same situation, but with the possibility to reset to factory state. People would have just tried again, succeeded and no-one would have given it a second thought.

1 Like
#51

About androids, it’s worse than iOS:

Cellebrite could not brute-force the Google Pixel 6, 7, and 8 series when the devices were powered off.

So the titan chip doesn’t stop them when powered on? Sounds like a bypass of shorter pin after first unlock. So looks like google can’t get it right like apple (both with their custom hw (secure enclave/titan) and sw)

3 Likes
Please Help me / forgotten pin code
#52

I’m curious now, what do you think where I’m coming from?

Yes, only needed one time at first time, but what happened was like the Challenger catastrophe. The boosters were also needed only one time at start but did explode.

1 Like
#53

sorry, what i meant by “i know where you’re coming from” was: “your frustration seems reasonable to me”.
there was a big problem that seems like it would have been easily caught if jolla had done even the tiniest amount of QA. i am not saying one way or another whether this is true, i just want to point out that the exact testing steps that would have caught a terrible bug are always obvious in retrospect in any project, and the hindsight bias makes it seem like the dev team was bizarrely negligent and could not have reasonably missed the issue. occasionally, this is even true.

1 Like
#54

OT: Yes I was frustrated, watching this tragedy, but not personally affected. So I’m back again, but in future or next time will do less adventures with updates but more enjoy what I could reach until now and a little hold back ambition.

1 Like
#55

Yes, and how many hardware adaptation bugs on XA2 and Xperia 10 have been fixed since, let’s say, 2020? That was all I was getting at.

Feel free to bookmark the post to check back when the last update released as ‘Sailfish 5’ is out: XA2 and Xperia 10 will be dropped. They run on old, outdated kernels and Sony no longer updates those. Xperia 10 II and 10 III run on the same, slightly newer kernel, so they will also be dropped simultaneously, but in ‘Sailfish 7’. Also quoting myself from two years ago:

#56

Leaving out crucial parts of statements to let your counter-arguments appear to be sound is insincere.
Side note: Mind that this is never a proper way to “win” an argument; even if that works, this scheme cannot make a wrong statement right.
May I also remind you that this discussion thread is about the “Ability to prevent encryption to become enabled”, not flaws of the hardware adaptation layers for specific devices.

Thus it proves (on a psychological level, while I was originally arguing on a technical level) this nonsense to be nonsensical.

For your statement, “XA2 and Xperia 10 no longer receive any real updates either and will be dropped in two years when Sailfish 6 is ready.”, I now understand that you lack technical reasons or specific information.

So I see, that you see yourself as a seer: Well, I cannot and do not want to argue about this kind of insight.

#57

​​​​​​​​​​​​​​​​​​​​