Trust Nexus ~ Cryptographic Overview

Cryptographic Overview

The goal of the WebAuthn+ open source project is to implement the highest standards in Real World Crypto, both in the selection of algorithms and in social processes.

The following provides a technical overview of cryptographic processes.

Creating and Distributing the System Level Public Key

In every system that depends on cryptographic processes, one of the most important tasks is the creation, security and distribution of keys.

In the WebAuthn+ open source project there is an initialization class, InitializeB_Keys.java, that creates the system level key pair.

KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(CryptoUtilities.KEY_FACTORY_ALGORITHM);
keyPairGenerator.initialize(CryptoUtilities.PUBLIC_KEY_MODULUS);
KeyPair pair = keyPairGenerator.generateKeyPair();

The "KEY_FACTORY_ALGORITHM" is RSA. The "PUBLIC_KEY_MODULUS" is 4,096 (which is significantly large).

In this prototype application both the public key and the private key are stored in the database. In the code comments we note: "This is NOT a good idea for a production level application. Some good suggestions for storing the private key can be found here."

For the distribution of the system level public key we depend upon the security processes of the Google Play Store and the Apple App Store. The public key is embedded within the code of the mobile applications. These distribution systems for mobile applications have security requirements for code signing and authentication to the developer's account.

If these processes can be compromised by external bad actors or internal bad actors within Google or Apple, the system could be disrupted but not compromised (no illegitimate access through WebAuthn+). If a faulty app or a bad public key was distributed to users, the authentication system would fail but not allow access; the system can only be compromised if a bad actor gains access to the system level private key.

If the private key is compromised, the security solution is to update the public/private key pair by creating a new version of the mobile app with a new public key and requiring all users to update to the new version.

Creating the User

When a user downloads and installs the WebAuthn+ mobile app, the first screen the user sees is the password creation screen. The initial rule is that the password must be at least eight characters, numbers or values. Requirements can be set in code on password length and complexity.

Important note: We do not use simple password based encryption to secure data on the user's smart phone. We will cover the issue of securing data on a smart phone later in a section below. The problem with using simple password based encryption is that if your smart phone was lost or stolen a bad actor could possibly gain root access and launch a brute force attack against the encrypted data.

The user creates and confirms his/her password and is then taken to the Profile screen. The password is held in memory for now.

Only the "Screen Name" and "Contact Email Address" are required in the reference implementation.

When the user clicks "Save Profile" a UUID is created for the user and this value, along with the profile information, is sent to the WebAuthn+ application server.

Communicating Between the Mobile App and the Application Server

Sending data from the WebAuthn+ mobile app to the WebAuthn+ application server follows a standard pattern based on TLS.

For every transmittal, a 256 bit AES symmetric key is generated within the Android code using the KeyGenerator class. This key will be used to encrypt the data we are transferring to the WebAuthn+ application server; we will refer to this key as the "transfer key".

A Cipher is created using the RSA algorithm and "PKCS1Padding". This cipher is initialized using the system level public key which has been distributed with the WebAuthn+ mobile app. The cipher is used to encrypt the "transfer key".

The user profile data is formatted into a text block of comma separated name/value pairs. We will refer to this data as the "transfer data".

A Cipher is created using the AES_256 algorithm and "PKCS5Padding". This cipher is initialized using the "transfer key" and an initialization vector of 16 bytes. The cipher is used to encrypt the "transfer data".

We could in theory just use the cipher created using the RSA algorithm and "PKCS1Padding" to encrypt the transfer data and skip the creation of the "transfer key"; however, encryption using an RSA based cipher is considered inefficient and is limited to a fairly small block size of data. So we only use the RSA cipher to encrypt the "transfer key" which is a 256 bit AES symmetric key that is very efficient and can encrypt large blocks of data.

A "Message Authentication Code" (MAC) is created for the encrypted "transfer data" using the "transfer key". The MAC algorithm is HmacSHA256. The MAC will insure message integrity.

A set of URL parameters (name value pairs) is created; this is the information that will be sent to the application server:

PUBLIC_KEY_UUID
TRANSFER_KEY_ENCRYPTED
TRANSFER_DATA_ENCRYPTED
TRANSFER_DATA_MAC

The "CREATE_USER_URL" is contained within the WebAuthn+ mobile app as a constant; the URL is a call to an action class on the WebAuthn+ application server.

