Home Overview Future Potential FAQ Protocols Test Contact License
When the solution to cybersecurity authentication emerges, everyone will say, "Of course, this is how it had to be."
TNX Cryptographic Protocols >>> page 1 - page 2 - page 3 - 
The following information is being reformatted into an RFC for the Internet Engineering Task Force (IETF).
Abstract
The Trust Nexus enables cryptographically secure authentication through mobile devices.  User names and passwords and all of their weaknesses are completely eliminated.  A user experiences single sign on to his/her mobile device.  Once signed on, users touch one button on their mobile device to authenticate to both web based and mobile applications. 
Under the Trust Nexus the concept of identity is fundamentally changed.  Who are you?  You are the entity that has been issued a cryptographically valid digital credential.
Think digital certificates on a mobile device with the convenience of One Touch Authentication™ and none of the overhead of PKI.
Think of the convenience of not managing cryptographic keys. The TNX One Touch mobile app generates a 4,096 bit public/private key pair and secures the private key on the mobile device (truly secure; no password based encryption processes; no dependency on "phone lock" OS processes).
Think of Identity and Authentication Management in terms of referencing cryptographically valid digital credentials, not in terms of managing and verifying certificate chains of authority, or even worse, managing and validating vast amounts of personal or biometric data.  Think of the past when the king's seal represented a stamp of approval; your identity did not matter, all that mattered was the validity of the king's seal and that you were the rightful holder of the credential.
How can you trust a digital credential?
Two questions must be answered:
Can you verify that the credential was issued in a valid institutional process (no counterfeit credentials)?
Can you verify that the person to whom the credential was issued is the person presenting the credential (no fraud in the authentication process)?
These questions can be answered with transparent cryptographic processes.
A New Archetype
The essence of our process is incredibly simple:  Through cryptographically valid digital credentials, we completely do away with user names and passwords (and all of their weaknesses).  If a credential is provisioned to a user's mobile device in a valid institutional process, then 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.
What is a valid institutional process?
It can be anything the institution defines AND controls, from the very simple to the highly secure.  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.  Digital credentials can also be issued under the Trust Nexus in a highly secure setting (e.g., a corporate security office or a bank branch office).
Currently, most strong authentication schemes rely on some type of Multi-factor authentication (MFA).
"Multi-factor authentication (MFA) is a method of computer access control in which a user is only granted access after successfully presenting several separate pieces of evidence to an authentication mechanism - typically at least two of the following categories: knowledge (something they know); possession (something they have), and inherence (something they are)." [ref]
This archetype based on validating pieces of information is fundamentally flawed in practice.  There is currently no multi-factor authentication process that is both secure and consumer friendly.  In recent years there have been numerous failures of new authentication architectures due to lack of consumer acceptance (OpenID and OAuth being the latest; the most recent "flavor of the month", the FIDO alliance, has gained little consumer traction).
This failure of multi-factor authentication has lead to a general reliance on user names and passwords.  As a secondary enhancement, many major service providers use text messaging to a mobile device (SMS) as a second factor; however, this process has recently been deprecated by the National Institute of Standards and Technology (NIST). [ref]
The Trust Nexus presents a new archetype for authentication based on cryptographically valid digital credentials.  In this new archetype what matters most is an institutional validation of the individual represented by a cryptographically valid digital credential that can be verified in a secure and consumer friendly way.
This institutional validation, captured in the cryptographic processes when the credential is issued, represents a stamp of approval.  If the stamp is cryptographically valid, the authentication can be trusted.
This new archetype presents different questions:  Has the digital credential been issued in a valid institutional process?  Is the user to whom the credential was issued the only person who can utilize the credential?  Can the institutional validation be verified when the user presents the credential?  Is the process consumer friendly?  Is the process cryptographically secure?  The Trust Nexus answers all of these questions.
Creating a Secure Mobile Identity Ecosystem is not about managing vast amounts of personal data; it is about managing cryptographically valid digital credentials that represent valid institutional processes.
No organization concerned with consumers is going to institute a complicated process.  No organization concerned with security is going to trust its authentication to a delegated process that depends on a user's Facebook account; however, a high level security organization like a financial institution will be willing to trust credentials issued by another financial institution if the institutional processes can be trusted and cryptographically verified.
The ability to create and secure a 4,096-bit cryptographic key on a user's mobile device makes this new archetype possible. [ref]
Because the receiver can cryptographically verify that you are the person to whom the credential was issued, under the Trust Nexus it truly does not matter who you are; what matters are institutional validations and the ability to verify those validations.
Most authentication schemes depend on securing and verifying personal data; we focus on the ability to use credential data in a valid institutional process.  The concept of verifying institutional validations rather than verifying personal data requires a shift in perspective.  Once that mental shift occurs everyone is amazed at how simple our system is.
Overview
In the late Seventies and early Eighties computer names were maintained by using handcrafted HOSTS.TXT files. As networks became more interconnected this process became unmanageable.  Everyone knew that something needed to be done.  When the Domain Name System (DNS) was created everyone saw it as the obvious solution.
Similarly, when the solution to cybersecurity authentication emerges, everyone will say, "Of course, this is how it had to be."
The basic question is, how can trust be established in the digital age?  If you and I have never met and I come to your website or place of business, how can you be confident that my digital credential is valid?  The Trust Nexus answers this basic question regarding the establishment of trust.
Within five to ten years all authentication will be done through digital credentials on mobile devices.  Imagine going to your local bank or corporate security desk and having a digital credential provisioned to your smart phone.  Once this or any other credential is provisioned in a valid institutional process, from then on, whenever you sign onto the institution's website (or mobile application) you simply scroll to the credential's icon on your smart phone and engage the "One Touch Sign On"™ process.
"Multi-factor authentication (MFA) is a method of computer access control in which a user is only granted access after successfully presenting several separate pieces of evidence to an authentication mechanism - typically at least two of the following categories: knowledge (something they know); possession (something they have), and inherence (something they are)." [ref]
This archetype based on validating pieces of information is fundamentally flawed in practice.  There is currently no multi-factor authentication process that is both secure and consumer friendly.  In recent years there have been numerous failures of new authentication architectures due to lack of consumer acceptance (OpenID and OAuth being the latest; the most recent "flavor of the month", the FIDO alliance, has gained little consumer traction).
This failure of multi-factor authentication has lead to a general reliance on user names and passwords.  As a secondary enhancement, many major service providers use text messaging to a mobile device (SMS) as a second factor; however, this process has recently been deprecated by the National Institute of Standards and Technology (NIST). [ref]
The Trust Nexus presents a new archetype for authentication based on cryptographically valid digital credentials.  In this new archetype what matters most is an institutional validation of the individual represented by a cryptographically valid digital credential that can be verified in a secure and consumer friendly way.
This institutional validation, captured in the cryptographic processes when the credential is issued, represents a stamp of approval.  If the stamp is cryptographically valid, the authentication can be trusted.
This new archetype presents different questions:  Has the digital credential been issued in a valid institutional process?  Is the user to whom the credential was issued the only person who can utilize the credential?  Can the institutional validation be verified when the user presents the credential?  Is the process consumer friendly?  Is the process cryptographically secure?  The Trust Nexus answers all of these questions.
Creating a Secure Mobile Identity Ecosystem is not about managing vast amounts of personal data; it is about managing cryptographically valid digital credentials that represent valid institutional processes.
No organization concerned with consumers is going to institute a complicated process.  No organization concerned with security is going to trust its authentication to a delegated process that depends on a user's Facebook account; however, a high level security organization like a financial institution will be willing to trust credentials issued by another financial institution if the institutional processes can be trusted and cryptographically verified.
The ability to create and secure a 4,096-bit cryptographic key on a user's mobile device makes this new archetype possible. [ref]
The essence of our process is incredibly simple:  Through cryptographically valid digital credentials, we completely do away with user names and passwords (and all of their weaknesses).  If a credential is provisioned to a user's mobile device in a valid institutional process, then 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.
Because the receiver can cryptographically verify that you are the person to whom the credential was issued, under the Trust Nexus it truly does not matter who you are; what matters are institutional validations and the ability to verify those validations.
Under the Trust Nexus the concept of identity is fundamentally changed.  Who are you?  You are the entity that has been issued a cryptographically valid digital credential.
Most authentication schemes depend on securing and verifying personal data; we focus on the ability to use credential data in a valid institutional process.  The concept of verifying institutional validations rather than verifying personal data requires a shift in perspective.  Once that mental shift occurs everyone is amazed at how simplehow simple our system is.
Comparison to PKI
While many of our cryptographic processes are similar to the processes used in Public Key Infrastructure (PKI), we avoid the bureaucratic inconveniences and lax security inherent in PKI. [ref] [ref]  Under PKI, when a digital certificate is issued the user (or a malicious administrator or someone who can access the user's system) can simply "share" the cert with anyone.  Under the Trust Nexus it is far less likely that a user will share his/her mobile device and six digit HEX pin. 
Also, under the Trust Nexus a catastrophic security breach of the PKI, similar to the Comodo Security Breach, would have no ill effects for users.  Contrary to the proponents of PKI, a Comodo-like security breach is always a possibility, especially if you travel to a hostile foreign country or if you are a citizen under an oppressive regime.
The most significant advantages the Trust Nexus has over traditional PKI is that there is no need to verify identity when public/private keys are issued.  The vetting process takes place when a credential is issued.
Removing the need for a Trust Authority to verify billions of individual identities and manage billions of public/private keys makes a world wide system practical.
Unlike PKI, in authenticating third party credentials we are only attempting to answer a very narrow question:  Has the credential been issued in a valid institutional process by the holder of the credential provider's public key? Unlike Certificate Authorities we are not attempting to validate the legitimacy of the credential provider or establish a "chain of authority" from one trusted entity to another. If a totally bad actor attempted to create a fraudulent financial institution and then issued credentials to users who then went out to present the credentials to third parties, our completely valid assumption is that there would be other factors in the process that would render the credentials invalid.
The Trust Nexus enables a non-hierarchical certification process.  A financial institution that registers as a credential provider may also include in its credential data a reference to a credential it was issued by a state or federal certification agency.  The legitimacy of the credential issued by the state or federal certification agency could be determined by the preponderance of the credentials it has issued.
Privacy
One of the most important aspects of our technology is that we secure identity while protecting privacy.  Our technology provides a 100% privacy protection.  We do not store personal data, we simply store associations between public keys and digital credentials.  We change the mind set of authenticating using personal data; instead, we verify institutional validations.
If you are a member of the Secret Moose Lodge of Ottumwa, Iowa, your identity credential can be validated under the Trust Nexus without any detailed information about you or your organization being revealed.  We simply verify the institutional validation that was created when your credential was issued.
Under the Trust Nexus it is possible for users to create pseudo-identities and conduct financial transactions in complete anonymity.  Users are always in complete control.  They can create accounts with their "legal identity" or choose from one or more pseudo-identities that they have created for various purposes.
Under the Trust Nexus the user's credentials cannot be accessed if his/her mobile device is lost or stolen.  We have solved this problem without needing access to the secure element of the mobile device.  We do not use password based encryption so a brute force attack would not be successful.  There are no dependencies on "phone lock" OS processes; the dependencies are on independent cryptographic processes.
Additionally, under the Trust Nexus once a financial institution has provisioned a credential to a user's mobile device in a valid institutional process, the user can conduct secure financial transactions without revealing any information about the details of the financial credential or the user.  Through secure cryptographic processes the user's mobile device will receive the transaction details from the seller's web application (or retail POS terminal).  The user's financial credential UUID will be added to these transaction details which will be cryptographically signed with the user's private key and returned to the seller's web application.  The seller's web application verifies the data packet, signs the data packet with the seller's private key and sends the data packet, the user's signature block and the seller's signature block to the payment processor.  The payment processor verifies both signature blocks (with public keys on file) then sends the information to the financial institutions to processes the debits/credits.
When a financial institution receives a request for payment containing the data packet (which includes the user's financial credential UUID) and the user's signature block, the financial institution can easily verify the the legitimacy of the request because the financial institution created the original financial credential UUID (and the association with the user's UUID and public key) when the credential was provisioned to the user's mobile device in a valid institutional process.
When everything is done and the seller receives payment, the seller only knows that there is an association between the user's financial credential UUID and the user's public key.  All other information could remain private at the user's discretion.  The fact that the user's private key is secured on his/her mobile device and that the financial credential was provisioned in a valid institutional process, means that the seller, payment processor and financial institution can be certain that the financial 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.
Maintaining the associations ("users/credentials/public keys"; "sellers/financial accounts/public keys") will be the essential functionality of a worldwide identity infrastructure for financial transactions and other three party credentials (driver's licenses, passports, insurance credentials, etc.).  Paradoxically, this worldwide identity infrastructure will contain no personal data.
Intellectual Property / License
The Trust Nexus will not attempt to compete against the dozens of existing players in the identity management space.  We intend to license our authentication technology to all players for a nominal fee; this will insure a rapid and widespread implementation.
All technologies described here in are "Patent Pending".  While each individual aspect of the system is not unique, the unique combination of all the aspects creates a system that enables the creation of secure digital credentials on mobile devices, prevents identity theft, prevents fraudulent financial transactions, protects privacy, enables a simplified federation process and provides a consumer friendly "One Touch Sign On"™ process.
We are very confident our patent applications will pass the Graham Factors for non-obviousness, especially the factors that show, "objective evidence of non-obviousness":
  • commercial success
  • long-felt but unsolved needs
  • failure of others
Basically, if we create a system that succeeds in the marketplace, patents will be awarded.
The utility of the Trust Nexus will not lead to duplication even after the patents expire.  Once the infrastructure is created and widely adopted it will be nearly impossible to displace the infrastructure.  A good analogy is the electrical power grid.  There are many players that compete in the production of electricity, but no one attempts to replace the basic infrastructure.
The Most Basic Use Case
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.  Under the Trust Nexus this criteria is securely met in a process that provisions a user's credential over the Internet.  In this process a user can secure access to an account without revealing anything about his/her identity.  Pseudo identities are a viable option.
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.  Under the Trust Nexus the user's identity is verified in a valid institutional process determined by the institution issuing the credential.
Our infrastructure technology can exist as an insulated microcosm within corporations or government agencies when there is no need for third party validation of credentials (e.g., a corporation or government agency simply wants to authenticate its own users).  When third parties must rely on credentials (e.g., drivers licenses, passports, financial credentials, insurance credentials, etc.) there will be a public identity infrastructure that will be run in cooperation with governments worldwide.
Key Components
There are two key components within Trust Nexus:
  • TNX Secure Web Application
  • TNX Secure Mobile App
The TNX Secure Web Application is a Java EE (more platforms coming soon) web application that, along with the TNX Secure Mobile App provides a complete implementation of the Trust Nexus.  This is not not theoretical; we have a functioning prototype and everything works.
The TNX Secure Mobile App is a digital wallet for managing both identity and financial credentials.  Additionally, this digital wallet enables users to manage their personal profile (the information about the user that is sent to credential providers).
The TNX Secure Mobile App will be FREE to consumers.
Basic Definitions
There are four primary actors within the Trust Nexus:
  • user
  • credential provider
  • infrastructure provider
  • third party accepting a credential
There are two types of credentials: "two party" and "three party".  A "two party" credential functions between the user and the credential provider (e.g., a corporation or government agency simply wants to authenticate its own users).  A "three party" credential is issued to a user by a credential provider and is presented to a third party (e.g., drivers licenses, passports, financial credentials, insurance credentials, etc.).
In most cases the infrastructure provider will be the Trust Nexus.  In some cases the infrastructure provider and the credential provider will be the same actor (e.g., a large corporation or government agency that completely runs its own system).
While the Trust Nexus will provide infrastructure services, the license does not prohibit organizations from running their own infrastructure.  In fact, the availability of the source code and data structures makes this very easy to do.  The license does prevent an organization from providing third party services.
Communication Between the Mobile App and the Servers
It is good coding practice to use descriptive variable names.  In the exposition that follows the actual variable names that are used in the source code are presented within quotes and highlighted in Indigo (e.g., "variableName").
Primary Assumption:  The TNX Secure Mobile App is provisioned to a user's mobile device in a secure process.  This insures the initial integrity of the infrastructure provider's public key.  We assume that downloading the TNX Secure Mobile App from the Google PlayStore or Apple Store is a secure process.
Even if a bad actor can trick a user into installing malware that has the "look and feel" of the TNX Secure Mobile App or even if a bad actor can replace an existing TNX Secure Mobile App with malware, the system CANNOT be compromised.  False authentications cannot be made.  Fraudulent financial transactions cannot be made.  The worst case scenario is that valid authentications and transactions will not be made. 
Communication between the mobile app and the servers (both the servers of the infrastructure provider and the servers of the credential provider) follows a basic design pattern.
There are four packages sent in every secure transmission from the mobile app to the server:
  • "packageOne":  The "providerPublicKeyUuid" which identifies the public key of the provider.
  • "packageTwo":  A one time "transferKey" encrypted with the public key of the provider.
  • "packageThree":  The data being sent; this data is encrypted with the one time "transferKey".
  • "packageFour":  A "Message Authentication Code" that insures the integrity of the message.
This structure insures the communication between the mobile app and the server 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.
The symmetric "transferKey" is used for efficiency.  Encrypting the data package with the provider's asymmetric public key is inefficient.
Note:  Our primary concern at the beginning of this project was the speed of cryptographic processes on Android based mobile devices.  We were pleasantly surprised.  Even with 4,096 bit asymmetric keys and 256 bit AES symmetric keys the process times on most new smart phones is sub-second (with the exception of the creation of the public/private key pair itself, which takes about ten seconds).
The reference implementation of the Trust Nexus uses incredibly strong keys:  4,096 bit asymmetric keys and 256 bit AES symmetric keys  According to RSA, "2048-bit keys are sufficient until 2030. An RSA key length of 3072 bits should be used if security is required beyond 2030."  Also, "The U.S. Government requires 192 or 256-bit AES keys for highly sensitive data." [ref]
>>> page 1 - page 2 - page 3
© Copyright 2017 ~ Trust Nexus, Inc.
All technologies described here in are "Patent Pending".