Product

Strengthening Industry Authentication Standards with the TPM

Written By
Monty Wiseman
Published On
Apr 14, 2022

Using (and strengthening) OIDC: An Industry-Standard Protocol

A TPM (or Trusted Platform Module) is an industry standard component that protects keys that can be used for authentication. A TPM is typically implemented as a hardware-based device, but other implementations are possible. 

The important property of TPMs is that the private key is protected from even the lowest level of the operating system. This property protects a TPM key from phishing and other attacks that may expose it. It is available on most PCs, networking equipment, and industrial controllers. 

The TPM can do many things, but for this blog we will focus on how it creates and stores private keys we use to authenticate the user. This capability is what Beyond Identity uses to strengthen the existing OIDC (OpenID Connect) protocol.

Learn how Beyond Identity connects and uses existing standards to improve the convenience and security of user authentication.

What is OIDC and what is the relation to OAuth?

OIDC defines the format and protocol of the information needed to authenticate a user without the need to share authentication material, such as passwords. 

OIDC is an authentication protocol that works atop of OAuth 2.0, also an industry-standard protocol. OIDC provides the authentication token used by OAuth. While the actual method used to authenticate the use is not defined by OIDC, most implementations use passwords or removable tokens, such as Yubikey. Even using OIDC, passwords and portable keys have inherent risks.

How Beyond Identity connects the dots between the TPM, OIDC, and OAuth?

The takeaway from above is that TPM-backed private keys can be used for authentication in the OIDC protocol. Beyond Identity uses this approach in our passwordless multi-factor authentication (MFA) solution.

Now we’ll discuss in more detail how exactly Beyond Identity uses the TPM to provide better security and stronger identity assurance when used with the existing OIDC standard.

Step one: Beyond Identity binds the individual to their device

When a user enrolls with Beyond Identity, the authenticator requests the TPM inside the user’s device to create public-private keys. 

This is done with the “tpm2_create” command, which generates both halves of a public-private key pair. The TPM protects the private key while in use and encrypts the actual private key when not in use.

At the same time, a certificate for the public portion of the key is created. This certificate binds the user who owns the device to that TPM-protected key pair. 

Step two: the online service requires authorization from the user

The online service will use OAuth protocols to provide the user’s authorization to use the user’s resources. However, OAuth only provides authorization, not user authentication: that is the role of OIDC. (As the user is authenticated by OIDC, not OAuth; a description of OAuth is outside the scope of this description.)

In the OIDC protocol, a relying party initiates a request to an OIDC Provider. OIDC defines the protocol and data formats for the OIDC Provider to return an OIDC Token. This token provides proof to the relying party that the user was authenticated to the OIDC Provider. This token does not contain any of the user’s secrets — thus providing the protection of the user’s authentication credentials.

OIDC does not define how the OIDC Provider authenticates the user. As stated above, they often use passwords or removable tokens such as YubiKeys. On the other hand, Beyond Identity is an OIDC Provider that uses the device’s built-in TPM.

Step three: the TPM proves the user’s Identity using the TPM-protected private key

Beyond Identity — as the OIDC Provider — issues a challenge to the user’s device (the user’s device has the Beyond Identity Authenticator app already installed, of course.) The Beyond Identicator Authenticator sends the challenge to the TPM, which is then signed by the user’s TPM-protected private key. 

The signed challenge is returned to Beyond Identity, and is verified against the already provisioned user’s public key. Beyond Identity, acting as a standard OIDC Provider, will produce a standard OIDC Token. 

All protocols are industry standard.

Beyond Identity: secure authentication by connecting industry standards

Beyond Identity connects existing standards together to increase the security of user authentication to online services.

With user-specific asymmetric keys stored and protected by the TPM on the user’s device (i.e., their PC), Beyond Identity authenticates the user. The benefit of asymmetric keys is that the “secret” that authenticates the user is never exposed. The TPM signs a challenge using the unique user-specific key. Beyond Identity also signs information about the device’s security posture allowing high assurance evaluation of the device’s security posture against a customer defined policy. 

In summary, the TPM provides high assurance of protection of the private key that’s used in the industry-standard protocol OIDC. 

  • OIDC defines both the information and format of the authentication payload — and the mechanisms to transport that information and format. 
  • Beyond Identity uses TPM-protected keys to sign challenges providing proof of the user’s identity (i.e authentication) then issues an industry standard OIDC Token.

See how Beyond Identity uses industry standards for interoperability and improves security through transparency.