When the URL parameters are received on the WebAuthn+ application server the private key associated with the PUBLIC_KEY_UUID is used to decrypt the TRANSFER_KEY_ENCRYPTED. The "transfer key" is used to recreate the MAC of the TRANSFER_DATA_ENCRYPTED. If this recreated MAC equals the TRANSFER_DATA_MAC, all is well and we proceed to decrypt the TRANSFER_DATA_ENCRYPTED using the "transfer key" and create the user within the data structures of the WebAuthn+ application server.

We need an unambiguous reference to the PUBLIC_KEY_UUID; we cannot encrypt this value for transit because we would not know which key should be used for the decryption. The worst case scenario is that a bad actor modifies the the URL parameters in transit and the process fails (the process cannot be compromised by a bad actor; it can only fail). For similar reasons, we do not encrypt the TRANSFER_DATA_MAC.

A response string (e.g., USER_SUCCESSFULLY_CREATED or USER_ALREADY_EXISTS or MESSAGE_INTEGRITY_COMPROMISED or PROBLEM_WITH_AUTHENTICATION_SERVER) is encrypted with the "transfer key" and returned to the WebAuthn+ mobile app along with a MAC to insure message integrity.

When we are sending an HTTP response from the WebAuthn+ application server to the WebAuthn+ mobile app, as in the example above, we can just use the "transfer key" which is already known by the WebAuthn+ mobile app.

When communicating directly from the WebAuthn+ application server to the WebAuthn+ mobile app, as in the example below, we communicate from the application server to the user's smart phone through an encrypted Firebase channel. These messages are short enough that they can be encrypted with the user's public key which is stored in the data structures of the WebAuthn+ application server. These messages can only be decrypted with user's private key which is stored securely on their smart phone.

Securing Data on a Smart Phone

What do you mean, "stored securely on their smart phone"? Is that a joke? We all know from the Apple v FBI encounter that anything on your smart phone can be decrypted by anyone with marginal computer skills. It is incredibly easy to do.

Well... it is not easy to do if the encryption process is done in a sensible manner (send the following architectural overview to your friends at Apple). As stated above, the most important principle is to NOT use simple password based encryption.

When a user downloads and activates the TNX WebAuthn+ mobile app from the Apple App Store or from the Google Play Store, in the installation process the mobile app generates a 4,096 bit public/private key pair in less than ten seconds (on a "good" phone). A 4,096 bit key pair is very large and highly secure (double the traditional recommendation by RSA Laboratories [ref]).

The public key is uploaded to the mobile app provider's (e.g., your bank's) data structures. The private key never leaves your smart phone. The private key is stored on your smart phone in an encrypted state.

In order to protect the private key and other data within the TNX WebAuthn+ mobile app, access to the app is protected by a password and that password is used to generate a secret key using the PBKDF2WithHmacSHA256 algorithm. The two most important inputs into this algorithm are the password itself and the iteration count. The more complex the password and the higher the iteration count the higher the computational cost for anyone trying to crack the secret key. We also use a UUID salt value as an input in generating the secret key; this guarantees uniqueness.

The reference implementation uses an iteration count of 262,144. The iteration penalty is imposed every time a user enters his/her password and activates the TNX WebAuthn+ mobile app. On a good phone the time penalty is about 2.5 seconds (about the limit for a "bad" user experience).

When a user enter his/her password in the TNX WebAuthn+ mobile app, after a configurable number of failed attempts (bad password entries) the mobile app locks and the assistance of a personal banker (or a team member from corporate security, etc.) is required to reconfigure the app. Don't forget your password unless you want to see your personal banker or a team member from corporate security, etc.

Because after a configurable number of failed attempts (bad password entries) the mobile app locks, it is impossible to retrieve the decrypt key and attack WebAuthn+ through a brute-force attack.

So even a simple password offers protection against a bad actor who steals a user's smart phone.

If the user chooses a password that is ridiculously easy to guess (e.g., "password", "123", "asdf") then the quality of the algorithm and the iteration count may not protect the user against a bad actor within the service provider's organization or a government agency that orders a service provider to relinquish all data.

In theory, a brute force attack could be launched against all data within a service provider's database. However, in reality, this would be a highly problematic course of action.

How do you protect yourself against any brute force attack? Choose a complex password for the authentication app.

On most mobile app keyboards there are 82 characters to choose from (26 lower case, 26 uppercase, 10 numeric and 20 symbols). If a user creates a password with twelve characters there are 82 to the 12th power possible permutations to consider when cracking the secret key generated from the password:

82^12 = 92,420,056,270,299,898,187,776

That is 92 sextillion and change. If you randomly go through half the possibilities, you have a about a 64% chance of hitting the right password. How long would that take if each guess took 1 second to compute on a very fast computer and you had an array of one million computers?

