聚合支付安全吗_将安全聚合整合到TensorFlow中

聚合支付安全吗

With Morten Dahl and Yann Dupis.

与Morten Dahl和Yann Dupis一起 。

Summary. We introduce a secure aggregation protocol into TensorFlow Federated based on encryption primitives from TF Encrypted. This post describes our motivation, presents the protocol, and highlights interesting details of our implementation. We assume some technical familiarity with TensorFlow Federated, secure aggregation, Paillier homomorphic encryption, and public key cryptography. We’ve open-sourced our code here.

摘要。 我们基于TF Encrypted的加密原语在TensorFlow Federated中引入了安全聚合协议。 这篇文章描述了我们的动机，介绍了协议，并突出了我们实现的有趣细节。 我们假设有一些技术的熟悉TensorFlow联合 ， 安全的聚集 ， Paillier同态加密和公钥加密 。 我们已经在这里开源了我们的代码。

The post is structured as follows:

该职位的结构如下：

• Overview
  总览
• Protocol & subprotocols
  协议和子协议
• Implementation details: Integration strategies
  实施细节：整合策略
• Implementation details: Implementing the secure sum
  实施细节：实施安全金额

总览 (Overview)

The TensorFlow ecosystem currently has three core pillars for privacy-preserving machine learning (PPML):

TensorFlow生态系统目前具有三个用于保护隐私的机器学习(PPML)的核心Struts：

• TensorFlow Federated for federated computation (TFF)
  TensorFlow联合进行联邦计算(TFF)
• TensorFlow Privacy for differentially private learning
  TensorFlow Privacy用于差异化私人学习
• TF Encrypted for encrypted computation (TFE)
  TF加密，用于加密计算(TFE)

TensorFlow Federated (TFF) provides the Federated Core language for federated computation, as well as a set of higher-level Federated Learning APIs. These could easily benefit from primitives for encrypted computation built into TF Encrypted (TFE). For example, one may want to protect client data from the server in a federated platform like TFF, in which case some kind of secure aggregation protocol is necessary. Ideally, using TFE to build secure aggregation into TFF would be seamless. However the libraries developed separately, so there are no obvious integration points.

TensorFlow联合(TFF)提供了用于联合计算的联合核心语言以及一组更高级别的联合学习API 。 这些可以很容易地受益于TF Encrypted(TFE)中内置的用于加密计算的原语。 例如，可能希望在TFF之类的联合平台中保护客户端数据免受服务器攻击，在这种情况下，某种类型的安全聚合协议是必需的。 理想情况下，使用TFE将安全聚合构建到TFF中将是无缝的。 但是，这些库是单独开发的，因此没有明显的集成点。

This situation led Morten to author an RFC for integrating TFE with TFF. As a first attempt, our team decided to build a specific secure aggregation protocol in TFF using primitives from TFE. We implement a passively secure version of the tff.federated_secure_sum intrinsic, which is currently left unimplemented in TFF’s native backend. Our work is aimed at users of the Federated Core, but could eventually be exposed to the higher-level tff.learning API as a custom tff.templates.IterativeProcess (e.g. for use with Keras). For those interested in using it to train models, the recently added tff.utils.secure_quantized_sum would be a great place to start.

这种情况导致Morten编写了将TFE与TFF集成的RFC 。 作为第一个尝试，我们的团队决定使用TFE中的原语在TFF中构建特定的安全聚合协议 。 我们实现了tff.federated_secure_sum内部函数的被动安全版本，该版本目前在TFF的本机后端中未实现。 我们的工作针对联合核心的用户，但最终可能会作为自定义tff.templates.IterativeProcess (例如，与Keras一起使用)暴露给更高级别的tff.learning API。 对于那些有兴趣使用它来训练模型的人来说，最近添加的tff.utils.secure_quantized_sum将是一个不错的起点。

import tensorflow as tf
import tensorflow_federated as tff
from federated_aggregations import paillier


paillier_factory = paillier.local_paillier_executor_factory()
paillier_context = tff.framework.ExecutionContext(paillier_factory)
tff.framework.set_default_context(paillier_context)


# data from 5 clients
x = [np.array([i, i + 1], dtype=np.int32) for i in range(5)]
x_type = tff.TensorType(tf.int32, [2])


@tff.federated_computation(tff.FederatedType(x_type, tff.CLIENTS))
def secure_paillier_addition(x):
  return tff.federated_secure_sum(x, bitwidth=32)


