Home Overview Future Potential FAQ Protocols Test Contact License
"Complexity is the worst enemy of security."
                                   - Bruce Schneier -
Initializing the TNX One Touch Mobile App >>> - page 1 - page 2 - page 3 - 
When a user first activates the TNX One Touch Mobile App the user's screen name and contact email address along with a "Universally Unique Identifier" are sent to a server in the TNX Secure Web Application (or to a server run by the infrastructure provider in the case of a large corporation or government agency controlling their own processes).
"Universally Unique Identifiers" are truly magical. The chances of two independently generated UUIDs being duplicates is incredibly small:  "To put these numbers into perspective, one's annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.00000000006 (6 EE-11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate. In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs."
Once the user's basic profile information is sent, another asynchronous process (transparent to the user) is launched to create the user's public/private key pair.  The process to create a 4,096 bit public/private key pair takes about ten seconds on a modern smart phone.  Once the keys are created, the public key is sent to a server in the TNX Secure Web Application and the private key is stored temporarily within memory in the TNX One Touch Mobile App.
Note:  The processes of the Trust Nexus insure that a user's private key is never exposed, not even to the infrastructure provider.  This self-creation and self-management of the public/private key pairs makes a worldwide system with billions of users possible.
When the TNX One Touch Mobile App is initialized a minimal amount of user data is stored within the TNX Secure Web Application.  The only data that is required from the user is a "screenName" and a "contactEmail"  The user can make up any screen name and use any email address he/she wants.  The TNX One Touch Mobile App has the capability to utilize multiple pseudo identities.
Securing User Data on the Mobile Device
How can data be secured on a mobile device even if the the mobile device is lost or stolen?  PIN based phone locks (used by all smart phone manufacturers) and PIN based application locks (used by Google Wallet, Samsung Wallet and others) are notoriously insecure.
"Your PIN affords you little protection if someone gets hold of your iPhone." [MacWorld]
The reason PIN based passwords are so easy to crack is that there are a limited number of possibilities to consider:  10,000 for a four digit PIN.  Text based passwords offer greater security if the passwords are long and complex, which, unfortunately, is an inconvenience for users.  Given that there are about ninety-four symbols available on a standard keyboard, a complex eight symbol password has 6.1 x EE 15 possibilities (6.1 billion times 1 million).  While this seems like a large number, even text based passwords are open to Brute Force Attacks.
The only way to secure data on a mobile device is to encrypt the data with a key that is stored off the device, delete the key from the mobile device when it is not needed and load the key in a secure process when it is needed.
In the initialization process of the TNX One Touch Mobile App a 256 bit AES "userSecurityKey" is created.  This key is used to encrypt data on the mobile device (including the user's private key).  Once the key is created it is off loaded to a server in the TNX Secure Web Application.  When a user starts the TNX One Touch Mobile App the "userSecurityKey" is downloaded.
The process of loading the "userSecurityKey" is a sub-second process, unnoticeable to the user.
The downside of this process is that there is a loss of functionality if the user's mobile device loses connection.  However, even if there is a loss of mobile service, most home environments, most corporate environments and most retail areas have or soon will have a WiFi service that will make the TNX One Touch Mobile App operational.  If both mobile service and WiFi service are down, it probably means there is a complete power failure and any services the user wishes to access are also down.
Securing the User Security Key
One of our goals in this project was to create a completely transparent system where everyone could examine the system for flaws.  In one of the early reviews we were forced to consider the possibility of bad actors within the TNX Secure Web Application (or within the organization of the infrastructure provider in the case of a large corporation or government agency controlling their own processes).
In an early version of the system, if a bad actor had unrestricted access to the TNX Secure Web Application he/she could associate a user's UUID to the user's "userSecurityKey".  If the bad actor could then steal the user's mobile device havoc would reign.
We solved this problem in a unique way by creating an obfuscated identifier that is only available to the user and then completely disassociating this identifier from all other aspects of the user within the TNX Secure Web Application.
When a user initializes the TNX One Touch Mobile App the user creates a PIN value.  There is an option between an enhanced six or eight digit HEX PIN screen (values 0 to F).  The PIN value is NOT used to encrypt data in a password based encryption process, it is used to create the user's obfuscated identifier.
The goal is to obfuscate the PIN values so that they are unique within the TNX Secure Web Application and not traceable back to any specific user.  This is done by creating a "PBEKeySpec" using three items: the bytes of the PIN string, a SALT value and an iteration count.  The SALT value is a Universally Unique Identifier that is combined with the bytes of the PIN string and is used for obfuscation.  If SALTs were not used, everyone with the same PIN and using the same iteration count would have the same identifying value.
The value from the PBEKeySpec is used to create a 256 bit AES symmetric key,  This key is used to initialize a Message Authentication Code object; this object is then used to create a hashed value of the user's UUID.  This hashed value becomes the user's obfuscated identifier associated with his/her "userSecurityKey" within the TNX Secure Web Application.
When a user activates his/her TNX One Touch Mobile App the process is repeated and a secure request is made to the TNX Secure Web Application which returns the user's "userSecurityKey" which the user can then use to encrypt and decrypt data on his/her mobile device.  The process is incredibly fast and unnoticeable to the user.
If a bad actor steals the user's mobile device and attempts to randomly guess the user's PIN, with each guess the TNX One Touch Mobile App must check with a server in the TNX Secure Web Application; there is a time out feature that inactivates the TNX One Touch Mobile App after a certain (configurable) number of failed attempts.
This process prevents a brute force attack.
There is a very low probability that a bad actor could correctly guess a user's PIN:
  • Standard Four Digit Numeric PIN Screen (values 0 to 9):  1 / 10,000
  • Enhanced Six Digit HEX PIN Screen (values 0 to F):  1 / 16,777,216
  • Enhanced Eight Digit HEX PIN Screen (values 0 to F):  1 / 4,294,967,296
Note: We even have an answer for the "Jack Bauer" scenario where evil actors kidnap and torture you to get your HEX pin. There will be an alternate HEX pin that will be a "duress code"; it will appear to sign you on and the authorities will be notified of your GPS location.
Creating an Identity Credential
For highly secure credentials, government agencies, corporations and financial institutions will provision credentials in a secure internal process:  users will bring their mobile device to the security office or branch location. 
Credentials can also be provisioned through an Internet process:  Users will go to a web page run by the credential provider.  In this process there is a general assumption that communication between the Internet browser and server takes place over a secure SSL/TLS connection.
In the most basic use case, the credential provider of a web application simply wants to secure the account to the user who created the account.  Identity does not need to be established; valid authentication (from the user who created the account) simply needs to be secure and repeatable.
It is a very simple process for a user to create a new identity credential and sign on to a web application for the first time.
When a user goes to a new web application he/she will see the following notification:
The user enters the "authenticationCode" ("TNX FMJV") into his/her TNX One Touch Mobile App and clicks "Authenticate".
Please Note:  The list of credentials that you see are simply for illustrative purposes in the prototype.
Once the user clicks "Authenticate" a secure transmission is sent to a server in the TNX Secure Web Application requesting the provider data.  The "transferKey" that was used to encrypt the data package in this request is held in the TNX One Touch Mobile App.  The server returns the provider data encrypted with the original "transferKey"; the server also returns a "Message Authentication Code" that insures the integrity of the message.
This process insures the communication between the server and the TNX One Touch Mobile App is secure and uncompromised.  If a bad actor intercepts the message he/she cannot access the encrypted data.  If a bad actor attempts to change the message, that change will be detected.  This process insures the credential provider's data, especially the public key, is securely downloaded to the TNX One Touch Mobile App.
Once the provider data is securely downloaded, the user is taken to a "profile" page where he/she can select how much personal information to send to the credential provider.
Prior to sending the user data to the credential provider, the TNX One Touch Mobile App makes a request to the TNX Secure Web Application for a "transactionUuid".  The TNX Secure Web Application records the request, associating the "userUuid" with the "transactionUuid" then sends the "transactionUuid" to the TNX One Touch Mobile App.
Along with the user's personal data the TNX One Touch Mobile App sends the credential provider the "transactionUuid" signed with the user's private key.  Once the data is received, the credential provider requests the user's recently recorded "transactionUuid" and public key from the TNX Secure Web Application.  The credential provider can then check the signature of the "transactionUuid".  If the "transactionUuid" is valid and the signature is valid the credential provider can be certain that a user associated with the given "userUuid" has sent the data.  This is the key step in cryptographically assuring the security of the credential.
For emphasis:  If the "transactionUuid" is valid and the signature is valid the credential provider can be certain that a user associated with the given "userUuid" has sent the data or the user gave his/her mobile device and six digit HEX pin (1/16,777,216) to someone else.
This process of creating, signing and verifying a "transactionUuid" is used in most processes between the TNX One Touch Mobile App and servers in the TNX Secure Web Application or servers run by a credential provider.  This process replaces the need for the "RSA SecurID key fob" or other similar devices.
Goodbye.
Once the user data is securely uploaded and the user's account is created by the credential provider the user is notified, "Credential successfully created".  A "verificationCode" ("MYF 879") is displayed in TNX One Touch Mobile App.
Notice that there is now an entry for The Trust Nexus in the list of Identity Credentials.
The user's web page is "auto-magically" transformed with a, "Thank you", message and the "verificationCode"
("MYF 879") is displayed.  The fact that the "verificationCode" is sent over a secure channel from the credential provider's server to the user's mobile app AND to the user's web browser eliminates any possibility of a phishing scam.
When the user touches "Authenticate" the "Text Code Sign On" process (details below) is engaged.
A verificationCode ("PKW 270") is displayed in the mobile app and on the web page.
The process for "Creating an Identity Credential" can also be applied in a secure setting where identity is verified (e.g., the issuance of corporate identity credentials at a security station or the issuance of financial credentials at a bank).  This secure "identity proofing" represents a high level institutional validation.  Within the Trust Nexus the user's identity is verified in a valid institutional process determined by the institution issuing the credential.
The NFC capabilities of mobile devices will enable a seamless process with no need for "authenticationCodes" in the process of Creating an Identity Credential at a physical location ("Touch and go. Your credential has been provisioned.").
The "authenticationCode" could also be sent "out of band" to the user (e.g., email, phone call, etc.).  If this code can be securely communicated to the user an existing account could be associated with the user's digital credential.  The process of securely communicating the "authenticationCode" is not specified within the Trust Nexus.
Text Code Sign On
When a user goes to the Text Code Sign On page in his/her web browser an asynchronous process is launched that reads the "userUuid" from a cookie value (initially set in the credential creation process).  This value is sent to the credential provider's server where a data base record is created.  This record contains the "userUuid" and a newly created "sessionUuid".  A check is also made to insure there are not duplicate sessions from the same user; this insures that a "bad actor" cannot hijack a valid user's session simply by manipulating the cookies on another computer.
An asynchronous process from the user's web browser then polls the credential provider's server every five seconds (configurable) and "asks" the question, "Has this user been authenticated?"  If the answer is yes, the "verificationCode" (created in the TNX One Touch Mobile App) is transmitted to the browser and displayed with a welcome message.
When a user enters the "authenticationCode" (displayed on the web authentication page; e.g., "TNX FMJV") in the TNX One Touch Mobile App and clicks "Authenticate", the following information is sent to a server in the credential provider's infrastructure from the mobile app:
  • "authenticationCode"
  • "userUuid"
  • "transactionUuid"
  • "transactionUuidSigned"
  • "verificationCode"
A "verificationCode" is generated by TNX One Touch Mobile App for each authentication.  This code is simply a visual cue for the user (displayed both in the mobile app and the web browser).  The "sessionUuid", transmitted securely from the credential provider's server to the user's web browser, provides the programmatic security check for a secure session.
The user's "transactionUuidSigned" is verified using the user's public key.  The only way the "transactionUuidSigned" can be verified is if it was created with the user's private key.  This process insures that when the user presents the credential (either in person or over the network) the receiver can be certain that either the credential and the user are valid or the user gave his/her mobile device and six digit HEX pin (1/16,777,216) to someone else.
>>> - page 1 - page 2 - page 3
© Copyright 2017 ~ Trust Nexus, Inc.
All technologies described here in are "Patent Pending".