Receiver-Initiated Secure Data Container for Single-Point Custody
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing secure data transfer methods are cumbersome and inconvenient, often requiring multiple authentication steps, new software installations, and lack a single point of custody, making them inaccessible to technology-averse consumers and increasing cyber security risks.
Innovation Solution
A method for secure data transfer involving a single point of custody with a receiver-initiated request, using a unique identifier to create a secure data container that is delivered to the sender, where data is uploaded and encrypted without requiring additional tools or authentication from the sender, ensuring secure transit and no residual data trails.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional secure data transfer methods are used (encrypted email, FTP, portal login), then security is improved, but ease of operation deteriorates due to multiple authentication steps and software requirements
Solution Approach 1:
The system segments the authentication process by separating receiver-initiated authentication from sender actions. The receiver authenticates and creates a secure container, while the sender only needs to upload data without any authentication, dividing the security burden into distinct operational phases.
Solution Approach 2:
The receiver performs preliminary authentication and sets up the secure data container before the sender transfers data. This preliminary action eliminates the need for sender authentication and complex real-time security negotiations, simplifying the sender's task to just uploading files.
2Reliability
If multiple authentication and software setup steps are required, then security is improved, but device complexity increases
Solution Approach 1:
The system extracts authentication requirements from the sender's side and places them entirely on the receiver's side. The sender's device complexity is reduced to minimal file upload functionality, while the receiver handles all authentication and security setup in advance.
Solution Approach 2:
The secure data container serves multiple functions: it acts as an encrypted storage medium, an authentication mechanism, and a transfer protocol all in one. This multi-functionality eliminates the need for separate authentication systems, encrypted email clients, and FTP software, reducing overall device complexity.
3Reliability
If fax machines or third-party services are used, then a single point of custody is achieved, but ease of operation deteriorates due to machine requirements and counter service
Solution Approach 1:
The receiver self-services by initiating the secure container creation and authentication process. This eliminates the need for sender-side machines or third-party counter services, as the receiver independently sets up the secure transfer mechanism and the sender simply uploads files to the provided container.
4Reliability
If encrypted email is used, then security is improved, but ease of operation deteriorates due to software download and password creation requirements
Solution Approach 1:
Instead of requiring the sender to encrypt and manage security (traditional approach), the system inverts the process by having the receiver create the encrypted container and authentication mechanism first. The sender then interacts with an already-secured system, reversing who performs the complex security operations.
Data Source
Figure 1A
Figure 1B
Figure 2A
AI summary
A semi-complete secure data container is associated with a unique identifier by a requesting entity but is void of data. The data container, and a request to add data to the container, are combined into a message that is sent to a client. Upon receipt of the request, the client need not do anything to create a secure environment by which to protect the data. The secure environment, or data container, is already created and is merely awaiting data; data supplied by the client. Once the client places the requested data into the data container, the container closes and encrypts the data. The container, now closed and containing encrypted data, returns to the original requesting entity which solely possesses the key to decrypt the contents.