App Authentication via Derived Network Tokens on User Equipment
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional authentication mechanisms in telecommunications networks restrict access to EAP_AKA mechanisms and tokens tightly, preventing general or non-privileged applications from utilizing the trust established between user equipment and the network, thereby limiting their ability to authenticate securely.
Innovation Solution
A method involving a user equipment performing EAP and AKA protocols with an entitlement configuration server, enabling a privileged application to obtain token information, which is then used by a non-privileged application to authenticate with a resource server, leveraging the established trust relationship and security procedures provided by the universal integrated circuit card entity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If access to EAP_AKA mechanisms and tokens is tightly restricted by the operating system, then security of the authentication mechanism is improved, but general or non-privileged applications cannot utilize the established trust relationship between user equipment and the network
Solution Approach 1:
The authentication token is segmented into two distinct tokens: a first token obtained through EAP_AKA authentication for device-level security, and a second token derived from the first token for application-level authentication. This segmentation allows the operating system to maintain tight restrictions on the first token while enabling general applications to use the second token, thus resolving the contradiction between security and application accessibility.
Solution Approach 2:
A privileged application acts as an intermediary between the restricted EAP_AKA mechanism and general applications. The privileged application obtains the first token through EAP_AKA, then derives and provides the second token to general applications. This intermediary approach maintains security restrictions while enabling application authentication capabilities.
2Ease of operation
If general applications use traditional authentication mechanisms with username and password, then ease of operation is improved, but security level is reduced compared to operator authentication
Solution Approach 1:
The system enables applications to perform self-service authentication using the second token without requiring manual username and password input from users. The application automatically obtains the second token through the privileged application and uses it for authentication, maintaining ease of operation while achieving security levels comparable to operator authentication.
Data Source
Figure 1~2
AI summary
The present invention relates to a method for authenticating a general or non-privileged application that is running on or is executed by a user equipment, wherein the user equipment is used with a telecommunications network, wherein the telecommunications network comprises an entitlement configuration server entity and wherein the telecommunications network comprises or is associated with or is able to access a resource server entity, wherein the user equipment comprises a universal integrated circuit card entity as well as runs or executes an operating system, wherein the universal integrated circuit card entity provides security procedures, and wherein the user equipment comprises a privileged application or functionality that is able to access the security procedures of the universal integrated circuit card entity, wherein, in order to authenticate the general or non-privileged application towards the resource server entity, the method comprises the following steps: -- in a first step, the user equipment performs or conducts an extensible authentication protocol, EAP, and/or an enhanced authentication and key agreement, AKA, with respect to, or towards, the entitlement configuration server entity, resulting in the privileged application or functionality receiving or comprising a first token information, -- in a second step, the user equipment requests, from the entitlement configuration server entity, a second token information, resulting in the second token information being received by the user equipment, the second token information being based on the first token information and provided to the general or non-privileged application, -- in a third step, the general or non-privileged application uses the second token information to authenticate itself at, or towards, the resource server entity.