Security from bruteforce

contour0806

circlingdante Seems like a good idea. I wonder it it would work well? Curious to see a response to your question.

circlingdante

contour0806 I've been doing this for a while and it works well. I just wanted to see if the approach is actually valid.

My thinking: If the assumption that an adversary gets physical access when the device is powered off is not valid, the "auto reboot" setting being enabled can help to mitigate this, by giving a limited amount of time to brute force the weaker secondary user profile. Am I correct in assuming that once a secondary user profile session is started, if the adversary got physical access while the device was on a lock screen they would still come up against the weaver token rate-limiting for accessing that secondary user profile?

A bit off topic, but putting all user data in secondary user profiles also seems to make sense in that, as far as I understand, the Owner profile stores sensitive OS information that secondary user profiles do not.

Nuttso

GrapheneOS So then use a random 6 digit PIN and depend on the secure element throttling.

Or use the 7 diceware and enable fingerprint unlock. Put an app like private lock on it that allows you to disable fingerprint but just acceleration. This seems more preferable.

L8437

Nuttso hi so interested in the app from fdroid called "private lock"

It requires device admin permissions to be able to lock

It also only uses sensor permissions.

Does having admin permissions for lock screen pose a risk? Like can it stop your phone from locking etc

Graphite

circlingdante strong password protecting the boot, but only need to enter it upon boot

What happens after 3 days when fingerprint is auto disabled?

contour0806

circlingdante I don't want to spread misinformation, but the last post quoting the GOS page may mean that your approach works as intended since the Owner profile is privileged as in, all other profiles depend upon the Owner being unlocked?

circlingdante

The assumption the whole thing is making is that the adversary needs to have access to the Owner profile before they can attempt to brute force secondary profiles. I make this assumption because that's where I understand the secondary profile information to be stored, but it could be wrong.

treequell

circlingdante

https://grapheneos.org/faq#encryption

Sensitive data is stored in user profiles. User profiles each have their own unique, randomly generated disk encryption key and their own unique key encryption key is used to encrypt it. The owner profile is special and is used to store sensitive system-wide operating system data. This is why the owner profile needs to be logged in after a reboot before other user profiles can be used. The owner profile does not have access to the data in other profiles. Filesystem-based encryption is designed so that files can be deleted without having the keys for their data and file names, which enables the owner profile to delete other profiles without them being active.

circlingdante

I think the question comes down to (which still isn't clear to me): would a brute-forcing adversary need to FIRST have cracked the Owner user profile in order to brute force attack the secondary user profiles, if the device was obtained when turned off? It seems like the answer is yes based on the documentation.

[deleted]

I would say, you are welcome to try it to see if it fits your needs. But it hasn't received any updates in a while, so I am afraid what you see is what you get and that is it.

User2288

To brute force a secondary profile, you don't need access to the first profile.

treequell

User2288 AFU, no. But BFU, you do.

User2288

treequell Are you sure about that?

If the entire data of the device is extracted into external storage, then naturally the data belonging to each profile is gonna be encrypted with its own key. To then decrypt the data of one profile you'd theoretically not need the key for the other profiles. Why is this not the case?

evalda

User2288 To then decrypt the data of one profile you'd theoretically not need the key for the other profiles.

In my understanding (and others please correct me if I am wrong) owner profile need to be unlocked because otherwise Titan M2 won't release the encryption key for other profiles.

User2288

evalda Isn't the point of "brute force" that you don't need the keys?

You are brute forcing the keys.

evalda

User2288 Not exactly. Brute forcing the keys is pointless, it would take too long so it's not a feasible approach. Usually they brute force passwords, PINs that made by humans and often has less entropy. However on Pixel that doesn't work because Titan holds the keys and implements rate limiting so you can't quickly loop through all possible PINs, passwords.

Dangor

To revive this topic, just 3 days ago a “banker”was arrested in greece by greek authorities on the request of the dutch which were present on spot. His pixel phone was opened by the dutch and his threema was decrypted.
If anyone is interested i can post the link, or you can search for details online. So i would say brute force in afu mode def possible.

Nuttso

Dangor link that it was a pixel pls. They may have found a way to bypass the titan m1 on older phones. The murderers of the journalist I'm Netherland also used a pixel and they decrypted it. This would only help with 6 digit Password. An 96+ entropy password can't be decrypted. This is why I say don't rely on tpm

Dangor

Sorry to double post but its a different topic. If anyone from graphene is reading this, why don’t you implement a toogle where if turned on if a usb connection is made on the phone(besides charger) all data will be wiped in the same moment?
An app called wasted is offering this option, but would rather see it as built in service.

Dangor

https://ibb.co/6nnjHc5

Excerpt is from 4 days ago

« Previous Page Next Page »