SecKey: TouchID with fallback to ApplicationPassword

Hi,


mainly for iOS, is it possible to call SecKeyCreateRandomKey with parameters so that using that private key will


- promp the user for touch id

- disallow changing touch id sets

- falls back to application password (NOT device code)

- keep the private key inside the enclave


Basically just like


SecAccessControlCreateWithFlags(kCFAllocatorDefault,

kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,

kSecAccessControlTouchIDCurrentSet | kSecAccessControlPrivateKeyUsage | kSecAccessControlApplicationPassword

, &error);


but not in the way that it first asks for touch and then asks for the password regardless of touch being successful.


Cheers,

Andreas Pardeike

Up vote post of a.p Down vote post of a.p
981 views
Posted by
a.p
Reply
Add a Comment

Replies

Actually,


I can simply cheat by using only

kSecAccessControlPrivateKeyUsage | kSecAccessControlApplicationPassword

for storing the private key and also store the application password touch-id secured in the enclave.

I would then try to retrieve the password thus triggering touch id. The user either successfully uses touch and I use the password to initialize the context and try to use the private key which will succeed. If the user fails to provide touch, using the key will trigger the password dialog.

Did not try to implement this for now but it should work. What I don't like about this is that the password is exposed to application space. 😠

Any alternatives?

/Andreas Pardeike

Posted by
a.p
Up vote reply of a.p Down vote reply of a.p
Add a Comment
I would like to point out that this Issue hasn't had any answer in 3 years. It is still very valid and necessary for us. Could someone review and revive it?

To be clear: I want to have an ACL for a Secure Enclave slot that is not the device pin but a user chosen password (like kSecAccessControlApplicationPassword) and I want to allow for a biometric shortcut in the same way this works with ACLs that use device pin with biometric shortcut and fallback to pin. To my knowledge, this combination is currently not supported in the SE.

The main motivation is security. We need a secret that is less often used and thus has a lower chance of being observed by a bystander. The device pin is often known by family members of our users. If we allow for a custom secret that is only used during business hours, it most likely is not used at home. Having a biometric shortcut will also reduce the risk of observing the secret and has a side effect of being more convenient for the user. Invalidating the biometric shortcut (like after a restart) should be the same as the existing functionality.
Posted by
a.p
Up vote reply of a.p Down vote reply of a.p
Add a Comment

It is still very valid and necessary for us.

Keep in mind that DevForums is an informal support channel. If you don’t get an answer here, you should open a DTS tech support incident to request formal support.

To my knowledge, this combination is currently not supported in the SE.

Honestly, I suspect you’re right, although I’m not 100% sure. Still, I think it’s worthwhile filing an enhancement request describing your requirements. Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment