Device Integrity supporting User Authentication

Use Case Metadata

Title

Device integrity provided by a claim from a remote device attribute provider to validate the source of user authentication.

Status

Use Case Lifecycle Status

Contributed	Working Draft	Committee Review	Compilation	Approval	Publication
This use case has been approved in version 1.2. This page may have been updated since the 1.2 document was approved.

Use Case AHG Review Status

The Use Case AHG reviewed this use case 2013-07-24. Comments are available on the Discussion Page. All comments were addressed at a UCAHG meeting on December 19, 2013.

Use Case Category

Integrity, Privacy, Compliance, Interoperability

Contributor

Tom Jones

Use Case Content

Use Case Description

Establish an integrity (aka health) claim for a device that, together with other security measures, is good evidence of the integrity of the information exchanged with the user. Today many relying parties do ensure that users can only access their services with devices that are known to be in the possession of the user. This case extends that to allow the relying party to specifically request an integrity claim from the user's device.

Integrity has two meanings in computer security. The first relates to the device not having been changed in any way since it was created. The second relates to the device reliably behaving in an expected manner. In a modern operating system, with vulnerabilities patched every month, the former definition is not practical and so the later definition is the one that applies in this use case.

This use case distinguishes between two actors which are typically conflated in other use cases. The user is a carbon-based life form that has no innate capability to interface to any digital network. The user device is a silicon-based life form that is extremely good at interfacing to the digital networks at high speed, but communicates only a few bits per second to the user with a user experience that is often sub-optimal. For high value resources on the network, the resource owner would like to assure that the data once available on the user device is not leaked to unauthorized users. This is not possible if the resource owner (aka the relying party) does not trust the user's device's integrity with respect to confidential material placed on the device. There are other mechanisms to control data leakage, like remote device wipe, which are to be considered in other use cases.

Actors

• Relying party (RP) in this case is a web service that requires user identity and other attribute information to complete a digital transaction.
• Identity Provider (IdP) for this case contains identity of the user potentially with other attributes.
• User Device is a modern computer system with graphical user interface and internet connectivity.
• Device Attribute Provider (DAP) registers the user device, receives signed status information from the device, can evaluate the status of the device and generate an integrity claim for the device. This provider is called a Remote Attestation Service by some standards-making bodies.
• Individual user in this case is a human being that wants to access a high value web site on the internet.
• User agent is digital process running on a user device and trusted by a user to represent them to other parties in an ID ecosystem.

Goals / User Stories

• The integrity of the device used for authentication of user identity provides the foundation for strong authentication and protection of user privacy.
• RP can prove compliance with regulations that require proof of user intent.
• User can know the device is only presenting the allowed information.
• User identity theft from their personal device is blocked.

Assumptions

• The RP has a relatively clear set of privacy compliance regulations to follow.
• Users are provided sufficient motivation to acquire device integrity information to obtain web services.
• Secure token services (STS) are available in the marketplace to provide user ID (IdP) and device integrity (DAP).
• The user agent has a fiduciary responsibility to the user regardless of where it is run.

Requirements

• Individual users have access to a modern digital device with secure root of trust.
• A minimalist standard taxonomy of data type is presented for user choice.
• The user device is the able to collect credentials from the user and transmit them to the identity provider.
• Claims from the identity provider and attribute providers, including the device attribute provider, can be composed into a bag of claims to be sent to the relying party. In this case the compositing function is provided by the user device.

Process Flow

• The user establishes an account with one or more IdPs.
• The user’s device is registered with a device attribute provider.
• The user accesses a web site which requires identity attributes of some sort to continue to process the user request. That web site then becomes a relying party.
• The RP uses a standard protocol and taxonomy to request the information needed from the user.
• This request for information is intercepted by an agent for the user that can:
  • Determine if the requested information is available,
  • Determine if the user has already authorized release of the requested information to this RP,
  • Display any remaining choices to the user to acquire more attributes or release those already available,
  • Compose user and device claims in a way the RP can evaluate the data,
  • Send the composed claims to the RP who has sole responsibility to determine if sufficient identity and attribute information has been proved to provide the requested access.
  • Repeat these steps until the RP is satisfied or one side gives up and abandons the effort.

File:HealthyDevice.png