Get started with Device360 today
Weekly newsletter
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.

Strengthening Industry Authentication Standards with the TPM

Download

Using (and strengthening) OIDC: An Industry-Standard Protocol

A TPM (or Trusted Platform Module) is an industry standard component that protects keys that can be used for authentication. A TPM is typically implemented as a hardware-based device, but other implementations are possible. 

The important property of TPMs is that the private key is protected from even the lowest level of the operating system. This property protects a TPM key from phishing and other attacks that may expose it. It is available on most PCs, networking equipment, and industrial controllers. 

The TPM can do many things, but for this blog we will focus on how it creates and stores private keys we use to authenticate the user. This capability is what Beyond Identity uses to strengthen the existing OIDC (OpenID Connect) protocol.

Learn how Beyond Identity connects and uses existing standards to improve the convenience and security of user authentication.

What is OIDC and what is the relation to OAuth?

OIDC defines the format and protocol of the information needed to authenticate a user without the need to share authentication material, such as passwords. 

OIDC is an authentication protocol that works atop of OAuth 2.0, also an industry-standard protocol. OIDC provides the authentication token used by OAuth. While the actual method used to authenticate the use is not defined by OIDC, most implementations use passwords or removable tokens, such as Yubikey. Even using OIDC, passwords and portable keys have inherent risks.

How Beyond Identity connects the dots between the TPM, OIDC, and OAuth?

The takeaway from above is that TPM-backed private keys can be used for authentication in the OIDC protocol. Beyond Identity uses this approach in our passwordless multi-factor authentication (MFA) solution.

Now we’ll discuss in more detail how exactly Beyond Identity uses the TPM to provide better security and stronger identity assurance when used with the existing OIDC standard.

Step one: Beyond Identity binds the individual to their device

When a user enrolls with Beyond Identity, the authenticator requests the TPM inside the user’s device to create public-private keys. 

This is done with the “tpm2_create” command, which generates both halves of a public-private key pair. The TPM protects the private key while in use and encrypts the actual private key when not in use.

At the same time, a certificate for the public portion of the key is created. This certificate binds the user who owns the device to that TPM-protected key pair. 

Step two: the online service requires authorization from the user

The online service will use OAuth protocols to provide the user’s authorization to use the user’s resources. However, OAuth only provides authorization, not user authentication: that is the role of OIDC. (As the user is authenticated by OIDC, not OAuth; a description of OAuth is outside the scope of this description.)

In the OIDC protocol, a relying party initiates a request to an OIDC Provider. OIDC defines the protocol and data formats for the OIDC Provider to return an OIDC Token. This token provides proof to the relying party that the user was authenticated to the OIDC Provider. This token does not contain any of the user’s secrets — thus providing the protection of the user’s authentication credentials.

OIDC does not define how the OIDC Provider authenticates the user. As stated above, they often use passwords or removable tokens such as YubiKeys. On the other hand, Beyond Identity is an OIDC Provider that uses the device’s built-in TPM.

Step three: the TPM proves the user’s Identity using the TPM-protected private key

Beyond Identity — as the OIDC Provider — issues a challenge to the user’s device (the user’s device has the Beyond Identity Authenticator app already installed, of course.) The Beyond Identicator Authenticator sends the challenge to the TPM, which is then signed by the user’s TPM-protected private key. 

The signed challenge is returned to Beyond Identity, and is verified against the already provisioned user’s public key. Beyond Identity, acting as a standard OIDC Provider, will produce a standard OIDC Token. 

All protocols are industry standard.

Beyond Identity: secure authentication by connecting industry standards

Beyond Identity connects existing standards together to increase the security of user authentication to online services.

With user-specific asymmetric keys stored and protected by the TPM on the user’s device (i.e., their PC), Beyond Identity authenticates the user. The benefit of asymmetric keys is that the “secret” that authenticates the user is never exposed. The TPM signs a challenge using the unique user-specific key. Beyond Identity also signs information about the device’s security posture allowing high assurance evaluation of the device’s security posture against a customer defined policy. 

In summary, the TPM provides high assurance of protection of the private key that’s used in the industry-standard protocol OIDC. 

  • OIDC defines both the information and format of the authentication payload — and the mechanisms to transport that information and format. 
  • Beyond Identity uses TPM-protected keys to sign challenges providing proof of the user’s identity (i.e authentication) then issues an industry standard OIDC Token.

See how Beyond Identity uses industry standards for interoperability and improves security through transparency.

Strengthening Industry Authentication Standards with the TPM

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

