Offline Access Tokens for Secure Temporary Lock Entry
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing electronic locks face challenges in securely managing access for temporary users without requiring constant network connectivity, leading to synchronization issues and security risks due to key distribution and storage limitations.
Innovation Solution
A method using public-key cryptography and digital signatures allows temporary access by generating a device's own key pair, enabling secure message delivery through an unregistered intermediary, ensuring message integrity and authenticity without direct user involvement.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If manual user authentication processes are used for each individual user, then security and access control are maintained, but the system becomes cumbersome and time-consuming when temporary users need to be frequently added and removed
Solution Approach 1:
The system pre-generates access tokens with embedded expiration timestamps before they are needed. Temporary user access is granted by distributing these pre-prepared tokens rather than creating individual user profiles in real-time, eliminating the time-consuming manual registration process while maintaining security through token validation and expiration mechanisms.
2Reliability
If the lock stores access lists locally to enable offline access, then access control works without network connectivity, but the device becomes full and requires constant synchronization with the hub
Solution Approach 1:
The system extracts the access control data from the lock device and stores it in the form of access tokens distributed to external devices. The lock only retains minimal verification logic and public keys, while the detailed access lists and user management are handled externally by the hub or server. This reduces the lock's storage requirements and eliminates the need for constant synchronization, as tokens are self-contained and can be verified offline.
3Reliability
If cryptographic key exchange is implemented between the lock and trusted servers to ensure message security, then authentication and message integrity are guaranteed, but additional system resources are required and key management becomes complex
Solution Approach 1:
The system performs key exchange and cryptographic setup in advance during device initialization or factory provisioning. The lock is pre-configured with its own key pair and the public keys of trusted entities. This preliminary cryptographic setup eliminates the need for complex real-time key management and exchange operations, reducing resource requirements during normal operation while maintaining strong security through pre-established cryptographic relationships.
Solution Approach 2:
The lock device is given the capability to independently generate its own cryptographic key pair and autonomously manage its private keys without requiring continuous external assistance. The device can independently verify messages using stored public keys and generate digital signatures, making the key management process self-sufficient and reducing the complexity of external key distribution infrastructure.
4Ease of operation
If access tokens are distributed to temporary users without network connectivity, then temporary access is enabled, but the tokens may become desynchronized or exhausted without ability to replenish them
Solution Approach 1:
The system pre-generates multiple access tokens with different expiration times and scopes before distributing them to temporary users. These tokens are created in advance with all necessary authorization information embedded, allowing users to access the system offline without needing to connect to replenish tokens. The pre-generation ensures tokens are available when needed while the expiration mechanisms prevent desynchronization issues.
Data Source
AI summary
System and method for delivering a secure message to a device. The method includes: digitally signing a first message using a private key of a first entity; encrypting the digitally signed first message using a public key of the device to form a token; further encrypting the token using a public key of a second entity; transmitting the further encrypted token to the second entity; the second entity decrypting the further encrypted token using a corresponding private key of the second entity to recover the token; the second entity delivering the token to the device; the device decrypting the token to recover the digitally signed first message using a corresponding private key of the device; and the device authenticating the digitally signed first message using a corresponding public key of the first entity.