为了实施附加的安全性，一些密码算法也可以指定一组不应从设备公开的常数值。这些存储在设备中的，需要防止未经授权暴露的秘密密钥和秘密值在一系列文章中被称为“秘密密钥”。

秘密密钥存储在设备内部，甚至在设备的整个生命周期中都存在。设备中实施的硬件和软件安全措施必须挫败未经授权的访问尝试，以检索这些秘密密钥。此外，设备中存在诸如根CA证书之类的数据可以公开但应防止未经授权的修改而被公开。

如果可以修改根CA证书，则攻击者可以通过替换伪造的根CA证书，使设备接受任何证书，从而破坏目的证书和安全通信。因此，同样重要的是，不要对设备中的数据（例如根CA证书）进行未经授权的修改。

设备内的安全级别取决于受保护内容的性质。在设备处理用户受限制的数据（如受复制保护的* 视频）的情况下，设备安全的需求比在个人数据（如个人文件或银行交易）的用户私有数据的情况下更为重要。

在用户的私人数据的情况下，通常会发生这种情况，因为用户在破坏此类数据时将遭受直接损失，因此他/她有责任限制对存储在设备中的秘密密钥和其他安全内容的物理访问。

同样，安全数据传输协议的一般实现建议为每个设备使用唯一的密钥。因此，如果任何设备的硬件安全性受到威胁，则不会影响网络中其他任何设备的安全性。

但是，在用户限制数据的情况下，破坏单个设备的秘密密钥会导致损害该设备处理的所有受复制保护的内容的安全性。因此，一个易受攻击的设备可以帮助未经授权的设备访问受版权保护的内容，对其进行解密并分发无数内容。

安全SoC（片上系统 ）可以设计

安全SoC（下面的图4），其中包含必需的硬件和软件支持，以增强设备内的安全性，从而抵御损害设备安全性的物理攻击。

该安全SoC通过在芯片内部保留诸如处理秘密密钥的Secure ROM之类的组件，为秘密密钥提供了物理保护。在执行期间，受保护的安全密钥将以明文形式加载到RAM，在此期间，可以监视到RAM 的总线以访问秘密密钥。

通过为安全SoC的内部RAM中的秘密密钥或涉及秘密密钥的加密操作的中间值分配缓冲区，可以防止这种情况发生。这样可以防止受保护的密钥可用于Secure SoC之外的任何总线。

安全SoC中的安全引导加载程序可确保设备使用具有正确进程特权的正版操作系统或固件进行引导。操作系统配置的MMU（内存管理单元）允许访问内部RAM中的缓冲区，而这些缓冲区仅涉及密钥操作。具有特殊OS特权的安全进程。

如果硬件制造商对Secure ROM进行了限制或预先编程，则可以使用万能钥匙对Secure ROM进行编程。该主密钥可用于加密设备密钥并将其存储在内部ROM中。

图4。安全SoC通过将处理秘密密钥的组件（如Secure ROM）保留在芯片内部，从而为秘密密钥提供物理保护。

在安全SoC的理想情况下，必须满足几个条件：

1）无法从物理上访问安全ROM以检索密钥。

2）无法监视SecureSoC内部的总线以获得受保护的数据或密钥。

3）应该无法删除或更换安全SoC中的任何组件，或者应防止SoC无法工作。

物理保护级别可以根据受保护内容的值而变化。保护可以仅仅是在进行物理访问尝试时篡改SoC以将SoC中所有存储的内容清零。

篡改检测保护方法不会阻止攻击者从芯片中获取数据，而只会使您知道芯片是否已被篡改。调零需要特殊的电源和硬件支持，这使得芯片更加昂贵。

该NIST（国家标准技术研究所）发出FIPS140-2 [9]发布指定不同级别的硬件的，涉及敏感信息的存储和转让的设备andsoftware安全要求。

现在，让我们更详细地了解安全SoC中每个组件的作用：1） ROM，2） 内部RAM和安全进程，3） securebootloader和代码签名，4）加密/解密引擎以及5）系统定时”以及它们如何有助于确保安全存储秘密密钥和其他受保护的数据。

