消费电子设备的安全威胁和安全需求

时间:2022-01-15 19:05:03

         关于消费电子设备的安全性,OMTP几年之前就开始了相关的工作,主要是定义了已被识别的设备的安全威胁,以及给出了可信环境的概念。工作的成果体现在几个文档上:

         OMTP Security Threats on Embedded Consumer Devices

         OMTP Trusted Environment OMTP TR0

         OMTP Advanced Trusted Environment OMTP TR1

从文档命名上可以看出,一个是安全威胁描述,另一个是可信环境,而后者由分为两个级别:TR0TR1TR0是比较基本的,TR1的安全性则更高一些。

         安全威胁方面,从攻击所需专业性、重复难度和传播难度三个方面进行了考量,从专业性上,容易:用户自己可以实现;中等:需要专业知识;难:需要专业知识和价格昂贵的设备。重复难度:容易:用户自己就可以重复;中等:需要到后街商店;难:需要专业知识和昂贵设备。传播难方面,WWW:攻破之后,通过互联网就可以传播,这种情况最糟糕;小公司:小公司可以使用信息/传播安全漏洞;大公司:大公司可以使用信息,比如克隆手机。

威胁分类:

         软件修改威胁SWMUE软件修改。关注特权代码的修改。

         软件机会主义威胁SWO:针对软件定义或者实现中的弱点,可以暴露UE的秘密或者使其不正常或非授权地工作。关注如缓冲区溢出、突破访问控制的攻击。

         硬件威胁--外部HWE:不破坏终端的完整性,通常通过UE外部的端口或者连接线来实施。

         终端注入HWT:物理威胁,要打开UE的外盒,包括探测PCB的总线或者挂在PCB上的packege的引脚。它包含物理上移除某个组件,而该组件的完整性不会被破坏。

         硬件组件攻击HWC:会影响到组件的物理完整性的威胁或攻击,包含但不限于SoC,内存和PCB。它包含物理上移除某个组件,而该组件的完整性会被破坏。

         硬件克隆,组件替换,组件增加CLO:替换UE的一部分或者整个UE的威胁。包含但不限于替换SoC或内存,以及生成一个UE的拷贝。

注意这里的威胁主要是针对系统和硬件的,并没有特别针对某个应用,比如在android中,应用访问通讯录的API是开放的,用户在应用安装的时候同意这种访问权限,应用就可以访问了。从计算机安全的角度来看,是否能防范缓冲区溢出,是否能防范获取系统特权才是其所关心的重点。对于窥探用户隐私的应用的防范,则需要在保证系统安全的基础上,定义特定的资产(比如通讯录,通话记录等),然后再对这样的资产实施相应的保护机制(如访问控制)。但是这样的安全需求还不是OMTP关注的重点。

         OMTP TR0是比较基本的可信环境需求的描述。所关注的威胁,主要是非安全的软件攻击,调试端口的攻击,不破坏设备物理性的硬件攻击(如芯片间通信信号的探测),更换数据存储元素或修改其内容等;不包含芯片级别的攻击(如芯片探测),旁路攻击(电源,时序等),在芯片间总线写入等。

         可信模型的基础是安全属性,包括真实性,完整性和保密性,以及授权方。硬件资源就可以包含:完整性保护的硬件,保密性保护的硬件,兼具完整性和保密性的安全硬件,以及安全存储(也包含完整性的保密性的属性),以及运行时要检查完整性的存储等。而存储的安全属性的保护又可以由普通OS,安全OS以及硬件分别来完成,也就是说,这是一个多级安全的可信模型,从底层到上层,分别有硬件、安全OS和普通OS来分别完成其安全责任。类似的,软件则定义了已被认证软件,授权软件和受保护的软件,以及普通软件。

         安全需求分为总体安全需求,调试端口保护,移动设备IDSIMLockDRM,安全启动,安全绑定,安全Flash更新等需求。这是针对TR0列出的威胁模型,所需要满足的需求。比如,对于硬件唯一密钥(Hardware Unique Key),要求一个ME首先要支持一个HU密钥,然后规定密钥应该如何产生,应该被谁访问,是否可以修改,密钥长度至少是多少,密钥的用途是什么,对于保密性,完整性,真实性的保护,应采用什么样的算法和加密强度等。再比如,对于安全启动的需求,可以认为在硬件控制完整性的存储中的组件是经过了验证的(就是安全ROM中的loader),然后这个loader装载后续的软件组件的时候,都要对其做完整性和真实性验证,这样就形成了一个安全启动链,从根开始一级一级地验证并加载组件,以保证整个系统的安全。对于需要保证的是:boot loader的真实性和完整性;如下资产的真实性和完整性:移动设备的ID,报告和保护移动设备ID的软件组件,实现SIMLock机制的软件组件;操作系统核的真实性和完整性。这其中有些是硬件完成,有些由软件完成,即上面提到的分级安全。

         OMTP TR1的威胁模型比TR0要具体和复杂些。除了前面考虑的威胁类别,还特意强调了:

         用于访问内存的硬件模块,比如一个DMA模块,可以不通过CPU而直接去访问某些资产,也不会被MMU的用户/特权模式所限制;

         用于显示内存和交互数据的CLCD

          通过移除电池或移除外部存储卡的方式来绕过安全。比如在设计得不好的DRM方案中,当播放歌曲到最后才减少播放权限次数,如果权限次数存放在外部存储卡中,就有可能通过移除外部存储卡来获得无限次的歌曲播放;

