探析iEx.ec的安全性

image035
作者:Oleg Lodygensky
iEx.ec团队技术总监。
法国巴黎第十一大学LAL/CNRS的国家科学研究中心高级研究工程师,XtremWeb-HEP的主要开发者。

 

 

在准备EDCON大会期间,我们准备了一系列文章来介绍基于区块链分布式云计算平台iEx.ec背后的技术。上一篇文章我们介绍了iEx.ec的架构。本文将会介绍iEx.ec的安全性能,本文需要读者已经熟悉、明白前两篇文章中的系统架构和基本主要原理内容。

简介

iEx.ec建立了不同级别的安全保证系统。本文将会介绍client、scheduler、worker间交互的安全性内容,主要包括的安全服务和协议如下:

  • 通讯
  • 认证
  • 授权
  • 访问权
  • 限制
  • 数据
  • 保密性
  • 封闭性
  • 持续性

在iEx.ec系统中,worker的管理体系与传统区块链网络中的矿工池管理类似。因此,几个iEx.ec的scheduler能管理不同子网络中的worker,每个scheduler本身与以太坊区块链连接。每个iEx.ec池由一组client管理,他们可以执行管理工作如任务提交和用户管理。如下图所示,自2016年12月以来,iEx.ec进行了网络测试,当时我们安装了ganglia集群监控软件。 为了执行可扩展性和可靠性测试,我们对每个核心(而不是CPU)使用一个工作程序。 DSP应用程序成功地使用了超过3600个worker用于单个调度程序。 iEx.ec网络的ganlia视图可以在http://xw.iex.ec/ganglia进行监视。

25

通信

由于敏感数据可以通过网络传输,XWHEP中间件通过使用传输层安全协议(TLS)系统地确保通信隐私。这主要是通过使用加密和鉴定通信实体的方式来确保通信安全。

Scheduler认证通过电子密钥对来实现:Scheduler私钥被安全地存储在服务器端,而可以自由分发的Scheduler公钥被封装在client和worker安装包内。电子密钥对的使用允许scheduler进行身份认证:只有在服务器证明其拥有的私钥有对应的公钥的情况下,分散的XWHEP组件才与Scheduler建立会话。此外,Scheduler无法在不接收相应公钥的情况下接受连接。

通信加密通过使用传输层安全协议(TLS)定义的电子密钥来实现。

认证

连接到scheduler不足以在操作平台上执行命令。每个client和worker必须提供有效的凭据才能通过scheduler的安全识别。服务器接受以下的凭据类型:

  • 账号/密码:账号/密码是唯一定义标识的密钥对。
  • X509数字证书:这是IETF设立的一个确保证书所有者身份的标准。该文档详细描述的证书超越本文范围,读者可以另行自行检索查询。中间件通过验证签署证书的颁发机构(CA)来验证使用X509证书的通信发起者。Scheduler可以管理自己信任的CA证书名单。
  • OpenId和OAuth:中间件可以将认证过程委托给已知的、可信的分布式验证服务器,如google账户。一旦认证成功,中间件将会检验用户是否允许进行使用部署。管理受信任的服务器列表和允许用户在平台中使用远程身份进行身份验证是系统最高的安全授权。这种认证机制有两种模式:1、自动接受可以立即开始工作的新用户;2、通过内部验证的形式获得新注册用户,该模式较为容易但是不是自动的。后者是出于安全目的的默认行为。

授权

在服务器端进行认证不足以在平台上执行命令。每个认证实体都有称之为“用户权限”的使用情况来定义授权。授权允许或拒绝执行请求的对应操作。

授权被定义为最小到最大特权的列举。超级用户(super_user)授权允许对所有对象进行完全访问。iEx.ec中的“管理员”(administrator)授权与超级用户授权相当。标准用户授权允许进行insert_job、insert_data等操作,不过我们不会将其命名为“insert_user”。

一般情况下,用户授权R允许操作A当且仅当:0 < A <= R

特殊情况是worker_user。当提交与该用户权限相关的凭据时,worker的权限如下:

  • 不能进行列表操作,如list_app、list_data等
  • 不能插入,如insert_app、insert_data等
  • 不能删除,如delete_app、delete_data等
  • 请求挂起任务
  • 发送程序心跳(heartbeat)信号
  • 通过提供应用程序唯一标识符(UID)来检索获得应用程序
  • 通过提供数据唯一标识符(UID)下载数据
  • 上传已计算的任务结果。这要经服务器严格检查。需要特别注意:上传结果与“简单”插入数据完全不同。

访问权

在iEx.ec平台上,每个对象都有对应所有者。默认情况下所有者对其拥有的对象有完全访问权限。获得相关对象访问权限的用户在即使不拥有访问对象的情况下也能访问。例如,如果目标对象允许群组访问,则属于该用户群的任何用户可以访问该群组中成员拥有的对象。

允许在服务器上执行命令不足以满足对特定对象执行相关命令。所有对象(如应用程序、数据、任务、用户对象等)都具有实现类似Linux文件系统访问权限的相关访问权限。该访问权限允许或拒绝对与其相关联的对象的访问。

iEx.ec分别为“读取”、“写入”、“执行”访问权限分配:

  • 对象所有者;
  • 所有者所属组成员(如果有);
  • 其他。

所有者或者iEx.ec上的管理者可以修改对象访问权限,但是增加访问权限的操作只能由全局管理员进行。

有一个例外情况,当访问权限被设置为完全被绕过以便于访问的时候:iEx.ec管理员被允许可以访问(读取、写入、执行)任何对象。这个例外允许以任何方式修改访问权限(甚至增加)。

