Warning: A non-numeric value encountered in /www/wwwroot/www.beanpodtech.com/wp-content/themes/Divi/functions.php on line 5841

上一期我们介绍在LPC55SXX系列安全芯片和ISEE-M系列可信计算环境为基础物联网安全可信系统整体解决方案。上一期还没看过的同学,欢迎进入点击链接了解详情~

这一期我们主要介绍对可信安全要求下的物联网终端生产产线安全问题的思考和对应的解决办法。

物联网终端生产安全问题

本系列第一篇我们讲到了ISEE-M的基本安全原理。其安全特点除了隔离,还有安全启动、密码服务、安全存储等。后面的三个特性都依赖于密码学技术,密码学技术有两大安全要素分别是“算法”和“密钥”。我们常用的密码算法由国内国际上顶级的科学家设计,从理论上确保其抗攻击能力非常的优秀,除非对算法本身被理论突破,在实际使用中,算法本身并没有巨大的使用风险。另外一个要素“密钥”的安全性以及对其的保护,生产实践中就凸显得更加重要,密钥泄露或者密钥保护不当,对业务来说是毁灭性的。

第一种情况,分析一下密钥本地保护的必要性

在很多实际的物联网系统中,很多技术人员设计了一套完整的PKI架构,采用了先进的TLS通信协议,最后实现时把密钥硬编码在代码里,或者明文写在本地文件中。做过攻击或者安全测试的人都知道,拿到一个评估项目最开始首先就是逆向查看代码中是否存在硬编码的密钥,以及本地是否有存储的密码文件。测试人员知道这些信息能做什么呢?可以做的事情很多。例如,利用该密钥自己伪造加密业务发起通信,解密本地机密数据文件,篡改本地密钥绕过核心验证等等。以上这些的方法都可以使得前期安全设计人员精心构造的安全大厦坍塌。

第二种情况,分析一下密钥的安全预分发的必要性

假设有一个物联网系统,有云端C和终端M,采用了TLS安全通信协议。 设想几种情况:

1、如果没有提前将CA的根证书部署到两个端中,二者是没有办法建立互信的,因此也就没有办法建立安全通道。如果通过在线的方式传送CA根证书,则路由中间攻击者可以轻易伪造篡改,最终使得安全通道失效。

2、如果我们要做C端对M端的认证,则需要M端对通信数据做签名,如果此时M端自行产生公私钥对,并用这个私钥签名,那么C端该怎么校验这个签名? 使用这个对应的公钥?把公钥传递到C端?然而这样是存在问题的!我们知道,在这个阶段,通信初期还没有任何的安全保障,如果在这种情况下把公钥传递给C端,需要确保这个公钥不能被篡改,能做到吗?显然是不可能的。

综上,我们需要有一套生产产线密钥管理工具,这套工具必须能够完成在生产阶段将必要的密钥以及安全配置预先部署到特定安全域中。这样才可以确保物联网整体系统中各个部分在出厂后,上线后它们之间都有一套基本的信任关系,才可以安全的通信,才可以安全可信的提供业务服务!

ISEE-P 生产线配套工具

ISEE-P生产线配套工具是我们LPC55XXX系列安全芯片和ISEE-M可信技术环境的物联网系统整体方案的组成部分。这套工具主要解决前面提到的一些问题。系统采用了硬件加密机,确保在整个生产环节中所有的敏感数据都不会泄露。同时,也为物联网领域做了量身定制,提供较高的可塑性,可以根据不同的安全级别提供不同的加密方案,提供在线、离线的部署方式,提供ISEE-P加密机自行产生各种业务根密钥的功能,也支持由客户产生后通过安全接口导入到ISEE-P中的方案。

ISEE-P的密钥部署技术保障

前面我们提到了为什么要有生产线方案, 另外我们知道物联网行业的多样性,必然导致各种不同类型厂商的工厂环境的多样性,安全条件、管理条件、人员素质的多样性。所以,整个环节中,密钥在传输过程的各个环节中都可能有人为的接触,都有可能在传输通道中间加入节点截取密钥数据。

我们基于前面的安全问题打造了ISEE-P,一套适用于各种环境的安全生产线配套方案,即考虑到了非技术人员的主观故意或者失职导致的密钥泄露,也考虑到了高级黑客技术的攻击情况。我们举几个关键的点来看一下ISEE-P是如何保障生产线密钥部署的安全的。

  • 关键节点中的通信加密

从设备制造商节点,到ISEE-P的加密机节点,再到设备节点,三个节点之间都设计了端到端的加密通信机制,确保端的安全域之外不会有密钥的明文存在。通信的加密机制采用最先进的ECDHE密钥协商机制。

  • 关键节点中的信任保障

前面提到的ECDHE需要依赖于端和端的互信,以防止中间人攻击。ISEE-P在最高级授权情况下在各个加密机之间植入安全认证证书,以及在ISEE-M的编译部署阶段植入加密机的根证书。另外,设备端的证书的信任依赖于加密机的计数策略和ISEE-M内置的安全策略,确保生产过程中不会有不符合安全规则的设备产生。

有了上面的基础密钥部署的技术保障,我们在实际生产中就可以按照各方的不同安全要求来保护各方所需密钥的部署。下面简单列举中典型的情况!

  • 设备根密钥

设备的可信计算环境ISEE-M中调用真随机数发生器产生一组公私钥对,可根据项目情况和硬件情况产生ECC密钥或者RSA密钥,甚至也有可能是对称密钥。在ISEE-P安全可控的环境中签发设备证书。该密钥是依赖于ISEE-M构建安全体系时的基础,一切PKI架构的保障。

  • 系统密钥RoT根

该密钥根是可信计算环境的基础保障,用来校验整个环境的完整性、有效性、防伪性。该根通常为根证书形式或者公钥的Hash值形式,部署过程中重点要保护其完整性和真实性。由前面提到的设备根密钥提供保护下发,并烧写固化到硬件OTP区域。

  • 镜像加密密钥

为了防止终端设备中知识产权泄露,固件通常采用加密,固件的加密依赖于出厂之前一定要有一个可用的密钥。该加密密钥由前面提到的设备根密钥提供保护下发,并写入设备内部的安全模块中。

  • 业务应用级密钥

这个级别的密钥可能会有很多,例如OTA、远程遥控等,有的业务方希望自己的密钥也在最安全可靠的情况下部署,例如支付类业务、身份识别类业务的根密钥也都是在设备的生产环节部署完成的。这个级别的密钥由前面提到的设备根密钥提供保护下发,并写入设备内部的安全模块中。

 

借助豆荚科技在移动设备领域,从工厂产线阶段,将密钥写入到终端设备,再将设备信息上传到后台服务器,建立了端到段的整套的产线方案,并已应用于微信支付、支付宝、谷歌 Key导入、DRM Key导入等众多领域。此方案避免在生产过程、终端设备产生安全信息泄露、既满足了方案厂商和业务方的安全需求,又保护了用户的重要数据,目前已应用于近4亿台终端设备。这些积累的产线生产经验借鉴到物联网领域,为万物互联的安全保驾护航!

ISEE-P是LPC55SXX系列安全芯片和ISEE-M系列可信计算环境为基础物联网安全可信系统整体方案的重要组成部分,ISEE-P也是可定制的软硬件及服务的生产解决方案。可以提高物联网设备生产环节的效率、极大的保障设备安全性、提高对业务方安全要求的适应性,适应物联网设备生产阶段不断发展提高的、复杂多变的安全可信要求!

 

我们还将继续推出此系列的后续文章,敬请持续关注豆荚科技公众号。