Lek ؋ $ ƒ $ ₼ $ $ Br BZ$ $ $b KM P лв R$ $ ៛ $ $ $ ¥ $ ₡ kn ₱ Kč kr RD$ $ £ $ € £ $ ¢ £ Q £ $ L $ Ft kr ₹ Rp ﷼ £ ₪ J$ ¥ £ лв ₩ ₩ лв ₭ £ $ ден RM ₨ $ ₮ MT $ ₨ ƒ $ C$ ₦ kr ﷼ ₨ B/. Gs S/. ₱ zł ﷼ lei ₽ £ ﷼ Дин. ₨ $ $ S R ₨ kr CHF $ £ NT$ ฿ TT$ ₺ $ ₴ £ $ $U лв Bs ₫ ﷼ Z$
Trust Nexus
WebAuthn+ JSON DLT ~ The Internet of Value
Home Identity Distributed Ledgers Finance Demo IVY Test Contact License
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.
"Secure identity" will make the Internet of Value [ref] possible.
The concept of "cryptographically valid digital credentials" will soon end the debate over "secure identity".
Within three to seven years all authentication will be done through cryptographically valid digital credentials on smart phones.  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 web application you simply engage the WebAuthn+ process in the TNX One Touch mobile app.
All those who are committed to multi-factor identity management systems are like engineers in the 1890s working diligently to perfect the telegraph system; all their work will soon be eclipsed by a much better technology.
It all depends on public-key cryptography.
Here is everything you need to know about the magic of public-key cryptography:  There are two keys, a public key which everyone has access to and a private key which you must keep private for the system to be secure.  If a bad actor gets access to your private key it is game over; you lost. 
  • A message that is encrypted with your public key can only be decrypted with your private key.  If you keep your private key private, anyone can send you a secure message by accessing your public key.
  • When you send a message and sign it with your private key, your signature can only be confirmed with your public key.  If you keep your private key private, the validity of your signature is assured. 
That is the essence of public-key cryptography.
In the WebAuthn+ process the credential provider sends messages from the web server to your smart phone through an encrypted Firebase channel.  A message can only be decrypted with your private key which is stored securely on your smart phone.
What do you mean, "stored securely on your 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).
When a user downloads and activates the TNX One Touch 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.
In order to protect the private key and other data within the TNX One Touch mobile app, access to the app is protected by a six digit HEX pin (there are 16 HEX digits: 0 - 9 and A - F).  There is a 1 in 16,777,216 chance that a bad actor who steals a user's phone could guess the HEX pin on the first try.
The six digit HEX pin is not used for password based encryption (which can be easy to crack, ask Apple).  In the authentication (sign on) process to the the TNX One Touch mobile app, when the user touches "Activate", a check is made to the mobile app provider's (e.g., your bank's) web server.  After a configurable number of failed attempts 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 six digit HEX pin unless you want to see your personal banker (or a team member from corporate security, etc.).
In order to protect the user's private key and other data within the TNX One Touch mobile app, in the installation process the TNX One Touch mobile app also creates a traditional symmetric key (AES-256; used by the U.S. government for "TOP SECRET" information) and that key is used to encrypt the user's private key and other data in the TNX One Touch mobile app.  This symmetric key is then associated with an obfuscated identifier based on the user's HEX pin (and other factors on the smart phone) and then uploaded to the mobile app provider's data structures.
When the user sign's on with a valid six digit HEX pin the symmetric key is downloaded securely to the TNX One Touch mobile app and used to decrypt the user's private key and other data.  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 is a sub-second process, unnoticeable to the user.
So if your smart phone is lost or stolen, a bad actor cannot sign on to your TNX One Touch 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.
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.
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.
The essence of our system 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 smart phone 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 smart phone 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 represent those validations with cryptographically valid digital credentials.
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 attributes do not need to be verified; valid authentication (from the user who created the account) simply needs to be secure and repeatable.  Under this use case a credential can be issued directly through a web application when the account is created.
The process for Creating a Digital 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, "know your customer").  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.  There is no master identity proofing process that one organization or a government controls.  The identity proofing takes place by the institution when a digital credential is issued.
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.
The traditional view of identity is that you are a collection of identity attributes (e.g., user name, first name, last name, address, account number, credit history, etc.) and you then prove your association to these attributes through one or more of the three factors of authentication:
  • Something you know (password, secret question)
  • Something you have (security token, USB key,)
  • Something you are (biometrics)
