Trusted Domain Software Consistency Check for ATM Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current security measures for self-service machines, such as ATMs, are vulnerable to infiltration due to standardization and shared operating systems, leading to potential unauthorized access and poor runtime behavior, with existing protection mechanisms being ineffective in ensuring software consistency and integrity.
Innovation Solution
A trustworthy domain is established within the self-service machine to check the consistency of the control software, using a secure operating system or smart card to generate blocking signals if inconsistencies are found, restricting functionality and ensuring only encrypted input is allowed when consistency is verified.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a shared operating system is used for standardization, then device complexity is reduced and ease of operation is improved, but security reliability deteriorates due to vulnerability to infiltration and inability to ensure software consistency
Solution Approach 1:
The system is segmented into a standard operating system environment and a secure domain environment. The secure domain is isolated from the standard OS, allowing standardization benefits while preventing security compromises from affecting the critical security functions. This segmentation enables different security levels coexisting on the same hardware platform.
Solution Approach 2:
A secure domain acts as an intermediary layer between the standard operating system and security-critical operations. This intermediary verifies software consistency and controls access to security functions, preventing direct infiltration from the standardized OS environment while maintaining operational efficiency.
2Reliability
If signature-based protection mechanisms are implemented, then software consistency checking is improved, but productivity deteriorates due to extended transaction times and startup phase delays
Solution Approach 1:
Software consistency checks are performed in advance during system initialization and software loading phases, before transactions execute. This preliminary verification ensures software integrity is established beforehand, allowing transactions to proceed without repeated consistency checks during execution, thus maintaining productivity.
Solution Approach 2:
The secure domain autonomously manages software consistency verification without requiring intervention from transaction processing systems. The secure domain self-manages the verification of security-critical software components, eliminating the need for external protection mechanisms to continuously monitor during transactions, thereby preserving transaction speed.
3Reliability
If centralized protection mechanisms are deployed, then coverage of all programs and files is improved, but device complexity increases and flexibility in software change management is reduced
Solution Approach 1:
The protection mechanism applies different security policies to different domains locally. The secure domain implements strict verification for security-critical software, while the standard OS domain maintains operational flexibility. This local differentiation provides comprehensive protection coverage without uniformly increasing complexity across the entire system.
Solution Approach 2:
The system segments protection responsibilities between the secure domain and standard OS. The secure domain handles verification of security-critical components with high reliability, while the standard OS manages application software with greater flexibility. This segmentation avoids the need for a single complex centralized mechanism to manage all software uniformly.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Method for checking the consistency of control software of a control computer of a self-service machine, with a trusted domain (1) located within the self-service machine, comprising the steps: - Checking the control software (2) for its consistency through the trusted domain (1) - in case of inconsistency, a blocking signal is generated which is used to restrict the functionality of the self-service machine.