result = secure_paillier_addition(x)
print(result)
>>> [10 15]

We use Paillier homomorphic encryption to perform the secure sum, and we use standard public key cryptography to ensure no party can learn values that they shouldn’t have access to in transit. We differentiate between two central parties, the Server (holding the Paillier decryption key) and the Aggregator (aggregating Paillier encrypted values). We assume that these two parties will not collude. Our implementation is designed with cross-silo federated learning between organizations in mind. Cross-silo is distinct from cross-device learning in that organizations can typically provision highly available servers of varying compute resources, which is generally not true of cross-device learning on mobile phones or embedded devices. In particular, some of the dependencies we rely on may not be suitable for mobile/embedded execution.

我们使用Paillier同态加密来执行安全总和，并且我们使用标准的公钥加密来确保任何一方都无法学习他们在传输中不应该访问的值。 我们将服务器(持有Paillier解密密钥)和聚合器(聚合Paillier加密值)这两个中央方区分开。 我们假设这两方不会共谋。 我们的实现在设计时考虑了组织之间的跨部门联合学习。 跨仓库与跨设备学习的区别在于，组织通常可以提供具有不同计算资源的高可用性服务器，这通常不适用于移动电话或嵌入式设备上的跨设备学习。 特别是，我们依赖的某些依赖项可能不适用于移动/嵌入式执行。

协议和子协议 (Protocols & subprotocols)

Our protocol is a composition of two well-known primitives — Paillier homomorphic encryption and authenticated public-key encryption. We assume the existence of three distinct sets of parties; several Clients, one Server, and one Aggregator. These correspond to placements in the TFF language (note that the Aggregator is a new placement we’ve introduced). The goal of the protocol is for the sum of the Clients’ input values to be realized on the Server, without the Server learning any of the input or intermediate values. Informally, we encrypt the client values according to the Paillier crypto-scheme, and then send these ciphertexts to the Aggregator to perform the encrypted addition. The Server maintains the only copy of the decryption key, so neither party ever has possession of the clients’ ciphertexts and the decryption key, thereby preserving the privacy of the clients’ inputs. The animation below illustrates this secure sum.

我们的协议由两个众所周知的原语组成-Paillier同态加密和经过身份验证的公钥加密。 我们假设存在三组不同的政党。 几个客户端，一个服务器和一个聚合器。 这些对应于TFF语言中的展示位置 (请注意，聚合器是我们引入的新展示位置)。 该协议的目标是使客户端的输入值之和在服务器上实现，而服务器不学习任何输入值或中间值。 非正式地，我们根据Paillier加密方案对客户端值进行加密，然后将这些密文发送到聚合器以执行加密加法。 服务器维护解密密钥的唯一副本，因此任何一方都不会拥有客户端的密文和解密密钥，从而保留了客户端输入的私密性。 下面的动画说明了此安全金额。

The secure sum protocol (Paillier aggregation)

安全和协议(Paillier聚合)

However, since the Aggregator placement is something we’ve introduced, TFF does not support direct communication between the Aggregator and Clients. In particular, TFF requires all communication to pass through the driving Python script (aka driver program), and this program is usually collocated with the Server role. Thus, in order to pass values from the Clients to the Aggregator, we must route the Clients’ ciphertexts through the Server. However since the Server holds onto the Paillier decryption key, they will have a temporary opportunity to decrypt client ciphertexts, which would be a security violation.

但是，由于我们已经介绍了Aggregator的位置，因此TFF不支持Aggregator和Client之间的直接通信。 特别是，TFF要求所有通信都通过驱动Python脚本(也称为驱动程序)进行传递，并且该程序通常与服务器角色并置。 因此，为了将值从客户端传递到聚合器，我们必须通过服务器路由客户端的密文。 但是，由于服务器保留了Paillier解密密钥，因此它们将有暂时的机会解密客户端密文，这将违反安全性。

We use a second protocol for securely communicating values from the Clients to the Aggregator, with the Server acting as an honest-but-curious router. This subprotocol uses a standard encryption implementation from libsodium for authenticated encryption. The graphic below illustrates the details of this protocol.

我们使用第二种协议将值从客户端安全地传递到聚合器，而服务器充当诚实但又好奇的路由器。 该子协议使用来自libsodium的标准加密实现进行身份验证加密 。 下图说明了此协议的详细信息。

