According to a large number of research papers, legacy access control systems cannot adequately support IoT requirements. Solutions like Identity Based Access Control (IBAC), Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), Trust-Based Access Control (TBAC), just to mention the best-known ones, fall short of providing the necessary functionality and security features. (Newer approaches, some of them based on blockchain, also could not deliver the right answers yet.)
The need for scalability, to be able to support potentially millions of devices and a large number of sometimes ad hoc users are too demanding for solutions which initially were created for well defined, controlled homogenous environments. Furthermore, these systems cannot cope with the distributed nature of most IoT services, are too demanding on resource-constrained, simple devices, and also the complex interoperability of collaborative systems stresses them beyond their capabilities.
Besides the operational shortcomings, there are also important security issues which the legacy access control systems cannot adequately solve. Enforcing the least privilege principle seems to be a real challenge, the confused deputy problem is also an open issue, just like right delegation with a documented audit trail, as well as real-time, sometimes only temporary, right issuance and revocation.
It seems that the Capability-Based Access Control (CBAC) system is more suitable for the IoT domain. Capability is a token, a key which holds a privilege assigned to its holder. When the requester intends to perform the action associated with the token it needs to send the request and the token to the gatekeeper/provider, which entity only needs to check the validity of the token. This usually means checking that the digital signature of the token is not corrupted. In case the token is valid and intact the request can be fulfilled, without further authenticating the requester or checking its privileges, as these actions have already been performed, when the token was prepared/issued by the authorization server. This procedure simplifies the system as no user list, or access rules need to be maintained at the point of access control, which task may also be performed by a resource-constrained device itself.
Capability based access control is a suitable solution for distributed architectures and resource-constrained devices. It can also support fine-grained right allocation satisfying the least privilege principle.
However, CBAC still has some remaining limitations. Delegation of privileges with the proper audit trail is still an issue, just like real-time token issuance and revocation. CBAC also introduces a new and major security challenge which is the necessary protection of the tokens from theft or replay.
The weakness of the CABC solution is inherent in its architecture. If the transaction flow is to be accelerated, then the token needs to be issued in advance which creates the new security challenge because in this scenario the token needs to be stored and protected by its holder. If, however, the token is generated as the first part of the transaction process, then it must be assured that the authorization server is always online, available (this requirement in itself is a potential single point of failure) and this additional communication and the performance of the actual authentication by the authorization server slows down substantially the actual transaction.
The new Front-End Access Control (FEAC) solution to be implemented by the IoTAC project leverages the benefits of Capability-Based Access Control and also removes its weaknesses. It can protect the credential tokens, it does not need always-on authorization server support, it can delegate privileges, and can also issue and revoke tokens real-time.
The advantageous capabilities of FEAC are the result of the
- use of secure element (chip card) on the user side
- delegation of the authorization server’s function of token generation.
FEAC breaks up the token generation and token presentation process into two parts.
In the first part, let’s call it pre-transaction phase, the user (requester) registers with the Authorisation server and requests privileges. The authorisation server authenticates the user and decides which privileges may be granted. The authorisation server prepares the privileges (credentials) and loads it/them to the user’s secure element, chip card. Loading of the credentials may be performed off-line, by sending a personalized chip card to the user, but the preferred scenario is the over-the-air personalisation of the user’s chip card.
During the transaction phase, the user needs to request a token from its own secure element. The user first authenticates itself with the chip card, then the card validates the request, and if the request may be granted then generates a token. This is a similar token to what the Authorisation server generates in a CBAC transaction and as such the resource server has nothing else to do than check the validity of the digital signature and execute the request.
By assigning an individual secure element to the user, the protection of the privileges is assured, all the tokens are unique, and the user/requester can only execute transactions for which it has the necessary privileges. The transaction is either faster or more secure or both, than that of a traditional CBAC one.
There is a valid question, however, which is related to usability. How can a user have access to a secure element/chip card and how can it be conveniently used? This question will be answered in my next post.
