Letâ€™s move on now the jury is out and the verdict is known. The how in this whole exercise is more important because it brings us to the question of usability over security.
So we tackled the Identify part of the Identify, Authenticate & Authorize process in IAM.
So letâ€™s move to the Authenticate part.
Reading the Gartner Magic Quadrant for User Authentication 2012 Report Gartner predicts that, by 2017, more than 50% of enterprises will choose cloud-based services as the delivery option for new or refreshed user authentication implementations, up from less than 10% today.”
To fulfill the promise of cloud computingÂ as stated by Gartner we need a new element in authentication. Apple has taken the lead in choosing usability over security and stated:
Touch ID does not store any images of your fingerprint. It stores only a mathematical representation of your fingerprint. iPhone 5s introduce the Secure Enclave within the A7 chip. The Secure Enclave is walled off from the rest of A7 or iOS. Therefore, your fingerprint data is never accessed or moved, only Touch ID uses it and it can’tÂ be used to match against other fingerprint databases.
So we need a â€˜Secure Enclave in the Cloudâ€™, letâ€™s call it an â€˜Authenticationâ€™ Service. Nowadays to encrypt a biometric feature in a mathematical representationÂ we use modern algorithms to produce a â€˜templateâ€™. Ofcourse it is not possible to reverse-engineer the template to your original biometric feature. The challenge is to define a process how to access the â€˜Secure Enclave in the Cloudâ€™ or â€˜Authenticationâ€™ service. Letâ€™s go back to our â€˜Identify, Authenticate & Authorizeâ€™ model. So instead of walling off our â€˜Secure Enclave in the Cloudâ€™ we will choose a secure way to communicate between the identifier (sensor or device), the authorizer (the gate or portal to request access for a service or application) and the authenticator (identity verifier). Letâ€™s choose for AES to secure the communication between the identifier, authenticator and authorizer.
AES (the Advanced Encryption Standard) is a fundamental building block used for encryption in the modern world. It takes a key and some data (plaintext) as input and transforms that data into something that looks entirely random (ciphertext). The only way to get meaning out of the ciphertext is to use AES and the same key to transform it back into the plaintext. A key is just a number, and AES can work with keys of three different sizes, 128 bits, 192 bits, and 256 bits. Is this secure enough ? Even with a supercomputer, it would take 1 billion billion years to crack the 128-bit AES key using brute force attack. This is more than the age of the universe (13.75 billion years). AES will do.
A simplified process we think fit a sensible way to access the â€˜Secure Enclave in the Cloudâ€™ (where all the templates are securely stored) is the following:
– the identifier (a sensor or device with a sensor) must be known to the authenticator
– you request access at the authorizer (a portal) with your application or browser
– the authorizer (portal) sends a request to the authenticator to request an action from the known identifier (sensor or device)
– acting upon request of the authenticator the identifier is asked to perform an action from the person and sends an encrypted image (fingerprint) back to authenticator for verification
– matching or verification takes place at the â€˜Secure Enclave in the Cloudâ€™ and the authenticator sends an ID back or a â€˜no matchâ€™.
– the authorizer translates the ID to a personal identifier and provide access or not to the services or applications.
Letâ€™s start the discussion of a â€˜Secure Enclave in the Cloudâ€™ and what do you think about the process. Please view our youtube movie (http://www.youtube.com/watch?v=XAICqeCSvBw).