Embedded Device Security Token Recovery via Remote Backup

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Embedded devices face challenges in maintaining security tokens due to memory constraints and software updates, leading to difficulties in recovering lost tokens, especially when user input is limited to keypads or virtual keyboards, which is time-consuming and stressful for users.

Innovation Solution

A method and system where a service provider server sends a backup copy of the security token to a device server, allowing automatic recovery by retrieving and resend the backup token to the embedded device when the primary copy is lost, using standard and secure protocols like HTTPS.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If security tokens are cached on embedded devices for automatic authentication, then user convenience is improved, but the tokens may be lost due to memory constraints or software updates

Engineering Contradiction:
Improveuser convenienceVSAvoidtoken retention
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The system performs preliminary action by creating a backup copy of the security token on a remote server before the token is potentially lost on the embedded device. This advance preparation ensures that when token loss occurs (due to memory constraints or software updates), the backup is already in place and can be quickly retrieved, resolving the contradiction between maintaining tokens for convenience and preserving them reliably.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

A remote server acts as an intermediary between the embedded device and the service provider. The server stores backup copies of security tokens and facilitates their recovery. When a device loses its token, the intermediary server provides the backup, resolving the unreliability of local storage while maintaining the convenience of automatic authentication.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If users re-input credentials on embedded devices after token loss, then token recovery is achieved, but user time and stress increase due to cumbersome input interfaces

Engineering Contradiction:
Improvetoken recoveryVSAvoiduser time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

Instead of requiring users to recreate the credential (which involves time-consuming manual input on limited interfaces), the system creates and retrieves a copy of the existing security token from a remote backup. This copying approach restores the token instantly without requiring user interaction with cumbersome input interfaces, resolving the contradiction between reliable recovery and time loss.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The system enables self-service token recovery by automatically detecting when a token is lost and retrieving the backup copy without requiring user intervention. The embedded device or service provider system automatically requests and receives the backup token from the remote server, eliminating the need for users to manually re-input credentials through time-consuming processes.

Inventive Principle:
Principle #25Self-service

3Reliability

If backup copies of security tokens are stored on remote servers, then token recovery reliability is improved, but system complexity increases

Engineering Contradiction:
Improvetoken recoveryVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The remote server performs multiple functions: it stores backup security tokens, manages token retrieval requests, and communicates with both service providers and embedded devices using standard protocols. This multi-functionality consolidates the backup system into a single versatile component, reducing overall system complexity while maintaining high recovery reliability.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system changes the storage location parameter of security tokens from exclusively local (embedded device) to distributed (both local and remote). By storing tokens in multiple locations with different characteristics, the system achieves reliable recovery without significantly increasing complexity, as the same token management protocols apply regardless of storage location.

Inventive Principle:
Principle #35Parameter changes

4Reliability

If standard secure protocols are used for token transmission, then security is improved, but communication overhead increases

Engineering Contradiction:
ImprovesecurityVSAvoidcommunication overhead
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The patent extracts the security-critical token transmission from the regular data communication flow. By separating authentication token exchanges from general data traffic and using dedicated secure protocols only when necessary (during initial authentication and token recovery), the system maintains high security while minimizing communication overhead during normal operations.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS8918853B2Method and system for automatic recovery from lost security token on embedded device
Publication Date: 2014.12.23 SHARP KK
  • US8918853B2 patent drawing
  • US8918853B2 patent drawing
  • US8918853B2 patent drawing

AI summary

Automatic recovery from loss of a security token on an embedded device is achieved by having a service provider (SP) server send to a device server a backup copy of the security token in conjunction with sending to an embedded device a primary copy of the security token, and retrieving from the device server and sending to the embedded device the backup copy of the security token upon detecting that the primary copy of the security token has been lost. The method and system obviate the need for a user to have to re-input on the embedded device a credential that is represented by the security token in the event the primary copy of the security token is erased from the embedded device or otherwise becomes inaccessible to the embedded device.