SecItemCopyMatching for Touch ID without passcode fallback - ios

Question

I am using SecItemCopyMatching to fetch a keychain item protected by Touch ID.
However, if Touch ID unlocking fails (or the user selects "Enter Passcode"), I want to present my own PIN-entry UI.
I do not want the user to be presented with the system passcode entry UI at any point.
LAContext's evaluatePolicy method provides this, but does not offer any actual keychain security, merely local authentication.
I therefore will not use LAContext to achieve this. Is this possible with SecItemCopyMatching?

Answer 1

On iOS 8.3 and above, the passcode fallback option is hidden initially but still appears if the first finger presented is not recognised.
For iOS 9, two new policies have been added that do not fallback to passcode. These policies are kSecAccessControlTouchIDAny and kSecAccessControlTouchIDCurrentSet

Answer 2

We had similar dilemma while working on one of our in-production app. We realised that we need touch ID unlock as well as custom fallback mechanism (which requires server API for unlocking) which is stronger than 4 digit unlock password.
So, Let me try to explain how we achieve it.
Similar is expectedly done by Apple for Appstore purchase and 1Password app.
Background:
Two mechanisms to integrate Touch ID:
Use Touch ID to access credentials stored in the keychain
Issue:
If a device has Touch ID as well, the preferred method is to authenticate with Touch ID and passcode is the backup mechanism
No other fallback mechanism is permitted and Apple does not allow customisation of the fallback user interface
Use Touch ID to authenticate with the app directly (called Local Authentication)
Issue:
No permission is granted to store secrets into or retrieve secrets from the Secure Enclave
Contrary to the keychain access case, Apple does not allow device passcode authentication as a backup
Every application needs to provide its own fallback to handle failed Touch ID case with custom UI
Concern:
About storing sensitive information in the keychain:
We were tempted to use this approach but were taken aback by realising the only fallback for failing to authenticate with Touch ID is the device passcode. iOS users usually configure a four digit passcode, which is less secure than users custom passwords.
Facelifting examples:
Apple uses your iCloud account password [custom fallback mechanism] as a fallback mechanism for itunes store purchase if user fails to authenticate with Touch ID.
1Password app also has similar approach.
Conclusion
In our app we authenticate with Touch ID via LocalAuthentication, we use our 'app specific PIN unlock feature' or the client's password as the fallback mechanism.
We don't store the password on the device, failure to authenticate with Touch ID requires full authentication through servers API, if device does not have a PIN configured within app.
Sample code:
[self.laContext evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
localizedReason:reason
reply:^(BOOL success, NSError *error) {
if (success)
dispatch_async(dispatch_get_main_queue(), ^{ successBlock(); });
else
dispatch_async(dispatch_get_main_queue(), ^{ fallbackBlock(error); });
self.laContext = nil;
}
];

Answer 3

This should probably be a comment to bllakjakk, but my reputation does not allow me to do so yet.
I am only adding this answer because the question was specifically asking about:
fetch a keychain item protected by Touch ID
The accepted answer mentions a scenario where no credentials are stored on the device.
For completeness I wanted to mention that if your app needs to authenticate to some external entity, and you therefore have to store credentials somewhere, then the Key-Chain option is the one to consider over Local Authentication.
The fear of somebody being able to authenticate via fallback for Key-Chain if they know the device pass-code (potentially weak four-digit and so on) is a moot point because nothing keeps a user from adding their own fingerprint to the device if they possess the pass-code, and then authenticating via Key-Chain or Local Authentication without having to select the fallback.
So if you are using Local Authentication over Key-Chain because you feel that the fallback mechanism is safer, you might be overlooking that minor detail and therefore be passing up on the opportunity to store credentials in the secure enclave.
We are about to implement TouchID for a financial application and are opting for Key-Chain. The intent is to educate our users about the need for strong device pass-codes at the time when they try to enable TouchID for our app.
I hope this helps you in making a decision.

Answer 4

You can try hiding the Enter Password button by doing the following:
1) define global function
static bool new_isFallbackButtonVisible(id self, SEL _cmd)
{
return NO;
}
2) in your application:didFinishLaunchingWithOptions: replace isFallbackButtonVisible method of LAContext class with your new implementation by calling
class_replaceMethod(NSClassFromString(#"LAContext"), NSSelectorFromString(#"isFallbackButtonVisible"), (IMP)new_isFallbackButtonVisible, "v#:B");

Answer 5

There is no way to disable fallback mechanism using passcode in Keychain TouchID integration. Use LocalAuthentication instead (But LocalAuthentication just provides a TouchID auth UI though not related to the Keychain).

Answer 6

You can hide/customize the "Enter Password" option by setting:
LAContext *context = [[LAContext alloc] init];
context.localizedFallbackTitle = #"";
and the option will disappear, or:
LAContext *context = [[LAContext alloc] init];
context.localizedFallbackTitle = #"Disable TouchID";
to customize the option text. While I know this isn't exactly what the OP was asking, it's most certainly related and could "fallback" into wanting minds.