The Qualcomm Wireless Edge Services (QWES) Attestation Token
draft-mandyam-rats-qwestoken-00

Abstract

An attestation format based on the Entity Attestation Token (EAT) is described. The Qualcomm Wireless Edge Services (QWES) token is used in the context of device onboarding and authentication. It is verified in the same manner as any CBOR Web Token (CWT).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 3, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. EAT Compliant Claims in QWES Token
• 2.1. OEM ID
• 2.2. nonce
• 3. QWES Token Augmentation to EAT
• 3.1. DevID
• 3.2. HWVer
• 3.3. Context
• 3.4. PKHash
• 3.5. SPID
• 3.6. QSEEVersion
• 3.7. FWVersion
• 3.8. Security State
• 3.9. CSR
• 3.10. AppData
• 4. Example
• 5. IANA Considerations
• 6. Normative References
• Authors' Addresses

1. Introduction

A description of the Qualcomm Wireless Edge Services (QWES) attestation token is provided. QWES allows for service providers to manage devices that implement Qualcomm semiconductor solutions. Based on the EAT-compliant attestation token (see [I-D.ietf-rats-eat]) produced in a trusted execution environment (TEE), a service provider can verify the device identity in addition to several other security-impacting characteristics.

2. EAT Compliant Claims in QWES Token

Certain claims defined for EAT are leveraged in the QWES token.

2.1. OEM ID

The QWES token makes use of an OEM ID. However, the type is a uint (not a bstr as per the EAT specification).

2.2. nonce

The QWES token can carry a nonce. The nonce is a bstr.

3. QWES Token Augmentation to EAT

Several claims have been defined that are not currently present in the EAT base set to complete the QWES token.

3.1. DevID

The DevID is a 256-bit bstr that serves as a device identifier. It differs from the ueid (Universal Entity ID) defined in the EAT specificaation. A specific device ID can be created for ISV's based on their identifier combined with a salt. This allows for a certain level of privacy preservation. Note that the RAND option for ueid may be a suitable substitute for this claim.

3.2. HWVer

This is a bstr claim that distinguishes different system-on-chip (SoC) models.

3.3. Context

This is a numerical (uint) index that denotes the context of the attestation. The current values defined (0-4) are: on-demand attestation, registration, provisioning, certificate issuance and proof-of-possession.

3.4. PKHash

This is a bstr containing a SHA-256 hash of a public key provisioned by the OEM. It can be used optionally in place of an OEM ID.

3.5. SPID

This is a numerical (uint) identifier of the service provider associated with the QWES token. The EAT specification's origination claim can be a suitable substitute.

3.6. QSEEVersion

This is tstr that designates the TEE version ("QSEE" = Qualcomm Secure Execution Environment).

3.7. FWVersion

This is tstr that designates the firmware version specifically dedicated to bootstrapping.

3.8. Security State

This is tstr that contains the state of one-time programmable (OTP) memory. Bits in this field will be set as per the security-impacting section of the OTP memory. The relevant bits in OTP would normally be used to control secure boot enablement, debug disablement, debug enablement parameters, and the state of device keys (i.e. whether they are locked for reading or writing).

3.9. CSR

A Certificate Signing Request (CSR) may be carried in a QWES token as a bstr. This allows for a CA (certifying authority) to verify an attestation and provide a certificate without an extra round trip. This is an optional claim.

3.10. AppData

This is a bstr containing a hash of the associated application data. Since the QWES token can be service provider-specific, the hash that is returned can correspond to the corresponding user space application that invoked the generation of the attestation token. This is an optional claim.

4. Example

A sample QWES token payload is shown. It would be signed and/or encrypted as per COSE guidelines.

          
{
  / DevID /                     h'0a',
  / OEMID /                     32,
  / HWVer /                     h'0e',
  / Context /                   2, / provisioning /
  / SPID /                      10,
  / Nonce /                     h'da378321bb'
}            
            
        

Sample QWES Token Payload

5. IANA Considerations

This memo includes no request to IANA.

6. Normative References

Authors' Addresses