百度安全

百度安全 查看完整档案

北京编辑  |  填写毕业院校百度  |  安全 编辑 anquan.baidu.com 编辑
编辑

百度安全官方内容平台,集合顶级行业论文、技术解读、案例实践等优质内容,如需转载或合作,邮件machang02@baidu.com,秒级回复!

个人动态

百度安全 发布了文章 · 9月21日

红与蓝:现代Webshell检测引擎免杀对抗与实践

上半年Webshell话题很火,业界举办了数场对抗挑战赛,也发布了多篇站在安全产品侧,着重查杀思路的精彩文章,但鲜有看到以蓝军视角为主的paper。

作为多场挑战赛的参赛者及内部红蓝对抗的参与者,笔者试着站在蓝军角度,聊聊现代Webshell对抗的一些思路,也以PHP Webshell为例,分享包括利用PHP自身bug、构造PHP内存马、强制赋值私有变量等一些还没有被提及到但又比较有趣的trick。

希望能对正在参与某些大型攻防对抗演练的你有所收获。

1 轻松绕过传统规则查杀

即便是现在一些主流商业产品,也大量沿用了传统木马特征检测的思路,使用规则或者样本库作为单一查杀手段。
对蓝军来说,这样的安全防护能力无疑是十分单薄和脆弱,通常是不堪一击的。

1.1一个极端的case

先来看一个极端的case
在这里插入图片描述

一个公开的Webshell

这样一个在百度就可以搜索到的webshell,自然会被检出查杀。但只是将其做一个简单变形:
在这里插入图片描述
POST改成GET

将POST改成GET,就能成功绕过该产品。可见即使是很多商业级产品,也只是简单维护了一个样本库而已。

这虽然是一个比较极端的case,但在面对主流的规则查杀产品时,对抗原理也是相通的,只是需要更高强度地编码。

1.2 花括号的妙用

在这里插入图片描述

PHP中,实现了数组索引对于curly brace的支持(7.4之后已标记为deprecated,commit 4416)

这意味着一个数组索引a[0]中的方括号也可以用花括号{0}替代,同时再插入一些圆括号,使原义不变,但正则却匹配不到,便可以成功bypass几乎所有主流规则查杀工具。

更多这类符号可以从词法分析角度挖掘,对于不同的编程语言,其编译器源码或者官方文档中会有对Token的定义。
在这里插入图片描述

PHP Token列表

通过查找Space、Separator、Comment、Other等类别,能发现更多有趣的trick。

除此之外,利用加密、或者异或等数学运算生成的样本,也能达到特征湮灭的目的,传统规则查杀的绕过不是本篇重点,这里不再一一列举。其根本原因是,正则表达式的意义就只是在有限长的字符集中匹配有限长度的字符子集,但PHP等编程语言却是图灵完备的,其在字符层面上的排列会有无穷种组合,所以通过高强度的编码便能达到bypass目的。

正则表达式和图灵完备的编程语言之间天然的矛盾也决定了,无论怎样复杂的规则都无法从字符层面cover住图灵完备的PHP等语言,必然带来绕过的可能。

2 突破现代Webshell查杀引擎

在上半年发起公开挑战赛的数款Webshell检测产品都聪明地摒弃了规则方式,通过静态分析或沙箱执行等手段,尽可能地贴近编程语言的解释和执行,有效地减少了传统绕过的可能。

但同时在参赛时也发现,由于静态分析或沙箱执行本身的缺陷,也带来了新的bypass可能。

2.1静态分析缺陷

静态分析也就是白盒的思路,从语法树角度实现了从sink->source的追溯,其一般的工作路径是这样:
在这里插入图片描述
通过词法分析->语法分析->语义分析实现了对程序语法上的理解。但由于代码没有真正run起来,实际上并不能实现对一段代码完全地理解,尤其是在面对PHP这类较为灵活的脚本,而非静态类型语言时,利用这点缺陷可以发掘出非常多的case。

2.1.1利用php自身的bug

最极端的情况是,利用php解释器或其他php底层的bug,使语法树和实际run起来的代码表达不一致,达到在语法层面合法,但实际运行起来是webshell的目的。

在这里插入图片描述

在这个case中,按照php的语法,并没有任何操作对KaTeX parse error: Expected 'EOF', got '&' at position 27: …了修改(php中引用必须显式=&̲形式)。但在实际运行时由于ph…bar->arr的值实际上被改变,key中会新增system和$_GET[mo]值。

从语法树角度看是回调了两个空值,但实际运行时却是回调了
register_tick_function(‘system’,$_GET[‘mo’]);
成功绕过所有主流的静态分析工具。

不过PHP官方并不将其视为一个bug,官方对此的解释是
在这里插入图片描述

但从PHP对引用的定义来看,必须显式使用=&操作才能获取到引用的返回。如果非要强行解释的话,笔者认为是当执行&get_value(k e y ) 时 实 际 r e t u r n 了 key)时实际return了key)时实际return了this->arr[k e y ] 的 引 用 , 在 传 值 执 行 时 会 在 内 存 新 建 一 个 key]的引用,在传值执行时会在内存新建一个key]的引用,在传值执行时会在内存新建一个this->arr[‘system’]的别名(不是指针,可理解为unix文件系统的硬链接,但指向的值是空)。但无论如何,这都和PHP文档中相关的定义不自洽,所以其更像是一个引用实现上的bug。

2.1.2 利用sink或source点不覆盖

通过流程图能看出,还可以利用白盒不覆盖的sink或source点的进行bypass,在此前的多篇文章中也提到这点,如利用filter_input、getenv等。这里举两个没有提到的case:

在这里插入图片描述

session_set_save_handler这个函数的特殊性在于他的每一个参数都是callable形式,并且read、write、destroy三个函数都会接收s e s s i o n I d 值 , 而 sessionId值,而sessionId值,而sessionId又受到session_id()的控制,通过构造回调,隐式调用了assert($_request)。类似的回调函数在php非常多,静态分析的sink点必须完全覆盖才能达到效果。

同理,source点上也有类似问题:

在这里插入图片描述

虽然关注了php://input形式,但在语法树上这个值仅仅是个字符串,通过简单变形混淆即可bypass。

2.1.3 打断污点传播

在之前的几次比赛中,被选手利用最多的方式恐怕便是打断污点传播了。这也是静态分析最大的问题—打断污点传播的方式五花八门、层出不穷。

如在php中,一个类似php://filter/read=convert.base64-encode/recource=index.php的wrapper/filter是可以自定义的,通过注册一个var协议,便隐去了从fopen到myclass之间语法树上的联系

在这里插入图片描述
成功bypass主流静态分析查杀工具。

还可以利用一些静态分析无法获得的操作系统资源,如内存、CPU、磁盘等动态值
在这里插入图片描述
通过取当前进程开销,由于其中ru_oublock参数常为0,便可以在bypass主流静态分析的同时,又得到一个稳定的webshell。

除此之外,如果静态分析没有适配unset等函数的话,可以通过变量销毁打断污点的传播:
在这里插入图片描述
原因是unset销毁了x 在 c h a n g e 函 数 内 的 引 用 , 其 后 紧 跟 的 x在change函数内的引用,其后紧跟的x在change函数内的引用,其后紧跟的x='q23’只是函数作用域内的局部变量,所以参与回调的x 并 未 发 生 改 变 。 当 静 态 分 析 未 能 正 确 处 理 u n s e t 时 便 会 造 成 x并未发生改变。当静态分析未能正确处理unset时便会造成x并未发生改变。当静态分析未能正确处理unset时便会造成x值的混淆,导致bypass。

2.1.4 强制修改私有变量

还可以利用一些静态分析上常犯的错误,如对private的处理上,理论上被private修饰的私有变量无法从外部访问(OOP语法明确规定),但实际上常见的语言无论是php、java、python等都有特殊的方法突破这一限制,从而实现对private属性的访问,如java的反射。

在php中,除了利用反射机制,还可以通过Closure::bind实现类似的功能
在这里插入图片描述
大概原理是将一个闭包中$this的指向改为其他实例(或者叫绑定),作用域的改变使得外部函数也可以访问到受保护的private、protected属性。从而导致了语法树的不可见,但webshell却能被实际执行。

2.2沙箱执行的弱点

动态沙箱和静态分析在流程上大同小异。主要区别在于,利用污点追踪技术,沙箱实现了对用户输入的追溯,并能真实执行目标代码。同时沙箱还能收集样本的实时行为并打上标签,如命令执行后门(HEUR.WebShell.Exec)、中国菜刀(HEUR.WebShell.Chopper)等,从而能做出更准确的判断。

在这里插入图片描述
显然,沙箱的绕过方法要远远少于静态分析,主要原因还是沙箱真实执行了静态分析中没有分析到位的部分,真正将代码run了起来,使得打断污点传播变得极为困难。

但即使如此,也依然存在绕过可能,除了和静态分析同样对sink和source不覆盖问题,还可以从以下方面考虑。

2.2.1随机行为

在这里插入图片描述
通常沙箱只会运行一次,一但这次执行得不到可疑之处,便不再运行。那么可以引入随机数来达到目的,如上述case中沙箱猜中的几率是1/9,但攻击者却可以无限次尝试来逼近webshell。

2.2.2利用定时/延时绕过

在这里插入图片描述
同样还可以利用时间戳,由于时间是自然增长的,当前时间戳的第7位是1,加上114后为char(115),即字符s。执行的是assers,第一时间也就通过了沙盒检测。但当1000秒后执行时,时间发生了变化,此时执行的是assert。

可以通过控制时间戳的位数来决定webshell的有效时长,也可以直接指定一个时间点如12月15日0点,在此之前上传通过检查,等待到达时间点后再访问执行。

2.2.3文件信息不对称

通常沙箱执行环境与真实文件所处环境通常会不同,比如沙盒通常会重命名文件然后检测,再比如执行路径不同。利用这点导致的信息不对称,也可绕过沙箱检测。

在这里插入图片描述
通过取自身文件名,成功bypass。

3 其他trick

除此之外,跨文件分析、时效性、编程语言版本差异等问题也是常利用的弱点,举两个例子:

3.1 PHP下的内存马、无文件马

Java中通过Instrumentation接口或者注册Bean Controller等方式可以将Webshell代码注入进内存/JVM进程中。但对PHP来说,由于PHP生命周期的关系,很难达到相同的效果。

最简单的便是通过死循环来使代码驻留在内存,最早在乌云中就提到类似思路:
在这里插入图片描述
删除自身后,通过死循环常驻内存,不停生成真实的webshell,达到不死马的效果。
缺点显而易见,真实webshell没有任何伪装,且以文件形式存在,会被检测引擎快速捕获。

我们将其进行改进:
在这里插入图片描述
Require完成后立即删除该文件,使真实webshell存储在内存中,却无文件存在。静态分析/沙盒检测时会查无文件,导致bypass。

3.2 PHP版本差异

不同PHP版本之间往往存在语法和执行上的差异,而沙盒/静态分析工具通常是固定于某个版本,利用这点也会导致bypass,最常见的莫过于利用php的新特性,如:
在这里插入图片描述
PHP7新引入的Null合并运算符,可以简单实现三元运算。

PHP7.4新增的函数类型声明:
在这里插入图片描述
PHP7.4的短闭包写法:
在这里插入图片描述
实现了一个短闭包,并隐式地调用了use($code)。

一旦静态分析/沙盒不支持这类新的语法特性,则依然会导致层出不穷的bypass问题。

3.3 莫名其妙的case

当然也有一些莫名其妙的case,可能由于检测引擎本身的问题,导致失效,比如:
在这里插入图片描述
因为一些不明原因bug,一些引擎带上var_dump函数后,再执行eval就会失效。

同理,echo在某些环境下也可以:
在这里插入图片描述

  1. 结语

我们讨论了蓝军视角下传统和现代webshell查杀的一些缺陷和弱点,但同时也注意:在红蓝对抗中,webshell查杀通常是hids的一部分。作为主机层面的入侵检测工具,hids除了漏报率和误报率要达到条件,能否及时探测web路径、能否云上互相感知同步等基础能力也十分重要,一但某一环节的及时性或有效性跟不上,都有可能带来新的gap点。

最后打个广告:

