适用于 Azure IoT 设备制造商的安全做法
随着越来越多的制造商发行 IoT 设备，了解常见做法指导会很有帮助。 本文汇总了在制造与 Azure IoT 设备预配服务 (DPS) 配合使用的设备时要考虑的建议安全做法。
- 选择设备身份验证选项
- 在 IoT 设备上安装证书
- 将受信任的平台模块 (TPM) 集成到制造过程中
选择设备身份验证选项
任何 IoT 设备安全措施的终极目标都是创建安全的 IoT 解决方案。 但是，硬件限制、成本和安全专业水平等问题都会影响你将选择哪些选项。 此外，安全措施会影响 IoT 设备连接到云的方式。 尽管要考虑的 IoT 安全要素有很多，但每个客户面对的一个关键要素是使用哪种身份验证类型。
三种广泛使用的身份验证类型为 X.509 证书、受信任的平台模块 (TPM) 和对称密钥。 尽管还存在其他身份验证类型，但在 Azure IoT 上构建解决方案的大多数客户都会使用这三种类型之一。 本文的剩余内容将会探讨使用每种身份验证类型的优点和缺点。
X.509 证书
X.509 证书是可用于身份验证的数字标识类型。 IETF RFC 5280 中阐述了 X.509 证书标准。 在 Azure IoT 中，可通过两种方式对证书进行身份验证：
- 指纹。 将对证书运行一种指纹算法来生成一个十六进制字符串。 生成的字符串是该证书的唯一标识符。
- 基于完整链的 CA 身份验证。 证书链是对最终实体 (EE) 证书进行身份验证所需的所有证书的分层列表。 若要对 EE 证书进行身份验证，需要对证书链中的每个证书（包括受信任的根 CA）进行身份验证。
X.509 的优点：
- X.509 是 Azure IoT 支持的最安全的身份验证类型。
- 使用 X.509 时，能够以较高的控制度实现证书管理。
- 许多供应商都可以提供基于 X.509 的身份验证解决方案。
X.509 的缺点：
- 许多客户可能需要依赖于外部供应商来获得证书。
- 证书管理的成本可能很高，并且会增加解决方案的总体成本。
- 如果未充分考虑到后勤，证书生命周期管理可能会很困难。
受信任的平台模块 (TPM)
TPM（也称为 ISO/IEC 11889）是用于安全地生成和存储加密密钥的标准。 TPM 也指与实现了该标准的模块进行交互的虚拟或物理 I/O 设备。 TPM 设备的存在形式可以是离散硬件、集成硬件、基于固件的模块或基于软件的模块。
TPM 与对称密钥之间有两个重要区别：
- TPM 芯片还可以存储 X.509 证书。
- DPS 中的 TPM 证明使用 TPM 认可密钥 (EK) - 一种非对称身份验证形式。 使用非对称身份验证时，公钥将用于加密，一个单独的私钥将用于解密。 相反，对称密钥使用对称身份验证，私钥用于加密和解密。
TPM 的优点：
- TPM 作为标准硬件包含在许多 Windows 设备上，内置了对操作系统的支持。
- 与基于共享访问签名 (SAS) 令牌的对称密钥证明相比，TPM 证明更便于提供保护。
- 你可以轻松续订、滚动更新设备凭据或使其过期。 每当 TPM 设备需要重新预配时，DPS 就会自动滚动更新 IoT 中心凭据。
TPM 的缺点：
- TPM 较为复杂且难以使用。
- 除非你有物理 TPM 或优质的仿真器，否则使用 TPM 进行应用程序开发会有难度。
- 可能需要重新设计设备控制板才能在硬件中包含 TPM。
- 如果滚动更新 TPM 上的 EK，将会销毁该 TPM 的标识并创建新的标识。 尽管物理芯片保持不变，但它会在 IoT 解决方案中使用新的标识。
对称密钥
使用对称密钥时，将使用同一个密钥来加密和解密消息。 因此，设备以及对该设备进行身份验证的服务都知道同一个密钥。 Azure IoT 支持基于 SAS 令牌的对称密钥连接。 对称密钥身份验证要求所有者负责保护密钥并实现与 x.509 身份验证同等级别的安全性。
对称密钥的优点：
- 使用对称密钥是开始进行身份验证的最简单且成本最低的方式。
- 使用对称密钥可以简化过程，因为无需生成任何额外的信息。
对称密钥的缺点：
- 对称密钥要求付出大量的精力来保护密钥。 同一密钥在设备与云之间共享，这意味着，在这两个位置都必须保护该密钥。 相比之下，使用 TPM 和 X.509 证书的难点在于，如何在不透露私钥的情况下证明公钥的所有权。
- 使用对称密钥时很容易使用糟糕的安全做法。 对称密钥的常见用法趋势是对设备上未加密的密钥进行硬编码。 尽管这种做法很方便，但会使密钥容易受到攻击。 可以通过在设备上安全地存储对称密钥来缓解一些风险。 但是，如果你优先考虑的是最终安全性而不是方便性，请使用 X.509 证书或 TPM 进行身份验证。
共享对称密钥
对称密钥身份验证有一个称为共享对称密钥的变体。 此方法涉及到在所有设备中使用同一个对称密钥。 建议避免在设备上使用共享对称密钥。
共享对称密钥的优点：
- 易于实现，且能以较低的开销大规模生产。
共享对称密钥的缺点：
- 很容易受到攻击。 与风险相比，易于实现这一优点不值一提。
- 如果某人获取了共享密钥，就可以模拟你的设备。
- 如果你依赖于易受攻击的共享对称密钥，可能会失去设备控制权。
根据设备做出正确的选择
若要选择身份验证方法，请务必考虑适合你的独特制造过程的每种方法的优点和成本。 对于设备身份验证，给定方法的安全性及其方便性之间往往存在一种对立的关系。
在 IoT 设备上安装证书
如果使用 X.509 证书对 IoT 设备进行身份验证，本部分提供了有关如何将证书集成到制造过程的指导。 需要做出几项决策。 这些决策涉及到常见的证书可变因素、何时生成证书以及何时安装证书。
如果你一向使用密码，可能会询问，为何不能在所有设备中使用同一个证书，就像在所有设备中使用同一个密码一样。 首先，在每个位置都使用同一密码是危险的做法。 这种做法会使公司暴露在严重的 DDoS 攻击之下，例如，中国东海岸在几年前发生的 DNS 关闭。 切勿在每个位置都使用相同的密码，即使是在个人帐户中。 其次，证书并非密码，而是唯一的标识。 密码类似于机密代码，任何人都可以使用它来打开受保护建筑物的房门。 它是你知道的东西，你可以向任何人提供密码以获取进入权限。 证书类似于驾照，其中包含你的照片和其他详细信息，可以向保安人员出示它，以便能够进入受保护的建筑物。 它与你的身份相关联。 如果保安人员准确地将人员与驾照进行匹配，则只有你才能使用你的驾照（身份）获取进入权限。
证书决策中涉及的可变因素
考虑以下可变因素，以及每个可变因素对总体制造过程的影响。
证书信任根来自何处
管理公钥基础结构 (PKI) 可能成本高昂且复杂， 尤其是当你的公司在管理 PKI 方面没有任何经验时。 选项包括：
- 使用第三方 PKI。 可以向第三方证书供应商购买中间签名证书。 或者，可以使用专用证书颁发机构 (CA)。
- 使用自我管理的 PKI。 你可以维护自己的 PKI 系统并生成自己的证书。
证书的存储位置
有一些因素会影响有关证书存储位置的决策。 这些因素包括设备类型、预期利润（是否可以承受安全存储的成本）、设备功能，以及设备上可使用的现有安全技术。 请考虑以下选项：
- 在磁盘上的安全位置（例如受信任的执行环境 (TEE)）中。
- 在本地文件系统或证书存储中。 例如 Windows 证书存储。
工厂的连接
工厂的连接决定了如何以及何时获取要在设备上安装的证书。 连接选项如下：
- 有连接。 有连接是最好的，因为它简化了在本地生成证书的过程。
- 无连接。 在这种情况下，可以使用 CA 签名的证书在本地离线生成设备证书。
- 无连接。 在这种情况下，可以获取提前生成的证书。 或者，可以使用离线 PKI 在本地生成证书。
审核要求
根据你生产的设备类型，可以制定规章来要求创建审核线索，规定如何在设备上安装设备标识。 审核会大幅增加生产成本。 因此，在大多数情况下，仅当有必要时才进行审核。 如果你不确定是否需要审核，请咨询公司的法务部门。 审核选项包括：
- 非敏感行业。 无需审核。
- 敏感行业。 应根据合规认证要求，在安全的房间中安装证书。 如果你需要一间用于安装证书的安全房间，则可能已经知道了如何在设备中安装证书。 另外，你可能已部署了一个审核系统。
证书有效期
与驾照一样，证书在创建时已设置了一个过期日期。 下面是证书有效期的选项：
- 不需要续订。 此方法使用较长的续订期，因此在设备的生存期内，永远不需要续订证书。 尽管这种方法非常方便，但也存在风险。
- 需要续订。 在设备生存期内需要续订证书。 证书有效期取决于上下文，需要制定续订策略。 该策略应包括获取证书的位置，以及设备在续订过程中必须使用的无线功能类型。
何时生成证书
工厂的 Internet 连接功能会影响证书的生成过程。 对于何时生成证书，存在多个选项：
- 设备生成的证书。 如果设备在内部生成证书，则必须从设备中提取公共 X.509 证书，以便在 DPS 中注册该设备。
- 联网工厂。 如果你的工厂已建立连接，则你随时可根据需要生成设备证书。
- 具有你自己的 PKI 的离线工厂。 如果你的工厂未建立连接，并且你使用自己的提供离线支持的 PKI，则可以按需生成证书。
- 具有第三方 PKI 的离线工厂。 如果你的工厂未建立连接，并且你使用第三方 PKI，则必须提前生成证书。 此外，需要从建立了连接的位置生成证书。
何时安装证书
为 IoT 设备生成证书后，可将其安装到设备中。
可以使用一些软件工具通过单个步骤来运行安装过程和最终质量检查。 你可以修改这些工具来生成证书，或者从预生成的证书存储中提取证书。 然后，软件可以在需要安装证书的位置安装证书。 使用此类软件工具可以大规模运行生产质量级别的制造。
在设备上安装证书后，下一步是了解如何向 DPS 注册设备。
将 TPM 集成到制造过程
如果你使用 TPM 对 IoT 设备进行身份验证，本部分提供了相关指导。 指导中涉及广泛使用的 TPM 2.0 设备，该设备支持基于哈希的消息身份验证代码 (HMAC) 密钥。 TPM 芯片的 TPM 规范是由“可信计算组织”维护的 ISO 标准。 有关 TPM 的详细信息，请参阅 TPM 2.0 和 ISO/IEC 11889 的规范。
获取 TPM 的所有权
制造包含 TPM 芯片的设备的一个关键步骤是获取 TPM 的所有权。 必须执行此步骤才能向设备所有者提供密钥。 第一步是从设备中提取认可密钥 (EK)。 下一步是实际主张所有权。 如何做到这一点取决于所用的 TPM 和操作系统。 如果需要，请联系 TPM 制造商或设备操作系统开发商来确定如何主张所有权。
在制造过程中随时可以提取 EK 和主张所有权，因此提高了灵活性。 本部分提供了有关何时提取 EK、何时主张 TPM 所有权的指导，以及将这些步骤集成到制造时间线时的注意事项。
重要
以下指导假设使用离散 TPM、固件 TPM 或集成式 TPM。 在适当的位置，指导中添加了有关使用非离散 TPM 或软件 TPM 的说明。 如果使用软件 TPM，可能需要执行本指导中未提到的其他步骤。 软件 TPM 的实现方式多种多样，这超出了本文的范畴。 通常，可将软件 TPM 集成到以下常规制造时间线。 但是，尽管软件仿真的 TPM 适用于原型制作和测试，但它不能提供与离散 TPM、固件 TPM 或集成式 TPM 相同的安全级别。 常规做法是避免在生产环境中使用软件 TPM。
常规生产时间线
以下时间线显示了 TPM 如何经历生产过程并在设备中结束。 每个制造过程都是独特的，此时间线显示的是最常见模式。 时间线提供了有关何时对密钥采取特定措施的指导。
步骤 1：制造 TPM
如果你从某个制造商那里购买了要在设备中使用的 TPM，请查看这些 TPM 是否会自动提取公共认可密钥 (EK_pub)。 如果制造商随交付的设备一起提供了 EK_pub 列表，则很有帮助。
注意
可以在预配服务中使用共享访问策略，向 TPM 制造商授予对你的注册列表的写入访问权限。 此方法允许制造商替你将 TPM 添加到注册列表中。 但该操作在制造过程的早期阶段发生，需要信任该 TPM 制造商。 这样做时需要自控风险。
如果你是向设备制造商销售 TPM 的 TPM 制造商，请考虑随物理 TPM 为客户提供 EK_pub 列表。 为客户提供 EK_pub 可让客户省去一个过程步骤。
如果你是 TPM 制造商，并且制造的 TPM 与你自己的设备配合使用，请确定在过程中的哪个阶段最方便提取 EK_pub。 可以在时间线中的任意剩余时间点提取 EK_pub。
步骤 2：将 TPM 安装到设备中
在生产过程中的此阶段，你应该知道了要将设备用于哪个 DPS 实例。 因此，你可将设备添加到注册列表以进行自动预配。 有关自动的设备预配的详细信息，请参阅 DPS 文档。
- 如果尚未提取 EK_pub，现在就是提取的好时机。
- 也很适合在此步骤中获取 TPM 的所有权，具体取决于 TPM 的安装过程。
步骤 3：在设备上安装固件和软件
在过程中的此阶段，请安装 DPS 客户端并提供 ID 范围和全局 URL 以进行预配。
- 现在是提取 EK_pub 的最后机会。 如果第三方要在你的设备上安装软件，则最好先提取 EK_pub。
- 非常适合在制造过程中的此阶段获取 TPM 的所有权。
注意
如果使用软件 TPM，现在可以安装它。 同时提取 EK_pub。
步骤 4：将设备打包并运送到仓库
一台设备有时会在仓库中放置长达一年的时间，然后才进行 DPS 部署和预配。 如果某个设备在部署之前在仓库中放置了较长时间，则部署该设备的客户可能需要更新固件、软件或过期的凭据。
步骤 5：将设备安装在目标位置
设备抵达其最终目标位置后，将通过 DPS 完成自动预配过程。
有关详细信息，请参阅预配。
资源
除了本文中建议的安全做法以外，Azure IoT 还提供了一些资源来帮助用户选择安全硬件和创建安全 IoT 部署：
- Azure Defender for Cloud 提供了一个服务来帮助创建安全 IoT 部署。
- 有关评估硬件环境的帮助，请参阅白皮书评估 IoT 安全性。
- 如需有关选择安全硬件的帮助，请参阅适用于 IoT 部署的安全硬件。