Client SDK Authentication Tokens for Trusted Element Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing communication models between a client SDK and a trusted element are vulnerable to insider attacks, as they rely on end-to-end encryption and signature models that do not adequately protect against internal malicious activities, allowing attackers to spoof requests, execute commands, and access sensitive data.
Innovation Solution
A method and system for verifying authenticity of communication by using asymmetric key pairs and tokens, where the client SDK obtains a public and private signing key, generates a command message with a client authenticity token and signature, and the trusted element verifies these using corresponding public keys to ensure secure execution of functions, with optional encryption for confidentiality.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If end-to-end encryption and signature models are used for communication between client SDK and backend, then confidentiality and basic authenticity are provided, but the system becomes vulnerable to internal/insider attacks where attackers can spoof requests and access sensitive data
Solution Approach 1:
The authentication mechanism is segmented into multiple independent verification layers: (1) verification of the client's digital signature on the request, (2) verification of the backend's digital signature on the response, and (3) verification of the trusted element's signature on sensitive operations. This segmentation ensures that no single point of failure allows insider attacks while maintaining manageable complexity through modular verification.
Solution Approach 2:
A trusted element acts as an intermediary between the client SDK and the backend service. This trusted element verifies the authenticity of communications bidirectionally - confirming the client's identity before allowing requests and validating the backend's responses before delivery. The intermediary prevents insider attacks by ensuring that even if the backend is compromised, it cannot forge authentic-looking responses without the trusted element's verification.
2Reliability
If zero-trust principles are applied to protect against insider attacks, then security against internal threats is improved, but the communication protocol complexity and verification overhead increase
Solution Approach 1:
Authentication credentials (digital signatures and certificates) are established and verified in advance before any sensitive operations occur. The client SDK signs requests with pre-obtained credentials, and the trusted element verifies these signatures before allowing communication with the backend. This preliminary authentication ensures that even if insider attacks occur during operation, the pre-established trust relationships prevent unauthorized actions.
Solution Approach 2:
The system implements bidirectional feedback verification where the trusted element not only verifies client requests but also verifies backend responses before delivering them to the client. This feedback loop ensures that any tampering or unauthorized modifications by insiders are detected and rejected, maintaining security while providing clear verification feedback at each communication stage.
3Reliability
If multiple verification layers are implemented to prevent spoofing and unauthorized access, then authenticity verification is improved, but the processing time and operational overhead increase
Solution Approach 1:
The patent replaces complex mechanical verification processes with cryptographic digital signatures. Instead of manual or complex procedural verification of authenticity, the system uses mathematical signature verification algorithms that can be executed efficiently by computers. The trusted element verifies the client's signature and the backend's signature using public key cryptography, which provides strong authenticity guarantees with minimal processing overhead compared to traditional verification methods.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The invention is a method for verifying authenticity of communication between a client SDK (20) and a trusted element (40). During an initialization phase, the client SDK sends a container (29) including an SDK public signing key (21) to a customer backend (70), via a customer application, a token request (101) comprising the container. The customer backend generates a client authenticity token, CAn, (79) by signing the container with a customer private signing key (71) and sends the CAn to the client SDK via the customer application. During an operating phase, the client SDK generates a command message (202) requesting execution of a function of the trusted element, said command message including the CAn and a command signature generated using an SDK private signing key (22) and sends the command message to the backend service which generates a command request (302) comprising both said CAn and the command signature and sends the command request to the trusted element. The trusted element performs a verification of both the CAn using a customer public signing key (41) and the command signature using the SDK public signing key retrieved from the CAn and executes said function using the command data only if said verification is successful.