Push Framework Security with Key Exposure Minimization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing messaging systems, particularly those using the push framework, face significant security issues and lack privacy, with most being complex to use and operate, and existing secured systems are either not user-friendly or effective.
Innovation Solution
A system and method for securing a push messaging framework that employs cryptographic key pairs for encryption and decryption, along with a scrambling hash function to minimize private key exposure and ensure secure communication between sender, receiver, and messaging service, while also offering an untrusted model for enhanced security at the cost of ease of use.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If cryptographic key pairs and multiple encryption layers are implemented, then security level is improved, but device complexity increases
Solution Approach 1:
The system segments the encryption process into multiple independent layers: application-layer encryption using the application's private key, transport-layer encryption using the messaging server's private key, and registration-layer encryption using the auxiliary private key. Each layer operates independently with its own key pair, allowing the security system to be broken down into manageable modular components that can be implemented and verified separately.
Solution Approach 2:
The messaging server acts as an intermediary that facilitates key exchange and message transmission without having access to the application's private keys. The server receives encrypted messages from senders, forwards them to receivers, and manages the auxiliary key infrastructure, thereby enabling secure communication without requiring the server to compromise security by storing sensitive application keys.
2Reliability
If private key exposure is minimized through scrambling hash functions, then security is improved, but ease of operation deteriorates
Solution Approach 1:
The system performs preliminary key pair generation and auxiliary key registration during the setup phase, before actual messaging operations begin. The auxiliary private key is generated and stored securely in the messaging server's database during registration, and the application's private key is generated and stored in the application's private storage area beforehand. This preliminary preparation eliminates the need for complex real-time key management during message transmission.
Solution Approach 2:
The application autonomously manages its own private key generation, storage, and usage without requiring external intervention. The application generates its own cryptographic key pair, stores the private key in its secure storage area, and uses it for encryption and decryption operations. This self-service approach simplifies the overall system operation while maintaining high security standards.
Data Source
Figure 1
Figure 2
Figure 3~4b
AI summary
The invention relates to a push messaging framework, which offers 2 end-to-end message security models: the "trusted model", which is intended for developers that trust the messaging service (MS) in a sense that they are willing to share the content of push messages with it, and the "untrusted model" for developers that do not trust the MS. There is an essential tradeoff between the two models: a higher level of security in the untrusted model comes at a price of a lower ease-of-use level. The invention offers an easy-to-use implementation of the untrusted model. Furthermore, the invention relates to a method for safekeeping the private key onboard clients for both security models. The method minimizes the duration of private key exposure in memory so that an attacker will have to time an attack to the exact moment that the key is used. This security measure is crucial for Android clients which can easily be compromised. Finally, the invention security model supports application authentication functionality intended to prevent pirating.