Inline Encryption Engine for SoC Resource Domain Isolation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional inline encryption techniques fail to securely protect data across resource domains in a system-on-a-chip (SoC) due to inadequate consideration of resource domain identity, leading to potential exposure of sensitive data when stored externally, as they rely solely on address-based cryptographic bindings which can become desynchronized across power, clock, or reset events.
Innovation Solution
Implementing an inline encryption engine within the SoC that automatically selects cryptographic keys, modes, and context components based on resource domain and address, ensuring transparent encryption and decryption transactions across multiple memory locations, thereby isolating secure storage for each domain without software overhead and maintaining data integrity across different resource domains.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If traditional address-based cryptographic bindings are used for data encryption, then encryption simplicity is maintained, but data security across resource domains deteriorates due to address desynchronization across power, clock, or reset events
Solution Approach 1:
The patent changes the cryptographic binding parameter from address alone to a composite parameter including resource domain identifier. This allows the encryption to remain simple in structure while significantly improving security by tying encryption to the immutable resource domain identity rather than volatile addresses that can desynchronize across power, clock, or reset events.
Solution Approach 2:
The patent segments the cryptographic binding into multiple components: resource domain identifier and address. By separating these binding elements, the system can use the stable resource domain identifier for security-critical bindings while maintaining address-based routing, thus resolving the contradiction between simplicity and security.
2Reliability
If dedicated encryption engines are allocated for each memory type, then encryption security is improved, but device complexity and resource overhead increase
Solution Approach 1:
The patent makes the encryption engine universal by allowing it to service multiple memory types (DDR, non-volatile memory) through resource domain-based routing. A single encryption engine can handle encryption for different memory types as long as the resource domain identifier and address combination is unique, eliminating the need for separate dedicated engines for each memory type while maintaining security.
Solution Approach 2:
The patent introduces resource domain identifier as an intermediary that mediates between multiple memory types and the encryption engine. This intermediary enables a single encryption engine to securely service multiple memory types by providing domain-specific context without requiring dedicated engines for each memory type.
3Reliability
If resource domain-based cryptographic binding is implemented, then data isolation security is improved, but encryption system complexity increases due to additional context components
Solution Approach 1:
The patent performs preliminary action by establishing resource domain identifiers and their associated cryptographic bindings before data encryption occurs. The resource domain controller pre-configures the binding between resource domain identifiers and cryptographic parameters, so that when encryption is needed, the system can directly use the pre-established bindings without complex real-time calculations, thus improving data isolation while managing complexity.
Data Source
AI summary
A method of encrypting data on a memory device includes receiving a memory transaction request at an inline encryption engine coupled between a processing core and switch fabric in a system on a chip (SOC). The memory transaction request includes a context component and a data component. The context component is analyzed to determine whether the data component will be stored in an encrypted memory region. If the data component will be stored in an encrypted memory region, the data component is encrypted and communicated to a location in the encrypted memory region. The location is based at least on the context component.