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

#1 楼

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



您的设备具有专用于此设备的私钥并且在设备外部未知。该密钥标识您的设备。任何可以访问该密钥的人都可以模拟该设备。这意味着它们尤其可以：


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

此私钥最好保持机密。


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


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




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

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

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

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


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

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

#2 楼

一点上下文

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


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


由于您当前正在使用STM32的读取保护（RDP） ），但最坚定的攻击者将无法以当前方案访问您的证书：


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


级别0-无保护（默认）
级别1-闪存可防止调试读取或通过RAM加载的代码转储

级别2-禁用所有调试功能



外部存储是否安全？

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

我需要保留哪些位的隐私？

创建设备时AWS IoT上的证书，您应该会看到这样的图像：



AWS IoT文档的“创建和激活设备证书”页面中的图像。

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

。

来自Wikipedia的图像，将其发布到公共域中。

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

私有密钥是您的设备用来解密消息的密钥，因此它稍大一些

您还询问了如果攻击者窃取RootCA证书会发生什么情况。如果有人偷走了AWS IoT的私钥，那将是灾难性的，但是您设备上的RootCA证书并非如此。亚马逊为您提供的RootCA.crt完全是公开的，目的是使您可以验证自己没有受到任何攻击（很可能是中间人假装是AWS IoT的服务器）。 />
被黑客入侵的设备可能造成什么损害？

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


仅允许将该内容发布到连接到数据处理器的2个通道（其名称和数据馈送通道），该通道将忽略即将出现的任何恶意数据包对它。


那很好。任何攻击都应仅限于设备可以发布到的两个MQTT主题，这样才不会造成大规模危害。

#3 楼

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

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

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

您的密钥当然应该具有not是未经授权的一方可以从一些摘录的示例中猜测出来的东西，或者生成它们自己的原始兼容实例的-即，您要么需要记录已生成的密钥，而有效密钥只是其中很小的一部分且无法预测空间，否则你会ed来对生成的密钥进行签名，并使系统仅接受密钥及其签名证明。

#4 楼

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

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

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