访问权限定义如下:

Ur Uw Ue Gr Gw Ge Or Ow Oe

其中,

Ur=用户(所有者)读取权限

Uw=用户(所有者)写入权限

Ue =用户(所有者)执行权限(如果适用)

Gr =群组读取权限

Gw =群组写入权限

Ge =群组执行权限(如果适用)

Or=其他读取权限

Ow=其他写入权限

Oe=其他执行权限(如果适用)

 

以八进制计数法为例:

755定义

– 所有者的完全操作;

– 用户组的读取和执行(如果有);

– 其他人的读取和执行。

750定义

– 所有者的完全操作;

– 用户组的读取和执行(如果有);

– 其他人无法访问。

700定义

– 所有者的完全操作;

– 用户组无权访问(如果有);

– 其他人无法访问。

限制

由于XWHEP为每个对象分配了身份和访问权限的授权,XWHEP因此有效地限制了所管理的对象。在XWHEP中,授权和访问权限的组合设置被称之为限制。所有应用程序、数据、任务,以及所有用户、client、worker都受限。

限制的目的是在限制访问,以便允许或拒绝分布式实体(client和worker)对受限对象的访问(读取、写入、执行)。XWHEP中间件帮助定义尽可能多的限制作为授权和访问权限的组合。下图所示的“保密性”显示了主要的“公共”、“群组”、“私人”限制:

26

上图中的“限制”通过示例显示了应用程序中的应用限制。我们可以看到三个应用程序限制:

  • 公共应用程序仅由管理员插入。所有用户均可访问:向此应用程序提交任务。基本上可以在任何worker上运行。
  • 群组应用程序由管理员组插入。群组中的所有用户均可访问:向此应用程序提交任务。只能在群组worker上运行。
  • 私人应用程序可以由任意用户插入。只有该对象所有者可以访问:向此应用程序提交任务。只能在私人worker上运行。

此外,上图显示了另外一个有趣的现象:worker(如志愿资源)的限制:

  • 公共worker能下载和运行公共应用程序。
  • 群组worker能下载和运行群组应用程序。
  • 私人worker只能运行私人应用程序。

数据

数据可以通过网络循环使用,从client到服务器,从服务器到worker,然后返回。数据传输安全性通过上面“通信”小节中详述的通信安全性来确保。

保密性

中间件根据上述的授权和访问权限机制来加强数据保密性,定义了如下限制:

  • 私人数据只发送给私人client和私人worker。
  • 组数据仅发送给群组client和群组worker。
  • 公共数据可以自由访问。

一旦对象被发送到分布式实体,XWHEP无法绝对保证完整性和隐私。此时,正确使用限制机制来确保保密性和限制对敏感数据的访问是用户的责任。

中间件定义了X509证书的特殊情况。X509证书是自动设置为私人数据。这可以确保除了所有者之外,其他人无法下载相关敏感数据。中间件系统可以设置worker永远不能访问证书。用户有责任确保其X509证书注册到平台中,并且不会通过将X509证书注册为其他数据类型(如仅“文本”形式)绕过默认行为。

完整性

中间件通过检查每次访问的数据大小和MD5校验来确保数据完整性。确保服务器端存储数据的完整性是iEx.ec管理员的责任。

数据持久化

XWHEP中间件不会在这个点上给用户强制建议。终端用户有责任确保其使用数据持久化方法。管理员可能在未向数据所有者发出正式通知的情况下就从服务器中移除任何数据。因此管理员有责任避免因移除数据而导致注册的应用程序和提交的任务出现问题。

贡献证明机制(Proof-of-Contribution)如何验证脱链计算的正确性?

iEx.ec的目标是开发一项新的协议为脱链计算提供共识算法,被称为PoCo(贡献证明机制Proof-of-Contribution),例如可以确保数据被正确传输,计算被正确运行。 简而言之,它将结果检查机制(多数投票、抽查等)与信誉和奖励系统相关联,以确保人们具有正确的行为动机,并避免过多副本。

但是需要明白一点,开发一些安全有效的应用需要时间,实际上也借助于平台发展的激励措施。 XWHEP已经具有任务复制功能,因此实现多数表决机制是一件非常简单的事情,多数表决是进行BOINC结果认证的基础算法。

结论

本文主要从XWHEP中间件的几个配置设计介绍了iEx.ec平台的安全性内容。下一篇将会介绍应用程序部署相关内容。

 

联系方式

诚挚邀请您加入或者联系我们,与我们更多互动交流:

https://iexec-team.slack.com

https://twitter.com/iEx_ec

https://www.reddit.com/r/iexec/

资源

iEx.ec Github:https://github.com/iExecBlockchainComputing/

XtremWeb-HEP Github:https://github.com/iExecBlockchainComputing/xtremweb-hep

XWHEP资料:

https://github.com/iExecBlockchainComputing/xtremweb-hep/blob/master/doc/xwhep-intro.odt

2014CrowComputing大会上XWHEP介绍视频:https://vimeo.com/113122296

 

相关研究文献:

Caillat, G., Lodygensky, O., Urbah, E., Fedak, G., & He, H. (2008, August). Towards a security model to bridge internet desktop Grids and service Grids. In European Conference on Parallel Processing (pp. 247–259). Springer Berlin Heidelberg.

Cheikh, A. B., Abbes, H., & Fedak, G. (2014, September). Towards privacy for MapReduce on hybrid clouds using information dispersal algorithm. In International Conference on Data Management in Cloud, Grid and P2P Systems (pp. 37–48). Springer International Publishing.