We are looking to leverage the SEP for store ECC keys to sign and decrypt. We need a fall back if the users biometrics/touchID fails - the device passcode.
Through testing, if we have set the SecAccessControlCreateWithFlags to:
accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, [SecAccessControlCreateFlags.touchIDCurrentSet, SecAccessControlCreateFlags.privateKeyUsage], &errorRef);When the device falls back to the user entering the passcode (i.e. FaceID or Touch ID fail) - it won't perform operations with SecKeyCreateDecryptedData or SecKeyCreateSignature leveraging the SecKey references. It forces a reauthentication.
But, if we change it to
accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, [SecAccessControlCreateFlags.userPresence, SecAccessControlCreateFlags.privateKeyUsage], &errorRef);during the private ECC key creation process - voila it works.
How, one could say "Hey just use that" but our goal is to leverage the touchIDCurrentSet / biometryCurrentSet so that enrollment changes force the key to be disgarded.
Is the proper solution an "and" of devicePasscode AND touchIDCurrentSet?
