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.
The ACHILLES project will incorporate the above concept into the INTER-IoT platform in order to achieve the following objectives: O1: To develop an open protocol that will allow existing user management systems to be used for access control, by all layers of the INTER-IoT platform. Policies will be built and managed in these systems and Things and gateways will be oblivious to them. O2: To allow providers to offer secure services without putting much trust to the Things or the gateway, protecting at the same time end-user privacy. Things and gateways will only have to follow a simple communication protocol and will not have access to any information related to end- users. O3: To facilitate interoperability, innovation, and B2B services, by allowing the use of (pointers to) policies (e.g., https://companyA/customers) without needing to have access to the policy implementation details (e.g., who the customers of Company A are). O4: To facilitate security management, by enabling access control policy modifications without communicating with the Things (or gateways). Service providers will be able to modify security policies even after Things and gateways have been deployed. O5: To develop tools that will allow Things-gateway mutual authentication, and appropriate APIs for the INTER-FW that will allow end-users to create and access protected resources.