Secure Kernel Caller Authentication via Callpoint Log
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current computer security systems face inefficiencies and increased complexity in maintaining security, as methods for securing systems are quickly undermined by security breaches, viruses, and attacks, necessitating a cost-effective and efficient solution to prevent unauthorized access to secure kernel routines.
Innovation Solution
Implementing a callpoint log, allowed-transitions table, and allowed-calls table within a secure kernel to authenticate and authorize access to secure kernel routines, using state transitions and cryptographic security to prevent unauthorized access and misuse.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional security methods are applied to protect secure kernel routines, then security against unauthorized access is improved, but system complexity and computational overhead increase significantly
Solution Approach 1:
The system divides security protection into two segments: a simple caller authentication mechanism in the unsecure kernel and a comprehensive authorization system in the secure kernel. The callpoint log maintains only essential execution state information, separating detailed security logic from the authentication process.
Solution Approach 2:
The system performs preliminary authentication of the caller routine before allowing access to secure kernel routines. By verifying the caller's identity and execution state in advance through the callpoint log, the system prevents unauthorized access before it can occur, reducing the need for complex continuous monitoring.
2Reliability
If comprehensive authentication and authorization mechanisms are implemented, then security against security breaches is improved, but computational overhead and time consumption increase
Solution Approach 1:
The system applies partial authentication by only verifying essential execution state information (current routine, previous routine, return address) rather than comprehensive security auditing. This partial action provides sufficient security while minimizing computational overhead.
Solution Approach 2:
The callpoint log automatically maintains execution state information as routines execute, without requiring active monitoring or additional computational resources. The log serves itself by being updated automatically during normal execution, reducing the burden on security mechanisms.
3Difficulty of detecting and measuring
If execution state monitoring is implemented for all routines, then detection of erroneous or malicious invocation is improved, but device complexity and resource requirements increase
Solution Approach 1:
The system applies execution state monitoring locally only at the boundaries between unsecure and secure kernel regions, rather than throughout the entire system. The callpoint log is maintained only for routines that transition between security domains, reducing the scope of monitoring.
Solution Approach 2:
The callpoint log acts as an intermediary that stores execution state information between the unsecure kernel caller and the secure kernel callee. This intermediary structure enables detection of unauthorized access patterns without requiring direct monitoring of all execution paths.
Data Source
AI summary
In various embodiments of the present invention, execution-state transitions occur in a first portion of a system, and a cumulative execution state for each process is maintained by a second portion of the system so that, when a second-portion routine is called, the second-portion routine can determine whether or not the current execution state is suitable for execution of the second-portion routine. In various embodiments, a callpoint log, allocated and maintained for each process, stores the cumulative execution state for the process. In one embodiment, the first portion is an operating system, and the second portion is a secure kernel, with the cumulative execution state used by the secure kernel to prevent unauthorized access by erroneously or maliciously invoked operating-system routines to secure kernel routines. In another embodiment, the cumulative execution state is used as a debugging tool by the second-portion routines to catch errors in the implementation of the first-portion routines.