The secure communication protocol

安全通讯协议

Composing these two subprotocols together yields our complete secure aggregation. They compose cleanly, since the secure communication protocol is only replacing the communication of ciphertexts from the Clients to the Aggregator in our idealized Paillier aggregation. In our implementation, this corresponds to a double-encryption of the raw client inputs, where the inner encryption layer is based on Paillier and the outer encryption layer uses libsodium. The entire process is illustrated below.

将这两个子协议组合在一起就可以构成我们完整的安全聚合。 由于安全的通信协议仅替代了我们理想化的Paillier聚合中从客户端到聚合器的密文通信，因此它们组成的内容整洁。 在我们的实现中，这对应于原始客户端输入的双重加密，其中内部加密层基于Paillier，外部加密层使用libsodium。 整个过程如下图所示。

The complete protocol (composition of secure communication and secure sum)

完整的协议(安全通信和安全总和的组成)

This concludes the presentation of our protocols. If you’re interested in the code, it has been open-sourced here. Please try it out, and let us know what you think!

这样就结束了我们协议的介绍。 如果您对代码感兴趣，它已在此处开源。 请尝试一下，让我们知道您的想法！

整合策略 (Integration Strategies)

TF Federated is a complex framework, and even a simple aggregation like tff.federated_secure_sum is non-trivial to re-engineer. In the rest of this post, we describe our integration strategy and implementation in more engineering detail. While we learned a lot throughout the process, much of our rationale comes from our original RFC. We describe three potential integration strategies for adding new execution patterns to TFF:

TF Federated是一个复杂的框架，即使是简单的聚合(如tff.federated_secure_sum )，对于重新设计也是很重要的。 在本文的其余部分，我们将以更详细的工程细节描述我们的集成策略和实现。 尽管我们在整个过程中学到了很多东西，但我们的基本原理还是来自原始的RFC 。 我们描述了三种向TFF添加新的执行模式的潜在集成策略：

1. Non-native backend
   非本地后端
2. Native backend: custom remote execution via gRPC endpoint
   本机后端：通过gRPC终结点自定义远程执行
3. Native backend: custom Executor
   本机后端：自定义执行器

We then analyze why none of these are immediately suitable for our needs, and detail our chosen integration strategy. Note that this is not an exhaustive list of the different development APIs that TF Federated supports.

然后，我们分析为什么这些都不立即适合我们的需求，并详细说明了我们选择的集成策略。 请注意，这并不是TF Federated支持的不同开发API的详尽列表。

We are hoping to implement a specific functionality in TFF’s Federated Core (FC). As mentioned in the official documentation, the FC is a functional language for federated computations. Thus, in TFF, how users express federated computations separates cleanly from how federated computations are executed. This presents the first potential integration strategy, through what’s known as a non-native backend. In this strategy, we would only use TFF for the FC and its compiler; the native TFF backend, including the entire Executor stack framework, would be left out. The native TFF runtime has a number of nice features that we would like to benefit from, including automatic thread management, GPU support through the TensorFlow runtime, as well as a gRPC service for remote execution. We would also rather not reimplement federated intrinsics that the native backend provides, for example tff.federated_map, tff.federated_broadcast, and the rest. However, the native backend can also be limiting for certain use cases. For example, clients’ processes can only ever inspect local computations that they are responsible for, since the native backend’s usual Executor stacks implicitly erase information about the global federated computation during compilation. Additionally, the native backend seems to assume that the driver program is collocated on the Server’s host, which introduces a communication bottleneck with the security implications mentioned earlier. Both of these considerations lead us to believe that the native backend would not be sufficient for a production ready system. However, since production-readiness is beyond the scope of our prototype, we decided to work with the native backend for its other benefits.

我们希望在TFF的联合核心(FC)中实现特定功能。 如官方文档中所述，FC是用于联合计算的功能语言。 因此，在TFF中，用户如何表达联合计算与联合计算的执行方式完全不同。 这通过所谓的非本机后端提出了第一个潜在的集成策略。 在这种策略中，我们仅将TFF用于FC及其编译器； 包括整个Executor堆栈框架在内的本地TFF后端将被排除在外。 原生TFF运行时具有许多不错的功能，我们希望从中受益，包括自动线程管理，通过TensorFlow运行时提供的GPU支持以及用于远程执行的gRPC服务。 我们也宁愿不重新实现本机后端提供的联邦内部函数，例如tff.federated_map ， tff.federated_broadcast以及其余的。 但是，本机后端也可能会限制某些用例。 例如，客户的进程只能检查他们负责的本地计算，因为本机后端的常规执行程序堆栈在编译期间会隐式擦除有关全局联合计算的信息。 此外，本机后端似乎假设驱动程序位于服务器的主机上，这带来了通信瓶颈，并带来了前面提到的安全隐患。 这两个考虑因素使我们相信，本机后端不足以用于生产就绪系统。 但是，由于生产就绪性超出了我们原型的范围，因此我们决定与本机后端一起使用，以获取其他好处。