Rather than proving an association to a set of attributes, we focus on the ability to use cryptographically valid digital credentials in valid institutional processes.  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.
Think of your smart phone as a security device for securing your private key.
Think of Identity and Authentication Management in terms of referencing institutional validations represented by 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.
Your identity is not determined by a collection of attributes; your identity is determined by a cryptographically valid digital credential that associates "you" to a public key.  The essence of "you" is determined by an institutional validation.
If your bank validates you and issues you a digital credential, your identity does not matter, all that matters is that you are the only person who can utilize that credential. 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.  In the age of technology it is possible to create a "valid seal" with a secure private key on a smart phone.
Establishing Security and Good Will
A system is secure if the plans for the system are public, and the bad actors can still not break in.
Our source code is available for download
In order to establish our infrastructure and generate good will, much of our technology will be licensed for a nominal fee or given away for free.  Our technology and infrastructure services are FREE for every publicly facing website for general user authentication.  There will be licensing fees for corporations and government agencies for internal authentication (e.g., free for banking customers; a small annual fee for banking employees).
Our process is primarily focused on authenticating to web applications.  A user with the TNX One Touch mobile app installed on his/her smart phone can go to any computer in the world and sign on securely to a web application.  For mobile apps, developers are free to use the source code for securely activating the TNX One Touch mobile app and encrypting data within the application.
An organization can maintain complete control of its authentication process under the Trust Nexus.  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 managed through The Worldwide Distributed Ledger of Credential Providers
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. [refA] [refB]  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 smart phone 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 advantage the Trust Nexus has over traditional PKI is that the public/private key pairs are generated in an asynchronous background process when the TNX One Touch mobile app is initialized and the user's private key is NEVER exposed.
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.
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 any personal data; when there is a need for third party validation we simply register the public keys of credential providers.  We change the mind set of authenticating using personal data; instead, the only thing that matters is an institutional validation represented by a cryptographically valid digital credential.
If you are a member of the Secret Moose Lodge of Ottumwa, Iowa, your digital credential can be validated under the Trust Nexus without any detailed information about you or your organization being revealed. 
Aren't biometric factors supposed to "save the day"?
There are severe limitations in using biometric data over a network or in a physical location with no monitoring; one of the most notable failures of biometrics is the "Gummi Bear Hack" used by Australian school children to defeat fingerprint sensors (and verified by Japanese researchers) [refA] [refB].
Most recently, a group of German hackers cracked the iPhone fingerprint scanner just two days after Apple Inc. launched the technology that it promises will better protect devices from criminals and snoopers seeking access [refA] [refB].
A biometric identifier is like a "magic word" that supposedly only the person associated with the identifier can say.  But once the "magic word" is spoken anyone who can access the identifying device (or the resulting digital stream) can speak the "magic word" and steal the user's identity.
Phone manufactures are touting biometric integration (most notably enhanced fingerprint scanners).  They are overlooking a disastrous use case:  What happens if a paramour drugs you and uses your finger to unlock your phone and financial accounts? Or even worse, Jack Bauer cuts out your eyeball and use it to "fool" an iris scanner.
When the person is present and the biometric data can be verified in the presence of a security agent, the utility of biometric processes increases significantly; in fact, this is the only valid use case for biometric factors.
Under the Trust Nexus it will be possible to securely store biometric data within a user's credential (not within a central repository) when the credential is created by the provisioning institution.  When a user presents the credential, verifying the biometric data in the credential against the individual in real time will provide enhanced security.
While there are many types of biometric identifiers, one of the simplest and most usable is a photograph of the human face verified by a human being.  Under the Trust Nexus any credential in a user's digital wallet that includes a photograph (driver's license, passport, bank debit card, etc.) will be highly reliable when a user presents the credential in person (and the quality of an identifying photo on a smart phone will be far superior to a photo on an ID card).
Iris scan identification, voice authentication and face recognition algorithms have become increasingly reliable; any one or a combination of these technologies could provide an additional layer of security.
Whatever type of biometric factor is used, the fact that the biometric (and all other) information in the Trust Nexus is stored in a user's digital wallet on his/her smart phone (secured by high level encryption) and not stored in a central repository means there cannot be a massive theft of identity information.  Governments that attempt to create vast repositories of biometric information will simply be storing extremely long "magic words" that are available for compromise at a single point of failure.
The "dirty secret" of biometrics is that biometrics are very poor for establishing an identity infrastructure; however, biometrics are great for destroying privacy and establishing a "Surveillance Society".[ref]
Will "Self-Sovereign Identity" provide a magical solution?
"Self-Sovereign Identity" (aka, "Decentralized Identity"), "...is the concept that people and businesses can store their own identity data on their own devices, and provide it efficiently to those who need to validate it, without relying on a central repository of identity data." [ref]
This is exactly what the Trust Nexus does with cryptographically secure digital credentials.  Once a digital credential is issued, all the user's information can be contained securely within the credential and the user has complete control.  There is no need for a central repository of identity data.  Our difference is that we think the credentials themselves, when issued by a legitimate credential provider (bank, passport office, DMV, etc.), will be sufficient.  There is no need to store claims, proofs, and attestation on a blockchain in a distributed database.  The size and complexity of such a system would be ridiculous.
As long as you can trust the legitimacy of a credential provider, you will be able to trust the claims contained within the digital credential; the assumption is that the credential provider has put the user through a legitimate identity proofing process.
Currently, the missing piece to the puzzle is a simple and elegant process for verifying the legitimacy of credential providers.
The Worldwide Distributed Ledger of Credential Providers (Which will contain no user data.) will complete the puzzle.
The Trust Nexus system is simple, effective, low cost, easy to implement and cryptographically secure.
While the Trust Nexus may "defy conventional wisdom", we are confident our core ideas are "non-consensus and right".
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.
How does the WebAuthn+ process work?
The graphic below provides an overview.
Hover over the numbers below in sequence and you will realize how simple and elegant the WebAuthn+ process truly is.
This is not theoretical; for all processes we have a functioning prototype and almost everything works:
  • Identity Management
  • Distributed Ledger
  • Funds Transfer
