Rogue employees protection

L8437

E24 I'm not using stock,I'm using graphene os. But I'm curious as I always seemed to think that the Google pixel standard once using the titan chip, stopped anyone from gaining access without a pin.

E24

L8437 I think they would have to have your physical device to be able to do anything with the pin. I'm sure there is some way but I just haven't looked into it

Relaks

[deleted] I'm sorry, I misunderstood.

Titan_M2

https://android-developers.googleblog.com/2018/05/insider-attack-resistance.html

de0u

Titan_M2 https://android-developers.googleblog.com/2018/05/insider-attack-resistance.html

Good link!

I feel as I may be missing something, though. Somebody with Google's signing key could build and sign a custom OTA image, including custom firmware for the secure element, no? If it were willing to dump its contents then one would be depending on passphrase length alone, true/false?

Maybe the 2 series didn't have OTA image updates?

L8437

Titan_M2 cheers for this I'll have a read

[deleted]

Maybe this is what you're talking about?: https://security.googleblog.com/2023/08/pixel-binary-transparency-verifiable.html

L8437

[deleted] thanks I'll have a look

Titan_M2

de0u Somebody with Google's signing key could build and sign a custom OTA image, including custom firmware for the secure element, no?

That will require knowing the passcode or wipe data.

de0u

Titan_M2 That will require knowing the passcode or wipe data.

I don't think rebooting the device into Recovery requires a passcode or wiping the user partition.
I also don't think that "adb sideload" requires a passcode or wiping the user partition.

I do think that sideloading will reject an OTA image which wasn't signed by the same signing key as the OS that is installed, but I think for the purposes of this discussion about hypothetical rogue Google employees we are assuming that the attacker has a custom OTA image which is signed by Google, which will "upgrade" the secure element's firmware to dump out its secrets for the attacker.

I completely get that I may be overlooking something. For example, I haven't sideloaded an OTA image in more than a year. Does it require a passcode?

L8437

de0u these are all interesting points I'm interested to learn about this

Titan_M2

de0u I think recovery sideload does not require passcode, and I think Google is referring to just the secure element firmware having that protection, non the rest of the OS.

[deleted]

L8437 I deleted my post but it got restored somehow...

de0u

Titan_M2 I think recovery sideload does not require passcode, and I think Google is referring to just the secure element firmware having that protection, non the rest of the OS.

Having what protection?

I think around a year ago there was a Titan firmware upgrade that went out via OTA. I think the OS can update the secure element's firmware. Or do I have that wrong?

Titan_M2

de0u Having what protection?

Insider attack resistance, that’s how I read the article.

GrapheneOS

de0u Secure element updates aren't rare. Most quarterly and yearly release has an update since it has functionality slowly added to the keystore, etc. In rare cases, there are important security patches for it. There are a lot of minor security hardening improvements over time too.

Blastoidea

Doesn’t having the OS able to tinker with the Titan chip’s brain sort of defeat the whole point?

Perhaps I’m missing something.

de0u

Blastoidea Doesn’t having the OS able to tinker with the Titan chip’s brain sort of defeat the whole point?

If secure-element firmware is to be updated, there needs to be some way to deliver the bits! The existing OTA mechanism works, well, over the air, and includes signature checking. It's not clear what other mechanism would be safer but be usable by millions of customers.

I think this is the event I am referring to: https://grapheneos.org/releases#2022091300

But I don't see how to reconcile this process with the article about how the Pixel 2 is resistant to rogue Google employees. Maybe the Pixel 2 didn't have OTA updates?

GrapheneOS

Blastoidea It has separate verified boot with downgrade protection and update signature verification with downgrade protection. The OS is only responsible for uploading the firmware updates. It doesn't in any way defeat the purpose of it. Insider attack protection is provided by not accepting firmware updates even if they have a valid signature and higher version until the Owner user has successfully authenticated, that's all.

Blastoidea

de0u

I’m not smart enough to read and understand all of that, or even pick out what is relevant.

Titan_M2

GrapheneOS So I assume recovery asks for Owner password?

de0u

GrapheneOS It has separate verified boot with downgrade protection and update signature verification with downgrade protection. The OS is only responsible for uploading the firmware updates. It doesn't in any way defeat the purpose of it. Insider attack protection is provided by not accepting firmware updates even if they have a valid signature and higher version until the Owner user has successfully authenticated, that's all.

Thanks for explaining. Hopefully I have this right now?

The secure element decides for itself whether an ostensible upgrade to its firmware is or is not acceptable, by checking that it's signed by Google and isn't a version downgrade.
After a reboot, the secure element won't consider a firmware upgrades from the OS before it has been unlocked.

So the standard sequence is:

The device downloads a new release, sets things up for Recovery to do the A/B swap, and then reboots into Recovery.
Recovery does the same checks as it would for an OTA sideload, e.g., the new OS is signed with the correct key and isn't a version downgrade. If the new OS passes, Recovery does the slot swap, and boots the new OS.
The new OS waits to be unlocked, then offers the secure element new firmware.
The secure element validates the new firmware before installing it.

If that is right, then the insider attack protection that is provided is that Google could prepare a malicious OS update containing malicious secure-element firmware, both with good signatures and version numbers, and that OTA image could be loaded onto the device, but the new secure-element firmware wouldn't be accepted by the secure element without the unlock code.

« Previous Page