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 WebAuthn+ Identity Distributed Ledgers Finance Demo IVY Test DEV 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 secure digital credential.
Secure identity will make the Internet of Value possible.
The concept of "cryptographically secure digital credentials" will soon end the debate over "secure identity".
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 WebAuthn+ mobile app.
All those who are committed to existing 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.
Current MFA systems are NOT secure: FBI Issues Surprise New Cyber Attack Warning: Multi-Factor Authentication Is Being DefeatedWebAuthn+ is secure against the attack scenarios described in this article.
Cryptography Fundamentals
While the mathematics of implementing a cryptographic system can be very complex, the basic principles are quite simple.
There are two broad categories of encryption:  Symmetric and AsymmetricSymmetric encryption depends on a single key that needs to be shared among the people who encrypt and decrypt messages.  Symmetric encryption can be very secure if the key is strong and protected.  The bureaucratic nightmare of securing and administering secret keys inspired the creation of Asymmetric encryption which is usually referred to as 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 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 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. 
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).
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 do not make a difference.  The system is highly vulnerable.
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.
Even though the secret key generated by the PBKDF2WithHmacSHA256 algorithm could be used to encrypt data on the user's smart phone, it is best practice to create an AES-256 key, use that symmetric key to encrypt data and just use the secret key to encrypt the AES-256 key.  If the user changes his/her password the change will not require a complete decryption/re-encryption of all values.
Also, having a secondary symmetric key that itself is encrypted allows the encrypted value to be stored off the user's smart phone.  When the user activates his/her TNX WebAuthn+ mobile app the encrypted key is downloaded and decrypted with the generated secret key.  If the user's mobile deice is lost, stolen or confiscated by bad actors, it is impossible to decrypt data with just the data on the phone (there is no way to test that a guessed password is successful).
In the authentication (sign on) process to the the TNX WebAuthn+ 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 password unless you want to see your personal banker or a team member from corporate security, etc.
There is also no need to associate the user's encrypted AES-256 key with the user in the server data structures.  We use the secret key generated by the PBKDF2WithHmacSHA256 algorithm to create an obfuscated identifier and associate the encrypted AES-256 key to that identifier.  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 is 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.
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
Cryptographically Secure Digital Credentials
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."
Whenever a significant technology problem is solved, incredible new opportunities arise.  Solving the Domain Name System (DNS) problem made the creation of the information Internet possible.  Solving the authentication problem will make the Internet of Value possible.
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 secure digital credentials, we completely do away with user names and passwords (and all of their weaknesses) for web authentication.  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 password 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 secure 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 Cryptographically Secure 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 secure 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, mobile device)
  • Something you are (biometrics)
Rather than proving an association to a set of attributes, we focus on the ability to use cryptographically secure 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 and your association to your digital credentials.
Access to your phone can be thought of in terms of the three factors of authentication:
  • Something you know (password)
  • Something you have (the phone itself)
  • Something you are (fingerprint scanner)
However, once you have established a legitimate association to your private key, the digital credential process takes over.  We have essentially created a single sign on process with the user's smart phone as the point of entry.
Think of Identity and Authentication Management in terms of referencing institutional validations represented by cryptographically secure 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 secure digital credential that associates "you" to a public key.  For each specific context, 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.
It will be simple to make cryptographically secure digital credentials interoperable amongst various institutions and commercial enterprises.  Surprisingly, there is no need to store user credentials or identity data in any type of worldwide data structure.  All that is necessary is to have sufficient information to validate the credential provider (bank, insurance company, government passport agency, etc.).
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 WebAuthn+ 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 WebAuthn+ mobile app, encrypting data within the application and communicating over an encrypted Firebase channel.  It would also be possible for multiple mobile apps to share a single credential management application, perhaps provided by a service provider.
An organization can maintain complete control of its authentication process under the Trust Nexus.  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) our infrastructure technology can exist as an insulated microcosm within corporations or government agencies
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. [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 smart phone and password. 
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 there is no certificate chain of authority to maintain and no cumbersome bureaucratic processes.
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.
Protecting 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 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 secure 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).
Fingerprint readers, 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 is stored in the user's TNX WebAuthn+ mobile app (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 everything works:
  • Authentication
  • Distributed Ledger
  • Funds Transfer
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 a direct Java Script method call.  The browsers also need to support "Session Specific Pairing"; more info about this can found in the section on WebAuthn+.
Even now, the WebAuthn+ process is more secure and convenient than SMS authentication codes or any other 2FA process.
You can test this for yourself.  Install the TNX WebAuthn+ 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.  Excluding attacks against the operating systems, 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, relying on users to check the address bar in their browsers is a bad plan.  A better plan is to send the domain name from the web browser to the user's mobile device for programmatic verification.
All that is necessary to make this work is a simple addition to the Web Bluetooth API.  A method needs to be added and this method needs to be run within the browser context:
Every Web Bluetooth service would have a default "DomainNameCharacteristic".  Once this is implemented, excluding attacks against the operating systems, 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 before you can report your smart phone lost or stolen... then the bad actor can access your account.
If a bad actor kidnaps you and attempts to torture you into giving up your password, you will be able to give up a false password which will be a "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 2020 ~ Trust Nexus, Inc.
All technologies described here in are "Patent Pending".