wait... your encryption key is saved on Google servers? that doesn't sound like the best...

@Michael from linked doc: for scheduling an OTA update with Resume-on-reboot feature two keys are generated. Before generating them user is asked to provide their pin/password which is turned into something called a synthetic password. Then it gets encrypted by those two keys and is then stored in the storage. One of the keys is sent to Google. Other one is stored in device's TEE. On successful update, during reboot, key from Google is obtained, key from TEE is obtained. They are used to decrypt synthetic password and that is used to unlock the device automatically...

...What I'm more interested is why Google is pushing its servers into this whole process. This Resume-on-Reboot feature can be implemented without a key in Google's hands. I don't see any security enhancement in protecting user data by having one key held by Google in this whole process, even if the key held by Google is valid only for one reboot.

@Firelord You need a trusted third party (Google in this instance) to enforce a time limit on the process. There's no tamper-resistant time source on a typical device.

we all know why. one day google can remotely decrypt even on cold start

@TooTea if this process is redesigned than tamper resistant time source is not needed. On every reboot the system can check a property that whether it is in a state of Resume-on-reboot. (The property should immediately be reset on every reboot). If yes, it should check if there is available an encrypted synthetic password file. Than the system can retrieve the key from TEE. If no key is there, than the password file is obsolete. In that case, it should be deleted. If the key is there, it should be used to decrypt the password file which should be used to decrypt user data.

@Firelord The thread model described on the RoR page says that the system needs to be safe against HW modifications in the middle of the RoR process. An attacker could get hold of a running device, trigger an OTA, stop the device in the middle of the reboot (thus with RoR fully armed), modify the hardware to enable reading the RAM (e.g. tap the memory bus), and power it on again to complete the RoR cycle and recover the keys. Or instead of reading RAM, mount any offline attack on TEE memory. The time limit protects against this (hoping the necessary HW mod would take more than a few minutes).

@TooTea in the same threat model the limitation is that attacker won't be able to read the ram content and cannot modify tamper-resistant hardware. If an attacker can read and interpret ram content of a live device than all security is lost to begin with. Same goes for TEE. If an attacker can compromise TEE that easily, than no encrypted user data is ever safe on a stolen phone or in the hands of unauthorized users. So with these two limitations imposed on the attacker, and given the new process I have in my comment why would Google servers still be needed?

@TooTea ...To trigger an OTA with Resume-on-Reboot feature the attacker must get the authentication from the user with their credentials. Let's assume that the user was not careful, was in a hurry, and gave authentication for the OTA trigger. What's next. The OTA would apply. Attacker cannot do anything with that. After that, it is during this reboot my hypothetical solution would work. What can an attacker do in this process to hijack (given the imposed limitations) the decrypted synthetic password?

@Firelord I understood that limitation as reading the RAM of the device in its original state (thus booted up, CE unlocked) without shutting it down first. Without RoR, that's enough to provide all the security you need, as powering the device off to modify the hardware is going to erase keys/RAM contents, and powering it up afterwards wouldn't decrypt the storage without the owner entering their PIN. RoR changes that because it enters the PIN for you. Similarly, just an offline attack on the TEE is normally not enough as you still need the PIN to derive the encryption key.

@Firelord Isn't the whole point of RoR that it allows OTA updates to happen unattended, in the middle of the night, while the owner is sleeping? So you just take their phone by whatever means (perhaps even seize it because you're a government agency) and then feed it an OTA and it will happily enter the RoR sequence without any user cooperation.

@TooTea on the linked page Google requires that user should authorize Resume-on-reboot (cause that authorization helps in creating synthetic password). So if an OTA update is available and user does not give authorization that OTA can still apply but RoR won't work. So a government agency have to coerce the user to enter PIN/Password in the middle of the night before triggering OTA. :D At least that's the impression I get from the linked doc. All I'm trying to understand is if Google's role can be safely eliminated from this whole RoR or not. I think it can be eliminated. It is too intrusive.

And receipt and time period would be valid in scenario 2.

@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.

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.

Okay. This K_s key is more like a time based OTP. // I didn't consider that an attacker can extract K_k from the device. I considered in this whole discussion one strong assumption that TEE cannot be compromised or be taken advantage of by an attacker. If I do consider otherwise, than given your last comment it makes sense to have a third-party provide a time-based key. It just happened to be the case that Google is placing itself in the whole scenario as a trusted third party.

And I appreciate your patience in resolving my confusion. :) Thank you.