Difference between revisions of "Late Binding Token"

From MgmtWiki
Jump to: navigation, search
(Solutions)
(Solutions)
 
(2 intermediate revisions by the same user not shown)
Line 6: Line 6:
 
# User held key fobs that have very limited functionality other than to carry a private key (aka user [[Credential]] and the ability to sign or decrypt hashes.
 
# User held key fobs that have very limited functionality other than to carry a private key (aka user [[Credential]] and the ability to sign or decrypt hashes.
 
# User held mobile devices like [[Smart Phone]]s that come with a built in [[Trusted Execution Environment]] that can perform the same function.
 
# User held mobile devices like [[Smart Phone]]s that come with a built in [[Trusted Execution Environment]] that can perform the same function.
 +
One rather interesting cross-over use of the [[Smart Phone]] as the source of trusted authentication replacing the user held key fobs is described in [https://security.googleblog.com/search/label/android%20security this use of Android phones] as the second factor. "On Chrome OS, macOS, and Windows 10 devices, we leverage the Chrome browser to communicate with your Android phone’s built-in security key over Bluetooth using [https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html FIDO’s CTAP2] protocol. On iOS devices, Google’s Smart Lock app is leveraged in place of the browser."
  
 
==Problems==
 
==Problems==
Line 16: Line 17:
 
The exact form of the [[Late Binding Token]] is widely variable from [[Smart Card]]s to [[TPM]] buried inside of a [[Smart Phone]] or other computing device. Existing solutions tend to be bound only to a single service provider, they would not be considered to be [[Late Binding Token]]s. The two most common implementations are:
 
The exact form of the [[Late Binding Token]] is widely variable from [[Smart Card]]s to [[TPM]] buried inside of a [[Smart Phone]] or other computing device. Existing solutions tend to be bound only to a single service provider, they would not be considered to be [[Late Binding Token]]s. The two most common implementations are:
 
# Portable key fob that can interface to a variety of devices with USB or Bluetooth protocols. Most often these use [[FIDO U2F]] or [[Web Authentication]] protocols.
 
# Portable key fob that can interface to a variety of devices with USB or Bluetooth protocols. Most often these use [[FIDO U2F]] or [[Web Authentication]] protocols.
# Portable devices that contain a [[Trusted Execution Environment]] with in them, often in the form of a TPM.
+
# Portable devices that contain a [[Trusted Execution Environment]] within them, often in the form of a TPM.
 +
But it is also true that some [[Smart Phone]]s, [https://security.googleblog.com/search/label/android%20security like Android] can be programmed to look like a simple key fob.
  
 
==References==
 
==References==

Latest revision as of 14:29, 23 July 2019

Full Title or Meme

A Security Token that can be bound to a Site after it has been shipped to theUser.

Context

There are two broad classifications of Late Binding Tokens.

  1. User held key fobs that have very limited functionality other than to carry a private key (aka user Credential and the ability to sign or decrypt hashes.
  2. User held mobile devices like Smart Phones that come with a built in Trusted Execution Environment that can perform the same function.

One rather interesting cross-over use of the Smart Phone as the source of trusted authentication replacing the user held key fobs is described in this use of Android phones as the second factor. "On Chrome OS, macOS, and Windows 10 devices, we leverage the Chrome browser to communicate with your Android phone’s built-in security key over Bluetooth using FIDO’s CTAP2 protocol. On iOS devices, Google’s Smart Lock app is leveraged in place of the browser."

Problems

There are a few problems that need to be mitigated with Late Binding Tokens.

  1. The Relying Party must be assured that the device is legitimate and did create the message that was sent from the user to validate an interchange.
  2. The user would like to be able to use one token to secure message interchanges with more than one service so they don't get asked to carry multiple tokens.
  3. Some services want to be assured that the user was present during any interchange. This feature is not available with all tokens.

Solutions

The exact form of the Late Binding Token is widely variable from Smart Cards to TPM buried inside of a Smart Phone or other computing device. Existing solutions tend to be bound only to a single service provider, they would not be considered to be Late Binding Tokens. The two most common implementations are:

  1. Portable key fob that can interface to a variety of devices with USB or Bluetooth protocols. Most often these use FIDO U2F or Web Authentication protocols.
  2. Portable devices that contain a Trusted Execution Environment within them, often in the form of a TPM.

But it is also true that some Smart Phones, like Android can be programmed to look like a simple key fob.

References