92,420,056,270,299,898,187,776 / 2 (half the possibilities for a 64% probability) /1 million computers
/ 60 seconds in a minute / 60 minutes in an hour / 24 hours in a day / 365 days in a year = 1,465,310,380 years

That's 1.465 billion years; the age of the Earth is estimated at 4.543 billion years. In cryptography the key is to use algorithms that require a significant time penalty to defeat.

Assume that a user chooses a eight character password. The number of possibilities is 82^8 = 2,044,140,858,654,976 and the time calculation goes to 32.4 years; not great but maybe "good enough".

Assume that you are trying to protect some system like your phone with a four digit PIN. Well, that is only 10,000 possible combinations and the system could be cracked in a matter of seconds. Assuming that the iPhone was protected by a PIN or a weak password, it really was no big deal that the FBI was able to crack the system.

In the WebAuthn+ process, even though the secret key that is generated by the PBKDF2WithHmacSHA256 algorithm (using the password and iteration count) could be used to encrypt data on the user's smart phone, if the phone was lost or stolen a bad actor could do a brute-force attack and "eventually" decrypt the data.

Instead, the PBKDF2WithHmacSHA256 key is used to generate an obfuscated identifier that is associated with the user but cannot be used to identify the user, for example:

2E988595485874A71449546BB49A7AFC9B603ED5EFFD7A5DAC9B8B333A345B78

When a user enter his/her password in the TNX WebAuthn+ mobile app this obfuscated identifier is generated and sent to the server.

In order to attain a high level of security an AES-256 symmetric key is also created when the TNX WebAuthn+ mobile app is installed. This key is used to encrypt/decrypt data on the smart phone. This AES-256 key is encrypted with the PBKDF2WithHmacSHA256 key and stored off the smart phone in the application provider's data structures, associated with the obfuscated identifier.

When a user enter his/her password in the TNX WebAuthn+ mobile app and sends the obfuscated identifier to the server, the encrypted AES-256 key is returned to the smart phone and decrypted using the PBKDF2WithHmacSHA256 key. This AES-256 key is then used to encrypt/decrypt data on the smart phone.

It is important not to associate the user's encrypted AES-256 key with the user in the server data structures. Associating the user's symmetric key with an obfuscated identifier and not the user's account limit's the possibility that a bad actor within the mobile app provider's organization could gain access to a user's symmetric key, steal the user's smart phone and gain access to the user's accounts.

The only way to secure data on a smart phone is to encrypt the data with a key that is stored off the device, delete the key from the smart phone when it is not needed and load the key in a secure process when it is needed. Our process takes just a few seconds and is within the boundaries of being user friendly.

So if your smart phone is lost or stolen, a bad actor cannot sign on to your TNX WebAuthn+ mobile app; and if a bad actor can programatically gain root access to your smart phone and read the stored data, the important data (i.e., your private key) is securely encrypted.

Even if a government agency ordered a service provider to decrypt the data on a user's smart phone, the service provider would not be able to comply in any practical scenario.

Let's say that a government agency ordered the acquisition of all the obfuscated identifiers in the service provider's data structures. Would they be able to match an obfuscated identifier with the user's encrypted data on his/her smart phone? Maybe, if the user has an incredibly simple password.

Why don't we just use the security key within the Trusted Platform Module provide by the phone manufactures? There are both social reasons and technical reasons. Big corporations have now proven that they cannot be trusted with our personal data AND they cannot be trusted not to collude with evil governments. There are also numerous technical reasons not to trust TPM: click here for details

Secure Authentication

If a user has a secure private key on his/her smart phone and if there is a secure association on the WebAuthn+ application server between the user identifier (email address) and the user's public key, authentication can become simple and secure.

Communication between the browser and the WebAuthn+ application server is done securely over TLS.

Communication between the WebAuthn+ mobile app to the WebAuthn+ application server is done securely over an Encrypted Firebase channel.

Communication between the WebAuthn+ mobile app and the web browser is done securely over Web Bluetooth with Session Specific Pairing.

Hover over the numbers below in sequence and you will realize how simple and elegant the WebAuthn+ process truly is.

For step four to work in a secure manner the host's domain name needs to be sent from the browser application code to the Bluetooth Gatt Server running on the user's mobile device. Application level (from within the browser code) messaging from the browser to the smart phone over bluetooth is not yet supported by the Web Bluetooth API. The prototype uses the Nexus Chromium Browser which does support a Web Bluetooth call from the browser application context.

This change solves the key problem that needs to be solved for web authentication to be secure: a secure "out of band confirmation" that the user is on the "right" web page; e.g., "www.chase.com" not "www.chaze.com" (this completely stops phishing scams).