One way to integrate with the native backend would be to implement a gRPC endpoint for the client-side of TFF’s RemoteExecutor service. This is most useful for those who want to replace the Python-based client runtime without throwing away the entire server-side of the stack. For example, if we only wanted to add a client runtime for training on mobile phones, this integration strategy would be perfect. However, we don’t want to replace the entire client runtime here; we just want to add a few operations to enable client-side encryption. We also need to introduce functionality not available in the native client runtime for TFF, including server-side decryption and a new Aggregator placement, so this would not even be sufficient for our needs.

与本机后端集成的一种方法是为TFF的RemoteExecutor服务的客户端实现gRPC端点。 对于那些希望替换基于Python的客户端运行时而不丢弃整个服务器端的用户而言，这非常有用。 例如，如果我们只想添加客户端运行时以进行手机培训，那么这种集成策略将是完美的。 但是，我们不想在这里替换整个客户端运行时。 我们只想添加一些操作来启用客户端加密。 我们还需要引入TFF的本机客户端运行时中不可用的功能，包括服务器端解密和新的Aggregator放置，因此，这甚至不足以满足我们的需求。

Finally, we can implement a custom Executor for use in the native backend. These executors are designed to be completely modular with each other, so handling of federated computations is kept separate from features like remote execution, caching, thread management, and execution on the TensorFlow runtime. For our purposes, this immediately offers some benefits over the prior two strategies. If we concern ourselves exclusively with the executors involved in federated orchestration, we can retain most features of the native backend, and we also won’t have to implement an entire client runtime.

最后，我们可以实现一个自定义的Executor，以便在本机后端中使用。 这些执行程序设计为彼此完全模块化，因此，联邦计算的处理与远程执行，缓存，线程管理以及在TensorFlow运行时上执行的功能保持分离。 就我们的目的而言，与前两种策略相比，这立即带来了一些好处。 如果我们只关心与联合编排有关的执行者，则可以保留本机后端的大多数功能，并且也不必实现整个客户端运行时。

After some investigation, we found that there were multiple executors involved in federated orchestration, including (at the time) the FederatedExecutor and the ComposingExecutor. Introducing an entirely new Executor class to replace these seemed excessive for our goal of adding a single intrinsic. Our initial stab at doing so coincided with some refactoring the TF team was planning for these Executors. We began collaborating with them on these changes, resulting in the tff.framework.FederatingStrategy released in v0.15.0. We use this FederatingStrategy abstraction to implement our own PaillierAggregatingStrategy, which modifies the behavior of FederatingExecutor to include our implementation of tff.federated_secure_sum.

经过一番调查，我们发现联邦编排中有多个执行者，包括(当时)FederatedExecutor和ComposedExecutor。 对于我们添加单个内在函数的目标而言，引入全新的Executor类来替换这些类似乎过于多余。 我们这样做的最初动力是与TF团队为这些执行者计划的重构相吻合。 我们开始与他们合作进行这些更改，从而在v0.15.0中发布了tff.framework.FederatingStrategy 。 我们使用这个FederatingStrategy抽象来实现我们自己的PaillierAggregatingStrategy，该策略修改了FederatingExecutor的行为以包括我们对tff.federated_secure_sum的实现。

实施安全总和 (Implementing the secure sum)

Our tff.federated_secure_sum implementation is itself noteworthy, because it requires functionality not included in TensorFlow’s default runtime. Since we’re relying on TFF’s native backend, the TFF compiler is responsible for transforming tff.federated_secure_sum into a series of TFF Computation protobufs. These Computations often represent TensorFlow graphs, which are eventually executed by the TensorFlow runtime on the Server, the Clients, or the Aggregator. According to the protocol above, here is a list of operations we need to make available to the runtime:

