SMACS：Smart Contract Access Control Service.(SMACS：智能合约访问控制服务)

在本篇论文中，作者提出了一种可低成本实现、可更新且精细的智能合约访问控制规则(ACRs)的框架——SMAC。这种框架将昂贵的ACR验证和管理操作的负担转移到了链下的基础架构上，同时仅实现了基于区块链的轻量级基于token的访问控制。SMACS除了简单的访问控制列表之外，还可以轻松地实施规则，从而增强智能合约运行时的安全性。

• 原文链接：SMACS：Smart Contract Access Control Service

一、写作背景

从本文可知，作者指出现存的智能合约承诺还存在多种的安全问题，这些问题到可通过有效的访问控制来缓解，但是当前区块链平台的特性缺乏隐私、昂贵的链上资源或延迟等问题，使得实现它具有挑战性。另外，由于智能合约的不可变性，当受到攻击时，很难升级或简单的杀死已经部署好的智能合约。

1.1 回顾智能合约知识（论文中没有的）

智能合约：一套以数字形式定义的承诺(promises)，包括合约参与方可在上面执行这些承诺的协议。

智能合约(Smart Contract)的概念是由计算机科学家、密码学家、法律学家尼克·萨博(Nick Szabo)在1994年提出，一种旨在以信息化方式传播、验证或执行合同的计算机协议，允许没有第三方的参与下进行可信交易。下面这位大佬就是Nick Szabo。

随着2009年比特币、区块链的出现，以及**2014年第一个大规模应用的智能合约应用平台——以太坊(Ethereum)**开始流行起来，智能合约再次火了起来。

• (1) 传统合约
  • 口头约定：约定双方进行口头承诺，由彼此的信任度做担保。
  • 纸质合约：由合约双方共同签订纸质合同，签字与盖章。
  • 电子合同：由合同双方之间通过电子信息网络的形式达成的协议。
• (2) 智能合约
  • 制定：多方用户共同参与制定一份智能合约。
  • 部署：合约通过P2P网络传播并存入区块链。
  • 执行：区块链构建的智能合约自动执行。

现存问题：若受到攻击，难以杀死已经部署的智能合约；昂贵的链上资源或延迟。

二、主要内容

智能合约程序有三个内存区域：堆栈(stack)、内容(memory)和存储(storage)。堆栈和内存是易失性的，使用起来很便宜。存储在区块链上维护，是跨交易的唯一持久内存区域。访问控制是一种安全技术，它规定了谁可以访问某些系统资源。

在整篇论文中，描述了以太坊背景下的SMACS，但它可以很容易地扩展到具有类似功能的其他平台和语言。SMACS包含四种类型的角色：

• a) 启用了SMACS的智能合约：负责验证其对应的token来验证传入的调用。若没有提供有效的token，则拒绝任何交易或消息调用；
• b) 所有者(Owner)：作为智能合约的创建者，负责定义和管理访问控制规则(Access Control Rules, ACRs)，以及相对应的Token Service(TS）实例；
• c) Token 服务(TS)：负责验证来自Client的请求，相应地发出访问控制token的服务；
• d) 客户端(Client)：指希望访问支持SMACS的智能合约的用户，它必须获得授予适当权限的token才能访问。

2.1 Token类型

SMACS支持三种类型的token来代表不同的权限，因此SMACS的访问控制可以归约成对token发行的控制。

• Super token：最高权限等级，可在token有效期内使用任意参数，自由调用合约的公共方法；
• Method token：限制了对特定方法的访问，可在token有效期内访问与之关联的特定合约的方法；
• Argument token：类似Method token，附加限制只能用特定的参数调用方法。

所有token都带有TS设置的过期时间，决定了token的生命周期。在客户端从TS获得令牌之前，它必须向TS提交一个格式良好的token请求。如下图：

首先Client进行Token请求，包括token的type类型和一段reqPayload。reqPayload是token请求的一个可选字段，根据类型其大小可变，它包括cAddr(目标合约地址)、sAddr(客户账户地址)、methodID(token访问的方法标识符)、argName(使用的参数)和argValue(参数值)等。然后，TS收到请求后，返回一个86字节的Token，包括type、expire(编码的到期时间)、index(标记一次性属性集)和TS的签名(signature)，签名中的type和签名是从客户端发送的token请求中提取。所有符号解释如下表所示。

2.2 Token的发布和验证

其实在TS返回token给Client之前，需要先对token进行解析和验证，只有验证通过后，才能发送给Client。SMACS有两个验证过程：一种是TS验证传入的token请求；另一种是智能合约验证从交易中提取的token。

• Token发布：客户端申请token请求后，TS将根据规则进行解析，并对其进行检查，验证通过后，才根据请求发送token。
• 合约方验证：从TS处获得token后，客户端可进行构建交易。TS收到交易后，验证token的权限是否在有效期内或是否被使用过（如算法1），合约才能继续执行交易。

