API‐Support

在分析程序（EAnalyzer）中支持API

动机

在某些数据分析场景中，数据提供方仅愿意以API形式（HTTP API）提供数据，而不愿意提供完整的数据集。这一方面是因为完整的数据集泄漏了更多的隐私，另一方面也是因为完整的数据集太大，在使用量不大时，不适合提供如此大量的数据。

因此，Fidelius需要在EAnalyzer中提供对API的支持。。

系统概念

• 数据提供方：以API形式或数据集形式提供数据，与以往一样，数据提供方持有枢钥。
• API：指HTTP API，这里是一个简单的Github的API，一个API可能有参数，也可能没有参数。API的参数通常可以描述为一个字典（dictionary），其中key,value均为字符串。
• APIMeta：用于描述数据提供方给出的API，其中的信息包括数据提供方的枢公钥、API URL、 API说明、API 参数列表、API结果描述。对一个API $h$，我们将其APIMeta记为 $M(h)=\lbrace\mathsf{Pk}_p, U, D\rbrace$ 其中 $\mathsf{Pk}_p$ 为数据提供方的枢公钥， $U$ 为API的URL, $D$ 为API的描述信息，包括API说明，API参数列表，API描述结果。

其他概念，例如典钥，枢私钥转发，EKeyMgr，都沿用以往的概念。

安全假设

在Fidelius的使用场景中，通常分为三个角色，数据提供方、计算节点（即Analyzer的部署节点）以及用户。

计算节点是好奇且可能作恶的，也就是说，计算节点会试图窃取并修改API的请求数据和API的返回结果。数据提供方以及用户均认为计算节点是好奇且作恶的。

除此之外，计算节点还有可能与数据提供方合谋，提供虚假数据。我们不考虑其他合谋情况，例如用户和计算节点的合谋，这种合谋不会带来收益，因此不会发生。

系统架构

如下图所示，系统引入FAPI Proxy和FAPI Dispatcher, 其中，FAPI Proxy部署在数据提供方一侧，用于注册API，解密API请求，加密API结果，以及和FAPI Dispatcher的通信; FAPI Dispatcher部署在Analyzer一侧，用于管理各个API，以及和FAPI Proxy的通信。FAPI Proxy是一个独立的进程或服务，可以和HTTP API Service部署在不同的节点上; FAPI Dispatcher则是一个模块，部署在Analyzer的进程内。

注意，图中省略了EKeyMgr。

虽然图中并未标明，但数据提供方、Analyzer、以及用户之间可以使用区块链或其他第三方通信。具体区别见下文的说明。

注册API

首先，数据提供方需要“发布”API数据，这和Fidelius中以往的发布数据流程不同。用户使用FAPI Proxy注册API,注册API时，需要提供枢公钥、API URL，以及其他说明信息，例如API参数说明，返回结果说明等。

如图所示，FAPI Proxy将这些信息发送给FAPI Dispatcher，FAPI Dispatcher在本地记录相关信息。对于一个API, $h$ ，注册过程完成后，FAPI Dispatcher中记录对应的APIMeta,即 $M(h)$。

调用API

下图说明了调用API的过程，具体说明如下：

1. 用户发起请求，注意，用户的请求不一定是直接的API请求，也可能是一个计算请求，该计算请求间接的需要使用数据提供方的API；用户请求可能是加密的或非加密的；

2. 在EAnalyzer中生成相应的API请求，在生成API请求时，EAnalyzer需要从FAPI Dispatcher中获取对应的APIMeta，并使用APIMeta中的枢公钥加密相应的参数，并形成加密的API请求，记为 $\digamma(h, m)=\lbrace I, U, M, \mathsf{Pk}_\iota \rbrace$, 其中

   • $h$ 为对应的API；
   • $m$ 为参数明文；
   • $I$ 为唯一标识，用于区分不同的API调用；
   • $U$ 为API的URL；
   • $M$ 为加密的参数， $M = \mathsf{Enc}(\mathsf{Pk}_p, m)$, 此处 $\mathsf{Pk}_p$ 为数据提供方的枢公钥；
   • $\mathsf{Pk}_\iota$ 为EAnalyzer的内部公钥。

3. 将加密后的API请求 $\digamma(h, m)$ 转交给FAPI Dispatcher，由其查找相应的FAPI Proxy，并发送给具体的FAPI Proxy；

4. FAPI Proxy接收加密API请求，使用APIMeta中对应的枢私钥解密后，得到明文API请求；

5. FAPI Proxy发送请求；

6. FAPI Proxy获得请求结果 $r$ ，并使用加密请求中的内部公钥加密结果，也就是说，对于加密请求 $\digamma(h, m)$ , 其结果记为 $\Gamma(h, m, r)=\lbrace I, U, R \rbrace$ ，其中

   • $R$ 为加密结果，即 $R=\mathsf{Enc}(\mathsf{Pk}_\iota, r)$。

7. 发送 $\Gamma(h, m, r)$ 给FAPI Dispatcher，此处需要同时将相应的枢私钥转发信息发送给FAPI Dispatcher；

8. 转发给相应的EAnalyzer，以及枢私钥转发；

9. 解密， $r = \mathsf{Dec}(\mathsf{Sk}_\iota, R)$ 获得请求结果明文，并进行相应的处理，例如使用用户的枢公钥加密；

10. 返回结果给用户。

使用区块链

使用区块链（智能合约）能带来额外的好处，例如防止数据提供方与计算节点的合谋，对于每次API调用进行存证等，这就要求上述步骤中的4、7使用区块链进行交互。对此的描述我们未来给出。

注意，使用区块链会带来一定的性能损失，降低调用API的性能，因此，应酌情考虑。

使用FAPI Proxy

在EAnalyzer中调用API

源文件

本文图片使用drawio绘制，源文件如下 FAPI-design.zip