Temporary Signing Key for Flash Transaction Authentication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for securing real-time transactions, such as those in FLASH-based gaming applications, are inadequate due to the insecurity of client applications, which allows for potential fraudulent acquisition of account information and identity theft, as shared secret cryptography fails when applied to unsecure applications like FLASH, where secrets can be inspected and compromised.
Innovation Solution
A method for authenticating electronic transactions using a temporary signing key constructed from user identity, a time-based salt value, and a shared secret between a client computer and a transaction server, ensuring only valid requests are processed, with the signing key being valid for a limited time to minimize fraudulent use.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If shared secret cryptography is used to secure transactions, then transaction security is improved, but it becomes vulnerable when applied to unsecure applications like FLASH where secrets can be inspected and compromised
Solution Approach 1:
The patent applies dynamics by making the signing key temporary and time-limited rather than static. The signing key is generated dynamically for each transaction session and automatically expires after a predetermined time period, preventing long-term compromise even if intercepted. This transforms the security model from static secret sharing to dynamic key generation that adapts to the security constraints of unsecure applications.
Solution Approach 2:
The patent segments the authentication process into distinct phases: a secure setup phase where the shared secret is established on the server, and an unsecure execution phase where the application runs without access to the secret. The signing key is derived from the shared secret but is separate from it, allowing the application to use the signing key without exposing the underlying secret. This segmentation isolates the secret from the unsecure environment.
2Reliability
If a signing key is made temporary and time-limited, then security against fraudulent use is improved, but key management complexity increases
Solution Approach 1:
The system implements self-service through automatic key generation and expiration. The server automatically generates signing keys derived from the shared secret and embeds them in the application code or transmits them to the client. The keys automatically expire after a predetermined time period without requiring manual intervention for key rotation or revocation. This reduces key management complexity despite the dynamic nature of the keys.
Solution Approach 2:
The patent applies preliminary action by pre-generating signing keys on the server before the application executes. The server derives the signing key from the shared secret and either embeds it in the application code during compilation or transmits it to the client before the transaction session begins. This preliminary key preparation simplifies the client-side implementation and reduces the computational burden during actual transaction processing.
3Measurement precision
If the signing key is derived from multiple parameters including user identity and time-based salt, then authentication precision is improved, but computational requirements increase
Solution Approach 1:
The patent applies partial action by using a predetermined subset of parameters for signing key derivation rather than all possible identifying information. The signing key is derived from the shared secret combined with the user's identifying information and a time-based salt value. This selective use of parameters provides sufficient authentication precision to distinguish between different users and sessions while avoiding the computational overhead of processing excessive identifying data.
Data Source
AI summary
Systems and methods for authenticating a request between a client computer and a transaction server are provided. An application request, comprising an identity of a user originating the request, is received at an application server from the client. The application server constructs a signing key based on (i) the identity of the user making the request, (ii) a time based salt value, (iii) a secret shared between the application and transaction servers and, optionally, (iv) an identifier of the distributor or developer of the application. The signing key is embedded in an unbranded version of the application thereby branding the application. The branded application can sign a request with the signing key and submit the signed request to the transaction server with the identity of the user and the identifier of the distributor or developer of the application.