从智能锁谈STM32安全技术

一. 安全分析智能锁

1.1 安全概念和保护对象

1.1.1 什么是安全

安全分为2类：

• 功能安全 Functional Safety

  • 不受保护系统的影响随机故障或系统设计缺陷的影响

• 信息安全 Information Security

  • 保护系统不受影响恶意威胁而受损失

本教程的安全是指信息安全！

1.1.2 信息安全三要素

信息安全有三个基本属性(基本服务):

• 保密性（C）：你应该知道，你可以知道；如果你不应该知道，就不要让你知道

• 完整性（I）：真实可靠，信息未修改，未假冒

• 可用性（A）：这个信息总是可以访问的，也可以使用

1.2 智能锁和安全分析模型

1.2.1 什么是智能锁？

智能锁不用于传统的机械锁，由芯片控制

• 结构：机械部件、主控芯片、电机单元、通信模块和各种传感器
• 开锁方式：密码，蓝牙，NFC(智能卡、手机、身份证)
• 连接方式：通过蓝牙，WIFI 或者其他窄带通信技术连接到云
• 安全：有异常监控和日志

1.2.2 资产、弱点、威胁模型

有一个非常成熟的模型来分析设备所需的安全技术资产、弱点、威胁模型：

• 资产：一切都被认为是有价值的对象
• 弱点(又称漏洞):系统的脆弱性
• 威胁：利用系统弱点损失资产价值，恶意第三方获取利益

如果没有需要保护的资产，漏洞和威胁不构成风险，就没有必要制定安全措施。因此，在谈到安全时，首先要确定需要保护的资产是什么。

资产弱点威胁模型表明，所有安全方案只应针对客户服务系统的风险弱点。

1.3 现实中的攻击手段和 STM32 的技术措施

1.3.1 在智能锁中识别资产

需要保护的资产是什么？从锁用户的角度来看，第一个重要的价值是锁的访问权。对于智能锁，保护对象是解锁和关锁的本质：电机的旋转。MCU 发出电机旋转信号的条件和判断过程是安全保护的内容。如果密码解锁，则需要检测密码是否合法。如果密码合法，则发出解锁信号，因此密码是具体资产。

1.3.2 识别智能锁的脆弱性

识别系统脆弱性的一种方法是系统分解、功能分解和生命周期分解。例如，将系统分解成不同的模块可以看到弱点：

• 例如联网：它不仅带来了方便，还带来了远程威胁，如远程解锁
• 例如设计软件和通信协议：如果软件有bug，很容易远程使用
• 例如锁的机械结构：例如，解锁是通过简单的电机旋转完成的，所以理论上有办法绕过它 MCU，也就是说，绕过所有信息安全的保护，直接给电机一个旋转信号，锁就会打开

恶意的人如何将威胁具体化，形成实际的攻击方式？通常有两种类型可以破解带芯片的系统：

• 物理攻击，根据对系统的破坏程度分为：

  • 非侵入性攻击

  • 半侵入攻击

  • 开盖攻击

• 软件攻击，又叫逻辑攻击

  • 抓住系统中的漏洞或弱点，突破系统

  智能锁面临威胁	分类	STM32 安全技术
  设备被破解	设备安全	STM32 SBSFU 安全启动和安全固件更新
  设备被假冒	设备安全	STM32 SFI 安装安全固件 STM32 SBSFU 安全启动与安全固件更新
  通讯被窃听	通讯安全	STM32 TLS 通讯安全
  通讯被篡改	通讯安全	STM32 TLS 通讯安全
  云端被破解	云端安全	云端处理
  云端被假冒	云端安全	通信安全认证云

二. 加解密技术

加解密技术离不开通信安全和设备安全。加解密技术必须在密码背后。

说白了，加密技术就是变换、加密变换及其反变换-解密变换。通过这种转换，可以提供信息安全的三个属性(服务):保密性、完整性和可用性。在讨论加解密算法应用中提供的服务时，我们不讨论可用性，因为算法总是可用的。

同时，广义的完整性细分为：狭义的完整性和认证性，就是完整性与真实可靠分离就这样，加解密技术也有三个属性(服务)，也叫 CIA，保密性、完整性和可认证性（Authentication）。

对称密钥和非对称密钥可以提供保密服务，单个散列函数可以提供狭义的完整性服务，基于非对称密钥技术的数字签名可以提供认证和识别服务，以及基于对称密钥的信息验证码MAC。

2.1 三种加解密技术和历史

• 第一阶段：加解密是艺术，1949年以前

  • 没有统一的标准和理论支持，加解密技术是基于过程(如隐写、特殊墨水)和方法(移位和替换)

• 第二阶段：对称密钥，1949~1976年

  • 1949年，香农发表《保密系统的通信理论》，提出基于密钥的加解密算法。加解密过程可以公开，但密钥不公开