• The above figure shows the user agent as a part of the user device. Other implementations are certainly possible. It is responsible for collecting, storing and releasing a collection of claims to the relying party based on informed user consent.
• The Secure Token Service / Device Attribute Provider is called a remote attestation service in some environments. It accepts the information created by the device at boot time in a Trusted Platform Module (TPM) to compare with known good configuration information to attest to the integrity (health) of the device by means of a device attribute claim.

Success Scenario

• Strong authentication (using two factors: user ID plus machine integrity claims) actually improves the security of users on the internet.
• Modern devices in common use for connecting users to the internet already come with a hardware root of trust that can be used to report on the current status of the device is a way that is not susceptible to tampering.
• A device integrity attestation attribute service becomes available in the cloud to the user at little cost to create claims as to the integrity of the user device and to enable easy remediation of an defects found in the device integrity. This service acts like an extension of an antivirus product that be determine if the device is truthfully representing its status.
• The RP gets access to the user identity and device integrity information in claims that are trusted to authorize release of the desired information to the user.

Error Conditions

• User does not have the credentials required by the relying party. Mitigation: the relying party redirects the user to one or more sources of appropriate credentials.
• The device or user agent loses the trust of the RA and hence of the RP. Mitigation: the user must be given actionable steps to get their devices and agents back into compliance. It should never be the case that an “unauthorized” message be transmitted without mitigation steps.

Relationships

• Extended by:
  • Privacy Enhanced by User Agent Use Case at https://www.idecosystem.org/wiki/Privacy_Enhanced_by_User_Agent
  • Privacy Enhancing Technologies at https://www.idecosystem.org/wiki/Privacy_Enhancing_Technologies
• Extension of:

References and Citations

• Page on this wiki Mobile Driver's License
• Privacy Enhancing Technologies are outlined in a companion use case https://www.idecosystem.org/wiki/Privacy_Enhancing_Technologies, which shows various ways to hide the identities of the user and the user device.
• Authenticate Windows Azure with ADFS at http://technet.microsoft.com/en-us/magazine/dn250023.aspx
• Trusted Platform Module at http://www.trustedcomputinggroup.org/developers/trusted_platform_module/specifications
• Endpoint Compliance Profile at http://www.trustedcomputinggroup.org/resources/tnc_endpoint_compliance_profile_specification
• NIST SP 800-164 Hardware-Rooted Security in Mobile Devices at http://csrc.nist.gov/publications/drafts/800-164/sp800_164_draft.pdf
• Cloud Platform Audit and Asset Management using Hardware-based Identities at http://docs.oasis-open.org/id-cloud/IDCloud-usecases/v1.0/cn01/IDCloud-usecases-v1.0-cn01.html#_Toc324801965. This oasis-developed use case describes the companion problem of establishing trust in a cloud provider using a virtual machine environment. The use is very detailed and provides two relevant comparisons to the present use case. First the devices now in development for users often are enabled on virtual machine technology and so can help with the implementation of device integrity of the user device. Second providers of identity and attribute data could directly use the oasis use case to provide proof of their integrity to both the user and to the relying party.

NSTIC Guiding Principles Considerations

Privacy Considerations

Raw device integrity claims typically include information like a public key that can be used to identify the device. In many cases the device is used by one or a small number of users which would allow linkage of this attribute to a user. Like any attribute, the device integrity claim would only be provided if the user authorized its release. It is certainly also possible to use a privacy enhancing technology provider (PETP) to combine all proffered claims into a composite claim with some identity that cannot be linked back to the original user. Where comparison of the device configuration occurs privacy needs to be considered. Comparisons performed at the attribute provider will expose user linkages that need to be disclosed and controlled.

User Experience/Usability Considerations

Existing device integrity solutions require direct involvement of the user in the process of establishing a connection to a Device Attribute Provider. The process must be made easier before user a likely to expend the time or money to create integrity claims for their personal devices. The most natural way to establish this integrity claim is to make it a part of the Anti-malware software installation which many users have enabled.

The best way to motivate the users to maintain the security and integrity of their devices is by monetary incentives or enhanced convenience. This is typically only possible for high value content like current movies or sensitive enterprise data that is only released to devices with known integrity.

Interoperability Considerations

Standards exist from the Trust Computing Group (TCG, see references) for the establishment of a hardware root of trust in a device. These standards are the best interoperability documents at the time this use case was created.