defalt

general recent conversations

Discussion on question by melonfsck: …

Imported from a comment discussion on android.stackexchange.co...

defalt

Nov 18, 2023 11:18

@melonfsck Have you had any luck?

defalt

Nov 11, 2023 17:03

@user589943 If you are interested, you can post your follow-up experiments here.

defalt

Nov 11, 2023 16:55

Do one thing, set a new password and make several clones of that /data partition using dd command and then swap /data with other cloned partitions and see if it still invalidates the password which is literally cloned. We should reduce the scope of what is changing everytime you swap /data.

defalt

Nov 11, 2023 16:55

No. TEE rarely writes new data in RPMB unless it's a new device being set up or after factory reset. Setting a password or re-enrolling a new password just creates a new password handle that is stored on disk which is why it is puzzling me why swapping /data is causing the password to be invalid. What else is changing behind the scene.

defalt

Nov 11, 2023 16:55

RPMB is always used whether or not the encryption is enabled. RPMB is used to store keying material to re-derive the same key for Gatekeeper and Keymaster after every reboot. It also provides replay and rollback protection to the keying material. If the device has strongbox, then weaver is used instead of RPMB. If neither RPMB nor strongbox is present, then only flash storage is used which is not secure.

defalt

Nov 11, 2023 16:55

I need some more information. Does it call the password as valid when you switch to other /data partitions which already have lock screen password configured?

defalt

Nov 11, 2023 16:55

After factory reset, it makes sense that your password becomes incorrect even if you restore data as you are not taking behind the scene communication between TEE and RPMB into account but changing just /data partition should not change anything.

defalt

Nov 11, 2023 16:55

Factory reset is a no go because without a hardware exploit, neither you can write into the RPMB partition without the HMAC key programmed into its UFS controller, nor you can decrease its counter to replay the pre-factory-reset keying material. You can practically take its backup using UFS programmer but that is only useful to read what TEE stores there.

defalt

Nov 11, 2023 16:55

In your edited post, you said you took the backup first and then factory reset was made. Factory reset instructs TEE to write new keying material into the RPMB partition which is used to derive new root key in the Keymaster and new Password Key in the Gatekeeper. Basically, once factory reset has been made, TEE won't reproduce the same root key and password key ever again.

defalt

Nov 11, 2023 16:55

The experiment in your edit is different. Factory reset deletes all keystore keys including the key that validates the password.

The Side Channel

Mostly randomly generated noise. – crypto.stackexchange.com

defalt

Oct 31, 2023 10:52

Hi, do you have any recommendation on seed based DRNGs that take the previous value as feedback to derive new value? I'm trying to find the name of these recommended algos.

Discussion between defalt and Big_Bou…

Imported from a comment discussion on security.stackexchange.c...

defalt

Jul 6, 2023 14:51

Developer guide for OIDC PKCE with facebook: https://developers.facebook.com/docs/facebook-login/guides/advanced/oidc-token/

With Google: https://developers.google.com/identity/protocols/oauth2/native-app

defalt

Jul 6, 2023 14:48

To me the complexity of your authentication flow is almost similar to what OIDC PKCE has but because it is standardized, you won't have to concern about security issues.

defalt

Jul 6, 2023 14:45

@Big_Boulard You can use OIDC Authorization Code Flow if you don't want code challenges and if you only have a web app but you have to use PKCE if you have a mobile app.

defalt

Jul 6, 2023 14:44

So, what problem are you facing with OIDC PKCE?

defalt

Jul 6, 2023 14:44

OIDC PKCE is the most common protocol for your approach. It uses JWT and it has dedicated endpoint just to retrieve the user information using the access token. It will make your authentication flow less noisy than it is right now. JWT is the way to go because signature verification can be done in memory which is good for your APIs.

defalt

Jul 6, 2023 14:44

Why are you sending the User Access Token to fb to verify it? It's JWT right, just use their public to verify it yourself. Your rest of the approach approach is almost similar to OIDC. Why you don't want to use OIDC for this? It's standardized and certified.

Discussion on answer by defalt: Can a…

Imported from a comment discussion on android.stackexchange.co...

defalt

Dec 15, 2022 20:11

RoR is secure but nothing is secure against forged OTA update. This is called insider attack and to combat this, Google has developed android Binary Transparency Logs where OEMs have to publish hashes of their OTA updates, then only the update manager applies OTA updates. This prevents OEMs to deliver targeted forged OTA image to a specific device.

defalt

Dec 15, 2022 20:06

> "Wouldn't this hypothetically make it a lot easier for a state actor that can force googles hand to unlock a phone via forged firmware upgrade, similar to what the FBI wanted from apple?"

Tripple letter agencies don't need Google's help to achieve this. They can just ask OEM's to deliver a forged OTA update that records your PIN or unlocks the device in AFU state on a specific PIN.

defalt

Dec 14, 2022 21:37

The assumption is that the attacker may try to retrieve K_s from Google from its own device by somehow extracting K_k from the victim's device TEE and using it decrypt the receipt. It is fairly easy for an attacker to clone encrypted receipt and double encrypted synthetic password from UFS. So Google enforces time period at its own HSM side to revoke the key.

defalt

Dec 14, 2022 20:42

@Firelord The design is to prevent decryption of synthetic password after the time period. This gives an attacker a limited time frame to seize the device and compromise K_k in TEE. The attacker can wait for the device to retrieve K_s from Google within the time frame but it will make it even more harder for the attacker to extract synthetic password as the decryption happens inside the memory used by TEE.

defalt

Dec 14, 2022 17:46

