Hardware Token Authorization for Self-Service Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current self-service systems face challenges with offline authorization, including limited traceability, difficulty in revoking rights, and security vulnerabilities, particularly when USB ports are closed or in emergency situations where technician access needs to be blocked.
Innovation Solution
A method utilizing a hardware token with dual interfaces for remote authentication through an authorization server, enabling secure online authorization by generating and transmitting digitally signed messages between the self-service system, token, and authorization server, with mutual authentication and cryptographic protection to prevent unauthorized access.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If offline authorization using technician tokens is implemented, then service calls can be authorized locally, but reliable logging and traceability cannot be achieved
Solution Approach 1:
The patent introduces a mobile device as an intermediary between the technician token and the authorization server. The mobile device receives the first message from the self-service system via the token, forwards it to the authorization server, and receives the second message back. This intermediary approach enables online authorization and traceability while maintaining the convenience of local token-based initiation.
2Ease of operation
If technician tokens store rights with long time windows, then authorization is convenient, but rights cannot be revoked effectively
Solution Approach 1:
The patent implements dynamic authorization where the second message from the authorization server contains time-limited authorization data. This allows authorization rights to be automatically revoked after a specified time window without requiring physical collection of the token. The authorization is dynamic rather than static, enabling effective revocation while maintaining convenience.
3Reliability
If USB ports are closed to prevent malware, then system security is improved, but offline authorization becomes impossible
Solution Approach 1:
The patent makes the authorization system universal by supporting multiple communication interfaces. The self-service system can authorize technicians through various means: traditional USB token connection, wireless communication (NFC, Bluetooth, Wi-Fi), or other interfaces. This multi-functionality allows authorization to work regardless of USB port status, maintaining both security and capability.
4Reliability
If protective mechanisms are fully active, then system security is maximized, but authorized service calls cannot be performed
Solution Approach 1:
The patent implements dynamic adjustment of protective mechanisms. The second message from the authorization server can instruct the self-service system to temporarily deactivate specific protective mechanisms only for the duration and scope of the authorized service call. This dynamic approach allows full security when not in use while enabling necessary service operations when authorized.
Data Source
Figure 1
Figure 2
AI summary
The invention relates to a method and an arrangement for authorizing an action at a self-service system. It enables a user (3) to be authorized to perform an action at a self-service system (1) using an authorization server (5), wherein the user (3) is equipped with a token (2) for identification. The method comprises the steps of: generating a first message by the self-service system (1) when the user (3) has identified themselves to the self-service system (1) by means of the token (2), and storing the first message on the token (2), wherein the first message contains data for identifying the user (3) and the self-service system (1); transmitting the first message from the token (2) to the authorization server (5); and checking at the authorization server (5), taking the first message into account, whether the action may be performed by the user (3) at the self-service system (1).Generating a second message at the authorization server (5) and transmitting the second message from the authorization server (5) to the token (2), the second message containing data on whether the action may be performed by the user (3) at the SB system; reading the second message by the SB system (1) and allowing the action by the SB system (1), provided the second message contains the corresponding authorization.