Private Compute Services attestation broken

[androidacy-user]

Looks like Google changed something yet again as it's broken again on 1.2.0-RC2, logs following

file_6100446615935514169.txt

[aviraxp]

Pcs apk

[0ctobot]

Pcs apk

Private Compute Services 1.0.release.667904832

Extracted from komodo.

[aviraxp]

does your keybox have a functional rsa key?

[androidacy-user]

does your keybox have a functional rsa key?

After switching to one that did, the error from TS went away, but there's some interesting keystore logs and PCS protected downloads are still failing.

Here's a full log:

2024-10-11-19-07-27.am.txt

[aviraxp]

0-11 19:06:39.012 I/NetworkUsageLogDatabase(17536): Inserting new NetworkUsageEntity of type ATTESTATION_REQUEST
10-11 19:06:39.017 I/RemoteProvisionSysSvc( 1577): getRegistration(android.hardware.security.keymint.IRemotelyProvisionedComponent/default)
10-11 19:06:39.021 I/RegistrationProxy( 1577): onServiceConnected: com.android.rkpdapp.service.RemoteProvisioningService
10-11 19:06:39.025 I/RegistrationProxy( 1577): IGetRegistrationCallback.onSuccess
10-11 19:06:39.028 I/RemoteProvisionSysSvc( 1577): Fetching key 10163 for client 189926998
10-11 19:06:39.028 I/RegistrationProxy( 1577): getKeyAsync operation started with callback 248676055
10-11 19:06:39.031 I/RemoteProvisionSysSvc( 1577): Successfully fetched key for client 189926998

I think they are beginning to use rkp.

[androidacy-user]

0-11 19:06:39.012 I/NetworkUsageLogDatabase(17536): Inserting new NetworkUsageEntity of type ATTESTATION_REQUEST
10-11 19:06:39.017 I/RemoteProvisionSysSvc( 1577): getRegistration(android.hardware.security.keymint.IRemotelyProvisionedComponent/default)
10-11 19:06:39.021 I/RegistrationProxy( 1577): onServiceConnected: com.android.rkpdapp.service.RemoteProvisioningService
10-11 19:06:39.025 I/RegistrationProxy( 1577): IGetRegistrationCallback.onSuccess
10-11 19:06:39.028 I/RemoteProvisionSysSvc( 1577): Fetching key 10163 for client 189926998
10-11 19:06:39.028 I/RegistrationProxy( 1577): getKeyAsync operation started with callback 248676055
10-11 19:06:39.031 I/RemoteProvisionSysSvc( 1577): Successfully fetched key for client 189926998

I think they are beginning to use rkp.

I did notice that, and that's part of the reason I shared detailed logs here. It's probably hackable some way or another, and if we don't figure it out now, we're screwed when - not if - they widely start using it

[aviraxp]

I don't think there is much we can do if they force rkp. But as for the case for now, I think they are verifying if private key is actually issued for Pixel devices (not for other oems) on server side.

Can you block internet access of com.google.android.rkpdapp and try if it works? I am not sure it it will correctly fallback to keys in devices.

[0ctobot]

I don't believe that we're dealing with true RKP here.

It seems to me like the issue is that v2 keys are being enforced

pub fn find_auth_token_entry<P: Fn(&AuthTokenEntry) -> bool>(
        &self,
        p: P,
    ) -> Option<AuthTokenEntry> {
        let reader = self.auth_tokens.read().unwrap();
        let mut matches: Vec<_> = reader.iter().filter(|x| p(&x.0)).collect();
        matches.sort_by_key(|x| x.0.time_received);
        matches.last().map(|x| x.0.clone())
    }

let (hat, last_off_body) =
                    Self::find_auth_token(|hat: &AuthTokenEntry| match user_auth_type {
                        Some(auth_type) => hat.satisfies(&user_secure_ids, auth_type),
                        None => false, // not reachable due to earlier check
                    })
                    .ok_or(Error::Km(Ec::KEY_USER_NOT_AUTHENTICATED))
                    .context(ks_err!("No suitable auth token found."))?;
                let now = BootTime::now();
                let token_age = now
                    .checked_sub(&hat.time_received())
                    .ok_or_else(Error::sys)
                    .context(ks_err!(
                        "Overflow while computing Auth token validity. \
                    Validity cannot be established."
                    ))?;

We can see here that v2 keys are being generated by keymint, saved to keystore, and validated against boot time metrics.

There used to be a flag for turning off v2 keys: fix_unlocked_device_required_keys_v2, but it appears this doesn't exist anymore.

What you're seeing in NetworkUsageLogDatabase is the attestation itself, but this problematic authentication process is managed offline (I believe) by Private Compute Compliance using HAT and TS.

The good news is that this isn't RKP, the bad news is that I don't think it makes this issue any easier to circumvent.

[androidacy-user]

@0ctobot the attestation request has always existed even when we were able to bypass v1. It's logged under Settings -> Security & Privacy -> More -> Android System Intelligence (not the request itself, just a record it happened).

V2 looks trickier to bypass but still doable - just more to spoof I think.

[0ctobot]