Using (and strengthening) OIDC: An Industry-Standard Protocol

A TPM (or Trusted Platform Module) is an industry standard component that protects keys that can be used for authentication. A TPM is typically implemented as a hardware-based device, but other implementations are possible. 

The important property of TPMs is that the private key is protected from even the lowest level of the operating system. This property protects a TPM key from phishing and other attacks that may expose it. It is available on most PCs, networking equipment, and industrial controllers. 

The TPM can do many things, but for this blog we will focus on how it creates and stores private keys we use to authenticate the user. This capability is what Beyond Identity uses to strengthen the existing OIDC (OpenID Connect) protocol.

Learn how Beyond Identity connects and uses existing standards to improve the convenience and security of user authentication.

What is OIDC and what is the relation to OAuth?

OIDC defines the format and protocol of the information needed to authenticate a user without the need to share authentication material, such as passwords. 

OIDC is an authentication protocol that works atop of OAuth 2.0, also an industry-standard protocol. OIDC provides the authentication token used by OAuth. While the actual method used to authenticate the use is not defined by OIDC, most implementations use passwords or removable tokens, such as Yubikey. Even using OIDC, passwords and portable keys have inherent risks.

How Beyond Identity connects the dots between the TPM, OIDC, and OAuth?

The takeaway from above is that TPM-backed private keys can be used for authentication in the OIDC protocol. Beyond Identity uses this approach in our passwordless multi-factor authentication (MFA) solution.

Now we’ll discuss in more detail how exactly Beyond Identity uses the TPM to provide better security and stronger identity assurance when used with the existing OIDC standard.

Step one: Beyond Identity binds the individual to their device

When a user enrolls with Beyond Identity, the authenticator requests the TPM inside the user’s device to create public-private keys. 

This is done with the “tpm2_create” command, which generates both halves of a public-private key pair. The TPM protects the private key while in use and encrypts the actual private key when not in use.

At the same time, a certificate for the public portion of the key is created. This certificate binds the user who owns the device to that TPM-protected key pair. 

Step two: the online service requires authorization from the user

The online service will use OAuth protocols to provide the user’s authorization to use the user’s resources. However, OAuth only provides authorization, not user authentication: that is the role of OIDC. (As the user is authenticated by OIDC, not OAuth; a description of OAuth is outside the scope of this description.)

In the OIDC protocol, a relying party initiates a request to an OIDC Provider. OIDC defines the protocol and data formats for the OIDC Provider to return an OIDC Token. This token provides proof to the relying party that the user was authenticated to the OIDC Provider. This token does not contain any of the user’s secrets — thus providing the protection of the user’s authentication credentials.

OIDC does not define how the OIDC Provider authenticates the user. As stated above, they often use passwords or removable tokens such as YubiKeys. On the other hand, Beyond Identity is an OIDC Provider that uses the device’s built-in TPM.

Step three: the TPM proves the user’s Identity using the TPM-protected private key

Beyond Identity — as the OIDC Provider — issues a challenge to the user’s device (the user’s device has the Beyond Identity Authenticator app already installed, of course.) The Beyond Identicator Authenticator sends the challenge to the TPM, which is then signed by the user’s TPM-protected private key. 

The signed challenge is returned to Beyond Identity, and is verified against the already provisioned user’s public key. Beyond Identity, acting as a standard OIDC Provider, will produce a standard OIDC Token. 

All protocols are industry standard.

Beyond Identity: secure authentication by connecting industry standards

Beyond Identity connects existing standards together to increase the security of user authentication to online services.

With user-specific asymmetric keys stored and protected by the TPM on the user’s device (i.e., their PC), Beyond Identity authenticates the user. The benefit of asymmetric keys is that the “secret” that authenticates the user is never exposed. The TPM signs a challenge using the unique user-specific key. Beyond Identity also signs information about the device’s security posture allowing high assurance evaluation of the device’s security posture against a customer defined policy. 

In summary, the TPM provides high assurance of protection of the private key that’s used in the industry-standard protocol OIDC. 

  • OIDC defines both the information and format of the authentication payload — and the mechanisms to transport that information and format. 
  • Beyond Identity uses TPM-protected keys to sign challenges providing proof of the user’s identity (i.e authentication) then issues an industry standard OIDC Token.

See how Beyond Identity uses industry standards for interoperability and improves security through transparency.

Strengthening Industry Authentication Standards with the TPM

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

Using (and strengthening) OIDC: An Industry-Standard Protocol

