Trustworthy Authentication
is defined as: “end-to-end zero-trust channel affinity that affirms verified user presence, identity, and intent to a relying party.”
AffirmID using FIDO Direct protocol provides trustworthy authentication.
This three-minute read introduces how “AffirmID” consistently provides trustworthy authentication results.
To organize a hands-on demo of AffirmID, including its AffirmIdP cloud identity provider service using FIDO Direct to connect with AffirmID Auth authenticator cell phone app, contact ProteqsIT via the phone number or email address listed above.
- Push – A mobile notification protocol adapted for authenticator use and best known for its simple one-tap authentication approval interface.
- CBA – Certificate-Based Authentication, which means a public key encrypted authentication challenge is signed by a device using its private key counterpart thereby establishing a trusting bond between client and user device. Its use is a statement of possession, not one of identity.
- FIDO – Fast Identity Online, a standard for authenticators published by the FIDO Alliance. FIDO2 is the second generation of a standard that defines an implementation of CBA.
- FIDO Direct– a novel adaptation of the Push like authentication but with enhanced security and benefits of FIDO2.
- One-Time-Pad (OTPad) – a type of cryptography in which a randomly generated 128-bit AES key is used only once before being discarded.
- AES – Advanced Encryption Standard as defined by the US government, also known as a symmetric block cipher and thought to be practically impossible to decipher.
- One-Time-Password (OTP) – a 6-to-8-character code generated by a standard algorithm using a random secret.
- 2FA – two factor authentication, in which one authenticator factor is supplemented by another, most commonly a password supplemented by an OTP code.
- MFA – multi-factor authentication, which typically refers to two or more user authentication factors of the following types: something you know, something you have, and something you are.
- MiTM – Man-in-the-middle is a type of cyberattack in which the exchange of user authentication messaging is intercepted and exploited maliciously by the attacker.
- MiTB – man-in-the-browser is similar to MiTM, except that the browser is infected with malicious functions that intercept and manipulate user authentication messaging as it flows via the browser between the authenticator device and the relying party.
- RC2 – AffirmID has finished development, testing, and certification and is ready for client usage as of Release Candidate 2.
What is AffirmID?
A concept based on the principle that zero-trust authentication must start with user identity confirmation. Affirmed identification based on recognizing the user exclusively. Affirmed identification as the first step in the authentication procedure. Affirmed identification that is a pre-condition authenticator use. That’s what “AffirmID” is. I am so confident in this concept that I developed market-ready proof-of-concept applications confirming its validity.
Proof of concept components include:
- AffirmIdP – an Identity Provider interacts with AffirmID Auth app providing account registration and maintenance, and authentication services to authenticator app using FIDO Direct protocol.
- AffirmID Auth – A FIDO2 app providing authentication service facilities and account registration and maintenance one user identity is recognized by its semi-automatic biometric identity verifier. It interacts with an identity provider by use of FIDO Direct protocol.
- FIDO Direct– a unique and very secure protocol facilitating FIDO2 registration and attestation, and FIDO2 authentication and asertion of device and app identity.
What do you mean by trustworthy authentication?
Can you say with certainty that the person granted authenticated access to your organization's network is who they claim to be? If you replied YES, you are either an exception or being dishonest with yourself. If NO, then a three-minute perusal of the following may prove rewarding and perhaps contribute to eventually trusting your authentication solution.
What is an 'AffirmIdP' identity provider?
As a NuGet package, AffirmIdP is compatible with most modern backend services, particularly those of IDP and IAM providers. Any cloud or on-premises authentication service can benefit from this solution, which provides authentication trust that has previously been difficult to establish.
AffirmIdP API at a glance:
- Pre-configured or ad-hoc created user accounts are populated during AffirmID Auth registration with user identity verification, email account identifier, verified of course, and FIDO2 account attestation.
- Offered are multiple APIs for account management and maintenance and authentication.
- The authenticate API is passed an account identifier, normally a verified email address, to authenticate the person owing or assigned to the selected account.
- With that the API performs a complete and very secure authentication ceremony in which the account user identity is verified and their intent to authenticate captured from a single screen tap on their cell phone
- The ceremony completes with receipt of FIDO2 assertion of both app and device identity.
- Results are returned in response to the API request. It may suggest a positive response, a timeout, a negative response (user declined the offer), or a warning of potential tampering.
What is the 'AffirmID Authenticator' app?
It is a free FIDO2 authenticator app for Android and iPhone cell phones. Even though it was made to work with FIDO2 over Bluetooth at first, its focus was changed to FIDO2 over ``FIDO Direct`` to help achieve zero-trust goals. The app supports a number of unique features, not the least of which is its semi-automatic user identity recognition and verification facility based on the biometrics of how the user uses their cell phone.
What is 'FIDO Direct'?
To ensure trustworthy authentication, we must verify affinity between the app and the user account. To do so with zero-trust confidence, we selected to use FIDO2 but with a reduced attack surface. With an eye towards the user benefit of mobile push, we shamelessly adopted its notification UI concept, but without the risks associated with a mobile push implementation. As a final measure to ensure MiTM avoidance, we implemented one-time-pad cryptography using out-of-band signaling. We opted to employ a reliable protocol that satisfies security needs, offers immediate mobile push like notification, and establishes a zero-trust verifiable direct connection between the application and cloud service. Thus, the vulnerabilities associated with mobile push and FIDO2's reliance on USB, Bluetooth, or NFC connectivity, as well as its reliance on a web browser or other proxy program, and the attack surface they present, were avoided. And so was created what is today known as ``FIDO Direct``.
FIDO2 is an excellent contributor to resolving authentication ceremony difficulties because it reduces the number of false positives. Unfortunately, adopters are forced to rely on proxy components in the message chain between the FIDO2 authenticator and the relying party user account, over which they have no control. Each of these proxy points provides an attack vector that malicious actors can exploit.
Mobile Push authentication has gained popularity due to its usability and inexpensive cost of implementation. It is free and simple to use. It is also fraught with dangers.
FIDO Direct aims to combine the robustness of FIDO2 core with the user experience of Push while avoiding the risks of both. Its protocol is meant to provide a direct streaming connection between the user account maintained by the relying party and a mobile phone authenticator app.
The AffirmIdP – FIDO Direct – AffirmID Auth combination offers simplicity of use, no high risk proxies, and no cell phone configuration requirements that some users detest.
Is AffirmID a 'Zero-Trust Authentication' provider?
Indeed, it is. The results of a quick Google search for ``zero-trust authentication`` are startling, both in terms of the relatively small number of hits and the fact that none of them deliver end-to-end zero-trust authentication. AffirmID does so for every step in the authentication process from verification of user identity to results delivery to a verified relying party.
There are multiple steps in the authentication ceremony, the following listing those of the AffirmID solution:
- Trust but verify identity of the user being authenticated;
- Trust but verify the challenge message received;
- Trust but verify the user’s authenticator;
- Trust but verify the challenge message response; and
- Trust but verify the relying party making the request.
Does AffirmID block phishing attacks?
Currently, there is no technology capable of blocking phishing attacks. Nevertheless, blocking what might result from a phishing attack is not, and this is what the security measures made standard in AffirmID are designed to accomplish.
88888There are multiple steps in the authentication ceremony, the following listing those of the AffirmID solution:
Trust but verify identity of the user being authenticated;
Trust but verify the challenge message received;
Trust but verify the user’s authenticator;
Trust but verify the challenge message response; and
Trust but verify the relying party making the request.
Is AffirmID available for evaluation?
An evaluation package is being prepared at this time and should become available before the end of April ’23.
TBD
What are configurations, availability, and pricing?
As above. to be provided before the end of April '23.
TBD
Is AffirmID covered by patents?
Yes, there is a portfolio of 5 published and one pending patents covering several aspects of the AffirmID proof of concept implementations.
Trustworthiness can only exist with end to end trust.
Establishing verifiable affinity on each leg of the authentication journey and using secure encryption are two essential components to achieve that.
Authentication takes place between two entities known as the “relying party” and the “user”. According to conventional understanding, the relying party is some form of organization having something to safeguard, whereas the user is an individual or a device seeking access to it.
On behalf of the relying party, modern authentication is often coordinated by an Identity Provider service such as AffirmIdP. The relying party, which is often a machine, device, or web accessory such as a browser or app, requests authentication and trusts the IdP to provide reliable results.
Typically, there are two or more hops, shown here as affinity bridges, in the authentication process. There are three when AffirmID is the facilitator of choice. For an attacker, each hop is a potential point of entry and thus each requires attention to detail to prevent such attacks or to mitigate them should they occur.
AffirmID protects each affinity span in three ways: by verifying identity of the person or entity on the opposite side of the span, by judicious use of modern protocols, and by use of strong encryption. For encryption we use the strongest known form, one-time-pad 128-bit AES cryptography, to protect every message crossing the span and of course the most recent TLS standards are employed as well.
Simply put, “behavioral biometrics identity recognition” refers to identifying the AffirmID Auth user based on how they use their cell phone. Automatic assurance that the individual authenticating with a cell phone authenticator is the same person who registered the AffirmID Auth account being used, without the possibility of impersonation.
It is crucial to protect communications between AffirmID Auth and AffirmIdP since here is where cybercriminals concentrate their efforts, frequently using phishing attacks. In order to build a user-friendly and safe Push authentication experience, special primary channel protocol methods are used. All messages are encrypted using session identification keys freshened for each ceremony over out-of-band circuits. Persistent authentication is also made possible in high security applications by the sophisticated protocols employed.
Security of the channels between Relying Party and Identity Provider services in the clouds is rarely thought about, but it is no less important. AffirmID Auth authenticator provisioned with a specific RP PerKey token is used to access the AffirmIdP RP dashboard and RP accounts. All authentication requests and account maintenance needs using the AffirmIdP APIs must use the OAuth 2.0 protocol.
That said, may I ask a rhetorical question?
-
- As an executive of an organization concerned with cyber security, do you trust your current altercation methods?
- As an individual, are you sure the person you are Signal’ing is who you think they are?
Stay tuned, there are several features now in flight to help secure the individuals personal data and accounts.