百度webshell查杀引擎webdir+(https://scanner.baidu.com/
自2014年就一直开放测试中,基于RASP思路很好地解决了静态分析及沙盒执行的弱点,对上述绝大部分免杀的webshell均能够很好地支持,也欢迎各路白帽子挑战尝试。

查看原文

赞 0 收藏 0 评论 0

百度安全 发布了文章 · 9月17日

百度世界大会公开课 | 人工智能的安全威胁:深度学习中的攻防对抗分析

9月15日,“万物智能—百度世界2020”在线上召开。大会联合央视新闻,用线上发布会的形式,面向行业、合作伙伴、广大用户和媒体,发布了百度人工智能全年最新、最前沿的技术、产品、解决方案等成果。其中,在百度飞桨与生态公开课环节,来自百度研究院的资深安全研究员仲震宇带来了《深度学习模型的安全问题与防护》的技术分享。

image

在数据丰沛的时代,计算机可以通过自我学习获得算法,把数据转化为知识。深度学习是当前机器学习技术中最为炙手可热的一种。深度学习的实质,就是通过构建具有很多隐层的机器学习模型和海量的训练数据,来学习更有用的特征,从而最终提升分类或预测的准确性。

通俗地讲,图片识别就是通过抓取数据的核心图像特征,从而辨识数据的类型并将其归类。比如,如果想判断图片中是一辆摩托车,那就只要抓取“有两个轮子”“有踏板”等特征便可以完成判断。过去由于图片识别的精准度不高,这种判断很难由机器完成,深度学习的出现便让这一问题迎刃而解。

近年来,随着深度学习技术的发展和各种模型的不断涌现,基于深度学习的计算机安全应用研究也成为了计算机安全领域里的一个热门研究方向。深度学习模型容易受到对抗样本的恶意攻击,这在业内已不是新鲜事。对图像数据添加人类难以通过感官辨识到的细微扰动,便可“欺骗”模型,指鹿为马,甚至无中生有。为实施此类攻击,攻击者往往需要提取模型结构、参数,继而利用特定算法针对性地生成“对抗样本”,诱导模型做出错误的,甚至攻击者预设的判别结果。

据介绍,在真实的物理世界中,依据这一原理,百度安全研究员已经进行了不少骚气的实验操作:

Blackhat欧洲大会上,我们重现了大卫科波菲尔让自由女神像消失的魔法。通过控制一辆Lexus背后的显示器上显示的画面,我们可以让著名的目标检测模型YOLOv3完全识别不出Lexus。同样的,我们也可以让一个‘停止’的交通标示在目标检测模型里被误认为是一个限速的标示。可以想象由此产生的识别错误会给安全攸关的驾驶场景带来麻烦。

当然,上面所提到的一些实验案例,是基于对深度学习模型高度认知的前提下,我们把这种提前知道模型内部构造,可以利用特定算法来生成“对抗样本”的攻击,叫做“白盒攻击”。然而,对于诸如语音识别、无人驾驶等对安全性有极高要求的行业中,攻击者并不一定能获取这些深度学习模型的模型框架和训练数据等详细内部构造信息,对模型的认知程度不高,这种类型的攻击就被称为“黑盒攻击”。显然,相较而言,“黑盒攻击”的难度更大,所以 AI 开发者们最好保护好自家的 AI 模型,避免让攻击者知道其内部构造。

然而,只是保护好自己的模型构造就足够了吗?百度安全研究员最近研究发现 —— 黑盒模型也未必更加安全。

我们发现许多实际分类应用的模型往往都是基于一些预训练模型。而这些预训练模型都是公开的。当攻击者把攻击目标从黑盒模型转移到它的父模型后(当中我们用了一个指纹攻击的技术完成对父模型的匹配),攻击难度就相对的降低。而成功攻击父模型后生成的对抗样本,同样可以利用攻击迁移性的特点有效地对黑盒模型实施打击。

公开课的最后,百度安全研究员介绍了百度安全针对对抗样本的解决思路,以及通过对抗训练强化模型来提高深度学习模型鲁棒性的途径。百度安全针对人工智能算法安全性的研究,包括深度学习模型鲁棒性测试、形式化验证、机器识别恶意样本实时监测、黑白盒攻防等领域。

在深度学习对抗上,我们在Github开源了AdvBox,Perceptron Benchmark工具。其中Perceptron Benchmark为深度学习模型的鲁棒性评估提供了标准的评测方法,同时也为模型鲁棒性的提升提供了有效的标准数据集。AdvBox集成了业界深度学习对抗的算法。此项技术已在Github完成开源,并登上了Black Hat、DEFCON等国际工业界会议,受到全球安全行业的关注和认可。同时,Advbox也已应用于百度深度学习开源平台PaddlePaddle及当下主流深度学习平台,可高效地使用最新的生成方法构造对抗样本数据集用于对抗样本的特征统计、攻击全新的AI应用,加固业务AI模型,为模型安全性研究和应用提供重要的支持。

我们希望能够通过百度安全的技术与服务,让更多人享受到科技带来的便利,让更多企业获得更加安全的 AI 解决方案。

点击链接,调整至1小时43分,查看完整课程视频
https://haokan.baidu.com/v?vi...

查看原文

赞 0 收藏 0 评论 0

百度安全 发布了文章 · 8月5日

百度安全研究院:区块链智能合约介绍

摘要

智能合约 (smart contract) 是一种由事件驱动的、具有状态的代码合约和算法合同 [11],随着以比特币为代表的区块链技术的蓬勃发展, 区块链技术已经开始逐步超越可编程货币时代而进入智能合约时代。智能合约作为区块链的核心部分,在技术中得到广泛应用,也是令区块链成为具有一定颠覆性技术的原因之一。本文通过对智能合约的背景知识以及流程介绍,总结出当前智能合约的特点和应用领域,从而为区块链智能合约技术的发展提供一定参考。

1 引言

区块链利用分布式节点共识算法对数据进行生成和更新,使用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算范式 [10],本身具有去中心化的特性。

区块链的发展主要分为三大阶段 [6],第一阶段为以比特币为首的可编程货币,第二阶段为以智能合约为首的可编程金融,第三阶段为以去中心化应用为首的可编程社会。比特币发展迅速,区块链发展阶段逐渐向第二阶段过渡,以以太坊为首的智能合约技术得到了广泛关注。

1995 年,由密码学家 Szabo 提出智能合约这一概念,由于当时缺少可信的执行环境,智能合约并没有被应用到实际产业中。比特币诞生后,由于比特币的底层技术区块链具有去中心化的特性,满足智能合约所需的可信的执行环境,区块链可以提供参与的各个节点的互信。

智能合约是一种计算机协议,在协议制定和部署后,不需要外加人为干预,即可实现自我执行和自我验证 [4]。从技术角度来说,智能合约可以被看作一种计算机程序,这种程序可以自主地执行全部或部分和合约相关的操作,并产生相应的可以被验证的证据,来说明执行合约操作的有效性。在部署智能合约之前,与合约相关的所有条款的逻辑流程就已经被制定好了。智能合约通常具有一个用户接口,以供用户与已制定的合约进行交互,这些交互行为都严格遵守此前制定的逻辑。得益于密码学技术,这些交互行为能够被严格地验证,以确保合约能够按照此前制定的规则顺利执行,从而防止出现违约行为。

image.png

表 1: 传统合约和智能合约的比较

智能合约是在传统合约基础上对安全性、唯一性进行改进的一种合约,用数字形式定义的承诺来保障合约参与者的协议安全可靠。

区块链的智能合约最早建立在以太坊,用一段代码来实现条款在处理硬件和软件中的应用,这段代码运行在以太坊的虚拟机中,按照特定程序执行操作,在相应的时间节点完成条款内容。

以太坊是一个开源的具有智能合约功能的公共区块链平台,以太坊项目借鉴了比特币区块链的技术,对它的应用范围进行了扩展。如果说比特币是利用区块链技术的专用计算器,那么以太坊就是利用区块链技术的通用计算机。简单地讲,以太坊 = 区块链 + 智能合约。

与比特币相比,以太坊最大的不同点是:它可以支持更加强大的脚本语言,即使用一套图灵完备的脚本语言来建立应用,允许开发者在上面开发任意应用,实现任意智能合约,这也是以太坊的最强大之处。作为平台,以太坊可以类比于苹果的应用商店,任何开发者都可以在上面开发应用,并出售给用户。

2 智能合约类型

智能合约分为广义智能合约和狭义智能合约。广义的智能合约是指运行在区块链上的计算机程序,适用范围较广。狭义的智能合约是运行在区块链基础架构上,基于约定规则,由事件驱动、具有状态、能够保存账本上资产,利用程序代码来封装和验证复杂交易行为,实现信息交换、价值转移和资产管理,可自动执行的计算机程序 [9]。

2.1 脚本型智能合约

将比特币中的智能合约称为脚本型智能合约。由于比特币中的脚本仅包含指令和数据两部分,其中涉及到的脚本指令只需要完成有限的交易逻辑,不需要复杂的循环、条件判断和跳转操作,功能有限但编写较为容易,支持的指令不到 200 条。

2.2 图灵完备型智能合约

将主要运行在以太坊和超级账本中的智能合约称为图灵完备型智能合约。脚本语言被设计成为仅在有限范围内执行有限功能的简单执行语言,是非图灵完备的语言。使用脚本语言编写的交易指令虽然能够满足比特币应用,但无法适应以太坊平台的开发需求。目前,以太坊主要使用 Solidity和 Serpent 两种智能合约开发语言。

2.3 可验证合约型智能合约

将正在研发中的 kadena 项目中的智能合约称为可验证合约型智能合约。可验证语言的语法类似于 Lisp 语言,用于编写运行在区块链 Kadena 上的智能合约,可实现合约的数据存储和授权验证等功能。为防止在复杂合约的编程过程中可能存在的安全漏洞以及因此而带来的风险,可验证合约型语言采用非图灵完备设计,不支持循环和递归。该语言编写的智能合约代码可以直接嵌入在区块链上运行,不需要事先编译成为运行在特定环境(如以太坊 EVM)的机器代码。

3 智能合约语言

3.1 Solidity

Solidity 可以用来开发合约并编译成以太坊虚拟机字节代码,运行在 Etheream 虚拟机(EVM)之上。是静态类型语言,支持继承、库和复杂的用户定义类型等特性。虽然 Solidity 语法与 Javascript 较为接近,是一种面向对象的语言,但是两者又有许多不同:

  1. 由于语言内嵌框架是支持支付的,所以可以提供如 payable 之类的关键词,实现在语言层面直接支持支付,更为简便;
  2. 由于以太坊底层是基于账户而非 UTXO,故存在特殊类型 Address,可以用于定位用户和合约,并定位合约的代码;
  3. 由于智能合约是将原来的一个简单函数调用变成了网络节点中的代码执行,故在去中心化的网络运行环境中,会更加强调合约或函数执行的调用方式;
  4. 由于为了保证合约执行的原子性,以避免中间状态出现的数据不一致,Solidity 的异常机制一旦出现异常,所有执行都会被回撤。

常用的 Solidity 集成有 Remix、Visual studio Extension 等。以编译器 Remix 为例,Remix 是基于浏览器的

IDE,集成了编译器和 Solidity 运行时的环境,不需要额外的服务端组件。这里用 Solidity 开发“Hello World”。可以看到,在 decoded output 中返回_HelloW_ orld ! 。

3.2 Serpent

Serpent 和 Python 类似,使用用 LLL 编译,最终会被编译为 EVM 字节码。可以用于开发合约编译成以太坊虚拟机字节代码。Serpent 是一种分组加密算法,更加简洁,将低级语言在效率方面的优点和编程风格的操作简易相结合,同时合约编程增加了独特的领域特定功能。

3.3 Lisp Like Language

Lisp Like Language(LLL) 是和 Assembly 类似的低级语言。更为简单,本质上只是直接对以太坊虚拟机的一点包装。是一门 Lisp 风格的底层编程语言,持续更新,并且与 Solidity 同属一个资源库。

4 智能合约运行机制

以以太坊开发平台为例,智能合约运行机制主要包含及下阶段:

  1. 生成代码:智能合约一般具有值和状态两个属性,代码中用 If-Then 和 What-If 语句预置了合约条款的相应触发场景和响应规则,在合约各方面内容都达成一致的基础上,评估确定该合同是否可以通过智能合约实现,即“可编程”,然后由程序员利用合适的开发语言将以自然语言描述的合同内容翻译为成为可执行的机器语言;
  2. 编译:利用开发语言编写的智能合约代码一般不能直接在区块链上运行,而需要在特定的环境(以太坊为 EVM, 超级账本为 Docker 容器)中执行,所以在将合约文件上传到区块链之前需要利用编译器对原代码进行编译,生成符合环境运行要求的字节码。;
  3. 提交:智能合约的提交和调用是通过“交易”完成,当用户以交易形式发起提交合约文件后,通过 P2P 网络进行全网广播,各节点在进行验证后存储在区块中;
  4. 确认:被验证后的有效交易被打包进新区块,通过共识机制达成一致后,新区块添加到区块链的主链。根据交易生成智能合约的账户地址,之后可以利用该账户地址通过发起交易来调用合约,节点对经验证有效的交易进行处理,被调用的合约在环境中执行。

5 智能合约项目

最简单的合约是:信息上传区块链——双方签字确认——双方达成共识——合约被存储。

image.png

图 2: 合约运行机制

image.png

图 3: 合约基本模型

Language Language 是一种安全稳定的分布式语言,符合 Szabo 对智能合约设计理念的特点,所有的远程通信会被加密。

Hawk Hawk 是一种去中心化的智能合约系统,是一个用智能合约构建隐私保护的框架 [2],在这个系统中不会以明确的方式将金融交易存储在区块链中,Hawk 编译器负责将程序编译为区块链和用户之间的加密协议。

OpenBazzar OpenBazzar 平台是一家利用比特币进行交易的去中心化电商平台,是一个开源平台,直接将用户与用户连接开展交易,实现点对点交易网络,买卖双方可以直接进行交易,不需要借助中心化平台,保证了隐私。

Ethereum Ethereum 是具有图灵完备编程语言的区块链平台,包含了公有链和私有链,可以创建任何应用。使用共识机制中的 PoW 机制,拥有更高的处理速度和精度,可以在没有处理所有交易的情况下验证应用状态,目标成

为分布式应用平台的脊梁。但区块的构造时间受到交易处理速度的影响,建块速度受到很大影响。

Codius Codius 是由 Ripple 实验室发布的智能协议,具有去中心化、安全性高等特点,可以实现点对点交易网络, 是一种开源平台,应用于 Ripple 平台上,实现的功能是引导货币流通。

Hyperledger Hyperledger 是一种 Linux 基金会下的区块链开源平台,以容器的形式运行智能合约,具有较高安全性。

6 智能合约基本特点

6.1 优势

可信性 智能合约的承诺包含两方面,一是自动,无需信任和公正地执行合约;二是直接,在合约执行的各个环节中取消中间人这一角色 [5]。智能合约的所有条款和执行过程是提前制定好的,并由计算机绝对执行。因此所有执行的结果都是准确无误的,不会出现不可预料的结果。

交易无需第三方 智能合约不需要中心化的权威来仲裁合约是否按规定执行,合约的监督和仲裁都由计算机来完成 [1]。在一个区块链网络中一般不存在一个绝对的权威来监督合约的执行,而是由共识机制来判断合约是否按规定执行,监督方式通常由 PoW 或 PoS 技术实现。由于智能合约的数字化特点,数据被存储在区块链中,使用加密代码强制执行协议,保证交易可追踪和不可逆转。

高效的实时更新 由于智能合约的执行不需要人为的第三方权威或中心化代理服务的参与,其能够在任何时候响应用户的请求,大大提升了交易进行的效率。用户只需通过网络对业务进行办理,节省了人力、物力。

更低成本 智能合约具有去人为干预的特点,其能够大大减少合约履行、裁决和强制执行所产生的人力成本,要求合约制定人能够将合约的各个细节在合约建立之初就确定下来。

6.2 目前存在的问题

不可撤销性 智能合约自动履行合约内容,但在现实生活中,合同可能会因为一些不可抗力、违法等原因解除。合同法中,对于合同的要求是避免律师预测和协商可能出现结果的灵活性。但由于区块链的不可修改性,智能合约一旦触发就会自动履行,不可撤销,具有一定的僵化特性。

法律效力 智能合约的起草需要通过第三方计算机程序员,而在合约出现问题时若判定是第三方计算机程序员的责任,那么对于错误的算法应该如何追究责任。在法律管辖权问题上,智能合约作为一种新兴合约方式,哪些法院可以受理诉讼、现有的法律条款应该如何修改等问题都是亟待解决的。

安全漏洞 智能合约的漏洞分为交易顺序依赖漏洞、时间戳依赖漏洞、处理异常漏洞和可重入缺陷漏洞 [3],依赖性漏洞是由于智能合约的执行正确与否与以太坊的状态有关,而有效的交易可能会影响以太坊的状态。当一个新的区块含有两笔交易时,交易的先后顺序可能会引起以太坊的最终状态不同,而交易的顺序取决于矿工,从而导致智能合约的执行依赖于矿工的操作 [8]。时间戳依赖漏洞是由于某些智能合约是根据区块中的时间戳所执行的,而时间戳是由矿工根据自身的时间所设置的,若时间被攻击者所修改,可能会导致产生一定风险。在不同的智能合约相互调用时可能出现处理异常漏洞,若被调用的合约产生错误返回值却没有被正确验证时,可能会遭受到攻击。若一个函数在执行完成前被调用了数次,导致发生意料不到的行为时,可重入漏洞就可能出现,可重入缺陷漏洞是指攻击者可以利用调用了智能合约而状态未改变的中间状态对合约进行反复的调用。

7 智能合约应用场景

7.1 法律方面

在法律层面,区块链智能合约可以被看作为智能合同 [10],即运用区块链技术来实现法律合同,将书面化的法律语言转化为可被自动化执行的技术。

以数字版权保护为例,类似于自由文化影响下的知识共享协议的开放式版权协议不断出现,如何保证版权的实用行为,是数字版权保护的核心问题。由于传统的版权保护具有时间、空间的限制,在版权登记、监管机制等方面容易受到影响,而数字版权保护的出现极大改善了这一问题,更好适应了数字资产形式变化多样、易传播的特点。

在版权登记方面,利用区块链技术原理中计算值的唯一性和不可篡改性,对不同的作品生成不同的计算值,将计算值视为作品的一种代表方式进行关联,可以减少作品追溯和存储的成本,简化作品查询流程。

在署名方式方面,使用数字身份对计算值对应的作品进行署名,使用加密技术对数字作品进行保护,保障作品不会被篡改。

根据合约代码和自然语言的比例,智能合约有以下几种表现形式:1、完全以代码形式编写的合约;2、以代码和自然语言两种形式书写的合约。如果法律认为无论是以自然语言书写还是以计算机语言编写,都视为合同的书面形式, 法律效力是相同的,那么两种语言编写的合约构成了完整的合同。

智能合同可能面临的问题有,第 2 种合同是以两种语言表现的,如果这两个版本合约内容上有冲突,以哪一个版本为准,无论是以自然语言版本为准还是以代码语言为准,都需要法律进一步明确并给出司法解释。

7.2 金融方面

在金融层面,因为智能合约可以在区块链中运作,从而充当很多角色。智能合约可以作为经济参与者,接受信息、存储信息,消除人工参与,降低成本,保证合约交易的高效。

以物联网为例,当前社会物联网包括数十亿个通过互联网共享数据的节点,通过物联网、区块链以及智能合约技术的融合应用,物联网支持的物理设备或财产,如公寓、汽车、停车场、自行车等,都可以允许人们在没有中间商的情况下出租、出售或共享 [7]。

当前租房市场在押金方面存在很多争议,一些不良房东在收到押金后就卷钱跑路。将智能合约引入到租房押金中, 在所有者设定出租房屋的金额后,用户通过交易向区块链支付押金,从而触发许可,获得房屋的智能锁权限。与此同时,押金被锁定在区块链中,直到用户决定向区块链发送另一个交易来返回虚拟密钥(如支付租金),智能合约自动执行,在扣除押金中的租金后将剩余金额发送给所有者,交易完成。这一过程将缩减不必要的时间,只需要通过手机进行操作,提高效率的同时降低风险。

但智能合约可能会带来新的金融犯罪行为和风险,例如机密信息泄漏、加密密钥被盗等犯罪行为,而当前的法院和监管机构暂时很难跟上这一技术的发展步伐,由于智能合约具有一定的复杂性,在一些消费者眼里是难以理解的, 这也是智能合约实施中需要解决的问题之一。

image.png

图 4: 子系统节点部署

7.3公益慈善

在公益慈善层面,当前面临的最大问题是资金流向不透明,导致很多人并不会使用众筹平台来进行慈善捐款。众筹是一种通过互联网方式发布筹款项目并筹集资金的方式,众筹更为开放,具有门槛低、依靠大众力量等特点。如何

解决资金信息公开透明,加强监管和监督,成为当前公益慈善的热点讨论之一。

区块链是遗传使用密码学方法产生关联的数据块,每一个数据块中都还喊了一定时间的交易信息,每个数据块都包含上一个块的哈希值,以用于验证其信息的有效性 [12]。智能合约可以通过代码合约实现对众筹系统价值流的控制, 将众筹业务流转换为智能合约代码。区块链的不可更改和共识机制保证了数据的真实和可靠性,可以提高众筹平台的公信力。

众筹区块链总体设计包含双数据系统、双私有链设计、高速与信誉机制、智能合约设计、审计与监督设计、可扩展链式设计。

由于区块链的分布式存储架构,可以在不同用户处放置不同权限的节点,让不同用户参与到管理中,对于发布的消息实现可追踪和不可修改。通过不断互联,使区块链形成互联链、链中链,按照统一标准进行管理监管,解决慈善公益的监管和监督问题。

参考文献

[1] Bartoletti, M., and Zunino, R. Bitml: A calculus for bitcoin smart contracts. pp. 83–100.

[2] Kosba, A., Miller, A., Shi, E., Wen, Z., and Papamanthou, C. Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. pp.839–858.

[3] Luu, L., Chu, D.-H., Olickel, H., Saxena, P., and Hobor, A. Making smart contracts smarter. pp. 254–269.

[4] Mourouzis, T., and Tandon, J. Introduction to decentralization and smart contracts, 03 2019.

[5] Pfitzmann, B., Schunter, M., and Waidner, M. Optimal efficiency of optimistic contract signing.

[6] V.Buterin. A next-generation smart contract and decentralized application platform. white paper (2014).

[7] 刘德林. 区块链智能合约技术在金融领域的研发应用现状、问题及建议. 海南金融 _000_, 10 (2016), 27–31.

[8] 张杰. 区块链安全综述. 西安文理学院学报 (_自然科学版_) (2020), 42–55.

[9] 王群, 李馥娟, 王振力, 梁广俊, and 徐杰. 区块链原理及关键技术. 计算机科学与探索, 1–24.

[10] 贺小苗. 区块链技术的应用: 智能合约及法律问题前瞻. 现代商业 _000_, 16 (2018), 153–154.

[11] 贺海武, 延安, and 陈泽华. 基于区块链的智能合约技术与应用综述. 计算机研究与发展 _55_, 11 (2018), 112–126.

[12] 黄洁华, 高灵超, and 许玉壮. 众筹区块链上的智能合约设计. 信息安全研究 (2017).

查看原文

赞 3 收藏 1 评论 0

百度安全 发布了文章 · 7月28日

百度安全论文入选IEEE TIFS,攻击者难逃“楚门的世界”

导读:近日百度安全发表的论文《Detecting Hardware-assisted Virtualization with Inconspicuous Features》入选国际TOP期刊IEEE TIFS,论文深度剖析了虚拟化检测技术,并创新性提出一种最新硬件虚拟化检测技术,无须提权就能实现对硬件虚拟化环境的检测,本文将对这篇论文进行详细的解读。

虚拟化作为云计算系统中的一种基础技术,近年来,虚拟化技术不仅广泛应用于云服务器,也广泛应用于个人桌面。那么究竟虚拟化技术是什么,又为什么起到这么重要的作用呢?

想象两个场景:

空旷的厂房,整个楼层没有固定的墙壁,从事各式工种的工人和机器设备扎堆聚集,无法形成流水化的高效作业。

开放的冷藏库里,面包、龙虾和榴莲裸露的存储在一起,没有任何封装和隔离,长久下去面包有了龙虾味儿,龙虾有了榴莲味。

从这两个例子里,我们不难看出,在空间资源一定的条件下,需要根据不同的需求进行重新规划,已充分发挥最大的利用效率。在计算机领域,就存在一种技术可以解决上面的问题,那就是"虚拟化技术"。

虚拟化(Virtualization)技术最早出现在 20 世纪 60 年代的 IBM 大型机系统,在 70 年代的System 370 系列中逐渐流行起来,这些机器通过一种叫虚拟机监控器(Virtual Machine Monitor,VMM)的程序在物理硬件之上生成许多可以运行独立操作系统软件的虚拟机(Virtual Machine),再通俗点就是“把一台电脑虚拟成N台电脑”。

同样的,虚拟化在云计算的应用也是如此,云计算本身就是把一个巨大无比的服务资源划分成很多小空间来使用,所以这也就解释了,为什么虚拟化是云计算最基础的软件设施。

虚拟化环境下的恶意程序分析

在计算机安全方面,虚拟化技术也有很广泛的应用,比如安全人员能够利用虚拟化环境进行安全分析测试。虚拟化技术的出现弥补了安全动态分析测试服务器资源不足,系统不纯净以及环境搭建周期长等问题,同时又不会“中伤”到本地操作系统,起到隔离作用,还能够严格控制运行在其中的程序行为,可谓一举多得。

有了虚拟化技术,安全人员便能够在一个孤立的环境中进行不同类型的安全动态分析。通常可以在虚拟环境中运行样本, 利用监控模块提取样本的进程、内存、文件、注册表、网络等行为数据, 通过对这些行为数据的汇总分析来推断样本的功能和恶意性。

这种测试听起来合乎常理,没有什么大问题,然而有没有可能上演这样的一幕:

在电影《楚门的世界》里,楚门从一出生,他的生活就被全球24小时直播,身边所有的人都是演员,生活的城市就是一个巨大的摄影棚,连太阳月亮甚至大海都是人造机器所操控的。

但是,“人造的世界”开始出现异常,莫名其妙天上掉下个录影棚灯,去世的父亲变成乞丐重新回来,初恋女友莫名其妙消失不见……

随着越来越多的异常出现,楚门开始主动检测那个世界的异常,并且证明这就是一个“虚拟化环境”,最终躲开镜头,扬帆出海,获得自由···

没错,恶意程序的作者也和楚门一样,意识到了虚拟化环境中的异常,为了有效地逃避虚拟化分析测试、攻击本地系统,他们掌握一种可以反虚拟化环境的技术,利用这项技术可以检测虚拟运行环境的存在,并隐藏他们的恶意行为,从而逃避安全研究员的分析。

也就是说,安全人员在虚拟化环境下分析恶意程序时,按照我们前面介绍的虚拟化技术原理下,恶意程序就会以为自己在一台“真的机器”里。

但现在存在一些检测方法,可以让软件识破自己其实是在虚拟机里,拥有了“上帝视角”的恶意程序,有的“装傻卖乖”不再搞破坏,企图混过安全人员的分析,又或者是直接选择自毁,总之不管采用哪种办法,最终目的只有一个,就是“让安全研究员没办法研究我”恶意程序如是说。

因此,为了对抗恶意程序的反虚拟化问题,需要安全研究人员掌握更高效便捷的虚拟化环境检测技术,从而构建起更难以被检测,更透明的分析系统,在本篇论文中百度安全研究员就对此做出了深入探索,并研究出了最新硬件虚拟化检测技术,能够无须提权就能实现对硬件虚拟化环境的检测。

传统硬件辅助虚拟化检测技术存在缺陷

首先,我们先来看看,目前恶意程序使用了哪些虚拟化检测方法。总结来说,他们广泛使用了两种虚拟化检测方法。第一种方法是查找虚拟机监视器或虚拟机本身留下的特定痕迹。另一种则是对硬件引起的计时差异进行分析,以用来标记。

然而第一种方法存在很大的局限性,这种方法的原理主要依靠查找虚拟机监视器或虚拟机本身留下的特定痕迹,通常仅用于识别传统的基于软件的虚拟化。为了给用户操作虚拟机提供方便,一些虚拟机监视器将主机插入Guest OS中,但这些痕迹可以轻易被恶意软件发现。常见的痕迹包括,Guest OS中运行的进行和服务、文件或注册表键值等,像CryptoWall、shi和Kronos这样流行的恶意软件都能够通过利用这些痕迹来检测虚拟化的存在。

而目前,随着X86处理器性能的提高和应用的普及,市面上主流的虚拟化更多依托的是硬件辅助虚拟化,论文中百度安全研究员重点对已知的硬件辅助虚拟化检测技术做了实验分析,结果可见表一。       

表一:硬件辅助虚拟化检测技术效果对比

从表1可见,目前已知的硬件辅助虚拟化检测技术均存在可被移除、需要特权账户或触发大量可疑的VM退出事件等缺陷。针对这些问题,百度安全研究员推出了全新的虚拟化硬件检测技术,能够实现在非特权状态下,不引发大量可疑事件,极具隐藏性的全新检测技术。

百度安全首创新型硬件辅助虚拟化检测技术

那么,究竟百度安全所提出的新型硬件辅助虚拟化检测技术是如何实现的呢?接下来,我们就一起跟随论文中的阐述具体来看。

整个工作分为两个阶段:(1)offline阶段和(2)online阶段(例如图1)。Offline阶段主要是采集特征属性在虚拟化环境(virtualized)和非虚拟化环境(native)的不同。这些数据可以保存起来,用于online阶段的检测。在online检测阶段,针对不同属性的划分,可以很容易的判断当前运行环境是否跑在了虚拟化缓解。

图一: 虚拟化检测的两个阶段

为了验证方法的有效性,百度安全研究员进行了实验研究,通过三台本地机器验证三种检测技术以及三家主流云供应商,结果详见表二。

表二:每个主流云提供程序上的三个本地机器和三个虚拟机的系统配置

接下来,我们将采用三个特征属性来给大家展示如何检测虚拟化环境。

1、利用TLB的延迟来检测

为了最大程度地减少两层的内存占用地址转换,现代处理器在虚拟环境中有两种类型的TLB,即hPT-TLB和组合的TLB。如图2所示,hPT-TLB用于将地址从GPA加速到HPA。组合式TLB存储GVA之间的映射和HPA,类似于本机环境中的TLB,并且缓存从VA到PA的地址转换。

直观地讲,一种可能的方法是测量内存访问(仅导致TLB丢失)并确定阈值,虚拟化可以在阈值之上被检测到。阈值可以通过比较确定本机和虚拟系统上的时间延迟。如果延迟被测得高于阈值,然后人们认为环境是虚拟的;否则它是本地的。但是,这种方法存在着误差,即内存访问所花费的时间因每个微体系结构而异。

因此,很难确定合理的绝对阈值。相反,我们使用导致TLB的miss和hit直接的差值来确定这个相对阈值。我们还因此设计了一个Prime+probe的算法完成此事(详细算法参见发表的论文https://ieeexplore.ieee.org/abstract/document/9122497/)。

图二:TLB的在地址转化过程中的流程

图三:在Amazon EC2,Microsoft Azure以及Google Cloud上面的检测结果。我们很容易看到虚拟化和本地系统在TLB miss方面的巨大差异

2、利用LLC Miss Penalty来判断

在现代操作系统中,访问GVA时硬件会走页面表进行地址转换。对于每个Guest页表遍历,硬件也遍历host页表确定相应的HPA。为方便访问,不仅相关的地址转换将被缓存到TLB中,而且访问的四级页表条目(PTE)将存储到CPU缓存中。如图2所示,虚拟化环境将使用缓存以总共存储16个主机PTE和4个Guest PTE,而本机环境仅需要4个PTE。如果再次发生相同的访问,将首先查找TLB。如果发生TLB缺失(即没有TLB条目均不包含地址翻译层),则将进行页表遍历。由于最近的PTE在CPU cache中,因此硬件将查找cache以检查其存在。如果不是在cache中,然后硬件从主设备获取它们内存。在这种情况下,两页的页表清晰可见与在本机环境。类似于基于TLB的测量,我们使用导致TLB和PTE引起的访问延迟

LLC  miss减去hit的等待时间,并把结果存储作为阈值。如果其他减去结果明显超出阈值,那么可以得出结论,环境是虚拟化。

图四:在Amazon EC2,Microsoft Azure以及Google Cloud上面的检测结果。我们很容易看到虚拟化和本地系统在LLC miss方面的巨大差异

3、利用L1D缓存的不稳定性进行检测

在本机环境中,进程调度允许进程竞争一个物理CPU。 在虚拟化在环境中,CPU虚拟化允许物理CPU在多个虚拟CPU之间共享。 它允许多个在一台计算机上运行的不同操作系统。 在同时,不仅进程竞争虚拟CPU,而且虚拟CPU竞争共享的物理CPU,从而加剧了竞争,导致L1D缓存的不稳定性加剧。 此外,虚拟CPU是通常会迁移到不同的物理核心以优化负载平衡。 考虑到L1D缓存是物理设备专用的CPU,并且L1D缓存的大小非常有限,攻击者可以预计多少个entry被evict出L1D。这个数字在有虚拟化的环境下,将会大大提高。

图五:在Amazon EC2,Microsoft Azure以及Google Cloud上面的检测结果。我们很容易看到虚拟化和本地系统在L1D 不稳定性方面的巨大差异。

总结来说,实验结果充分验证了三种方法的有效性,我们所提出的检测技术不会触发任何可疑系统,并独立于操作系统。这一技术研究并不单单只是为了缓解恶意程序对于虚拟化环境的检测,而是致力于在深入研究相关检测技术的基础之上,有针对性的防范恶意程序入侵对虚拟化安全的威胁,为制定合理有效的对抗思路提供未来方向,甚至是让虚拟化环境变得更加“真实”,对于这一领域的前沿研究的推动和发展具有积极的指导作用。

针对以上的情况,云厂商可以做以下的一些缓解方案:(1)采用performance counter进行监控,发现异常的TLB,L1D以及LLC的活动,进行及时报警。但是这个方法噪音很大,具有很高的误报率。(2)进行二进制代码扫描,寻找可疑的代码片段。最后云厂商还可以采用定制机器的方式,对机器的TLB以及cache进行深度改造,从根本上消除这些方面的影响。

此次论文入选IEEE TIFS,再次展现了百度在前沿安全研究的技术沉淀和国际水准。截止2020年上半年,百度安全已经有14篇论文发表在包括Usenix、ASPLOS,、IEEE TDSC,、IEEE TIFS、 MICRO、ICSE等在内的国际顶级会议和期刊。未来,百度安全也将继续深度投入智能安全、云安全、工业互联网、车联网安全各个细分领域的前瞻性安全研究,产研结合推动技术创新,用实打实的“成绩单”起舞于国际安全舞台。

查看原文

赞 0 收藏 0 评论 0

百度安全 发布了文章 · 7月17日

DevSecOps在百度的实践

本文将从传统 SDL 开始,介绍百度从 SDL 到DevSecOps的演进历程。全文涉及 SDL 的痛点、DevSecOps 建设初衷、实践形式、落地思路,以及落地后的效果与收益,也会介绍DevSecOps在云原生时代的探索思路与落地场景。如果你正准备或者已经参与到企业DevSecOps建设的相关工作中,这篇文章或许能够给你的工作带来一些启发。

一、轻量级SDL,百度的前DevSecOps时代

作为一家大型互联网公司,百度具备着所有大型公司和互联网公司的典型特点,业务体系繁多、业务数量庞大,业务迭代迅速。

在百度内部,业务研发模式有别于传统的SDLC模型,更接近于DevOps 模式,CI/CD工具集成和自动化程度高,产品迭代频次多、周期短。

面对这样的业务研发场景,传统通过输出人力到业务团队,全流程跟进和解决业务研发生命周期的安全问题的方式已经不再适合。安全团队不能,也不可能将人力覆盖到所有业务。因此,安全团队势必需要构建通用性的产品安全基础设施,将其嵌入到产品研发流程中,然后配合重点业务的小范围安全评估,来实现高可用、高自动化的软件研发生命周期安全保障。

在百度,我们将这种方式称之为轻量级 SDL,即通过少量的人力投入,以高自动化、高 CI/CD 集成的方式解决业务产品的安全问题。在轻量级 SDL 建设初期,我们根据实际业务场景,构建了百度的自动化漏洞检测系统,并将其嵌入到业务测试上线流程中,具体图示如下:

通过轻量级 SDL 建设,我们以不足 10 人的团队规模,支撑百度 80% 以上业务的上线前安全检查,并在过去的几年时间,保证百度线上业务安全问题数量每年降低30% 以上。

当然,上图中描述的轻量级 SDL架构也存在一些问题和痛点。

虽然通过在测试上线阶段嵌入了自动化安全测试流程,能够帮助业务在上线之前提前发现安全问题,降低安全风险。但是由于业务团队相对缺少安全意识和视野,经常误认为保障业务安全只是安全团队的工作,认为自动化安全测试是安全团队给业务团队增加的额外负担。在这种情况下,业务团队在面对自动化安全测试流程检查出的问题时,也常常是 case by case 的解决,并没有深层次的解决安全意识和安全编码相关的问题。

对此,我们整理了轻量级 SDL 初期建设完成后亟待解决的一些问题,并决心解决:

  1. 自动化安全工具很难覆盖到产品的需求设计阶段。
  2. 安全只覆盖了产品研发的编码和测试阶段,并没有实现全链条覆盖。
  3. 绝大多数产品的安全措施集中在测试阶段,流程滞后、修复成本高、效率低。
  4. 仅通过自动化安全工具的嵌入,很难与业务团队建立安全协同机制。
  5. 非常规型安全漏洞,很难在测试阶段进行自动化发现和收敛。

二、构建DevSecOps的初衷

针对上述问题,我们期望对轻量级 SDL 架构进一步完善,建设一个产品研发全流程覆盖、高自动化集成、强调安全与业务协同的业务安全保障框架。

我们期望通过产品研发全流程的安全措施建设,持续提升业务团队相关人员的安全意识、安全编码习惯以及对安全场景的理解,让业务在产品研发的各个阶段都能实现高效、安全、可靠的交付,将安全漏洞和缺陷消灭在问题的根源。

这些都与 DevSecOps 的理念不谋而合,所以我们决定在轻量级 SDL 的基础上,构建百度的 DevSecOps。

三、百度DevSecOps实践

我们在建设DevSecOps时,主要侧重以下方面:

  1. 打造高自动化的产品安全工具链: 利用产品安全工具在产品研发的各个阶段进行自动化漏洞挖掘,快速发现漏洞的同时确保不会降低研发效率
  2. 在全公司范围内的落地:设计普适性的、能够覆盖百度所有业务并真正落地的 DevSecOps 框架
  3. DevSecOps安全运营:对各个产品安全工具进行安全能力建设与工程化运营,并支持特定业务线的定制化需求
  4. 云原生场景的探索:在云原生基础架构变革大趋势下,讨论百度DevSecOps与云原生场景的融合与落地措施。

后边的章节会按照这个顺序逐一阐述。

3.1 产品安全工具链打造

业务安全保障的核心工作之一就是降低线上漏洞数量。在 DevSecOps 的建设中,想要大幅度降低线上漏洞数量,其核心是构建和利用好各种自动化漏洞发掘工具,并将其与CI/CD进行自动化集成,确保执行漏洞发掘的时机准确、及时,并且不会影响研发效率。

在我们的解决方案中,主要涉及到DAST、SAST、IAST、RASP等工具的设计与实现,感兴趣的同学可以阅读之前发过的相关文章:

  1. DAST

分布式Web漏洞扫描服务建设实践系列——扫描架构演进及要点问题解决实践

分布式Web漏洞扫描服务建设实践—衡量指标及解决实践(2)

  1. SAST

企业级自动化代码安全扫描实战

构建企业级研发安全编码规范

  1. IAST/FAST

灰盒自动化漏洞挖掘实践

  1. RASP

开源应用运行时自我保护解决方案 - OpenRASP

3.2 公司范围落地实践

3.2.1 总体落地思路

在百度,产品研发流程被抽象成「需求」、「开发」、「代码准入」、「测试」、「上线&验证」五个阶段。每个阶段都有完善且严格的规范和要求,例如在代码准入阶段,要求正式提交的代码必须严格遵循百度代码风格规范,否则不允许提交代码。这些规范保证了百度的产品能够优质、高效和稳定的交付,我们称之为研发工程规范性模型,下文简称工程规范性模型。

百度工程规范性模型将产品研发各个阶段的规范和措施的完成度量化为分数,以产品和代码仓库的维度进行统计和公示,并在公司层面建立了工程规范性评分基准线。

我们在思考如何设计和落地 DevSecOps在各个研发阶段的安全能力时,发现 DevSecOps 的内核与工程规范性模型是高度相似的,都是通过在产品研发的各个阶段设计规范、工具、检查,来提升研发效率、产品质量、工程师素养。

再一次的不谋而合,促使我们决定依托于百度工程规范性模型构建百度的 DevSecOps 模型,推动DevSecOps工具链与相关规范的落地实施,并借助于百度工程规范实现快速推广 DevSecOps 到全公司的效果。

百度工程规范性模型要求所有接入的规范、工具、方法都要具备高自动化以及高 CI/CD 集成的能力,这一点实际我们在SDL时代就已经完成。所以在落地DevSecOps时,我们只需要按照该模型的标准,将各项产品安全工具、产品安全措施转换为可量化、分步实施的安全检查项。

通过将安全检查项合理放置在产品研发的各个阶段中,我们实现了研发全链条覆盖:

同时得益于高度自动化的安全工具链支撑,虽然我们在研发流程中深度嵌入了很多安全检查项,但是依然可以满足DevOps时代产品快速迭代的需求。例如,我们将第三方高危组件、安全编码规范等安全检查项嵌入到代码准入阶段,自动化扫描任务可以在分钟级完成,完全不会影响代码的正常提交。

下面的章节,我们会介绍在 DevSecOps 落地过程中,在各个研发阶段涉及到的一些具体安全措施和安全工具。

3.2.2 需求阶段

-需求设计安全解决方案

在DevOps模式下,需求、设计阶段通常是整个研发周期中最灵活且难以控制的。由于业务量庞大、业务快速迭代的特点,很多传统产品安全措施如:威胁建模、安全设计评审、业务设计安全评估等工作难以覆盖到所有业务。

对此,在百度DevSecOps方案中,我们针对不同业务场景提供了一系列安全解决方案,覆盖Web业务、App业务、IoT业务、toB私有化、用户隐私等业务场景,基于多年SDL安全经验积累,对各个业务中容易出现风险的地方提供了统一化的安全解决方案,这些方案有的是规范约定,有的是bad case枚举,还有的是基于安全SDK的解决方案。

同时将其集成到百度工程规范指定的需求管理产品iCafe中。当业务线研发人员、PM创建需求卡片时,可以根据自身的业务场景选择对应的安全解决方案,并在研发前完成规范、安全方案的学习,从而在研发编码阶段尽可能避免这些问题。

3.2.3 开发/代码准入阶段

  1. 供应链安全检测

供应链安全检测主要聚焦第三方代码引入公司内部的安全性检测。

百度的产品代码托管在内部代码托管平台,因此供应链安全检测也应该围绕代码托管平台展开,除了在研发流程中嵌入新增代码检测以外,我们还针对存量的代码实现检测与工单追踪闭环,为第三方代码风险快速、有效收敛提供最便捷的通道。

整体检测架构为:

供应链检测系统中的第三方高危软件识别主要依托于指纹匹配技术,主要分为代码指纹识别与包管理解析两种。代码指纹识别类似于传统的正则匹配;包管理解析则是针对不同包管理文件,例如java的pom.xml、gradle,nodejs的package.json等,做语法解析,获取到引入的包名与版本号。代码指纹识别漏报率相对更高,包管理解析获取的包名通常为类库名,与第三方软件的通用名称存在差异,需要根据实际应用场景做进一步的适配和兼容。

第三方软件的漏洞被外界爆出后,攻击者可能在短时间内进行攻击,如果供应链检测无法做到快速响应,将会使得整个供应链安全检测的效果大大折扣,因此我们同步建设了实时指纹扫描与软件查询能力。通过打通线上工单系统,我们可以在分钟级完成漏洞代码定位与推送,并实现80% 以上代码库在一天内更新修复。以fastjson组件为例,在19年和20年的几次漏洞爆发中,我们在分钟级便完成大量使用fastjson组件的代码库定位与工单推送,并在天级的时间内推动业务代码完成修复,闭环效果十分明显。

  • 安全编码规范检查

安全编码规范检查主要聚焦于百度内部生产的代码的安全性检测。

区别于于传统白盒安全扫描,安全编码规范检查治理白盒漏洞的思路是先通过制定相关的基于安全基础库的安全编码规范,要求业务摒弃一些危险的编码习惯,比如各种拼接写法、调用不安全的默认API等,使用安全SDK中的API实现相关的功能,从而降低写出漏洞的风险。

与供应链安全检测类似,百度安全编码规范检查也集成在公司内部研发工具链中。

在这种模式下,一条规范检查规则是这样的:

关于该治理措施和安全工具的构建,可以阅读:构建企业级研发安全编码规范

3.2.4 测试阶段

在测试阶段,我们主要嵌入了上线前安全基准测试,也就是市面上DevSecOps方案主要宣传的部分,即各种安全工具链的使用,作为产品上线前的最后一个兜底工作。

在百度,我们构建了:黑盒扫描(DAST)、白盒扫描(SAST)、灰盒扫描(IAST/FAST)、RASP等产品安全工具链,并将这些工具做到自动化程度极高,减少业务参与的难度,实现一次配置永久运行的效果。

值得注意的是,RASP技术(https://rasp.baidu.com)除了在遭受外部攻击时可以进行攻击识别,还可以从一些程序错误中有效识别出漏洞。因此在我们的实践中,RASP产品被大量部署在测试环境中,在对业务线完全透明的情况下,帮助业务线提前发现漏洞、风险。

3.2.5 上线&验证阶段

目前上线&验证阶段主要是要求业务线进行安全产品、安全防护能力的接入,主要涉及到:日志备份、线上版RASP、集团WAF等,确保产品线上运行时安全。

3.3 DevSecOps安全运营

当我们完成整个研发全链条的覆盖之后,后续的工作变得相对比较简单,可以将有限的人力投入到工具链安全能力建设、产品线DevSecOps定制化需求、重点业务场景安全解决方案制定与实施中。通过精细化的安全运营,确保DevSecOps得以准确、高质量的实施。

3.4 DevSecOps云原生场景探索

CNCF将云原生定义为致力于帮助企业在公有云、私有云和混合云等新型动态环境中构建与运行可弹性扩展应用的一种技术,包括容器、微服务以及不可变基础设施等。

相比于传统的基础架构模型,构建于云原生技术之上的研发模型能够实现应用弹性、可扩展部署,并且开发和交付也更加敏捷。但与此同时,由于基础软件自由引入,应用快速迭代,镜像的获取、容器的部署更加灵活,云原生产品研发过程中实际上具有更多潜在的安全风险。比如当基础镜像中引入了恶意组件或者高危组件这种场景,传统的产品安全措施与工具链很难对其进行风险治理与收敛。

因此,我们需要将DevSecOps与云原生深度结合,对云原生技术下构建的研发流程进行持续管控,更好地在研发链条中保护业务安全。

云原生时代下,我们在DevSecOps方案中增加了镜像安全扫描、安全分发、镜像签名与运行时监控等产品安全措施,这些与原有的应用层DevSecOps共同构成了一条完整的DevSecOps安全管控链路。镜像扫描可以通过配置是否阻断,来限制包含高危漏洞的镜像上线;安全分发可以保证镜像分发安全,而运行时监控则能针对线上容器危险操作、非法网络连接等进行阻断。具体的管控方案如下:

除了增加一些自动化的检查和监控以外,我们还在着力推动镜像仓库统一化、基础镜像标准化等,避免线上运行时环境过于分散,降低后期治理与管控成本。

除了上述内容,我们也在关注K8s等编排工具本身的安全性,宿主机上容器软件权限设置,以及内核安全等。

将DevSecOps应用到云原生化架构中,让安全与业务更加紧密地联系在一起,将会是云原生时代提升业务安全质量、降低业务安全风险和后期安全成本的最优解,也可能是唯一解。

四、DevSecOps建设收益

通过DevSecOps的落地,我们从过去仅在测试阶段检查转变为产品研发全流程的安全保障,进一步提升了研发效率、安全问题检出效率,降低了安全问题的修复成本,并提升了产品安全质量以及业务团队的安全素养。

此外,业务线在各个研发阶段都能看到安全相关的措施,安全措施和研发措施进行融合,增进安全协同,更能够让业务线意识到产品安全并不只是安全团队的事情,而是产品线、安全团队一起协同的结果,Sec和Dev、Ops一样,都是研发过程中必须要做的工作。

总的来说,通过DevSecOps的落地,我们获得了:

  1. 打造了覆盖研发全链条的产品安全框架,后续可以基于这个框架进行产品安全措施扩展,比如将隐私合规要求融入DevSecOps需求阶段中
  2. 提升了研发效率、安全问题检出效率,降低了修复成本
  3. 提升了产品安全质量以及业务团队的安全素养
  4. 大幅度降低线上漏洞风险,自DevSecOps落地后,线上风险得到了进一步收敛

五、文章总结

本文从传统SDL时代的痛点出发,阐述了我们建设DevSecOps的初衷,并分享了百度DevSecOps在各个研发阶段的建设、落地思路与安全实践,以及相关工具链打造经验。最后介绍了我们建设DevSecOps的相关收益与效果。

希望本文对读者有所帮助。

查看原文

赞 2 收藏 0 评论 0

百度安全 发布了文章 · 7月14日

“联邦学习”标准发布 百度安全参与制定

【导读】:2020年7月9日,关于联邦学习的团体标准—《基于联邦学习的数据流通产品技术要求与测试方法》首次发布,百度作为主要参与拟订单位参与了标准的制定及发布。

image.png

2020年7月9日,关于联邦学习的团体标准——《基于联邦学习的数据流通产品技术要求与测试方法》首次发布,百度作为主要参与拟定单位参与了标准的制定及发布。

此次标准由中国通信标准化协会提出并归口,中国信息通信研究院、北京百度网讯科技有限公司等十余家单位及企业参与了标准的拟订工作。标准规定了基于联邦学习的数据流通产品必要的技术要求及相应的测试方法,适用于基于联邦学习的数据流通产品的研发、测试、评估和验收等场景。

中国通信标准化协会于2002年在北京成立,负责组织信息通信领域或国家标准、行业标准及团体标准的制修订工作,承担国家标准化管理委员会、工业及信息化部信息通信领域标准归口管理工作。此次标准的发布,标志着联邦学习这一技术将向着更加成熟化、标准化、产业化的方向发展,为今后各界共建联邦生态打下坚实基础。

至目前,百度安全联邦计算已参与了多项国内、国际标准的定制工作,包括 TC260国家标准——《信息安全技术数据脱敏产品安全技术要求和测试评价方法》(在研);TC601行业标准——《基于多方安全计算的数据流通产品技术要求与测试方法》、《数据脱敏工具技术要求与测试方法》(在研);相关国际标准——IEEE P2842 《Recommended Practice for Secure Multi-party Computation》(在研),在数据安全和隐私保护技术方面建立了多维度行业影响力。

百度安全联邦计算 联邦学习领域新探索
在大数据市场发展迅猛,国家法律法规逐步健全,监管从严的大潮下,通过数据安全技术实现跨机构数据安全合作已成为行业普遍共识,与此同时,促进数据安全流通共享,进一步释放数据价值,加速数据合作共赢也成为行业刚需。
在此基础上,百度安全推出联邦计算平台,致力打造更安全的数据合作体验,为跨机构数据合作提供联合分析、联合建模等隐私安全能力,为联邦学习的大规模工业化落地提供产品技术解决方案。

什么是百度安全联邦计算?

百度安全联邦计算(Baidu Federated Computing, BFC),高效融合多方安全计算(Secure Multi-Party Computation,MPC或SMC )、可信执行环境( Trusted Execution Environment,TEE)、差分隐私(Differential Privacy,DP)和数据脱敏(Data Masking)等多种领先数据安全和隐私保护技术,可在各方数据不出域的基础上进行联合计算,获取各方所需的计算结果,全力打造跨组织数据合作“可用不可见,相逢不相识”的极致安全服务体验。

目前,百度安全联邦计算已在联合营销等多个场景实现最佳实践,未来,亦将继续打磨安全可控、分布式计算的产品能力,深耕广告、政务、金融、医疗、工业等重点垂直领域,深化与ABC、边缘计算、区块链在资源、产品、解决方案方面的协同,更好的满足业务需求。

查看原文

赞 1 收藏 1 评论 0

百度安全 发布了文章 · 7月9日

AI,你准备好了吗? — 非对抗下的真实威胁

6月29日-7月2日在西班牙召开的 International Conference on Dependable Systems and Networks (DSN 2020)会议上, 来自百度安全对于深度神经网络(DNN)模型安全性的研究Quantifying DNN Model Robustness to theReal-World Threats成功入选。在该文章中,百度安全研究员们建立了一套衡量深度神经网络面对真实存在于物理世界威胁时鲁棒性的标准化框架。百度安全希望通过这个研究呼吁业内将人工智能模型的面对威胁,特别是面对物理世界中的威胁时的表现纳入衡量模型的标准,携手工业界、学术界共同探索与建设安全的AI时代。

DSN是可信系统和网络的国际会议,是国际顶尖的计算机会议之一,具有广泛的影响力。DSN2020国际会议,共有285篇论文投稿,录用48篇,录取率仅为16.8%。DSN率先提出了系统可靠性和安全性研究之间的融合,并以其独具一格的眼光聚焦于意外和恶意网络攻击,使其成为引领增强当今各种计算系统和网络的鲁棒性最负盛名的国际会议,为百度安全分享在AI鲁棒性研究提供了一个完美的舞台。

深度学习模型容易受到对抗样本的恶意攻击,这在业内已不是新鲜事。对图像数据添加人类难以通过感官辨识到的细微扰动,便可“欺骗”模型,指鹿为马,甚至无中生有。为实施此类攻击,攻击者往往需要提取了解模型结构模型的架构、参数,继而利用特定算法针对性的生成“对抗样本”,诱导模型做出错误的,甚至攻击者预设的判别结果。

然而在面对应用在安全攸关场景下的商业模型(例如,人脸识别、语音识别、无人驾驶等领域)中,很少有机会让攻击者掌握如此多的信息。当下以Google、Amazon为代表的国内外知名科技公司将云计算的运作模式与人工智能深度融合,将人工智能技术作为一种云服务(AIaaS,人工智能即服务)提供给用户和合作伙伴,除Amazon等少数公司会告知模型算法,绝大多数公司仅向用户反馈调用结果。模型信息以及攻击者攻击变现手段的缺失,此类恶意攻击尚未在现实业务中大量出现。

但这并不意味着这些商业模型就固若金汤了。百度安全团队在DSN 2020上带来的最新研究成果表明,真实世界的环境因素对输入数据正常扰动(例如:亮度、对比度变化,摄像头的抖动等等)就足以对深度学习模型的分类或预测结果产生不一致。更为要命的是此类威胁在非对抗场景中与生俱来。而业内对此类威胁重视程度并不足,目前缺乏对此类威胁的合理定义,并且苦于无法有效地评估深度学习模型鲁棒性。如果持续忽略此类威胁,不仅会导致严重的安全事故,也会破坏整个人工智能生态应用的进程。如果说对抗样本的发现,将传统安全产业框架延伸至机器学习模型算法安全性的范畴,那么物理世界安全属性扰动带来的威胁,则令这个问题更加严峻和复杂。这意味着现有模型在不存在恶意攻击者情况下就可能自乱阵脚,AI系统在特定环境下,例如自动驾驶在雨雪天气,颠簸路面将丧失对城市交通、道路标识及车辆正确的识别能力。此类威胁还可延伸至金融认证、安全监控等领域,蕴含巨大的安全风险。建立有效的模型鲁棒性评估机制是打造真正安全可行的AI系统必不可少的基石。

图1:真实世界的环境因素对输入数据正常扰动

百度安全团队中的Zhenyu Zhong、Zhisheng Hu、XiaoweiChen博士创新性的提供了一个模型鲁棒性评估量化框架,如图2所示。首先基于现实世界的正常扰动定义了可能出现威胁的五大安全属性,分别是光照,空间变换,模糊,噪声和天气变化。并且针对不同的模型任务场景,制定了不同的评估标准,如非定向分类错误、目标类别错误分类到评估者设定的类别等标准。对于不同安全属性扰动带来的威胁,该框架采用了图像领域中广为接受的最小扰动的Lp-norm来量化威胁严重性以及模型鲁棒性。

图2:深度学习模型鲁棒性评估框架

百度安全团队在现场展示了不同学习任务模型 - - 包含13个开源图像分类模型、3个SOTA目标检测模型、3个商用云端黑盒模型,在面对不同安全属性下带来的威胁,以及不同评估标准下的鲁棒性测评。并且展示了同类型学习下,不同模型鲁棒性的横向比较。评测结果表明,物理世界威胁不但普遍存在,而且较小的扰动就足以触发。无论是目标检测模型还是云端黑盒模型,在各个安全属性扰动下,都会被成功欺骗。例如图3中所示,由于摄像头抖动带来的极小的motion blur就足以使实验中的3个目标检测模型产生误判。而这些目标检测模型常用于自动驾驶中。同样用于不良内容过滤的云端模型,添加轻微的噪声便足以绕过。

图3:目标检测模型以及云端模型鲁棒性对比

百度安全研究员还与参会学者一同探讨了百度安全针对物理世界威胁解决思路,包括针对特定安全场景选取不同模型框架、对抗训练强化模型提高深度学习模型鲁棒性等途径。此外,百度安全始终倡导通过新一代技术研发与开源,此文中的鲁棒性评估量化框架已与百度安全perceptron robustness benchmarking dataset一同应用于百度深度学习开源平台PaddlePaddle及当下主流深度学习平台,可高效地评估模型面对物理世界威胁的特征统计,同时也支持使用最新的生成方法构造恶意对抗样本数据集用于攻击全新的AI应用、加固业务AI模型,为模型安全性研究和应用提供重要的支持。

*点击阅读原文查看视频分享

YouTube视频链接:https://www.youtube.com/watch...

查看原文

赞 0 收藏 0 评论 0

百度安全 发布了文章 · 6月30日

关于深度神经网络(DNN)模型安全性的研究 —— 非对抗下的真实威胁

6月29日-7月2日在西班牙召开的 International Conference on Dependable Systems and Networks (DSN 2020)会议上, 来自百度安全对于深度神经网络(DNN)模型安全性的研究Quantifying DNN Model Robustness to theReal-World Threats成功入选。在该文章中,百度安全研究员们建立了一套衡量深度神经网络面对真实存在于物理世界威胁时鲁棒性的标准化框架。百度安全希望通过这个研究呼吁业内将人工智能模型的面对威胁,特别是面对物理世界中的威胁时的表现纳入衡量模型的标准,携手工业界、学术界共同探索与建设安全的AI时代。

DSN是可信系统和网络的国际会议,是国际顶尖的计算机会议之一,具有广泛的影响力。DSN2020国际会议,共有285篇论文投稿,录用48篇,录取率仅为16.8%。DSN率先提出了系统可靠性和安全性研究之间的融合,并以其独具一格的眼光聚焦于意外和恶意网络攻击,使其成为引领增强当今各种计算系统和网络的鲁棒性最负盛名的国际会议,为百度安全分享在AI鲁棒性研究提供了一个完美的舞台。

深度学习模型容易受到对抗样本的恶意攻击,这在业内已不是新鲜事。对图像数据添加人类难以通过感官辨识到的细微扰动,便可“欺骗”模型,指鹿为马,甚至无中生有。为实施此类攻击,攻击者往往需要提取了解模型结构模型的架构、参数,继而利用特定算法针对性的生成“对抗样本”,诱导模型做出错误的,甚至攻击者预设的判别结果。

然而在面对应用在安全攸关场景下的商业模型(例如,人脸识别、语音识别、无人驾驶等领域)中,很少有机会让攻击者掌握如此多的信息。当下以Google、Amazon为代表的国内外知名科技公司将云计算的运作模式与人工智能深度融合,将人工智能技术作为一种云服务(AIaaS,人工智能即服务)提供给用户和合作伙伴,除Amazon等少数公司会告知模型算法,绝大多数公司仅向用户反馈调用结果。模型信息以及攻击者攻击变现手段的缺失,此类恶意攻击尚未在现实业务中大量出现。

但这并不意味着这些商业模型就固若金汤了。百度安全团队在DSN 2020上带来的最新研究成果表明,真实世界的环境因素对输入数据正常扰动(例如:亮度、对比度变化,摄像头的抖动等等)就足以对深度学习模型的分类或预测结果产生不一致。更为要命的是此类威胁在非对抗场景中与生俱来。而业内对此类威胁重视程度并不足,目前缺乏对此类威胁的合理定义,并且苦于无法有效地评估深度学习模型鲁棒性。如果持续忽略此类威胁,不仅会导致严重的安全事故,也会破坏整个人工智能生态应用的进程。如果说对抗样本的发现,将传统安全产业框架延伸至机器学习模型算法安全性的范畴,那么物理世界安全属性扰动带来的威胁,则令这个问题更加严峻和复杂。这意味着现有模型在不存在恶意攻击者情况下就可能自乱阵脚,AI系统在特定环境下,例如自动驾驶在雨雪天气,颠簸路面将丧失对城市交通、道路标识及车辆正确的识别能力。此类威胁还可延伸至金融认证、安全监控等领域,蕴含巨大的安全风险。建立有效的模型鲁棒性评估机制是打造真正安全可行的AI系统必不可少的基石。

image.png

图1:真实世界的环境因素对输入数据正常扰动

百度安全团队中的Zhenyu Zhong、Zhisheng Hu、XiaoweiChen博士创新性的提供了一个模型鲁棒性评估量化框架,如图2所示。首先基于现实世界的正常扰动定义了可能出现威胁的五大安全属性,分别是光照,空间变换,模糊,噪声和天气变化。并且针对不同的模型任务场景,制定了不同的评估标准,如非定向分类错误、目标类别错误分类到评估者设定的类别等标准。对于不同安全属性扰动带来的威胁,该框架采用了图像领域中广为接受的最小扰动的Lp-norm来量化威胁严重性以及模型鲁棒性。

image.png
图2:深度学习模型鲁棒性评估框架

百度安全团队在现场展示了不同学习任务模型 - - 包含13个开源图像分类模型、3个SOTA目标检测模型、3个商用云端黑盒模型,在面对不同安全属性下带来的威胁,以及不同评估标准下的鲁棒性测评。并且展示了同类型学习下,不同模型鲁棒性的横向比较。评测结果表明,物理世界威胁不但普遍存在,而且较小的扰动就足以触发。无论是目标检测模型还是云端黑盒模型,在各个安全属性扰动下,都会被成功欺骗。例如图3中所示,由于摄像头抖动带来的极小的motion blur就足以使实验中的3个目标检测模型产生误判。而这些目标检测模型常用于自动驾驶中。同样用于不良内容过滤的云端模型,添加轻微的噪声便足以绕过。

image.png
图3:目标检测模型以及云端模型鲁棒性对比

百度安全研究员还与参会学者一同探讨了百度安全针对物理世界威胁解决思路,包括针对特定安全场景选取不同模型框架、对抗训练强化模型提高深度学习模型鲁棒性等途径。此外,百度安全始终倡导通过新一代技术研发与开源,此文中的鲁棒性评估量化框架已与百度安全perceptron robustness benchmarking dataset一同应用于百度深度学习开源平台PaddlePaddle及当下主流深度学习平台,可高效地评估模型面对物理世界威胁的特征统计,同时也支持使用最新的生成方法构造恶意对抗样本数据集用于攻击全新的AI应用、加固业务AI模型,为模型安全性研究和应用提供重要的支持。

*点击链接查看视频分享
https://v.qq.com/x/page/h3106...
————————————————

查看原文

赞 0 收藏 0 评论 0

百度安全 发布了文章 · 6月28日

区块链共识机制介绍

作者:qinyutong、chengyueqiang

共识机制(Consensus Mechanism)是区块链事务达成分布式共识的算法,随着区块链这一技术不断被推广,共识机制作为区块链的核心,也愈加受到人们的关注。共识机制在保护数据的一致性方面具有重要作用。本文选取了 8 种常用的共识机制,根据机制的原理、运行过程中的角色、算法流程以及优缺点等方面,对工作量证明、权益证明、容量证明等机制进行详细介绍。同时,文章也对相似的机制进行对比分析。从而加深人们对共识机制的了解,加速区块链技术的发展。

1   引言

区块链是比特币的底层技术,类似于数据库账本,而共识机制是去中心化的分布式账本中的规则核心,决定了区块链的安全性、可扩展性和去中心化程度等许多重要特性。

共识机制是指以去中心化的方式就网络的状态达成统一协议的过程。也被称为共识算法,有助于验证和验证信息被添加到分类账簿,确保只有真实的事务记录在区块链上 [12]。因此,共识机制负责安全地更新分布式网络中的数据状态。已经硬编码到协议中的规则确保在全球计算机网络中总是能找到唯一的数据来源并达成一致。这些规则保护整个网络,实现无需信任的网络,而无需中央数据或中介。

共识机制是决定按照哪一个参与节点记账,和确保交易安全完成的重要手段。[8] 共识机制需要平衡效率和安全的关系,安全措施越复杂,相应的处理时间越慢。而想要提高处理速度,简化安全措施的复杂度是非常重要的一步。

共识机制同时满足一致性和有效性。一致性是指所有诚实节点保存的区块链前缀部分完全相同,而有效性是指由某诚实节点发布的信息终将被其他所有诚实节点记录在自己的区块中 [11]。共识机制确保区块链是容错的,因此是可靠和一致的。与中心化系统不同,用户不必信任系统中的任何人,区块链共识机制中嵌入的协议规则可以确保只有有效和真实的交易才可以被记在公共透明的账簿中,嵌入网络的协议规则保证了公共分类帐的状态总是随着大众的共识变换而更新。

区块链的去中心化的一个重要优势是分配授权,任何人都能在同一个基础上参与进来。而共识机制可以确保区块链不存在区别对待,从而达到公平分配。由于公共区块链具有开源这一特性,使任何人都可以监督并验证底层源代码对网络中的所有参与者是否公平 [7]。

共识机制可以通过激励好的行为,在某些情况下,惩罚坏的行为者来实现这一点。例如在工作量证明这一机制中,通过奖励比特币给矿工这一方式,奖励他们每一笔交易的担保和验证。任何运算和安全维护都需要大量的算力和钱财,而共识机制可以使这些资源将更好地用于为系统工作,而不是针对系统。

常见的共识机制有:PoW(工作量证明)、PoS(权益证明)、DPoS(委任权益证明)、PBFT(实用拜占庭容错算法)、POOL(验证池)等。

2   PoW:Proof of Work(工作量证明)

2008 年,在比特币白皮书(Bitcoinswhitepaper)上,PoW 第一次得到重视。PoW 是依赖机器进行数学运算(与或运算,计算出一个满足规则的随机数)来获得本次记账权 [1],向全网其他节点发送本次需要记录的数据,由其他节点验证后,达成共识后对数据进行存储。PoW 最早是一个经济学名词,它是指系统为达到某一目标而设置的度量方法。简单理解就是一份证明 [3],用来确认你做过一定量的工作。监测工作的整个过程通常是极为低效的,而通过对工作的结果进行认证来证明完成了相应的工作量,则是一种非常高效的方式。

举例说明,10+?=12,谁先解出来答案,谁就收获。

一句话概括:干的越多,收的越多(有且仅有实际劳动,才能获得成果)

图 1: PoW 的工作原理图示

2.1   名词解释

哈希函数 Hash 哈希函数是一个单向加密函数,哈希算法能够获取任意数量的数据,并返回一个固定长度的字符串 [6],该字符串对于特定的输入是完全唯一的。

Nonce  一个只能使用一次的随机数。

矿工 Miners  加密货币网络中独立的交易处理器,其目标是验证交易。通常也被称作Full Node或Node。

2.2   角色

工作者 需要完成的工作必须有一定的量,这个量由工作验证者给出;

工作者无法找到很快完成工作的办法;

工作者无法自己” 创造工作”,必须由验证者发布工作。

验证者 可以迅速的检验工作量是否达标。

2.3   优点

1. 算法简单,容易实现。

2. 节点间无需交换额外的信息即可达成共识(节点间自由进出)。

3. 破坏系统需要投入极大的成本。

4. 需要全网所有节点参与,完全去中心化。

2.4   缺点

1. 目前比特币已经吸引全球大部分的算力,新的区块链必须找到一种不同的散列算法,很难使用与过去相同的算力得到相同的安全保障。

2. 大量的资源浪费。

3. 共识达成的周期较长,不适合商业应用(容易产生分叉,需要等待多个确认,区块的确认时间难以缩短)。

4. 永远没有最终性,需要检查点机制来弥补最终性。

2.5   应用实例

比特币中,使用 PoW 确认区块的有效性(只要该 CPU 耗费的工作量能够满足该工作量的证明机制,那么除非重新完成相当的工作量,该区块的信息就不可更改)

2.6   问题解释

为什么说 PoW 消耗能源的问题严重?

——因为矿工(Miners)的每一个猜测(guess)都需要消耗一台计算机产生一定数量的能量。目前,整个比特币网络的哈希率(Hash rate)为~17,000,000 TH/s,即整个网络每秒 17,000,000,000,000,000,000 个猜测(guess)。这种能源需求与匈牙利的消费量大致相同。 

3   PoS:Proof of Stake(权益证明)

2012 年,PoS 作为点点币(Peercoin)的介绍首次被提出。PoS 是 PoW 的一种升级共识机制,不需要消耗电力来进行运算,根据每个节点记账权的获得难度,令其与节点持有的权益成反比,等比例的降低挖矿难度,从而加快找随机数的速度。为了保证其简单,PoS 中没有矿工(Miners),而是改为了验证员(Validators)。仍然是基于哈希运算竞争获取记账权的方式,容错性与PoW 相同。PoS 是基于矿工们目前拥有的数字货币数量分配,一种根据你持有货币的量和时间进行利息分配的制度,在 PoS 模式下,你的“挖矿”收益与你的币龄成正比,而与电脑的计算性能无关。

举例说明,PoS 类比成我们手中的钞票。当我们拥有的钞票越多,那在生活中所获得的权益就越多。一句话概括:持有越多,获得越多(在银行存钱得利息)

3.1   名词解释

验证员 Validators 验证器,要验证交易,验证器必须下注一定数量的stake,stake的大小决定了验证器验证下一区块的可能性。

3.2   优点

1. 在一定程度上缩短了共识达成的时间,转账效率提高。

2. 不再需要大量消耗能源和算力挖矿。

3.3   缺点

1. 还是需要挖矿,本质上没有解决商业应用的痛点。

2. 所有的确认都只是一个概率上的表达,而不是一个确定性的事情,理论上有可能存在其他攻击影响。

3. 去中心化程度,容易出现强者恒强的情况,持币大户持币生息,从而出现垄断问题。

3.4   问题解释

PoS 在改善了PoW 消耗能源的问题后,还有哪些问题需要考虑?

——诸多问题中拥有最大争议的问题是,如果过多的权重被赋予非常多的财富或旧节点,网络会很快变得不公平。

表 1: PoW 和 PoS 的比较

4   DPoS:Delegated Proof of Stake(委任权益证明)

与 PoS 的主要区别在于节点选举若干代理人,向代理人授权选票后,由代理人验证和记账,钱包即为状态监视器。其合规监管、性能、资源消耗和容错性与 PoS 相似。类似于董事会投票,持币者投出一定数量的节点,由节点选择代理人,代理他们进行验证和记账。

举例说明,如果持币者 A 支持了代理人 50 个币,持币者 B 支持了代理人 10 个币,那么 A 的投票权重是 B 的 5 倍。

一句话概括:节点选举若干代理人,由代理人验证和记账

4.1   组成部分

1. 选出一组区块生产者:选举过程由token 持有者决定,选举出的生产者的表现会影响到整个网络的工作情况,进而影响到 token 持有者的利益。

2. 调度生产

4.2   算法流程(以正常操作和少数分叉为例)

1. 正常操作:正常情况下区块生产者按顺序进行生产,间隔时间是3s。没有人错失生产,如下便是最长的链(箭头指向前一个区块)。

图 2: 正常操作

2. 少数分叉:当不超过 1/3 的节点有恶意或不能工作,而产生一个分叉时,如下图的 B,这条分叉每 8 秒出一个块,而正常工作的节点每 8 秒出 2 个块 [13]。原因是按照 A,B,C,A... 的顺序,每个节点要等待相应时间才可以出块。根据最长链原则,系统依然能运行。

图 3: 少数分叉

4.3   优点

1. 大幅缩小参与验证和记账节点的数量,可以达到秒级的共识验证。

2. 通过赞成投票制,可以确保即使一个人拥有50%的有效投票权,也不能独自选择一个出块人,保证算法安全。

3. 大多数出块人出现问题时,DPoS 仍可以继续工作。

4.4   缺点

1. 整个共识机制还是依赖于代币,很多商业应用是不需要代币存在的。

2. 弱中心化,去中心化程度不高。

4.5   应用实例

EOSIO:EOSIO 由委托证明 (DPoS) 系统维护,该系统最初是由 Larimer 创建的,现在仍被 Steemit 使用。Dan Larimer 第一次在 BitShares 使用 DPOS,它立即成为最快的区块链之一。后来BM 将 DPOS 引入 Steem,Steem被认为是最快和最稳定的区块链项目之一,每天处理超过 100 万交易,而只使用其容量的百分之一。

5   PBFT:Practical ByzantineFault Tolerance(实用拜占庭容错算法)

PBFT 是一种状态机副本复制算法,一般包括三种协议:一致性协议 (agreement)、检查点协议 (checkpoint) 和视图更换协议 (view change)。在保证活性和安全性(liveness and safety)的前提下提供了 (n-1)/3 的容错性。在分布式计算上,不同的计算机透过讯息交换,尝试达成共识;但有时候,系统上协调计算机(Coordinator / Commander)或成员计算机(Member/Lieutanent)可能因系统错误并交换错的讯息,导致影响最终的系统一致性[9]。拜占庭将军问题就根据有多少错误计算机来寻找可能的解决办法,虽然无法找到一个绝对答案,但只可以用来验证一个机制是否有效。而拜占庭问题的可能解决方法为:在 N ≥ 3F + 1的情况下一致性是可能解决。其中,N为计算机总数,F为有问题计算机总数。信息在计算机间互相交换后,各计算机列出所有得到的信息,以大多数的结果作为解决办法。

一句话概括:每个“将军”根据内部状态和新消息结合运行计算或操作,从而达成个人决定,个体将决定共享,根据全部决定确定共识决定。

5.1   协议

一致性协议至少包含若干个阶段:请求(request)、序号分配(pre-prepare)和响应(reply)。根据协议设计的不同,可能包含相互交互(prepare),序号确认(commit)等阶段。

检查点协议算法设置周期性的检查点协议, 将系统中的服务器同步到某一个相同的状态,系统会设置一个 check-point 的时间点,在这个时刻可以定期地处理日志、节约资源并及时纠正服务器状态。

视图更换协议某个副本节点 i 检测出主节点作恶或者下线,会产生超时机制,启动视图更换,并将视图编号 v 变更为 v+1,同时不再接受除检查点消息(checkpoint)、视图更换消息 (view-change) 和新视图消息(new-view)外的其他消息请求。

基于全同态加密的 PSI 全同态加密技术使得对于明文的数学操作可以直接在密文上进行而不需要先将密文解密。早期的全同态加密十分低效,而它的性能在近几年才有所提高。使用全同态加密技术的 PSI 协议,通过拥有较小集合的一方将自己的集合加密以后发送给另一方,而另一方负责基于密文求两个集合的交集,然后将结果交给对方解密。使用全同态加密实现 PSI 可以达到相对较小的交互复杂度,但它的计算复杂度通常非常高,导致协议效率低下。所以,在不牺牲太多交互复杂度的情况下降低计算复杂度是基于全同态加密的 PSI 协议主要面临的挑战。

5.2   算法流程

1. 客户端发起消息:客户端 C 向主节点发送操作请求 <REQUEST,o,t,c>

   o: 请求执行状态机操作

   t: 客户端追加的时间戳

   c: 客户端标志

   REQUEST: 包含消息内容 m,以及消息摘要 d(m) 等

2. 预准备阶段: 在预准备阶段,主节点对收到的客户端请求消息签名进行验证,验证通过,基于当前视图 v 分配一个序列号 n 给收到的客户端请求,然后向所有备份节点群发送预准备消息 < <PRE-PREPARE, v, n , d>, m>

  v:视图编号m:客户端发送的请求消息d:请求消息m 的摘要n:预准备消息序号

预准备消息的目的是作为一种证明,确定该请求已在视图v 中被赋予了序号 n,从而在视图变更的过程中消息仍可被追溯。

3. 准备阶段: 副本节点 i 收到主节点的 PRE-PREPARE 消息,需要进行以下校验:

•   主节点 PRE-PREPARE 消息签名是否正确。

•   当前副本节点是否已经收到了一条在同一v 下并且编号也是 n,但是签名不同的PRE-PREPARE 信息。

•   d 与 m 的摘要是否一致。

•   n 是否在区间 [h, H] 内。

校验通过后,副本节点 i 向所有副本节点发送准备消息 <PREPARE,v, n, d, i>,并将预准备消息和准备消息在节点i 进行保存,用于 View Change 过程中恢复未完成的请求操作。当节点 i 收到接超过 2f+1 个节点的准备消息后,就可以进入确认阶段。其中会检查这些消息的视图编号 v,消息序号 n 和摘要 d。

4. 确认阶段:进入确认阶段的节点向其他节点包括主节点发送一条<COMMIT, v, n, d, i> 确认消息。当节点i 接受到 2f+1 个 m 的确认消息后并满足相应条件后,消息m 变更为 committed-local 状态,节点执行 m 的请求。在完成 m 请求的操作之后,每个副本节点都向客户端发送回复。进入 reply 阶段。

5. 回应客户端:节点 i 返回 <REPLY, v, t, c, i, r> 给客户端,r:请求操作结果。客户端如果收到f+1 个相同的 REPLY 消息,说明客户端发起的请求已经达成全网共识,否则客户端需要判断是否重新发送请求给主节点。

图 4: 注:副本 0 是主节点,副本 3 是失效节点,C 是客户端。

5.3   优点

1. 系统运转可以脱离币的存在,PBFT 算法共识各节点由业务的参与方或者监管方组成,安全性与稳定性由业务相关方保证。

2. 共识的时延大约在 2~5 秒钟,基本达到商用实时处理的要求。

3. 共识效率高,吞吐量高,可满足高频交易量的需求。

4. 不使用工作量证明的耗电模式,更加节能环保。

5.4   缺点

1. 受到节点数量的限制以及节点需要选举或许可,可扩展性及去中心化程度较弱。

2. 容错性较低,当有 1/3 或以上记账人停止工作后,系统将无法提供服务;当有 1/3 或以上记账人联合作恶,且其它所有的记账人被恰好分割为两个网络孤岛时,恶意记账人可以使系统出现分叉,但是会留下密码学证据。

6   POOL(验证池)

验证池机制是基于传统的分布式一致性技术和数据验证机制的结合,它使得在成熟的分布式一致性算法(Paxos、Raft)基础上,不需要代币也能实现秒级共识验证。

6.1   优点

1. 不需要代币也可以工作,在成熟的分布式一致性算法(Paxos、Raft)基础上,实现秒级共识验证。

2. 提高应用程序的运行速度,改善效率并降低开销。

6.2   缺点

1. 去中心化程度不如比特币。

2. 更适合多方参与的多中心商业模式。

7   PoC:Proof of Capacity(容量证明)

2015 年,该理念被 Dziembowski 等进行了形式化定义。PoC 通过分配一定数量的内存或磁盘空间用于解决服务提供者所提供挑战的方式,显示了某个人对某个服务(例如发送邮件)具有合法的兴趣。虽然 Ateniese 等人的论文 名称也是“Proof-of-space”,但它事实上一种采用 MHF(Memory Hard Function,一种计算代价取决内存的哈希算法)的 PoW 协议。PoC 是使用缓存大量数据的方法来对计算时间进行节省。

举例说明,将彩票填满硬盘驱动器,生成一个随机数,然后检查匹配数字最多的人。如果你有最匹配的号码,你就会赢得奖励。

一句话概括:储存空间越大,收的越多(有且仅有实际劳动,才能获得成果)

7.1   名词解释

哈希值 Shabal Shabal算法是一种很慢的算法,允许输入任意长度的有序位序列,甚至是一个空序列。也适应任何长度的字节流,但是由于考虑到安全性,适用长度最好小于 27位。输入长度可以是任何整数值和8的倍数。假如给定一个 bit 序列,按其左右顺序索引编号,即第一位的索引为0。使用左和右来描述有序的位序列:序列中的第一位称为最左位,最后一位称为最右位。

Plotting 绘图产生存储大量预计算哈希值的文件,在存储器充满哈希值的文件后,仍可以参与块的创建过程。这个过程叫做绘图。

7.2   算法流程

1. 硬盘驱动器的绘图:根据硬盘驱动器的大小,制作独特的绘图文件可能需要几天甚至几周的时间。绘图时使用被称为 Shabal 的非常慢的哈希值。与 SHA-256 哈希值不同,Shabal 是比特币矿商快速使用的哈希值。由于Shabal 哈希值很难计算,所以我们必须预先计算它们并将它们存储在硬盘上。这个过程称为绘制硬盘驱动器。

2. 块的实际挖矿:计算 0 到 4085 之间的铲斗数。假设你的计算结果是42。然后你会去舀 42 勺nonce 1 然后用舀的数据来计算一段时间,这叫做截止时间[5]。对硬盘上的所有 nonces 重复此过程。在计算完所有的截止日期后,你会选择最小的截止日期。截止日期表示“在允许您伪造一个块之前,自最后一个块被伪造以来必须经过的秒数”。如果在这段时间内没有其他人锻造了一个块,你可以锻造一个块并获得一个块奖励。

图 5: PoC 的工作过程图示

7.3   优点

1. 你可以使用任何普通硬盘,这样其他矿商就不会从购买专门设备中获得优势,比如用 ASIC 挖矿比特币。

2. 使用硬盘驱动器的能源效率是基于ASIC 的采矿的 30 倍。

3. 容量证明更加分散,因为每个人都有一个硬盘驱动器。你甚至可以从你的 Android 手机的硬盘上进行挖矿。

4. 矿商不需要不断升级设备。旧硬盘可以像新硬盘一样存储数据。

5. 完成挖矿后可以清除硬盘驱动器,并将其用于最初的目的。

7.4   缺点

1.  产能开采的普遍证据可能会导致另一场军备竞赛。今天人们使用tb 的硬盘,但是我们最终会看到 pb、exabytes 和 zettabytes。

2. 容量证明是一项相对较新的技术,在现实世界中没有经过严格的测试和挑战。

3. 目前,硬盘驱动器绘制的数据除了挖矿用途外是无用的。然而,有计划将硬盘用作重要开源信息的冗余存储。硬盘可以存储地图、维基百科文章或其他值得保存的信息。

4. 已经有恶意软件在人们的电脑上挖矿比特币。如果容量证明变得流行起来,你可能会看到恶意软件在密谋人们的硬盘。

7.5   问题解释

为什么说 PoC 是一种低电力消耗的共识机制?

——在容量证明的环境下,由于机械硬盘天生对(相对的)电力不敏感,电力成本短期内不再是矿工加入网络的敲门 砖,而机械硬盘的广泛适配性,更进一步降低了矿工加入网络的难度,目前家用电脑常用之1~2T 硬盘即可成为挖矿设备。更进一步,容量证明实际上不储存网络数据,即使硬盘损坏也不会导致网络内容丢失,避免了FIlecoin 时空证明中数据丢失对网络使用性的影响。

图 6: PoC 和 PoW 的比较

8   Paxos

Paxos 由 Lamport 于 1888 年在《The Part-Time Parliament》论文中首次公开。Paxos算法解决的问题正是分布式一致性问题,即一个分布式系统中的各个进程如何就某个值(决议)达成一致。

Paxos 算法运行在允许宕机故障的异步系统中,不要求可靠的消息传递,可容忍消息丢失、延迟、乱序以及重复。它利用大多数 (Majority) 机制保证了 2F+1 的容错能力,即 2F+1 个节点的系统最多允许 F 个节点同时出现故障 [2]。一个或多个提议进程 (Proposer) 可以发起提案 (Proposal),Paxos 算法使所有提案中的某一个提案,在所有进程中达成一致。系统中的多数派同时认可该提案,即达成了一致。最多只针对一个确定的提案达成一致。

8.1   角色

Proposer  提出提案(Proposal)。Proposal信息包括提案编号(Proposal ID)和提议的值(Value)。

Acceptor 参与决策,回应Proposers的提案。收到Proposal后可以接受提案,若Proposal获得多数Acceptors的接受,则称该 Proposal 被批准。

Learner 不参与决策,从Proposers/Acceptors学习最新达成一致的提案(Value)。

8.2   原则

8.2.1   安全原则

 保证不能做错的事。 

1. 针对某个实例的表决只能有一个值被批准,不能出现一个被批准的值被另一个值覆盖的情况;(假设有一个值被多数 Acceptors 批准了,那么这个值就只能被学习)。

2. 每个节点只能学习到已经被批准的值,不能学习没有被批准的值。

8.2.2   存活原则

 只要有多数服务器存活并且彼此间可以通信,最终都要做到的下列事情:

1. 最终会批准某个被提议的值。

2. 一个值被批准了,其他服务器最终会学习到这个值。

8.3   算法流程

 1. 第一阶段:Prepare 阶段。Proposer 向 Acceptors 发出 Prepare 请求,Acceptors 针对收到的 Prepare 请求进行 Promise 承诺。

2. 第二阶段:Accept 阶段。Proposer 收到多数 Acceptors 承诺的 Promise 后,向 Acceptors 发出 Propose 请求, Acceptors 针对收到的 Propose 请求进行 Accept 处理。

3. Learn 阶段。Proposer 在收到多数 Acceptors 的 Accept 之后,标志着本次 Accept 成功,决议形成,将形成的决议发送给所有 Learners。

8.3.1   算法描述

 1. Prepare: Proposer 生成全局唯一且递增的 Proposal ID (可使用时间戳加 Server ID),向所有 Acceptors 发送Prepare 请求,这里无需携带提案内容, 只携带 Proposal ID 即可。 

2. Propose: Proposer 收到多数 Acceptors 的 Promise 应答后,从应答中选择 Proposal ID 最大的提案的 Value,作为本次要发起的提案。如果所有应答的提案 Value 均为空值,则可以自己随意决定提案 Value。然后携带当前 Proposal ID,向所有 Acceptors 发送 Propose 请求。

3. Acceptors 收到 Prepare 请求后,做出“两个承诺,一个应答”。

4. Accept: Acceptor 收到 Propose 请求后,在不违背自己之前作出的承诺下,接受并持久化当前Proposal ID 和提案 Value。

5. Learn: Proposer 收到多数 Acceptors 的 Accept 后,决议形成,将形成的决议发送给所有 Learners。 

图 7: Paxos 算法过程

8.3.2   两个承诺,一个应答 [4]

 1. 两个承诺:不再接受 Proposal ID 小于等于当前请求的 Prepare 请求;不再接受 Proposal ID 小于当前请求的Propose 请求。

2. 一个应答:不违背以前作出的承诺下,回复已经Accept 过的提案中 Proposal ID 最大的那个提案的 Value 和 Proposal ID,没有则返回空值。

8.4   优点

1. 高效,节点通信无须验证身份签名。

2. Paxos 算法有严格的数学证明,系统设计精妙。

3. 容错性能: 允许半数以内的 Acceptor 失效、任意数量的 Proposer 失效,都能运行。一旦 value 值被确定,即使半数以内的 Acceptor 失效,此值也可以被获取,并不会再修改。

8.5   缺点

1. 工程实践比较难,达到工业级性能需要进行不同程度的工程优化,而有时工程设计的偏差会造成整个系统的崩溃。

2. 只适用于 permissionedsystems(私有链),只能容纳故障节点 (fault),不容纳作恶节点 (corrupt)。

3. 持 CFT(Crash FaultTolerant),不支持拜占庭容错 (ByzantineFault Tolerance)。

8.6   问题解释

Multi-Paxos 和 Paxos 的关系? 

——朴素Paxos 算法通过多轮的 Prepare/Accept 过程来确定一个值,我们称这整个过程为一个 Instance。Multi-Paxos 是通过 Paxos 算法来确定很多个值,而且这些值的顺序在各个节点完全一致,概括来讲就是确定一个全局顺序 [10]。

9   Raft

Raft 最初是一个用于管理复制日志的共识算法,它是一个为真实世界应用建立的协议,主要注重协议的落地性和可理解性。Raft 是在非拜占庭故障下达成共识的强一致协议,是一种管理复制日志的一致性算法。它的首要设计目的就是易于理解,所以在选主的冲突处理等方式上它都选择了非常简单明了的解决方案。Paxos 有效的基本保障是:任意两个法定集合,必定存在一个公共的成员。分布式系统除了提升整个体统的性能外还有一个重要特征就是提高系统的可靠性。提供可靠性可以理解为系统中一台或多台的机器故障不会使系统不可用(或者丢失数据)。保证系统可靠性的关键就是多副本(即数据需要有备份),一旦有多副本,那么久面临多副本之间的一致性问题。一致性算法正是用于解决分布式环境下多副本之间数据一致性的问题的。 

业界最著名的一致性算法就是大名鼎鼎的 Paxos(Chubby 的作者曾说过:世上只有一种一致性算法,就是Paxos)。

但 Paxos 是出了名的难懂,而 Raft 正是为了探索一种更易于理解的一致性算法而产生的。

9.1   角色

Raft 要求系统在任意时刻最多只有一个 Leader,正常工作期间只有 Leader 和 Followers。

Leader 领导者接受客户端请求,并向Follower同步请求日志,当日志同步到大多数节点上后告诉Follower提交日志。所有对系统的修改都会先经过Leader,每个修改都会写一条日志 (Log Entry)。Leader 收到修改请求后的过程如下,这个过程叫做日志复制(Log Replication):

 图 8: 日志复制

Follower 跟从者所有结点都以Follower的状态开始。如果没收到Leader消息则会变成Candidate状态。接受并持久化 Leader 同步的日志,在 Leader 告之日志可以提交之后,提交日志。

Candidate 候选人Leader选举过程中的临时角色。会向其他结点“拉选票”,如果得到大部分的票则成为Leader。

图 9: 三个角色之间的关系图

9.2   算法流程

1. Leader Election 领导人选举:当 Follower 在选举超时时间内未收到 Leader 的心跳消息,则转换为 Candidate状态。为了避免选举冲突,这个超时时间是一个 150~300ms 之间的随机数。一般而言,在 Raft 系统中:

•   任何一个服务器都可以成为一个候选者Candidate,它向其他服务器 Follower 发出要求选举自己的请求。

•   其他服务器同意了,发出 OK。注意,如果在这个过程中,有一个 Follower 宕机,没有收到请求选举的要求,此时候选者可以自己选自己,只要达到 N/2+1 的大多数票,候选人还是可以成为Leader 的。

•   这样这个候选者就成为了 Leader 领导人,它可以向选民也就是 Follower 发出指令,比如进行记账。

•   通过心跳进行记账的通知。

•   一旦这个 Leader 崩溃了,那么 Follower 中有一个成为候选者,并发出邀票选举。

•   Follower 同意后,其成为 Leader,继续承担记账等指导工作。

2. Log Replication 日志复制:Raft 的记账过程按以下步骤完成:

图 10: 记账过程

对于每个新的交易记录,重复上述过程。在这一过程中,若发生网络通信故障,使得 Leader 不能访问大多数 Follower 了,那么 Leader 只能正常更新它能访问的那些 Follower 服务器。而大多数的服务器 Follower 因为没有了 Leader,他们将重新选举一个候选者作为 Leader,然后这个 Leader 作为代表与外界打交道,如果外界要求其添加新的交易记录,这个新的 Leader 就按上述步骤通知大多数 Follower。当网络通信恢复,原先的 Leader 就变成 Follower,在失联阶段,这个老 Leader 的任何更新都不能算确认,必须全部回滚,接收新的Leader 的新的更新。

9.3   优点

1. 比 Paxos 算法更容易理解,而且更容易工程化实现。

2. Raft 与 Paxos 一样高效,效率上 Raft 等价于 (multi-)Paxos。

3.  适用用于 permissionedsystems(私有链),只能容纳故障节点(CFT),不支持作恶节点。最大的容错故障节点是(N-1)/2,其中 N 为集群中总的节点数量。强化了 Leader 的地位,整个协议可以分割成两个部分:Leader在时,由 Leader 向 Follower 同步日志;Leader 失效了,选一个新 Leader。

4. 强调合法 Leader 的唯一性协议,它们直接从 Leader 的 度描述协议的流程,也从 Leader 的角度出发论证正确性。

9.4   缺点

1. 只适用于permissioned systems (私有链),只能容纳故障节点 (CFT),不容纳作恶节点。

表 2: Raft 和 Multi-Paxos 的比较

参考文献

[1]  Beccuti, J., and Jaag, C. The bitcoin mining game:On the optimality of honesty in proof-of-work consensus mechanism. WorkingPapers (2017).

[2]  From Wikipedia, t. f. e. Paxos (computer science). https://en.wikipedia.org/wiki..._(computer_science).

[3]  From Wikipedia, t. f. e. Proof of work. https://en.wikipedia.org/wiki..._of_work.

[4]  Lamport, L.  Paxos madesimple.  https://www.microsoft.com/en-...

made-simple/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Flamport%2Fpubs%2Fpaxos-simple.pdf.

[5]  Team, E. Proof of capacity explained: Theeco-friendly mining algorithm. https://www.coinbureau.com/ed...

[6] 杜江天. 区块链工作量证明机制中的哈希算法探讨. 电脑编程技巧与维护 _No.394_, 4 (2018), 42–44.

[7] 杨宇光, and 张树新. Review and research for consensus mechanism of block chain信息安全研究_004_, 4 (2018), 369–379.

[8] 梁斌. 从” 比特币挖矿” 看区块链技术的共识机制. 中国金融电脑, 9 (2016), 45–46.

[9] 甘俊, 李强, 陈子豪, and 张超. 区块链实用拜占庭容错共识算法的改进.计算机应用, 7 (2019).

[10] 祝朝凡, 郭进伟, and 蔡鹏. 基于 paxos 的分布式一致性算法的实现与优化.华东师范大学学报 _(_自然科学版_)_, 10 (2019), 168–177.

[11] 程书芝, 师文轩, and 刘俪婷. 区块链技术综述.

[12] 韩璇, and 刘亚敏. 区块链技术中的共识机制研究. 信息网络安全, 9 (2017).

[13] 黄嘉成, 许新华, and 王世纯. 委托权益证明共识机制的改进方案. 计算机应用, 7 (2019),2162–2167

查看原文

赞 0 收藏 0 评论 0

百度安全 发布了文章 · 6月11日

百度安全联邦计算携手观星盘 打造联合营销绿色通道

大数据时代,营销的魅力在于精准。如何利用百度技术优势,在保证数据安全的前提下,解决客户在拉新、激活等方面的精准营销需求,是我们需要思考和解决的问题。

在广告营销场景中,百度作为广告平台提供第二方数据,包括广告的曝光、点击等;广告主则拥有安装、激活、转换等更丰富的行为数据。为了能够为广告客户提供更精准的营销服务,需将广告客户的数据与百度数据联合,进行整体优化和联合营销。考虑到数据作为一种特殊资产,在数据合作过程中,广告主将面临数据安全、用户隐私、政策合规等诸多顾虑,因此广告主将用户转化等敏感数据回传至广告平台的意愿不高,这便导致广告平台无法针对广告主的核心诉求“转换”进行全链路优化,相应的广告投放效果也就无法达到最佳。

image.png

图1 精准营销需要安全连接广告平台和广告主的数据

为了解决联合营销场景中的数据安全合规问题,百度安全联手数据流通服务部使用“联邦计算”技术,为观星盘开辟“联合营销绿色通道”。在保证各方敏感数据不出域的前提下,基于“可用不可见”的安全计算,将百度观星盘数据和广告客户数据安全打通,以实现联合精准营销。目前方案已在百度观星盘平台上线,并受到客户的一致好评。

项目背景:

近年来以RTA为代表的精准广告模式在各广告平台逐步试水,观星盘作为百度营销的重要入口,希望为百度客户,特别是KA客户,提供更精准的联合营销服务,同时又保证各方数据安全合规。 2019年底观星盘、数据流通服务部和百度安全联动,使用百度安全联邦计算(Baidu Federated Computing,BFC)技术将观星盘与广告客户数据进行安全打通,在保证数据不出域、数据可用不可见的基础上,采用安全可控、分布式计算的技术方案,助力外部合作伙伴完成精准的用户拉新行动。

解决方案:

整体方案可概括为,百度观星盘与外部合作伙伴在各自的管理域中部署一个BFC计算节点。BFC计算节点具备数据管理、作业管理等功能,负责联邦计算作业的安全加密计算,其中BFC主节点仅用于协调各方计算节点,不接触各方本地数据。

目前BFC已与百度观星盘进行产品对接,可以在观星盘产品中直接使用BFC与广告客户的数据进行安全连接和联合营销,并通过观星盘将联合营销模型应用到Feed、开屏、凤巢等平台进行广告展现。

image.png

图2 百度与外部合作伙伴联合营销架构图

截至目前,已有多家客户通过观星盘和BFC进行联合营销,涵盖短视频、教育、金融、电商等诸多行业。接入联合营销服务后广告客户反馈效果良好,其中用户激活量提升近3成,同时CPA也有明显降低。此外,客户后端转化率也有进一步提升,最高可达30%。广告客户对投放效果的满意度超出预期,客户消费率大幅度提升。

此次联合营销方案具有极佳的可复制性,可迅速落地,为其他外部合作伙伴提供联合营销服务。该方案是百度安全联邦计算技术在营销领域的典型应用,通过不断的技术创新,在满足数据安全合规的前提下为客户提供更精准的营销服务,进一步提升客户满意度,同时也为百度提供一种新的联合营销模式,并受到广告客户普遍认可和接受。

了解更多:

什么是百度安全联邦计算

百度安全联邦计算(Baidu Federated Computing, BFC),高效融合多方安全计算(Secure Multi-Party Computation,MPC或SMC )、可信执行环境( Trusted Execution Environment,TEE)、差分隐私(Differential Privacy,DP)和数据脱敏(Data Masking)等多种领先数据安全和隐私保护技术,在各方数据不出域的基础上进行联合计算,获取各方所需的计算结果,全力打造跨组织数据合作“可用不可见,相逢不相识”的极致安全服务体验。

image.png
图3 百度安全联邦计算技术架构

未来,百度安全联邦计算将继续打磨安全可控、分布式计算的产品能力,深耕广告、政务、金融、医疗、工业等重点垂直领域,深化与ABC、边缘计算、区块链在资源、产品、解决方案方面的协同,更好的满足业务需求。

联络方式:

网站:https://anquan.baidu.com/page/63

邮箱:bfc-support@baidu.com

关于百度安全:

一直以来,秉承“有AI,更安全”的使命,百度安全始终倡导通过新一代技术研发与开源,实现对安全问题的快速响应和有效对抗。并致力于在全面覆盖百度各种复杂业务场景的同时,为生态合作伙伴提供技术支点及完善的产品解决方案,共同应对AI时代带来的各种安全挑战,实现产业共赢。

查看原文

赞 1 收藏 1 评论 0

认证与成就

  • 获得 28 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 3月24日
个人主页被 2.8k 人浏览