@0ctobot the attestation request has always existed even when we were able to bypass v1. It's logged under Settings -> Security & Privacy -> More -> Android System Intelligence (not the request itself, just a record it happened).

V2 looks trickier to bypass but still doable - just more to spoof I think.

I agree with you, the attestation request is not problematic here.

The true hurdle is sidestepping v2 key authentication. I can't pretend to know how you would go about that, even in theory, but anything short of RKP is still good news.

[aviraxp]

What you said doesn't make any sense. The system/security/keystore2/src/enforcements.rs:585: No suitable auth token found. log is the result, not reason.

1. You disallow rkp app to connect internet so rkp attestation key cannot be fetched. Timeout is triggered: https://github.com/LineageOS/android_system_security/blob/12112e1d80e6c4b31bf1aac46fa5fab940706884/keystore2/src/remote_provisioning.rs#L139.

2. Key timeout triggers auth timeout, and https://github.com/LineageOS/android_system_security/blame/12112e1d80e6c4b31bf1aac46fa5fab940706884/keystore2/src/enforcements.rs#L492 is set, which triggers the logic at https://github.com/LineageOS/android_system_security/blame/12112e1d80e6c4b31bf1aac46fa5fab940706884/keystore2/src/enforcements.rs#L609.

3. Because the device has remote_provisioning.strongbox.rkp_only set (I think?), it is disallowed to fallback to use local strongbox key (likely the hardware doesn't have embed a key), so it just falls back to TRUSTED_ENVIRONMENT as seen in logs.

Also there is no such thing as v2 key. The flag is named fix_unlocked_device_required_keys, v2 is just a renewed resolution. Also, this flag is only for setUnlockedDeviceRequired api (https://developer.android.com/reference/android/security/keystore/KeyProtection.Builder#setUnlockedDeviceRequired(boolean) ), and doesn't have anything to do with the issue here.

I checked PCS attestation code and seems nothing changed. I can only think of they changed the attestation logic at server (such as a more tightened rkp one).

[androidacy-user]

there's no such thing as not embedding keys. Even RKP uses them

Besides, PI and basically every other attestation currently uses non RKP attestations, and until recently, PCS didn't either. Those logs only started showing up a couple weeks ago or so for myself.

[aviraxp]

there's no such thing as not embedding keys. Even RKP uses them

Besides, PI and basically every other attestation currently uses non RKP attestations, and until recently, PCS didn't either. Those logs only started showing up a couple weeks ago or so for myself.

Those logs doesn't show for you. Those logs he posted only shows up after blocking rkp app internet access.

[0ctobot]

What you said doesn't make any sense. The system/security/keystore2/src/enforcements.rs:585: No suitable auth token found. log is the result, not reason.

1. You disallow rkp app to connect internet so rkp attestation key cannot be fetched. Timeout is triggered: https://github.com/LineageOS/android_system_security/blob/12112e1d80e6c4b31bf1aac46fa5fab940706884/keystore2/src/remote_provisioning.rs#L139.
2. Key timeout triggers auth timeout, and https://github.com/LineageOS/android_system_security/blame/12112e1d80e6c4b31bf1aac46fa5fab940706884/keystore2/src/enforcements.rs#L492 is set, which triggers the logic at https://github.com/LineageOS/android_system_security/blame/12112e1d80e6c4b31bf1aac46fa5fab940706884/keystore2/src/enforcements.rs#L609.
3. Because the device has remote_provisioning.strongbox.rkp_only set (I think?), it is disallowed to fallback to use local strongbox key (likely the hardware doesn't have embed a key), so it just falls back to TRUSTED_ENVIRONMENT as seen in logs.

Also there is no such thing as v2 key. The flag is named fix_unlocked_device_required_keys, v2 is just a renewed resolution. Also, this flag is only for setUnlockedDeviceRequired api (https://developer.android.com/reference/android/security/keystore/KeyProtection.Builder#setUnlockedDeviceRequired(boolean) ), and doesn't have anything to do with the issue here.

I checked PCS attestation code and seems nothing changed. I can only think of they changed the attestation logic at server (such as a more tightened rkp one).

Thanks for the information, truthfully this is not my area of expertise, so it's entirely possible that I'm wrong. I've just been trying to do some research on the matter, and speak with people have more specialized knowledge than I do and frankly, I've been getting wildly conflicting information from everyone I've spoken. Some insisting it's not RKP, some insisting that it is. My previous post was just a summary of what I thought I had found out, but I'm not surprised to find out that it's wrong.

The device has to have an embedded key though, because standard on-device authentication is still being used for everything but enabling these handful of AI features. TrickyStore is still capable of fooling everything else, Strong Integrity is still attainable.

[androidacy-user]

there's no such thing as not embedding keys. Even RKP uses them

Besides, PI and basically every other attestation currently uses non RKP attestations, and until recently, PCS didn't either. Those logs only started showing up a couple weeks ago or so for myself.

Those logs doesn't show for you. Those logs he posted only shows up after blocking rkp app internet access.

The logs relevant to RKP successfully fetching the key is what I was referring to