Fork Process Re-Keying for Copy-on-Write Memory Encryption

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing cryptographic computing systems face challenges in securely managing cryptographic keys during process creation, particularly in Unix-like systems where child processes share encryption keys with the parent, leading to vulnerabilities such as replay attacks and key wear-out due to shared keys across multiple processes.

Innovation Solution

Implementing a 'magic marker' system to re-encrypt data objects on copy-on-write, using cryptographic pointers as tweaks, and leveraging memory tagging technologies to manage encryption keys at the data object level, ensuring each child process receives new keys and maintaining data confidentiality.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If child processes share the same encryption keys as parent processes during fork() operations, then process creation is efficient and simple, but security is compromised due to key wear-out and vulnerability to attacks

Engineering Contradiction:
ImprovesecurityVSAvoidkey management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the encryption key management by creating separate key namespaces for parent and child processes. When a fork() operation occurs, the child process receives a copy of the parent's key namespace, but subsequent key generation operations create unique keys for each process. This segmentation allows efficient process creation while ensuring security through key isolation.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements preliminary action by pre-establishing key namespaces before fork() operations and configuring the key management system to automatically handle key separation. The kernel is modified to intercept fork() calls and perform key namespace copying and isolation in advance, so that when child processes are created, they already have their own key contexts, eliminating the need for complex post-fork key management.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If encryption keys are refreshed for each child process, then security is improved, but the complexity of key management and process creation increases

Engineering Contradiction:
ImprovesecurityVSAvoidprocess creation ease
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent implements self-service by making the key management system automatically handle key generation, copying, and isolation during fork() operations without requiring explicit application-level intervention. The modified kernel intercepts fork() calls and performs all necessary key management operations transparently, allowing applications to create processes as usual while security is enforced automatically by the key management infrastructure.

Inventive Principle:
Principle #25Self-service

3Use of energy by moving object

If parent and child processes share physical pages through copy-on-write, then memory efficiency is improved, but encryption security is compromised as both processes can access the same encrypted data with the same keys

Engineering Contradiction:
Improvememory efficiencyVSAvoiddata security
Core Design Contradiction:
Use of energy by moving objectVSReliability

Solution Approach 1:

The patent applies local quality by making encryption keys process-specific while maintaining shared physical pages. Each process (parent and child) has its own key namespace and unique keys, so even though they share the same encrypted data in physical memory, they cannot decrypt it with each other's keys. This allows memory efficiency through sharing while ensuring security through localized key ownership.

Inventive Principle:
Principle #3Local quality

4Device complexity

If the same encryption keys are used across multiple processes, then key management is simplified, but the system becomes vulnerable to brute-force attacks and key wear-out

Engineering Contradiction:
Improvekey management complexityVSAvoidvulnerability to attacks
Core Design Contradiction:
Device complexityVSObject-affected harmful factors

Solution Approach 1:

The patent implements dynamics by making the key management system adaptive to process lifecycle events. Keys are dynamically generated, copied, and isolated based on fork() operations, exec() calls, and process termination. The key management infrastructure automatically responds to process creation and destruction events, ensuring that each active process has appropriate keys while maintaining security through automatic key rotation and isolation.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentEP4202740B1Process object re-keying during process creation in cryptographic computing
Publication Date: 2026.05.06 INTEL CORP
  • EP4202740B1 patent drawingFigure 1
  • EP4202740B1 patent drawingFigure 2
  • EP4202740B1 patent drawingFigure 3

AI summary

A method comprises detecting execution of a fork() operation in a cryptographic computing system that generates a parent process and a child process, assigning a parent kernel data structure to the parent process and a child kernel data structure to the child process, detecting, in the child process, a write operation comprising write data and a cryptographic target address, and in response to the write operation blocking access to a corresponding page in the parent process, allocating a new physical page in memory for the child process, encrypting the write data with a cryptographic key unique to the child process, and filling the new physical page in memory with magic marker data.