The Front-end Access Management (FEAM) system will be deployed at each of the four pilot locations. The four pilots are the smart home in Greece, the prosumer cell operation in Hungary, the connected car in Spain and the drone operation in France.
In all the four cases the core security functions, the hosting of the users’ secure elements, chip cards, and their secure applications, will be provided by a card farm.
The card farm will have a multireader – this device is also a development of the IoTAC project – which will host 16 JAVA chip cards each storing seven IoTAC user secure applications. All in all, this architecture will be able to serve more than 100 users and if necessary, the number of deployed multireaders can be increased, the operation is flexibly scalable.
Although the four pilots will be located at four different geographic locations and will have completely independent architectures, one single card farm, which is a multi-tenant cloud-based operation, will provide security services for all of them. This operation will be maintained and supported by ATOS Hungary.
The Management modules of the four FEAM services will initially be run remotely from the architecture of SafePay. Four independent modules, one for each operation, will be installed and configured. Initially these modules will not be integrated with the legacy architecture of the pilot services. Their databases, in terms of available functions, operations, the list of users and their privileges will be populated manually. In the second pilot cycle some deeper level of integration may be possible, but it is not a major target of the exercise.
Figure 1: FEAM Architecture
The Management module is the FEAM component which establishes the link between the local pilot operations and the card farm. The four Management modules will be registered with the card farm, each of them will have a number of secure elements allocated, and these dedicated chip cards will be assigned to their respective users.
It is the Resources server, or Gateway module of FEAM which must be deployed locally at each of the pilot locations. It is also possible to have more than one Gateways for any of the pilot operations should the architecture require more than one access points. The Management module will remotely configure and manage the Gateway(s) which belong(s) to its specific operation. Configuration comprises key exchanges and the generation of certificates, while the operation covers the synchronisation of operating constrains and the collection of service logs.
In the first pilot cycle each FEAM Gateway module will be running on local servers connected through an API to the secure internet gateway of the pilot operation, while in the second phase of the operation, a tighter integration is foreseen, and the modules will be hosted by the gateway device itself.
As FEAM will become an integral part of the pilot architectures and operations some level of integration will be inevitable.
On the front-end, user side, the legacy service application (we call it Host application) must be integrated with the FEAM Library and they jointly become the FEAM Client. The FEAM Client may be a mobile or desktop application and both will be demonstrated in one or the other pilot operation. The FEAM library has the task to perform all the FEAM specific functions on the user side. It should receive the original command from the Host application, which without FEAM would be directly sent by the Host app. to the pilot architecture. The FEAM library then communicates with the Card farm, have the command approved by the user secure application, establishes secure communication with the Gateway module and transmits the command to the Gateway. The FEAM Library also receives a response from the Gateway about the result of the operation, or a content, which it passes on to the Host application. There is an API specification available which describes how the Host application should communicate with the FEAM Library.
At this point we expect that at the back-end the Gateway module just needs to be configured to communicate with the protected system, the pilot architecture. The Gateway will transmit the same message/command to the legacy environment which without FEAM, would have come directly from the Host application. The legacy operation should not be changed at all, should not even realize that a robust security mechanism has been integrated into the overall operation.