设备关机时替换Flash芯片,这就可能把整个存放在flash中的安全路线完全替换掉;

         通过总线监控来获取秘密;

         修改外部RAM中的内容;

         设备开机时替换Flash芯片,比如两个几乎一样的flash芯片,其中一个是有真实性保证的,在设备运行的某个时刻使用没有真实性保证的flash将其替换,两个flash的内容基本一致,除了其中的DRM权限对象。

TR1的安全需求又分为profile1profile2,后者比前者要更加高级一些。TR1从如下几个功能模块来描述:安全存储,可信执行环境(TEE),灵活的安全启动,GBA,运行时完整性检查,UICC(安全元素,SE)的安全交互,安全用户输入输出。

安全存储是在终端上保存敏感对象,保护其完整性和保密性的推荐机制,主要保护数据和密钥。

         可信执行环境提供安全的软硬件设施来支持应用的安全执行,保护诸如内存管理,执行和应用程序管理,执行环境的交互,API等,在设备中处于一个很低的层次,注意它和普通的执行环境(比如Android)是分离的。

         运行时完整性检查是确认设备所做的事情正是其该做的事情,以及关键数据的完整性保证机制。它保护如IMEISIMLock状态等。

         安全用户输入输出确保呈现给用户的任何东西都是真实的,而不是被恶意软件篡改过,以及用户输入不被窃取。其实国内银行的二代key就是完成了这个保护。

           GBA本来是一个框架,用来在USIM和运营商之间建立安全联系,目的是为应用层服务,比如SP可以从运营商请求密钥来与用户的USIM建立联系以提供服务。在终端上的密钥访问,存储机制等均需要安全保护。

         灵活安全启动比TR0而言,最大的区别就是增加了启动代码是可以更新的。

         与UICC的安全交互,保证了设备与UICC之间的数据传递是安全的而且能防范其被修改。

 

         为实现以上描述的安全需求,首先需要芯片级别的支持,芯片能够提供诸如HU密钥的保护机制,然后就是在软件上考虑如何充分利用硬件支持的特性,设计合适的安全方案和安全机制来满足安全需求,比如数据和密钥存储在什么地方,代码的完整性如何验证,应用的认证性如何验证,应采用几级密钥体系等,这是一个复杂又渐进的过程。