Battery-Free Security Token Using Wireless Energy Harvesting
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing security tokens require a battery to maintain a common time base with authentication servers, which limits their functionality and increases complexity, and they often require a direct connection between the terminal and authentication server, making them vulnerable to 'man in the middle' attacks.
Innovation Solution
A security token that uses a wireless interface to receive electrical energy from a terminal, such as a smartphone, and generates one-time passwords (OTPs) through cryptographic derivation using first and second data stored in its electronic memory, eliminating the need for a battery and allowing for secure authentication without a direct connection to the authentication server.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a battery is used to maintain a common time base with the authentication server, then the security token can generate constantly changing passwords synchronously, but the device complexity and power requirements increase
Solution Approach 1:
The patent extracts the time base maintenance function from the security token by implementing a state machine that generates timestamps purely from internal state transitions and counter increments. This eliminates the battery requirement while maintaining synchronous password generation capability through algorithmic time derivation rather than physical time synchronization.
Solution Approach 2:
The patent changes the fundamental parameter of timekeeping from continuous battery-powered clock synchronization to discrete state-based timestamp generation. The state machine transitions through defined states and increments counters to generate monotonically increasing timestamps, transforming the time base from a continuous physical phenomenon to a discrete computational sequence.
2Productivity
If a direct connection between terminal and authentication server is required, then real-time authentication is possible, but the system becomes vulnerable to man in the middle attacks
Solution Approach 1:
The patent introduces the OTP value as an intermediary that carries authentication information without requiring direct real-time communication between terminal and server. The OTP encapsulates the authentication state and can be transmitted through potentially insecure channels while maintaining security, as it is derived from secret data and timestamps rather than requiring active connection verification.
Solution Approach 2:
The patent performs preliminary authentication by generating the OTP value in advance based on secret data and current timestamp, before actual authentication occurs. This allows the authentication information to be prepared and transmitted separately from the authentication event itself, decoupling the timing requirements and reducing vulnerability to interception attacks.
3Reliability
If cryptographic derivation uses only secret data and timestamp, then security is enhanced, but the OTP may not be unique across different authentication instances
Solution Approach 1:
The patent implements dynamics by making the OTP generation dependent on the current timestamp value, which continuously changes. The state machine transitions through different states and increments counters based on time progression, ensuring that even with the same secret data, each authentication instance produces a unique OTP due to the changing temporal parameter.
Solution Approach 2:
The patent performs preliminary counter incrementing and state transitions before generating the OTP value. This ensures that each authentication request operates on updated internal state, guaranteeing uniqueness of the generated OTP even when derived from the same secret data, by incorporating the progression of time through counter values.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The invention relates to a method for generating an OTP using a security token (106) for authentication with respect to an authentication module (184). The security token has an electronic memory (118) which only a processor (128) of the security token can access, first (160) and second (162) data being stored in said electronic memory and in addition, a version of the first data and the second data being stored in a database (188).