CN113468610A - 去中心化可信访问控制框架及其运行方法 - Google Patents

去中心化可信访问控制框架及其运行方法 Download PDF

Info

Publication number
CN113468610A
CN113468610A CN202110705275.5A CN202110705275A CN113468610A CN 113468610 A CN113468610 A CN 113468610A CN 202110705275 A CN202110705275 A CN 202110705275A CN 113468610 A CN113468610 A CN 113468610A
Authority
CN
China
Prior art keywords
addr
cloud
authorization
enclave
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110705275.5A
Other languages
English (en)
Inventor
谭良
杨彩霞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sichuan Normal University
Original Assignee
Sichuan Normal University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sichuan Normal University filed Critical Sichuan Normal University
Priority to CN202110705275.5A priority Critical patent/CN113468610A/zh
Publication of CN113468610A publication Critical patent/CN113468610A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Medical Informatics (AREA)
  • Storage Device Security (AREA)

Abstract

本发明公开了一种去中心化可信访问控制框架及其运行方法，Cloud(云)、BC(区块链)、DU(数据用户)、DO(数据所有者)；DO将资源上传到Cloud，然后在BC中通过注册交易发布权限。DU将对资源的请求发送到Cloud，Cloud查询BC，由BC返回权限给Cloud，由Cloud判断请求是否有权限，最后回复请求给DU。本发明优点是：拥有可信的分布式访问控制体系结构；将访问控制权限加密存储在区块链中，有效保护用户隐私；有效保护访问控制实施过程的机密性和完整性；保证资源的机密性、完整性、可用性、真实性和可问责性。

Description

