百度安全：AI是系统工程 需要真正开放的安全护航

　　毋庸置疑的是，人工智能时代已经到来。有数据显示，到2020年，会有500亿台物联网设备在全球部署。埃森哲预测，人工智能可能将劳动生产率提升40%，让人们更有效地利用时间。到2035年，人工智能将让年度经济增长率提升一倍。

　　但是，所谓“螳螂捕蝉，黄雀在后”，AI既能被用来提升效率，也能被黑客用来提升攻击技术，有更多途径窃取用户隐私。前段时间各种智能电视被破解，摄像头变成客厅监视器;某品牌智能扫地机器人被曝出存在高危漏洞，变成家庭“间谍”等安全事件频发。

　　网络安全成了这些智能设备的“阿喀琉斯之踵”。

　　危机四伏的AI生态

　　在笔者看来，移动互联时代，无论是终端、云端、传输通道，最终保护的都是这整个网络生态中的数据，这些数据既有企业和用户的隐私，也包含了账户和密码等。在AI时代，大抵相同。所不同的是各种IOT设备的多样化，身份认证加入了生物识别，语音输入需求更多地取代了手动输入。但他们的工作方式依然是智能终端与云端的各种通信。

　　根据百度安全的总结，AI的安全既包含传统安全层面，比如AI系统的硬件、软件、框架、协议等，也包含AI自身层面的安全，比如错误地引导机器学习系统，以达到攻击者的目的，或者破坏机器学习的样本，让机器学习得出错误的结果。

　　在最近的GeekPwn极棒破解大会现场，百度安全实验室的研究员只用一张打印的A4纸晃了晃，就成功秒破了某安卓智能手机的人脸识别认证系统，虹膜和指纹也相继被破解。AI时代，人脸识别、指纹密码、人眼虹膜认证等生物认证方法，取代了传统的密码。很多人认为生物识别的唯一性保护了我们的隐私。但事实上， 这种想法实在过于简单。要知道，当你成功把自己变成一个活着的人体密码的时候，也就成为了黑客的重要“资源”。

　　云管端一体化的AI安全方案

　　在这次OASES联盟成立的发布会上，百度安全宣布向联盟成员开放了其在AI生态上的多项安全能力。官方的说法是，希望在智能终端领域，通过专利共享、技术开源、标准共建，与联盟合作伙伴共同推动安全技术与服务的应用落地，共建安全的AI 时代。 


　　将这次开放的能力进行梳理(如图所示)可以看出，这是百度安全针对智能终端系统给出的全面的安全方案，包含了“云、管、端”的各个环节。这些方案里面，也结合了百度安全的大数据安全能力，以及机器学习实践经验。

　　终端层面的安全

　　在终端层面，首先要保证的是系统安全。因为一旦系统被攻破，就等于给智能终端的安全来了个釜底抽薪，即便上层的应用安全做得再好也是徒劳。但这恰恰是智能系统的“顽疾”。以往的安全修复，需要系统厂商先打补丁、升级系统，终端厂商再进行修复、版本升级，最后终端用户升级智能终端的系统。这个修复链条非常长，收敛的速度甚至长达几年。加之智能系统碎片化严重，市面上有2万多种设备型号，安全根本无从保证。更要命的是，在这个过程中专业的安全企业是缺位的，即便是发现了高危漏洞也无从“插手”。

　　针对这个问题，百度安全研发了KARMA自适应内核漏洞热修复方案。它通过五大策略，最大限度地保证了系统安全，避免系统漏洞被黑客利用：从逻辑层阻断攻击，提升自适应性;使用内存安全语言编写安全补丁，防止补丁开发者失误导致系统崩溃;对待修补的内核进行语义聚类，并非只有二进制一致才施加修复，进一步提升自适应性和安全性;方案设计了修复分级策略，进一步提升方案的自适应性;生态共建，以开放、联合、协作的模式去合力修复漏洞，打击黑产。

　　目前，KARMA已经在1100多个不同安卓系统版本进行了系统化验证测试，并且在某些主流智能终端中应用。据了解，它可以支持目前市场上绝大多数安卓设备，同时还适用于传统桌面、服务器Linux的修复等。它可以支持100%的漏洞修复，其中93.4%可以自适应修复，并且对性能几乎没有影响，不影响用户体验。

