去中心身份与可信身份,零信任架构

可信身份可以是中心化的,也可以是去中心化的,所以这里专门把可信、去中心二者并列。 中心化情况下,中心提供者无法自证清白,某些不诚实的中心提供者还会冒用用户身份作恶。 而且中心化逻辑下,中心保存了大量用户账号,中心需要承担非常高的安全压力。 比如服务器被入侵就导致了用户的安全问题。「防火墙/是网络作为安全边界,可信身份/零信任架构是身份作为安全边界!」

去中心身份与可信身份,零信任架构_第1张图片

互联网行业,身份存在的目的是告诉特定服务提供方(比如支付宝)“我是谁”。这个意义上讲,任何可以告诉别人我是谁的标记性信息都可以叫做身份。 传统互联网行业最常用的身份措施就是用户名,密码是用来保证用户名不被伪造的。

用户名/密码的方式有几个问题:

  • 第一, 身份数据泄露。
  • 第二, 登陆伪造,主要指的是中间人攻击。
  • 第三, 掌握你信息的中心化机构泄露你的数据。
  • 第四, 中心化机构不可用。
  • 第五, 繁琐的各种注册、填写信息,用户体验不好。 以上说的都是中心化身份/账户体系/登录逻辑的问题。
去中心身份与可信身份,零信任架构_第2张图片

接下来我说下去中心身份和登录是什么?

去中心身份是指身份数据的保存由owner自己控制,流转/使用过程完全由owner自己控制的一套账户产生、使用的机制。

解决什么问题:

用户无需注册,身份信息自主产生,哪些人能使用自己的身份信息由用户自己控制,用户不用一遍遍注册和填写资料。而且可以很方便的与个人生物识别信息关联,用户不用记录自己的身份信息。不再担心密码丢失。 比如,具体用例可以是这样:

  1. 用户在可信环境里(比如sgx环境,或者手机的trustzone里等等)生成私钥,且由可信环境保证永不导出。
  2. 首次使用时,用户把自己的个人信息在可信环境里用私钥签名,然后将这个信息发送到服务器。服务器验证签名,然后以公钥为依据注册这个用户的个人信息。
  3. 后续任何时候发起任何动作,都需要把业务数据在可信环境里用私钥签名,服务器验签,然后根据公钥找到这个用户的权限信息,然后鉴权及进行后续业务流程。
  4. 关键操作,比如付款等,可以再加个生物识别(指纹、虹膜、脸纹都可以),增加关键措操作安全性。
  5. 服务器验签及鉴权逻辑实时发送用户的行为数据到sparkstream等实时计算平台做安全大数据分析,及时发现安全问题。若有问题,直接撤销相关公钥的注册。
  6. 私钥无需备份,万一硬件丢失/损毁,重新走1的逻辑,业务方根据用户的个人信息做账户映射就行了。

相比传统账号/密码方式的优势:

去中心身份与可信身份,零信任架构_第3张图片
  1. 不需要用户记忆用户名密码,不存账号泄露问题,「无账号比有账号更安全」
  2. 服务端不存储用户账号,「不会有泄露用户账号风险」;同时,也因为这个原因,任何操作我们都可以确认是用户或者用户设备发起的操作,一旦有问题,服务提供方可以自证清白。
  3. 因为服务方不保存用户私钥,所以「避免了服务方冒充用户身份作恶的可能性」。账号层面,用户可以完全信任服务方。

「这个做法其实就是零信任架构的最基本过程,只不过传统零信任架构基于中心化实现,存在一些不好解决的问题(比如证书如何颁发,如何分发,如何确保设备可信性等等,还有中心化逻辑的服务器被入侵导致的身份泄露等问题)。」

复杂场景的实现方案

去中心身份与可信身份,零信任架构_第4张图片

接下来说下更复杂的场景(比如满足监管、实名等需求)的实现方案:「可信计算+去中心技术。」

「每个人的身份id可以自主选择和生成,这个id可以通过技术手段与具体的一个人的生物特征绑定。」 用户请求服务时,只需要带上这个id信息,由服务提供方验证这个id有哪些服务内容权限。

传统登录总是会有个C/S或者B/S的交互过程,这个交互过程通常不附带任何业务数据和逻辑,纯“验身”,实际上我们只需要在每次需要敏感服务的同时、携带上验身数据就够了。任何能让服务提供者知道“你是谁”的方式都能满足传统“登录”的需求,所以登陆逻辑不需要单独存在。

去中心登陆的实质就是:

「发起服务请求时随服务一起附带身份信息,同时这些身份信息不需要也不允许服务提供方存储、看到,只允许服务提供方使用。」

去中心身份与可信身份,零信任架构_第5张图片

「因为服务提供方不存储任何身份数据」 不能看到身份数据,只能”用“身份数据,所以服务提供方无法泄露或者贩卖用户数据。然后这套系统需要满足哪些基本条件:

  • 第一,「是可验证,无法造假」这里的无法造假,主要指的是:消息里说本消息是A发出的,则一定是A发出的,不可能是B伪造出来的。这里的无法造假与实人认证没有关系。
  • 第二,「数据去中心存储」,不需要任何一个中心化机构存储信息。这实际是对可用性的保障。
  • 第三,「能有权限控制」用户指定谁能看哪些、能用哪些信息,其他人在非授权情况下不能看、不能使用任何信息。
  • 第四,「授权信息可撤销、可修改」。比如,工信部近几年一直强调的,要求互联网企业必须对用户提供注销机制。但是,目前来看,多数企业仍然基于自身利益考虑,并不愿意对用户提供这样的操作。在去中心身份下,“注销”这个操作,就是简单的撤销对某个服务提供者的身份授权,不需要服务提供者主动操作。
  • 第五,「允许附加元信息」,比如第三方认证数据等等。
  • 第六,「有办法与真实的自然人关联」。比如如何安全、稳定的与个人的指纹、虹膜等信息关联,同时还能确保这些生物信息不可被第三方获取。我们知道目前的指纹、面部识别,基本逻辑是各个服务提供者(比如支付宝、微信等)会采集并存储个人的生物信息,然后验证时,把客户端采集的生物信息与服务提供者中心化服务器存储的信息做比对。

这个过程明显存在一个问题就是:如果你的指纹、面部三维数据泄露了,你总不能换指纹、换脸吧。所以,「在身份领域一个基本原则就是:生物信息可以用,但是不允许看、不允许存、不允许流转。」

目前的绝大多数企业是不去满足这点的(随着硬件安全设备的进步,这一点有改变,比如目前几乎所有手机的指纹器是不提供指纹图像数据的)。

前不久,某AI公司采集的人脸识别数据库就泄露了,而且是三维生物识别信息,简单说就是在某些情况下,用程序就可以直接冒充这些被泄露信息的人的身份的。

比如冒充机构或者组织的核心部门的门禁信息等等,这是个非常恐怖的事情。这也是我说的去中心身份需要满足这个条件的非常重要的原因。

这套系统的基本逻辑架构:

  1. 「去中心网络(或者其它可信环境)保存用户身份及附加信息」:满足私密、授权、高可用,甚至用户与服务者之间无网络也必须可用。如何实现“无网络时仍然可用”,这里先放一下,后续会有解释。
  2. 「多重身份数据」:日常服务提供方不可见身份数据的明文,所有身份需求必须明确,不允许有未知的身份需求和可见明文身份数据的需求。多监管部门多签名机制:可解密得出明文身份的数据,都需要多个监管部门联合签名,且签名得出的明文数据会使用诸如频域水印技术等打上水印,方便跟踪。
  3. 「用户发起一个服务请求时,和服务一起携带自己的身份数据给到服务提供方」。这些数据并非明文,而是一个基本身份ID。服务提供方用这个身份id与该用户拥有的服务做关联。同时,如果有特殊的需求,比如实名认证、合法性认证等等,业务提供方可以带上身份id去与监管方做黑盒比对,监管方只返回类似”合法“/”不合法“、”实名“/”未实名“等业务结果,不允许返回数据明文。
  4. 「以太坊做密钥分发与管理,IPFS负责内容寻址,ENS做人类可读性信息的解析,whisper做安全的数据传输通道。」

主要技术点:

  1. 上面说到的逻辑上的「去监管方验证“等逻辑,实际上所有操作都是在本地进行的」,借助去中心相关逻辑,比如区块链、ipfs等,所有数据都是在本地的。只不过这些数据都是加密过的,不是任何人都能看到明文,这里也是去中心身份的技术体现之一。
  2. 可信计算:区块链,SGX,trustzone。上面提到,「无网络时身份仍然可用」,其实与这里就有很大的关系。

「一个具体的场景:」 用户无网络时,因为某个紧急理由,需要授权第三方能使用自己的的身份信息。此时,传统方案里,基本就只能把一些敏感信息(比如密码等)通过第三方渠道告知需求者,这实际是不现实的。在可信计算环境下,可信计算对于非授权者可以认为是黑盒,只能看到我想让你看到的内容。

