tl;dr – Tidas is now open source. Let us know if your company wants help trying it out.
When Apple quietly released the Secure Enclave Crypto API in iOS 9 (kSecAttrTokenIDSecureEnclave), it allowed developers to liberate their users from the annoyance of strong passwords or OAuth.
That is, if the developers could make do without documentation.
The required attribute was entirely undocumented. The key format was incompatible with OpenSSL. Apple didn’t even say what cipher suite was used (it’s secp256r1). It was totally unusable in its original state. The app-developer community was at a loss.
We filled the gap
We approached this as a reverse-engineering challenge. Ryan Stortz applied his considerable skill and our collective knowledge of the iOS platform to figure out how to use this new API.
Once Ryan finished a working set of tools to harness the Secure Enclave, we took the next step. We released a service based on this feature: Tidas.
When your app is installed on a new device, the Tidas SDK generates a unique encryption key identifying the user and registers it with the Tidas web service. This key is stored on the client device in the Secure Enclave and is protected by Touch ID, requiring the user to use their fingerprint to unlock it. Client sign-in generates a digitally-signed session token that your backend can pass to the Tidas web service to verify the user’s identity. The entire authentication process is handled by our easy-to-use SDK and avoids transmitting users’ sensitive data. They retain their privacy. You minimize your liability.
David Schuetz, at NCC Group, assessed Tidas’s protocol in this tidy write-up. David’s graphic on the right accurately describes the Tidas wire protocol.
Tidas’s authentication protocol, combined with secure key storage in the Secure Enclave, provides strong security assurances and prevents attacks like phishing and replays. It significantly lowers the bar to adopting token-only authentication in a mobile-first development environment.
We saw enormous potential for security by enabling applications to use private keys that are safely stored outside of iOS and away from any potential malware, like easily unlocking your computer with a press of TouchID, stronger password managers, and more trustworthy mobile payments.
We thought the benefits were clear, so we put together a website and released this product to the internet.
Today, Tidas becomes open source.
Since its February release, Tidas has raised a lot of eyebrows. The WSJ wrote an article about it. We spoke with a dozen different banks that wanted Tidas for its device-binding properties and potential reduction to fraud. Meanwhile, we courted mobile app developers directly for trial runs.
Months later, none of this potential has resulted in clients.
Authentication routines are the gateway to your application. The developers we spoke with were unwilling to modify them in the slightest if it risked locking out honest paying customers.
Banks liked the technology, but none would consider purchasing a point solution for a single device (iOS).
So, Tidas becomes open source today. All its code is available at https://github.com/tidas. If you want to try using the Secure Enclave on your own, check out our DIY toolkit: https://github.com/trailofbits/SecureEnclaveCrypto. It resolves all the Apple problems we mentioned above by providing an easy-to-use wrapper around the Secure Enclave API. Integration with your app could not be easier.
If your company is interested in trying it out and wants help, contact us.
“The developers we spoke with were unwilling to modify them in the slightest if it risked locking out honest paying customers.”
I’m not sure I see a correlation between using Tidas and any elevated risk of locking out actual authentic paying users…
Using the Secure Enclave Crypto API for user authentication introduces some uncertainty into the process. What if users lose their phones, how do you re-enroll them? What if users don’t have a TouchID? Will users understand logging in without a password? etc etc. All solvable problems, but it messes with a process that works “well enough” right now, even if storing passwords introduces incredible security risk to your app or company and the user experience of passwords could be better. It was difficult to overcome a potential client’s inertia in the face of these uncertainties, unless the threat to their app was very high. At least, this is the opinion that we discovered among the companies and people we talked to about Tidas.
Given that attributes for kSecAttrTokenIDSecureEnclave are undocumented, wouldn’t usage of this library disqualify any app based on it, given Apple’s policy with respect to private APIs? Did you get feedback of any sort from Apple on this? This looks like a borderline case but better safe than sorry.
It’s a public API, it’s completely legitimate for the App Store. Apple has encouraged developers to use it in presentations at the WWDC.
Sad to hear that! Thanks for sharing! That’s really awesome
Pingback: 2016 Year in Review | Trail of Bits Blog