我们的tff.federated_secure_sum实现本身值得注意，因为它需要TensorFlow的默认运行时中未包含的功能。 由于我们依赖TFF的本机后端，因此TFF编译器负责将tff.federated_secure_sum转换为一系列TFF计算原型 。 这些计算通常代表TensorFlow图，最终由TensorFlow运行时在服务器，客户端或聚合器上执行。 根据上面的协议，这是我们需要对运行时可用的操作的列表：

Paillier ops:

Paillier操作：

• Keygen (primitives for RSA), or key import
  Keygen(RSA的原语)或密钥导入
• Encryption
  加密
• Addition
  加成
• Decryption
  解密方式

Ops for secure communication:

安全通信的操作：

• Keygen
  Keygen
• Encryption
  加密
• Decryption
  解密方式

While the Paillier ops are relatively simple to define mathematically, they require high-precision integer data types that TensorFlow doesn’t support natively. We use the GMP library for its multiple-precision arithmetic primitives, and expose it to TensorFlow through the runtime’s ABI for custom ops. These GMP ops are made available to Python in the TF Big library, which we depend on for our TensorFlow implementation of Paillier primitives. TFF ingests the Paillier primitives as TF computations, i.e. Python functions decorated with tff.tf_computation. The PaillierAggregatingStrategy is then responsible for applying the TF computations to federated types to realize the Paillier Aggregation protocol presented above.

尽管Paillier ops的数学定义相对简单，但它们需要TensorFlow本身不支持的高精度整数数据类型。 我们将GMP库用于其多精度算术原语，并将其通过运行时的ABI公开给TensorFlow以进行自定义操作 。 这些GMP操作可在TF Big库中供Python使用，我们在Paillier原语的TensorFlow实现中依赖该库。 TFF将Paillier原语作为TF计算摄取，即用tff.tf_computation装饰的Python函数。 然后，PaillierAggregatingStrategy负责将TF计算应用于联合类型，以实现上述的Paillier Aggregation协议。

A similar process works for the Secure Communication protocol. We use libsodium to define custom TensorFlow ops that provide the primitives needed to encrypt/decrypt TF tensors for an authenticated channel. We then expose these primitives in Python and decorate them as TF computations to be able to use them with federated inputs. Instead of using these computations directly in PaillierAggregatingStrategy again, we abstract the secure communication protocol out into a separate Channel class. The two abstractions are only responsible for implementing their own subprotocols, which allows us to test and verify them separately before composing them together into a single protocol.

安全通信协议也可以使用类似的过程。 我们使用libsodium定义自定义的TensorFlow操作，这些操作提供了对经过身份验证的通道的TF张量进行加密/解密所需的原语。 然后，我们在Python中公开这些原语，并将其装饰为TF计算，以便能够将其与联合输入一起使用。 与其再次在PaillierAggregatingStrategy中直接使用这些计算，不如将安全通信协议抽象到单独的Channel类中。 这两个抽象仅负责实现自己的子协议，这使我们能够在将它们组合为一个协议之前分别对其进行测试和验证。

Finally, to allow users of the Federated Core to experiment with our work, we expose a custom executor factory function. This factory function is responsible for constructing an execution context that can support our new PaillierAggregatingStrategy. In order to pin computations to a new Aggregator party, we add it as a PlacementLiteral backed by its own stack of executors identical to those used by the Server placement. In reality, this is a shallow modification, since this placement is unknown to the compiler. Replacing the default local_executor_factory function with our own local_paillier_executor_factory adds the ability to use tff.federated_secure_sum in simulations, as illustrated in the code snippet at the beginning of this post.

最后，为了允许联邦核心的用户试验我们的工作，我们公开了一个自定义执行器工厂功能。 这个工厂功能负责构造一个可以支持我们新的PaillierAggregatingStrategy的执行上下文。 为了将计算固定到新的聚合方，我们将其添加为PlacementLiteral，由其自己的执行器堆栈支持，该执行器与服务器放置位置所使用的执行器相同。 实际上，这是一个浅浅的修改，因为此位置对于编译器是未知的。 用我们自己的local_paillier_executor_factory替换默认的local_executor_factory函数可增加在模拟中使用tff.federated_secure_sum的能力，如本文开头的代码段所示。

This work accomplishes a number of goals we had for prototyping an integration with TFE and TFF. As a first step, it showed how one can embed custom, crypto-friendly primitives into TFF using TensorFlow’s custom op interface, and also use those primitives to build secure aggregation protocols.