With this change, excluding attacks against the operating system and malware that mimics or compromises a true application, there is only one threat vector: If a bad actor "looks over your shoulder", steals your password, then steals your smart phone, and defeats the fingerprint reader (or other security) before you can report your smart phone lost or stolen... then the bad actor can access your account.

Session Specific Pairing

The pairing process currently specified by the Web Bluetooth API is not user friendly and not highly secure. "Session Specific Pairing" would be a great improvement.

Currently, JavaScript code in the web browser makes a request for a Bluetooth device advertising a specific service. Any device with the service UUID within sixty meters will show up in the pairing screen.

The user must select from potentially multiple devices in the pairing list. The reason for this manual selection has to do with security. The creators of the Web Bluetooth API did not want a web application to pair with just any Bluetooth device that happened to be close by and advertising a specific service.

However, it is incredibly annoying to have to manually pair your mobile phone whenever you sign on, especially when your phone is the only device in the list.

The process would be far more efficient and secure if a session UUID was added to the filters for the Bluetooth.requestDevice() JavaScript method. This session UUID would be sent to the mobile device by the browser and checked against the session UUID sent to the mobile device from the server. With this change, Web Bluetooth pairing could become automatic and more secure (no chance of the user selecting the wrong device).

In the Java Script, we would just add a sessionUuid to the services attributes:

let device = await navigator.bluetooth.requestDevice({filters: [{services: [serviceUuid, sessionUuid]}]});

A "message" attribute could also be added to the filters; e.g., "{message: ['Activate your WebAuthn+ mobile app.']}"

Once the app is activated it will start advertising with the service UUID and the session UUID; it will be picked up by the browser and automatically paired. Life will be beautiful.

The Nexus Chromium Browser supports "Session Specific Pairing".

Establishing a Trusted System ~ The Nirvana of Simple Passwords

The "Nirvana Solution" for authentication will enable users to keep simple passwords (which is what they really want). They do not want physical security keys or biometrics. They do not want to be required to use their smart phone for every authentication to every web application. They want simplicity (this is why basic user names and passwords have stuck around for so long).

Once the user successfully signs on, he/she can designate the system as a "trusted system" (e.g., a home computer or an office workstation); in the future the user can sign on to that "trusted system" with a user name (e.g., your email address) and a simple password (anything you choose, even "asd" or "123" or "pw").

If you forget your password, you can simply reset it without making a support call. Everything is done with high levels of cryptographic security.

The password can be incredibly simple because the value that the user enters is combined with a UUID salt value that is stored on the user's system as a cookie (hence, the system needs to be secure). The values are used to generate a cryptographic hash using the Stanford JavaScript Cryptography Library.

        var out = sjcl.misc.pbkdf2(password, sjclSalt, sjclIterationCount, sjclLength);
        var passwordHash = sjcl.codec.hex.fromBits(out).toUpperCase();
        console.log("passwordHash: " + passwordHash); // TODO: remove

A simple user password of "asd" becomes "7C3249A2415F53FC1A8A150C60C9347CBC14AE0C62C7C5C73FF4BC45A15ECFCA"; this value is essentially a generated password and is sent to the server over encrypted HTTPS. The value is hashed once again on the server with the Argon2id hashing algorithm (most secure) and stored on the server as a set of Argon2id parameters:

'$argon2id$v=19$m=1048576,t=4,p=8$HQiUtZvto2icGsXVTF/BJw$emWzw24cLFhmnd8WUhZDyjRJHCg1C0J9542yTPCiACE'

Whenever the user signs on, the hash values are recalculated and compared with the stored hash value. Without access to the user's physical system and knowledge of the user's password, it is impossible for a bad actor to sign on, even if there was a complete breach of the server data. The user can use the same simple password across multiple sites because each time it will be combined with a different salt value and will be stored on different servers as a completely different hash value.

A cookie with a password on a trusted system is actually more secure than a digital certificate on a "trusted system". With a digital certificate a bad actor just needs to access the system, either physical access or through malware. When a cookie and a password are required a bad actor would need both. Essentially, the cookie turns your trusted system into a "something you have" authentication factor.

Also, the user can always reset his/her own password. There is no need to call tech support.

Everyone assumed that user names and passwords had to be eliminated in order to solve the authentication problem. The paradox of the WebAuthn+ solution is that most users will be able to keep their user names and passwords, and passwords can become even simpler.

WebAuthn+ provides an open source reference implementation.
A system is secure if the plans for the system are public, and the bad actors can still not break in.

All technologies described here in are "Patent Pending".