Offline Access Revocation via Local Blacklist Storage
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing device access revocation protocols are not suitable for resource-constrained environments and may not function effectively under limited or unreliable network connectivity, as they require complex client-server architectures and significant memory and storage resources to prevent security breaches.
Innovation Solution
An access control system utilizing a blacklist stored at the resource device, which allows for immediate revocation of access by adding entries for users, roles, or permission levels, even when valid access tokens are presented, enabling denial of access independent of network connectivity and prior authorization.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If complex client-server architectures with consistent network connectivity are used for device access revocation, then security against replay attacks is improved, but device complexity and resource requirements increase significantly
Solution Approach 1:
The patent extracts the revocation list from the server and stores it locally in the device's non-transitory storage medium. This allows the device to independently check token validity against the revocation list without requiring continuous server connectivity, thereby reducing architectural complexity while maintaining security
Solution Approach 2:
The system segments the access control functionality by separating token validation from revocation list updates. The device can validate tokens using locally stored revocation lists, enabling offline security operations, while periodically synchronizing with the server when connectivity is available
2Reliability
If complex client-server architectures with high memory and storage requirements are used for device access revocation, then security against breaches is improved, but resource consumption increases making it unsuitable for resource-constrained environments
Solution Approach 1:
The patent implements a streamlined revocation list structure with fixed fields (token identifier, issuance time, expiration time) that can be efficiently stored and processed. The list is updated periodically rather than maintaining complex real-time synchronization, reducing overall resource requirements while maintaining security effectiveness
Solution Approach 2:
The revocation list is pre-populated and stored in the device's non-transitory storage medium before token validation occurs. This preliminary storage eliminates the need for complex runtime queries to external servers, reducing both memory requirements and processing overhead during critical validation operations
3Device complexity
If access tokens are allowed to expire naturally for revocation, then system simplicity is maintained, but revocation speed is insufficient for immediate access restriction
Solution Approach 1:
The system pre-populates the revocation list with tokens that need to be revoked, with their validity periods explicitly defined. When a token is added to the revocation list, the device can immediately check against this list during validation, enabling instant revocation effect without waiting for token expiration
Solution Approach 2:
The device continuously checks the revocation list during token validation operations. When the revocation list is updated with new entries, the validation process immediately reflects these changes by checking against the updated list, providing real-time feedback on token validity and enabling prompt access restriction
4Extent of automation
If continuous network connectivity is required for access revocation, then centralized control is maintained, but system reliability decreases in environments with limited or unreliable network connectivity
Solution Approach 1:
The system segments access control into independent offline validation operations and periodic online synchronization operations. The device can validate tokens against locally stored revocation lists without network connectivity, maintaining operational reliability, while periodically updating the revocation list from the server when connectivity is available
Solution Approach 2:
The revocation list is pre-stored in the device's non-transitory storage medium, enabling offline validation. The device is prepared in advance with the necessary revocation data, eliminating the need for continuous network connectivity during critical token validation operations
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
In some implementations, after one or more users have each been granted a respective access token allowing access to a resource device, revocation data is received by the resource device. The revocation data indicates that the previously granted access to the resource device should be revoked. For example, the revocation data may indicate (i) a user, role, or permission level for which access is revoked and (ii) a duration that access to the resource device was allowed. After receiving the revocation data, the resource device receives token data derived from an access token that allows access to the resource device. The resource device determines that the access token relies on authorization of the user, role, or permission level indicated by the revocation data, and in response, the resource device denies access.