下载掌阅APP，畅读海量书库
立即打开
能想到搞智能电视安全功能点工作的大概时间点为：
图 113
起因：可能有一个起因是更加早，但这个起因只是听说，并没有实际证据证明。
某品牌的机顶盒（还是电视的）首页突然被人篡改，出现某轮功的页面，领导层留意到了这个事件，并开始讨论和决定谁来牵头搞这个事情，可能是由于本人喜欢具有挑战性的工作，也由于过去的工作成绩不错（获得很多奖），所以智能电视安全工作就落到本人头上了。
有证据的工作起因如下。
现在都能够想起，当初做产品的网络安全的这个岗位的原因倒是公司收到了几家公司的智能电视机安全检测报告。
这些报告是开启电视机软件安全工作的起因，特别是当时研发领导具有前瞻性和社会责任心也比较重，所以这个工作就由这个原因而开展起来。
图 114
还记得 2018 年的 4 月应邀参加一个论坛，叫“AI时代智能电视安全新挑战”，在会上，某个单位提出了智能电视机的很多网络安全、信息安全的问题。
图 115
可以看到电视机系统在专业的安全人士眼里是存在的非常多的安全问题的。
图 116
可惜去参加这个论坛的，大多级别不会太高，所以这次会议并没有引起多大的浪花，主要是大家都还没有被伤过痛过。这次的论坛，倒是让本人在互联网安全的路子继续走了下去。后面才知道，这是几个有名的安全单位想在智能电视机这个行业开辟安全领域而举行的论坛，想先把水搞混，只是没引起多大的浪花，后面就不了了之。
后来的一段较长时间后，国外出现了一起对自身影响很大的电视高危漏洞事件，现在还能够在网上大量搜索到该事件。
图 117
而之所以能形成事件是因为当时是没有有效的接收安全漏洞和处理事件的手段，一般公司接收安全漏洞和事件最省钱、最快捷、较通畅的方式就是通过Security邮箱，这个事件形成之前，黑白帽子也有给这个邮箱发过邮件，但迟迟得不到回复，所以就在博客发了出来。在博客中发出来后，还等了很长一段时间，才有隔壁单位发来消息，说电视机漏洞在博客中被公开而迟迟没有处理引起了各方的关注。
由于整体缺乏处理这个事情的经验和担责问题，所以这个事情处理得比较缓慢，记得这个事情的处理经由业务、法律、北美等单位反复协商，最终才得以回复。
当时还没有产品的网络安全部门，所以在回复过程中，高层再三要求必须进行多方讨论，确定措辞后才能回复。整个过程好像持续了一个月以上。
这个事情影响深远，暴露出一些电视机安全问题，比如端口号漏洞、目录权限漏洞、监控应用等。
通过对这个事情的复盘分析，得出大体存在下面的原因：
●开发时安全措施不足：
●无法进行安全测试；
●安全应对经验不足；
进而引出了产品的安全能力不够的结论，需要建立以下几点：
①安全审计、权限最小化等在开发时需要做的安全措施；（本篇章）
②安全认证、开发检测工具，举行安全测试等测试措施；（第 5 章安全质量治理）
③软件安全开发流程、隐私影响开发流程等流程建设；（第 7 章流程保障建设）
④建立统一的应急响应中心等对外安全门户。（第 8 章安全数字建设）
从报告、论坛、事件等可以总结出智能电视机会面临以下安全问题：
图 118
肯定还有很多超出了这里面所提到的问题，但当时大体的方向是准确的，不会影响到后面方案的制定。
接着，对这些问题做了归类，这些问题有以下特征：
●有些问题只是单纯的一个问题BUG；
●有些某个团队已经在做了，但没有覆盖全；
●有些其实是工程师故意留的后门，但没有得到管控；
●有些得到管控了，但人员的变动又被重新引起；
●有些问题需要一整套的解决方案；
●有些问题需要一整套的解决流程；
●有些需要和供应商进行协商处理；
●有些甚至需要立项，专门进行开发；
●有些需要购买第三方安全软件来支撑。
把每个问题进行归类总结，经过多次思考后可以得到解决方案：
图 119
注：一切的方案都是从业务问题而来，而不是凭空设想。
这样的归纳可以看到有些措施一下子就能够解决不少问题，问题主要还是集中在下面三个基本措施：
●最小权限；
●SELinux配置；
●端口安全。
对于智能电视机来说，只要这 3 个基本措施做到位，基本能解决以上一半安全问题。
对于大部分没有考虑过安全，在裸奔的物端设备，缺乏的往往就是基础安全措施。
（1）总结系统安全特征
上面对安全准则的解读提到的系统安全的 11 个特征，再加上数据保密性、真实性 3 个数据安全特征，可以形成安全方案的 14 个特征：
图 120
自主访问控制和身份鉴别需要配搭使用，但两者之间又不一样：
●身份鉴别更多的在于进门时候去看一下，并且标识出来；
●自主访问控制是进门之后根据身份标识赋予的权限；
●标志不算是一个安全措施，一般需要和强制访问控制一起使用。
（2）把上面的方案进行重新排列，找出其特征
图 121
可以看出：电视机系统到处漏风其实是身份鉴别和自主访问控制没做到位，而这是第一级用户自主保护级的要求。
工程师为了调试方便会置入调试提权命令*SU；为了程序能够调用系统权限方便会故意写出RootS*的进程；为了售后方便会在工厂菜单开放出ROOT权限的系统功能或内部服务置入ROOT提权功能等。但这些为了方便业务的功能，假如加入身份鉴权、自主访问控制等安全特征，就会加大研发工作的工作量，而且业务开发工程师大多没有相应的安全意识。同时，管控它会困难重重，特别是加入安全特征并不会带来绩效，而合规所要求的保护个人信息的安全，最直接就是保护数据，也就是数据的完整性、真实性、保密性这些特征会在研发中得到更多的使用，直接保护数据是让数据看不懂、改不了，而系统安全特征是保护数据偷不走，系统的稳定运行，不会被劫持等，至于隐蔽通道分析，在实际的工作中，基本不会考虑到这个特征。
由特征粗略判断级别：
图 122
假如能够落实以上措施，可能才能让终端系统的安全级别达到第一级——用户自主保护级别，但也具有了一些第三级——安全标志保护的特征（SELinux，可信执行环境等）。
要达到所要的安全级别肯定需要更多的措施实现，这需要一个推导过程：由功能能引起什么威胁，由威胁推导出所有安全措施。（相关内容请阅读第 6 章的国际认证）
根据上面所推导出来的智能电视安全方案，根据和系统关系是否紧密可以分为：系统层接口层、应用层。
图 123
可以看到：
●属于数据安全特征的，基本都在应用层，安全工厂菜单放在应用层是因为工厂菜单是一个用户能感觉到的应用；
●属于系统安全特征的，基本都在系统层，把安全RootS*放在系统层是因为它就是一个没有界面的进程，有需要的界面进程会来调用它，比如工厂菜单可以通过它来提权。
●安全SDK是为了解决某一个问题而放在了应用层。
记得当初最优先执行的方案就是：安全调试、关键数据保护、修复漏洞以及在几个重点应用上推行安全编码；接着推行全面开启配置SELinux，安全RootS*，安全SDK等；最后应该是应用加固、最小权限、漏洞修复机制等。
至于安全启动、TEE执行环境、安全mboot、安全工厂菜单这些大多停留在方案和计划中，出于各种缘由，最终应该是没有完全落实到位。
上面已经由具体的问题推导出需要做关键数据保护，但什么是关键数据呢，可能有人认为是个人数据或敏感数据，但在这里不是，这里的关键数据对应了事件引起的问题：主要页面被替换或劫持，所以寻找关键数据就在开机动画、海报、屏保、广告、关机动画上找。
图 124
识别出的关键数据包括：
●开关机各种数据，如开机LOGO、开机动画、开机视频、关机动画等；
●主页显示的数据，如主页海报、角标、墙纸、屏保、广告等；
●重点应用的数据，如G*，*购等用户经常打开的应用数据。
不同的关键数据是由不同的应用、服务、系统加载显示的，所以涉及的范围很广泛，数据存放在不同的途径中，那么详细的解决方案也不一样，而通过审查，确认这些数据都是明文存储在本地上的，终端显示没有对其做任何完整性、保密性、真实性的措施和校验。
由于大多关键数据的体积比较大，出于效率的原因并不适合做整个文件或目录的加密，所以大多采用简单签名的方式校验文件。
识别出什么是关键数据后，就要看看这些关键数据会面临什么样子的攻击或威胁。
图 125
大部分的关键数据都会面临以下三种威胁。
●本地数据被替代：但只要不是通过网络传输的，一般认为这种威胁并不大。
●通过网络劫持或者伪造服务端：下发不合法的资源文件，这种威胁就比较大。
●通过非法的应用进行修改：这种威胁也是有的，因为用户是分不清楚是不是他安装的第三方应用引起的系统问题。
针对以上问题，需要根据实际情况做出相应的防护方案，除系统提高安全特征外，有效的办法就是对下载的资源做签名检验，完整性校验不能保证资源的真实性，签名检验可以。
一种情况是需要考虑的，就是资源校验不通过，真正面临威胁的时候应该怎么处理。
图 126
大多情况，假如校验不通过，都是把资源数据丢弃掉，在本地进行删除，假如是从服务器下载的，那么就会把错误上报给服务器，重新请求下载，而显示上的优先级可以如下：
●显示上一次合法数据；
●显示默认资源数据；
●不显示任何数据，也就是黑屏。
数字签名分为两个过程：签名、验签。
本方案的签名比较简单，在第四章也有数据签名措施的说明。
当终端来请求资源的时候，在云端会对资源文件进行摘要算法，本设计里是取MD5 值，站在更加安全的角度上看，MD5 是不安全的。
提出这个方案时是刚接触安全这个领域，原先大量的完整性校验也使用了MD5，容易做到兼容。
接着，用私钥对MD5 的值做非对称RSA加密后生成了签名文件（签名文件一般还包含其他信息，但主要保护的是MD5 值）；再和资源进行合并成为资源数据包下发到终端。
图 127
在终端：
●会首先分离出签名文件和资源数据文件；
●再对资源数据文件做一次摘要算法运算出MD5 码；
●同时，用公钥对签名进行解密，还原出数据包中的摘要MD5 码；
●再对数据包中的MD5 的值与从资源文件算出来的MD5 进行比较；
■假如是一样的，就说明是合法的
■假如不一样，就说明不合法的
●然后按照上一节所制定的方案进行处理。
即使资源文件和签名一起被替换或篡改，只要私钥没有被泄露，那么就会校验不通过，保障资源文件的合法性。
但这种方式有个问题：公钥是公开的，也就是任意的终端都能拿到，所以签名是保证资源文件的真实性，摘要算法同时也保障了其完整性，但没法实现该资源的保密性。
由于本设计使用了安全系数较低的MD5 码，完整性方面的安全级别不会很高，RSA的密钥使用了 1024bit，所以签名的加密，或者说资源真实性方面的安全性基本是到位的。
有了方案和签名原理，下来就落到设计各个运用和云端的数据交换架构。
图 128
终端其实是分层的。
●mboot属于驱动层或硬件层
本次是需要驱动层显示的资源，比如LOGO或开机动画，一般没有直接联网的功能，所以依赖于服务的资源拷贝或者升级时把默认资源内置到对应的本地目录。
●Framework、bootvideo和资源推送服务属于框架层或服务层
对于需要框架层显示的，也需要服务层进行网络下载资源，然后复制到对应目录位置，比如开机视频等。
●上面就是各种负责显示的应用层了
最常用的就是应用层的海报、屏保、广告等的显示，一般都是对应应用直接从资源云端进行下载。
本设计有个设计得不好的地方，那就是资源推送服务权限过高。应用层资源需要资源推送服务拷贝到对应应用的目录中，那么资源推送服务肯定是ROOT权限运行，它可以访问所有用户的目录，那么就需要修改强制访问控制SELinux的规则，让它可以访问所有资源。
比较合理的方式是：通过内部通信、消息、接口进行资源的传输，然后对接口进行鉴权。
在本设计中，资源推送服务自身的存在就是个很大的安全威胁：假如推送下来的脚本存在提权漏洞，那么通过资源推送服务也就相当于获得了整个智能终端的权限。
威胁的详细解决方案可以从详细设计找到，省略。
这里有一个重要的地方就是在云端需要私钥加密，而在终端需要公钥解密，所以会涉及密钥如何生成、分发、使用、更换等问题，而当时是没有技术条件管理密钥的，所以就制定一个密钥规范来进行管理。
图 129
这里需要定义几个角色。
●密钥管理工程师：负责生成公私密钥对，负责私钥的安全。
●云端资源管理工程师：负责用私钥对资源文件进行签名。
●终端开发工程师：负责写软件对资源文件进行下载、解密、校验、显示等。
因此，整体的流程大概就是（对于密钥管理工程师）：
●将密钥对以及信息记录上传到密钥保存服务器进行保存；
●设定密钥的生效期间，比如 1 年；
●假如发现泄露，重新生成密钥对，并且更新到密钥保存服务器；
●假如云端资源管理工程师离职，需要重新生成密钥对，防止泄密；
●密钥管理工程师离职，新任密钥管理工程师也需要重新生成并且更新。
这里可以发现一些较大的问题，比如：密钥的安全依赖负责人的责任心；这个密钥管理工程师非常重要，但工作绩效很难体现；继任者，特别是密钥管理工程师的领导的继任者很难继续把工作执行下去；终端的密钥更新会很麻烦，一不小心就是批量的事故。所以必须有统一的密钥管理平台才行。
总结一下本设计的数据保密特点：
●签名使用了 1024bit的非对称算法RSA，真实性的级别达到业界水平；
●对资源的合法性校验使用了摘要算法MD5，完整性的级别偏低；
●没有对资源进行加密，该设计没有保密性。
总结一下本设计的系统安全特点：
●应用直接进行资源请求和校验符合安全设计要求；
●存在资源推送服务这样的服务，该服务的安全隐患较大；
●各个应用和资源推送服务应该通过通信或接口访问，而且必须鉴权。
从这个安全设计上可以看出，对设计进行安全评审是非常有必要的，设计上存在着安全问题，那么测试软件是无法检查出来的。
本方案从数据本身入手解决了关键数据被修改替换的问题，还需要从通信方面入手解决这个问题，见“本章节后面的安全通信措施”。
只要软件复杂，就会有漏洞，对于应用的漏洞的修复，只需要更新该应用就可以了，但对于操作系统来说，假如直接更新系统进行漏洞的修复，那么就要面临长时间下载系统升级包、重启产品进入漫长的更新过程等问题。
但为什么要进行漏洞的修复呢，有两个最重要的原因：
●法规的直接要求；
●漏洞对系统带来的威胁。
各个法律法规首先就会把漏洞修复、安全更新都写进去，这是软件安全、网络安全、信息安全的最基本的要求。
图 130
欧盟NIS2 的有效范围是电气电子设备，其要求如下：24 小时内进行漏洞处理和披露，应该不需要处理完漏洞，只需要报告就可以了；提供补救方案以应对漏洞，这里不只是组织措施，更多的是技术措施。
欧盟RED指令也明确了要求：联网设备必须进行软件安全更新、漏洞必须及时修复；英国和澳大利亚的法规同样有类似的要求；而美国是各个州都会不太一样，但漏洞修复以及软件及时更新都是必备的；国内的情况更加复杂，每个类别的产品往往有自己的安全要求，不同的相关部门还会发布各自的要求，但不管如何，漏洞修复和及时更新都是必须的。
做漏洞热修复的时候，肯定还没有NIS2、RED等法律法规；但GDPR、SB327、COPCS等法规已经发布，有着类似的要求。
修复漏洞最大的理由其实来自威胁，但在启动漏洞修复机制的项目的时候，并没有多大关注安全漏洞带来了多大的实际威胁，那时在智能产品，还很少人关注到系统漏洞所带来的影响，只是法规有这个要求而已，而且漏洞修复的工作量是非常大的。
比如从网络上找到的各种产品的漏洞情况也表明：很少人关注智能家电的漏洞威胁。
图 131
这是某一年的情况，每个月的漏洞不断地增长，漏洞主要集中在路由、摄像头等产品上；至于智能家电，公开的漏洞都非常少，但假如出现一个，就会伤筋动骨：比如前面的“一件印象深刻的安全事件”。
因此，对于智能产品，特别是智能终端的操作系统来说，漏洞修复是一件吃力不讨好的事情，而且往往还会产生质量事故的工作：没人关注威胁，工作量又很大。
虽然对于通用的电脑操作系统，比如Windows来说，在用户看来修复漏洞好像挺快速的，但通常也需要比较长的测试和试运行后，才会批量推送升级，这有一个非常好的前提就是Windows只是一个操作系统，底层的电脑的各种硬件基本都是通用的，都是X86 架构。
（1）这有繁多的修复型号
对于智能产品来说，硬件会更加多变，厂家的产品型号更加繁多，比如一年就有几百个型号的产品发布，这些产品都会经过不同的部门、团队的研发然后进行集成。少有人能够彻底清楚每个型号之间的每个差异，所以对于测试部门来说，每种型号系统都是需要测试。这就导致就算是一个小修改，一个小补丁，开发和测试的工作量都非常大。
在做安全之前的一段很长时间里，经历过每届领导以减少开发量、减少测试量为目标的工作，比如以增量测试、差异测试、分支管理为目标的项目。所以也清楚为了修复一个漏洞而发布一版软件是不太可行的。
图 132
对于修复漏洞来说，这需要个过程。刚开始，需要安全应急人员进行应急处理，其间，应急平台和沟通方式就非常的重要。从个人经历过的一个事件来说，这个应急有时会延续半个月之久，所以才有后续的一系列事情。假如该漏洞被安全工程师消灭在事件萌芽阶段，那么领导根本不会关注到居然还有这个工作。这就很考验工程师的责任心。假如产品这时候在市场销售，那么往往是会持续地OTA更新一段时间的，那么这段时间进行漏洞修复的补丁，就可以打在OTA升级包里。但还是会由于机型的繁多，发生需要经历一个多月才能在重要的机型上升级完毕的事情，至于最后有没有所有机器都进行安全升级是很难说清楚的，因为有些机器并没有联网、有些机器并不能静默升级，用户实际操作过程也是多种多样的。
（2）这是非常冗长的修复链条
图 133
这些链条每一步都会存在修复门槛，就算发现漏洞，主芯片供应商的修复积极性也不会太大，因为这并不能让其多卖更多的芯片。同样的道理，终端厂家更没有动力去测试补丁，特别是这个补丁还没有实际产生危害的。而终端厂家后续还要制作OTA，发布OTA，这些都有很大的工作量，特别是一年有几百个型号的产品。就算是保护漏洞的补丁OTA顺利发布，运营端上传这些OTA也需要一段的时间。
到了用户状态，情况就更加复杂更加消极。对于很多系统，特别手机系统都不会经常升级。因为过往的升级经验告诉他：升级往往带来的是系统变慢，还可能会多了一些莫名其妙的功能或广告，而所说的安全修复基本感知不到。就算用户接受升级了，也需要下载一个上G的升级包，这需要较长时间的等待升级，还需要重启，补丁才会生效，这同样阻碍到安全修复的进行。这些都导致OTA升级过后，大量的智能终端或智能产品得不到安全修复的，连Windows几年后都是弃子，不会有安全修复。
由此可知道：供应商、终端厂、运营端、用户对安全修复都是非常消极的。这让漏洞修复在智能产品上举步艰难。
这需要寻找一个用户无感、既安全数据量又少、不需要考虑繁多的机型、没有冗长的修复链条的方案。
来自业务的诉求肯定不是安全方面的，而是体现在成本、体验方面。在较早之前，已经有业务提出现有的软件机制存在这各种问题。
图 134
比如应用和系统频繁的升级会导致用户体验比较差，而往往修复一点小问题就需要对应用或者系统进行整包升级，操作起来网络流量消耗比较大，进而带来的成本也会比较大；有些应用可能还会引起安卓包管理机制PackageInstaller机制升级的问题，而包管理机制的修复与升级，很大可能会引起系统的升级，更加的大动干戈。
现有的系统软件形态是无法动态更换主题（当时无法更换）的，也没法分功能分模块上线，需要把所有复杂的规划都开发完后才上线，这导致系统软件上线周期长，更好的办法是规划一部分就开发一部分，上线一部分。
从代码区区分功能可能对于开发人员来说是比较顺手，但对于维护人员来说，版本还是难于维护，特别是无法分功能进行部署，也就无法分功能修复漏洞。
同样需要寻找一个用户无感、既安全数据量又少、不需要考虑繁多的机型、没有冗长的修复链条、可以分功能修复的方案。
目前，业界已经具有比较成熟的基本可以满足要求的修复方案：热修复方案。
根据操作系统的层级，解决的方案要分两个层面：
●应用层热修复方案；
●系统层热修复方案。
对于应用层的热修复方案只简单介绍一些业界方案，后续章节主要讲系统层，特别是 Linux层方案。
注：热修复指在系统（或应用）运行过程中，对其漏洞进行动态加载修复生效过程。
（1）应用层热修复方案
应用层一般有成熟的方案，根据网上能找到的资料以及自己的粗略的理解，整理了一个方案的列表，如下面所示：
图 135
根据具体的业务需求，选择某种方式就可以了，可能有些方案需要和供应商签署协议，而更具体详细的修复原理，这里不再列出。
在早期，某个团队其实有提出基于开源框架自研的热修复方案，原因是自研才能够比较好地解决业务问题，里面的坑自己也才能够填，虽然成熟的解决方案比较稳定，但可能随着人员的变动，后续的维护完善会更加的麻烦，但不知道什么原因，此类项目都会不了了之，落地普及困难。
（2）系统层热修复方案
通过网络搜索整理，可以知道，知名的系统热修复方案如下：
图 136
还能搜索到很多热修复的原理，很多还有源代码，说明很多爱好者对这块多有研究。热修复门槛并不高，但要形成整套系统，就会有很多地方需要考虑，特别是安全性方面，不要本来为了安全进行修复的，但最终却开了个大大的安全漏洞，原因是系统层的修复肯定是需要内核最高权限的。
为了解决实际的问题，契合实际的情况，以及掌握更大的主动性、安全性，有必要对这题基于开源的资料进行一些研究，
ksplice
ksplice只需要一个差异文件列出内核即将接受的修改即可，不需要预先修改。
图 137
Kpatch
基于ftrace的机制，但不将内核调用重定向回老版本。
图 138
实际的方案需要考虑到各个方面，比如云端补丁的管理、安全通信、终端补丁的管理、终端补丁安全等，这是主要要开发的内容。
图 139
落地的方案包括以下四种。
●漏洞管理平台：可以是安全响应中心的一部分或者独立的网站，可以分内核漏洞、框架层漏洞、服务层漏洞、应用漏洞等 4 个层级进行管控。
●补丁管理平台：单独开发的一个网站。需要对补丁管理区分不同的信息，比如不同机型、不同型号、不同国家、不同批次、不同销售端等；可以和升级管理平台、项目管理平台打通，对补丁进行管理。
●补丁管理程序：物端产品的一个应用层软件。通过一机一密的密钥对从补丁管理平台下发补丁，一般设计需要是双向认证，假如不是双向认证，会被冒充终端从服务器下载到补丁。这是建立密钥管理平台的一个原因（见第 8 章安全数字化），当时并没有密钥管理平台，由补丁管理平台自生成密钥对，所以并不够安全。
●补丁修复服务，补丁的修复需要系统权限、ROOT权限下进行修复，所以需要一个补丁修复程序，在安全的运行空间进行运行，而其对补丁的访问，对系统、框架以及其他服务的修复，一般使用强制访问控制SELinux进行强管控，进而保证其安全性。
图 140
内核修复方案采取类似Kpatch的原理，最大的特点是会存在地址保护索引表保护过程的地址。
在内核中的内核模块函数地址结构中，会存在 25xx多个内核模块，这些模块随着不同的内核版本，数量应该会有变化，这个方案修改内核模块的地址结构，但函数 2 有漏洞需要打补丁的时候，会修改函数在内核模块函数地址结构里的函数 2 的注册地址为索引表的地址以及补丁在这个索引表里的位置，所以内核调用函数 2 的位置就会调用到补丁，而调用到补丁后可以有两种选择：可以返回索引表再使用函数 2 地址来调用实际的函数 2，这种方法常用来修复对于函数输入参数判断的漏洞；或者不返回索引表而直接返回，这种方法常代替整个函数，修复的范围就更加广。
能够保持热修复补丁的数量和地址索引表的大小有关，通常为 256 个补丁，这意味积累一定程度的补丁后，最后通过OTA来进行全盘的升级，保证系统的稳定性、安全性。
框架的修复在业界一般有比较成熟的方式：通过反射的方式进行修复。
图 141
对于框架的修复，有几个地方：
●假如有老补丁，那么需要备份，这样在打新补丁的时候假如出现问题，可以回退；
●JAVA层一般使用反射的方式获取系统class，然后HOOK住替换为补丁的class，但记得这种方式还是比较损失性能的；
●对于C层会获取对应的sservice，然后通过动态代理对象的方式，也就是proxyNotimng替换系统的sservice，达到修复的目的。
作为一个服务，一般都是采用内部通信的方式提供服务，内部通信的方式可以是内部binder或者是内部SOCKET。
图 142
客户端一般会提供功能接口的函数给客户端程序进行调用，而其通过通信调用服务端的功能，此时服务端可以查询一下补丁列表，假如没有补丁，就直接调用原来的函数。
假如有补丁，那么可以加载补丁的函数，先调用补丁ID的函数再去调用原函数（也可以直接返回），和内核修复原理类似。
在这个设计中，函数列表是一个比较考验性能的设计，在整个服务的研发过程中，有使用过链表，也可以类似binder成熟的设计；而补丁ID表可以使用链表或者干脆就一个结构数组存储，毕竟需要打补丁的服务函数一般不会太多。
在物联网产品行业中，实际的补丁管理是非常复杂的，这对于很多公司是不可理解的，他们大多只关注安卓的版本。
图 143
在最初的考虑中，智能产品会有很多机芯，这些机芯还会从属不同的SOC厂家，比如ms*、M*K等；
对智能电视厂家来说，一般都会从SOC厂家带来操作系统，也就是安卓版本，而随着实际情况的升级，在实际用户的手中，安卓版本就会比较多，所以补丁也必须分开管理。
不同的安卓版本，可能内核版本是一样的，但也不能排除有些不一样的情况；对于框架framework层也是一样的，这两者大多不会开分支。
不管是内核、框架、服务、应用，都会可能有很多的漏洞，每个漏洞也许会有不同版本的补丁，而打补丁最好还需要区间选择，方便先进行小规模的升级，等到补丁机制被验证是稳定可行后，才大规模地进行升级，减少升级带来的影响。
一般来说，智能设备所运行的服务会比较多，可能有十几到几十个进程，再考虑到用户端可能运行不同版本的服务，这就非常复杂了，想想就头大；对于应用，真实情况会更加的复杂：应用的版本，很多的应用，导致整个补丁管理平台的设计非常复杂。
如可算一个数学题：假如产业有 3 个机芯，每个机芯 2 个安卓版本，每个安卓版本 1 个内核版本、1 个框架版本、10 个服务，每个服务 2 个版本、20 个应用，每个应用 3 个版本，都有 3个漏洞，每个漏洞只有 2 个补丁，那么总共有多少补丁？（数量都设置得比较保守）
比较好的方式是能够解耦，比如系统服务能够和安卓版本解耦，应用能够和安卓版本解耦，安卓版本能够和机芯型号解耦，那么管理的数量和层级就没那么多。
经过优化的结构为：
图 144
注：按照这种方式再算一下上面的数学题，看看有多少个补丁？
这个方案并没有进入大量普及的阶段，无法用实践准确检验什么样的补丁管理平台是最符合物联网产业要求的。
虽然补丁的管理平台比较难设计得既好用又简单，需要一个较长的实践过程，但该项目执行后，对于修复漏洞这个事情来说效益是非常客观的，对漏洞修复流程的改善也大有裨益。
图 145
之前升级方法主要有以下弊端：
●整包集成过程比较费时，它会包含除安全漏洞修复外的其他改动；
●整机包必须进行较完整的测试，这比较费时；
●整包一般比较大，在 2G到 5G之间，整机包进行上传和用户下载，费时费流量，进而导致用户好不容易开机看电视，还要升级一小时才能看，非常影响用户体验。
之后流程的特点：
●不需要集成整机包，没有这个集成过程；
●不需要整机完整地测试，只需要测试补丁对应的功能；
●补丁包一般很小，在几K到几M之间，几秒就能完成上传和下载；
●用户可以不用关机，对正常观看电视无影响。
不同修复与升级方法之间其实有互补的关系，在产品的不同期间可以采用不同的升级方式：既能够节省成本，又能够提升用户体验，还能满足市场需求。
图 146
总体来说，整包升级修复慢，但系统完全替换，稳定性方面肯定较高，升级方案成熟，不需要修改架构代码开发。就算到现在，很多操作系统的大版本升级都是整包升级。
差分升级就是为了解决整包整机大的问题，不过机制原因可能导致测试工程师不太清楚具体修改哪些地方，所以测试的工作量并不能减少，大多还是需要整体进行测试。
补丁升级最大的阻力来源于需要修改系统，而这对于智能产品厂家来说并不友好，因为智能产品厂家的原始操作系统都来自芯片厂家，并没有自己原始积累的操作系统，意味着换个机芯，换个操作系统版本就需要重新修改一遍，所以不同的修复升级方式需要适应不同的产品时期。
图 147
在研发或者销售前期，系统一般会面临比较大的改动，此时用整机修复升级会比较好；而在销售中期到晚期，系统一般稳定下来了，测试可以补丁升级配合差分升级；而在用户存量，产品已经进入末期了，补丁升级能够及时修复漏洞，投入最小，影响也最小。
已经记不清这个项目的起因是什么了，只能依稀记得是在哪个网络论坛看到过可以通过工厂菜单获取到ROOT权限，然后对电视进行控制；又或是参加一个工厂菜单项目的评审，然后从中得到安全问题；又或是那次安全论坛上，安全爱好者找到了很多使用遥控组合键进入工厂菜单的方法。
工厂模式确实是电视最大的漏洞所在，体现在以下几个方面：●进入工厂模式的方式在网上随处可以找到（如下图）；
图 148
●工厂模式可能还是工厂生产模式、用户工厂菜单、返修工厂菜单、酒店菜单等的集合；
●用户工厂菜单，特别是工厂生产模式，直接就可以提权到ROOT权限；
●工厂模式可以访问机器的所有资源，包括各种证书、序列号等；
●工厂模式大体分为菜单＋服务的形式运行，而服务的接口没有做任何鉴权，所有应用都可以调用；
●工厂模式经常被供应商用来私自修改一些SN码之类的，这是串货的一个原因，而串货是当时领导关注的一个安全问题。
当时，根据从各方获知的信息以及对工厂模式的了解，提出的整改要求大概是：
●后台服务和工厂菜单应用分离；
●工厂菜单保留和安全无关的功能；
●整机生产后进行复位进行用户态，需通过通信端口进行安全校验后，才能进行调试；
●酒店模式的密码修改为可修改，且用户第一次进入提示进行修改；
●酒店模式下，U盘拷贝数据到电视需要输入密码；
●增加二维码和生产模式的安全检验方式；
●ROOT态执行命令改为用户态命令；
●统计工厂模式的资源访问情况；
●工厂自动化测试工具加入安全鉴权；
●海外售后的需使用证书及其使用方式；
●服务名次不要出现Factory字样，不然很容易被猜测出是工厂的服务。
可以看出要求集中在自主访问控制和身份鉴别的策略控制上，是系统安全的第一级要求。
工厂应用大概的架构示意图：
图 149
可以看出工厂、售后、酒店等所有的功能都集中在一个应用中，而这个应用会直接调用系统的一些功能来实现这些功能。记得工厂应用在做CTS的时候是独立做特权处理的，工厂应用会通过后面所说的ROOT服务进行ROOT权限的系统命令调用。
这是一个杂烩的框架，根据这个框架，是不好处理用户权限、生产权限、售后权限、酒店权限的，所以必须进行分离。
由于工厂业务的阻力，方案只能在原来的基础上做了修改，并不能重新进行设计。
图 150
首先，把生产服务和有菜单的工厂应用给分离出来。按照原来的想法，应该分 4 个应用才算完美，最终方案只是生产服务与工厂应用的分离，但已经很大地提升了安全度，而且设计生产时，能打开所有权限，特别是密钥和序列号的抄写权限的，强制访问控制SELinux也是关闭的，这能尽可能小的影响到生产。
其次，用户态进入生产服务的时候提升了鉴权的复杂度，特别是增加生产服务对系统功能调用的鉴权。
再次，进入工厂应用鉴权进行了提升，抛弃了固定的数字进入工厂应用，用户第一次进入后，提醒用户修改；或者使用一机一密鉴权证书进入。
最后，工厂应用到系统功能的调用也进行了鉴权。
最早的鉴权设计得比较粗糙，没有统一密钥管理平台发放密钥对或者证书来进行认证鉴权。（这是要建设密钥管理系统的起因之一，相关内容见第 8 章）
图 151
使用设备的序列号和时间生成鉴权码，这虽然很容易被算出来，但也是通用做法，网上很多鉴权码都是类似的方式。然后，在终端和云端进行加密保存，这里采用了非对称加密算法RSA进行加密，可以保证其安全性。
图 152
还存在两个地方有可能有漏洞，那就是工厂调试工具和售后调试工具都是通过串口或其他通信方式和工厂生产服务或工厂应用菜单进行通信而达到调试的功能的，而且这两个工具很容易被泄露到网上，所以需要进行IP绑定或用户认证或微信认证，这非常有必要。
提出的要求其实并没有全部落地，特别是下面 4 个和安全强相关的需求并没有得到实现，更别说落地了。
●增加二维码和生产模式的安全检验方式；
●ROOT执行的命令改为用户态命令；
●工厂自动化测试工具的安全鉴权模式；
●海外售后的证书使用方式。
工厂模式就是后台管理功能，这不仅在云服务，在终端都是一个最大漏洞的所在，而对于工厂模式的进入方式往往掌握在售后工程师手中，售后往往已经外包给三方公司，所以是最难进行安全管理的。
工厂模式安全是很能体现一个公司技术实力的：假如一个企业连工厂模式、工程师调试模式的安全都做到位了，那么这个企业的其他技术肯定不会差，质量也不会差；就如某水果、某菊花。
在智能电视机中会存在一个包罗万象的TV服务，这个服务一般以ROOT形式运行，采用的是C/C ＋＋的语言进行编写，运行在LINUX系统后台服务中，对外提供各种服务。
图 153
在此之上运行着各种应用，包括但不限于电视功能、信源功能、媒体功能、工厂功能、HBBTV功能，它们在电视上运行的功能多多少少都与之有关系。就算没有直接关系，电视上的功能应用总要获取现在的接口情况、信号情况、声音情况、画质情况、场景情况，这些也需要通过服务系统功能接口进行调用，所以可以说是智能电视操作系统的核心。
而最初的系统服务是没有对接口进行鉴权的，所有应用都能调用它，特别是一些应用通过它来执行需要执行ROOT权限的系统命令。也就是说，只要能知道或了解有该服务存在，就能够直接获得系统ROOT权限以及调用大部分系统功能，包括媒体的数字版权、各种密钥、个人数据等。
这样的系统服务很不安全，为了有效地对其进行管控，所以提出了安全电视系统服务接口项目及方案。
对于系统服务，接口鉴权是一种行之有效的办法，而这个方案的鉴权方式比安全工厂模式的方案又更进了一步。
最初提出了两种的方案，一种是不用初始化，一种是需要初始化以及正常的函数调用。
（1）第一种方案
第一种方案不需要初始化，所有应用直接功能调用就可以，但每次调用都必须带一个访问密钥进行调用。
图 154
到了TV系统提供的统一接口的时候，通过应用去系统中查到该应用对应的PID，把它作为参数自动带入。
TV系统服务会位于一个ROOT权限运行的进程中，该服务进程会根据PID去获取得到应用名称，接着验证访问密钥的合法性，然后验证密钥中的应用名称和通过PID获取的应用名称是否一致，还可能会验证调用的接口是否在访问密钥允许的范围内，假如一切都是合法的，就执行相应的TV系统功能，包括操作系统的功能。
这种方案看起来简单，但对于应用来说不是很友好，每个接口都需要去修改，使其能带入密钥，通过一些手段也许操作并没有那么复杂，但最大的问题在于会增加每个功能调用的耗时，而且时长可能会比较长，还可能存在一些新添加的接口会忘记修改参数传入密钥的情况，错漏比较大，所以有了第二种方案。
（2）第二种方案
第二种方案把应用带入密钥和正常的功能调用分开。
图 155
访问密钥只在应用初始化的时候带入，然后通过获取系统的应用列表就清楚PID对应的应用名称是什么，整个过程和第一种方案类似。最大的区别就是先把密钥、PID、应用名称保存在一个列表里，作为后面正常功能调用的数据来源。
对该方案信息流的详细解析在下一节。
图 156
到正常的系统功能调用的时候就不需要传入访问密钥了，TV系统功能接口统一做好获取应用PID就可以，然后TV系统服务层通过该PID就可以获取该应用的访问密钥，假如存在这个数据就验证接口，都合法了就执行TV的系统功能。
这就没必要解析出信息流了。
对比第一种方案的优点体现在以下几个方面。
●修改少：只是初始化的时候需要添加一个参数，应用层基本无感。
●执行快：正常的功能接口就一个查表对比。
●安全高：只有一次的密钥传输，安全度也高，保存的密钥对应关系表是在内存中。
●错漏少：只修改初始化接口的参数，出错的概率低，并且如果出现错误，那么功能也无法正常调用，整个应用就无法正常运行，马上就能修复错漏了。
（3）访问密钥
访问密钥最初的设计如下：
图 157
包括以下几个方面的内容。
●标志头：可以对这种方式起一个特别的名字，一般可为TV系统服务的名字。
●版本好：这个访问密钥的版本，一般为版本：1。
●签发者：这个密钥的签发机构，可以是本公司名称。
●签名时长：密钥的使用时长，为了不用经常更新密钥，可以是 9999，无限期。
●应用所属：这个应用是谁开发的，可以是公司也可以是团队名称。
●应用名称：也就是包名。
●应用版本：这个包的版本是多少。
●接口范围：要调用的TV系统服务的接口访问，可以是所有、某模块、某模块的接口ID等，看细分，但为了省事，后续基本都签发能够获取所有的接口权限。
●签名：在平台上进行签名，把这个密钥打包成为签名；后续该签名的秘钥进化为秘钥管理平台派生，进而建立起更加安全的信任链。
密钥与签名技术后续会持续出现，每次要解决的问题都不一样，出现的时间也不一样，也就是经验不一样，技术完善程度也不一样。
对第二个方案应用初始化的信息流拆解如下：
图 158
在云端：
●访问密钥信息通过摘要算法，比如HASH里的SHA1 会生成一个不可逆的摘要值，这个摘要值可以校验密钥数据的完整性；
●对该摘要值使用私钥进行非对称加密形成签名数据，这就可以校验密钥数据的真实性；
●需要采用BASE64 进行编码形成访问密钥，保障一定的保密性。
在物端：
●访问密钥会被应用开发者在终端的应用初始化时候作为参数使用；
●通过终端系统的内部通信，比如socket或者binder传输到TV系统服务层进行解码，解码出签名数据和密钥数据；
●在电视机里一般会集成公钥或者在电视终端初始化的时候通过HTTPS下发公钥；
●TV系统服务层使用公钥对签名数据进行解密，解密出密钥数据的摘要值（SHA1 值）；
●然后对密钥数据进行真实性和完整性校验；
●假如合法，就把数据保存在TV系统服务层。
由于这是跨进程的函数调用机制，对于性能的损失是非常敏感的，所以需要对接口进行性能测试，应用要看到这个数据才肯把接口鉴权功能加进去。
测试需要分几个部分进行测试（以下所测时间只是示意，不代表实际）：
首先，需要测试给应用初始化带来的耗时，虽然初始化一般只做一次，但还是有影响的。
图 159
最终测试 100 次出来的值，平均会多耗时 3.5 毫秒以内，对应应用初始化动辄上百毫秒来说，影响在可接受的范围内。
其次，需要看对应用功能接口调用带来的性能损耗，这个的影响会比较大，比如一些需要连续调节的功能，比如调音量。
图 160
可以看出测试 100 次后，原始和加了鉴权的耗时差距两条线距离还是比较近的，通过求平均，耗时大概增加了 0.8 毫秒以内，对于一次功能调用是几毫秒，也还能够接受。
这个方案的耗时主要集中在于终端的数据保存和数据查找，有很大的优化空间：把存储链表实际得更好，通过索引表让数据查找更加快速，通过加权的接口调用在内存中缓存等措施可以极大地提高性能。
作为产品新添加的措施，最大的阻碍其实是如何兼容已经在市场和用户家里的设备，最难解决的三个问题应该是：
●机器的系统是老系统，应用是新应用，应用会传入访问密钥参数，但TV系统服务没有相应的功能和接口；
●机器进行OTA升级为新系统，但有些第三方应用没有添加访问密钥参数，调用接口造成失败；
●加密密钥泄露后如何更新密钥；
再加一个限制：需要处理的存量机器可能会上亿台，而且年代可能需要追溯到十年。
这类的限制是产品优化的最大阻碍之一。为了减少软件开发人员的反对声音，最终添加一个编译选择，可以选择是否打开，假如没有打开，就沿用以前没有鉴权的方式，对现有系统没有任何影响，但安全性肯定不够，只能后面徐徐图之。
这个工作进行了一两年后，终于在新的机器上大多落地了这个安全措施。
开始是强力推行这个安全措施，导致一有TV系统服务出现接口调用问题，系统开发人员就会甩锅给这个模块，但最终大多证明问题并不是加这个功能引起的。（以下只是示例）
比如遇到某媒体中心闪退：
图 161
●分析LOG，看到没有安全接口的打印，怀疑应用没有调用到TV系统服务；
●检查应用的调用代码，代码正确；
●怀疑强制访问控制SELinux配置问题，关闭之，问题依旧；
●继续打印调试；
●检查出是odex问题，关闭验证，问题解决。
比如某第三方应用调用TV系统服务功能失败：
图 162
●分析LOG，怀疑该应用没有权限调用TV系统服务权限；
●检查该应用的访问密钥，确实没有权限，估计是哪里拷贝的，不是申请的；
●重新帮忙申请符合权限的访问密钥；
●问题解决。
比如安卓系统遇到某一个应用崩溃了：
图 163
●分析LOG，堆栈里有logout*接口，但应用并没有调用该接口；
●检查应用代码，代码逻辑不正确；
●修改应用注册代码为正确调用方式；
●问题解决。
图 164
系统服务接口的安全鉴权加入，成了应用系统功能调用的咽喉，只要是有什么查不明白的问题，往往就会怀疑是因为加了这个安全机制。特别是假如编译时去掉该接口鉴权功能，软件运行又正常了，那么就更说不清楚了，而这往往是软件和数据内存在编译时重新进行排列，然后程序指针踩到导致的系统不稳定。
那场“AI时代智能电视安全新挑战”可以引导从本行看安全行对于智能电视、智能产品的安全见解，结果是漏洞百出，所以印象比较深刻，对于权限的管控的大部分想法来自那场论坛。
图 165
至于后面来自合规的要求——所有应用都必须最小权限，那是后话了。
而ROOT权限是LINUX等操作系统中最大权限，获得ROOT权限，基本就能控制了整个系统，这是超级用户权限。在LINUX系统中，会通过UID来区分不同用户的权限级别，UID为 0被定义为ROOT用户权限。
获取ROOT权限后，那么就能随意安装恶意程序、窃取用户数据、劫持该系统、植入病毒或后门，等等，都能完成，所以ROOT权限的管控尤为重要。
翻开记忆，不同的方案获取ROOT权限的方式是各不相同的（下面是几年前的情况，不代表现在依旧如此）。
图 166
以下为每种方案的特点：
MS*方案的是比较常规的方式，有SHELL会话的用户，说明是多用户的系统，但系统内部会内置一个提权的可执行命令，这个名字通常会被更改，稍微和常规电脑的提ROOT权命令不同。
NT*的方案默认是就以ROOT权限进行登录，说明极有可能是单ROOT用户系统，系统里的所有功能、应用都会运行在ROOT权限下，但默认会关闭串口，进入boot模式可以打开串口进行调试。记得这个方式在海外被别人找到过，并且进行发帖，后面好像修改了进入root的方式来解决。
MT*的方案比较安全，整机软件会有释放版和调试版，释放版的软件由于强制访问控制做得比较好，所以很难获得ROOT权限，也没有提权命令，但因为要发布两个软件，会增加发布工程师的工作量，以及后面发现调试版的问题居然和释放版会不太一样，用户发现释放版会偶然死机，但调试版在同一个条件下居然不会，因此，后续都发了调试版到市场，也就存在提ROOT权限的命令了。
RO*的方案是最完善的，有内置多个用户，比如ROOT、SHELL、App等，假如要获取ROOT权限，需要想方案商申请一个证书，这个证书是跟这个机器绑定的，不能用其他机器，必须把这个证书通过某种方式烧入机器，才能获取ROOT用户权限。
本方案就是借鉴RO*的方案特性，以解决MS* 、NT*、MT*方案中出现的权限问题。
在最初的智能电视机系统里面，都会存在很多提权的途径，不只有外界论坛找到的那些提权方法。
在没有接触安全工作的时候会觉得存在这些提权方式都是理所当然的：为了研发和售后等业务的方便。但一旦进入安全工作领域，总会想着需要把它管控起来，就比如开着好几扇门在那，总要想办法锁起来一样，虽然屋里也没啥值钱的。
●一般来说，提权途径有下面几种。
●*su提权：原理是执行带setUID权限可切换到ROOT权限的可执行命令，作用一般是研发工程师提权调试用，也有软件想提权就执行它。
●系统漏洞：只要是软件系统，就会有漏洞。
●系统服务：很多服务自身就运行在ROOT权限下，或者会运行su来提权，或者会通过与其他ROOT权限的服务通信来获得ROOT权限。
●adb提权：端口配置，backupAgent等提权漏洞。
●sudo提权：一般会根据配置sudoers来进行授权，一般是让某些超级权限有针对性的下放。
不同提权的方法自然需要不同的解决方案。
图 167
（1）对于有提权执行文件*su
删除*su当然是最简单的方法，但一般不会直接这样做，有些场景还是需要的，比如开发和调试。
安卓系统一般为多用户系统，但在安卓之前的系统，存在单用户的Linux系统，此时系统基本是裸跑着。
参考RO*的方式，研发自己的一机一密提权机制，应对有些场景提权的需求。
（2）对于有系统漏洞的方案
首先肯定要找出漏洞，需要涉及购买商用的系统和第三方库漏洞扫描软件；然后需要进行OTA升级，解决漏洞问题，或者使用前面的漏洞热修复系统修复漏洞；
（3）对于在后台运行的服务和进程的情况
首先是梳理到底多少服务和进程运行在root权限下，有没有必要运行；那些执行SetUID的提权软件也要找出来；那些通过间接接口调用可以获取提权的也要找出来，比如工厂功能。
（4）对于adb的解决方案
adb默认肯定一般是关闭的（在出厂机器中发现有些型号是打开adb的），假如要打开，必须进行密码鉴权认证，并且一定时间没有使用该功能，要能够自动关闭，其对应的端口 5555 也要关闭，漏洞也要修复。
在这些方案里面，对root权限管控的一机一密机制尤为重要，大多情况都不能直接删除或关闭了事，很多场景是强需要的，而采用物端内置提权默认密钥或密码，会容易被泄露，只要有一台泄露密钥或密码，那么所有型号所有机器就都面临威胁。
这需要开发一套系统来搞定。
会用到一机一密提权的用户有开发工程师、测试工程师、售后人员、工厂生产、第三方开发工程师等，那么需要开发一个系统平台管控不同用户使用不同的密钥（证书），该系统包括下面基本内容：
图 168
这看起来是最原始最简单的密钥管理系统。（密钥管理系统见第 8 章）
网站开发有一套成熟的框架，经过讨论，选择的技术栈为：
图 169
其中Element UI 和VUE为前端技术栈，Tango、MongoDB为后端技术，RSA保密算法。
整个证书的数据流架构方案和上一节的系统服务接口安全方案类似。
图 170
变化的是：
●这里需要的信息是申请人邮箱，要确定到底是谁需要提权，通过邮箱可以初步确定身份，如发工程师、测试工程师、售后人员、工厂生产、第三方开发工程师；
●需要设备的MAC地址或者其他信息，这是一机一密的关键，联网设备的MAC地址具有唯一性，每一台设备具有唯一的MAC地址，把MAC地址写入密钥，密钥和设备就一一绑定起来；
●需要录入设备系统版本号，也是该证书的关键，虽然不是一机一密强标志，但是系统信息的重要来源，作用大体为可以搞一型一密，产品查询绑定、系统与密钥的匹配等；
●需对整个信息做加密，这些信息严格来说是个人信息，需要保密，而且只发生在提权的用户提权操作，对于性能要求没那么高；
●可以再进行BASE64 的编码，进一步增强其安全性；
物端系统的ROOT提权需要分几种场景。
（1）整体设计
图 171
●正常运行状态（用户态）
设备内会存在一个常运行服务，在开机时候系统会启动这个服务，该服务一般运行在ROOT权限下。
●需要时进行提权（调试态）
该服务检测到有插入U盘，判断一下U盘里是否带有证书，假如有，就检测证书类型是否正确，该服务就会把授权证书拷贝到系统某一个位置。注意，这个服务并没有立刻解密证书，所以此刻并不清楚谁想要提权。通过安装证书，该电视机器就切换到了调试模式或叫工程模式、调试态。
●不需要时恢复正常（用户态）
恢复出厂或者升级的时候，该服务会删除提权证书，设备又恢复到普通模式、用户态。
（2）如何提权
图 172
调试模式下能够运行所有系统命令，并且都是在ROOT权限下运行，相当于控制整个电视系统。
●工程师首先要执行提权命令（或者叫进入调试态的命令）（不是原来的*su了）。此时的提权命令就会检查系统中是否有调试证书（提权证书），假如有就解密证书。
●接着获取终端系统的信息，包括但不限于MAC地址和系统版本号等。
●然后把对比一下证书中的信息和系统信息是否是一致的。此时假如服务和平台进行通信，就可以知道是谁在进行提权。
●假如一致，就设置UID ＝ 0 来切换SHELL为ROOT用户权限。这时候就能够在ROOT权限下执行任何命令、访问任何数据、调佣系统任何资源。
（3）提权分级
上面说过，可以通过进入工厂模式获得ROOT权限，也意味着可以为所欲为。
可以通过证书所属进一步控制权限，进行提权分级。
图 173
可以改造系统调用机制，使在执行系统命令的时候，增加需要验证证书的权限、证书类型等。假如是开发者证书，就执行所有的系统命令；假如是其他证书，比如测试工程师、售后人员、工厂生产、第三方开发工程师，那么就可以适当控制其系统执行权限。
业务或应用经常要调用一些系统命令，特别是ROOT权限下的命令来干一些事情，比如工厂菜单里的清除用户数据、应用数据等，再比如系统清理工具需清理所有用户和系统数据等，那么就需要存在一种运行在ROOT权限下的系统命令服务，以满足业务的需要。
图 174
该服务原来是没有做权限管控的，包括第三方、恶意等的应用只要知道有该ROOT权限服务都可以直接调用，执行ROOT权限下的任何系统命令，这非常的危险。
随着安全系统服务接口以及ROOT权限管控措施这两个项目的推进，肯定也要把该服务也管控起来，所以采用了类似的接口鉴权、执行系统命令权限管控等措施进行了管控，由于原理和上面两个方案类似，这里说明一下，详细设计略。
应用层调用到系统高权限服务层的任何接口，都需要进行接口鉴权才是合理的；提权的密钥证书统一在平台申请和生成。
（1）历史遗留问题
要实现提权，至少系统要有多用户机制才行；
从上面已经看到：还是存在像NT*的古老纯Linux平台，整个系统就一个用户，也就是ROOT用户，不存在普通用户，所有指令都是最高权限运行，所以无法对权限进行管控，而经过和方案商的沟通，其进入boot模式开关串口模式也没法做一机一密提权证书校验。
通常来讲，一个多用户系统，最基本必须具备 4 种用户组：
图 175
虽然在安卓系统中是常识，但实际操作起来却不容易，最终好像只有一个方案商能把他们的Linux开启多用户机制，其他方案商都没办法或者不想干这吃力不讨好的事情。一段时间后，随着安卓系统的普及，这个事情倒不需要再做。
（2）可以从mboot动刀
某些芯片方案商一直没有搞定多用户机制，所以只能从控制mboot入手了，因为进入mboot，基本相当于控制了整个系统，可以开启关闭SELinux，可以开启关闭调试口等，可以对芯片数据进行清除，可以升级操作系统等。
图 176
在mboot的命令里面添加一个指令，该指令是控制其他指令是否执行的，当执行该指令的时候：
●先判断mboot的指令是否是解锁状态，假如解锁状态，说明已经进行认证了，可以放心地放开其他指令的执行；
●假如没有解锁标志，那么就是认证过程了，逻辑和上面类似，就是检测U盘是否有证书，解密证书后，判断证书是否合法，假如都合法，就设置指令解锁标志；
●假如是非法就关闭解锁标志，除了解锁指令的指令，所有其他的指令都不能被执行；
●更好的处理方式还可以对高危指令做独立的鉴权。
那场“AI时代智能电视安全新挑战”的某个专题的演讲中，不止一次地呼吁智能电视必须把SELinux开启起来：
图 177
而这成了研究什么是SELinux的起因，在现在看来是多么基础的知识。
在NSA发布橘皮书之后，着手研究Linux的安全强制访问控制机制，这就诞生了SELinux，所以SELinux是一个针对Linux的安全加强系统。估计是美国相关单位或者一些关键性设备里，跑的都是Linux（或者Unix）。
在Linux2.6 之前，SELinux是通过patch方式发布的，而在此之后，SELinux正式进入内核，成了标配，叫LSM（Linux安全模块），所以Linux2.6 之前后的安全级别是两个级别，Linux2.6之前最多只能达到系统审计保护级，而Linux2.6 之后能达到安全标志保护级甚至结构化保护级之上。
Linux只是内核，一个完整系统还需要包括其他东西，各家也都对Linux和SELinux有自己的改动，就如在安卓系统上，谷歌对SELinux也有修改，形成了SEAndroid，所以需要对SELinux有一个简单的理解。
（1）DAC&MAC
为了不用翻看什么是DAC和MAC，把前面的安全标志保护级的介绍复制一下。
自主访问控制（DAC：Discretionary Access Control）目标的主体可以自主地确定其他主体对其目标的访问权限。
强制访问控制（MAC：Mandatory Access Control）：任何主体无权改变其目标的访问权限
DAC和MAC的区别：
●DAC在系统运行过程中，可以改变权限；（领导想提拔哪个人就提拔哪个人）
●MAC在系统运行过程中，不能改变标签；（与生俱来的特性，改变不了）
●DAC默认最大权限；（到达哪个级别就具备那个级别所有的权限）
●MAC默认无任何权限。（与生俱来的，没有任何特性，就没有任何权限）
这里可以套用网上的示意图再次理解一下：
图 178
（2）权限检查流程
Linux系统会先做DAC检查权限，再做MAC检查权限：
图 179
也就是后做SELinux的权限检查，这由LSM模块所执行：
LSM模块机制：
图 180
LSM模块是根据安全策略文件来决定权限的，也就是安全策略文件是SELinux的配置文件。
（3）三要素与安全策略文件
图 181
一个事务要访问另一个事务，至少必须具备三个要素：
●谁要访问：主体
●访问谁：客体
●访问本身：操作
而在SELinux中，操作的规则是由安全策略文件控制着的。
（4）安全属性
假如在开启SELinux的Linux系统中，通过PS -Z命令查看，能看到类似的信息：
图 182
以第一行为例子：
●u为user，用户（和DAC的用户不同）；
●r为Role，角色（基于角色访问控制，Role Based Access Control，简称RBAC）；
●init为域类型，所属的域类型为init：MAC的管理思路（Type Enforcement Access Control，简称TEAC，TE）
●s0 为安全级别，Multi-level Security（MLS），将系统的进程和文件分级，不同级别的资源需要对应级别的进程才能访问，这里看到的都是最高级别。
归纳如下：
图 183
（5）安全策略文件
要达到上面的属性，就必须编写安全策略文件，格式是：
allow（规则类型） domain_t（域类型） bin_t（客体类型）:file（客体类别）execute（访问向量）
比如：
安全策略文件里的一条语句假如是：allow netd proc:file write.
那么意思是大概是：授权allow（域类型netd、客体类型proc）为（类别file、能进行write访问）。
规则类型包括allow、allowaudit、dontaudit、neverallow等；
客体类别包括file、dir、socket等；
访问向量包括read、write、open等；
域类型和客体类型：自定义。
安全策略文件就是用上面这个格式写的文件，假如继续再详细写下去，本书的易读性会下降很多。
原本可以是一本书的知识在这里被缩减到两页多一点，就可以看到有多简单。
阅读网上有篇叫《深入理解SELinux》的文章，可以深入了解SELinux的原理；
SEAndroid是SELinux在安卓系统上的使用，又有哪些不同呢？
SELinux的进阶就是SEAndroid了，其根据安卓的特殊性，添加了property_contexts和seapp_contexts等文件。
图 184
安全策略文件包括以下几个方面的内容。
平台共有策略：system/sepolicy/public。
平台私有策略：system/sepolicy/private。
平台对vendor的定义：system/sepolicy/vendor。
vendor策略：自定义；厂家自己定义的策略。
SELinux的配置有大量的教程，而实际的实践伴随着大量的解决问题的过程，这里只讲入门的实践。
●首先，可能要在某个配置里添加或开启编译选项：
androidboot.selinux=permissive security=selinux
●然后，可能会遇到上百成千个问题，对着问题解决吧。
●获取SELinux permissive log分析生产策略方法：
■安装audit2allow环境
■过滤 avc log ：dmesg |grep avc
■ audit2allow -i avc_log.txt
在配置SELinux安全策略文件的时候，遇到了很多问题，归纳起来有下面几类：
图 185
造成这些问题的原因如下：
由于懂得配置SELinux策略的工程师，不太清楚软件进程及其需要访问的客体资源是哪些，而编写该软件工程师又不清楚SELinux的原理，所以SELinux配置也是一个考验耐心和沟通的工作。前面的“安全系统服务接口”也往往由于SELinux的配置错漏导致莫名的接口访问出现问题，而负责该软件的工程师往往以为是系统接口安全机制导致的。
当时花费了大量的时间在配置 SELinux，而配置 SELinux 又枯燥又没有什么可以写的，这才是做安全的大部分工作实质。
本节的安全通信是为了解决前面所说的图片劫持所采取的方案，更加完备的安全通信技术，在后面的章节里。
本措施是关键数据保护措施的补充。
这既有那场论坛做的引子：
图 186
也有自身发现的问题：云端的照片被非法替换的问题。
更多的信息看前面的“关键数据保护措施”里的内容。
图 187
而出现这些原因的根源是：采用了CDN加速并且使用HTTP。
直接把HTTP修改为HTTPS会有出现其他一些问题。
直接把终端请求资源的链接从HTTP修改为HTTPS，需要一些前提：
●CDN本身支持HTTPS请求：好在所用的CDN是支持HTTPS的；
●所有业务需要合法的证书：大部分资源需要更换CDN加速的域名，还有有些需要购买证书；
●终端需要改造校验证书；
●对于需要识别资源，好在前面的关键数据安全措施里面已经识别了。
和云端的资源通信会分两种情况：接口资源（后面简称接口）和静态资源（图片、视频等）（后面简称资源），这就可以推导出下面几个方案。
（1）方案一，部分HTTPS
该方案只是对接口进行HTTPS传输认证，没有对资源进行HTTPS加密传输，只是在终端会再次确认资源是否合法（参考前面的关键数据保护措施），主要因为各种图片视频采用HTTPS，消耗还是比较大，修改量也会比较大，有些应用没有CDN证书。
图 188
特点：
●可以防止接口协议被劫持；
●可以防止图片被篡改；
●服务器必须保存一份资源清单；
●增加一次传输认证，可能会影响用户体验。
（2）方案二，全部HTTPS
该在上面的基础上，对静态资源也采用HTTPS通信。
图 189
特点：
●可以防止接口协议被劫持；
●可以防止图片被篡改；
●需要CDN支持HTTPS加速；
●CDN服务器需要支持证书；
●电视应用都需要改动，改动量比较大。
（3）方案三，动态IP
图 190
特点：
●可以防止DNS劫持，即相当于自建了DNS服务器；
●无法借助CDN加速；
●一般只有专业的云提供商才用这种方式，如百度、阿里、腾讯等。
最终在关键的几个项目上采用了方案二。
以下安全措施要不是采取三方的方案，要不就只是研究并没落到实处。
在整个智能电视安全建设过程，还通过封装外界安全SDK实现自身安全能力的工作，主要是这样可以快速打造自身通用的安全技术与检测能力。（三方方案）
图 191
当时选择的第三方SDK是某度的SDK，基于此之上会建立自己的黑白名单机制。
图 192
第三方SDK有自身的恶意应用等信息，可以自建黑白名单机制获取这些名单后传到云端进行存放，云端也有维护人员定期更新一些新的名单上去，这样其他应用就可以使用，自身的黑白名单的数据会建立在前人的基础之上逐渐增大，而维护人员的数据来源可以使用其他的安全软件进行测试后得出。
系统分区校验dm-verity对于保障安卓系统存放重要数据、系统软件等分区的完整性安全性非常重要，这个机制至关重要。下面的描述来自网络：
dm-verity是Device mapper架构下的一种目标设备类型，通过它来保障设备或设备分区的完整性，它的典型架构是如图一。
dm-verity类型的设备需要两个底层设备，一个是数据设备，顾名思义是用来存储数据，实际上就是要保障完整性的设备，另一个是哈希设备，用来存储哈希值，在校验数据设备完整性时需要。
图 193
图中映射设备和目标设备是一对一关系，对映射设备的读操作被映射成对目标设备的读操作，在目标设备中，dm-verity又将读操作映射为数据设备（Data Device）的读操作。但是在读操作的结束处，dm-verity加了一个额外的校验操作，对读到的数据计算一个hash值，用这个哈希值和存储在哈希设备（Hash Device）中的值做比较，如果不同，则本次读操作被标记为错误。
图 194
应用层需要执行下面三步初始化dm设备。
①创建dm设备
open /dev/device-mapper设备节点；
传入逻辑分区name、随机生成uuid参数，调用DM_DEV_CREATE ioctl命令。
②载入verity table
上层通过镜像固定位置获取到信息并初始化好verity table；
通过调用DM_TABLE_LOAD ioctl 命令将verity table传递给kernel。
③激活 dm device
调用DM_DEV_SUSPEND ioctl命令激活dm device。
内核原理比较枯燥，不详细赘述。
至此，应该就是解BUG的时候了，解完问题就能够使用了。
牵头的安全团队没有实际操作过dm-verity的启用的，是通过向SOC方案商提要求让他们增加这个功能而把该功能落到了物端。
终端管理是厂家为了解决用户产品、改善用户体验，在线售后的一个管理系统，所以对该系统安全要求得比较严格。
必须使用严格的安全通信机制以及证书校验机制进行安全设计。
图 195
（1）云端管理服务的前端对后端认证
●前端会对后端采用HTTPS/WSS协议进行认证。
（2）云端管理服务的后端对前端认证
●后端会要求前端采用微信登录，使用暴力破解方式可以破解用户名/密码的登录形式；
●微信登录后，会要求绑定公司邮箱，进行人员的身份鉴权；
●进行身份鉴权后可以获取，前端就可以获取后端相应的权限。
（3）终端管理客户端的前台对后端认证
●客户端前台会采用行业标准HTTPS/WSS协议对云服务后端进行认证；
●客户端需采用独立的证书，不采用公钥证书，要不会被仿冒；
●客户端需采用SELinux，要不终端上的其他应用可能会利用终端管理客户端的资源。
（4）云端管理服务的后端对客户端的认证
●后端对于客户端采用HMAC签名认证，内容包括时间戳、设备信息、密钥等。
（5）终端管理客户端内部通调用安全
●内部之间的接口调用采用和 4.2.6 安全系统服务接口类似的接口鉴权方式保障安全。
（6）云端管理服务内部调用安全
图 196
●后端内部会采用权限管理器Permision Manager，决策所有访问是否有权限；
●所有权限调整的操作，只能在堡垒机上执行，堡垒机会记录所有的行为；
●授权管理是面向管理及工程师的功能，角色有超级用户、用户、管理员。
（7）终端管理客户端后台
●这是数据上报给云端的一个服务；
●客户端前台在可信连接到云端的时候会根据证书生成token；
●该token会传给该后台；
●该后台通过这个token会和服务端进行认证；
●认证通过，就会上报数据给云端；
至此，整个终端管理系统的安全设计就基本宣告完成，主要集中在身份鉴别、强制访问控制、数据的保密性、完整性、真实性上。
这个设计经由其他团队落到终端管理的系统中。
一般方案商都会有SecureBoot，但会由于各种原因无法启用：
●售后难于维修；
●生产线改造；
●开启关闭SecureBoot机制。
这些原因里，生产和售后是最大的阻碍。
以某个芯片的SecureBoot作为原理说明：
图 197
（1）Mask CODE & root_public_key
● Mask CODE 固化在芯片内部，芯片出厂后就无法修改，一般采用一次性熔断机制烧写第一段启动代码，确保第一段代码的安全性；
●root_public_key为安全启动的信任基础，一般由芯片公司烧入Efuse区域，一般由密钥管理系统生成，私钥保存在芯片公司里；
●这是整个SecureBoot这个信任链的信任根，是信任链的第一级；
●Mask CODE会校验存储在EMM/Nand区域里的sboot程序；
●最后，Mask CODE会加载和运行sboot程序。
（2）Sboot & ext_public_key
●Sboot为一小段启动程序，由Mask CODE校验和启动；
●Sboot主要进行硬件模块的初始化，比如给DRAM上电，为Uboot准备；
●Sboot会引导加载OPTEE（可信执行环境）和Uboot；
●ext_public_key会由root_public_key签名；
●ext_public_key是信任链的第二级。
（3）Uboot & sys_public_key
●Uboot为工程师能够操作到的第一个启动程序，由Sboot校验和启动；
●Uboot 会对boot.img和recover.img做校验；
●校验成功后，Uboot会引导启动boot.img或recover.img；假如失败会死机；
●sys_public_key可由机器厂家生成；
●sys_public_key须由ext_pub_key签名保障其安全性；
●假如机器厂家有密钥管理系统，也可以由密钥管理系统认证其安全性；
●sys_public_key是信任链的第三级，一般的SecureBoot就到这。
（4）init & app_public_key
● init.rc 是Linux系统启动的第一个进程，由Uboot引导启动；
●init.rc可根据app_public_key来引导启动系统中的应用、服务、通信；
●app_public_key由机器厂家生成；
●一般来说，一机一密的密钥指的就是该key；
●一个机器里面不同应用可以有不同的app_public_key。
（5）升级影响
●升级boot.img/recover.img的时候，必须升级其签名文件，比如secure_boot.bin；
●升级脚本必须支持签名文件的升级；
●recovery的OTA升级包必须支持安全升级功能；
●OTA升级包和revovery.img必须匹配，这也是信任链之一。
不止一次找过多个方案提供商的FAE，找过工厂工程师，在售后那里了解情况，综合的多次研讨了很长的一段时间，最终这个功能没有落地。
在以前的工作规划里，总会把可信执行环境TEE（optee或Trustzone）作为智能产品电视机的安全技术规划的长期目标。
可信执行环境TEE主要用于运行具有付费功能的应用或者其他需要高可信环境的程序。
假如在智能电视机里配备有TEE，那么很有可能是OPTEE，因为它比较便宜。
这需要了解到它的原理。
（1）架构
TEE可以看做一个独立的系统。
图 198
在普通系统或一般系统REE上运行的程序，简称CA（client Application），会调用TEE的接口，TEE的接口会通过IOCTL调用内核模块里的TEE驱动，而驱动通过消息和TEE的OS进行通信。
Tee-suplicant是一个进程，是安全执行系统TEE访问REE的资源的。
这里面涉及几个鉴权和隔离：
●CA到Tee Client的鉴权；
●从用户空间到内核空间的隔离，Tee Api通过ioctl调用到系统驱动：
● REE内核空间到TEE OS内核空间的隔离；
● TEE OS内核空间到TA的隔离（这个隔离可能没有）。
重重关卡啊。
（2）信任链
图 199
在SecureBoot过程中Sboot的那个阶段就会启动TEE，所以TEE的安全基于SecureBoot信任链，也就是说没有SecureBoot的TEE是不够安全的。
TEE可以看做一个和Linux或安卓系统并列运行的微型系统，在存储空间、运行环境等都做了隔离，由于足够小、足够简单、运行的应用足够少、对外接口可控，被SecureBoot信任链管控，所以认为其足够安全，是可信执行环境。
TEE也可以基于其他安全硬件方案，比如安全芯片建立的信任链。
TEE启动最好能够早于Uboot，越早越安全嘛。
（3）应用
这是个典型的应用，支付宝、微信等应用的支付，可以通过REE系统的TEE接口，把交易信息、个人信息等保持在TEE中。
图 200
安全执行环境中会保存SIMLOCK信息、KMS信息、微信信息、DRM信息等，而TEE里面的密钥，会由可信密钥系统生成，由生产烧录工具烧入。
这也导致需要建立密钥管理系统。（密钥管理系统可查阅第 8 章内容）
通常情况下，可以使用CC认证来评估可信执行环境的安全度，可信就是经过了CC认证。（可查阅第 6 章，CC认证相关内容）
在做电视机安全的时候，还重点搞了应用加固，先是使用开源原理自己搞，到后面采购了第三方（娜*）的应用加固软件，把它放到第 4 章的应用安全里去讲。
上面的安全措施大多都是解决相应的安全问题的，但软件需要有更加基本的保障来指引，这就需要内化安全标准。
注：内化安全标准，把了解到的一些信息、资料消化转化为内部的安全标准或规范。
需要根据已有的、已知的安全技术、安全措施制定相应的安全标准，假如现阶段并无法实施的安全措施或安全技术，被制定进入标准是没有办法执行的，那就失去了意义。
（1）根据已有的信息制定电视系统安全标准的技术要求
●启动安全
要求：启动时，应该基于安全信任链对引导程序、操作系统逐级做安全教育。
方案：建立在系统安全启动上。
●调试端口安全
要求：调试端口不应该直接向用户开发。
方案：建立在ROOT权限控制上。
●安全升级
要求：升级包必须校验后方可升级、若需强制升级，必须提升并告知用户。
方案：已经了解升级安全的重要性，才有了后面的安全升级技术。
●网路安全
要求：应具备防范计算机病毒、网络入侵、攻击破坏等网络安全功能。
方案：建立在安全SDK的基础上。
●信息安全
要求：必须接入有关部门规定的电视平台，禁止内置非法信息，对关键数据必须进行保护等。
方案：建立在有关部门规定上。
●身份鉴别
要求：必须提供专用的身份鉴别模块，必须满足一定的密码要求等。
方案：建立在合作方的要求、工厂模块的密码设计上。
●访问控制
要求：应提供访问控制安全策略对文件、数据库做最小权限控制。
方案：建立在强制访问控制SELinux上。
●漏洞修复
要求：操作系统和第三方软件的漏洞必须及时修复。
方案：建立在安全SDK的基础上。
●升级安全
要求：应具备安全机制防止升级包被解包分析。
方案：已经了解升级安全的重要性，才有了后面的安全升级技术。
●安装安全
要求：应用软件的安装需得到明确的授权，不能破坏其运行环境。
方案：建立在合作方的要求、有关部门的报告上。
●卸载安全
要求：终端应用卸载后，不影响智能终端的使用，包括只自己的删除资源数据、其他应用也能够使用等。
方案：建立在合作方的要求、有关部门的报告上。
●实现安全
要求：不应设计后门、防止被反编译反调试等。
方案：建立在合作方的要求、系统服务接口安全、关键数据保护上。
●资源安全
要求：不应该长时间占用系统资源，不应影响对合法用户的登录和资源的访问等。
方案：建立在合作方的要求、有关部门的报告上。
●数据安全
要求：禁止明文存储个人信息数据，防止被未授权获取等。
方案：建立在隐私合规要求上、关键数据保护上。
●传输安全
要求：禁止以明文方式通过网络传输用户信息等。
方案：建立在隐私合规要求、安全通信措施上。
●跨境传输
要求：向用户所选择的国家外传输的，必须提供原因和数据内容、目的地等资料，并且通过合规性审查。
方案：建立在隐私合规要求、网络数据安全检测工具上。（见第 8 章）
●其他安全
要求：Cookie安全、数据库安全、会话安全、服务器端安全、日记安全、开源组件安全等。
（2）根据安全标准的技术要求确定测试方法
（见第 5 章中安全测试的相关内容）
注：实际的标准文件的每个要求和测试都需要更加详尽地描述。
注：本标准制定过程和目的还可参考书末“跋 2 的制定标准经历”。
通过上面的安全要求和安全测试，建立起基本的安全，以及上面所写的安全技术，就基本能够保障智能电视机的系统安全了。
从上面可以总结出，大部分的方案都需要密钥、签名、证书，而这些密钥、签名、证书的生成、管理等都各种各样。
图 201
●安全工厂菜单的接口鉴权签名在自建云平台申请；
●安全通信证书由应用开发人员自己想办法搞定，一般从CA申请；
●关键数据保护的密钥和签名在数据云端那边管理；
●ADB安全的身份鉴权真是在自建云平台申请；
●安全RootS*服务的音乐鉴权签名在自建云平台申请；
●安全系统接口的签名在自建云平台申请；
●调试端口安全签名在自建云平台申请；
●安全启动的各个密钥，基本都是SOC商家默认提供的；
●最小权限签名在自建云平台申请；
●安全mboot密钥在自建云平台申请；
●TEE执行环境的密钥由SOC商家默认提供；
●ROOT身份鉴权签名在自建云平台申请；
●端口安全身份鉴权签名在自建云平台申请；
●安全OTA的数据签名由软件人员自己管理，可能在OTA升级平台上；
●漏洞修复机制签名在自建云平台申请；
●应用签名密钥由软件人员自己管理。
可以看到，每个安全措施都需要密钥、签名、证书（后续统称密钥），而这些密钥都不知道是怎么生成的，估计很多就是机型算出一个MD5 码作为密钥，这些密钥在机器大多也明文存放着，这些密钥也往往在开发工程师中明文经手的，而且这些密钥基本没有有效期管理。
而应该说明的是，此时的自建证书云平台，没有任何安全防护，只是简单的一个页面，所有证书都是独立的，安全存在很大的隐患。
只要自己想提升产品安全，开发安全技术，就会涉及密钥、签名、证书，所以迫切需要一个统一的安全的密钥管理平台进行管控。
后来才知道欧洲有了 103645，也就是后来的EN303645 物联网基线标准，在第 6 章有详细的描述，这里提前看一下以上措施都满足 303645 的哪些要求。
图 202
大部分的措施都是为了减少暴露弱点的，这很容易理解，调试安全、mboot、RootSxx等实际都是为了研发方便而人为搞出来的弱点，以上安全措施只是控制住这些弱点。
有些措施需要其他手段解决。
●通用默认密码：其实在内化标准中有，只是没体现出来。
●漏洞报告机制：有了后续制定的安全应急响应流程以及安全响应中心。
●个人数据保护：合规工作线的事项，没体现在这里。
●抵御故障能力：这点自身就是常规质量。
●远程安全监控：对应的是安全终端管理，其实也有争议。
●轻松撤销信息：对应个人数据保护。
●更易安装维护：用户体验线的。
有些措施对应上物联网基线要求有些勉强。
●应用加固：可以算是确保软件完整性，但软件完整性的准确措施是签名。
●安全执行环境：这点是保护密钥，机密数据的环境，超过了基线要求。
●数字版权DRM：媒体的措施，不在物联网基线要求内。
可以看到前面做了这些安全措施，虽然直接过不了认证，但为以后电视机能够通过 303645的认证打好了基础（可参阅第 6 章安全认证），而更加后面的法规又对物端提出了更加严格的要求。
第三次战略规划中的得到智能系统的安全框架比搞电视机安全要晚了很长的一段时间，但还是可以对比一下满足了多少要求。
图 203
可以看到由解决问题得到的安全框架（以下简称“本节框架”）和由市场洞察战略规划得到的安全框架（以下简称“规划框架”）有很大的不一样：
●本章节技术满足后面的NIS要求的漏洞处理这个点；
●本章节技术满足了RED要求防肉鸡安全技术的一部分；
●本章节技术满足了RED要求个人数据保护技术的一部分。
就算本章节技术的所有措施落实到位，要满足规划框架的要求，还有很多工作要做。
这就是目前看到的后续智能电视、智能产品的安全技术趋势，但智能门锁的安全建设，倒不主要为了解决问题，也不是为了满足基线要求或以后的法规要求，而是为了建立智能门锁安全竞争力。