A TPM (or Trusted Platform Module) is an industry standard component that protects keys that can be used for authentication. A TPM is typically implemented as a hardware-based device, but other implementations are possible. 

The important property of TPMs is that the private key is protected from even the lowest level of the operating system. This property protects a TPM key from phishing and other attacks that may expose it. It is available on most PCs, networking equipment, and industrial controllers. 

The TPM can do many things, but for this blog we will focus on how it creates and stores private keys we use to authenticate the user. This capability is what Beyond Identity uses to strengthen the existing OIDC (OpenID Connect) protocol.

Learn how Beyond Identity connects and uses existing standards to improve the convenience and security of user authentication.

What is OIDC and what is the relation to OAuth?

OIDC defines the format and protocol of the information needed to authenticate a user without the need to share authentication material, such as passwords. 

OIDC is an authentication protocol that works atop of OAuth 2.0, also an industry-standard protocol. OIDC provides the authentication token used by OAuth. While the actual method used to authenticate the use is not defined by OIDC, most implementations use passwords or removable tokens, such as Yubikey. Even using OIDC, passwords and portable keys have inherent risks.

How Beyond Identity connects the dots between the TPM, OIDC, and OAuth?

The takeaway from above is that TPM-backed private keys can be used for authentication in the OIDC protocol. Beyond Identity uses this approach in our passwordless multi-factor authentication (MFA) solution.

Now we’ll discuss in more detail how exactly Beyond Identity uses the TPM to provide better security and stronger identity assurance when used with the existing OIDC standard.

Step one: Beyond Identity binds the individual to their device

When a user enrolls with Beyond Identity, the authenticator requests the TPM inside the user’s device to create public-private keys. 

This is done with the “tpm2_create” command, which generates both halves of a public-private key pair. The TPM protects the private key while in use and encrypts the actual private key when not in use.

At the same time, a certificate for the public portion of the key is created. This certificate binds the user who owns the device to that TPM-protected key pair. 

Step two: the online service requires authorization from the user

The online service will use OAuth protocols to provide the user’s authorization to use the user’s resources. However, OAuth only provides authorization, not user authentication: that is the role of OIDC. (As the user is authenticated by OIDC, not OAuth; a description of OAuth is outside the scope of this description.)

In the OIDC protocol, a relying party initiates a request to an OIDC Provider. OIDC defines the protocol and data formats for the OIDC Provider to return an OIDC Token. This token provides proof to the relying party that the user was authenticated to the OIDC Provider. This token does not contain any of the user’s secrets — thus providing the protection of the user’s authentication credentials.

OIDC does not define how the OIDC Provider authenticates the user. As stated above, they often use passwords or removable tokens such as YubiKeys. On the other hand, Beyond Identity is an OIDC Provider that uses the device’s built-in TPM.

Step three: the TPM proves the user’s Identity using the TPM-protected private key

Beyond Identity — as the OIDC Provider — issues a challenge to the user’s device (the user’s device has the Beyond Identity Authenticator app already installed, of course.) The Beyond Identicator Authenticator sends the challenge to the TPM, which is then signed by the user’s TPM-protected private key. 

The signed challenge is returned to Beyond Identity, and is verified against the already provisioned user’s public key. Beyond Identity, acting as a standard OIDC Provider, will produce a standard OIDC Token. 

All protocols are industry standard.

Beyond Identity: secure authentication by connecting industry standards

Beyond Identity connects existing standards together to increase the security of user authentication to online services.

With user-specific asymmetric keys stored and protected by the TPM on the user’s device (i.e., their PC), Beyond Identity authenticates the user. The benefit of asymmetric keys is that the “secret” that authenticates the user is never exposed. The TPM signs a challenge using the unique user-specific key. Beyond Identity also signs information about the device’s security posture allowing high assurance evaluation of the device’s security posture against a customer defined policy. 

In summary, the TPM provides high assurance of protection of the private key that’s used in the industry-standard protocol OIDC. 

  • OIDC defines both the information and format of the authentication payload — and the mechanisms to transport that information and format. 
  • Beyond Identity uses TPM-protected keys to sign challenges providing proof of the user’s identity (i.e authentication) then issues an industry standard OIDC Token.

See how Beyond Identity uses industry standards for interoperability and improves security through transparency.

Book

Strengthening Industry Authentication Standards with the TPM

Phishing resistance in security solutions has become a necessity. Learn the differences between the solutions and what you need to be phishing resistant.

Download the book

By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.