Cache Structure with Object Identification Labels for Secure Data Access

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing computer systems face inefficiencies in protecting and managing secure objects' data in shared cache environments, where secure data must be frequently encrypted and decrypted, leading to performance bottlenecks and exposure to unauthorized software access.

Innovation Solution

Implementing an object identification label for each cache line to securely store and manage secure object data in unencrypted form by ensuring only authorized software can access it, using an object-id register to verify ownership and control access, allowing secure data to remain in cache without repeated encryption/decryption across CPU threads and processors.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If secure data is stored in encrypted form in cache, then security is improved, but access speed deteriorates due to frequent encryption/decryption operations

Engineering Contradiction:
ImprovesecurityVSAvoidaccess speed
Core Design Contradiction:
ReliabilityVSSpeed

Solution Approach 1:

The cache is segmented into multiple regions or sets, each associated with specific secure objects. By dividing the cache structure and implementing fine-grained access control at the cache line or set level, the system allows unauthorized software to access only specific segments while permitting fast access to authorized data without full encryption/decryption overhead.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system performs preliminary decryption of secure objects when they are first loaded into cache, and maintains them in decrypted form for subsequent fast accesses. Cache control logic is pre-configured with object identification labels and access permissions, enabling rapid authorization decisions without real-time cryptographic processing.

Inventive Principle:
Principle #10Preliminary action

2Speed

If secure data is stored in unencrypted form in cache, then access speed is improved, but security deteriorates due to exposure to unauthorized software

Engineering Contradiction:
Improveaccess speedVSAvoidsecurity
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

Different cache lines or cache sets are assigned different security attributes and object identification labels. The cache controller applies local access control policies based on the specific security requirements of each cache line, allowing unencrypted storage in authorized contexts while maintaining security boundaries through label-based access control.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The cache controller acts as an intermediary between software and cache data, using object identification labels and access permission checks to mediate access requests. This intermediary layer enables fast access to authorized software while blocking unauthorized access to unencrypted data without requiring continuous encryption.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If frequent encryption and decryption operations are performed, then security is maintained, but system performance deteriorates due to cryptographic overhead

Engineering Contradiction:
ImprovesecurityVSAvoidsystem performance
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

Decryption is performed preliminarily when secure objects are loaded into cache, and the decrypted data is retained for multiple accesses. This eliminates the need for repeated decryption operations during normal access patterns, significantly reducing cryptographic overhead while maintaining security through controlled access mechanisms.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

Once decrypted, secure data remains in unencrypted form in the cache for continuous fast access by authorized software. The cache control logic ensures continuous security through label verification without requiring continuous cryptographic operations, maintaining both performance and security.

Inventive Principle:
Principle #20Continuity of useful action

4Productivity

If cache is shared by multiple processors and threads, then resource utilization is improved, but security deteriorates due to potential access by unrelated processes

Engineering Contradiction:
Improveresource utilizationVSAvoidsecurity
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

Each cache line or cache set is tagged with object identification labels indicating the secure object owner. This local quality differentiation enables the shared cache to simultaneously serve multiple processors and threads with different security requirements, allowing each to access only their authorized data while sharing physical cache resources.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The shared cache is logically segmented into regions associated with different secure objects and owners. The cache controller implements segmentation-based access control, directing access requests to appropriate segments and blocking unauthorized access while maintaining high resource utilization through efficient sharing of authorized access.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS9875193B2Cache structure for a computer system providing support for secure objects
Publication Date: 2018.01.23 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US9875193B2 patent drawing
  • US9875193B2 patent drawing
  • US9875193B2 patent drawing

AI summary

A method (and structure) protects confidentiality and integrity of information in a secure object from other software on the system. An object-id value that identifies software currently executing on a CPU (Central Processing Unit) is stored, the value having a predetermined standard value when software that is not a secure object is executing. Each block of information in the cache is associated with an ownership value that is used to store an identification of the software that owns the information in the block. When software attempts to access information in one of the blocks, the object-id of the currently executing software is compared with the ownership value associated with the block being accessed. Access to the block is allowed if the object-id of the currently executing software matches the ownership value of the block.