The reason behind making one key online and another offline is to spread the attack vector. From time to time, spyware agencies have proved themselves to be capable of exploiting specific component of TEE's that eased their work to decrypt the device. For example, they target "Gatekeeper" Trusted App in TEE to bypass the cooldown timer for wrong attempts.

FBE is designed in a way that at least one input must come from outside the device. For example, in BFU state you provide PIN to decrypt FBE keys and in AFU state you use biometric to authorize decryption of cached FBE keys.

Discussion between defalt and DurandA

Imported from a comment discussion on security.stackexchange.c...

defalt

Sep 20, 2022 08:20

So if you have 3 web services Alice, Bob and Charles and if a user is using Bob's web service, whenever the token refresh will happen, Bob's service will share the new ID token with Alice and Charles web services to update themselves. The update event must invalidate the cached ID token they had earlier.

You can use a message broker to share update event.

Now I understand your problem and it seems to be an X-Y question. You are asking how to solve X but actually the problem is Y and you think X is the solution in which you are having a problem to achieve.

defalt

Sep 20, 2022 08:12

By sharing the ID token, the user can just use one service and ID token will be updated for all of them.

defalt

Sep 20, 2022 08:10

@DurandA Web services can share ID Token with each other. It means, if one of the service receives an updated ID Token from the identity provider in an access token refresh response, it can share that token with other services.

defalt

Sep 18, 2022 17:57

@DurandA In that case just keep the access token short lived. Access token refresh will give you updated userinfo. You don't have to poll the identity provider.

defalt

Sep 13, 2022 15:34

Why do you need updated profile data immediately? Usually, user doesn't change its profile information that often.

defalt

Sep 13, 2022 15:31

@DurandA The resource server will have temporary access when the user will send them in cookies.

defalt

Sep 13, 2022 15:29

Yes. Keep polling with access token. Once access token expires, refresh the access token and start polling again. This is why you shouldn't poll it. Web service should not store tokens. You should only start polling when the user is online.

defalt

Sep 13, 2022 15:29

You can poll /userinfo endpoint using access token. Though it's not recommended to do so. User profile data should be periodically updated, not frequently.

defalt

Sep 13, 2022 15:29

How soon do you want updated profile data when it is updated?

Android Enthusiasts

Welcome to the main chat room for android.stackexchange.com! H...

defalt

Sep 13, 2022 08:48

@AndrewT. The comment there answers it precisely.

defalt

Jul 16, 2022 16:07

https://twitter.com/arter97/status/1538687131446431745?s=20&t=NNqdTly1fUaVAGX6IskeYA

Has anyone experienced this? @alecxs

Discussion on question by David: How …

Imported from a comment discussion on android.stackexchange.co...

defalt

Jul 28, 2022 20:48

Let's discuss this in chat.

defalt

Jul 28, 2022 20:48

Production date doesn't decide what android version you will have. Manufacturing starts early. It must be brand new, this is why it is not updated. It's not possible for the seller to downgrade version either. Android devices have rollback protection.

defalt

Jul 28, 2022 20:48

Just check the android version and security patch date. Factory reset doesn't rollback updates. If it's a factory purchase, you will find its update is few months behind the latest one. There's no way to rollback version in locked bootloader.

Discussion between defalt and MR.-c

Imported from a comment discussion on security.stackexchange.c...

defalt

Jun 10, 2022 21:04

No, keep it. Someone like you may search for it and by that time it will be already answered.

defalt

Jun 10, 2022 21:02

Yes, it's better if you introduce OpenID Connect instead of custom implementation.

defalt

Jun 10, 2022 20:59

This is Oauth2 specification.

defalt

Jun 10, 2022 20:59

The optimal way is to keep the public key in memory and validate the token by its signature.

defalt

Jun 10, 2022 20:58

Then you are losing the benefit of having a signature. Signature verification can be done in memory without database lookup. If you are looking into the database anyway, then you simply validate it without verifying the signature.

defalt

Jun 10, 2022 20:54

In your case, expired tokens are also deleted at the same time so invalidate the token until it's deleted.

defalt

Jun 10, 2022 20:54

So that means a compromised token can be reused by the attacker even if the user has logged out and because your expiry time is end of the day, the attacker can reuse the compromised token until the day is over. So you should invalidate it until it's expired and then delete it.

defalt

Jun 10, 2022 20:48

@MR.-c How do you validate them? Signature verification?

defalt

Jun 10, 2022 20:47

It should be invalidated until it's expired. Once the expiry date is crossed, you can delete it from the server.

defalt

Jun 10, 2022 20:47

You are supposed to revoke the token.

defalt

Jun 10, 2022 20:47

This is basically how OIDC works. The server sends the end session request to the Identity Provider that revokes the access token in cookies and the user is logged out.

Discussion between defalt and A. Hersean

Imported from a comment discussion on security.stackexchange.c...

defalt

Nov 10, 2021 05:24

Cool, I will ask twitter.com/raelizecom to pull this off on Qualcomm Snapdragon TEE.

defalt

Nov 10, 2021 04:48

@A.Hersean "The delay to limit guessing only applies to someone trying every possibility using the graphical interface, maybe with a robot typing on the screen. For someone who opened the phone and copied its (mostly encrypted) data by accessing it directly, no such limitation applies."

Are you talking about cloning TEE data as well or just UFS/eMMc storage?

defalt

Nov 10, 2021 04:44

This is why spyware agencies are struggling to decrypt android & iOS devices when they are powered off. The only attack vector that works on powered off devices is to exploit TEE in a way that it can bypass cooldown timer for incorrect attempts. Grayshift was manage to pull this attack on iPhone.