this post was submitted on 06 Jul 2024
483 points (94.5% liked)

Privacy

31859 readers
389 users here now

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

Related communities

Chat rooms

much thanks to @gary_host_laptop for the logo design :)

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 19 points 4 months ago (2 children)

Intrinsically/semantically no but the expectation is that the texts are encrypted at rest and the keys are password and/or tpm+biometric protected. That's just how this works at this point. Also that's the government standard for literally everything from handheld devices to satellites (yes, actually).

At this point one of the most likely threat vectors is someone just taking your shit. Things like border crossings, rubber stamped search warrants, cops raid your house because your roommate pissed them off, protests, needing to go home from work near a protest, on and on.

[–] [email protected] 12 points 4 months ago* (last edited 4 months ago) (2 children)

If your device is turned on and you are logged in, your data is no longer at rest.

Signal data will be encrypted if your disk is also encrypted.

If your device's storage is not encrypted, and you don't have any type of verified boot process, then thats on you, not Signal.

[–] [email protected] 7 points 4 months ago* (last edited 4 months ago) (1 children)

That's not how this works.

If the stored data from signal is encrypted and the keys are not protected than that is the security risk that can be mitigated using common tools that every operating system provides.

You're defending signal from a point of ignorance. This is a textbook risk just waiting for a series of latent failures to allow leaks or access to your "private" messages.

There are many ways attackers can dump files without actually having privileged access to write to or read from memory. However, that's a moot point as neither you nor I are capable of enumerating all potential attack vectors and risks. So instead of waiting for a known failure to happen because you are personally "confident" in your level of technological omnipotence, we should instead not be so blatantly arrogant and fill the hole waiting to be used.


Also this is a common problem with framework provided solutions:

https://www.electronjs.org/docs/latest/api/safe-storage

This is such a common problem that it has been abstracted into apis for most major desktop frameworks. And every major operating system provides a key ring like service for this purpose.

Because this is a common hole in your security model.

[–] [email protected] -3 points 4 months ago* (last edited 4 months ago) (1 children)

Having Signal fill in gaps for what the OS should be protecting is just going to stretch Signal more than it already does. I would agree that if Signal can properly support that kind of protection on EVERY OS that its built for, go for it. But this should be an OS level protection that can be offered to Signal as an app, not the other way around.

[–] [email protected] 2 points 4 months ago (1 children)

Having Signal fill in gaps for what the OS should be protecting is just going to stretch Signal more than it already does. I would agree that if Signal can properly support that kind of protection on EVERY OS that its built for, go for it. But this should be an OS level protection that can be offered to Signal as an app, not the other way around.

Damn reading literacy has gone downhill these days.

Please reread my post.

But this should be an OS level protection that can be offered to Signal as an app, not the other way around.

  1. OSs provide keyring features already
  2. The framework signal uses (electron) has a built in API for this EXACT NEED

Cmon, you can do better than this, this is just embarrassing.

[–] [email protected] 1 points 4 months ago

Why exactly am I re-reading your post? Im in complete agreement with you? Should I not be?

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago) (1 children)

Signal data will be encrypted if your disk is also encrypted.

True.

and you don't have any type of verified boot process

How motherboard refusing to boot from another drive would protect anything?

[–] [email protected] 1 points 4 months ago (1 children)

Its more about protecting your boot process from malware.

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago) (1 children)

Well, yes. By refusing to boot. It can't prevent booting if motherboard is replaced.

EDIT: s/do anything/prevent booting/

[–] [email protected] 1 points 4 months ago (1 children)

Thats correct. Thats one of the many perks.

[–] [email protected] 1 points 4 months ago (1 children)

EDIT: s/do anything/prevent booting/

[–] [email protected] 1 points 4 months ago (1 children)

If the hardware signatures don't match, it wont boot without giving a warning. If the TPM/Secure Enclave is replaced/removed/modified, it will not boot without giving a warning.

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago) (1 children)

If the hardware signatures don't match

Compromised hardware will say it is same hardware

If the TPM/Secure Enclave is replaced/removed/modified, it will not boot without giving a warning.

Compromised hardware controls execution of software. Warning is done in software. Conpromised hardware won't let it happen.

[–] [email protected] 1 points 4 months ago (1 children)

Compromised hardware doesn't know the signatures. Math.

[–] [email protected] 1 points 4 months ago (1 children)

Compromised hardware can't create new signatures, but it doesn't matter because it controls execution of software and can skip any checks.

[–] [email protected] 1 points 4 months ago (1 children)

If the hardware is tampered, it will not pass the attestation test, which is an online component. It will fail immediately and you will be alerted. Thats the part of verified boot that makes this so much harder for adversaries. They would have to compromise both systems. The attestation system is going to be heavily guarded.

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago) (1 children)

which is an online component.

So, storing on Signal's server key to decrypt keys. Welcome back to apple-isms and online-only.

It will fail immediately and you will be alerted.

Provided you have some other non-compromised way of communications.

[–] [email protected] 1 points 4 months ago

Yes, verified boot will have out-of-bands alerts for you by design. Without the online component, you will risk not being able to detect tampering.

[–] [email protected] 3 points 4 months ago

TPM isn't all that reliable. You will have people upgrading their pc, or windows update updating their bios, or any number of other reasons reset their tpm keys, and currently nothing will happen. In effect people would see Signal completely break and loose all their data, often seemingly for no reason.

Talking to windows or through it to the TPM also seems sketchy.

In the current state of Windows, the sensible choice is to leave hardware-based encryption to the OS in the form of disk encryption, unfortunate as it is. The great number of people who loose data or have to recover their backup disk encryption key from their Microsoft account tells how easily that system is disturbed (And that Microsoft has the decryption keys for your encrypted date).