Its a track ball.
Awesome, it’s amazing to see how mature this is all already looking
1 Like
Are new devices all flashed from the same image? Then as far as I understand all phones will use the same encryption keys, even if the passphrase is changed later on 
This has been discussed for example here but I did not find any note from Purism (employees) how this problem will be tackled. 
2 Likes
The video shows in second ~20 a case which seems to fit for the L5, at least from the places where the wholes are. Where I could get such a case?
3 Likes
Could you point us to an explanation of how this works? Perhaps we need to research exactly what is happening a bit more in-depth.
EDIT: we even have an issue for that https://source.puri.sm/Librem5/librem5-flash-image/-/issues/2
1 Like
I guess it is the same I wrote about here. The explanation I found is the one here
It’s good to see that issue addressed. I’d also like to see it addressed for the initial setup of a freshly delivered Librem notebook.
1 Like
I executed
gsettings set sm.puri.Chatty experimental-features true
as the new post on Byzantium released says but I do not see any difference in Calls.
Where is the matrix support? Rebooted too. apt-get update and upgraded too. No difference.
Under Chatty-Settings > “Add-account”.
Now you have two options “XMPP” and “Matrix”.
1 Like
Ah, OK thanks, I was looking in a different place. To be accurate it is
Chatty→Menu→Preferences and the Add New Account
1 Like
See what @ChriChri wrote. I am by far not an expert on LUKS.
Two more links might be interesting, though.
First, the cryptsetup wiki explicitly discourages writing containers/images:
From https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions a paragraph in section 1.2:
CLONING/IMAGING: If you clone or image a LUKS container, you make a copy
of the LUKS header and the master key will stay the same! That means
that if you distribute an image to several machines, the same master key
will be used on all of them, regardless of whether you change the
passphrases. Do NOT do this! If you do, a root-user on any of the
machines with a mapped (decrypted) container or a passphrase on that
machine can decrypt all other copies, breaking security. See also Item
6.15.
And in 6.15 it says among other things:
6.15 Can I clone a LUKS container?
You can, but it breaks security, because the cloned container has the same header and hence the same master key. Even if you change the passphrase(s), the master key stays the same. That means whoever has access to one of the clones can decrypt them all, completely bypassing the passphrases.
To make it concrete: This means that if I would find a Librem 5 which is turned off and where the owner has changed their passphrase, then I can take any other Librem 5 that was flashed with the same image (or just download that image itself) to get the master key and will be able to decrypt the phone I found.
As for how to actually do this, see the answers here: https://unix.stackexchange.com/q/119803
So I guess a solution would be to make reencrypting and thus changing the master key part of the flashing process.
(Also, as I understood from other threads, this does not affect the laptops because they are installed “individually” and not flashed from an image - can someone confirm this?)
5 Likes
To emphasize that off-topic again: It would also help a lot to do this during initial setup of Librem notebooks to make sure that a masterkey that might have gotten ‘lost’ during transport is replaced by a new one.
4 Likes
That is a 3d printed TPU case: https://source.puri.sm/Librem5/3D_designs/-/tree/master/Librem5-Case
3 Likes
Thanks. If I pull the STL file from there, is there any more information about how to print this, with which material etc.?
I put that info on my thingiverse: https://www.thingiverse.com/thing:4961260
In a nutshell:
- Rafts: No
- Supports: Yes
- Resolution: .2mm (I bet .3mm would be fine too)
- Infill: %25 (I think you could get away with 12% or so too)
- Filament material: TPU
- Print slowly (My printer did best at 20mm/s with TPU)
2 Likes
Although the above linked issue says that this only applies to phones where the user explicitly flashed the image and did not then proceed to change the master key - and does not apply when the phone is initially shipped by Purism.
To me this is a bad enough problem because the average customer may not be aware of the need to do this even though perhaps most customers will not have cause to reflash their phone.
Maybe the solution is:
- for any image for an encrypted file system that is available for download, Purism should publish the master key - so that users can verify whether their master key matches the public master key (matching means that they have ‘forgotten’ to re-encrypt)
- ideally the encrypted file system image would automatically re-encrypt on first boot, using a new random locally-generated master key, after telling the user what is happening, because I imagine this is going to take a fair amount of time.
1 Like
Do we know this for sure? I thought all phones sent out by purism are also flashed with an image and thus at least those with the same version of PureOS would share the same masterkey
I like the two ideas! Additional thoughts:
I think publishing a hash of the key would be enough to check this, so for example the output of the cryptsetup luksDump command.
But this should come with a warning that the phone needs to be charged first / have full battery. Doing it immediately on first boot might be (i) dangerous if the battery runs out during reencryption[1] and (ii) unwanted if someone else turns the phone on before / while it is on its way to the owner. So maybe reencrpytion should be mandatory when the passphrase is changed the first time, and offered as optional when it is changed again later?
[1] What would actually happen then? Can LUKS cope with a partition or volume where half of it is encrypted with another master key 
1 Like
Depends on what level of certainty you require. It is stated by @dos in the most recent comment on the above-linked Issue. Good enough for me!
It would but why bother? Since any motivated person can extract the actual master key from the flash image for download, isn’t it security through obscurity to publish a hash rather than the actual master key.
Yes. By telling the user and requiring confirmation to continue,
a) you allow the user not to continue if the phone is not in an adequate charge state, and
b) you generate some entropy in order to improve the locally-generated master key.
Depends on whether it is malicious or accidental.
If accidental, it can be partially addressed by educating users to expect to be prompted this way on first boot - and hence they will recognise when it isn’t working as described.
If malicious, you have much bigger problems and this discussion by itself isn’t going to solve all of it e.g. a malicious party could alter the code so that it still prompts to continue on to re-encryption, goes through the motions of re-encrypting but either doesn’t actually re-encrypt or uses a compromised master key. (In that case your only real option is to download the image, and reflash, and hence ignore whatever the shipped state of the device was - but you also want all of the other things that Purism will offer as part of Anti-Interdiction for the Librem 5.)
Anyway, I think we can see that Purism is aware of the problem.
2 Likes
The phones are manually re-encrypted before shipping.
Regarding the publishing of the key, that’s not the solution. If you don’t trust Purism to provide you with a correctly set up phone, then there are a lot more places where mistakes can happen. You’re better off reflashing yourself.
If you’re worrying about interdiction, then the key does not matter anyway. The man in the middle can generate a new one, not matching any published keys, but still insecure (because known to third parties). The solution to that is not helped by publishing the key.
4 Likes
To be fair to @m4lvin, it was my suggestion to publish the master key: in order to solve a specific problem, namely that the customer him or herself flashes the phone, does not realise the need to re-encrypt and/or forgets to do it and/or somehow thinks that it was successfully run but actually the customer managed to stuff it up, and subsequently wants to verify the state of encryption on the phone.
Absolutely it will do nothing about malicious activity. It is only suggested to cover accidents i.e. mistakes by the customer.
2 Likes
This is no stupid question. I also would prefere an official how to for an update procedure! 
@david.hamner