将证书保留在外部存储器上是一种不好的做法吗？

我们正在使用STM32微控制器开发AWS-IoT。

直到今天，我们仍将证书写入闪存，并锁定闪存以防止外部读取。随着应用程序代码的增加，我们在闪存上的空间越来越小，因此我们计划将证书从外部移动到SD卡/ EEPROM中，并在连接到AWS-IoT之前在需要时随时读取。

笔记：

• 为该事物编写的策略将仅允许具有特定名称的设备连接该特定证书。

• 事物只能发布到2个通道（它的名称和数据馈送通道）上，该通道连接到数据处理器，该处理器将忽略进入其的任何恶意数据包。

• 如果该事物发布/订阅了其他任何主题，则AWS将立即断开该事物的连接。

如果我检测到设备被盗/流氓，则会从服务器上停用密钥。

开发者可以使用证书（RootCA，服务器密钥，客户端密钥）做什么？

将此类用例的证书保留在可由开发人员访问的外部存储上是一种不好的做法吗？

您提到“证书”，但是从上下文来看，我认为您是指两种不同的事物。

• 您的设备具有私钥，该私钥对该设备唯一，在设备外部未知。该密钥标识您的设备。任何可以访问该密钥的人都可以模拟该设备。这意味着他们可以，尤其是：

  • 在您的设备被合法授权发布的频道上发布有效但不正确的数据。
  • 发布无效数据，将使合法设备被禁止。
  • 根据使用情况，可能会公开设备所有者的一些私人信息。

  此私钥最好保持机密。

• 您的设备可能至少具有一个公共密钥，这使它可以识别与之通信的服务器。任何人都可以阅读此密钥是可以的：它是公开的。但是，攻击者应该不能修改密钥。否则，他们可能会与设备通信并模拟服务器。这可以使他们执行以下操作：

  • 将固件更新推送到设备。
  • 将配置更新推送到设备。
  • 使设备将其数据上传到其他位置。

好消息是，这种威胁分析实际上并不十分相关。您无需牺牲任何安全性！（至少不是保密性和真实性属性-如果在外部存储东西，则可用性会受到影响，因为这可能会丢失系统的一部分。）

只要您至少有128位存储空间（至少可以写入一次），并且拥有更多存储空间，就可以实施安全的远程存储解决方案。使用有限空间的设备存储来存储密钥。每个设备的此密钥必须唯一。STM32具有硬件RNG，因此您可以在首次启动时在设备上生成它。如果您的设备没有硬件RNG，则可以在安全的设备外位置生成密钥并将其注入到设备中。

使用此密钥，对您存储在设备之外的内容使用经过身份验证的加密。当您想从外部存储中读取一些数据时，请对其进行加载，解密和验证。当您要将一些数据写入外部存储时，请对其进行加密和签名。这保证了数据与内部存储中的数据一样机密和真实。

经过身份验证的加密足以保证数据的机密性和真实性，但并不能完全保证其完整性。

• 如果有多个数据块，那么当设备读回数据块时，无法确定这是正确的数据块。解决方案：包括在每个组块的内容的唯一标识符（例如启动每个块与一个"AWS-IoT private key."，"configuration CA certificate."，"publishing server CA certificate."，"user personal data."，...）。
• 如果您在某个时候更新数据，那么当您读回它时，就不能确定您正在获取该数据的最新版本。如果有人可以修改外部存储，则他们不能放入伪造的数据，因为这将使真实性检查失败，但是他们可以还原旧数据，因为曾经是真实的东西仍然是真实的。解决方案：在外部存储的每个数据块中，都包含一个计数器，每次编写该块的新版本时，该计数器都会增加。当您读回一个块时，请确认它是预期的版本。

为避免在外部存储设备损坏或丢失的情况下使设备变砖，请在有限的内部存储空间空间中使用，将设备重置为“良好”状态所需的优先级，例如恢复出厂设置。第二要务是性能方面的考虑。

一点背景

由于您将MQTT与AWS IoT结合使用，因此，期望使用X.509证书进行身份验证和安全性。亚马逊对如何保护证书有一些指导，因此在此引用一下：

证书使非对称密钥可以与设备一起使用。这意味着您可以将私钥刻录到设备上的安全存储中，而无需允许敏感的加密材料离开设备。

由于您当前正在使用STM32的读取保护（RDP），因此，除了最坚定的攻击者之外，所有其他攻击者都将无法在当前方案中访问您的证书：

