What is Transitive Trust?

You may well have heard of “transitive trust” when applied to security and in its traditional sense it refers to trust that exists between domains or companies. Let’s start here just to get the basics covered.

• One-way Trust
• A trusts B/ B. does not trust A. 
  ‍
• Two-way Trust
• A trust B / B trusts A. 
  ‍
• Non-transitive Trust
• A trusts B but does not allow that trust to be extended. It finishes at B. 
  ‍
• Transitive Trust
•  A trusts B, B trusts C, so A also trusts C and C also trusts A.

‍

‍

Now, how about in the context of authentication? AuthN by IDEE uses these basic principles as the building blocks for a secure authentication architecture and indeed the entire identification lifecycle (Registration, Authentication, Adding a Device, Account Recovery & Off-boarding). This is important. It is important because the entire identity lifecycle must be considered to make a truly phish-proof MFA (Multi Factor Authentication) solution, and not just fall back on phishable factors outside of the act of authentication itself. 

Let’s take a look. 

Transitive Trust Consists of Four Key Elements

In the case of AuthN by IDEE, when we talk about transitive trust, we are talking about these four elements.

1. Trusted service - the integrity of the service the user is accessing needs to be established to ensure its not a fake service impersonating the real service. 
2. Trusted device - the reliability of the device from which a transaction is carried out must be known and its integrity verified. 
3. Trusted user - the identity of the user who carried out the transaction must be securely authenticated and verified. The user needs to be in total control of the trusted device to approve a transaction carried out on a trusted service using authentication factors that cannot be phished, stolen and/or circumvented by an attacker. 
4. Trusted credential - a credential that cannot be phished, stolen and/or circumvented. 

Applying all four attributes, means that a transaction can only be carried out on a “trusted service” by a “trusted device” coupled to a “trusted user” and authorized under the “user’s total control.” 

‍As we mentioned in the introduction, transitive trust must be incorporated into the entire identity lifecycle from account registration to termination. Here’s a closer examination of what that looks like. 

 MFA Registration with Transitive Trust

When first setting up AuthN by IDEE, the registration process forms the basis of transitive trust. You must first register on a trusted service (such as Microsoft 365). It is a quick and effortless process. Here is what is going on in the background during the registration process and how it all works:

1. To register on a service, the user identity is validated and verified either by proving possession and control of the assumed identity or by an admin who can vouch for the authenticity of the user's identity. 
2. Once the user’s identity has been verified, authenticator factors are established for the user for that specific service tied to the user device.
3. The authentication factors are based on public key cryptography and inherence and/or knowledge (for example, in the case of AuthN by IDEE, we ask users to unlock their device as per their preferred configuration, PIN, Face ID, Thumb Print).  
4. The credential (cryptographic private key) is securely provisioned on the trusted user’s device. It is stored in a secure enclave and/or TPM (Trusted Platform Module) in a way that it is impossible to be removed from the device or stolen by a cybercriminal.  
5. The registered cryptographic key is cryptographically bound to the trusted service and the device so that the key can only be used on that service from that trusted device under the user's authorisation. 

‍

‍

MFA Authentication with Transitive Trust  

The trust established at registration is explicitly transited to the authentication process. This is how it works:

1. The user must initiate access to the trusted service from the user's trusted device. 
2. The user's credentials (private key) must be explicitly authorised by the user using either inherence or knowledge factor locally on the trusted device to generate a response to the authentication request from the trusted service. As with registration this means the user unlocking their device. 
3. Upon the user's authorisation, the private key signs a verifiable proof of possession and control of not just the key but also the trusted device at that point in time. 
4. The verifiable proof is independently verified by the trusted service to ensure the integrity, authenticity, and provenance of not just the user identity but also, the device on which the user authorised the transaction to grant the user access to the requested service.

‍

‍

Making Another Device a Trusted Authenticator Device with Transitive Trust: 

To provision an additional trusted device to the user account, the user must explicitly authorise the additional device with security strength that is equivalent to that of authentication. 

1. The user must initiate the process of adding a new device to the trusted service from the user's already trusted device. 
2. Upon the user's authorisation, the user's private key signs a verifiable proof of possession and control of not just the authorisation key but also the existing trusted device at that point in time. 
3. The verifiable proof is independently verified to ensure the integrity, authenticity, non-repudiation, and provenance of not just the new device authorisation but also, the device on which the user authorised the new device.  
4. If the transitivity is satisfactory, the new authorised device becomes a trusted device which the user could use to authorise subsequent transactions. 

‍

Account Recovery with Transitive Device: 

If the established existing transitive trust can no longer be proved (e.g., the user lost the trusted device) then the user must undergo identity proofing as in the registration process to establish and verify their identity and trust on a new device coupled to the trusted service. 

At every step of the user identity lifecycle, transitive trust ensures that a transaction was carried out on a “trusted service” by a “trusted device” coupled to “trusted user” and authorised under the “user’s total control.” This makes the AuthN by IDEE MFA solution’s architecture immune to credential phishing and all password-based attacks including AiTM (Adversary in The Middle).