安全ROM。 在设备的持久性存储中安全地存储设备密钥的一种方法是在存储之前对密钥进行加密。因此，即使有人设法从持久性存储中获取数据，他/她也将永远无法理解秘密密钥。

要加密任何数据，通常需要两件事：加密算法和加密密钥。如果使用任何众所周知的算法（如AES）对密钥进行加密，则加密的强度仅与用于加密的密钥的保密性一样强。

因此，再次面临着用于存储用于加密密钥的密钥所面临的相同问题。除非使用仅设备制造商已知的加密算法，否则将重复此问题。

如果将设备专有算法用于秘密密钥的加密和存储，则秘密密钥的安全性仅与算法的保密性一样强。

由于代码二进制文件以明文形式存储在设备存储器中，并且有许多用于重新设计代码的工具（如“ objdump”）可用，因此暴露秘密密钥的机会不容忽视。

存储密钥的另一种方法是将其存储在Secure ROM中。安全ROM驻留在设备的安全SoC内部。安全ROM的硬件控制器先对数据解密，然后再从ROM中取回数据。此硬件支持将防止未经授权的物理访问来检索存储在Secure ROM中的秘密密钥。

包含秘密密钥或涉及秘密密钥的密码操作中间值的缓冲区在安全SoC的内部RAM中分配。因此，可以防止秘密密钥可用于Secure SoC外部的任何总线。

如果安全ROM受硬件制造商限制或预先编程，则可以使用设备主密钥对安全ROM进行编程。设备主密钥是每个设备硬件或安全SoC独有的密钥，可以进一步用于将设备秘密密钥加密和存储在安全性较低的ROM中。

Secure ROM的实现中可能存在的漏洞包括：

1. 从物理上将Secure ROM从Secure SoC中移除，将其放置在另一设备中，并尝试检索受保护的密钥。

2. 访问SecureROM和RAM之间的总线以检索受保护的密钥。

3. 在设备上运行的未经特权/未经授权的应用程序可以访问API，以从安全ROM检索密钥。

理想情况下，在设计合理的安全SoC中，不存在前两个漏洞。可以通过使用安全引导加载程序和正确的进程特权的实施来防止第三个漏洞，从而不允许未特权的应用程序运行和访问设备的受限内存位置。

内部RAM和安全进程。在安全SoC的内部RAM中分配用于秘密密钥或涉及秘密密钥的加密操作中间值的缓冲区，以防止秘密密钥可用于安全SoC之外的任何总线。

将内部RAM中的该存储区称为安全存储区。并非每个进程都应该访问该存储区。只有具有特殊操作系统特权的进程“安全进程”才能访问“安全存储区”。这类似于操作系统中具有管理特权或根特权的进程。

引导期间的操作系统将内存管理单元配置为仅允许对安全进程访问安全内存区域。同样重要的是，未经授权的用户请勿修改OS中的MMU配置代码，以访问安全存储区。

如本系列其他地方所讨论的，可以通过使用安全引导加载程序和代码签名来确保这一点。安全进程已配置为在设备启动期间启动。

操作系统应禁止任何未经授权的进程作为SecureProcess运行或启动新的Secure Process。如果设备支持，这可以防止任何下载的应用程序访问安全存储区以读取密钥。

由安全过程对秘密密钥执行的操作的结果通常是公共数据，例如加密数据或公共密钥。其他较少特权进程需要这些输出数据来执行操作，例如将输出数据传输到其他设备。特权较低的进程可以有几种调用安全进程的方法。

例如，假设安全进程在获取输入数据并开始执行之前先等待信号量。的输入数据缓冲器将是一个非安全存储器区域。特权级别较低的任何进程都可以释放输入缓冲区，并填充输入缓冲区并向安全进程发出信号，以开始执行。

安全过程在接收到信号后，使用秘密密钥对输入数据进行相应的加密操作。操作的输出放置在非安全存储器区域中，较少特权进程可以从该区域读取输出。

安全的引导加载程序和代码签名。密钥虽然受到硬件安全措施的保护，但必须通过某些API公开才能使用。必须确保无法修改设备的固件，以便未经授权的用户可以使用这些API从设备中提取秘密密钥。

