IoT-For-Beginners为你的植物 IoT 设备加上安全锁——对称密钥、SAS 令牌与 X.509 证书认证实战【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners本篇技术文章基于 IoT-For-Beginners 课程库中农业farm项目的最后一课Keep your plant secure对应 阿拉伯语翻译版文档英文原文见 2-farm/lessons/6-keep-your-plant-secure/README.md展开。在这之前你已经用土壤湿度传感器构建了一个可以上报遥测数据、接收云下命令的 IoT 设备读完本篇后你将理解 IoT 设备面临的典型安全威胁掌握连接字符串中对称密钥与 SAS 令牌的工作原理并能够用 Azure CLI 一条命令生成 X.509 证书、在 Raspberry Pi 或虚拟 IoT 设备代码中完成证书认证接入最后清理云资源完成整个农业项目闭环。一、为什么必须为 IoT 设备做安全设计IoT 安全的定义很明确确保只有预期的设备才能连接到你的云端 IoT 服务并发送遥测数据同时只有你的云服务才能向设备下发命令。IoT 数据往往还是个人数据甚至医疗等敏感数据因此整个应用栈都必须把安全纳入设计防止数据泄露。在 farm 项目的场景中威胁非常具体如果竞争对手的黑客控制了你部署的土壤监测设备他们可能持续上报土壤湿度很高的假读数导致自动灌溉系统永远不启动植物枯死或者反向操作让水泵 24 小时不间断工作用过度浇水杀死植物并带来高额水费。课程列举了 IoT 应用不安全时面临的五类典型风险伪造设备发送错误数据例如持续上报高湿度读数使灌溉系统永不触发未授权用户读取设备数据包括个人数据或对业务关键的数据黑客下发恶意控制命令以损坏设备或其连接的硬件设备沦为内网跳板黑客借 IoT 设备接入更多网络渗透私有系统个人数据被用于勒索。这些不是假想场景。课程列举了多起真实事件2018 年黑客通过鱼缸恒温器上开放的 WiFi 接入点攻入一家赌场网络窃取数据2016 年 Mirai 僵尸网络利用仍在使用默认用户名和密码的 DVR、摄像头等 IoT 设备对 ISP Dyn 发起史上最大规模之一的 DDoS 攻击某玩具公司Spiral Toys的 CloudPets 联网玩具用户数据库完全暴露在公网儿童语音消息被泄露和勒索某运动应用 Strava 的路径展示功能让陌生人能推断出用户的家。如果你能连接自己的智能牙刷或联网体重秤那么攻击者也能连接别人的——这就是默认凭据 无认证的代价。需要说明的是安全是一个庞大的主题该课程只覆盖设备连云环节的基础安全数据传输中防篡改监测、设备本身被入侵、设备配置变更等话题不在范围内。面向此类威胁业界也发展出了 Azure Defender for IoT 这类IoT 版杀毒软件工具专为小型低功耗设备设计。二、加密原理从设备 ID 克隆到密钥认证设备连接 IoT 服务时传统方式是使用一个 ID 来表明身份。问题在于ID 可以被克隆——黑客可以架设一台恶意设备使用与真实设备相同的 ID 发送伪造数据。解决思路是把要发送的数据转成乱码形态这个打乱数据的依据是一个只有设备和云端都知道的数值。这个转换过程称为加密encryption所用数值称为加密密钥encryption key。云端服务再用同一密钥或专用的解密密钥执行解密decryption把数据还原如果一条密文无法用密钥解开说明设备身份不可信消息被拒绝。执行加密/解密的这套技术体系统称密码学cryptography。2.1 早期加密与现代加密最早的密码学是 3500 年前的替换密码用一个字母替换另一个字母。凯撒密码Caesar cipher把字母表整体偏移固定位数只有收发双方知道偏移量维吉尼亚密码Vigenère cipher更进一步用密钥词让每个字母的偏移量各不相同。古代密码学的应用远不止战争——美索不达米亚的陶工用它保护釉料配方古埃及人用它保密咒语印度有人用它写密情书。现代加密则复杂得多它利用复杂的数学使得可能的密钥空间大到暴力破解不现实。HTTPSHyperText Transfer ProtocolSecure就是日常例子——浏览器与服务器之间的流量经过加密即使有人截获网络流量也读不到内容很多计算机还对硬盘数据全盘加密硬盘被偷也读不出数据。但并非一切都安全有些设备完全没有安全机制有些用弱密钥加密甚至有同类设备全部共用同一个 WiFi/蓝牙 密码。此外尽管现代加密号称破解需要数十亿年量子计算的兴起已经让所有已知加密在短期内被攻破成为可能这也是后量子密码学研究的动因。2.2 对称密钥与非对称密钥加密分两大类型理解它们是对比理解 IoT Hub 认证机制的关键对称加密用同一把密钥加密和解密数据收发双方必须持有相同的密钥。它的安全性短板在于密钥本身需要某种方式共享——发送方可能得先把密钥发给接收方。如果密钥在传输途中被窃取或收发任一方被攻破暴露密钥整个加密体系就崩溃了见原文档中黑客截获密钥的示意图 send-message-symmetric-key-hacker.png。非对称加密使用一对密钥公钥加密用和私钥解密用即公钥/私钥对。公钥只能加密不能解密私钥只能解密不能加密。接收方公开分发自己的公钥任何发送者都可以用它加密消息但只有持有私钥的接收方才能解开。私钥永远不离开接收方因此非对称加密更安全——代价是更慢。实际系统常常混合使用两者先用非对称加密安全地传递对称密钥之后所有数据都用更快的对称加密传输——既解决了密钥分发问题又兼顾性能。HTTPS 的 TLS 握手正是这一思路的典型应用。三、对称密钥认证连接字符串、SharedAccessKey 与 SAS 令牌IoT Hub 支持对称密钥和非对称密钥两种设备认证。对称方式更简单本 farm 项目的前几课用的就是它——连接字符串connection string。课程给出的完整示例如下HostNamesoil-moisture-sensor.azure-devices.net;DeviceIdsoil-moisture-sensor;SharedAccessKeyBhryind7kKEIDxubK61RiEHHRTrPl7HUow8cEm/mU0这条连接字符串由分号分隔的三段组成每段都是键值结构键值说明HostNamesoil-moisture-sensor.azure-devices.netIoT Hub 的 URL 地址DeviceIdsoil-moisture-sensor设备的唯一标识SharedAccessKeyBhryind7kKEIDxubK61RiEHHRTrPl7HUow8cEm/mU0设备与 IoT Hub 共同知晓的对称密钥其中SharedAccessKey就是设备与 IoT Hub 共享的对称密钥。它的巧妙之处在于这把密钥永远不会从设备发到云端也永远不从云端发到设备它只用于加密发送或接收的数据。SASShared Access Signature共享访问签名令牌的认证流程是这套机制的核心设备首次尝试连接时发送一个 SAS 令牌包含三部分IoT Hub 的 URL、令牌的过期时间戳通常是当前时间起一天、以及一个签名该签名就是URL 过期时间用连接字符串中的共享访问密钥加密后的结果IoT Hub 用自己的共享访问密钥解密签名若解密结果与明文中的 URL 和过期时间一致则放行连接同时 IoT Hub 校验当前时间早于过期时间——防止恶意设备截获真实设备的 SAS 令牌后重放。从源码结构看这是一种非常优雅的零知识证明式校验发送方把同一段已知数据以明文和密文两种形式发出服务端解密密文后与明文比对。若一致证明收发双方持有同一把对称密钥而密钥本身全程未在网络中明文传输。两个容易踩的坑时间必须准确。由于存在过期校验设备必须知道精确时间通常从 NTP 服务器读取时间不同步会导致连接直接失败密钥绝不能硬编码在公开代码仓库中。黑客拿到源码就拿到了密钥而且发版时每台设备都要重新编译密钥也很麻烦。最佳实践是从硬件安全模块HSM——IoT 设备上一块专门存储加密值的芯片——中读取密钥。学习阶段把密钥写进代码本项目前面几课就是这样做的更方便但务必保证该密钥不会进入公开的代码版本控制。另外IoT Hub 中每台设备其实有两把密钥和两条对应的连接字符串这支持密钥轮换当第一把密钥疑似泄露时切换到第二把并重新生成第一把。四、X.509 证书用可信第三方解决公钥身份问题非对称加密有一个身份难题你要把公钥发给所有想给你发数据的人但对方如何确认这真的是你的公钥而不是冒名顶替者答案是X.509 证书——把你的公钥装进一份由可信第三方验证过的数字文档。X.509 证书是包含公钥/私钥对中公钥部分的数字文档通常由受信任的证书颁发机构Certification Authority, CA签发并由 CA 数字签名表示该密钥有效且归属于证书声明的所有者。你之所以信任证书就像你信任护照一样——因为你信任签发它的国家。证书是收费的但测试场景下可以自签名self-sign即自己创建并由自己签发的证书。原文档特别强调生产环境永远不要使用自签名证书。证书内部包含多个字段公钥的所有者身份、签发 CA 的信息、有效期、公钥本体等。使用证书前的良好实践是校验它确实由原始 CA 签名。工作流程上使用 X.509 证书时发送方和接收方各自持有一对公钥/私钥以及包含各自公钥的 X.509 证书双方以某种方式交换证书然后互相用对方公钥加密发往对方的数据、用自己的私钥解密收到的数据对应示意图 send-message-certificate.png。X.509 在 IoT 场景中有一个显著优势证书可以在设备间共享。你可以只创建一张证书上传到 IoT Hub然后所有设备都使用它每台设备只需要持有对应的私钥来解密来自 IoT Hub 的消息。反向地设备发往 IoT Hub 的消息所使用的 Azure 服务端证书由 Microsoft 发布是很多 Azure 服务共用的同一张证书有时甚至直接内置在 SDK 里。再强调一次安全边界公钥本身就是公开的——Azure 的公钥只能用于加密发往 Azure 的数据而不能解密因此可以安全地出现在源码等任何地方。五、动手实践一条 Azure CLI 命令生成 X.509 证书生成 X.509 证书的步骤本质上是两步创建公钥/私钥对——最常用的算法是RSARivest–Shamir–Adleman提交公钥及关联数据去签名或由 CA 签名或自签名。Azure CLI 提供了命令可以在 IoT Hub 中创建新设备身份同时自动生成公钥/私钥对并创建自签名证书若想看 OpenSSL 手工执行的详细步骤可参考 Microsoft IoT Hub 官方文档中的自签名证书教程。执行az iot hub device-identity create --device-id soil-moisture-sensor-x509 \ --am x509_thumbprint \ --output-dir . \ --hub-name hub_name将hub_name替换为你自己的 IoT Hub 名称。参数说明--device-id soil-moisture-sensor-x509新设备 ID用-x509后缀与前几课创建的soil-moisture-sensor身份区分--am x509_thumbprint声明认证方式authentication method为 X.509 指纹--output-dir .把生成的密钥与证书文件输出到当前目录。执行后当前目录会新增两个文件soil-moisture-sensor-x509-key.pem—— 设备私钥文件soil-moisture-sensor-x509-cert.pem—— 设备的X.509 证书文件。务必妥善保管这两个文件私钥文件绝不能提交到公开的代码仓库。六、在设备代码中使用 X.509 证书Raspberry Pi / 虚拟 IoT 设备课程在 2-farm/lessons/6-keep-your-plant-secure/single-board-computer-x509.md 中给出了完整的代码改造步骤仓库中 code/pi/soil-moisture-sensor/app.py 和 code/virtual-device/soil-moisture-sensor/app.py 两个文件就是改造完成后的成品代码。关键改动如下把soil-moisture-sensor-x509-key.pem和soil-moisture-sensor-x509-cert.pem复制到设备代码所在目录若使用 VS Code Remote SSH 在 Raspberry Pi 上开发可直接把文件拖进 VS Code 资源管理器完成复制声明 IoT Hub 主机名——即连接字符串中HostName段格式为你的 Hub 名加.azure-devices.net后缀以及设备 IDhost_name host_name.azure-devices.net device_id soil-moisture-sensor-x509从azure.iot.device模块导入X509类注意 import 列表比之前多了X509from azure.iot.device import IoTHubDeviceClient, Message, MethodResponse, X509用证书和密钥文件构造X509实例x509 X509(./soil-moisture-sensor-x509-cert.pem, ./soil-moisture-sensor-x509-key.pem)用基于证书的工厂方法替代原来从连接字符串创建客户端的那一行device_client IoTHubDeviceClient.create_from_x509_certificate(x509, host_name, device_id)删除原来的connection_string变量——认证不再依赖其中包含的SharedAccessKey。以 Raspberry Pi 版代码 为例接入证书认证后的完整程序结构是通过grove.adc.ADC读取土壤湿度、通过GroveRelay(5)控制继电器创建 X.509 客户端并connect()注册device_client.on_method_request_received回调处理relay_on/relay_off直接方法并以 200 状态码回MethodResponse主循环每 10 秒读取一次 ADC将{soil_moisture: ...}以 JSON 封装为Message上报 IoT Hub。虚拟设备版代码 与其逻辑完全一致区别仅在开头用 Counterfit 框架模拟硬件from counterfit_connection import CounterFitConnection CounterFitConnection.init(127.0.0.1, 5000)并把真实 Grove 驱动替换为counterfit_shims_grove的桩模块这样在没有实物的电脑上也能验证完整的 X.509 认证链路。运行后你可以在 IoT Hub 中观察到设备正常连接、上报土壤湿度遥测并继续照旧发起直接方法请求验证继电器控制。Wio TerminalArduino的局限课程在 wio-terminal-x509.md 中明确说明撰写时 Azure Arduino SDK 尚不支持 X.509 证书想在 Wio Terminal 上实验证书认证的读者建议参考上述 Python SDK 的虚拟设备方案。这一限制值得在选型时留意设备端 SDK 的认证能力支持情况需要单独确认。七、收尾清理云资源并挑战 Azure Portal作为 farm 项目的最后一课学完安全后别忘了清理云资源以控制成本。课程指向仓库根目录的 clean-up.md 清理指南由于本项目的所有服务都创建在同一个资源组Resource Group内只需删除资源组即可连带删除其中的 IoT Hub、Functions App 等资源az group delete --name resource-group-name输入y确认即可。注意清理要放在完成本课作业之后——作业还需要用到这些云资源。课程还布置了一个实操挑战用 Azure PortalWeb 图形界面而非 CLI 来创建并删除一个 IoT Hub熟悉资源组的门户化操作——通过门户创建服务时不必预先单独建资源组可以在创建服务时一并生成用完记得删除。最终作业assignment.md要求综合运用 farm 项目六课所学自选一个传感器和一个执行器构建一台新的 IoT 设备向 IoT Hub 上报遥测并通过无服务器代码Azure Function消费遥测事件来控制执行器。评分维度覆盖设备编程、Hub 双向通信、无服务器触发器三方面从能同时做到到完全无法完成分级评定。小结这节课给出了 IoT 设备认证的两条完整路径对称密钥路径靠连接字符串中的SharedAccessKey生成 SAS 令牌以加密比对 过期校验证明设备身份胜在简单但密钥管理轮换、HSM 存储、防入库必须到位X.509 路径借助 RSA 公钥/私钥对与 CA 签发的证书测试可自签名生产必须 CA 签发一条az iot hub device-identity create命令即可生成密钥与证书再用IoTHubDeviceClient.create_from_x509_certificate三行代码替换连接字符串接入。理解了这两条路径背后的密码学原理与威胁模型你的智能农业设备——以及你未来构建的任何 IoT 系统——才算真正守门到位。【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
IoT-For-Beginners为你的植物 IoT 设备加上安全锁——对称密钥、SAS 令牌与 X.509 证书认证实战【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners本篇技术文章基于 IoT-For-Beginners 课程库中农业farm项目的最后一课Keep your plant secure对应 阿拉伯语翻译版文档英文原文见 2-farm/lessons/6-keep-your-plant-secure/README.md展开。在这之前你已经用土壤湿度传感器构建了一个可以上报遥测数据、接收云下命令的 IoT 设备读完本篇后你将理解 IoT 设备面临的典型安全威胁掌握连接字符串中对称密钥与 SAS 令牌的工作原理并能够用 Azure CLI 一条命令生成 X.509 证书、在 Raspberry Pi 或虚拟 IoT 设备代码中完成证书认证接入最后清理云资源完成整个农业项目闭环。一、为什么必须为 IoT 设备做安全设计IoT 安全的定义很明确确保只有预期的设备才能连接到你的云端 IoT 服务并发送遥测数据同时只有你的云服务才能向设备下发命令。IoT 数据往往还是个人数据甚至医疗等敏感数据因此整个应用栈都必须把安全纳入设计防止数据泄露。在 farm 项目的场景中威胁非常具体如果竞争对手的黑客控制了你部署的土壤监测设备他们可能持续上报土壤湿度很高的假读数导致自动灌溉系统永远不启动植物枯死或者反向操作让水泵 24 小时不间断工作用过度浇水杀死植物并带来高额水费。课程列举了 IoT 应用不安全时面临的五类典型风险伪造设备发送错误数据例如持续上报高湿度读数使灌溉系统永不触发未授权用户读取设备数据包括个人数据或对业务关键的数据黑客下发恶意控制命令以损坏设备或其连接的硬件设备沦为内网跳板黑客借 IoT 设备接入更多网络渗透私有系统个人数据被用于勒索。这些不是假想场景。课程列举了多起真实事件2018 年黑客通过鱼缸恒温器上开放的 WiFi 接入点攻入一家赌场网络窃取数据2016 年 Mirai 僵尸网络利用仍在使用默认用户名和密码的 DVR、摄像头等 IoT 设备对 ISP Dyn 发起史上最大规模之一的 DDoS 攻击某玩具公司Spiral Toys的 CloudPets 联网玩具用户数据库完全暴露在公网儿童语音消息被泄露和勒索某运动应用 Strava 的路径展示功能让陌生人能推断出用户的家。如果你能连接自己的智能牙刷或联网体重秤那么攻击者也能连接别人的——这就是默认凭据 无认证的代价。需要说明的是安全是一个庞大的主题该课程只覆盖设备连云环节的基础安全数据传输中防篡改监测、设备本身被入侵、设备配置变更等话题不在范围内。面向此类威胁业界也发展出了 Azure Defender for IoT 这类IoT 版杀毒软件工具专为小型低功耗设备设计。二、加密原理从设备 ID 克隆到密钥认证设备连接 IoT 服务时传统方式是使用一个 ID 来表明身份。问题在于ID 可以被克隆——黑客可以架设一台恶意设备使用与真实设备相同的 ID 发送伪造数据。解决思路是把要发送的数据转成乱码形态这个打乱数据的依据是一个只有设备和云端都知道的数值。这个转换过程称为加密encryption所用数值称为加密密钥encryption key。云端服务再用同一密钥或专用的解密密钥执行解密decryption把数据还原如果一条密文无法用密钥解开说明设备身份不可信消息被拒绝。执行加密/解密的这套技术体系统称密码学cryptography。2.1 早期加密与现代加密最早的密码学是 3500 年前的替换密码用一个字母替换另一个字母。凯撒密码Caesar cipher把字母表整体偏移固定位数只有收发双方知道偏移量维吉尼亚密码Vigenère cipher更进一步用密钥词让每个字母的偏移量各不相同。古代密码学的应用远不止战争——美索不达米亚的陶工用它保护釉料配方古埃及人用它保密咒语印度有人用它写密情书。现代加密则复杂得多它利用复杂的数学使得可能的密钥空间大到暴力破解不现实。HTTPSHyperText Transfer ProtocolSecure就是日常例子——浏览器与服务器之间的流量经过加密即使有人截获网络流量也读不到内容很多计算机还对硬盘数据全盘加密硬盘被偷也读不出数据。但并非一切都安全有些设备完全没有安全机制有些用弱密钥加密甚至有同类设备全部共用同一个 WiFi/蓝牙 密码。此外尽管现代加密号称破解需要数十亿年量子计算的兴起已经让所有已知加密在短期内被攻破成为可能这也是后量子密码学研究的动因。2.2 对称密钥与非对称密钥加密分两大类型理解它们是对比理解 IoT Hub 认证机制的关键对称加密用同一把密钥加密和解密数据收发双方必须持有相同的密钥。它的安全性短板在于密钥本身需要某种方式共享——发送方可能得先把密钥发给接收方。如果密钥在传输途中被窃取或收发任一方被攻破暴露密钥整个加密体系就崩溃了见原文档中黑客截获密钥的示意图 send-message-symmetric-key-hacker.png。非对称加密使用一对密钥公钥加密用和私钥解密用即公钥/私钥对。公钥只能加密不能解密私钥只能解密不能加密。接收方公开分发自己的公钥任何发送者都可以用它加密消息但只有持有私钥的接收方才能解开。私钥永远不离开接收方因此非对称加密更安全——代价是更慢。实际系统常常混合使用两者先用非对称加密安全地传递对称密钥之后所有数据都用更快的对称加密传输——既解决了密钥分发问题又兼顾性能。HTTPS 的 TLS 握手正是这一思路的典型应用。三、对称密钥认证连接字符串、SharedAccessKey 与 SAS 令牌IoT Hub 支持对称密钥和非对称密钥两种设备认证。对称方式更简单本 farm 项目的前几课用的就是它——连接字符串connection string。课程给出的完整示例如下HostNamesoil-moisture-sensor.azure-devices.net;DeviceIdsoil-moisture-sensor;SharedAccessKeyBhryind7kKEIDxubK61RiEHHRTrPl7HUow8cEm/mU0这条连接字符串由分号分隔的三段组成每段都是键值结构键值说明HostNamesoil-moisture-sensor.azure-devices.netIoT Hub 的 URL 地址DeviceIdsoil-moisture-sensor设备的唯一标识SharedAccessKeyBhryind7kKEIDxubK61RiEHHRTrPl7HUow8cEm/mU0设备与 IoT Hub 共同知晓的对称密钥其中SharedAccessKey就是设备与 IoT Hub 共享的对称密钥。它的巧妙之处在于这把密钥永远不会从设备发到云端也永远不从云端发到设备它只用于加密发送或接收的数据。SASShared Access Signature共享访问签名令牌的认证流程是这套机制的核心设备首次尝试连接时发送一个 SAS 令牌包含三部分IoT Hub 的 URL、令牌的过期时间戳通常是当前时间起一天、以及一个签名该签名就是URL 过期时间用连接字符串中的共享访问密钥加密后的结果IoT Hub 用自己的共享访问密钥解密签名若解密结果与明文中的 URL 和过期时间一致则放行连接同时 IoT Hub 校验当前时间早于过期时间——防止恶意设备截获真实设备的 SAS 令牌后重放。从源码结构看这是一种非常优雅的零知识证明式校验发送方把同一段已知数据以明文和密文两种形式发出服务端解密密文后与明文比对。若一致证明收发双方持有同一把对称密钥而密钥本身全程未在网络中明文传输。两个容易踩的坑时间必须准确。由于存在过期校验设备必须知道精确时间通常从 NTP 服务器读取时间不同步会导致连接直接失败密钥绝不能硬编码在公开代码仓库中。黑客拿到源码就拿到了密钥而且发版时每台设备都要重新编译密钥也很麻烦。最佳实践是从硬件安全模块HSM——IoT 设备上一块专门存储加密值的芯片——中读取密钥。学习阶段把密钥写进代码本项目前面几课就是这样做的更方便但务必保证该密钥不会进入公开的代码版本控制。另外IoT Hub 中每台设备其实有两把密钥和两条对应的连接字符串这支持密钥轮换当第一把密钥疑似泄露时切换到第二把并重新生成第一把。四、X.509 证书用可信第三方解决公钥身份问题非对称加密有一个身份难题你要把公钥发给所有想给你发数据的人但对方如何确认这真的是你的公钥而不是冒名顶替者答案是X.509 证书——把你的公钥装进一份由可信第三方验证过的数字文档。X.509 证书是包含公钥/私钥对中公钥部分的数字文档通常由受信任的证书颁发机构Certification Authority, CA签发并由 CA 数字签名表示该密钥有效且归属于证书声明的所有者。你之所以信任证书就像你信任护照一样——因为你信任签发它的国家。证书是收费的但测试场景下可以自签名self-sign即自己创建并由自己签发的证书。原文档特别强调生产环境永远不要使用自签名证书。证书内部包含多个字段公钥的所有者身份、签发 CA 的信息、有效期、公钥本体等。使用证书前的良好实践是校验它确实由原始 CA 签名。工作流程上使用 X.509 证书时发送方和接收方各自持有一对公钥/私钥以及包含各自公钥的 X.509 证书双方以某种方式交换证书然后互相用对方公钥加密发往对方的数据、用自己的私钥解密收到的数据对应示意图 send-message-certificate.png。X.509 在 IoT 场景中有一个显著优势证书可以在设备间共享。你可以只创建一张证书上传到 IoT Hub然后所有设备都使用它每台设备只需要持有对应的私钥来解密来自 IoT Hub 的消息。反向地设备发往 IoT Hub 的消息所使用的 Azure 服务端证书由 Microsoft 发布是很多 Azure 服务共用的同一张证书有时甚至直接内置在 SDK 里。再强调一次安全边界公钥本身就是公开的——Azure 的公钥只能用于加密发往 Azure 的数据而不能解密因此可以安全地出现在源码等任何地方。五、动手实践一条 Azure CLI 命令生成 X.509 证书生成 X.509 证书的步骤本质上是两步创建公钥/私钥对——最常用的算法是RSARivest–Shamir–Adleman提交公钥及关联数据去签名或由 CA 签名或自签名。Azure CLI 提供了命令可以在 IoT Hub 中创建新设备身份同时自动生成公钥/私钥对并创建自签名证书若想看 OpenSSL 手工执行的详细步骤可参考 Microsoft IoT Hub 官方文档中的自签名证书教程。执行az iot hub device-identity create --device-id soil-moisture-sensor-x509 \ --am x509_thumbprint \ --output-dir . \ --hub-name hub_name将hub_name替换为你自己的 IoT Hub 名称。参数说明--device-id soil-moisture-sensor-x509新设备 ID用-x509后缀与前几课创建的soil-moisture-sensor身份区分--am x509_thumbprint声明认证方式authentication method为 X.509 指纹--output-dir .把生成的密钥与证书文件输出到当前目录。执行后当前目录会新增两个文件soil-moisture-sensor-x509-key.pem—— 设备私钥文件soil-moisture-sensor-x509-cert.pem—— 设备的X.509 证书文件。务必妥善保管这两个文件私钥文件绝不能提交到公开的代码仓库。六、在设备代码中使用 X.509 证书Raspberry Pi / 虚拟 IoT 设备课程在 2-farm/lessons/6-keep-your-plant-secure/single-board-computer-x509.md 中给出了完整的代码改造步骤仓库中 code/pi/soil-moisture-sensor/app.py 和 code/virtual-device/soil-moisture-sensor/app.py 两个文件就是改造完成后的成品代码。关键改动如下把soil-moisture-sensor-x509-key.pem和soil-moisture-sensor-x509-cert.pem复制到设备代码所在目录若使用 VS Code Remote SSH 在 Raspberry Pi 上开发可直接把文件拖进 VS Code 资源管理器完成复制声明 IoT Hub 主机名——即连接字符串中HostName段格式为你的 Hub 名加.azure-devices.net后缀以及设备 IDhost_name host_name.azure-devices.net device_id soil-moisture-sensor-x509从azure.iot.device模块导入X509类注意 import 列表比之前多了X509from azure.iot.device import IoTHubDeviceClient, Message, MethodResponse, X509用证书和密钥文件构造X509实例x509 X509(./soil-moisture-sensor-x509-cert.pem, ./soil-moisture-sensor-x509-key.pem)用基于证书的工厂方法替代原来从连接字符串创建客户端的那一行device_client IoTHubDeviceClient.create_from_x509_certificate(x509, host_name, device_id)删除原来的connection_string变量——认证不再依赖其中包含的SharedAccessKey。以 Raspberry Pi 版代码 为例接入证书认证后的完整程序结构是通过grove.adc.ADC读取土壤湿度、通过GroveRelay(5)控制继电器创建 X.509 客户端并connect()注册device_client.on_method_request_received回调处理relay_on/relay_off直接方法并以 200 状态码回MethodResponse主循环每 10 秒读取一次 ADC将{soil_moisture: ...}以 JSON 封装为Message上报 IoT Hub。虚拟设备版代码 与其逻辑完全一致区别仅在开头用 Counterfit 框架模拟硬件from counterfit_connection import CounterFitConnection CounterFitConnection.init(127.0.0.1, 5000)并把真实 Grove 驱动替换为counterfit_shims_grove的桩模块这样在没有实物的电脑上也能验证完整的 X.509 认证链路。运行后你可以在 IoT Hub 中观察到设备正常连接、上报土壤湿度遥测并继续照旧发起直接方法请求验证继电器控制。Wio TerminalArduino的局限课程在 wio-terminal-x509.md 中明确说明撰写时 Azure Arduino SDK 尚不支持 X.509 证书想在 Wio Terminal 上实验证书认证的读者建议参考上述 Python SDK 的虚拟设备方案。这一限制值得在选型时留意设备端 SDK 的认证能力支持情况需要单独确认。七、收尾清理云资源并挑战 Azure Portal作为 farm 项目的最后一课学完安全后别忘了清理云资源以控制成本。课程指向仓库根目录的 clean-up.md 清理指南由于本项目的所有服务都创建在同一个资源组Resource Group内只需删除资源组即可连带删除其中的 IoT Hub、Functions App 等资源az group delete --name resource-group-name输入y确认即可。注意清理要放在完成本课作业之后——作业还需要用到这些云资源。课程还布置了一个实操挑战用 Azure PortalWeb 图形界面而非 CLI 来创建并删除一个 IoT Hub熟悉资源组的门户化操作——通过门户创建服务时不必预先单独建资源组可以在创建服务时一并生成用完记得删除。最终作业assignment.md要求综合运用 farm 项目六课所学自选一个传感器和一个执行器构建一台新的 IoT 设备向 IoT Hub 上报遥测并通过无服务器代码Azure Function消费遥测事件来控制执行器。评分维度覆盖设备编程、Hub 双向通信、无服务器触发器三方面从能同时做到到完全无法完成分级评定。小结这节课给出了 IoT 设备认证的两条完整路径对称密钥路径靠连接字符串中的SharedAccessKey生成 SAS 令牌以加密比对 过期校验证明设备身份胜在简单但密钥管理轮换、HSM 存储、防入库必须到位X.509 路径借助 RSA 公钥/私钥对与 CA 签发的证书测试可自签名生产必须 CA 签发一条az iot hub device-identity create命令即可生成密钥与证书再用IoTHubDeviceClient.create_from_x509_certificate三行代码替换连接字符串接入。理解了这两条路径背后的密码学原理与威胁模型你的智能农业设备——以及你未来构建的任何 IoT 系统——才算真正守门到位。【免费下载链接】IoT-For-Beginners12 Weeks, 24 Lessons, IoT for All!项目地址: https://gitcode.com/GitHub_Trending/io/IoT-For-Beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
