PKI API Authentication via Signature Token Intermediary
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing authentication techniques, such as keyed-hash message authentication codes (HMAC) and mutual SSL based on public key infrastructure (PKI), face challenges including key leakage risks, high setup and maintenance costs, and difficulty in authenticating at the application level, especially in securing sensitive information in less trusted zones.
Innovation Solution
A PKI-based authentication method that involves generating API messages using cryptographic algorithms like RSA-SHA2 or ECDSA, where messages are signed with a private key and verified with a public key, reducing the need for sensitive information in less secure zones and allowing authentication at the application level, thereby protecting internal networks from unauthorized access.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If HMAC is used for authentication, then message integrity and authenticity are protected, but the secret key must be shared between sender and receiver increasing the risk of key leakage
Solution Approach 1:
The patent introduces a signature token as an intermediary that carries authentication information without exposing the private key. The signature token is generated by signing data with the private key and then encrypting the signature with the recipient's public key, allowing verification without key exposure.
Solution Approach 2:
The patent extracts the authentication function from the private key itself and places it in a separate signature token. The private key remains securely stored and is never transmitted, while the token contains the necessary authentication information for verification.
2Reliability
If mutual SSL based on PKI is used for authentication, then security is enhanced, but the setup and maintenance costs are high due to requiring both private and public keys in insecure environments
Solution Approach 1:
The signature token serves as an intermediary that eliminates the need to store and manage private keys in insecure perimeter networks. Only public keys and signature tokens are present in the low-security zone, dramatically reducing setup and maintenance complexity.
Solution Approach 2:
The patent segments the authentication mechanism into separate components: private key generation in secure zones, signature creation, and verification using public keys in less secure zones. This segmentation allows each component to be optimized for its specific security requirements.
3Reliability
If mutual SSL implements authentication below application level, then network security is provided, but it is difficult for higher-level applications to map subjects to principals needing authentication
Solution Approach 1:
The patent adds an application-level dimension to authentication by incorporating subject identification and principal mapping information directly into the signature token at the application layer, rather than relying solely on network-level SSL authentication.
Solution Approach 2:
The signature token serves multiple functions: it provides cryptographic authentication, carries subject identification information, enables principal mapping, and works across different application protocols. This multi-functionality resolves the limitation of traditional SSL authentication.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Methods, systems, and devices are provided for generating API messages using PKI-based authentication techniques. A client system can generate a private/public key pair associated with the client system and sign an API message using the private key of the private/public key pair and a PKI-based cryptographic algorithm, before sending the signed API message to a server system. The server system (e.g., operated by a service provider) can authenticate the incoming signed API message using a proxy authenticator located in less trusted zone (e.g., a perimeter network) of the server system. In particular, the proxy authenticator can be configured to verify the signature of the signed API message using the public key corresponding to the private key and the same cryptographic algorithm. The authenticated API message can then be forwarded to a more trusted zone (e.g., an internal network) of the server system for further processing.