The messaging from the browser to the smart phone over bluetooth (step4) is not yet supported by the browsers.  Once it is supported in the WebAuthn process, we will be able to utilize that portion for WebAuthn+.  Even now, the WebAuthn+ process is more secure and convenient than SMS authentication codes.
You can test this for yourself.  Install the TNX One Touch mobile app and then go to our Test page.
No Bluetooth
How does the WebAuthn+ process work without bluetooth communication?
There will be times when a user attempts to sign on from a browser on a system that does not have bluetooth capabilities.  WebAuthn+ works with or without bluetooth communication.  Users with older systems are not excluded from the process.  The graphic below provides an overview.
The most important step is step 5:  The user must check the domain name which appears on both the sign on web page and on the user's smart phone.
Hover over the numbers below in sequence and you will realize how simple and elegant the WebAuthn+ process truly is.
Even without the bluetooth communication between the browser and smart phone working yet, the WebAuthn+ process is highly secure.  There are only two threat vectors when there is no bluetooth communication between the browser and smart phone.
First, if a bad actor can convince you that you are on "www.chase.com" when you are really on "www.chaze.com" a "man-in-the-middle" phishing attack can be launched.  The graphic below, from a Google I/O presentation on WebAuthn, portrays such an attack.
If a user is diligent about checking the domain name which appears on both the sign on web page and on the user's smart phone all will be well.
In order to simplify the user's check, we clear the address bar of everything except the domain name.  The following excerpt is from our open source code:
Unfortunately, it is easy to become complacent.  Relying on users to check the address bar in their browsers is a bad plan. 
Once bluetooth communication between the browser and the user's smart phone is implemented (sometime in the next few months) there will be a programmatic check of the URL address; the user will be alerted in his/her TNX One Touch mobile app if the he/she is on a phishing site.  A "man-in-the-middle" phishing attack will no longer be a threat.
The second threat vector:  If a bad actor "looks over your shoulder", steals your six-digit HEX pin and then steals your smart phone before you can report it lost or stolen, the bad actor can access your account.  Once the browsers implement bluetooth communication between the browser and the smart phone, this is the only threat vector in the WebAuthn+ process.
If a bad actor kidnaps you and attempts to torture you into giving up your six-digit HEX pin, you will be able to give up a six-digit "duress code" that will lead the bad actor to believe access has been granted and will alert the authorities to your geographic location.
Other threats against the operating systems on smart phones are now less problematic (reading into another app's memory space, etc.), especially if you stay with the main app stores.  If you download a "free" copy of Angry birds from an Elbonian website, you will get what you deserve.
Any organization with a significant IT staff will be able to take the WebAuthn+ source code and implement the system as a microcosm within their own environment.  For companies with a modest IT staff, WebAuthn+ will be provided as a service by one of the dozens of existing players in the identity management space.
Implementation and support are always the most difficult aspects in providing software as a service (SAS).  For users of WebAuthn+ as a service, the configuration will involve four very simple steps:
  • Modify CSS styles for a template authentication page.
  • Enter a JavaScript parameter for the URL of the App Server.
  • Configure a REST process to accept the user's credential UUID and authentication UUID when confirmed by the TNX Server (step 8).
  • Configure the Web App's authentication process to accept the authentication UUID (step 9).
In the graphic below, steps 1 through 7 are provided by the WebAuthn+ service provider.
Service providers will be able to incorporate the WebAuthn+ platform into their offerings for a very modest licensing fee (about eleven cents per internal user per month; our technology is FREE for every publicly facing website for general user authentication). 
Click here for license details.
© Copyright 2019 ~ Trust Nexus, Inc.
All technologies described here in are "Patent Pending".