Using Touch ID with the iOS SDK

How does AirWatch implement Touch ID?

AirWatch apps encrypt their sensitive data with an encryption key named the master key. This master key is derived from an intermediate key called the derived key. The derived key is generated from the user pin created within the application or the username/password of the user depending on what authentication type is selected. If all authentication types in the apps are disabled, then a random pin is generated to use for generating the derived key and subsequently the master key. 

If Touch ID is enabled, once the derived key is generated, a copy of this derived key is stored inside an area accessible only if fingerprint authentication is done (kSecAccessControlUserPresence keychain space).

When the application locks and the user authenticates with his/her fingerprint, the SDK will read the derived key stored in the kSecAccessControlUserPresence keychain space and use the retrieved key to decrypt the master key and subsequently the AirWatch app’s stored data.


Apple offers two approaches to invoke Touch ID inside an application

1. Using the LAContext’s evaluatePolicy method call which returns back a YES or a NO for whether the fingerprint scan was successful.

This approach is used if you are only trying to use the Touch ID prompt for UI purposes without encryption. This API gives the developer the ability to specify how you want to handle the alternative or fallback approach on the fingerprint prompt screen.


2. Attempting to save/read from a keychain storage location that has the kSecAccessControlUserPresence property set.

This approach is used if you need to use the user’s fingerprint to encrypt/protect a specific piece of data inside the keychain and utilizes the fingerprint as an escrow service for encryption keys. With this API, the OS will always force the alternative to be the device pin. AirWatch SDK/apps use this approach. 


Container encryption

SSO passcode and Touch ID utilize the same key management approach where a specific user input (Pin, UN/PWD, fingerprint) is used to generate a derived key, and then that derived key is used to encrypt/decrypt the master key which in turn is used to encrypt/decrypt the AW data. The derived key is an ephemeral key that is deleted and recreated over and over again based on the session. I.e. When the app locks, the derived key is deleted, and the master key cannot be decrypted which means the AW data cannot be accessed. In order to unlock the app, the user has to provide their input to regenerate the derived key to unlock the AW data.

If you are using Touch ID, then the SSO pin and device pin become equal in strength. Since AirWatch uses the keychain API for Touch ID (which offers data protection for user input key derivation), the OS forces the device pin as a fallback rather than allowing the developer to handle it.

Have more questions? Submit a request


Article is closed for comments.