安全嵌入式系统:挖掘可信根
来源:    发布时间: 2016-12-13 10:10   377 次浏览   大小:  16px  14px  12px
“我能相信我的系统吗?”这一般通过在定义好的边界上把系统分开来解决:最常见的是,我们使用的各部分是应用软件;操作系统、启动代码和固件;以及硬件。一般而言,如果我们能够定义这些分层之间的接口——从而定义了我们在每一层面上能够信任什么,如果我们能够信任设计的每一层,那么就能够信任系统。

作者:Ron Wilson


很多嵌入式设计必须要保证能够正确的工作。出现故障会导致对人或者财产造成不可挽回的损失。直到最近,通过仔细的设计和硬件可靠性才解决了这一问题:如果软件和逻辑正确,没有硬件失效,系统会正常工作。


但是,今天,我们生活在计算机网络空间暗战的年代。如果您的系统要工作,那您就必须假设从烦人的黑客到犯罪团伙,甚至是大肆耗费政府资金的实验室的所有人都会攻击它。为能够保护您的系统,您必须确定您能够信任什么——最终,是谁。这不是一个简单的任务,还有人认为,甚至是不可能实现的任务。但是,您必须去做。


定义一种分层结构

问题“我能相信我的系统吗?”本身就是难以衡量的。为能够抓住这一问题的关键,我们需要把基本的大问题分成很多更小、但是较难的问题。这一般通过在定义好的边界上把系统分开来解决:最常见的是,我们使用的各部分是应用软件;操作系统、启动代码和固件;以及硬件。一般而言,如果我们能够定义这些分层之间的接口——从而定义了我们在每一层面上能够信任什么,如果我们能够信任设计的每一层,那么就能够信任系统(图1)。



图1 把系统分成层,显示了定义可信的接口。

可信只能是包容性的。如果您的目标软件非常好,您必须还要信任操作系统(OS),以便正确的响应其应用程序接口,不会损坏您的代码。对此,您必须相信在启动加载程序中没有可能损坏OS的恶意代码,硬件中没有可能控制系统的特洛伊木马。某些架构师把这一递归问题描述为找到可信根。但是,这种比喻可能过于乐观了。在6月份的设计自动化大会(DAC)的安全系统小组讨论中,Intel资深首席工程师Vincent Zimmer提到了发言人虚构的一个故事,地球是乌龟背上的一个盘子。询问乌龟站在哪里,发言人回答说,“它是乌龟;下面一直都有乌龟。”


最终——如果递归最终结束在某一地方,可信不是终结在一个设计上,也不是一种方法上,而是工程师,人类自己。至少一些专家是这么认为的。


可信源

所有这些带来了一个明显的问题:您怎样才能信任设计中的某一层?术语“可信根”是指,您可以向下找到一些最终的可信层,然后您就安全了。但实际上并非如此。


一般而言,只有很少的方法能够在设计层中建立可信,无论是硬件还是软件。


■ 您可以从您选择信任的源中获得设计

■ 您可以正式的从可信源中获得设计

■ 您可以提供冗余,这样,例如,两个不同的设计在执行之前必须在功能上达成一致,或者一个设计实际测试了另一设计的输出。

■ 您可以限制功能的范围,这样,它实际上不能影响您要保护的任何东西。


当然,一旦您信任了设计的某一层,您必须在底层建立可信,在其中,物理上可以改变设计行为——一直向下。有必要更详细的检查这一过程,一层一层的。


可信应用

让我们从应用软件开始——因为攻击者可能就从这里开始。Square的移动安全主任Dino Dai Zovi在DAC小组讨论中谈到,“有些地方总是1999。黑客并不需要进入您的硬件。要进入您的软件仍然非常容易。”在接下来的研讨中——这是关于汽车安全的,Theia实验室的逆向工程专家Craig Smith强调了一点。他说,“系统达不到无懈可击。但是,今天,这太容易了。缓冲溢出攻击在嵌入式系统中屡屡得手。毕竟,这次根本不行了。”


几种因素凑到一起使得应用程序非常容易受到攻击。一个就是不重视。管理员仍然非常重视调度和编码效能,而不重视安全。Jeff Massimilla是通用汽车的首席产品计算机空间网络安全官,在汽车研讨时提醒说:“如果安全不提升到董事会层面上,就得不到所需要的资源。”


而且,能否访问也是个问题。很多嵌入式系统连续运行,在现场部署后无法访问这些系统进行远程更新。您不能对变电站或者发电厂进行离线软件更新。Massimilla注意到,也不能更新行驶中的汽车的代码:“汽车不能离线。”所以,当您发现已经部署的系统有漏洞时,您可能也会无计可施。


