USB Controller Binding Identity Policy Enforcement

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current computing devices lack secure enforcement of USB device policies, especially when untrusted software is present, as they do not effectively protect I/O data across the on-chip boundary and cannot ensure that only authorized software restricts device usage.

Innovation Solution

A computing device that generates a binding identity within a firmware secure enclave, securely provisions it to a USB controller, and uses a policy enforcement enclave to enforce device usage policies by verifying the identity in each command, ensuring only trusted software can restrict device usage, even in the presence of untrusted operating systems.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If USB device policies are enforced without secure enclave binding identity verification, then device operation is simple and fast, but security is compromised and unauthorized software can restrict device usage

Engineering Contradiction:
ImproveUSB device policy enforcement securityVSAvoidUSB controller structure
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements a nested security architecture where a binding identity is embedded within the USB controller's secure enclave, and policy enforcement commands are nested within authenticated message structures. The binding identity contains cryptographic credentials that are nested within the controller's secure memory, creating multiple layers of verification that enhance security without proportionally increasing external complexity.

Inventive Principle:
Principle #7Nested doll (Nesting)

Solution Approach 2:

The patent introduces a binding identity as an intermediary credential between the USB controller and policy enforcement software. This binding identity acts as a mediator that verifies the authenticity of policy commands without requiring the controller to directly trust the software, thus enhancing security while maintaining a relatively simple control flow.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If I/O data is allowed to move across the on-chip boundary without cryptographic protection, then data transfer speed is high, but data integrity and confidentiality are compromised

Engineering Contradiction:
ImproveI/O data integrityVSAvoidI/O data transfer speed
Core Design Contradiction:
ReliabilityVSSpeed

Solution Approach 1:

The patent applies preliminary cryptographic protection by sealing the binding identity with a cryptographic key before the I/O data transfer occurs. This pre-established security credential is then used to authenticate and protect the data during transit across the on-chip boundary, ensuring integrity without adding real-time encryption overhead that would slow down the actual data transfer.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If USB device policies are enforced without binding identity verification, then software can freely restrict device usage, but authorized software cannot be distinguished from untrusted software

Engineering Contradiction:
ImprovePolicy enforcement capabilityVSAvoidSoftware authorization trust
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent uses cryptographic binding identities as a form of digital 'coloring' or identification marker that distinguishes authorized software from untrusted software. The binding identity acts as a unique credential that changes the trust status of software, allowing the system to differentiate between authorized policy enforcement commands and unauthorized attempts, thus enabling reliable policy enforcement.

Inventive Principle:
Principle #32Color changes

4Reliability

If secure enclave binding identity verification is implemented, then only authorized software can enforce policies, but the system requires additional cryptographic verification steps

Engineering Contradiction:
ImprovePolicy enforcement authorizationVSAvoidCommand verification time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The binding identity is established and verified in advance during system initialization or device attachment, rather than being verified for every single command. This preliminary verification creates a trusted state that persists through subsequent operations, reducing the time overhead for individual policy enforcement commands while maintaining strong authorization guarantees.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS10824766B2Technologies for authenticated USB device policy enforcement
Publication Date: 2020.11.03 INTEL CORP
  • US10824766B2 patent drawing
  • US10824766B2 patent drawing
  • US10824766B2 patent drawing

AI summary

Technologies for USB device policy enforcement include a computing device having a USB controller and secure enclave support. On boot, a firmware enclave randomly generates a binding identity and then securely provisions the binding identity to the USB controller. The firmware enclave also seals the binding identity to a policy enforcement enclave. At runtime, the policy enforcement enclave unseals the binding identity and includes the binding identity in a policy enforcement command sent to the USB controller. The USB controller verifies that the binding identity included in the command matches the binding identity that was previously provisioned. If the binding identities are successfully verified, the USB controller enforces the command. The USB controller may block data transfers or device configuration changes for one or more specified devices. Each of the firmware enclave and the policy enforcement enclave are trusted execution environments. Other embodiments are described and claimed.