固件还包含安全关键代码，例如处理安全关键硬件配置（例如内部RAM配置）以指定访问权限的代码。因此，必须拒绝任何覆盖设备固件组件的尝试。Secure Bootloader的存在可以确保这一点。

在启动之前，加载固件代码之前，Secure Bootloader会检查固件是否为真品，并在修改或更换设备固件后阻止设备启动。下面的图5显示了一个安全Bootloader实现的示例。

图5。公钥和私钥是由设备制造商生成的，用于签名和验证设备固件代码。设备制造商必须将私钥保密。

安全引导加载程序位于Secure SoC内部的写保护ROM上。将安全引导加载程序保留在写保护的ROM中可确保永远不会修改安全引导加载程序本身。

除了常规的引导初始化代码之外，SecureBootloader还包含固件代码的签名验证模块和用于验证固件代码的代码验证公钥。

固件代码使用设备制造商的代码验证私钥签名。安全启动加载程序在启动时通过使用代码验证公钥验证签名来检查代码的有效性。

尽管用于签名固件代码的私钥从未随设备一起发售，但设备制造商必须将其保密。用于签名固件代码的私钥保密性上的妥协使任何有权访问私钥的人都可以编写和签名安全引导加载程序可接受的代码。

如果设备的固件不可升级，则可以在没有安全启动加载程序的情况下，以更简单的方法强制执行启动加载程序中的安全级别。

在这种情况下，将整个固件写入只读存储器中并将引导加载程序配置为仅从只读存储器区域进行引导可以防止任何未经授权的固件组件在设备上运行，但是在许多情况下，不可升级的固件也会带来同样的问题设备上的许多限制。

有些文件（例如根CA证书）在修改后会导致设备安全性受到损害。此类文件还需要与设备的固件代码一起签名。

还有每个设备专用的文件，例如加密的密钥或设备证书，这些文件在修改后会阻止设备进行安全的数据传输，但不会损害设备的安全性。

这些设备专用文件的签名将在设备生产期间或设备固件升级期间引起开销，在此期间，设备制造商需要为每个设备签名固件代码。由于修改这些文件不会损害设备安全性，因此这些文件可以保存在设备中而无需进行签名。

加密和解密引擎。在许多安全协议实现中，由本系列前面讨论的密钥协商算法生成的共享机密用作主密钥，并生成用于加密和解密过程的子密钥。

当用作主密钥时，共享密钥将存储在设备中，直到协议指定的到期时间为止，并且生存期将为几天甚至几个月的量级，具体取决于用于数据传输的协议。

但是子键的生存期通常会在几秒钟的时间内变小。在这种情况下，共享机密的安全性要求更高，因此安全地存储在设备中。

但是，子密钥的安全要求并不像共享密钥或certificatePrivate-Keys之类的密钥那么重要。子密钥生成协议也将使得不可能从子密钥导出主密钥。

在用于加密和解密的密钥（子密钥）的安全性不是很关键的情况下，加密和解密引擎（模块）可以驻留在安全SoC之外。

子密钥在安全SoC内部生成，并传递到安全SoC外部的加密/解密引擎。在某些其他协议中，共享密钥或私钥本身用于加密/解密。

在这种情况下，加密/解密引擎应位于SoC内部，以防止密钥在Secure SoC外部的总线上可用。因此，可以根据用于加密和解密的密钥的安全性需求，将加密和解密引擎置于Secure SoC内部或外部。

系统定时。设备的数字证书通常带有有效期。有效期在不同的协议实现中会有所不同。

一些协议（例如SSL（安全套接字层））指定了几年或几十年的固定有效期，而其他协议（例如DTCP（数字传输内容保护）则指定了证书的无限有效期）。

嵌入式设备中的系统时间通常将具有用户界面以设置或修改系统时间。对于证书验证过程，任何设备都应维持与用户修改的系统时间不同的系统时间，以使用户无法修改系统时间以强制设备接受过期的证书。设备处于关闭状态后。

在许多情况下，设备处理有效期为20-30年或更长的证书时，未经授权修改系统时间并不是很关键。此时间范围比许多设备的寿命大得多。

而且，根CA在此时间范围内更新根证书的机会也很高。如果CA更改了根CA证书，则设备必须更新根CA证书和中间CA证书，并应从CA获取新的设备证书。