Requirements Federated Learning and mUlti-party computation Techniques for prostatE cancer, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7-eu/flute-requirements/ and changes regularly. See the Directory of published versions

2.5 PETs and security and privacy requirements

Based on the previously identified privacy and security requirements, this section shows how the PETs used by FLUTE platform can help to meet them. Following a brief introduction of SMPC and TEEs, a mapping is presented of the security and privacy requirements for individual PETs. Not all the requirements of the previous subsection are mapped to PETs because some of them can be implemented by means of more classic encryption algorithms or other techniques.

2.5.1 SMPC

Secure Multiparty Computation protocols allow a group of parties to jointly compute a function while also protecting the privacy of the participants’ inputs. An important feature that distinguishes SMPC from other more conventional cryptographic schemes is that SMPC also seeks to protect against adversaries coming from the system itself, hence protecting the privacy of the participants’ inputs from each other.

According to UN Handbook on Privacy-Preserving Computation Techniques, the use of SMPC for general secure computation can show a slowdown up to 10,000 times compared to the unprotected counterpart. In contrast, if the computation relies heavily on additions and/or integer and fixed-point arithmetic, its application can be much faster.

A common trait of the most practical SMPC solutions is the effect of increasing the communication complexity and number of rounds among participants. There is also a wide range of techniques under the label of SMPC (e.g., garbled circuits, secret sharing, etc.). The final choice is highly dependent on the number of parties and the desired computation.

2.5.1.1 Security and privacy requirements

The use of SMPC helps to implement the following requirements:

• F-SRS-4: SMPC is one of the PETs techniques used in FLUTE to protect the federated learning training, so it will be one of the techniques that can be selected in FLUTE platform for training protection.
• F-SRS-10: With the use of SMPC the aggregation could be done in a distributed way by the different data owners and the central aggregator, avoiding that the central aggregator has clear access to the local or global models.
• NF-SRS-2: SMPC is one of the PETs used in FLUTE to protect data privacy.

2.5.2 TEEs

Trusted Execution Environment (TEEs) is a highly secure, isolated space within a computer system or microprocessor. It provides a protected environment for running trusted and sensitive code, safeguarding against unauthorized access and tampering. They use cryptographic and hardware-based security to ensure code and data integrity, enhancing device security, user privacy, and protection against threats like malicious actors.

Computation in a TEE is made secure by a special hardware provided. Such a protected execution environment is often termed an enclave. Typically, the memory space of each enclave application is protected from access while resident on the processor chip, and then AES-encrypted when and if it is stored off-chip. Registers and other processor-local state of the enclave are protected from access. Code entry and exit points are tightly controlled, so that execution cannot easily switch between the enclave and the unprotected application that envelops it.

Another significant feature of enclaves is that other processes (whether local or remote) that must trust an enclave can receive attestation that the enclave is genuine, and that the code running in it (and in fact the static parts of its memory space) are exactly what is expected. Such attestation is guaranteed using cryptographic capabilities such as digital signatures and hash functions. Furthermore, attestation serves as a robust mechanism to ensure the currency of all software components. This is achieved by incorporating software measurements within the attestation report, empowering users to scrutinize and potentially decline attestation based on these measurements. This proactive approach to software integrity not only enhances security but also reinforces user trust in the system.

The utilization of Trusted Execution Environments (TEEs), in contrast to alternative privacy-enhancing technologies, exhibits no substantial performance degradation. According to the UN Handbook on Privacy-Preserving Computation Techniques, TEEs demonstrate only a marginal slowdown, ranging from 20% to 800%, when compared to unencrypted computing.

2.5.2.1 Security and privacy requirements

The use of TEEs helps to implement the following requirements:

• TEEs can be used to protect local training of models or the central aggregation, so it can be used to implement the requirement F-SRS-4 because it will be one of the techniques that can be selected in a federated learning training.
• TEEs allow to protect local models from the aggregator, even if it is honest-but-curious or malicious. Therefore, TEEs technology can help to meet requirement F-SRS-10.
• Requirement NF-SRS-2 can be implemented in part by the use of TEEs, because it is one of the PETs that is going to be used in FLUTE to protect data privacy.
• TEEs attestation protocols enforce that the software is up to date, otherwise the attestation protocol will fail. This helps to satisfy requirement NF-SRS-3.
• TEEs also provide attestation, guaranteeing that the aggregator doesn’t modify the local models or try to add new random data in the aggregation process to poison the model. This helps meet the requirement NF-SRS-5.