为了实现SMACS框架，对于每个公共和外部方法，将token参数添加到原始参数列表中，并在实际方法主体之前声明执行算法1的verify调用。SMACS可以确保从外部调用的每个方法在执行主体之前验证token，使得旧式合约的代码在SMACS框架中可以部署就绪。

为了便于与旧式合约的结合和转换，作者开发了一个工具，该工具可以将允许任何旧版的智能合约转换成等效的SMACS合约。如下图所示提供了这种转换的示例。只需在内容调用的公共方法情况前，声明和验证token，而内部方法不必验证token。

2.3 一次性token

在SMACS框架中，作者声明了一个非常重要的token使用方法，也就是一次性token。一次性token可确保给定token只能使用一次，它为了至关重要方法的访问控制提供了安全性。例如在TS收到未知客户端的token请求时可能特别有用。在以太坊中采用随机数机制来抵抗重放攻击，但是合约本身无法访问交易的随机数。因此SMACS必须实施合约内的机制，以支持一次性token的验证。

• TS维护了一种counter变量，用于发行具有一次属性集的token。每发行一次性token，counter变量都会初始化为0，并将其递增1，然后将更新后的值作为token的索引值。（但是，由于链上存储非常昂贵，因此，如果已发行的一次性token的数量很庞大，则此方法可能会昂贵且不切实际。）
• 因此，作者提出了一种经济有效的方案来处理一次性集token，其中每个索引都被有效地编码为一个比特循环重用的bitmap(位图)。在此方法中，使用n-bits映射到S集合来表示具有连续索引值的n个一次性token的集合状态。
  

bitmap的状态可表示为一个元组 ( S , s t a r t , s t a r t P t r , e n d , e n d P r t ) (S, start, startPtr, end, endPrt) (S,start,startPtr,end,endPrt)，其中 S ∈ { 0 , 1 } n S\in \{ 0,1 \}^n S∈{0,1}n , s t a r t ∈ { 0 , 1 , . . . } start\in \{ 0,1,...\} start∈{0,1,...}, s t a r t ∈ { 0 , . . . , n − 1 } start\in \{0,...,n-1\} start∈{0,...,n−1}, e n d = s t a r t + n − 1 end=start+n-1 end=start+n−1, e n d P t r = s t a r t P t r + n − 1 m o d n endPtr=startPtr+n-1 mod n endPtr=startPtr+n−1modn。在算法2中，这个n-bit序列 S [ s t a r t P t r ] ∣ ∣ S [ s t a r t P t r + 1 m o d n ] ∣ ∣ . . . ∣ ∣ S [ e n d P t r ] S[startPtr]||S[startPtr+1 mod n]|| ... ||S[endPtr] S[startPtr]∣∣S[startPtr+1modn]∣∣...∣∣S[endPtr]指示索引为 s t a r t , s t a r t + 1 , . . . start, start+1,... start,start+1,...和 e n d end end的n个一次性token的状态。

例如：令S为n=8，初始化S所有单元格为0，且start=startPtr=0,end=endPtr=7.

• 1）当收到索引为0、1、4、5的token访问合约后，相应的单元格将设置为1，如红色单元格所示。
  
• 2）当收到索引为9的token访问请求时，根据算法2中的 s e e k ( ) seek() seek()函数可知，返回最小的整数j，使得s[j]=0，且 i − e n d ≤ j − s t a r t P t r i-end\leq j-startPtr i−end≤j−startPtr成立，可以计算得出返回2，并分配给startPtr。 S [ e n d P t r ] S[endPtr] S[endPtr]设置为1，它是由 s t a r t P t r + n − 1 m o d n = 9 m o d 8 = 1 startPtr+n-1 mod n=9 mod 8=1 startPtr+n−1modn=9mod8=1得到，则更新后新的索引为 { 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 } \{2,3,4,5,6,7,8,9\} {2,3,4,5,6,7,8,9}的token状态。
  
• 3）当收到索引为12的token访问请求时，同样计算可得更新后索引变为 { 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 } \{6,7,8,9,10,11,12,13\} {6,7,8,9,10,11,12,13}token状态和并未使用的索引2，3信息将被丢失。（因为根据上一次的索引为2 ~ 9，其中2和3还没被设置为1，就更新到6 ~ 13了，故2，3的索引信息将被抛弃）
  
  因此，为了避免丢失token，SMACS往往会分配足够大的bitmap。

2.4 调用链token

当外部账户发起交易时，一个被调用的合约方法可以调用另一个合约的方法，并可以一直延续下去。若使用了SMACS调用链上的智能合约，则客户端必须为所有这些智能合约获取适当的token。

