GAA Push Service Key Determination Without Feedback Channel
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing Generic Authentication Architecture (GAA) push service is unable to function effectively in scenarios where the User Equipment (UE) lacks a feedback channel, preventing secure key selection and communication in push services, as it relies on active UE initiation and lacks a mechanism for key notification to the network side.
Innovation Solution
A method and device are introduced to determine and use a push service key at the network side, which is then indicated to the UE for secure communication, allowing the UE to select and use a qualified push service key for encrypted communication with the network side, enabling secure push services even without a feedback channel.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the existing GAA push service is used, then the service can be provided, but it cannot function effectively when the UE lacks a feedback channel, preventing secure key selection and communication
Solution Approach 1:
The patent introduces an intermediary mechanism where the network side determines and indicates the push service key type to the UE. This intermediary key indication mechanism enables communication scenarios without feedback channels by allowing the network to unilaterally establish secure communication parameters, thus resolving the contradiction between maintaining push service reliability and adapting to diverse communication scenarios.
2Reliability
If the UE initiates active connection request, then mutual authentication can be performed, but the network side cannot initiate active communication request (push service)
Solution Approach 1:
The patent inverts the traditional authentication initiation model by allowing the network side to determine and indicate the push service key type to the UE, rather than requiring UE initiation. This inversion enables the network to actively initiate push services while maintaining authentication security through the indicated key type, thus resolving the contradiction between authentication reliability and communication initiation flexibility.
3Reliability
If the NAF requests derived key from BSF, then secured communication can be established, but the process is complex and requires multiple entities interaction
Solution Approach 1:
The patent extracts the key type determination function from the complex multi-entity interaction and consolidates it on the network side (NAF/BSF). By taking out the key type indication mechanism and placing it on the network side, the system maintains secured communication reliability while simplifying the overall key management process, as the network side alone determines and indicates the appropriate key type to the UE.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A realizing method for PUSH service of GAA and a device. The method includes the steps: the network side determines a PUSH service cryptographic key; the subscriber side communicates with the network side, and determines the PUSH service cryptographic key in accordance with the network side, and communicates with the network side using the PUSH service cryptographic key. By means of the method, the cryptographic key type of the PUSH service can be selected conveniently and agilely according to the actual application situation, and the network side and the subscriber side can select the derivation cryptographic key of the cryptographic key type meeting the requirement to communicate with each other.