回到刚才这个例子,我在本地,通过手机计算出一个加密过的密钥,把这个加密密钥通过第三方渠道(比如人肉口口相传、纸介质等等)传送给请求者。请求者在他本地的黑盒环境中按照事先预定好的逻辑使用密钥并获得授权。

  1. 「各种密钥算法,比如DH、RSA等等」。他们具体解决的是就是信息的非对称使用:「能用、不能看」,这些算法与可信计算环境共同构成一个可信的身份使用逻辑,确保身份数据的非对称使用。而这一点,也是传统身份系统里不能解决的问题:第三方能用你的数据也就能看你的数据,拿走你的数据,这是所有身份相关安全风险的根本原因之一。

技术壁垒:

第一个是软件层面的。目前的「区块链技术只是解决了身份可信、数据可信、行为可信。对于执行环境可信是不满足的」,也就是我一旦需要解密数据,或者对数据做明文操作,运行环境的控制者是可以看到这些数据的。

这就引入第二个壁垒点:「硬件层面的执行环境可信。」 前面说过,硬件层面执行环境的可信主要几个解决方案:intel的SGX技术,arm的trustzone,以及其它第三方的TPM模块,他们各有优缺点。

  • 「对于SGX来说,其黑盒环境资源与外部不可信环境共用较多,攻击面比较大。」 比如各种侧信道攻击,在GitHub上有相应实现。解决方案上,目前intel有发布过一些软件层面的补丁,部分缓解了这个问题,但仍然没有彻底解决。 不过好的一面是,「目前的侧信道攻击所能获得的数据粒度仍然比较大,做不到很精细的程度」。所以如果使用这个方案,需要根据侧信道攻击的原理及产生问题的原因(比如针对特定代码模式的处理),做一些针对性处理。SGX的优点在于,其可以运行多个黑盒环境且各个黑盒环境相互隔离,这一点讲,它的安全性和实用性是最好的。
  • 「ARM的trustzone环境从硬件架构上讲是安全性最好的。」 Trustzone有独立的内存、缓存等资源,部分独立的CPU内部硬件资源,还有独立的操作系统“trustOS”。但是,其只有一个可信环境,不像SGX可以同时运行多个可信环境,这限制了它的应用面。同时,因为需要有trustOS的支持,这通常是由手机厂商提供的,所以trustOS的可用性及功能完备性取决于手机厂商的具体实现,这对于花样翻新的各种应用明显是满足不了这些应用的需求的。
  • 「关于其他第三方的TPM模块」,他们更多被用于标准的密码存储与加解密计算。这里有个问题是,对于TPM模块,在我国目前的环境下,法律对其有合规性要求,所有TPM都必须得到国家密码局的认可,未得认可的TPM模块及其电子产品,在中国销售和使用都是违法的。这个点,它的风险在哪,我就不过多解读了,大家可以私下沟通。

以上说的都是两个方面的技术壁垒,「一是如何解决区块链的可信执行环境问题,二是硬件方式的可信环境,各自仍然不完善,如何与现有软件技术结合的问题。这是整个去中心可信身份的最重要两个技术壁垒。」

可信黑盒

最后,我想针对可信黑盒,举个具体的使用流程,让大家知道如何在可信黑盒环境下,「既使用了数据,又不会让使用者看到数据。」

以征信信息为例,用户A和机构B都使用各自黑盒协商出一个密钥,这个密钥的公钥通过网络传输到对方。密钥算法基于大数分解难题或者椭圆曲线的对数难题,确保公钥无法推导出私钥。产生公私钥过程都在黑盒里执行,任何第三方(包括用户)都无法知道私钥内容。

机构B在拿到用户A的公钥后,在黑盒内推导出一个用于解密的密钥,这个密钥除了黑盒内的程序,任何第三方都无法得知。

机构B从以太坊、IPFS等位置取得加密过的数据,将加密数据输入黑盒环境,黑盒程序利用刚才的密钥解密出数据明文,并根据事先预定好的逻辑(由区块链确保逻辑是公开的、可接受的、未被篡改的,也就是行为可信),根据数据明文得出业务结果并告诉机构B。

这就是一个最简单的可信身份的应用过程。

作者:mccoysc 链接:jianshu.com/p/d0449c0f3 来源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

你可能感兴趣的:(网络,分布式,区块链,安全)