I think I don't understand one thing about Key Attestation. It seems that it is impossible to change "attestation challenge" (passed as an argument in key generator specification) to something else during subsequent attestations. This means that although I can verify in the beginning that key was created in secure element, I can't verify it later, since if application was compromised attacker can easily send me previously received valid certificate chain, which isn't exactly secret, in response to my inquiry. [NOTE: I mean it is easily provable that if Secure Element is indeed secure and key material never leaves it, certificate chain that is received is always valid. But see rest of my question.]
But let's say that this is safe and I am supposed to live with only one check per key's lifetime. This leads us to another question: there is a field KeyDescription (OID: 1.3.6.1.4.1.11129.2.1.17) in certificate received during attestation that is supposed to contain, among other values, field of type AuthorizationList, which includes field of type RootOfTrust, which includes field VerifiedBootState. I can't check it, but let's say that it always includes current boot state, and not one from when the key was created. How can I trust this value if I can't change attestation challenge?
EDIT: I do realize that I can create new key with different challenge every time I want to verify boot state and subsequently delete it from SE, but it seems pretty inefficient, not very elegant and may be a problem if for some reason there will be policy introduced that limits key creation attempts.
I got it. I was simply misunderstanding things. Reason behind single challenge and inability to change nonce is quite probably this:
When key is created, attestation can be requested. If data attests hardware storage and secure boot reports that devices is in green state (device is not rooted, secure boot performed), then any change will cause keys to be wiped. This means that as long as this key exists, we can be certain ("to a reasonable degree" of course) that nothing has radically changed in device's software (and hardware) and if our software was secure, it still is.
References: