SixToken is a Sixscape product for mobile devices (currently Android and iOS) to support Strong Client Authentication [provide link to article on SCA]. It turns your phone into an “authentication token” for use with online services (e.g. web-based accounting) or workstation login (Windows or MacOS). 

To use SixToken, you must have an Identity Registration Protocol IRP [include link to IRP writeup] account on some server that you have access to. The authentication to this account can be via username/password or SCA (via client certificate). 

At setup time, SixToken allows you to easily and securely obtain cryptographic key material (X.509 Client digital certificate and private key) using our IRP. It also creates an account for Firebase Push Notification at Google, which will be used during SCA. 

When doing SCA, the user will connect to the Server application or workstation login handler as usual, providing just a username (no password). The Server application (which has a copy of the user’s certificate, including their public key), will use that user’s public key to create a crypto challenge. This is a short random string of characters, encrypted with the user’s public key. This challenge is sent to the user’s phone via push notification. It is not necessary for this transmission to be encrypted. The phone will allow the user to unlock their private key, using biometric (if the phone provides this, else a PIN). The unlocked private key is used to decrypt the challenge, with the result be returned to the server application via HTTP (again, no encryption is required, but can be used if desired). If the server receives the same random string that it encrypted to create the Crypto Challenge, that is considered proof of user’s identity (only they should have the private key necessary to answer the Challenge). 

Upon confirmation of the user’s identity, access is granted to the online service or workstation. 

This process uses real 2FA (Two Factor Authentication). This requires use of two different categories of identifiers, from three possible categories: 

  • Something you know, like a password or PIN 
  • Something you have, like your phone or key material 
  • Something you are, like your fingerprint or iris scan 

In this case, the two factors are 1) something you have: your phone and key material, and 2) something you are: your fingerprint or iris scan. If the phone has no biometric reader, it can fall back to something you knowa PIN. None of these authentication factors ever leave the phone. They are used to unlock the private key, which is used to decrypt the challenge. The private key is protected in the phone’s key store (or key-chain).  

No password is used or sent to the server, nor I there a need for a username/password database on the server. There is no need for the user to create or manage passwords. 

To the user, they initiate the connection, a message pops up on their phone requesting their approval, they swipe their fingerprint, and they are “in”.  

This is much more secure than phone-based login using push notification without the embedded crypto challenge. This crypto challenge has been used very successfully for many years as part of TLS. In theory you could use a client certificate on your client computer to do SCA to the application (without using your phone). There are two problems with this: 1) browsers are very poor at managing and using client certificates, and 2) there is typically no biometric reader on your computer. 

We use push notification instead of SMS, since SMS is easy to hack. We don’t use OTP tokens since those also have been hacked (e.g. the RSA Data Security OTP token). 

Some infrastructure must be setup and managed for this to work, including an IRP server and a source of push notification services (in this case Google Firebase). We can automate the setup of this infrastructure to a large degree. 

If someone steals your phone, they cannot unlock your private key without your fingerprint. If you lose your phone, or the key material is erased for some reason, it is trivial to securely obtain new key material via IRP and you are back in business in seconds. This scheme does not do encryption, so there is no need to escrow the private keys. 

The private key is protected fairly well in the phone’s key store or key-chain, but we are working on ways to provide hardware protected storage inside the phone, e.g. a secure SIM, or Bluetooth/NFC PKI smart-card, for very high security applications.