如图，客户端触发调用链之前，需从 S C A , S C B , S C C SC_A,SC_B,SC_C SCA​,SCB​,SCC​对应的TS中获取三个token， t k A , t k B , t k C tk_A, tk_B, tk_C tkA​,tkB​,tkC​。并可以在交易中嵌入如下形式的三个token的数组：
S C A : t k A ∣ ∣ S C B : t k B ∣ ∣ S C C : t k C SC_A: tk_A || SC_B: tk_B || SC_C: tk_C SCA​:tkA​∣∣SCB​:tkB​∣∣SCC​:tkC​

• a) 当 S C A SC_A SCA​收到交易时，它可以提取token的地址，并根据算法1验证有效性。
• b) 随后，此token数组通过消息调用传递给 S C B SC_B SCB​，消息调用将解析出 t k B tk_B tkB​并对其进行验证。
• c) 最后，在调用 S C C SC_C SCC​时传递数组，该 S C C SC_C SCC​可以执行与 S C A SC_A SCA​和 S C B SC_B SCB​类似的操作。

2.5 访问控制规则(ACRs)

SMACS中的每种token类型，都有一组与之关联的规则。特定类型的token请求将根据与该类型的规则集进行检查。

• 黑名单和白名单：是SMACS中通用的访问控制规则(ACRs)。白名单表示此列表之外的地址都无法从TS获得有效的token，即无法访问智能合约。SMACS中并不强制要求如何创建这个列表。例如Super token白名单的地址可以列为Argument token的黑名单。

• 运行时验证规则：Argument token类型还允许定制更高级的ACRs，以增强SMACS合约的运行安全性。假设客户端使用一组特定的参数访问合约的方法，SMACS允许TS在隔离的链下环境中模拟运行时合约的行为。若观察到调用触发的任何异常行为时，则拒绝访问。因此，为Argument token实施适当规则的TS，可以保护已经部署的易受攻击的智能合约。

后面一章节就是介绍与两种流行的案例（Hydra和Re-entrancy攻击）的结合，讨论了其可以使用第三方工具来实施用于增强某些运行时安全性属性的高级规则，这里就不再详细阐述，建议看原论文。

三、实验分析与评估

• 1）安全性分析：敌手无法绕过SMACS中的访问控制，所有合约的公开接口都需要token验证过程，以确保token真实性。获得token的唯一办法是请求TS，TS将根据其访问规则验证该请求。
  • 替代攻击：若攻击者拦截交易，并从中获取token，由于TS签名会创建token和可应用token的交易进行加密绑定，因此合约方会拒绝交易。
  • 重放攻击：若攻击者拦截交易，并在网络中重播它。交易中包含的随机数确保每笔交易都是唯一的，若网络已接受交易，则不会再处理交易。此外，client的地址受token签名的保护，因此攻击者无法提取和重用他人的token。
  • 51%攻击：若敌手拥有区块链网络总投票率的50%以上，这使得它可以重写区块链历史。但它无法绕过SMACS访问控制，也就无法获得针对非法交易的有效token。
  • 隐私性：SMACS将访问规则移至作为链下服务的TS。因此，已部署的规则，验证工具及其配置将保持私有状态，不会泄露给客户。
• 2）可行性分析：若要求TS始终保持token的验证和签名状态，则会存在单点故障。然而，SMACS中的TS易于扩展和复制。对于发行的token，提供可用性就像提供不需要任何协调的冗余TS一样容易。

3.1 gas开销

实验环境：Solidity v0.4.24开发环境，部署在的测试网。TS由运行Node.js　v10.2.1与node-localStorage package的Web服务器，用于存储规则和签名密钥对。使用web3.js实现client和owner，以太坊的ECDSA签名方案作为默认方案。

3.2 Token服务性能

实验环境：在macOs Sierra 10.12.6，Intel Core i5 CPU（2.7 GHz）和8GB RAM系统上评估TS的吞吐量。对每种类型的token，向TS发送 1 0 i ( 0 ≤ s ≤ 5 10^i(0\leq s≤5 10i(0≤s≤5）的token请求，记录TS所需总时间，并计算每个请求所需的平均时间。

四、论文总结与思考

总结全文，作者提出了一种结合轻量级链上验证和链外访问控制管理的基础架构，可大致分为以下三个重点：

• 重点1：对于不同类型的token赋予了不同的权限，SMACS的访问控制就可以归约成对token发行的控制，以低成本实现智能合约的高效、灵活和细粒度的访问控制。
• 重点2：为智能合约提供恶意地址防护和抵制执行异常行为的功能，SMACS实现了两个验证过程，TS验证传入的token请求和合约验证从交易中提取的token。
• 重点3：一次性的token可确保token只能使用一次，它为重要方法的访问控制提供了安全性。

个人的疑问和思考：

以上仅代表我个人的疑惑，欢迎大家在下方留言积极讨论，一起学习，一起进步！

标签：Control,验证,访问控制,SMACS,TS,IFIP,DSN,token,合约
来源： https://blog.csdn.net/A33280000f/article/details/116586060