## 6 Performance Evaluation  
### SECOM Implementation and Validation  
#### 6.1.1 Experimental Setup  
The implementation of each component of the SECOM standard is performed using a Javascript framework called Spring Boot [25]. The framework follows a layered architecture that consists of a presentation layer, a business layer, and a persistence layer running on a 4-core Linux server with 8 GB RAM and installed using the JDK (Java development kit), Docker engine and Docker-compose in the Livorno ICT stack.  
The proposed SECOM implementation is composed of different microservices organised in three layers: the API access layer, the aggregation layer, and the application logic layer. The API access layer includes the Spring Cloud API Gateway [26] and the Keycloak [27] server for authentication and authorisation. The aggregation layer includes the Eureka [28] discovery server, the Kafka [29] message broker, and the Zipkin [30] distributed tracing system. Finally, the application logic layer consists of the ship and the SCC microservices as well as of the SECOM security suite (WebSocket, encryption, decryption, asymmetric encryption and signature creation, asymmetric decryption and signature verification, and key generator microservices). All these microservices are working independently and running in their dedicated Docker-containerised environment. To containerise all microservices, we relied on a Maven plugin called JIB [31]. Then, we added the configuration of each microservice to a Docker-compose file to be able to orchestrate the multiple interconnected services in our system implementation. Some of the dependencies used are JCA (Java Cryptographic Cypher) and JSE (Java security), which provide the core security functionalities such as secret key generation, DH public and private key generation, and encoding. In addition to these Java libraries, we also used (i) Spring Boot dependencies, such as Starter Web and Lombok [32], which provide necessary components for building web applications using the Spring MVC framework; (ii) Web Client dependency for HTTP requests; (iii) Kafka dependencies; (iv) OAuth2 client and OAuth2 resource server dependencies, which allow the client to interact with the authorisation server; and (v) dependencies for the discovery server registration.  
After configuring all this, our main purpose was to generate a shared key (using an authenticated Diffie-Hellman key) to be exchanged among the ship and the SCC for encrypting and sending an authenticated and confidential message over an unsecured public network. To achieve this, the users make a request through the API Gateway and become subscribed to the topics required for the key exchange (functionality provided by the WebSocket microservice). Consequently, it is possible to make a copy (a digital twin) of the ship and SCC microservices. However, this operation is successful only if the users are authenticated and authorised through the Keycloak server and, subsequently, are provided with an ID and an access token accordingly. In addition to the trust and key stores used for establishing the mutual TLS channel between the digital twin of the ship and the SCC microservices, we also prepared certificates and private keys using OpenSSL [33]. Once a secure communication channel is established, all microservices can interact with the SECOM security suite, synchronously or asynchronously, using the Kafka message broker, and establish a shared key. During this interaction, the Eureka discovery server is used, together with Spring Cloud API Gateway, to discover all the microservices that have been pre-registered, while the routes and interactions among the microservices are traced using Zipkin.