Massimilla说,另一个问题是规模。“我们大约有30至40个电子控制单元(ECU)来保证新车的安全。”Delphi的CTO兼执行VP Jeffrey Owens同意这一观点。“现在的汽车有50个ECU,一亿多行代码。这比F-35战斗机复杂4倍。”规模如此庞大的代码在模块级无法使用形式验证工具,也不可能实现完全冗余。汽车制造商不会仅仅为了安全就增加ECU。因此,实现可信的所有方法都非常困难。


而规模也意味着,将重用大部分代码。这就有可能一次建立对一个模块的信任。汽车安全标准ISO 26262提供了方法对可信IP模块中建立的代码认证其可信性。


ISO 26262规定,您可以把满足某些严格标准的组件放到一起,构建兼容系统。例如,开发的组件本身符合26262标准,包括了形式检查、严格的可追溯性,以及可信工具等要求。也可以接受在有26262之前开发的组件,这是因为它们已经在现场得到了广泛应用,而且没有出现故障。所有这类组件已经被认证为与其所设计的具体系统环境安全无关,因此被称之为脱离环境安全元素(如果您愿意,可以简称为SEooC)。


由于它们脱离了周围环境,因此,每一SEooC必须包括形式安全手册,列出IP安全使用的要求和假设。对于在26262环境中重新使用SEooC的任何人而言,手册都是强制性的。其要求还适用于另一文档,开发接口协议(DIA)——管理26262兼容设计的多方约定,多方参与其中,定义了在整个过程中,谁担当什么样的角色,承担什么样的责任(图2)。



图2 集成一个可信组件需要安全操作和可信方法。

ISO 26262源自汽车标准——要求比最初的IEC 61508等工业标准更具体,比大部分嵌入式设计的临时方法更严格。但是,由于越来越多的嵌入式设计人员面临被攻击的实际成本问题,26262的影响扩展到了其他应用领域。


这几乎是在大规模应用软件中建立可信的唯一方法。而操作系统和固件的情况更复杂。


OS问题

操作系统和固件遇到的很多问题都与应用代码相关。但是有一些明显的不同。首先是,很多设计许可了整个操作系统——或者整个开发平台,而不是编写自己的。很难找到比小型实时内核程序更符合SEooC质量的安全方法了。其次是工作软件和固件通常需要在现场进行更新这一事实。回想一下您是多么频繁的更新Windows。第三,系统开发人员一般把OS看成黑盒,根本不知道其代码,怎样工作的,也不知道其中会有什么风险。


系统软件的一种主要发展趋势对安全实际带来了威胁。Georgia技术公司嵌入式计算特聘主席Marilyn Wolf向参加DAC的听众提醒说,“开源并不是一种可靠的方法。”在与ISO 26262 SEooC无关的一次网络研讨会上,Mentor Graphics嵌入式部门首席安全官Robert Bates指出,“现在的开源软件绝不可能成为SEooC。基本上,忘掉Linux吧。欧洲尝试将Linux版本纳入汽车安全完整性等级(ASIL) B [26262评定中第二最低等级]中,但是这需要两到三年的时间。”


专家建议与客户协商,减少系统的ASIL,或者隔离OS,这样,物理上只能影响不关键的功能。例如,在只显示信息的用户接口上使用Linux是可以接受的,前提是只要这不影响控制环路。否则,其他可选方法是使用现场经过验证的内核程序,从SEooC或者同样安全的组件中开发OS,编写符合26262标准的定制内核程序,或者在裸金属硬件上运行应用程序。在多核系统中,可以在两个或者三个内核中运行不同的操作系统,使用重复检查或者投票方法,但是仍然需要仔细应对两个OS被攻击的情况。


更新呈现出一些新问题。更新应达到SEooC质量——即,即使是建立更新的团队并不了解您的系统,您也必须确定更新中的任何东西都不会让系统出现漏洞。在您替换系统中的任何代码之前,您要肯定新代码来自合法有效的源,您所接收到的与源发出的应完全一样。一般而言,这就要求采用很强的哈希码对更新加水印,有获得认证的版权方签名,并加密。您的系统必须接收更新,解密,在安装之前验证签名和哈希码。


但是,您会信任这一解密和检查过程吗?对此,您必须信任进行这一工作的软件,以及执行代码的硬件,包括,例如,硬件加密加速器和片内总线。这类问题把我们从边界带到了安全硬件内。在这一环境下,概念是相同的——可信源,但是要求更高。设计和更新硬件会很难而且耗时。工具链更复杂,需要多方参与。攻击可以是物理的,也有可能是逻辑的。由于很难攻击硬件而且成本高,因此,防御者的确面对的是最熟练而且最耐心的对手。


保护硬件

可信硬件必须从可信规范开始:能够追溯设计的所有未来单元的需求文档。在明确分开系统能够干什么,不能够干什么之前,您不会认为系统是安全的。


原理上,需求这种形式是指允许进行形式等效检查和声明测试。但是,在实际中,需求一般被表述的模棱两可,没有采用开发人员的固有语言,有时候会参考从未经过全面特性测试的前一代硬件。在这类项目中,最重要的是硬件开发人员和系统开发人员针对出现的所有问题及时沟通——凸显了26262的DIA的重要性。您不会希望推出的SoC带有“块移动是怎样执行的?”或者“在哪些条件下,存储的密钥是可读的?”等悬而未决的问题。


