Prototype Implementation. We implemented a proof of concept of the key agreement scheme. A desktop computer was used as a coordinator. A surveillance camera (Axis 207MW [20]) and a PDA (Personal Digital Xxxxx- xxxx; Nokia N800 [21]) were used as home devices. The prototype scenario involved the home devices registering to the computer and the PDA fetching images from the camera using the group key ob- tained using the LKH [18] protocol. An unregistered PDA trying to masquerade as a device that was previously part of the network was not able to rejoin the network or fetch the images from the surveillance camera. Leaving, rejoining, and other interactions between devices in the network that did not require user input did not impose any latencies that were observable to a user.
Prototype Implementation. The Trust Management Framework designed in deliverable D4.1 included various modules: Trust Information Sources, Trust Assessment, Trust Results and Evidence Storage, and Trust Level Update. The current prototype covers in terms of modules and interfaces the Trust Information Source and the Trust Results and Evidence Storage modules. Instead, Trust Assessment and Trust Level Update modules are in an early implementation phase at the time of release of this deliverable (they will be part of the 5GZORRO full release). Regarding the communication paradigm employed by the Trust Management Framework, it follows both a request/response paradigm and a publish/subscribe paradigm. The former is utilised by the 5GZORRO modules that need to launch the trust lifecycle, for instance, the SRSD. The latter is used by the Trust Management Framework itself in order to retrieve historical trust information, recommendations, and new events or triggers, as well as to send trust information about a stakeholder. In the case of publish/subscribe communication paradigm, such a framework will utilise the common Xxxxx instance which will be shared with other 5GZORRO modules (intra- and cross-domain communication fabric). The definition of the Trust Management Framework interfaces is available in the following GitHub page: xxxxx://0xxxxxx.xxxxxx.xx/Trust-management-framework/. Concerning the virtualization technology used for the software package, this module is released as a Docker container to facilitate orchestration and delivery together with other 5GZORRO modules.
Prototype Implementation. With a focus on the SCONE framework to enable TEE capabilities, a proof of concept was prepared to validate the integration of TEE with the orchestration services. A Docker container was deployed in a virtual machine with SGX-enabled capabilities in a Kubernetes cluster with two nodes, one with SGX-enabled capabilities from the cloud provider Azure [10] and another without those capabilities placed in an OpenStack instance. In this scenario, an application can run in a shared environment (i.e., OpenStack, Cloud, on-prem) without the need for services to trust in each other; in other words, the application can run in a non-trusted shared environment, since only the application itself (with the hashes generated by a special service called CAS, described below) can see its own security-relevant and runtime information. Every other service or other tenant will see encrypted information at runtime or at rest. The adopted SCONE framework for TEE is based on four main components that allow deploying an application in a secure environment: • Session: Entails all security-relevant details of a SCONE application. It includes every aspect of the container ecosystem such as commands to be executed on images, secrets, volumes and environment variables. Everything is then attested with the unique signature of the enclave which is authorized to retrieve the secrets from the CAS; • LAS (Local Attestation Service): Service that runs locally, alongside the enclave, and the application that wants to access the secrets. This service is responsible to complete the application attestation and ensure that the hardware is SGX-enabled and share that information with CAS; • CAS (Configuration and Attestation Service): Remote service which stores things like configurations, secrets and filesystem keys needed by the application in runtime, that were provided by the session. This service ensures that all secrets are protected from being visible by humans and are only visible inside the TEEs. These secrets and configurations will then be put in transit and shared with the application once the attestation takes place (when the application proves its integrity and authenticity);
Prototype Implementation. In the current prototype, an initial version of the entire set of interfaces has been implemented to verify its suitability and to test the desired functionalities. However, this implementation only covers the functional requirements to successfully establish a secure connection between domains. The functionalities which will be implemented for the next release are: a) Client-to-gateway and gateway-to-gateway authentication; b) Integration with the Identity and Permission manager module for key management. The prototype is implemented following a request/response setup based on a Restful API. The definition of the interfaces is available as Swagger file at xxxxx://0xxxxxx.xxxxxx.xx/inter-secure-channel-setup/#/ The prototype has been implemented using Python 3, with the following additional packet requirements: • flask and flask_restful, for the Restul API setup [15] • Gevent, for networking management [16] • Werkzeug, for the WSGI server [17] For the VPN service setup and management, WireGuard VPN [3] has been leveraged. WireGuard is an open- source software implementing VPNs with state-of-the-art cryptography and an easy setup. This tool aims to provide faster connections than previous solutions such as IPSec [4] or OpenVPN [5]. WireGuard works in a client-server setup in which VPN connections are added using new network interfaces. This configuration enables to have different VPN connections to different domains in the same client. The only configuration needed is to define which IP range is redirected to each WireGuard interface. To enable the automated installation and configuration of WireGuard, the module includes an interface named "launch" which is in charge of deploying WireGuard in the target machine and of configuring the required network properties to enable traffic forwarding. Additional packets installed during setup are linux- kernel-headers and openresolv. The GitHub repository of the module is available at: xxxxx://xxxxxx.xxx/5GZORRO/inter-secure-channel- setup. The current prototype is released in the form of a Virtual Machine (VM) as the module is intended to be deployed in gateways (which are rarely deployed as containers). However, it might be possible to deploy the module in containers if the required dependencies are fulfilled.
Prototype Implementation. The current ISSM-WFM prototype executes Workflow 3-6, Trustworthy Slice Setup with Third Party Resources, reported in D2.3. The prototype implementation can be found in xxxxx://xxxxxx.xxx/5GZORRO/issm/. As such it can be considered as fully implemented. The definition of the business flow implementing Flow 3-6 of D2.3 can be found in xxxxx://xxxxxx.xxx/5GZORRO/issm/blob/master/flows/issm-sensor.yaml. Additional business flows will be realized as the rest of 5GZORRO platform matures and will be reported in deliverable D4.3.
Prototype Implementation. The ISSM-O prototype has been implemented in simulation for this deliverable and its integration within the ISSM architecture for the 5GZORRO platform is planned for the next 5GZORRO release. Optimization solvers such as OptaPlanner (xxxxx://xxx.xxxxxxxxxxx.xxx/) and Gurobi (xxxxx://xxx.xxxxxx.xxx/) are being evaluated for integration as part of ISSM-O implementation. Full description of the implementation of the ISSM-O module, its functional validation, and its integration with the rest of ISSM for inter-domain optimization will be reported in D4.3.
Prototype Implementation. The prototype covers all the modules of the NSSO and is built upon the following software components: • Vertical Service Manager: Containerized deployment of the vertical service management function available in [36]. This module contains the driver to interact with network slice manager from [36] . • Generic-purpose NSMF: Containerized deployment of the network slice management function available in [36]. This module contains the drivers to interact with the MDA and with the e-Licensing Manager, using the APIs established in [40][41].
Prototype Implementation. The e-Licensing Manager (eLM) makes use of OpenAPIs to communicate with external services such as the Marketplace and the NSSO. These interfaces are based on REST and are available through the eLMC Swagger console which will be accessible under <eLMC-URL>:8080/ui. At this moment, the final deployment environment is not yet defined but an extensive set of tests have been carried out in a ATOS’s testbed and are defined in section 4.3.3. Internal communications between the different microservices that build up eLMC and xXXX are based on AMPQ protocol by making use of a RabbitMQ Broker which is initially deployed along with the eLMC. This choice enables the 5G Platform to seamlessly grow horizontally by including new Operators. The xXXX has three inner components:
Prototype Implementation. Provision of technical assistance, training, study tours, equipment and vehicles and carrying out of premises reconfiguration for the development of a mixed manual, semi-automated and automated information systems to handle the modernized operational functions of, inter alia, taxpayer registration, tax accounting and declaration process, encompassing: (i) business logic development, including, as appropriate, forms revision; (ii) technology platform development, including, inter alia, processing, storage, data and voice communications; (iii) user training, including information technology and operational training; and (iv) technical training for systems staff and responsible managers.
Prototype Implementation. The prototype trap receiver is a simple Java program which listens to incoming UDP transmissions which come into the program server and are directed to the default SNMP trap port (UDP 162). The program consists of two Java resources: UDPServer.java and SNMPMessageReader.java. For the program to function, the open source SNMP4J library should be imported, as well as some standard Java libraries. The configuration within the device that connects to the trap receiver should be done as described in Section 5.1 in order for the prototype to receive the traps. From the SNMP message, the application takes the SNMP version that the device is using as well as the IP address and the device type. Once the coldStart trap is detected, the application understands that a new device has been deployed in the substrate and wishes to connect. When a datagram directed to this IP and UDP port is received through a socket, the program stores the datagram source IP address which identifies the device that sent the datagram. Based on data in the SNMP datagram, the prototype is able to identify the device that wishes to connect. Currently, a MX‐480 router, a J‐3250 router and an EX‐3200 switch can be identified by the prototype. The source IP address and the device type are all the information necessary for the FEDERICA Slice Tool to start communicating with the new device. The prototype has been successfully tested on a local testbed consisting of Juniper devices. Therefore, in the code some fixed IP addresses can be found. In the actual implementation, these IP addresses should be replaced with the IP addresses in use by the local device and the NOC. The complete device configuration is an option that is already available in the FEDERICA Slice Tool. This registration step is currently done manually. After an integration process, the registration step could be done automatically by the FEDERICA Slice Tool, minimizing the manual configuration to a simple configuration (explained previously in Section 3.1) in the devices before deploying them in the physical substrate. A recommended future implementation would be the integration of the prototype into the current FEDERICA Slice Tool.