全局读取保护功能使嵌入式固件代码（预装在闪存中）可以防止逆向工程，使用调试工具进行转储或其他侵入式攻击手段。

• 级别0-无保护（默认）
• 级别1-通过加载RAM的代码进行调试或转储代码，可以防止闪存读取
• 级别2-禁用所有调试功能

外部存储是否安全？

它可能不那么安全。如果客户端的私钥被盗，则攻击者可以发送看似来自您设备的数据，而实际上却不是。尽管不清楚您要发送什么数据，但是任何不受信任的数据都可能带来安全风险。

我需要保密哪些位？

在AWS IoT上创建设备证书时，应该看到如下图所示：

^{来自AWS IoT文档的`` 创建和激活设备证书''页面中的图像。}

私钥是您真正需要保留的东西... private，并且如果可能的话，绝对应该存储在受读保护的内存中。公钥和证书设计为共享的，因此，如果空间不足，则可以安全地将其移至外部存储。您可以在页面上获得更多上下文，SSL / TLS如何工作？可以在Wikipedia 上的Information Security Stack Exchange和公钥加密中找到。如果我不提供此图片来解释为什么私钥需要保密的话，我想我会对您不利。

。

^{维基百科的图片，已发布到公共领域。}

设备的公钥是AWS IoT用于签署要发送到您的设备的消息的签名（但不能证明谁在发送消息）。因此，实际上，如果有人窃取了公共密钥，这不会是一个大灾难，因为这并不是秘密。

该私钥是你的设备用来解密的消息，所以这是一个稍微大一点的问题，如果一个攻击者窃取这一点。

您还询问如果攻击者窃取RootCA证书会发生什么情况。如果有人偷走了AWS IoT的私钥，那将是灾难性的，但是您设备上的RootCA证书并非如此。在RootCA.crt亚马逊给你的是完全公开的，其目的是让你可以验证你不会被以任何方式攻击（最有可能是人在这方面的中间人故作AWS物联网的服务器）。

被入侵的设备可能造成什么损坏？

您的被盗设备只能执行策略中列出的操作。尝试遵循最小特权原则 ; 只授予您的设备绝对需要的特权，因此，如果发生最坏的情况，也不会造成太大破坏。对于您的具体情况：

事物只能发布到2个通道（其名称和数据馈送通道），该通道连接到数据处理器，该数据处理器将忽略进入其的任何恶意数据包。

非常好。任何攻击都应仅与设备可以发布的两个MQTT主题隔离，因此不会造成大规模危害。

理想情况下，您希望整个系统具有这样的设计：解剖单个单元只会破坏该单元，而不会破坏整个系统。

特别是如果您将密钥存储在不同的存储器中，使得它们跨芯片之间的标准电子接口，那么它们应该仅是已经可以安全发布的密钥，或者是该设备的特定物理实例所独有的密钥。

如果单个密钥是从单个设备中提取的，并且开始被滥用或出现在必须来自多个未授权克隆的大量流量中，则可以在服务器端禁止该密钥。

您的密钥当然应该具有这样的特性：未经授权的一方不能从摘录的几个示例中猜测出来，或者生成它们自己的原始兼容实例-即，您需要记录已生成的密钥，其中有效的密钥是仅在巨大可能性空间中的一小部分且不可预测的部分，否则您需要对生成的密钥进行签名，并使系统仅接受结合了其签名证明的密钥。

您应该尝试保持客户端密钥的机密性（但要了解失去它的含义（1），如其他答案所述）。服务器公共密钥和AWS公共证书对于确保设备端的安全很重要，这不是因为您想保密，而是因为通过替换AWS证书（在受感染的设备上），攻击者可以说服设备执行与攻击者的主机交换信息，或与AWS进行中间人交流。

通过执行此操作（2），攻击者可以剥离TLS安全性，这可能会导致安全性大大降低，从而他们可以对客户端密钥进行反向工程。

通过这种推理，可以安全地暴露在外部存储设备中的唯一密钥是服务器公钥。更改此（3）只会使您的设备被迫连接到流氓的AWS服务，该服务可能难以设计访问。即使仅泄露此密钥，也可能使某人窥探或伪造某些传输（例如，如果TLS层可以以某种方式降级）。

因此，总而言之，风险不只是泄漏信息，还存在如果（应该信任的）固件可以提供不信任的安全信息的风险。