从达成一致的需求中,设计能够理想的通过连续的抽象级,在每一级采用可信工具,进行等效性检查,声明测试和检查等。这一过程不但要能够探测到无意的错误,还要探测到故意的阴谋破坏。是的,我们的确处于阴谋破坏的现实环境中。在DAC安全研讨中,BBN技术Raytheon公司的Lisa McIlrath解释说:“我知道的确有对某些人的Verilog进行持续性攻击的情况,因为我就这么做过。一些攻击点是在CPU内核中,特别是,指令解码逻辑。您不得不有可信Verilog。”


工具也有同样的问题,就像IP。很显然,IP适合SEooC的讨论——但是设计工具呢?综合、布局布线,甚至是时序工具都有机会修改设计。我们还是处于现实中:在他的DAC主题演讲中,Cadence总裁兼CEO Lip-Bu Tan说,“安全是满足了客户需求后的另一项要求。我们积极工作以保护我们的工具和IP的安全。我们知道,我们的客户非常担心。”


这类安全不能限于一种工作模式。通过调试和测试模式能够成功的攻击器件。JTAG端口通常会为使用方呈现出相当多的数据。有侧面通道攻击:监视内核供电电流,以探测代码执行流,例如,正如一篇DAC论文所演示的,把误码注入到文本字符串中,以找到加密密钥。最后,还有物理攻击:降低供电电压,迫使出现可供利用的例外,或者对SoC进行物理分解和逆向工程。


在极端情况下,有人会采取极端手段。您可以把设计分成两块——彼此之间是不能理解的,在不同的代工线生产,只是在3D模组中装配起来。您可以采用误导布局和假的或者模棱两可的功能来打乱设计。这些手段看起来非常难而且成本高,但是,如果其他的选择是国外势力控制了您的防空系统,那么,这类手段就很合理了。实际上,一些严肃的研究人员已经建议将其用在风险非常大的系统中。


毕竟,这些考虑会涉及到投片。然后——您真的信任能够接触到设计文件、测试文件和晶片的代工线的所有人吗?您的装配和测试厂家又会如何呢?他们都会在您的硬件中产生被攻击点,或者对您的设计进行逆向工程。如果全球政治或者经济形势出现了巨变,您仍然会信任他们吗?


保护最重要的

知道了这些之后,您是不是想放弃了。从芯片规范直至应用支持,要保护设计的每一阶段在经济上不可行,在技术上也是难以实现的。在安全研讨中,Typhone的CEO Siva Narendra同意这一观点:“不可能每一层都建立信任。”好在这通常并不是必须的。


Dai Zovi注意到,“攻击者并不是只会蛮干的恶人。他们会在乎不同的风险。他们慢慢的扫描,如果所能得到的不符合预期,他们就不会花功夫进行攻击。


对于攻击者而言,攻击的成本的确不同。您可以通过共享件工具,适用的PC,一些小技巧,深入到很多应用程序和操作系统中。真正持续的攻击需要汇集来自他人未受保护系统的僵尸网络,或者把一些图形处理单元(GPU)放到一起。Narendra向不安的听众明确了一点,“一千个图形卡加上9个小时的时间足以攻破任何64字符的密码。”另一方面,对SoC进行逆向工程需要偷几块可用芯片,使用价值数百万美元的离子束工具和电子显微镜。


总是希望从自动售货机上免费钓到苏打水的攻击者可不愿意投入这么多。但是一个犯罪团伙有可能投入数万美元,切实威胁到电网,而电厂则不得不花费数千万美元进行修复。(不幸的是,现在他们能攻击的不止于此。)一个国家可能投资建设研究实验室,去攻击潜在敌人的军事或者民用设施的关键系统。原则上,您只需要保护设计不受攻击而避免经济损失就可以了。


然而,对于很多嵌入式系统,很难估算风险和回报。您值得一直让家里的热水壶不出故障吗?全国的保险公司值得让成百上千个热水壶不爆炸吗?从一个节点开始大规模的攻击整个网络,攻击一个微不足道的设备的投入会远远大于设备本身的价值。


尽管有这种不确定性,关于本文开始时的问题的最佳答案可能就是投资回报。一个理性的攻击者到了某一层不会再投入更多深挖下去的时候,您就可以在这一层停止挖掘可信根。对于很多系统,这意味着要仔细的编写应用程序,采用基于ARM的TrustZone等进行安全更新过程,还要有非常安全的密钥存储。对于关系到生命安全的交通运输或者工业系统,以及一个国家的能源和通信基础设施,则意味着ISO 26262或者其他类似的。对于国防系统,则意味着把设计分开,打乱设计,多个国内的代工线,以及正式成熟的代码等。