An entity providing cloud services (PaaS, IaaS, MaaS etc.) to its customers. It is assumed that a cloud provider is in physical control of the hardware used to provide the cloud services. Depending on the service offered the cloud provider is also in logical control over certain infrastructure aspects, e.g. if the cloud provider offers PaaS he controls the hypervisor.
A rather small component which offers a single service.
A container is the execution unit of a lightweight isolation mechanism for computer programs. Contrary to virtual machines, containers are isolated with operating system mechanism providing near baseline performance. After its initial creation, a container provides the environment stored in its image. Changes to the container do not propagate to the image.
Trusted computing base (TCB)
The set of hardware and software components which can break the security policy. Therefore one has to trust that these components are not malicious or faulty.
Trusted execution environment (TEE)
A piece of hardware which allows secure processing. Usually the achieved protection goals are confidentiallity and integrity.
A hardware-based trusted execution environment. This kind of hardware allows the execution of encrypted code on encrypted data where the corresponding plaintexts are only known inside the processor but will never leave it.
A snapshot of a container’s state that can be used to initialize new containers with the same state.
A Docker registry stores Docker images for the purpose of easy distribution comparable to the app stores of Android or iOS.
Set of all components and basic services which form the foundation to run cloud native applications (microservices) in a secure way. The SecureCloud platform can be seen as a combination of the SecureCloud runtime and the SecureCloud services.
Microservice which is developed for and execute on the SecureCloud platform.
SecureCloud runtime<a name=”SCruntime”
The SecureCloud runtime comprises the components and libraries necessary to execute an executable within an enclave. Currently there exist two implementations of the SecureCloud runtime, one is based on the Intel SDK and the other on the SCONE runtime.
Set of all basic services which form the foundation to run SecureCloud applications in a secure way. This comprises the SecureCloud infrastructure services as well as the SecureCloud platform services. Most of the SecureCloud services are implemented as SecureCloud microservice.
SecureCloud infrastructure services
These are the lower layer SecureCloud services such as scheduling and orchestration, attestation, auditing, and monitoring.
SecureCloud platform services
These are the higher layer SecureCloud services related to communication, storage, and computation.
Set of SecureCloud microservices which are orchestrated to achieve a certain purpose.
SecureCloud application operator
The entity which is in logical control of the execution of the related Secure cloud application. Usually the Secure cloud application operator utilises the SecureCloud application to fulfil some data processing for the benefit of the SecureCloud application operator.
SecureCloud application developer
The entity (or entities) that develops a SecureCloud application and provides it to the SecureCloud application operator.
A software framework, jointly developed by the SERECA and SecureCloud EU projects, allowing the trustworthy execution of *unmodified* x86 source code within Intel SGX enclaves. It consists of components enabling the execution inside enclaves such as the SCONE runtime and the C, C++, Fortran, Go, and Rust SCONE cross-compilers, components ensuring the trustworthiness of this execution and deployment in clouds such as Palaemon and SCONE client.
SCONE Docker image
A SCONE Docker image is a Docker image that contains an SCONE-enabled executable and is additionally annotated via image labels with metadata allowing the attestation of the started SCONE-enabled executable and the image’s file system content.
A SCONE container is a running instance of a SCONE Docker image.
Microservice which is a SCONE-enabled executable.
An executable created by a SCONE cross-compiler. The actual program will be executed within an enclave and utilises the SCONE runtime.
The runtime environment necessary to execute a SCONE-enabled executable. At the moment this consists of a modified C-library based on the musl library.
Compilers for various programming languages such as C, C++, Rust, Go, and Fortran which compile source code into a SCONE-enabled executable.
A program that is used to configure SCONE-enabled executables. It allows the user to push confidential configurations to Palaemon and encrypt files to ensure their content is only accessible by specific SCONE-enabled executables executed inside enclaves.
The SCONE infrastructure summarises all components necessary to deploy and run a SCONE-enabled executable. This includes Docker components like the Docker daemon and the Docker registry as well as the SCONE client and additional services like Palaemon and LAS.
Configuration and Attestation Service (Palaemon)
The Configuration and Attestation Service (Palaemon) is a component of the SCONE infrastructure. Programs executed in enclaves, in particular, SCONE-enabled executables, connect to Palaemon to obtain their confidential configuration. Palaemon provisions this configuration only after it has verified the integrity and authenticity of the requesting enclave. Additionally Palaemon checks that the requesting enclave is allowed to obtain the confidential configuration. Initially, configurations are pushed to Palaemon with the SCONE client. Palaemon also ensures — with the help of a lease mechanism — that only a well defined number of instances of a given microservice can run at the same time or in total.
Local Attestation Service (LAS)
A per-platform-service enabling remote attestation of SGX enclaves independently of the framework (i.e. SCONE or Intel SDK) used to create the enclave. It separates the development of (SCONE-enabled) SecureCloud microservices from the Intel SDK by providing a stable interface to the attestation facilities of Intel’s SDK and decouples the availability of applications deployed on the SecureCloud platform from Intel’s Attestation Service, in conjunction with Palaemon, through the introduction of an independent quoting enclave.
Process of proving the integrity and authenticity of the attestee’s software or hardware component to a verifier. This includes validating if a given software is executed on a given hardware.
Local attestation Attestation executed locally, e.g. one software component validates the integrity and authenticity of another software component which is executed on the same hardware. In Intel SGX, the CPU creates a report containing integrity information of the attested enclave whose keyed-MAC can only be verified, and changed for that matter, by the verifier enclave running on the same platform.
Attestation executed remotely, i.e. the component which does the validation and the component which is validated are executed on different machines. In Intel SGX, the report received during local attestation is signed with the quoting enclave’s private key making the integrity of the quote – the signed report – remotely verifiable.
A boot procedure which allows only the execution of firmware, bootloaders and operating systems which are digitally signed by a (well) defined set of acceptable signers.
A boot procedure which measures the state of the system at each boot step. This measurement can be accessed to verify the current state of a given system. Compared to secure boot, measured boot will not prevent an “insecure” state of the system.
Content-based routing (CBR)
CBR is a publish/subscribe approach in which clients can subscribe to messages with predicates over the message content.
Secure content-based routing (SCBR)
Security enhanced CBR where the routing engine’s memory and computations cannot be spied on by the cloud provider or any other outsider.
Concept of electricity supply network which combines bidirectional communication and information technology to monitor, control and react to changes in the production and consumption behaviour.
An electric energy meter combined with information technology and therefore capable of executing bidirectional communications, computations and storage.
Advanced metering infrastructure (AMI)
Concept of remote energy metering infrastructure based on bidirectional communication between the energy distributor and the consumer’s energy meters. AMI is the part of smart grid which concerns to smart metering systems and includes smart meters, communication metering data collection, metering data management and interface with interoperability bus to other applications.
Meter data collection (MDC)
IT system responsible for smart meters reading, configuration, control, communication management and interface with metering database.
Meter data management (MDM)
IT system responsible for data processing and analytics of all metering data. MDM includes connection to billing systems, alarm management, electrical reports and advanced features as energy balance, losses detection and interface with network planning and maintenance.