　　终端层面的另一大问题是应用安全。但是现有智能终端应用的生命周期缺乏联动，开发者、应用平台、手机厂商、安全厂商相互隔离。这一隔离不但影响了安全信息的互通，也造成了诸多限制，引发了新的安全问题，比如Android App Store 不允许开发者更换签名证书，如果开发者私钥被偷窃，他只能继续使用这一私钥，眼睁睁看着偷得私钥黑客发布冒名顶替的恶意App。应用开发者其实早就意识到了签名束缚之痛，只是目前应用较为广泛的签名证书更换手段(提示用户安装新证书签名的新版本应用，安卓5.0以上可以自动升级等)，要么用户体验极差，要么存在降级攻击等风险。

　　为解决这个问题，百度安全开源了OASP应用签名安全方案——一种更安全、灵活的密钥证书管理方案。它首创了应用状态在线查询机制，是一种生态联防、去中心化的安全方案：开发者能及时提供应用状态;安全厂商能大规模扫描监控签名信息生成信用信息，并在端上结合信用信息判断App是否恶意;应用商店可以收纳开发者提交的应用信息，并定期下架有问题的App;设备厂商则能通过OASP的签名机制进行额外的安全校验。

　　传输层面的安全

　　终端设备和云端服务通信的过程中，传输通道的安全性至关重要，一旦被黑客恶意劫持，设备和云端服务器的数据也就都处在风险中。而现在普遍应用的TLS/SSL方案是基于非内存安全语言编写，容易被黑客利用内存安全漏洞攻击，而且未来也面临着被量子计算机破解的威胁。

　　而百度安全基于内存安全技术的下一代可配置嵌入式安全通信协议栈MesaLink，在语言层面提供内存安全保障，算法层面提供后量子密码对抗能力。这就使得网络传输可以避免OpenSSL“心脏流血”等高危漏洞隐患，并且能对抗量子密码学攻击，进一步增强网络传输层的安全。在MesaLink的保驾护航下，AI系统的通信有了内存安全和抗量子破解的双重保障，黑客很难再通过内存安全漏洞和量子计算机技术通过网络通信层攻击进入AI系统。

　　云端的安全

　　云安全都快成了老生常谈的话题。不过现在的云端防护引擎存在着一定缺陷，比如它们大多依赖请求特征。一方面，要适应千差万别的后端应用，以及它们对协议的处理方式，本身就很困难。另一方面，面临一些新型攻击，防御引擎需要及时增添规则，较为被动。最后，防护引擎只要看到符合特征的请求，就会产生报警，并不知道黑客是否真的攻击成功了，所以误报率比较高。

　　自从Gartner提出自适应安全架构之后，得到了业界的一致认可。百度安全最近发布了OpenRASP开源自适应安全解决方案，保护引擎集成在了应用内部，在应用完成协议解析后，才开始检测攻击。

　　这与传统的安全防护解决方案有什么差别呢?首先，传统防护产品主要依赖请求特征，OpenRASP是通过监控应用的执行逻辑和行为来实现防护;其次，OpenRASP可以实现应用的热补丁，比如可以永久免疫Struts系列漏洞;最后，OpenRASP实现了编码规范检查、服务器安全基线检查，这也是传统防护产品无法实现的。OpenRASP和KARMA分别在云端和终端两侧为智能终端产品和服务提供自适应安全保障能力。

　　未来的AI攻防：需要真正的生态开放

　　AI是一把双刃剑，用在安全专家手里，能够更快、更高效地做好防御。将AI用于安全领域，在感知层可以提升用户体验，认知鉴权由“知”(密码)、“有”(U盾)到“是”的转变;在执行层，AI可以提升安全攻防对抗的能力，无论是网络空间安全还是业务安全;在战略层，安全专家角色实现由人到机器的转变，AI自主进行攻防对抗。而将AI用在黑客手里，就可能造成“永恒之蓝”那样席卷全球的灾难。

　　然而，AI是一个大的生态系统，它的安全也是复杂的多层面的。任何一个企业都无力涵盖所有。这也正是OASES联盟的价值所在。它希望针对AI安全能够发动整个产业链的力量，联合终端厂商、安全厂商和研究机构，通过生态开放、联合的力量，保护各种智能设备的安全，最大化避免AI生态出现安全和隐私的灾难。据悉，百度安全已经将上述的云管端安全方案对联盟内开放。

　　作为一个技术型的生态联盟，它跟以往联盟最大的不同之处就在于实现了真正的开放，不仅是提供单方向的服务，而且是核心基础技术开源，专利共享。这就打消了产业链上的顾虑，有效地推动了核心技术落地，推动联盟之间的合作。

　　AI时代，百度安全寄希望于行业联合和技术创新，让安全的天秤向防御的一方倾斜一点，再倾斜一点。