iOS `SecureEnclaveSecureArea.getKeyInvalidated` always returns `false`, so key invalidation is undetectable on iOS

[mc1100]

Version: 0.99.0; re-checked against main @ 145e9e1a — unchanged.
Setup: a KMP wallet (Android + iOS) using SecureEnclaveSecureArea for credential keys.

What happens

The iOS implementation is a constant:

multipaz/multipaz/src/iosMain/kotlin/org/multipaz/securearea/SecureEnclaveSecureArea.kt

Lines 221 to 223 in 145e9e1

	override suspend fun getKeyInvalidated(alias: String): Boolean {
	return false
	}

override suspend fun getKeyInvalidated(alias: String): Boolean {
    return false
}

The Android implementation does the real thing:

multipaz/multipaz/src/androidMain/kotlin/org/multipaz/securearea/AndroidKeystoreSecureArea.kt

Lines 601 to 608 in 145e9e1

	override suspend fun getKeyInvalidated(alias: String): Boolean {
	try {
	loadKey(alias)
	} catch (_: KeyInvalidatedException) {
	return true
	}
	return false
	}

Why false is not a correct answer for this Secure Area

In #853 the KDoc was clarified as: "Existing keys in a Secure Area may be invalidated and this can happen on Android if e.g. the LSKF is removed … Applications can also use getKeyInvalidated to learn ahead of time if a key is still usable." In that thread a constant false was described as the right implementation for a Secure Area whose keys are never invalidated (the example given was a highly-available cloud HSM).

The iOS Secure Enclave is not such a Secure Area. multipaz itself offers BIOMETRY_CURRENT_SET when creating keys:

multipaz/multipaz/src/iosMain/kotlin/org/multipaz/securearea/SecureEnclaveUserAuthType.kt

Line 15 in 145e9e1

BIOMETRY_CURRENT_SET(1 shl 1),

which maps to kSecAccessControlBiometryCurrentSet. iOS invalidates keys created with that flag when the biometric enrolment changes — a new fingerprint or a re-enrolled face. That is the direct iOS analogue of the LSKF-removal case that motivates the API on Android, and it is reachable through multipaz's own public settings.

Consequence

Every caller that filters on invalidation is silently a no-op on iOS — SecureAreaBoundCredential, Credential, and DocumentModel all consult it. A document whose enclave key has been invalidated stays listed as usable and then fails at signing time, which is the worst moment to discover it: mid-presentation, in front of a verifier, rather than at render time where the wallet could prompt the user to re-issue.

Suggested implementation

Detecting this without a LocalAuthentication prompt is possible: LAContext.evaluatedPolicyDomainState changes when the biometric enrolment changes, and reading it (after canEvaluatePolicy) presents no UI. Storing that value in SecureEnclaveAreaKeyMetadata at key creation and comparing it on query would make getKeyInvalidated accurate for BIOMETRY_CURRENT_SET keys — the metadata record already exists and is versioned CBOR, so there is a natural place to put it. Keys created without that flag can keep returning false, correctly.

A prompt-free implementation matters here: this API is called while rendering a document list, so anything that can raise a biometric prompt per credential is unusable in practice.

What we do meanwhile

We accepted the divergence deliberately rather than probing the enclave per credential, and we still call isInvalidated() on the read path, so a fix upstream lands for us with no code change.