
iOS 8 Touch ID Authentication API - chmars
http://www.andreas-kurtz.de/2014/10/ios-8-touch-id-local-authentication-caveats.html
======
gress
There are some tell-take signs that this is a cursory inspection by soemone
who is not familiar with the iOS security environment.

Firstly, the statement that the passcode is only 4-digits. Not knowing that
this can optionally be switched to a far longer string, and that this option
can be mandated by policy in secure environment, is an indication that the
author is making his inference just by looking at the GUI.

Also, whilst it's true that the passcode can be brute forced, this must be
done on-device and so requires a non-trivial rig (which even then will be
encumbered by the work required for each try), or a many-hour manual attack.

The link-bait title is another tell-tale.

~~~
gfodor
A 4-digit passcode cannot be brute forced if the application is dependent upon
an external service. After N bad attempts, lock the user (which I'm sure
dropbox does.)

~~~
potatolicious
The default lockscreen passcode works the same way. After several attempts it
will lock the phone and prevent further access for some time.

Brute forcing a PIN on iOS is not particularly practical in the same way brute
forcing auth via a script isn't practical (so long as the system wasn't
designed by idiots).

~~~
gfodor
Sure, my point is just that a server-side check is immune to attack (assuming
the server is not compromised.) A client-side check is subject to other
exploits allowing the attacker to get around it.

Either way, you're right, it's pretty much a given that brute forcing a
4-digit passcode in iOS is far from easy, regardless of context if the
developer knows what they are doing.

------
pudquick
Interesting article.

I think Apple could remediate this by extending the Local Authentication API
into a get/set keychain-backed method.

You'd do something like [TouchID getLocalAuthFor:"uniqueIdentifier"] and
success would return the secret. The app could store a one-way hashed copy of
the secret to verify the correct value had been received. This would also rely
on using encrypted local storage otherwise this all gets bypassed by USB
access.

This would require extending the keychain on iOS to include items
decryptable/retrievable only with TouchID biometric information.

... And there comes the rub: your fingerprint information is local per device
and not transferred. These keychain items would only be decryptable on the
same device and only as long as you don't replace your recorded fingerprints.

This may be part of why Apple is only doing a yay/nay API at the moment -
because anything more starts verging into people/devs complaining they can't
unlock their secrets when iCloud Keychain or device replacements are in use.

Apple is not currently transferring your TouchID biometrics between devices
and I'm pretty sure this is a business they're intentionally avoiding.

~~~
rucceett
There is a keychain-backed method. Read the end of the article.

------
rucceett
Summary: The Dropbox passcode lock is only a view preventing access to the
app, but does not encrypt anything. Dropbox' use of Touch ID does not improve
on this and it uses a Touch ID API that only provides a yes/no answer.

> Instead, it could actually grant access to cryptographic keys. As, however,
> the keys would still be stored on the device (although in the keychain),
> this is merely a compromise, albeit one which could actually provide added
> value (ACL protected items are not backed up).

That's all Touch ID can do. The data stored in the keychain (with a
kSecAccessControlUserPresence ACL) is encrypted with a key the secure enclave
needs to provide (or it is asked to decrypt an item-specific key). So without
the secure enclave agreeing, which it only does when it finds a matching
fingerprint, you can't get the data. What more can you expect?

------
harshaw
Funny enough I recently implemented touchID for my company (Mustbin).

The local authentication framework APIs only provide a place to store data. In
our case we use touchID as a secure keystore for client side decryption /
encryption keys, certificates, etc. If you don't have a touchID device we fall
back to storing keys encrypted via passcode and also protected by the device
hardware encryption (the data protection API). If someone where to hack the
app to bypass the touchID window you couldn't get at the data since it is
encrypted at rest.

A wierd oddity of the local authentication framework is that if the user
deletes the application the keychain isn't deleted, so if you naively delete
and reinstall the app you get back old keydata :(

~~~
shawn-butler
NSUserDefaults are cleared however when app is uninstalled.

Can add an "UninstalledOrFirstRun" NSUserDefault.

Based on whether it exists at launch, you can clear out previous keychain
entries.

~~~
harshaw
right, I ended up implementing something like that. However, it is
counterintuitive to the IOS model of app sandboxing.

------
gfodor
It seems the key point of the article, obfuscated by discussions about hiding
UIViews and the limits of the Touch ID API, is that the dropbox app does not
encrypt the files of your dropbox account using a shared secret key. I think
everyone already knows this.

------
smackfu
It is kind of interesting that Apple has provided an authentication API via
Touch ID, but no similar authentication API for non-Touch ID. So you have to
roll your own if you want it to work on older devices.

