In this article we present the work performed under the first development period of the PrEstoCloud framework as far as security aspects are concerned. PrEstoCloud aims to deliver a framework which allows the deployment of complex applications on top of diverse computational resources which span from data center resources to edge resources. For such an operational environment with diverse resource types it is important to provide proper mechanisms that guarantee a certain level of security on multiple layers of the architecture. The security mechanisms providing this multi layered protection in PrEstoCloud are the following: a) perimeter security, b) end-to-end encryption and c) adoption of TPM based trusted computing.
In PrEstoCloud we provide perimeter security at the component level, through the usage of eXpress Data Path (XDP)/eBPF sophisticated state of the art technology for kernel-based packet processing. The implemented perimeter security mechanism allows high performance dropping of traffic from unknown or well-known malicious sources, based on perimeter-security policies that can be defined from PrEstoCloud UI.
In PrEstoCloud we have application components that need to communicate within data center resources while but also with the edge resources. In general, data center resources are already protected by the network manager of the correspondent IaaS provider; hence, VMs that belong to the same administrative zone belong to an existing overlay that share a uniform isolation policy. On the other hand, as far as edge resources are concerned, this assumption is not true since there is lack of isolation. Conclusively, raw computational resources that are onboarded in an edge cluster must be able to trust each other and communicate securely. These requirements have been covered by the incorporation of Cjdns protocol in the PrEstoCloud device stack. Through this protocol mutual trust of resources (that join and leave the cluster dynamically) is achieved along with point-to-point encryption on layer-3. CJDNS has the ability to create encrypted overlays. More specifically, Cjdns is using asymmetric encryption principles in order to achieve trust among mesh nodes. To this end, each node is generating a public-private key and peer-acceptance is bound to the exchange of public key. However, the protocol allows the “blind” acceptance of peer requests. Irrelevant of the peer-acceptance mode, the routed traffic within the overlay is encrypted at the peer level.
In PrEstoCloud we have to deal with resources at both cloud and edge and therefore, the trust on the resources that are used for the deployments is important. And as far as untrusted resources are concerned, the proposed countermeasure is the adoption of a TPM module. Trusted Platform Module (TPM) is a cryptographic coprocessor, a devoted microcontroller or chip, intended to protect hardware by joining cryptographic keys into devices. In addition, TPM is a standard for a protected crypto processor and has been included on most PCs and laptop motherboards produced in the past decade. TPM is the core component of trusted computing and includes capabilities such as random number generation, secure generation of cryptographic keys, remote attestation and sealed storage. A variety of vendors such as Infineon, Broadcom, Atmel, STMicroelectronics, and Nuvoton produce TPM chips, while many PC manufacturers shipping TPM-enabled PCs such as Dell, Lenovo, HP, Toshiba, and Fujitsu. A TPM module can be used in a hardware version or even in a virtualized version. For PrEstoCloud we not enforce, but we suggest and support the usage of TPM-enabled devices, for the apps that are orchestrated by the orchestration component.
A fully functional proof-of-concept was implemented, according to which, specific applications that were orchestrated through the platform used TPM function calls. The proof of concept was dedicated to ARM-based processors since the need of trust assurance is bigger in the case of edge resources.
More information about the security mechanisms of PrEstoCloud can be found in the deliverable D5.7.