去中心化可信访问控制框架及其运行方法
技术领域
本发明涉及云环境安全技术领域，特别涉及一种云环境中基于SGX的去中心化可信访问控制框架及其运行方法。
背景技术
云是一种提供共享并支持无处不在的按需访问计算的计算模型，为各行各业提供新的数据处理和服务，显著降低用户计算和存储成本，提高易用性。随着云计算规模化和集约化的发展，其面临的云安全问题日益凸显，在工业界和学术界引起广泛关注。访问控制是云环境保护企业及个人等存储在云端的敏感数据的重要安全技术之一，一方面，由于云环境采用中心化访问控制机制，当受到黑客攻击和云内部管理员非法访问时，易引起安全和隐私问题；另一方面，云访问控制的执行引擎运行在非安全环境，也容易遭受攻击。
与传统的计算模式相比，云计算的计算及存储模式发生了很多变化，主要体现在以下5个方面：①用户无法控制其存储在云端的资源；②用户和云之间缺乏信任；③云中迁移技术可能导致数据的安全域发生改变；④云中多租户技术导致访问主体被重新定义；⑤云中虚拟技术可能会导致同一物理设备上的资源被窃取。面对这些挑战，学术界出现了大量的云访问控制研究，业界也在尝试实现现有的访问控制技术。然而，无论是学术界研究的访问控制模型或机制，还是产业界实际使用的访问控制方式，均存在对身份、密钥、权限、认证信息等的中心化存储和管理模型。这样的访问控制技术，仍然存在安全和隐私问题，可大致分为两个方面：
(1)攻击者攻击：①外部恶意攻击者攻击可信中心，篡改中心服务器上存储的授权数据库，非法访问或窃取用户存储在云中的资源。②云的系统管理员管理授权数据库，拥有对资源的访问和管理权限，恶意的云系统管理员可能会利用该权限非法访问资源，或者篡改授权数据库进行非法访问。
(2)云访问控制执行引擎(ACEE)运行在非安全环境，容易遭受攻击造成隐私泄露。云通过虚拟化技术构建云服务架构，在享受便捷的同时，也带来很多安全隐患。①由于虚拟机(VM)共享物理资源，无法提供ACEE的可信执行环境，容易遭受同一VM或VM间的恶意应用程序的攻击，造成隐私泄露。②云虚拟监控器(VMM)用于管理上层运行的多个VM，而ACEE运行在VM中，因此恶意的V MM可能会执行特权命令来窃取ACEE关键数据和代码，甚至是篡改ACEE访问控制结果，进行非法访问。
目前的云访问控制包括四个主要的流程：身份认证，访问授权，访问控制，安全审计，其目的是限制云端数据不被非法访问。但无论是学术界研究的三类云访问控制模型或机制，还是工业界实际使用的云访问控制方式，都有三个共同的特点：
一个或多个可信中心。学术界提出的三类访问控制中，包括云访问控制模型、基于密码机制的云访问控制模型、云中多租户及虚拟化访问控制，均需要一个或多个可信的授权中心存储身份、密钥、授权信息等。首先，在云访问控制模型中，基于使用控制的访问控制(UCON)模型需要可信中心存储访问权限和权限相关的义务和条件；其次，在密码机制的访问控制中，基于属性基加密(ABE)的访问控制通常需要一个或多个可信中心来对密钥进行统一管理和分发；最后，在云多租户和虚拟化访问控制中，一般需要将虚拟机访问控制权限存储在可信中心。此外，在产业界中实际使用的云访问控制方式，都需要可信中心来存储用户身份信息和访问权限。
内部可信的系统管理员(SA)。云计算提供商(CSP)为云用户提供三种典型的服务：基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)。尽管服务不同，均需要可信的系统管理员对访问控制策略数据库(ACPD)进行管理维护，保证所提供的服务不被非法访问和使用。例如，IaaS主要为用户提供计算能力和存储空间，需要SA来监控和管理对基础设施环境的访问。PaaS主要为用户提供开发和执行应用的平台，需要SA对平台的访问控制进行监控和管理；S aaS主要为用户提供所需的应用，同时也需要SA对访问控制策略进行管理和维护。
ACEE运行在VM中。云虚拟化作为云计算的核心技术，是一种调配计算资源的方法，通过VMM或称监管程序(Hypervisor)对计算机资源进行虚拟化，在物理机上构建一个虚拟机系统，每个VM运行有自己的操作系统(OS)，在OS之上运行各种应用程序，各应用程序共享底层物理资源。如今，典型的云服务提供商比如亚马逊(AWS)、微软(Azure)、阿里云(Alibaba Cloud)，尽管他们作为服务提供商提供的服务有所差异，但都提供访问控制服务，而访问控制的执行引擎都运行在各自的云端VM中。
目前的云访问控制存在以下问题：
问题1：攻击者攻击可信中心，篡改ACPD。①攻击者攻击可信授权中心，篡改ACPD，造成数据泄露或数据被盗。例如，攻击者冒充合法用户进行访问或窃取资源，或篡改ACPD，增加非法访问的权限，或删除合法用户权限，破坏机密性、可用性和完整性。②恶意SA特权访问或篡改ACPD。例如，恶意SA利用权限绕过身份认证，非法访问资源，导致隐私泄露，破坏机密性和完整性；恶意SA篡改ACPD，导致隐私泄露，破坏机密性、完整性和可用性。
问题2：ACEE运行在非安全环境，易遭受攻击。云采用虚拟化技术来共享资源，通过VMM来管理上层运行的多个虚拟机，而访问控制执行引擎(ACEE)运行在虚拟机中，因而容易遭受攻击。①由于ACEE和其余应用程序运行环境并未隔离，因此ACEE容易遭受来自应用程序间的攻击。②多个虚拟机运行在VMM之上，共享底层资源，因此ACEE容易遭受管理域和虚拟机之间的攻击。③VMM运行在特权模式，用来管理上层运行的多个虚拟机和运行在虚拟机中的程序，因此ACEE容易遭受VMM特权攻击。
本发明关键技术名称定义：
SGX：指Intel SGX是Intel架构新的扩展，旨在以硬件安全为强制性保障，提供用户空间的TEE，通过一组新的指令集和内存访问机制，实现不同程序间的隔离运行，保障用户关键代码和数据的机密性与完整性不受恶意软件的破坏。
发明内容
本发明针对现有技术的缺陷，提供了一种去中心化可信访问控制框架及其运行方法。
为了实现以上发明目的，本发明采取的技术方案如下：
一种去中心化可信访问控制框架，包括：Cloud(云)、BC(区块链)、DU(数据用户)、DO(数据所有者)；
Cloud：它为用户提供身份验证和数据存储。Cloud通过区块链确定DU或D O的访问权限，由访问控制服务器(ACS)对DO或DU进行访问控制，ACS底层硬件支持SGX，ACS上的ACEE运行在SGX保护的ACEE Enclave中，同时Cl oud初始化成为区块链用户时，私密数据由基于ACEE Enclave身份进行密封保存。
②BC：它具有开放、透明、防篡改、不可逆的特点，与分布式数据库一样，我们将其作为授权数据库进行访问控制。
③DO：DO将资源上载到Cloud，并将资源的访问权限发布到BC中。运行在支持SGX的客户端程序中，初始化成为区块链用户时，私密数据由Client Enclave密封存储。
④DU：DU得到由Cloud的许可就可访问资源。运行在支持SGX的客户端程序中，初始化成为区块链用户时，私密数据由基于Client Enclave身份进行密封保存。
DO将资源上传到Cloud，然后在BC中通过注册交易发布权限。DU将对资源的请求发送到Cloud，Cloud查询BC，由BC返回权限给Cloud，由Cloud判断请求是否有权限，最后回复请求给DU。
去中心化可信访问控制框架中的定义：
∑TEE.init(prog)->encid：Enclave实例初始化函数，输入为Enclave程序代码prog，输出为对应的Enclave实例的encid。
∑TEE.run(encid,func,args)->(outp,σTEE)：Enclave中程序执行函数，在初始化∑TEE.init后执行，输入为encid,func,args，其中encid为指定的Enclave实例，func为指定的程序代码，args为传入func的参数，输出为func执行的结果outp和硬件签名证明σTEE，其中σTEE＝∑TEE.Sig(skTEE,(func,outp))。
∑TEE.ver(pkTEE,(prog,outp),σTEE)->true or false：验证硬件签名函数，输入pkTEE来验证硬件签名σTEE是否有效，有效则输出true，否则输出false。
sgx_seal_data(data,sealkey)->dataseal：基于Enclave身份的密封函数，对data进行密封，存储在Enclave外，输入为密封数据data和密钥sealkey，输出为密封结果dataseal。
sgx_unseal_data(dataseal,sealkey)->data：基于Enclave身份的解封函数，通过sealkey恢复密封的data，输入为密封结果dataseal和密钥sealkey，输出为data。
E(key,M)/D(key,N)：表示加密/解密函数.E()用于加密M，D()使用key解密N,key可以是对称密钥对或非对称密钥对。
Hash(M)：表示Hash函数。
KC：表示Cloud非对称密钥对，KC包括公钥KpubC和私钥KpriC。
KDO：表示DO非对称密钥对，KDO包括公钥KpubDO和私钥KpriDO。
KDU：表示DU非对称密钥对，KDU包括公钥KpubDU和私钥KpriDU。
KW：表示生成钱包地址的非对称密钥.KW包括公钥KWpub和私钥KWpri。
ks：表示对称密钥。
Addr：表示区块链中的钱包地址，即用户的身份。
resCAP：资源的访问权限.resCAP＝{p,m,exp},其中p是访问控制策略,比如DAC,BLP,RBAC等；m是资源访问模式,比如up,down,modify,delete；exp是资源访问有效期。
resCAP_S：表示加密的resCAP。
resInfo：资源信息集.resInfo＝{resOwnerID,resID,resName,resCAP,resURL},其中resOwnerID是资源所有者唯一标识符，resID是资源的唯一标识符，resName是资源名称，resCAP是资源访问权限，resURL是资源访问地址。
bresInfo：区块链资源信息集.bresInfo＝{actionInfo,resInfo},其中actionInfo是资源附加信息，resInfo是资源信息集。
tran：它代表了区块链集合的一种交易。tran＝{tranID,Addrfrom,Addrto,value,bresInfo},其中tranID是交易编号，Addrfrom是交易发起者，Addrto是交易接收者，value是交易值，bresInfo是区块链资源信息集。
本发明还公开了一种去中心化可信访问控制框架实体注册方法，包括：Cloud注册、User注册和资源发布；
实体注册阶段要求Cloud、DO、DU注册成为区块链节点，其中DU和DO注册相同，统称为User注册，首先引入了KGen()，AGen()和SynData()，KGen()生成KW，输入NULL，输出KW；AGen()生成Addr，输入为KWpub，输出为Addr。SynData()旨在同步ti到tj的数据，输入为ti和tj，输出为块数据tij。
Cloud注册流程，包括以下步骤：
①CRequest||ti||tj.ACEE Enclave将请求CRequest||ti||tj发送给服务器，然后由Cloud向BC发送注册请求。
②BC调用KGen()生成KWcloud(KWpubCloud,KWpriCloud),然后调用AGen(KWpubCloud)生成Addrcloud。区块链利用ks1加密Addrcloud||KWcloud,KpubC加密ks1,然后发送E(ks1,Addrcloud||KWcloud)||E(KpubC,ks1)||blockdataij给Cloud，其中blockdataij表示区块链中ti到tj的数据。通常，Cloud会自动调用SynData(ti,tj)将blockdataij同步到本地数据库。
③Cloud先调用D(KpriC,ks1)解密得到ks1,然后调用D(ks1,Addrcloud||KWcloud)解密得到Addrcloud||KWcloud，再调用sgx_seal_data(KWcloud,sealkeycloud)，在ACEE Enclave中使用对称密封密钥sealkeycloud将KWcloud进行密封存储，密封结果为datasealcloud1。同样的，Cloud还需将KC进行密封存储，密封结果为datasealcloud2。
User注册流程，包括以下步骤：
①URequest||tl||tm.Client Enclave将请求URequest||tl||tm发送给客户端，User向BC发送注册请求。
②BC调用KGen()生成KWuser(KWpubUser KWpriUser),然后调用AGen(KWpubUser)生成Addruser。BC发送E(ks2,Addruser||KWuser)||E(KpubUser,ks2)||blockdatalm给User。其中blockdatalm表示区块链中tl到tm的数据。通常，User会自动调用SynData(tl,tm)将blockdatalm同步到本地数据库。
③User调用D(KpriUser,ks2)和D(ks2,Addruser||KWuser)解密得到Addruser||KWuser，然后调用sgx_seal_data(KWuser,sealkeyuser)，在Client Enclave中使用对称密封密钥sealkeyuser将KWuser进行密封存储，密封结果为datasealuser。
资源发布方法是DO将资源发布到云端，然后将资源元数据发布到BC上。引入1个函数ResUp()和1个区块链接口TxSend()。ResUp()目的是通过DO将资源上传到云端，DO输入resContent和resUpURL，输出resInfo；TxSend()是区块链交易接口，输入KWpri,Addrfrom,Addrto,index,content,timestamp,输出为tranID。
资源发布的具体流程，包括3个步骤。
①DO和Cloud之间进行双向远程认证，认证对方身份是否可信，运行环境是否可信，以此来建立远程认证通道。然后由Client Enclave调用ResUp(resContent,resUpUrl)将资源上传到Cloud。
②ACEE Enclave将E(ks3,resInfo)||E(KpubDO,ks3)给DO，DO利用D(KpriDO,ks3)和D(ks3,resInfo)解密得到resInfo。
③Client Enclave调用Tresource将资源注册到区块链，其中Tresource为智能合约，如算法1所示。
Figure BDA0003131885600000081
Figure BDA0003131885600000091
在合约Tresource中，行1为初始化Enclave；行2为对resID进行哈希处理；行3为加密资源权限resCAP；行4-8判断加密权限是否成功，如果成功则设置resInfo，否则返回false；行9为初始化资源注册信息，行10为恢复密封的钱包密钥KWpriDO；行11获取时间戳；行12调用TxSend()来发布资源注册交易；最后返回tranID和σTEE。
本发明还公开了一种去中心化可信访问控制框架访问控制方法，包括以下步骤：
在访问控制之前，引入一个基于区块链实现的查询接口TxQuery()，TxQuery()实现的是合约查询接口，输入为Addrfrom,Addrto,index,输出为发送方Addrfrom发送给Addrto的最新一笔交易tran。
访问控制流程，包括以下步骤：
①User和Cloud之间进行双向远程认证后，Client Enclave向ACEE Enclave发起请求E(ks4,Addruser||resInfo’)||E(KpubC,ks4)，其中resInfo’表示它想访问的资源。
②ACEE Enclave接收到请求，先调用D(KpriC,ks4)和D(ks4,Addruser||resInfo’)解密得到Addruser||resInfo，’然后调用Hash(resID)计算得到hashresID，最后调用智能合约QueryCap()向区块链发起权限查询请求，QueryCap()如算法2所示。
Figure BDA0003131885600000092
Figure BDA0003131885600000101
③BC返回resCAP_S||σTEE给ACEE Enclave。
④ACEE Enclave调用VerifyCap验证Addruser是否具备访问能力，VerifyCap如算法3所示.
Figure BDA0003131885600000102
⑤ACEE Enclave将ResponseAccessInfo返回给Client Enclave.若ResponseAccessInfo为true，则User可访问资源，否则不允许User访问资源。
⑥ACEE Enclave调用Taccesslog将访问记录发布到区块链，其中Taccesslog为智能合约如算法4所示。
Figure BDA0003131885600000103
Figure BDA0003131885600000111
本发明还公开了一种去中心化可信访问控制框架隐私保护的授权方法，包括：DO授权给DU的直接授权和已获得授权DU对欲授权DU进行授权的间接授权；
直接授权包括以下步骤：
①DU1(授权者)和Cloud之间进行双向远程认证后，Client Enclave向ACEEEnclave发起请求，其中authFlag是授权请求，ACEE Enclave解密得到authFlag||AddrDO||AddrDU1||resInfo。
②ACEE Enclave计算Hash(resInfo.resID)得到hashresID，调用QueryCap(AddrDO||Addrcloud||hashresID)查询AddrDO是否具备授权能力。
③BC返回resCAP_S’给ACEE Enclave。
④ACEE Enclave解密resCAP_S’得到resCAP，’检查AddrDU1请求的权限是否在DO的授权范围之内，是则执行下一步。
⑤Cloud和DO之间进行双向远程认证，ACEE Enclave通知Client Enclave进行授权，并发送授权许可标志AuthPermit。
⑥Client Enclave调用Tpublish将授权发布到区块链，Tpublish如算法5所示。
Figure BDA0003131885600000112
Figure BDA0003131885600000121
⑦BC返回授权交易tranID给Client Enclave。
⑧DO发送authFlag给DU1。
所述间接授权是指已被授权的DU对其他用户进行授权，包括至少5个实体：DO(资源所有者)、DU1(授权者)、DU2(请求者)、BC和Cloud。
间接授权和直接授权的区别在于授权DU2需要发送间接授权通知E(ks9,authFlag||AddrDU2||resInfo||authTime)||E(KpubDO,ks9)给DO。
间接授权步骤如下：
①DU2与Cloud进行双向远程认证之后，Client Enclave向ACEE Enclave发起请求E(ks7,authFlag||AddrDU1||AddrDU2||resInfo)||E(KpubC,ks7)，其中authFlag为DU2请求授权标志。Cloud解密得到authFlag||AddrDU1||AddrDU2||resInfo。
②ACEE Enclave计算Hash(resInfo.resID)得到hashresID，调用QueryCap(AddrDU1||Addrcloud||hashresID)查询AddrDU1是否具备授权能力。
③BC返回resCAP_S’给ACEE Enclave。
④ACEE Enclave解密resCAP_S’得到resCAP，’检查AddrDU2请求的权限是否在DU1的授权范围之内，是则执行下一步。
⑤Cloud和DU1之间进行双向远程认证，ACEE Enclave通知Client Enclave(DU1)进行授权，并发送授权许可标志AuthPermit。
⑥Client Enclave(DU1)调用Tpublish(AddrDU1,AddrDU2,KpubC,resInfo)将DU1对DU2的授权发布到区块链。
⑦BC返回授权交易tranID给Client Enclave(DU1)。
⑧DU1发送authFlag给DU2。
⑨DU2发送授权通知提醒E(ks9,authFlag||AddrDU2||resInfo||authTime)||E(KpubDO,ks9)给DO。
本发明还公开了一种去中心化可信访问控制框架隐私保护的授权撤销方法，包括：
定义了以下规则：
(1)谁授权谁撤销。
(2)所有者可以撤销直接授权和间接授权。
(3)只有当授权用户撤销所有授权时，上一级授权用户才能撤销该授权用户的授权。
根据上述三条规则，授权撤销包括基本授权撤销和复杂授权撤销。基本授权撤销是授权撤销的基本操作单元，即撤销不再具有间接授权的权限。
基本授权撤销包括以下步骤。
①DU1(授权者)与Cloud通过远程认证建立可信通信通道后，Client Enclave向ACEE Enclave发送权限撤销信息，authRevoc为权限撤销请求标志。
②ACEE Enclave解密得到authRevoc||AddrDU1||AddrDU2||resInfo，然后调用QueryCap查询AddrDU1是否有授权给AddrDU2的能力。
③BC将查询结果返回给ACEE Enclave。
④ACEE Enclave解密resCAP_S’得到resCAP，’若resCAP’不为空，则发送授权撤销标志authRevoc给DU1。
⑤Client Enclave调用Tpublish发布授权撤销交易，其中resInfo.resCAP＝＝null。
⑥DU1中Client Enclave与DU2(请求者)中ACEE Enclave通过远程认证建立可信通信通道，并由DU1向DU2发送authRevoc||AddrDU1||AddrDU2||resInfo.resID，通知DU2权限被撤销。
复杂授权撤销指具有一个或多个间接授权的授权撤销。流程为：DU1拥有授权，DU1授权给DU2，DU2不仅使用访问资源的权限，还授权给DU3。然而，所有复杂的授权撤销都是通过基本的授权撤销逐步完成的。
复杂授权撤销流程：
①DU1(授权者)与Cloud通过远程认证建立可信通信通道后，Client Enclave向ACEE Enclave发送权限撤销信息，authRevoc为权限撤销请求标志。
②ACEE Enclave解密得到authRevoc||AddrDU1||AddrDU2||resInfo，然后调用QueryCap查询AddrDU1是否有授权给AddrDU2的能力。
③BC将查询结果列表(DU1对DU2授权、DU2对DU3授权)返回给ACEE Enclave。
④ACEE Enclave得到查询结果列表，分别解密resCAP_S’得到resCAP，’若resCAP’不为空，则通知DU2撤销对DU3的授权。
⑤DU2在Client Enclave中调用Tpublish(AddrDU2,AddrDU3,KpubC,resIno)发布授权撤销交易到BC中，其中resInfo.resCAP＝＝null。
⑥BC返回交易标志tranID1给DU2，然后由DU2中的Client Enclave向Cloud发送撤销完成表示Revoke Over。
⑦ACEE Enclave与DU1中的Client Enclave通信，发送允许授权撤销标志authRevoc给DU1。
⑧DU1中Client Enclave调用Tpublish(AddrDU1,AddrDU2,KpubC,resIno)发布授权撤销交易到BC中，其中resInfo.resCAP＝＝null。
⑨BC返回交易标志tranID2给DU1，然后DU1中Client Enclave与DU2(请求者)中ACEE Enclave通过远程认证建立可信通信通道，并由DU1向DU2发送authRevoc||AddrDU1||AddrDU2||resInfo.resID，通知DU2权限被撤销。
与现有技术相比，本发明的优点在于：
(1)可信的分布式访问控制体系结构。本发明采用分散、防篡改的区块链存储访问控制权限，以区块链账户地址作为身份，同时设计访问控制、授权和授权撤销流程，利用SGX技术保证访问控制策略实施过程。
(2)授权隐私保护。由于区块链公开透明，容易泄露用户隐私。本发明将访问控制权限加密存储在区块链中，有效保护用户隐私。
(3)可信访问控制。由于传统云访问控制中ACEE运行在非安全环境，容易遭受攻击泄露隐私。本发明将ACEE运行在SGX保护的安全环境中，同时解决客户端和服务器的可信认证和密钥封装问题，有效保护访问控制实施过程的机密性和完整性。
(4)安全。本发明保证资源的机密性、完整性、可用性、真实性和可问责性，同时可有效防止黑客和云内部管理人员对资源的非法访问，而且还保证访问控制实施过程的机密性和完整性。
附图说明
图1是本发明实施例去中心化可信访问控制框架结构图；
图2是本发明实施例Cloud注册流程图；
图3是本发明实施例DO或DU注册流程图；
图4是本发明实施例资源上传流程图；
图5是本发明实施例访问控制流程图；
图6是本发明实施例直接授权流程图；
图7是本发明实施例间接授权流程图；
图8是本发明实施例直接授权撤销流程图；
图9是本发明实施例间接授权撤销流程图；
图10是本发明实施例TEE算法时间开销曲线图；
图11是本发明实施例加解密开销对比曲线图；
图12是本发明实施例吞吐量对比曲线图；
图13是本发明实施例时间开销对比曲线图。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚明白，以下根据附图并列举实施例，对本发明做进一步详细说明。
一种云环境中基于SGX的去中心化可信访问控制框架，包括：Cloud(云)、BC(区块链)、数据用户(DU)、数据所有者(DO)
①Cloud：它为用户提供身份验证和数据存储。Cloud通过区块链确定DU或DO的访问权限，由访问控制服务器(ACS)对DO或DU进行访问控制，ACS底层硬件支持SGX，ACS上的ACEE运行在SGX保护的ACEE Enclave中，同时Cloud初始化成为区块链用户时，密钥等私密数据由基于ACEE Enclave身份进行密封保存。
②BC：它具有开放、透明、防篡改、不可逆的特点，与分布式数据库一样，我们将其作为授权数据库进行访问控制。
③DO：DO将资源上载到Cloud，并将资源的访问权限发布到BC中。运行在支持SGX的客户端程序中，初始化成为区块链用户时，密钥等私密数据由Client Enclave密封存储。
④DU：DU如果由Cloud的许可就可访问资源。运行在支持SGX的客户端程序中，初始化成为区块链用户时，密钥等私密数据由基于Client Enclave身份进行密封保存。
如图1所示，假设云是半可信的，即云的软件、硬件、非对称密钥和业务流程都是可信的，而云SA是不可信的；BC认为是可信的；SGX认为是可信的，即基于SGX的远程认证、密封、Enclave是可信的。DO将资源上传到Cloud，然后在BC中通过注册交易发布权限。DU将对资源的请求发送到Cloud，Cloud查询BC，由BC返回权限给Cloud，由Cloud判断请求是否有权限，最后回复请求给DU。
为保证实体间通信安全，我们要求各实体在数据传输之前已经通过基于SGX的远程认证过程，来对通信双方的身份和运行环境是否可信进行证明，所有的远程认证均为双向认证。此外，为了便于描述，可将整个可信执行环境(TEE)抽象为一个算法集合∑TEE，TEE对应的Enclave操作可分为∑TEE.init(初始化)和∑TEE.run(运行)。TEE初始化完毕后会生成一对TEE密钥对(pkTEE,skTEE)，其中pkTEE为主公钥，skTEE为主私钥，由于硬件型号群组共享，因此pkTEE公开为所有人可知。
定义1.∑TEE.init(prog)->encid：Enclave实例初始化函数，输入为Enclave程序代码prog，输出为对应的Enclave实例的encid。
定义2.∑TEE.run(encid,func,args)->(outp,σTEE)：Enclave中程序执行函数，在初始化∑TEE.init后执行，输入为encid,func,args，其中encid为指定的Enclave实例，func为指定的程序代码，args为传入func的参数，输出为func执行的结果outp和硬件签名证明σTEE，其中σTEE＝∑TEE.Sig(skTEE,(func,outp))。
定义3.∑TEE.ver(pkTEE,(prog,outp),σTEE)->true or false：验证硬件签名函数，输入pkTEE来验证硬件签名σTEE是否有效，有效则输出true，否则输出false。
定义4.sgx_seal_data(data,sealkey)->dataseal：基于Enclave身份的密封函数，对data进行密封，存储在Enclave外，输入为密封数据data和密钥sealkey，输出为密封结果dataseal。
定义5.sgx_unseal_data(dataseal,sealkey)->data：基于Enclave身份的解封函数，通过sealkey恢复密封的data，输入为密封结果dataseal和密钥sealkey，输出为data。
下面我们来介绍一下后面用到的一些符号。首先，列出了一些重要的函数和符号，如表1所示。然后，列出了一些关键字段和集合，如表2所示。
表1符号表
Figure BDA0003131885600000181
表2集合和字段定义
Figure BDA0003131885600000182
Figure BDA0003131885600000191
一种云环境中基于SGX的去中心化可信访问控制框架运行方法，包括以下步骤：
1初始化
1.1实体注册
实体注册阶段要求Cloud、DO、DU注册成为区块链节点，其中DU和DO注册相同，我们统称为User注册。在设计注册流程之前，我们引入了KGen()，AGen()和SynData()，这三个函数都是基于区块链实现的。KGen()生成KW，输入NULL，输出KW；AGen()生成Addr，输入为KWpub，输出为Addr。SynData()旨在同步ti到tj的数据，输入为ti和tj，输出为块数据tij。
然后我们设计Cloud注册流程如图2所示，包括3个步骤：
①Cloud->BC:CRequest||ti||tj.ACEE Enclave将请求CRequest||ti||tj发送给服务器，然后由Cloud向BC发送注册请求。
②BC->Cloud:E(ks1,Addrcloud||KWcloud)||E(KpubC,ks1)||blockdataij。BC调用KGen()生成KWcloud(KWpubCloud,KWpriCloud),然后调用AGen(KWpubCloud)生成Addrcloud。区块链利用ks1加密Addrcloud||KWcloud,KpubC加密ks1,然后发送E(ks1,Addrcloud||KWcloud)||E(KpubC,ks1)||blockdataij给Cloud，其中blockdataij表示区块链中ti到tj的数据。通常，Cloud会自动调用SynData(ti,tj)将blockdataij同步到本地数据库。
③Cloud:sgx_seal_data(KWcloud,sealkeycloud)||sgx_seal_data(KC,sealkeycloud)。Cloud先调用D(KpriC,ks1)解密得到ks1,然后调用D(ks1,Addrcloud||KWcloud)解密得到Addrcloud||KWcloud，再调用sgx_seal_data(KWcloud,sealkeycloud)，在ACEE Enclave中使用对称密封密钥sealkeycloud将KWcloud进行密封存储，密封结果为datasealcloud1。同样的，Cloud还需将KC进行密封存储，密封结果为datasealcloud2。
接下来，我们设计User注册流程如图3所示，包括3个步骤：
①User->BC:URequest||tl||tm.Client Enclave将请求URequest||tl||tm发送给客户端，User向BC发送注册请求。
②BC->User:E(ks2,Addruser||KWuser)||E(KpubUser,ks2)||blockdatalm。BC调用KGen()生成KWuser(KWpubUser KWpriUser),然后调用AGen(KWpubUser)生成Addruser。BC发送E(ks2,Addruser||KWuser)||E(KpubUser,ks2)||blockdatalm给User。其中blockdatalm表示区块链中tl到tm的数据。通常，User会自动调用SynData(tl,tm)将blockdatalm同步到本地数据库。
③User:sgx_seal_data(KWuser,sealkeyuser)。User调用D(KpriUser,ks2)和D(ks2,Addruser||KWuser)解密得到Addruser||KWuser，然后调用sgx_seal_data(KWuser,sealkeyuser)，在Client Enclave中使用对称密封密钥sealkeyuser将KWuser进行密封存储，密封结果为datasealuser。
1.2资源发布
资源发布就是DO将资源发布到云端，然后将资源元数据发布到BC上。在设计资源注册流程之前，我们先介绍1个函数ResUp()和1个区块链接口TxSend()。ResUp()目的是通过DO将资源上传到云端，DO输入resContent和resUpURL，输出resInfo；TxSend()是区块链交易接口，输入KWpri,Addrfrom,Addrto,index,content,timestamp,输出为tranID。
接下来，我们设计了资源上传的流程，如图4所示，包括3个步骤。
①DO->Cloud:ResUp(resContent,resUpUrl)。DO和Cloud之间进行双向远程认证，认证对方身份是否可信，运行环境是否可信，以此来建立远程认证通道。然后由ClientEnclave调用ResUp(resContent,resUpUrl)将资源上传到Cloud。
②Cloud->DO:E(ks3,resInfo)||E(KpubDO,ks3)。ACEE Enclave将E(ks3,resInfo)||E(KpubDO,ks3)给DO，DO利用D(KpriDO,ks3)和D(ks3,resInfo)解密得到resInfo。
③DO->BC:Tresource(AddrDO,Addrcloud,KpubC,resInfo,resCAP)。Client Enclave调用Tresource将资源注册到区块链，其中Tresource为智能合约，如算法1所示。
在合约Tresource中，行1为初始化Enclave；行2为对resID进行哈希处理；行3为加密资源权限resCAP；行4-8判断加密权限是否成功，如果成功则设置resInfo，否则返回false；行9为初始化资源注册信息，行10为恢复密封的钱包密钥KWpriDO；行11获取时间戳；行12调用TxSend()来发布资源注册交易；最后返回tranID和σTEE。
Figure BDA0003131885600000211
2访问控制流程
访问控制是User向Cloud请求访问资源，Cloud查询BC，根据BC中存储的权限决定User是否可以访问资源。如果User有权限，Cloud则返回User符合其访问权限的回应，并将User访问记录存储在区块链中。在设计访问控制流程之前，我们先介绍1个基于区块链实现的查询接口TxQuery()。TxQuery()实现的是合约查询接口，输入为Addrfrom,Addrto,index,输出为发送方Addrfrom发送给Addrto的最新一笔交易tran。
然后我们设计访问控制流程，如图5所示，包括7个步骤。
①User->Cloud.E(ks4,Addruser||resInfo’)||E(KpubC,ks4).User和Cloud之间进行双向远程认证后，Client Enclave向ACEE Enclave发起请求E(ks4,Addruser||resInfo’)||E(KpubC,ks4)，其中resInfo’表示它想访问的资源。
②Cloud->BC:Addruser||Addrcloud||hashresID.ACEE Enclave接收到请求，先调用D(KpriC,ks4)和D(ks4,Addruser||resInfo’)解密得到Addruser||resInfo，’然后调用Hash(resID)计算得到hashresID，最后调用智能合约QueryCap()向区块链发起权限查询请求，如算法2所示。
Figure BDA0003131885600000221
③BC->Cloud：resCAP_S||σSTEE.BC返回resCAP_S||σTEE给ACEE Enclave。
④Cloud:VerifyCap(resCAP’,resCAP_S,σTEE).ACEE Enclave调用VerifyCap验证Addruser是否具备访问能力，如算法3所示.
Figure BDA0003131885600000231
⑤Cloud->User:ResponseAccessInfo.ACEE Enclave将ResponseAccessInfo返回给Client Enclave.若ResponseAccessInfo为true，则User可访问资源，否则不允许User访问资源。
⑥Cloud->BC:Taccesslog(Addruser,Addrcloud,AddrDO,resInfo’,accessTime).ACEE Enclave调用Taccesslog将访问记录发布到区块链，其中Taccesslog为智能合约，如算法4所示。
Figure BDA0003131885600000232
3具有隐私保护的授权
授权分为直接授权(DO授权给DU)和间接授权(已获得授权DU对欲授权DU进行授权)。
3.1直接授权
直接授权是指资源所有者将访问权限授予其他用户，我们设计直接授权流程如图6所示，包括8个步骤。
①DU1->Cloud:E(ks5,authFlag||AddrDO||AddrDU1||resInfo)||E(KpubC,ks5)。DU1和Cloud之间进行双向远程认证后，Client Enclave向ACEE Enclave发起请求，其中authFlag是授权请求，ACEE Enclave解密得到authFlag||AddrDO||AddrDU1||resInfo。
②Cloud->BC:AddrDO||Addrcloud||hashresID。ACEE Enclave计算Hash(resInfo.resID)得到hashresID，调用QueryCap(AddrDO||Addrcloud||hashresID)查询AddrDO是否具备授权能力。
③BC->Cloud：resCAP_S。’BC返回resCAP_S’给ACEE Enclave。
④Cloud:VerifyCap(resCAP,resCAP_S’,σTEE)，ACEE Enclave解密resCAP_S’得到resCAP，’检查AddrDU1请求的权限是否在DO的授权范围之内，是则执行下一步。
⑤Cloud->DO:E(ks6,AddrDU1||resInfo)||AuthPermit)||E(KpubDO,ks6)，Cloud和DO之间进行双向远程认证，ACEE Enclave通知Client Enclave进行授权，并发送授权许可标志AuthPermit。
⑥DO->BC:Tpublish(AddrDO,AddrDU1,KpubC,resInfo)，Client Enclave调用Tpublish将授权发布到区块链，如算法5所示。
Figure BDA0003131885600000251
⑦BC->DO:tranID.BC返回授权交易tranID给Client Enclave。
⑨DO->DU1:authFlag.DO发送authFlag给DU1。
3.2间接授权
间接授权是指已被授权的DU对其他用户进行授权，包括至少5个实体：DO(资源所有者)、DU1(授权者)、DU2(请求者)、BC和Cloud。
从图7来看，间接授权和直接授权的步骤基本相同，间接授权和直接授权的区别在于授权DU2需要发送间接授权通知E(ks9,authFlag||AddrDU2||resInfo||authTime)||E(KpubDO,ks9)给DO，这里不再赘述。
4具有隐私保护的授权撤销
授权撤销是指授权用户撤销授权。授权撤销是一个非常复杂的过程。为了规范授权撤销过程，我们定义了以下规则：
(1)谁授权谁撤销。
(2)所有者可以撤销直接授权和间接授权。
(3)只有当授权用户撤销所有授权时，上一级授权用户才能撤销该授权用户的授权。
根据上述三条规则，授权撤销包括基本授权撤销和复杂授权撤销。基本授权撤销是授权撤销的基本操作单元，即撤销不再具有间接授权的权限。例如，我们假设DU1授权给DU2，而DU2不再有任何间接授权。我们设计了基本授权撤销的工作流程，如图8所示，包括6个步骤。
①DU1->Cloud:E(ks10,authRevoc||AddrDU1||AddrDU2||resInfo)||E(KpubC,ks10)，DU1与Cloud通过远程认证建立可信通信通道后，Client Enclave向ACEE Enclave发送权限撤销信息，authRevoc为权限撤销请求标志。
②Cloud->BC:AddrDU1||AddrDU2||hashresID，ACEE Enclave解密得到authRevoc||AddrDU1||AddrDU2||resInfo，然后调用QueryCap查询AddrDU1是否有授权给AddrDU2的能力。
③BC->Cloud:resCAP_S’.BC将查询结果返回给ACEE Enclave。
④Cloud->DU1:authRevoc.ACEE Enclave解密resCAP_S’得到resCAP，’若resCAP’不为空，则发送授权撤销标志authRevoc给DU1。
⑤DU1->BC:Tpublish(AddrDU1,AddrDU2,KpubC,resInfo)。Client Enclave调用Tpublish发布授权撤销交易，其中resInfo.resCAP＝＝null。
⑥DU1->DU2:E(ks11,authRevoc||AddrDU1||AddrDU2||resInfo.resID)||E(KpubDU2,ks11)，DU1中Client Enclave与DU2中ACEE Enclave通过远程认证建立可信通信通道，并由DU1向DU2发送authRevoc||AddrDU1||AddrDU2||resInfo.resID，通知DU2权限被撤销。
复杂授权撤销通常是指具有一个或多个间接授权的授权撤销。例如，我们假设这样的场景：DU1拥有授权，DU1授权给DU2，DU2不仅使用访问资源的权限，还授权给DU3。具体的交互过程如图9所示。然而，所有复杂的授权撤销都是通过基本的授权撤销逐步完成的，因此不再重复叙述。
5本发明的实验与性能评估
5.1实验环境
本实施例的实验平台是ubuntu 16.04(2核，16G内存，60G存储)和Windows10(2核，12G内存，1T存储)。我们选择了EOS的CryptoKylin-Testnet作为我们的区块链环境，它是典型的EOS测试链之一，版本为v1.8.12，chain-ID为5fff1dae8dc8e2fc4d5b23b2c7665c97f9e9d8edf2b6485a86ba311c25639191.。辅助工具是SCONE[Arnautov S,Trach B,Gregor F,et al.{SCONE}:Secure linux containers with intel{SGX}[C]//12th{USENIX}Symposium on Operating Systems Design and Implementation({OSDI}16).2016:689-703]，它构建了一个基于SGX的可信docker，其版本为v19.03.8。使用SCONE构建TEE，使用SCONE提供的fspf命令对KW和K进行加密，并使用EOS-Encrypt库进行加解密，使用SGX远程认证建立可信的通信通道来保证通信安全，使用高级加密标准(AES)来保证通信的机密性。
然后，在表3中，我们测试访问控制，其中“-”表示操作未执行。
表3访问控制结果
Figure BDA0003131885600000271
5.2性能评估
在性能评估中，重点研究了本发明框架函数评估和时间性能开销。在功能评估方面，首先对本发明框架的功能与近年来的云访问控制解决方案进行了比较，访问结果如表4所示，其中现有技术文献出处如下：
[1]Zhang P,Chen Z,Liang K,et al.A cloud-based access control schemewith user revocation and attribute update[C]//Australasian Conference onInform ation Security and Privacy.Springer,Cham,2016:525-540.
[2]Xia Q,Sifah E B,Smahi A,et al.BBDS:Blockchain-based data sharin gfor electronic medical records in cloud environments[J].Information,2017,8(2):44.
[3]Wang S,Wang X,Zhang Y.A secure cloud storage framework with accesscontrol based on blockchain[J].IEEE Access,2019,7:112713-112725.
[4]Xia Q I,Sifah E B,Asamoah K O,et al.MeDShare:Trust-less medicaldata sharing among cloud service providers via blockchain[J].IEEE Access,2017,5:14757-14767.
[5]Alansari S,Paci F,Margheri A,et al.Privacy-preserving accesscontrolin cloud federations[C]//2017IEEE 10th International Conference onCloud Computing(CLOUD).IEEE,2017:757-760..
表4与其他相关方案的比较
Figure BDA0003131885600000281
Figure BDA0003131885600000291
在表4中，本发明框架比其他方案更具功能性和安全性。以文献[1]为例，与传统的云访问控制方案相比，除了本发明框架运行在TEE之外，本发明框架执行还有额外的消耗，主要体现在智能合约方法调用消耗。与以太坊部署和执行智能合约需要消耗Gas类似，EOS部署和执行智能合约需要消耗RAM。由于EOS价格不稳定，测试时0.05650EOS可购买1KBRAM，1EOS≈1.8969USD，1KB RAM＝103byte RAM.
表5列举了本发明框架智能合约的消耗，Tresource、Tauth、Taccesslog只需创建1次，DO将资源上传到Cloud后发表资源注册交易消耗为18.4972USD，授权和撤销交易消耗为18.0072USD，访问记录消耗为12.90953USD。这些成本均基于部署到EOS的本发明框架实验原型，可以通过优化代码来降低成本。
表3智能合约消耗(RAMPrice＝0.05650EOS,1EOS≈1.8969USD)
功能 RAM使用(byte) 实际花销(EOS) USD
Tresource合约创建 172589 9.751279 18.4972
Tauth合约创建 168017 9.492961 18.0072
Taccesslog合约创建 120453 6.805595 12.90953
资源注册 152 0.008588 0.016291
授权 328 0.018532 0.035153
授权撤销 288 0.016272 0.030866
访问记录 344 0.019436 0.036868
时间性能方面。本发明框架在TEE中运行，使用Addr进行身份验证，ACEE查询BC中存储的resCAP_S来验证权限。
首先，考虑到本发明框架在TEE中运行，我们测试了TEE算法的时间开销。∑TEE.init初始化操作通常只需执行一次，平均时间开销为1.5s，因此我们将重点放在其他四个TEE算法上。如图10所示，我们测试10个组，每组取10个测试平均值，
从图10可以看出，在TEE内执行某个功能函数时间开销约为0.1s，验证硬件签名时间约为0.08s，对KW，KC，KDO，KDU密钥对密封时间约为0.23s，解封时间约为0.008s。由此可见，用于加解密的密钥解封时间花销非常小，利用SGX密封技术对密钥进行存储保证安全的同时性能也较好。
其次，本发明框架需要存储在区块链中的hashresID作为交易资产单位来查询授权交易，因此哈希时间开销可能会影响查询效率。因此，我们测试了SHA256的哈希时间开销，结果显示，当resID属性数为128字节时，哈希时间开销小于1ms。
表4SHA256时间开销对比
Figure BDA0003131885600000301
再次，本发明框架对TEE中的resCAP进行加密并存储在区块链中，然后查询解密resCAP_S来进行权限验证。我们将本发明框架与比较方案[Yang K,Jia X.Attributed-based access control for multi-authority systems in cloud storage[C]//2012IEEE 32nd International Conference on Distributed Computing Systems.IEEE,2012:536-545.]进行了比较，如图11所示。结果表明，本发明框架在TEE中进行加密和解密，并且还需要取出密封密钥进行加密和解密，但其加解密时间开销要优于比较方案。
此外，考虑吞吐量是目前衡量网络性能的重要指标。因此，我们将运行在TEE中的本发明框架与传统云的每秒写入事务数(TPS)进行比较，测试事务数为100-1000。其中，使用EOSBenchTool对本发明框架的EOS进行单节点单线程测试，使用sysbench测试MySQL5.7进行测试。如图12所示，其中本发明框架的TPS约为1200，延迟为0，Cloud的TPS约为780。当Cloud的交易数为1000时，延迟为0.5s。因此，在实际应用中可以通过优化配置来提升本发明框架的性能。
最后，我们运行在TEE下的本发明框架与传统云平台的访问控制时间进行对比，将Alibaba Cloud的部署的MySQL 5.7作为传统云平台的授权数据库，测试数20,40,60,80,100，取10次测试平均值，数据库数据为500，本发明框架合约存储数据为500，假设存入MySQL5.7的数据经过相同的加密处理，忽略用户输入、网络等因素影响，测试结果如图13所示。
如图13所示，实验结果表明，运行在TEE下的本发明框架与传统云相比，主要区别在于传统云访问控制基本在云端完成，查询部署在云端的授权数据库中指定授权交易时间花销为0.27s左右，而本发明框架需要在基于SGX保护的TEE内与区块链进行交互，通过存储在链上的合约表的时间花销为1.116s，因此时间花销上会比传统Cloud多一些，但考虑到本发明框架运行在TEE，其安全性能更高，因此整体上来看该时间花销也是可接受的。
本领域的普通技术人员将会意识到，这里所述的实施例是为了帮助读者理解本发明的实施方法，应被理解为本发明的保护范围并不局限于这样的特别陈述和实施例。本领域的普通技术人员可以根据本发明公开的这些技术启示做出各种不脱离本发明实质的其它各种具体变形和组合，这些变形和组合仍然在本发明的保护范围内。

Claims (5)

1.一种去中心化可信访问控制框架，其特征在于，包括：Cloud(云)、BC(区块链)、DU(数据用户)和DO(数据所有者)；
Cloud：它为用户提供身份验证和数据存储；Cloud通过区块链确定DU或DO的访问权限，由访问控制服务器(ACS)对DO或DU进行访问控制，ACS底层硬件支持SGX，ACS上的ACEE运行在SGX保护的ACEE Enclave中，同时Cl oud初始化成为区块链用户时，私密数据由基于ACEEEnclave身份进行密封保存；
②BC：它具有开放、透明、防篡改、不可逆的特点，与分布式数据库一样，我们将其作为授权数据库进行访问控制；
③DO：DO将资源上载到Cloud，并将资源的访问权限发布到BC中；运行在支持SGX的客户端程序中，初始化成为区块链用户时，私密数据由Client En clave密封存储；
④DU：DU得到由Cloud的许可就可访问资源；运行在支持SGX的客户端程序中，初始化成为区块链用户时，私密数据由基于Client Enclave身份进行密封保存；
DO将资源上传到Cloud，然后在BC中通过注册交易发布权限；DU将对资源的请求发送到Cloud，Cloud查询BC，由BC返回权限给Cloud，由Cloud判断请求是否有权限，最后回复请求给DU；
去中心化可信访问控制框架中的定义：
∑TEE.init(prog)->encid：Enclave实例初始化函数，输入为Enclave程序代码prog，输出为对应的Enclave实例的encid；
∑TEE.run(encid,func,args)->(outp,σTEE)：Enclave中程序执行函数，在初始化∑TEE.init后执行，输入为encid,func,args，其中encid为指定的Enclave实例，func为指定的程序代码，args为传入func的参数，输出为func执行的结果outp和硬件签名证明σTEE，其中σTEE＝∑TEE.Sig(skTEE,(func,outp))；
∑TEE.ver(pkTEE,(prog,outp),σTEE)->true or false：验证硬件签名函数，输入pkTEE来验证硬件签名σTEE是否有效，有效则输出true，否则输出false；
sgx_seal_data(data,sealkey)->dataseal：基于Enclave身份的密封函数，对data进行密封，存储在Enclave外，输入为密封数据data和密钥sealkey，输出为密封结果dataseal；
sgx_unseal_data(dataseal,sealkey)->data：基于Enclave身份的解封函数，通过sealkey恢复密封的data，输入为密封结果dataseal和密钥sealkey，输出为dat a；
E(key,M)/D(key,N)：表示加密/解密函数.E()用于加密M，D()使用key解密N,key可以是对称密钥对或非对称密钥对；
Hash(M)：表示Hash函数；
KC：表示Cloud非对称密钥对，KC包括公钥KpubC和私钥KpriC；
KDO：表示DO非对称密钥对，KDO包括公钥KpubDO和私钥KpriDO；
KDU：表示DU非对称密钥对，KDU包括公钥KpubDU和私钥KpriDU；
KW：表示生成钱包地址的非对称密钥.KW包括公钥KWpub和私钥KWpri；
ks：表示对称密钥；
Addr：表示区块链中的钱包地址，即用户的身份；
resCAP：资源的访问权限.resCAP＝{p,m,exp},其中p是访问控制策略,比如DAC,BLP,RBAC等；m是资源访问模式,比如up,down,modify,delete；exp是资源访问有效期；
resCAP_S：表示加密的resCAP；
resInfo：资源信息集.resInfo＝{resOwnerID,resID,resName,resCAP,resURL},其中resOwnerID是资源所有者唯一标识符，resID是资源的唯一标识符，resName是资源名称，resCAP是资源访问权限，resURL是资源访问地址；
bresInfo：区块链资源信息集.bresInfo＝{actionInfo,resInfo},其中actionInfo是资源附加信息，resInfo是资源信息集；
tran：它代表了区块链集合的一种交易；tran＝{tranID,Addrfrom,Addrto,value,bresInfo},其中tranID是交易编号，Addrfrom是交易发起者，Addrto是交易接收者，value是交易值，bresInfo是区块链资源信息集。
2.根据权利要求1所述的去中心化可信访问控制框架的实体注册方法，其特征在于，包括：Cloud注册、User注册和资源发布；
实体注册阶段要求Cloud、DO、DU注册成为区块链节点，其中DU和DO注册相同，统称为User注册，首先引入了KGen()，AGen()和SynData()，KGen()生成KW，输入NULL，输出KW；AGen()生成Addr，输入为KWpub，输出为Addr；SynData()旨在同步ti到tj的数据，输入为ti和tj，输出为块数据tij；
Cloud注册流程，包括以下步骤：
①CRequest||ti||tj.ACEE Enclave将请求CRequest||ti||tj发送给服务器，然后由Cloud向BC发送注册请求；
②BC调用KGen()生成KWcloud(KWpubCloud,KWpriCloud),然后调用AGen(KWpubCloud)生成Addrcloud；区块链利用ks1加密Addrcloud||KWcloud,KpubC加密ks1,然后发送E(ks1,Addrcloud||KWcloud)||E(KpubC,ks1)||blockdataij给Cloud，其中blockdataij表示区块链中ti到tj的数据；通常，Cloud会自动调用SynData(ti,tj)将blockdataij同步到本地数据库；
③Cloud先调用D(KpriC,ks1)解密得到ks1,然后调用D(ks1,Addrcloud||KWcloud)解密得到Addrcloud||KWcloud，再调用sgx_seal_data(KWcloud,sealkeycloud)，在ACEE Enclave中使用对称密封密钥sealkeycloud将KWcloud进行密封存储，密封结果为datasealcloud1；同样的，Cloud还需将KC进行密封存储，密封结果为datasealcloud2；
User注册流程，包括以下步骤：
①URequest||tl||tm.Client Enclave将请求URequest||tl||tm发送给客户端，User向BC发送注册请求；
②BC调用KGen()生成KWuser(KWpubUser KWpriUser),然后调用AGen(KWpubUser)生成Addruser；BC发送E(ks2,Addruser||KWuser)||E(KpubUser,ks2)||blockdatalm给User；其中blockdatalm表示区块链中tl到tm的数据；通常，User会自动调用SynData(tl,tm)将blockdatalm同步到本地数据库；
③User调用D(KpriUser,ks2)和D(ks2,Addruser||KWuser)解密得到Addruser||KWuser，然后调用sgx_seal_data(KWuser,sealkeyuser)，在Client Enclave中使用对称密封密钥sealkeyuser将KWuser进行密封存储，密封结果为datasealuser；
资源发布方法是DO将资源发布到云端，然后将资源元数据发布到BC上；引入1个函数ResUp()和1个区块链接口TxSend()；ResUp()目的是通过DO将资源上传到云端，DO输入resContent和resUpURL，输出resInfo；TxSend()是区块链交易接口，输入KWpri,Addrfrom,Addrto,index,content,timestamp,输出为tranID；
资源发布的具体流程，包括3个步骤；
①DO和Cloud之间进行双向远程认证，认证对方身份是否可信，运行环境是否可信，以此来建立远程认证通道；然后由Client Enclave调用ResUp(resContent,resUpUrl)将资源上传到Cloud；
②ACEE Enclave将E(ks3,resInfo)||E(KpubDO,ks3)给DO，DO利用D(KpriDO,ks3)和D(ks3,resInfo)解密得到resInfo；
③Client Enclave调用Tresource将资源注册到区块链，其中Tresource为智能合约，如算法1所示；
Figure FDA0003131885590000051
在合约Tresource中，行1为初始化Enclave；行2为对resID进行哈希处理；行3为加密资源权限resCAP；行4-8判断加密权限是否成功，如果成功则设置resInfo，否则返回false；行9为初始化资源注册信息，行10为恢复密封的钱包密钥KWpriDO；行11获取时间戳；行12调用TxSend()来发布资源注册交易；最后返回tranID和σTEE。
3.根据权利要求1所述的去中心化可信访问控制框架的访问控制方法，其特征在于，包括以下步骤：
在访问控制之前，引入一个基于区块链实现的查询接口TxQuery()，TxQuery()实现的是合约查询接口，输入为Addrfrom,Addrto,index,输出为发送方Addrfrom发送给Addrto的最新一笔交易tran；
访问控制流程，包括以下步骤：
①User和Cloud之间进行双向远程认证后，Client Enclave向ACEE Enclave发起请求E(ks4,Addruser||resInfo’)||E(KpubC,ks4)，其中resInfo’表示它想访问的资源；
②ACEE Enclave接收到请求，先调用D(KpriC,ks4)和D(ks4,Addruser||resInfo’)解密得到Addruser||resInfo，’然后调用Hash(resID)计算得到hashresID，最后调用智能合约QueryCap()向区块链发起权限查询请求，QueryCap()如算法2所示；
Figure FDA0003131885590000061
③BC返回resCAP_S||σTEE给ACEE Enclave；
④ACEE Enclave调用VerifyCap验证Addruser是否具备访问能力，VerifyCap如算法3所示.
Figure FDA0003131885590000062
⑤ACEE Enclave将ResponseAccessInfo返回给Client Enclave.若ResponseAccessInfo为true，则User可访问资源，否则不允许User访问资源；
⑥ACEE Enclave调用Taccesslog将访问记录发布到区块链，其中Taccesslog为智能合约如算法4所示；
Figure FDA0003131885590000071
4.根据权利要求1所述的去中心化可信访问控制框架的授权方法，其特征在于，包括：DO授权给DU的直接授权和已获得授权DU对欲授权DU进行授权的间接授权；
直接授权包括以下步骤：
①DU1(授权者)和Cloud之间进行双向远程认证后，Client Enclave向ACEE Enclave发起请求，其中authFlag是授权请求，ACEE Enclave解密得到authFlag||AddrDO||AddrDU1||resInfo；
②ACEE Enclave计算Hash(resInfo.resID)得到hashresID，调用QueryCap(AddrDO||Addrcloud||hashresID)查询AddrDO是否具备授权能力；
③BC返回resCAP_S’给ACEE Enclave；
④ACEE Enclave解密resCAP_S’得到resCAP，’检查AddrDU1请求的权限是否在DO的授权范围之内，是则执行下一步；
⑤Cloud和DO之间进行双向远程认证，ACEE Enclave通知Client Enclave进行授权，并发送授权许可标志AuthPermit；
⑥Client Enclave调用Tpublish将授权发布到区块链，Tpublish如算法5所示；
Figure FDA0003131885590000081
⑦BC返回授权交易tranID给Client Enclave；
⑧DO发送authFlag给DU1；
所述间接授权是指已被授权的DU对其他用户进行授权，包括至少5个实体：DO(资源所有者)、DU1(授权者)、DU2(请求者)、BC和Cloud；
间接授权和直接授权的区别在于授权DU2需要发送间接授权通知E(ks9,authFlag||AddrDU2||resInfo||authTime)||E(KpubDO,ks9)给DO；
间接授权步骤如下：
①DU2与Cloud进行双向远程认证之后，Client Enclave向ACEE Enclave发起请求E(ks7,authFlag||AddrDU1||AddrDU2||resInfo)||E(KpubC,ks7)，其中authFlag为DU2请求授权标志；Cloud解密得到authFlag||AddrDU1||AddrDU2||resInfo；
②ACEE Enclave计算Hash(resInfo.resID)得到hashresID，调用QueryCap(AddrDU1||Addrcloud||hashresID)查询AddrDU1是否具备授权能力；
③BC返回resCAP_S’给ACEE Enclave；
④ACEE Enclave解密resCAP_S’得到resCAP，’检查AddrDU2请求的权限是否在DU1的授权范围之内，是则执行下一步；
⑤Cloud和DU1之间进行双向远程认证，ACEE Enclave通知Client Encla ve(DU1)进行授权，并发送授权许可标志AuthPermit；
⑥Client Enclave(DU1)调用Tpublish(AddrDU1,AddrDU2,KpubC,resInfo)将DU1对DU2的授权发布到区块链；
⑦BC返回授权交易tranID给Client Enclave(DU1)；
⑧DU1发送authFlag给DU2；
⑨DU2发送授权通知提醒E(ks9,authFlag||AddrDU2||resInfo||authTime)||E(KpubDO,ks9)给DO。
5.根据权利要求4所述的去中心化可信访问控制框架的授权撤销方法，其特征在于，包括：
定义了以下规则：
(1)谁授权谁撤销；
(2)所有者可以撤销直接授权和间接授权；
(3)只有当授权用户撤销所有授权时，上一级授权用户才能撤销该授权用户的授权；
根据上述三条规则，授权撤销包括基本授权撤销和复杂授权撤销；基本授权撤销是授权撤销的基本操作单元，即撤销不再具有间接授权的权限；
基本授权撤销包括以下步骤；
①DU1(授权者)与Cloud通过远程认证建立可信通信通道后，Client Enclave向ACEEEnclave发送权限撤销信息，authRevoc为权限撤销请求标志；
②ACEE Enclave解密得到authRevoc||AddrDU1||AddrDU2||resInfo，然后调用QueryCap查询AddrDU1是否有授权给AddrDU2的能力；
③BC将查询结果返回给ACEE Enclave；
④ACEE Enclave解密resCAP_S’得到resCAP，’若resCAP’不为空，则发送授权撤销标志authRevoc给DU1；
⑤Client Enclave调用Tpublish发布授权撤销交易，其中resInfo.resCAP＝＝null；
⑥DU1中Client Enclave与DU2(请求者)中ACEE Enclave通过远程认证建立可信通信通道，并由DU1向DU2发送authRevoc||AddrDU1||AddrDU2||resInfo.resID，通知DU2权限被撤销；
复杂授权撤销指具有一个或多个间接授权的授权撤销；流程为：DU1拥有授权，DU1授权给DU2，DU2不仅使用访问资源的权限，还授权给DU3；然而，所有复杂的授权撤销都是通过基本的授权撤销逐步完成的；
复杂授权撤销流程：
①DU1(授权者)与Cloud通过远程认证建立可信通信通道后，Client Enclave向ACEEEnclave发送权限撤销信息，authRevoc为权限撤销请求标志；
②ACEE Enclave解密得到authRevoc||AddrDU1||AddrDU2||resInfo，然后调用QueryCap查询AddrDU1是否有授权给AddrDU2的能力；
③BC将查询结果列表(DU1对DU2授权、DU2对DU3授权)返回给ACEE Enclave；
④ACEE Enclave得到查询结果列表，分别解密resCAP_S’得到resCAP，’若resCAP’不为空，则通知DU2撤销对DU3的授权；
⑤DU2在Client Enclave中调用Tpublish(AddrDU2,AddrDU3,KpubC,resIno)发布授权撤销交易到BC中，其中resInfo.resCAP＝＝null；
⑥BC返回交易标志tranID1给DU2，然后由DU2中的Client Enclave向Cloud发送撤销完成表示Revoke Over；
⑦ACEE Enclave与DU1中的Client Enclave通信，发送允许授权撤销标志authRevoc给DU1；
⑧DU1中Client Enclave调用Tpublish(AddrDU1,AddrDU2,KpubC,resIno)发布授权撤销交易到BC中，其中resInfo.resCAP＝＝null；
⑨BC返回交易标志tranID2给DU1，然后DU1中Client Enclave与DU2(请求者)中ACEEEnclave通过远程认证建立可信通信通道，并由DU1向DU2发送authRevoc||AddrDU1||AddrDU2||resInfo.resID，通知DU2权限被撤销。
CN202110705275.5A 2021-06-24 2021-06-24 去中心化可信访问控制框架及其运行方法 Pending CN113468610A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110705275.5A CN113468610A (zh) 2021-06-24 2021-06-24 去中心化可信访问控制框架及其运行方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110705275.5A CN113468610A (zh) 2021-06-24 2021-06-24 去中心化可信访问控制框架及其运行方法

Publications (1)

Publication Number Publication Date
CN113468610A true CN113468610A (zh) 2021-10-01

Family

ID=77872716

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110705275.5A Pending CN113468610A (zh) 2021-06-24 2021-06-24 去中心化可信访问控制框架及其运行方法

Country Status (1)

Country Link
CN (1) CN113468610A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118013559A (zh) * 2024-04-09 2024-05-10 南京邮电大学 基于区块链数据用户角色模型的印章数据加密安全系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118013559A (zh) * 2024-04-09 2024-05-10 南京邮电大学 基于区块链数据用户角色模型的印章数据加密安全系统

Similar Documents

Publication Publication Date Title
Yang et al. AuthPrivacyChain: A blockchain-based access control framework with privacy protection in cloud
US11971980B2 (en) Using trusted execution environments to perform a communal operation for mutually-untrusted devices
CN105745661B (zh) 对权限管理的内容的基于策略的受信任的检测
Krautheim et al. Introducing the trusted virtual environment module: a new mechanism for rooting trust in cloud computing
US8826391B2 (en) Virtualized trusted descriptors
AU2020244511B2 (en) Balancing public and personal security needs
US10498712B2 (en) Balancing public and personal security needs
US9544137B1 (en) Encrypted boot volume access in resource-on-demand environments
US20210374232A1 (en) Data distribution using a trusted execution environment in an untrusted device
US11575672B2 (en) Secure accelerator device pairing for trusted accelerator-to-accelerator communication
WO2015117523A1 (zh) 访问控制方法及装置
Yu et al. Enhancing security of Hadoop in a public cloud
US11947659B2 (en) Data distribution across multiple devices using a trusted execution environment in a mobile device
Khalil et al. TPM-based authentication mechanism for apache hadoop
WO2021218812A1 (zh) 通信方法、系统、装置、电子设备和可读存储介质
CN113468610A (zh) 去中心化可信访问控制框架及其运行方法
Park et al. CAFE: A virtualization-based approach to protecting sensitive cloud application logic confidentiality
US9509503B1 (en) Encrypted boot volume access in resource-on-demand environments
US11405201B2 (en) Secure transfer of protected application storage keys with change of trusted computing base
Hao et al. Trusted block as a service: Towards sensitive applications on the cloud
Kim et al. Secure user authentication based on the trusted platform for mobile devices
Kiyomoto et al. LMM: A common component for software license management on cloud
AU2016429414B2 (en) Balancing public and personal security needs
Chen et al. SecTube: SGX-based trusted transmission system
Huh et al. Towards a trustable virtual organisation

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination