About Achilles

ACHILLES provides a solution to the problem of access control and Thing authentication for the INTER-IoT platform. Access control and endpoint authentication in the IoT is a challenging problem. Things are usually small devices with limited storage capacity, power, energy, and processing capabilities, in order to be inexpensive and practical. In many cases Things are "exposed" to tampering, whereas in many application scenarios, after Things are deployed, it is not easy to access them. Things usually are not able to perform "heavy" tasks, such as complex cryptographic operations. Storing user credentials or any other sensitive information in a Thing creates security risks, adds storage overhead, and makes security management an impossible task. When it comes to interoperable applications, Things (or even gateways) cannot interpret complex business roles and processes. Moreover, companies are not willing to share sensitive information about their users with a Thing (or a gateway), even if this information is required by an access control mechanism, neither do they want to invest in yet another security system.

The ACHILLES project overcomes these limitations by allowing the delegation of security operations to a third party, referred to as the Access Control Provider (ACP), which can be implemented by a trusted separate entity, or even the service provider itself. We describe below the ACHILLES concept in the context of the use case of a "smart port." In this use case, illustrated in the following figure, port employees want to access resources provided by Things embedded in containers arriving at the port, through an INTER-IoT gateway. Container owners want to make sure that these resources can be accessed only by the port employees. On the other hand, the port authority does not want to allow third parties to access its user management system.

Using ACHILLES this problem can be overcome as follows. The port authority extends its user management system to support access control policies, as well as the ACHILLES protocol. Then, it creates an access control policy that defines who the port employees are and assigns to this policy a URI. From a high-level perspective, the user management system of the port authority can now be viewed as an RPC server: whenever a port employee makes a call to the policy URI, using as input call parameters a "token" and his identification data, the server generates and responds with an encryption key. A policy URI can then be used by container owners to protect their resources (Steps 1-3).

Each container owner "registers" its resource to the user management system of the port authority and receives back a secret key which is installed in the INTER-IoT gateway, along with the policy URI (steps 4-6). Suppose now that a port employee wants to access some information provided by a protected resource. Initially, he sends an "unauthorized request" to the gateway and receives back a token and the URI of the policy generated during step 1 (steps 7-8). Then he performs an RPC call to the user management system and obtains an encryption key (steps 9-10). With our solution, the gateway can also calculate the same encryption key, offline, without any communication with the user management system. Since both entities, i.e., the port employee and the gateway, now share the same key, they can use it for securely exchanging data.

Fact sheet

Publications

Publications in conference/workshops

• N. Fotiou, G.C. Polyzos, "Authentication and authorization for interoperable IoT architectures", Proc. 1st International Workshop on Emerging Technologies for Authorization and Authentication (Co-Located with ESORICS 2018), Barcelona, Spain, 2018 [pdf]

Master/Diploma Thesis

• S. Lepeniotis, "Access control policy definition using XACML", M.Sc. thesis, 2018
• D. Mermigas, "Access control providers and their use in access control systems", Dipl. Thesis, 2018

Presentations

• Second periodic report [pdf]
• Final report [pdf]