Domain-Specific Security Sandbox for Secure Flash Transactions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for securing real-time transactions, such as shared secret cryptography, fail when applied to insecure applications like FLASH-based gaming applications, as the secret key can be compromised when bytecode is inspected on the client computer.
Innovation Solution
The use of server cross-domain policies and domain-specific security sandboxes to execute transaction modules in isolated environments, preserving the source URL and preventing introspection, ensuring secure interactions between domains.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If shared secret cryptography is used to secure transactions, then transaction security is improved, but the secret key becomes vulnerable to inspection in insecure applications like FLASH
Solution Approach 1:
The system segments the transaction processing into two distinct components: a secure server-side transaction module that generates and holds the secret key, and a client-side application that only interacts with the module through controlled interfaces. The transaction module is delivered as a separate executable component (e.g., SWF file) that runs in an isolated environment, separating the secret key management from the insecure application code.
Solution Approach 2:
The transaction module acts as an intermediary between the insecure client application and the secure server. It receives requests from the application, performs authenticated communication with the server using the secret key, and returns results without exposing the key to the application. The cross-domain policy serves as a mediator that controls and restricts how the application can interact with the module.
2Ease of manufacture
If the transaction module is delivered as downloadable bytecode, then ease of distribution is improved, but the bytecode can be inspected and secrets extracted at the client computer
Solution Approach 1:
The transaction module is packaged in a proprietary executable format (e.g., SWF) that acts as a protective shell. This format allows the module to be delivered and executed in a controlled environment (FLASH player sandbox) while preventing direct inspection of the internal secret key. The shell provides a layer of obfuscation and runtime control that prevents extraction of sensitive information.
Solution Approach 2:
The module executes in an isolated runtime environment (FLASH player sandbox with restricted cross-domain policies) that acts as an inert atmosphere. This environment prevents the module from being inspected or modified by the host application while still allowing it to function. The sandbox restricts file system access, prevents debugging, and controls inter-process communication.
3Reliability
If cross-domain policies restrict interaction to specific source URLs, then security is improved, but system complexity increases due to multiple domains and policies
Solution Approach 1:
The security complexity is extracted from the application code and placed entirely in the runtime environment's cross-domain policy configuration. The application itself remains simple and does not need to implement security logic. The policy management is handled by the FLASH player and server infrastructure, separating security concerns from application development.
Data Source
AI summary
Computer systems, methods, and computer readable media for facilitating a secure transaction are provided in which a client application is executed on a client computer. The client application initiates a request to a first domain comprising (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application. Responsive to this request, the client receives a validated transaction module from the first domain. The client application loads the validated transaction module into a separate domain security sandbox that is segregated from memory space in which the client application is run. The validated transaction module conducts a validated transaction between the second domain and the validated transaction module. Separately, through the client application, a determination is made as to whether the transaction is complete by querying the first domain.