这项工作实现了我们与TFE和TFF集成的原型制作中的许多目标。 第一步，它展示了如何使用TensorFlow的自定义op接口将自定义的，友好的加密基元嵌入到TFF中，以及如何使用这些基元构建安全的聚合协议。

We thought of several interesting extensions to our protocol that we leave as potential future work. First, exposing this protocol to the tff.learning API would make it more easily consumable; this should be fairly easy to do by writing a builder function that produces a tff.templates.IterativeProcess. One might also wish to use this secure aggregation protocol with remote execution, which can be done by implementing a new executor factory similar to local_paillier_executor_factory that uses RemoteExecutors instead of EagerExecutors (perhaps similar to worker_pool_executory_factory). Another interesting direction would be to experiment with different encodings of client data, including more efficient packing of ciphertexts and using quantized data instead of standard integer data types. Finally, exposing a general purpose secure aggregation functionality into TFF is still an open problem that we hope to one day solve, per our RFC. If you are interested in any of these, please do reach out!

我们想到了对协议的一些有趣的扩展，这些扩展是我们将来可能要做的工作。 首先，将此协议暴露给tff.learning API将使其更容易使用。 通过编写生成tff.templates.IterativeProcess的构建器函数，这应该相当容易做到。 可能还希望将这种安全聚合协议与远程执行一起使用，可以通过实现一个类似于local_paillier_executor_factory的新执行器工厂来实现，该工厂使用RemoteExecutors而不是EagerExecutors(也许类似于worker_pool_executory_factory )。 另一个有趣的方向是尝试使用客户端数据的不同编码，包括更有效的密文打包以及使用量化数据而不是标准整数数据类型。 最后，根据RFC ，将通用的安全聚合功能公开到TFF中仍然是一个悬而未决的问题，我们希望有一天能够解决。 如果您对其中任何一个感兴趣， 请联系 ！

TensorFlow Federated is an amazing library. The functional Federated Core API is clean and modern, and the Federated Learning APIs are constantly being updated to support Google’s own research plans for FL. While it’s not a feature complete framework for production-level federated learning, it is extremely thoughtful in the way it models federated computations in the Federated Core language. The team has been quite clear about their goals and non-goals, and has always gone the extra mile to help us whenever we had a question or an issue.

TensorFlow Federated是一个了不起的库。 实用的Federated Core API干净现代，并且Federated Learning API不断更新，以支持Google自己的FL研究计划。 尽管它不是用于生产级联合学习的功能完整的框架，但它在以联合核心语言对联合计算进行建模的方式上却非常周到。 团队非常清楚自己的目标和非目标，并且在遇到问题时总是竭尽全力为我们提供帮助。

Finally, we’d like to thank Michael Reneer for his continued support of our development with TFF, as well as Katharine Jarmul, Dragos Rotaru, and Keely Chamberlain for helping review this post.

最后，我们要感谢Michael Reneer对我们与TFF合作的一贯支持，以及Katharine Jarmul，Dragos Rotaru和Keely Chamberlain对本文的回顾。

关于海角隐私 (About Cape Privacy)

Cape Privacy is an enterprise SaaS privacy platform for collaborative machine learning and data science. It helps companies maximize the value of their data by providing an easy-to-use collaboration layer on top of advanced privacy and security technology, helping enterprises increase the breadth of data included in machine learning models. Cape Privacy’s platform is flexible, adaptable, and open source. It helps build trust over time providing for seamless collaboration and compliance across an organization or multiple businesses. The company is based in New York City and is backed by boldstart ventures and Version One with participation from Haystack, Radical, and Faktory Ventures.

Cape Privacy是用于协作式机器学习和数据科学的企业SaaS隐私平台。 它通过在高级隐私和安全技术之上提供易于使用的协作层来帮助公司最大化其数据的价值，从而帮助企业提高机器学习模型中包含的数据的范围。 Cape Privacy 的平台是灵活，适应性强且开源的。 随着时间的推移，它有助于建立信任关系，从而在整个组织或多个业务中实现无缝协作和合规性。 该公司总部位于纽约市，并获得了大胆创业公司和Version One的支持，并获得了Haystack，Radical和Faktory Ventures的参与。

翻译自: https://medium.com/dropoutlabs/building-secure-aggregation-into-tensorflow-federated-4514fca40cc0

聚合支付安全吗