Less than entirely confident stab (someone please correct if I get this wrong):
- Exclave exposes a small set of functions that kernel may call for sensitive operations
- One of those is “update exclave”. The input to this is a blob signed with Apple’s private key.
- Exclave verifies signature, so a compromised kernel and push a malicious update
How the exclave gets Apple’s public key is a little opaque to me. One way would be to have the exclave have its own (per device or per global version) private key, but client side private keys are very high risk.
Alternatively, perhaps some elaborate set of baked-in public keys for Apple and a way to validate a CRL?
I would think the Secure Enclave would handle such things.
That said I’m not sure what you or GP mean by “update exclave”. It’s just part of the kernel binary loaded up at system start. Wouldn’t it be updated the same way the rest of the kernel is, probably requiring a restart?
No, because that way a rogue kernel could overwrite the exclave itself and the next reboot would be insecure. You can’t trust a low-trust environment to update a high-trust environment.
- Exclave exposes a small set of functions that kernel may call for sensitive operations - One of those is “update exclave”. The input to this is a blob signed with Apple’s private key. - Exclave verifies signature, so a compromised kernel and push a malicious update
How the exclave gets Apple’s public key is a little opaque to me. One way would be to have the exclave have its own (per device or per global version) private key, but client side private keys are very high risk.
Alternatively, perhaps some elaborate set of baked-in public keys for Apple and a way to validate a CRL?