4、SHA-256校验实战：从原理到安全启动

SHA-256，说白了就是一把密码学尺子。它能给任意长度的数据量出一个固定256位的「指纹」。这个指纹几乎不可能被伪造——你改一个比特，指纹就完全变了样。

我在固件安全项目里用过不下十种哈希算法，但SHA-256始终是首选。为什么？因为它够快、够安全，而且硬件加速单元几乎成了现代MCU的标配。你想想看，一个算法能被NIST认证、被Linux内核、被UEFI、被TLS同时采用，本身就说明了很多问题。

4.1 SHA-256算法原理详解

SHA-256属于SHA-2家族，输出256位（32字节）的摘要值。它的核心逻辑其实不复杂：把输入数据切成512位的块，然后一块一块地「压缩」。

我刚开始啃FIPS 180-4标准时也觉得头大，但后来发现只要抓住几个关键点就行：

填充：在数据末尾补一个'1'位，然后补'0'，直到长度模512等于448。最后64位放原始长度（大端序）。
分块：每512位为一个消息块，每个块再拆成16个32位字。
扩展：16个字通过循环移位和异或运算扩展成64个字。
压缩：用64轮迭代，每轮用6个逻辑函数（Σ0、Σ1、Ch、Maj等）和64个常数K。
输出：8个32位工作变量拼接成256位摘要。

嗯，这里要注意：SHA-256的「雪崩效应」非常强。我曾经测试过，只改固件里的一个版本号字节，摘要值就完全不一样了。这就是它能做完整性校验的根本原因。

核心要点：SHA-256不是加密算法，是哈希算法。它不可逆——你不能从摘要反推出原始数据。所以它只适合做校验，不适合做保密。

下面这张图展示了SHA-256的完整处理流程：

4.2 Python实现SHA-256校验

实际项目中，我们很少自己写SHA-256的实现——标准库已经做得很好。但理解怎么用、怎么避免踩坑，是另一回事。

我个人习惯用Python的hashlib库做原型验证。下面这段代码是我在调试OTA升级校验时写的，可以直接用：

import hashlib
import os

def sha256_file(filepath, chunk_size=65536):
    """
    计算文件的SHA-256摘要
    chunk_size=64KB，适合嵌入式固件镜像
    """
    sha256 = hashlib.sha256()
    
    if not os.path.exists(filepath):
        raise FileNotFoundError(f"固件文件不存在: {filepath}")
    
    with open(filepath, 'rb') as f:
        while True:
            chunk = f.read(chunk_size)
            if not chunk:
                break
            sha256.update(chunk)
    
    return sha256.hexdigest()

def verify_firmware(filepath, expected_hash):
    """
    校验固件完整性
    返回 (是否通过, 实际摘要)
    """
    actual_hash = sha256_file(filepath)
    is_valid = (actual_hash.lower() == expected_hash.lower())
    return is_valid, actual_hash

# 使用示例
if __name__ == "__main__":
    firmware_path = "firmware_v2.1.bin"
    expected = "a3f5b8c9d1e2f4a6b8c0d2e4f6a8b0c2d4e6f8a0b2c4d6e8f0a2b4c6d8e0f2"
    
    ok, actual = verify_firmware(firmware_path, expected)
    if ok:
        print("✅ 固件校验通过")
    else:
        print(f"❌ 校验失败")
        print(f"期望: {expected}")
        print(f"实际: {actual}")

经验之谈：分块读取时，块大小选64KB是个好平衡点。太小的块（比如4KB）会增加I/O次数，太大的块（比如1MB）在低端MCU上可能爆内存。我在一个STM32项目里试过，64KB刚好。

这里有几个容易踩的坑，我列出来：

常见错误	后果	正确做法
一次性读取整个文件	大固件（>100MB）内存溢出	分块读取，逐块update()
摘要比较时忽略大小写	明明一样却判失败	统一转小写再比较
用字符串模式('r')打开文件	换行符被转换，摘要错误	始终用二进制模式('rb')
在update()之间重置hash对象	只算了最后一块	只创建一次hash对象

我曾经在产线上遇到过一个问题：固件烧录后校验总是不通过。查了两天才发现，是打包脚本里用了open(file, 'r')，Windows下的换行符\r\n被转成了\n。从那以后，我所有涉及二进制文件的代码都强制加注释# 必须用rb模式。

4.3 SHA-256在安全启动中的应用

安全启动（Secure Boot）是SHA-256最经典的应用场景之一。它的核心逻辑其实很简单：

ROM代码（不可更改）先校验Bootloader的签名和哈希。
Bootloader再校验固件镜像的签名和哈希。
固件运行时还可以校验应用分区和配置数据。

每一级都只信任上一级。这就是所谓的「信任链」（Chain of Trust）。

我参与过一个车规级MCU的安全启动设计，当时架构是这样的：

重要警告：SHA-256只保证完整性，不保证真实性。如果有人能替换你的固件文件并重新计算SHA-256，校验照样能通过。所以安全启动必须配合数字签名（RSA或ECDSA）一起使用。SHA-256负责「有没有被改」，签名负责「是谁改的」。

在实际的嵌入式项目中，SHA-256的硬件加速单元通常直接集成在MCU内部。我记得在NXP i.MX RT系列上，硬件SHA引擎计算一个16MB的固件只需要不到200毫秒——如果用软件实现，同样的数据要跑好几秒。所以选型时，我建议优先考虑带硬件哈希加速的芯片。

最后说一个我踩过的坑：安全启动的密钥管理。曾经有个项目把私钥直接硬编码在打包脚本里，结果代码仓库被泄露，整个产品线的固件签名都废了。正确的做法是用HSM（硬件安全模块）或至少用密码隔离的密钥存储。嗯，这个我们后面章节会细讲。

📚 课程目录

4、SHA-256校验实战：从原理到安全启动

4.1 SHA-256算法原理详解

4.2 Python实现SHA-256校验

4.3 SHA-256在安全启动中的应用