• 第三阶段：非对称密钥，1976~至今

  • 1976年，两位美国计算机学家缩写为 D，一个缩写为 H，发表了文章《解密不传密钥》，即 DH 密钥交换协议
  • 受DH受密钥交换协议启发，3人(名称首字母 R，S，A）发明了 RSA 非对称密钥加解密技术
  • 非对称密钥技术划时代，解决了对称密钥的管理和分发问题

2.2 参数模型加解密

至少两方参与加解密技术定义模型，加密方（Alice）和解密方（Bob）。A 和 B 它们之间的距离可以是空间（例如，从北京到上海，考虑到不同路由器之间的不安全通信连接）或时间（现在你和明天的加密和解密对话）。

A用密钥加密一段明文，形成密文。B收到密文，用密钥解密，得到明文。

根据密钥的数量，有三种情况：

• A 加密密钥和 B 的解密密钥，是一样的，即 1 个，叫对称加密技术
• A 加密密钥和 B 解密钥不同，即 2 称为非对称加密技术
• 特殊情况：A 加密了，B 无法解密，0 称为单向散列函数

2.3 单向散列函数

在加解密技术中，散列=摘要=哈希

加解密技术摘要有两个特点：

• 对原始消息的任何变化都会导致摘要的变化
• 原始消息(原文)的线索不能从摘要中计算出来，这就是为什么单向函数被称为

单个散列函数的用途：

• 提供完整性服务

  • 已知一段数据的摘要，如果数据被修改了，使用前计算下摘要，就知道数据是否被修改或替换了

  • 如果修改了数据，同时重新计算了摘要，此时检查不出来。

    此时的解决方法：

    • 通过硬件技术，比如一次可编程技术（如 OTP）将摘要写进去
    • 通过加密技术， 使用消息验证码 MAC（对称密钥技术）、数字签名（非对称密钥技术）

• 存储敏感信息

  • 反面例子：某知名网站发生了信用卡大泄露，也有某知名网站发生过用户名密码大量泄露的事件。预防措施：不论是网站还是 MCU 人机界面系统，用户的密码应该使用哈希值。用户登录系统时，用户输入的值会被转换成哈希值，与系统里存储的哈希值进行比较，这样即使系统被攻破，用户的原始密码不会泄露
  • 正面例子：区块链系统

构成密码级的散列函数主要是MD5，SHA1，SHA2（包括 SHA-256 和 SHA-512，而 SHA-224 是 SHA-256 的删减版，SHA-384 是 SHA-512 的删减版），SHA3（输出长度： 512、384、256、224、64位）。SHA3 并不是要取代 SHA2，因为 SHA2 目前并没有出现明显的弱点。

CRC32 也是单向函数，但不是加密级单向函数，原因：加密级单向函数要求：不容易构造碰撞，就是已知明文和哈希值，不能轻易构造出另外一个明文对应同一个哈希值。

MD5 和 SHA1 在某种意义上被攻破了，不再推荐使用。

在MCU开发中使用单项散列函数，通常就是2个参数：散列函数的类型、明文。

2.4 对称加密技术

对称不对称，指的不是加解密过程，而是加密和解密所使用的密钥。加密和解密所使用的钥匙一样，称为对称密钥。

对称密钥技术的发展非常迅速，应用简单，使用广泛，各种各样的文件、文本、声音、图像的保密都是通过对称密钥技术来保护的。如果需要保密地传输一个固件，给固件加密的一定是对称密钥技术。如果上网需要 https，最终加密传输网页的也一定是对称密钥技术。

对称密钥怎么使用？对称密钥算法，如果接口封装的好，一定至少有2个参数：密钥、明文。这个密钥参数也很简单，如果是 128 bit，那么密钥长度就是 16 个字节。

通常密钥都很小，然而矛盾的是，大部分时候需要加密的内容都很长。几个 Byte 的密钥长度与几百 MB 大小的文件，如何使用长度很短的密钥对长度很长的文件进行加密呢？

有2种方法：

• 将短的一方，变长。一种是把密钥无限扩展，让密钥的长度和明文长度对应起来。这种就是所谓的流加密。
• 将长的一方，变短。还有一种就是把明文分组，分块。分成一个一个块，这个块大小符合符合加密算法锁需要的明文大小。这就是经常听到的分组加密，分块加密。

对于第一种方法，流加密，存在一个问题：如何生成密钥流和明文长度大小一样。理想情况下，有一份和明文一样长的随机数做密钥，这样当然安全，可是，密钥这么长，怎么记录，怎么传输，都是问题。现实中还是从一个密钥，通过一种算法，进行计算，生成密钥流。

对于第二种算法，分组加密，看上去很好，符合工程技术的常见思维，对问题分解然后针对每个小块处理。但块与块之间是否就是独立的关系呢？块与块之间独立，对带来安全问题。

对于分组加密，如果每个位置上的数据独立，加密出来的数据总是一样，会有问题。同样的道理，如果每次对一个消息报文加密出来的结果都是一样，也会存在安全问题。

• 明文和密文一一对应，可以实施重放攻击
• 明文和密文一一对应，可以实施明文攻击

所以加解密技术也要保证：对于一个文件同样的明文出现在每一处的解密不一样，一个文件今天和明天的加密结果也不一样。如何做到？通过一个初始向量，加上分组连接模式，而这个初始向量是可以公开的，而且每次不一样。

从模型上，如果使用一个对称密钥技术，至少需要2个参数：明文、密码。如果安全点，至少需要4个参数：明文、密钥、初始化向量、分组模式。

对称加解密算法有哪些？

• DES：密钥长度 64 位，实际密码只有 56 位。每一块长度 8 字节。因为密钥长度太短，现在已经被认为不安全，一般不建议使用 DES 算法。如果一定要使用，建议使用3DES，就是把 DES 算法执行了 3 次，每次的密钥都不一样，这样密钥长度就变成了DES 密钥长度的 3 倍。
• AES：密钥长度可以使用 128 位、192 位和 256 位。每一个分块的长度固定为 128 位。
• SM1
• SM4

对称加密算法常用的5组分组模式：ECB（电子密码本）、CBC（密文分组链接）、CFB（密文反馈）、OFB（输出反馈）、CTR（计数器）。

对称密钥具有简单、速度快的优点，但缺点也很明显。在加密模型中，加密方A（Alice），解密方B（Bob）。对称密钥技术下，A 和 B 必须共享同一个密钥，这样 A、B 之间才能进行保密通信。这就引出了一个问题，如果 A 和 B 之间隔了千山万水，怎么样 A 和 B 之间共享一个密钥呢？在这个问题的解决，非技术手段，就是把 2 个需要通信的召集在一起，面对面协商出一个共享密钥。但这个手段，在过去，信息技术不发达、互联网技术不发达的情况下，还可以勉强接受。在今天，我们和每一个网络服务之间都需要随时随地的进行保密通信，面对面协商根本就不可能，这就必须依赖技术手段。这个技术手段就是非对称加密技术，依靠非对称加密来传输对称加密的密钥。

2.5 非对称加密技术

非对称加密技术指的是加密、解密的密钥不相同。

一对密钥：

• 私钥：保留的那个密钥
• 公钥：开放的那个密钥。任何人都可以使用公钥，从而解决了密钥分发的问题。

因为每个人都可以使用公开的密钥对要发送给我的信息进行加密，对称密钥技术又叫公钥技术。

反过来（用私钥加密，发送给所有人），计算上可以，但是保密性已经不存在了，因为我已经把公钥公开给所有人，所有人都可以看到这个秘密。

但是这个方法也是有用的，如果你用私钥加密一段数据，其他所有人都有你的公钥，能够解开验证其中的内容，就证明是你发送的，这样你就抵赖不了，这就是签名技术。不过在签名体制里，就不能叫加密解密，叫它用私钥签名和用公钥验签。

公钥是用来加密的，私钥是用来解密的；私钥用来签名，公钥用来验签。

非对称机密技术，有 2 个主要的用途：

• 保密性服务：公钥加密、私钥解密
• 认证的服务：即数字签名，私钥签名、公钥验签

非对称加密技术提供的保密服务有在密钥管理方面的优点，是否可以取代对称加密技术呢？不行，原因在于性能。非对称加密技术都是基于一些数学难题，即使正常运算，运算量也很大。非对称加密的性能比对称加密要慢一个数量级，无法满足许多通信实时性要求高的场合。

非对称加密技术，性能不能，还有什么用呢？利用非对称密钥在钥匙管理的有点，来传输对称密钥。可以预先设计好的对称密钥，或者临时生成的会话密钥，通过非对称加密技术构造的管道传递出去。

非对称密钥技术目前有哪些成熟算法？

• RSA：基于两个大的素数乘起来。私钥包括模数 n、密钥对 d 和 e；公钥包括模数n、密钥 e。生成模数 n 的素数 p 和素数 q，如果要应用余数定理快速计算，则可以保留p，q。但公钥只能包含模数 n 以及加密密钥 e。

• 椭圆曲线 ECC：指20世纪90年代开始流行的椭圆曲线，是基于离散对数的求解困难。椭圆曲线参数是公开的（加解密的双方都可以拿到），不是生成的，私钥是一个随机数，公钥是私钥运算得到。椭圆曲线参数，包括椭圆曲线多项式的各项系数例如系数a，系数b，以及一个模数p，再加上椭圆曲线的一个参考点G。基点既然是椭圆曲线上的一个参考点，那就是就是以坐标的形式出现的，一个是x，一个是y，私钥则在椭圆曲线基础加上一个随机数，公钥是私钥和基点进行点乘后的结果，同样点乘的结果还是点，那么在代码里公钥就是具有x，y的形式，一个是x，一个是y。

  ECC 与 RSA 相比，RSA 的密码长度较长，比如典型的 2048 位、256 字节；ECC 同等加密强度小于 256 位、32 字节。在密钥长度上 RSA 比椭圆曲线高了一个数量级，10倍左右。

• 密钥协商技术：DH密钥交换协议

  • 原理：乘方
  • 双方共同约定一个乘方的底数g
  • A（Alice）选取了一个随机数x，保密，基于g，计算g的x次方，然后把结果及g发送给B（Bob）。这里并没有把随机数x发送给B，而且因为求对数困难，任何人也无法从g的x次方结果里反推出来x
  • B收到g，以及g的x次方的结果。注意：B并没有收到x。B也选取一个随机数y，保密，同样以g为底，计算g的y次方，然后把g的y次方发送给A。B没有把y发送给A，而且因为求对数困难，任何人也无法从g的y次方结果里反推出来y
  • 最终，A有g的y次方以及自己的x，可以计算出g的y次方的x次方；B有g的x次方以及自己的y，可以计算出g的x次方的y次方。因为乘方的次序是没有关系的，所以这两个值是一样的，共同密码就协商出来了。而窃听的人知道了g的x次方，g的y次方，也知道底数g，还是没有办法求出对数，求出x和y，从而没有办法计算出g的x次方的y次方的结果。

但是所有的非对称密钥技术都不能防备一个问题：加入有人假冒Bob，怎么办？这就是中间人攻击的问题，只有采用数字证书才能解决。因为在任何情况下，我证明我是我，都是很难另不认识的人相信的。数字证书是靠一个可信第三方解决了这个问题。

2.6 数字签名与消息验证码

信息安全的服务除了保密性，还有完整性。信息安全的完整性可以扩展为狭义的完整性服务和认证服务。

如何实现认证服务？就是将单向散列函数与加密技术结合来实现认证服务。主要认证服务有 2 种：

• 基于对称加密技术，称为消息认证码（MAC）
• 基于非对称加密技术，称为数字签名

2.6.1 数字签名

数字签名的一般流程：现将要签名的文档，进行一个哈希运算（比如使用SHA-256，计算出32个字节的摘要），然后将摘要根据一定的标准，组成一个数据块，根据这个数据块，使用非对称加密技术的私钥对他进行签名运算。注意，签名的对象是哈希后的值，这样就避免了非对称密钥的速度慢的缺点。

签名总是随着明文发送给其他用户，因为公钥是公开的，其他用户如果需要验证这份文档是否完整可靠，只要用公钥解开签名中的哈希值，同时再计算一下明文的哈希值，如果这两个哈希值匹配，那么可以认为这个文档是完整并且可靠的。

注意：数字签名是有标准的，不能自己创造签名的算法和格式，否则很容易造成不安全。

2.6.2 消息认证码（MAC）

消息认证码有很多种实现与标准：

• HMAC：将明文和密钥进行组合，然后进行哈希运算，运算后的结果再次与密钥进行组合，然后再进行哈希运算，这样运算后的结果才 HMAC。A 将明文和 MAC 发送给 B 时，B 可以按照同样的过程对明文做个 HMAC 运算。因为有了密钥的参与，若恶意第三方修改或者假冒明文，但是因为他们没有密钥，所以没办法计算出正确的 HMAC。
• 基于AES的操作模式或者分组模式：AES 的 CBC 或者 GCM 模式都是将所有的明文块在加密的密文里通过某种关系联系在一起了，也就是最后一个加密块的结果事实上依赖于前面的所有的明文块。这就起到了狭义完整性的需要。这种情况下，块连接模式，或者操作模式、分组模式，就起到了类似哈希函数的效果。而 AES 本身是有密钥参与的，那么我们只要取最后一个块，或者单独计算的标记值，就成为消息认证码 MAC。

2.7 智能锁中用到的加解密以及STM32 CryptoLib

STM32 提供的加密库 X-Crypto-lib 支持单向散列函数、对称密钥技术、非对称密钥技术，通过了美国密码算法认证体系认证，在实现上安全性得到了保证，也适合在一些有认证需求的MCU产品上。

密码技术可以由软件实现，也可以由硬件加速。**软件加密库可以运行在所有的STM32平台上。**STM32 特定型号有常用的算法加速，可以减轻内核负载，降低功耗。

除了 STM32 加密库，如果用户对认证要求不高，也可以采用一些第三方或者开源的加密实现，例如 mbedTLS 就包含了所有流行的加解密算法的实现。

2.7.1 算法工具

PC 上工具推荐 OpenSSL，是个命令行工具，支持所有的主流算法。

2.7.2 智能锁需要的加解密算法

从前面的安全分析中，可以知道，智能锁最需要保护的用户开锁的权利，制造商的知识产权，以及用户的隐私。

• 开锁的权利事实上就是如何在系统中产生一把数字化的钥匙，这把钥匙可以不要求保密，但必须完整可靠。那么数字签名技术肯定是必须。对于 MCU，推荐使用椭圆曲线算法 ECC 以及 SHA256 来实现数字签名技术。

• 知识产权保护涉及到固件安装或者升级时的保密，肯定需要对称加密技术，推荐使用AES 算法。同时，在启动时要检测固件是否已经被破坏，则需要数字签名技术（推荐ECC + SHA256）。

• 保护用户隐私，则应当使用对称密钥技术（推荐 AES）进行数据加密。

• 对外界通讯（包括云端）安全则需要依赖 TLS，TLS 几乎需要所有种类的加解密算法。

三. 通讯安全

现实的系统已经不再是信息孤岛，物联网更是提出了“万物互联”的口号。一个 MCU，小到和周边其他芯片进行协作，大到和云端进行通信，上报数据、接受指令，如何保证这些数据、指令不被修改、假冒、窃听，已经是一个基本需求。对于通信安全的主要部分，网络安全技术，在 STM32 MCU 上有个轻量级的 TLS 实现，已经被作为中间件集成到 STM32 CubeMX。

TLS 的实现本身是一个密码学技术的集成，非常复杂，实现了保密，完整，身份认证，消息认证的服务，大家最关心的还是如何使用 TLS。本章不仅介绍 TLS 的基本原理、身份认证、密钥协商、通信加密，并帮助你解决 TLS 中的问题，比如，选密码套件为什么不再推荐使用 AES-CBC 这个加密模式了；为什么推荐 ECDHE 进行密钥协商，不再推荐使用 RSA 的公钥加密了。

本章中介绍如何使用 STM32 Cube mbedTLS 来解决实际问题中的网络安全问题，更进一步，通过对 TLS 的来龙去脉进行剖析，可以使用类似于 TLS 的理念来解决几个典型问题：

• 如何安全的与同一主板上外围芯片进行安全通信，例如 WiFi 模组，以及安全芯片等
• 在特定 MCU 资源受限的情况下，如何构造轻量级的网络安全方案，例如，若不使用TLS，如何在网络上进行安全的通讯

本章重点：

• 点对点通讯与端对端通讯的区别
• 通讯有什么样的威胁，安全威胁来自什么样的弱点
• 常用的 TCP/IP 模型和 TLS 位于哪个层次
• SSL、TLS、HTTPS 是什么关系
• 密钥协商如何保证前向安全
• 身份认证的数字证书为什么需要链式结构
• 如何避免中间人攻击
• STM32 Cube TLS 从哪里获取

3.1 智能锁面临的远程威胁

网络联网可以小规模组网，也可以直接连上 Internet。

• 小规模组网，则多个设备在某个空间区域组成一个内部的网络，这种情况下，信息在这个局部网络之间流动
• 连入 Internet，则设备能够通过 Internet 向服务器发送消息，也可以从服务器接收消息。

无论设备是与内部的服务器通讯，还是与存在于 Internet 中的云进行进行消息交互，一旦组成网络，就面临通讯链路上的威胁（信息被窃听、被篡改、被假冒）。

什么样的系统弱点导致如此肯定系统会受到威胁？

• 连接方式不安全

  连接方式主要分为2大类：有线连接和无线连接。

  • 对于使用集线器连接的局域网，可以相互监听通信数据包。以太网的所有通信信号都在同一个链路上传送，即使是设备 Alice 向设备 Bob 发送消息，同样的消息也会发送到该子网中的每一台终端。WireShark 软件可以用来分析数据包，也可以用来监听一个小网络内的所有节点之间的通信。可以使用交换机代替集线器来增强安全性，然而，传统线路上的数据还是明文的。
  • 对于无线连接，信号本来就散布在空中，本质上就是不安全的。比如 GSM 伪基站。

• 中间节点不安全

  • 两个节点之间没有其他中间环节的通信，称为点对点通信 Point to Point； 通信中间可能经过各种各样的网关，各种各样的路由节点，称为端对端通信 End to End。

  • 在端对端通信中，一般需要经历很多个环节，例如我的手机通过 App 向我家中的空调发送一条指令，我的手机要通过移动运营商的基站，也要经过云端服务器，同时要经过一系列骨干网路由器，再连接我所选择的网络服务商，最后通过我家的WIFI 热点发送给我家的空调。环节多，任何一个环节出了问题，那么这个风险就存在了。假设其中的任何一个节点因为病毒，或者操作失误，就会导致我们的信息被泄露、被篡改。处在这种网络威胁中，如果智能锁仅仅按照传统的嵌入式设备来进行编程，那么开锁命令可能会被假冒。恶意的人可以捕获开锁命令，再次向锁进行发送；或者锁的密钥下发可以被其他人完整的获取。

• 无法确定通讯对方是否可靠

  • GSM协议不去校验服务器端，无法知道基站的真伪，就冒出了很多GSM伪基站。
  • 因为通讯线路是对所有人可见，那么我们希望通讯线路上流动的数据是加密的，而且是可靠的。这里有一个安全考虑，仅仅保护最后一公里是否可以？是否可以相信骨干网上所有的中间节点都是安全的？结论是：不能做这个假设，骨干网上的节点也处在危险之中。要做端到端的加密和消息认证，而不是某一段点对点的加密与认证，好处：不管中间任何环节点被攻破了，或者被修改了，它都不能获取我们的秘密。

互联网上两个节点之间的通讯，永远面临一个问题，怎么相信对方就是我应该谈话的那个人呢？所有一定要对其进行认证，最好是双向认证，这些需求叠加在一起的一个典型实现就是 TLS。

3.2 TLS基本原理

TLS（Transport Layer Security），意指传输层安全，是解决网络安全的重量级武器。

TCP/IP 的四层模型：物理层、网络层、传输层、应用层。TLS 层位于传输层和应用层之间。

3.2.1 TLS的成长史

TLS发展历史:

• SSL1.0，1994年

  是个不成熟的版本，网景公司并未对外公布

• SSL2.0，1995年 网景公司对外发布，但是被认为是一个不安全的协议版本，具体表现在：

  • 哈希函数使用了 MD5
  • 握手消息没做保护，易遭到中间人攻击
  • 消息完整性检查和消息加密使用了同一个密钥
  • 可以很容易中断会话

• SSL3.0，1996年

• TLS1.0，1999年

  基于SSL3.0，可以看成 SSL3.1。该版本使用非常广泛。

• TLS1.1，2006年

  主要是BugFix

• TLS1.2，2008年

  • TLS1.1 和 TLS1.2 都没有发现明显的安全缺陷
  • TLS1.2 提供了较先进的待认证的加解密方式（AEAD）

• TLS1.3，2018年

  • 将之前协议中加密传输前，额外的2个来回的握手简化为1个来回
  • 减少了密码套件的选择，不再有 3DES，RC4，AES-CBC，SHA1，MD5选择
  • 取消使用RSA做密钥交换的方式

3.2.2 TLS的一般原理

3.2.2.1 两阶段协议

TLS 是一个两阶段协议，一个是握手阶段，一个是应用数据加密传输阶段。

3.2.2.2 TLS子协议

• Sub Protocol
  • Handshake Protocol 握手协议
  • ChangeCipherSpec Protocol 改变密码规格协议
  • Alert Protocol 警告协议
  • Application Data Protocol 应用数据协议
• Record Layer Protocol 记录协议层

3.2.2.3 TLS握手

握手阶段有3个目标：

• 关于密码算法达成一致
• 关于密码算法的参数达成一致，因为密码算法的参数是一个主密钥分割而成，这里是如何生成主密钥
• 验证对方身份，建立信任

过程：

• 首先，客户端向服务器打招呼，发送Hello消息。Hello消息包括：①自己的版本号；②会话ID；③随机数（这个随机数是一个输入，用来创建会话的对称密钥，初始化向量以及消息验证码密钥）；④一些建议的密码套件，包括什么样的密钥协商算法、签名算法、哈希算法、会话对称密钥算法以及验证码算法。
• 服务器端看到客户端向它打招呼，要根据客户端打招呼的信息，决定选择哪种加密算法。虽然客户端有它的喜好，但是服务器也要根据自己的实际情况作出选择，然后同样要发送Hello消息，包括：①自己的版本号；②会话ID；③服务器生成的随机数（这个随机是一个输入，和客户端的随机数一道，作为输入，用来创建会话的对称密钥，初始化向量，以及消息验证码密码）；④如果服务器返回所选择的算法；⑤同时返回给客户端服务器的证书；⑥如果必要，服务器可以要求客户端提供证书。
• 双方打了招呼，则需要进一步协商生成一个主密钥的前密钥（pre-master secret）。这个密钥的生成方式又有两种，一种是由客户端生成，通过证书的公钥加密发送给服务器端；另一种是客户端与服务器端基于DH协议的各种变换，各自生成。密钥生成方式是在 Hello 消息中选择并达到一致的。
• 一旦双方有了生成主密钥的基础（主密钥的前密钥、客户端随机数、服务器端随机数），双方可以根据一致的算法PRF生成主密钥。主密钥拆分成3组密钥：①消息验证码密钥；②初始化向量；③用来加密的对称密钥。
• 这时客户端可以向服务器表示要改变加密方式，进行加密通讯。同样服务器也可以做同样的表示。
• 于是握手阶段完成，双方达到同一个状态，同时获得了所有进行加密通信的参数，就可以进行第二阶段应用加密。

3.3 身份认证

3.3.1 证书

如果进行安全通讯，最基本的前提就是在通讯双方建立起信任。所以，在TLS握手中需要进行身份认证。

对于网络设备来说，每一个设备，都需要一个身份证，在网络中，被称为证书。

证书有统一的国际标准来规范，即 X.509 证书，包括：

• 证书的有效期信息：从什么时候开始，到什么时候结束
• 证书的所有者信息，颁发给谁
• 证书的颁发机构，由谁颁发
• 证书的公钥
• 证书的公钥算法
• 证书的签名

X.509 证书，为什么要包含这些信息？这些信息有几个层次：

• 一些简单可判断的信息
  • 对方很容易从证书里判断这个是否快过期了，这个证书的所有人到底是谁。如果这两个信息都不对，那么这个证书就会判断为危险
  • 要检查证书的颁发者，或者这个验证人。如果这个颁发机构本来就臭名昭著，那马这个证书就很危险。或者是自己验证自己，这样就无法从信任链上自动验证。
• 与算法有关的信息
  • 允许对方来验证演示的算法材料，如公钥、公钥算法以及签名。
  • 签名不是一个简单的数字。首先，签名所用到的信息，他是除算法 ID 和签名自己之外的所有信息，也就是对有效期、所有者、颁发机构，包括公钥在内的所有信息，做了个哈希（摘要），然后再使用非对称密钥的私钥对其进行一个签名运算。这个签名运算的结果，没有正确的私钥的人，无法算出一模一样的结果。

当我们获得了一个服务器的证书，如何验证该服务器是否正确？是否被别人修改了？验证证书是否完整可靠，是通过验证证书的签名完成的。证书里包含了公钥，我们公钥将这个签名值解开，得到一个哈希值。我们同样要对除了算法 ID 和签名之外的所有信息做个哈希运算，然后看看这两个哈希值是否一样，就知道这个证书有没有被修改了。

那么证书即使是完整的，我们又怎么详细对方是证书的所有者呢？我们要发起一些只有数字证书的合法所有人才能完成的操作，并给出回应。例如，我把后面的会话密钥的前主密钥，就是通过这个数字的证书的公钥加密，或者与这个数字证书的私钥紧密关联，那么如果对方不是证书的合法所有人，就没法将对话进行下去。

3.3.2 中间人攻击

还存在一个风险，如果另一个人 E 也宣传我是我，他也产生一对公钥私钥，用私钥对证书签名。然后 Alice 向 Bob 申请证书，他在半路截胡，把自己的证书发给 Alice，然后继续请求 Bob 发出证书给他自己。同样，如果双向认证，Bob 向 Alice 申请证书，这个恶意中间人E，就同样把自己的证书发送给 Bob。此时，如果 Alice 拿到的证书不是 Bob 的，而是这个恶意中间人 E 的证书。同理，Bob 拿到证书也不是 Alice 的，也是这个恶意中间人 E 的。这就像人与人之间谈话，如果需要中间人传话，中间人完全可以无中生有弯曲双方的真实意图。

如果没法方法区别开来，这个恶意中间人 E 可以把 Alice 发出的所有的消息全部解密，因为Alice 使用的所谓 Bob 的公钥，实为恶意中间人 E 的公钥。接下来，E 可以看情况是否修改这个报文，也可以不加修改，只是看看有什么样的秘密，然后就把这样消息通过真实的 Bob 的公钥发送给 Bob。Bob 完全不知道有个恶意中间人 E 盯着 Alice 发送给 Bob 的一切。以此类推，对于 Bob，恶意中间人也可以进行同样的操作。这样 Alice 和 Bob 都以为正在和对方进行保密通信，实际上数据已经被窃听，也可能被修改，这就是所谓的中间人攻击。

如何应对？一种方式是使用可信的方式交换证书，即只相信那些手工检查后，手工接受的证书。对于 STM32 等资源受限的设备，有时候应该采用这种方式：直接先烧录一些证书，同时关联某些服务器。它表示我们在连接服务器时，会直接相信其关联的证书。但这种方式没法用在要跟很多并无直接的面对面接触的网站，因为数量就过于庞大，且无法更新。而且，并非所有人都具备这个能力去检查证书的真伪，这就需要一个根证书和证书链。

3.3.3 根证书和证书链

我们需要一个根证书，这个根证书是我们所信任的。如果没有这个根证书，那么就等于没有一个集中式的信任。当然，也不是没有办法，例如，把这个证书抛出来，让大家投票，如果打分人觉得可信，我们就接受它。这个分布式的信任解决方法，是区块链中所用到的技术。这个技术从效率上讲是非常低的，并不适合于一般的网络情况下。因此，根证书是非常必要的。

根证书从哪里来？有一个机构叫 CA 授权中心，是可信的。我们就在设备里预先烧好这个根证书。这样，当我们收到一个外部的证书时，可以从陌生证书的链条，一级一级向上验证，看看最终能不能归结到这个根证书。如果能，那么这个证书是可靠的。

有些网站的证书不能通过验证，就会弹出警告给用户，问是否你能接受，这种情况要小心处理。比如，一个代理服务器希望你接受它的证书，那么通过该代理服务器的所有访问都可能被破解。因为这个代理服务器充当了中间人的角色。

如果去抓 TLS 的握手协议报文，在服务器返回的证书链中，一般至少有两个证书：服务器的证书、CA授权中心的中间证书。不能直接发送根证书，否则自己证明自己，很容易被伪造。

3.3.4 单向认证与双向认证

很多网站服务器提供内容的服务，并关心连接的客户端是谁，也就是说，谁都可以连接它；而客户端关心连接的服务器是否真实。例如我想连接工商银行，需要确定是工商银行，否则，这个发送的密码及产生的交易，就可能存在风险。

对于物联网设备，你能否享受云服务，而通常云服务不是免费的，那么云端一定要认证设备，否则这个云就是免费的云。同时，如果我的物联网设备的很多数据是有价值的，那么物联网设备希望云是可靠的。这种情况下，物联网设备就需要验证这个云的证书。因此，在大部分情况下，物联网设备和云端，在通信安全上执行的是双向认证。

3.4 密钥协商与通信加密

3.4.1 密钥协商

通讯线路上如果要对消息进行保密，我们需要对称加密；如果需要对消息进行认证，则需要对称密钥。所以最终所需要的密钥有3个：

• 消息加解密的对称密钥
• 与对称密钥相关的初始化向量
• 对消息进行认证的密钥

TLS 这3个密钥是从一个叫主密钥 Pre Master Secret 通过某个固定算法 PRF 伪随机函数派生而来的，而且这3个密钥，各不相同。否则，一个被破解，会导致另外一个也被破解。

那么这个主密钥是从何而来的呢？从一个前主密钥 Pre Master Secret 通过某个固定算法 PRF 伪随机函数派生而来，这个伪随机函数的输入包括这个前主密钥、加上双方Hello消息里的随机数。

Pre Master Secret 的产生则具有不同的方式和不同的安全效果。

第一种是基于 DH 协议。DH 协议允许在不安全的通信信道上，发送双方的公钥，然后根据双方的公钥及各自不公开的私钥，计算出一致的 Pre Master Secret。

第二种是基于 RSA 协议构成的公钥加密通道。握手阶段，服务器回复的Hello消息中包括了证书，证书可以用来验证身份，同时证书提供了服务器的公钥。客户端可以采用这个公钥，将前主密钥 Pre Master Secret 加密的信息传递给服务器。这样双方可以获得获得一致的前主密钥 Pre Master Secret。使用 RSA 协议进行密钥协商因其不具有前向安全性，在TLS1.3 中已经被删除。**前向安全：长期使用的主密钥泄露不会导致过去的会话密钥泄漏，而那些会话的内容也不会因某个主密钥的泄漏而被破解。**在今天的海量存储的时代，是存在先保存，后破解的可能性。例如，有人暂时不能破解通信双方的密钥，但是当其存储所有双方的来往信息，期望有一天能攻破某一方的私钥后，获得某个密钥，从而破解通讯内容。假设我们使用静态的固定密钥，这个静态的固定密钥总会存在某个地方，如果有一天，黑客利用 OpenSSL 的 HeartBleeding 漏洞或者其他手段攻破这个系统，那么以前的所有存储的会话就破解了。我们认为这种系统就不具有前向安全性。

单纯的 DH 协议是不能防备中间人攻击的，因此 DH 协议中所使用的公钥必须要经过认证。在这种情况下，我们一般使用基于椭圆曲线的 DH 协议就是 ECDH，这是第三种产生前主密钥 Pre Master Secret 的方式。

如果使用证书中静态的公钥来进行 ECDH 密钥交换，那么静态私钥与公钥对的多次使用，会增加密钥对被破解的风险，从而将服务器的证书置于风险之中。可以通过为密钥交换生成临时的公钥私钥对来防范风险。

3.4.2 通讯加密

双方都获得所有的安全参数之后，就可以进行应用数据的加密。对于应用数据，仅仅是加密肯定不够，还存在中间人攻击的风险，中间人有可能篡改消息，如重放或者打乱顺序等等。所以，还需要对它进行消息认证。那么，是否只要使用了认证就完事大吉呢？答案是如果使用的认证方式不对，如 AES-CBC，依然可能会遭到中间人攻击。

在最早的TLS实现里，实现加密的方式是：①先对消息认证，也就是计算 MAC，包括头部、序列号、消息本身；②然后进行补齐；③最后进行加密。实质上，这种方式存在很大问题，很容易遭到中间人侧信道攻击。

来看一看具体的算法内容。

填充算法依据是 PKCS#5 或者 PKCS#7 标准。对于 AES， 块的长度固定为16个字节。那么如果需要填充1个字节则是为 01， 如果是需要填充2个字节则是 02 02，如果需要填充 3 个字节则是 03 03 03，那么如果什么字节都不需要填充是16个0，也就是0的个数是分块的长度。所以对于 AES 算法，填充后最有1个字节，只有16种可能。

典型的加密认证算法有 AES-CBC，但是 AES-CBC 这个块加密模式的特点是密文块连接模式，也就是前一个密文块和后一个明文进行 XOR，然后再去加密。

在TLS实现中，TLS 服务器会按照下列顺序相应：①解密；②检查Padding格式是否正确；③检查MAC是否正确。第二步对最后的填充字符给出响应，会告诉我们这个填充字符是否正确。我们在此不用实际的返回码，使用1简单表示正确，使用0简单表示错误。那么：

• 固定的填充格式
• 有单独的错误码1或者0；
• CBC的密文块连接方式

就构成了TLS的一个协议层次上的弱点。

AES-CBC 解密的过程是，先单独对一个密文块进行 AES 解密运算，得到中间结果，然后让中间结果与前一个密文进行 XOR。由此看出，改变前一个密文会影响输出的明文。

伪造前一个密文块，接上一个正确的密文块，看看出会出现什么。第一个目标，是让服务器相信明文中的填充字符是 0x01。我们不知道解密的中间结果是什么，但是我们只要不停地改变伪造的密文的最后一个字节，总共有 256 种可能，总有 1 次让服务器输出 0x01。一旦输出为 0x01， 服务器就会返回 1，表示正确，接下来尝试结束。服务器告诉我们，在这种情况下，明文的最后一个字节是 0x01，前一个密文是我们伪造的，我们是知道它是多少，只要将 0x01 与伪造的前一个密文的最后一个字节 XOR，就可以得到正确的中间结果的最后结果。如法炮制，很快就可以得到整个正确的中间结果，这时，当将前一个密文换成保存的那个块后 XOR，在没有密码的情况下，我们就知道了明文。

这时，我们只需要尝试 256 x 16，而不是 256 的 16 次方，即可得到一个块的明文。这不是说 CBC 不安全，更不用说 AES 不安全，但是将①固定的填充格式；②有单独的错误码1或者0；③CBC的密文块连接方式加在一起就不安全了。

这就是 TLS1.3 去掉 AES-CBC 模式的原因。理解此原因后，在使用 TLS1.2 的过程中，选择密码套件应该有清晰的方向。

3.4.3 STM32 CubeTLS库

TLS 在 PC 上的实现就是大名鼎鼎的 OpenSSL。对于 STM32 MCU，根据单片机本身 Flash 及 RAM 大小，可以达到不同的实现。下表列出了各个公司支持 STM32 的 TLS 实现。

公司	方案名称
arm	MbedTLS
CypherBridge	Embedded TLS SDK
HCC	VerifiableSSL/TLS
Oryx Emb	CycloneSSL
SEGGER	emSSL
ST	STM32 Cube-TLS
wolfSSL	Embedded SSL Library

对于商用用途免费主要是 MbedTLS，同时 MbedTLS 是 CubeMX 所支持的中间件。

如何将 MbedTLS 在 STM32 上使用起来？ ST 推出的每一个云连接的开发包，都包含 MbedTLS，里面的代码是可以运行的。如果觉得云连接开发包里的 MbedTLS 太复杂，可以从 CubeMX 出发，自己修改 MbedTLS 的配置文件。如何配置？主要是密码套件的选择，强烈推荐使用：

• 传输前主密钥 Pre-master secret，选择基于椭圆曲线的 DH 密钥交换协议，不要选择基于 RSA 加密方式
• 身份认证可选择基于 RSA 或者椭圆曲线的数字证书
• 选择带认证的加密方式，如 AES-GCM
• 选择 SHA256 作为密钥派生的哈希函数

如果还是认为 mBedTLS 太大，怎么办？可以考虑其他协议。因为 mBedTLS 所提供的安全服务也是保密、完整、可靠。如果事先想服务器的证书或者等价的身份信息写进 STM32，将客户端的证书或者等价的身份信息写进服务器，则握手这个环节将大大简化。对于在 MCU 和 云端之间定义更加轻量级的 TLS，国内一些知名互联网公司已着手进行。

3.5 STM32 通讯安全在智能锁中的应用

对于网络安全，取决于智能锁的网络拓扑如何构造。一般情况下，智能锁有3种节点：①智能锁本身；②智能锁服务器；③手机用户。

那么，这里存在多个通讯联系：

• 智能锁设备与服务器
• 手机通过服务器连接智能锁
• 手机通过蓝牙连接智能锁

为了保证通讯安全，希望智能锁设备与服务器之间的连接，是通过 TLS 连接。而手机通过服务器连接智能锁，需要通过两个阶段：通过 TLS 进行加密，在服务器进行解密，然后再次通过 TLS 进行加密。前提是，我们能确定服务器是安全的，或者要对服务器进行相应的安全服务。这种用法可以说明两个问题：

• 安全是一个整体。必须考虑每一个部分的安全。
• 没有最完美的安全方案。TLS 协议是在传输层之上，应用层之下。对于那些不是传输层直接连接的两个节点之间的通讯，TLS 协议需要应用层介入进行解包再打包。

在这种情况下，传递的信息依赖于中间二传手，也就是服务器的安全性。换言之，当通过手机给智能锁发送指令，这个安全类型，尽管使用了 TLS，并不能算是真正的端到端的安全。

如果用手机通过蓝牙直接连接智能锁，发送开锁指令，并不需要过于关于保密性。蓝牙通讯必然是一个很短的距离，这种场景下，恶意的人并不一定通过无线这种方式窃听；即使通过无线方式窃听，因为距离很近，也很容易被发现。但是，指令的完整可靠性必须得到保证，否则，指令可能被记录，然后再在某个时间被重放，这样智能锁就有可能被恶意打开了。指令的完整可靠性可以借鉴 TLS 使用随机数，加上时间，加上序列号进行验证码 MAC 的计算。

四. 安全启动

本章要点

• 安全启动的概念
• 安全启动的重要性
• 安全启动具有不同的实现形式
• 如何使用 STM32 的安全技术来实现安全启动

4.1 安全启动的概念

4.1.1 什么是安全启动？

安全启动总来讲的就是确保设备总是在运行可信的软件。

安全启动 = 安全根 = 根安全 = 信任根 = 根信任

安全启动，前面加了安全二字，意味着这个启动部分具有全部或者部分的安全属性。

• 保密性：
  • 安全启动的代码，部分或全部，不应该被外界所了解；
  • 安全启动可以要求后续代码或者低权限代码，不能访问安全启动的内容；
• 完整性：安全启动的代码，不能被修改、破坏，也不能被跳过；
• 可靠性：启动所执行的代码总是来源可靠的代码。

从而，安全启动至少有 2 层含义：

• 启动位置是固定的；
• 启动顺序是不能改变的

也可以进一步要求：

• 启动代码对后续用户软件应该是不可访问的，或者说是不可见的。

4.1.2 仅有加密是不够的

安全是一个整体，对于一个 IoT 设备，谈到安全就必须考虑：

• 设备安全：要将安全作为一个整理考虑。如果仅仅使用加解密算法，设备也还是会很容易被假冒、被破解
  • 威胁1：修改启动顺序，举个栗子：代码在启动时，有一段算法，先比较某段数据的验证码 HMAC，再决定是否使用这段数据。如果没有安全启动，就意味着可以执行顺序，那么黑客就可以直接修改这段并直接跳转过去。实际的跳转代码最后就是一个标志位，很容易找到。软件的功能被破解了，这个设备也就被破解了。
  • 威胁2：修改启动位置，举个栗子：代码已经投产，烧好在Flash中。只要换个启动方式，比如使用 JTAG 从 RAM 启动，将代码读出来，这样资产就被破坏了。如果里面也包含通讯安全的密钥，那么这个设备的身份也被偷走了。
• 通信安全
  • 孤立的通讯安全是不够的，必须是整体的安全
• 在通讯安全里，一直假定，设备和云已经做了相应的安全保护；或者设备和云端都是在安全的环境里运行，不会受到恶意的破坏。否则，即使使用了具有前向安全的 ECDHE 协议来协商密钥保证通信安全，如果两端的私钥都可能被黑客掌握，那这个算法又能有没什么用？
• 云端安全

安全启动是一个比较宏观，或者说是一个比较层次比较高的安全服务，实现它有多种方式。

如果在 STM32 使用了 RDP level 2，从某种程度上已经实现了一个安全启动。但还需要注意：

• 是否充分使用了 STM32 的硬件安全功能：RDP， WRP， PCROP， Secure User Memory， FireWall， MPU， DAP SW enable/disable， anti-tamper， 甚至 STM32L5 的 TrustZone 等。
• 是否为后续阶段提供了安全执行应该有的安全服务。

4.1.3 安全启动解决了什么问题

攻击者会使用软件攻击加上物理攻击的方法来攻击系统，目的当然是为了实实在在的利益，可能是想获取固件代码，以节省研发成本；可能是想获得身份秘钥，让其他非授权设备获得相应的服务；也可能是想获取更高权限，获得没有购买的服务。

为了保护设备不被破解，不被假冒，我们要采取措施防止物理攻击和软件攻击：

• 最简单的物理攻击是 JTAG 连接，因此在产品出厂之前一定要确保 JTAG 完全连接不上，或者 JTAG 满足一定的条件才可以连接。

• 安全启动通过加解密技术检测信任根的代码是否被破坏或者替换，并拒绝有异常的信任根代码执行。

  最常见的软件攻击是恶意软件注入以及缓冲区溢出， 在安全启动里要加上相应的动态保护。例如，为了保护安全启动的身份密钥，可以将安全启动与后续的用户代码隔离，那么用户代码就没有机会向安全启动代码里注入恶意代码。

• 安全检测为系统进一步执行提供检测与判断，保证下一级代码在执行之前也是完整可靠的。这样，从安全启动开始，完整和可靠的特性一级一级的传递下去，也就是说，安全启动构造了一个软件执行的信任链。

4.2 STM32安全启动架构

4.2.1 安全启动在STM32中的实现

安全需要一个起点。安全启动要求启动的位置一定是固定在某个地方，启动位置靠什么保证？必须靠硬件。软件本身的特点，决定了它很容易被修改，即使做了加密和加扰，破解难度也依然比硬件低很多。所以，安全启动一定要靠硬件来保证，脱离硬件谈安全启动，基本上是不可能的。

实现 Root of Trust（信任根）通用的做法是什么？一般是，芯片有个 Bootrom 启动只读存储区。硬件的设计保证，芯片加电启动一定是从这个只读的甚至不可见的 Bootrom 里执行。

事实上，保持安全启动的原则不变，实现方式可以不一样。Bootrom 如果直接固化在芯片里，会减少灵活性，无法适应 MCU 的广泛应用场景。所以，STM32 采用的是使用 STM32 硬件技术，允许客户在开发过程中形成 Bootrom，Bootrom 具有安全启动的几个特征：

• 启动位置是固定的
• 启动顺序是不可修改的
• 启动代码或者核心部分对后续代码是不可见的

4.2.2 安全启动的STM32软件架构

STM32 SBSFU 架构分为3层：

• 驱动层，包括 BSP 以及 STM32 HAL
• 中间件层，包括 STM32 Cryptolib，以及安全引擎。安全引擎提供了 Secure Key Storage 安全存储密钥的服务，以及安全进行加解密操作的服务
• 应用层，包括 SBSFU，以及用户固件。其中，安全启动与安全固件更新部分，包括了安全配置、用户固件加载，以及为用户固件更新所准备的固件烧录功能

本章重点是安全启动，重点讨论 STM32 如何构建一个安全环境，如何保证下一级固件的安全执行。

4.2.3 在STM32中固定启动位置

复盘下系统的初始执行过程：系统上电， STM32 MCU 根据 BOOT0 和 BOOT1 管脚的配置，再加上软件 BOOT 寄存器，可以确定系统应该在什么地方启动，存在三种可能：

• 从系统内存 System Memory BootLoader 启动
• 从用户 Flash 启动
• 从 SRAM 启动

理论上系统内存可以充当信任根，然而，考虑到系统内存所达到的安全级别和灵活性，我们不希望它从系统内存启动。从 SRAM 启动，如果没有信任根的话，那么这个 SRAM 的安全无法得到保证。因此，只有唯一的选择，也就是 STM32 目前的安全设计方案：将系统固定在用户 Flash 启动。

如何将系统固定在用户 Flash 启动？

根据 STM32 手册，需要使用读保护 RDP。不使用 RDP，首先 boot pin 可以重新拉高或者拉低，从而构成不同的配置；其次 JTAG 可以连接上去，让 STM32 从 SRAM 启动。

读保护 RDP 要设置成2，才能够确保启动位置不会被修改。RDP 设置成 1，是保护 Flash 内容不被读出，并不能将启动顺序固定到用户 Flash。 例如， JTAG 依然可以连接上 STM32，boot 脚依然可以被重新修改。

所有的 STM32 系列都具备 RDP 功能，唯一需要注意的是 STM32F1 系列不具备 RDP level 2 这一设置。

例如，不设置 RDP 为 2，也可以实现可信的安全固件安装。在安全固件安装中，系统内存提供了 RSS 根安全服务，在这个过程中，系统内存充当了信任根，这就是一个RDP 级别1 的信任根。

再例如，如果使用 STM32L4， 将堆栈放在 SRAM2 中，那么在 RDP 1 的情况下，想通过 JTAG 攻击 STM32，例如读 Flash 内容，或者对 Flash 修改，基本不可能。

总结一下，构造安全启动，必然需要设置读保护 RDP，一般设置成2，有些情况下也可以设置为1（这时要确保 SRAM1 不包含任何安全敏感信息）。

4.3 STM32安全技术RDP与MPU

4.3.1 检查安全配置 & 构造安全执行环境

与一般的 MCU 启动比较，STM32 安全启动多了些步骤。

• step 1：检查静态安全环境，如 RDP level、PCROP、WRP

• step 2：配置动态安全配置，如 Firewall、MPU、IWDG

• step 3：验证用户固件

这个安全的执行环境保证了启动的顺序不会被改变，以及启动代码的保密性。

4.3.2 防外部攻击

此处谈的外部攻击，不是把芯片剖开，使用光学 标签： 用于传感器芯片的开放式封装结构2000n外置传感器式智能隔离温度变送器模块用于试件内部预埋传感器的试模