Tamper-Proof Electronic Message System Using Embedded Public Key
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional tamper-proofing techniques for electronic messages are resource-intensive and complex, particularly in healthcare contexts, as they require frequent communications with a common security subsystem and maintenance of public keys, making them burdensome for both network and computational resources.
Innovation Solution
A computer-implemented technique that injects a public key into a security token, allowing the client application to sign the payload with a private key, which is then validated by the service provider application using the corresponding public key, reducing the need for the common security subsystem to sign messages and eliminating the requirement for maintaining lengthy lists of public keys.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a single-use token approach is used for each electronic message, then message authentication is achieved, but network resources and common security subsystem resources are burdened due to additional communications required for each message
Solution Approach 1:
The system performs preliminary actions by having the client application obtain a security token with an embedded public key before message transmission. This token is cached and reused for multiple messages, eliminating the need for repeated communications with the common security subsystem for each message while maintaining authentication reliability.
Solution Approach 2:
The invention uses a copied approach by embedding the public key within the security token itself. Instead of requiring the service provider to maintain separate lists of public keys for each client, the public key is copied into the token that travels with the message, simplifying the validation process and reducing system complexity.
2Reliability
If a common security subsystem signs each electronic message, then message integrity is verified, but additional communications between client and security subsystem are required for each message
Solution Approach 1:
The common security subsystem performs signing operations in advance by issuing security tokens that contain the client's public key. These tokens are cached and valid for multiple messages, allowing the service provider to verify message integrity without requiring real-time communication with the security subsystem for each message.
Solution Approach 2:
The client application uses its cached security token to sign messages locally without requiring ongoing interaction with the common security subsystem. The service provider independently validates messages using the public key embedded in the token, making the system self-sufficient after initial token issuance.
3Reliability
If a local signing authority maintains a list of public keys for each client application, then message validation is possible, but computational resources are burdened when many client applications send messages
Solution Approach 1:
Instead of maintaining separate lists of public keys, the invention copies the relevant public key directly into the security token. The service provider only needs to validate the token signature using the embedded public key, eliminating the computational burden of searching through or managing lists of public keys for each client application.
Solution Approach 2:
The invention extracts only the necessary public key from the client's key pair and embeds it within the security token. This eliminates the need for the service provider to maintain or search through comprehensive lists of all client public keys, significantly reducing computational resources required for message validation.
Data Source
AI summary
A computing system for generating tamper-proof electronic messages is disclosed herein. A service provider application receives an electronic message from a client application. The electronic message comprises an authorization provider (AuP) token that includes a public key of a local signing authority (LSA) and a signed payload that has been signed by the LSA using a private key of the LSA that forms a cryptographic key pair with the public key, the signed payload comprising an indication of a programmatic task to be executed by the service provider application. Responsive to validating the AuP token in the electronic message, the service provider application extracts the public key from the electronic message. Responsive to validating the signed payload based upon the extracted public key of the LSA, the service provider application executes the programmatic task.