我需要“加载”到板上的键之一是Azure设备连接字符串，当然还有WiFi SSID和密码。
我担心有人可能会简单地拿起董事会并“下载”文件以访问安全证书。
我的恐惧是没有根据的吗？或者失去证书是我需要减轻的真正威胁吗？
#1 楼
[免责声明：我是一名安全/加密专家，每天都在处理此类安全体系结构问题。它们，但是攻击者不能。这是一个众所周知的难题，非常难解决。然后使用Apple Secure Enclave。对于传统服务器，您可以使用HSM或智能卡，但是我知道的唯一完整的软件解决方案是从某种形式派生AES密钥通过组合所有硬件设备的序列号构建的“硬件指纹”。然后使用该AES密钥加密凭据。在同一台服务器上运行的进程可以重建AES密钥并解密凭据，但是一旦从服务器中提取文件，该文件基本上是不可解密的。
物联网为此深陷其中：
硬件序列号是唯一的假设可能不成立，并且
与服务器不同，攻击者可以物理访问设备，因此很可能在该设备上获得外壳
硬件加密（TPM）和“硬件指纹”加密都充其量是混淆的，因为从根本上说，如果本地进程可以解密数据，则攻击者可以运行该本地进程也可以对其进行解密。
因此，标准技巧似乎在这里不起作用。您需要问自己的第一个问题是：
我的威胁模型是什么/这个项目在
Secure <--> Convenient规模上位于何处？最终，我认为您要么需要确定
security > convenience并在每次启动后让人员输入凭据（使用类似@BenceKaulics的答案），要么您确定security < convenience并仅将凭据放在设备上，也许使用一些混淆如果您觉得这有所作为。由于物联网设备的性质，这是一个很难解决的难题。
为了完整起见，成熟的工业解决此问题的方法是：在制造时为每个IoT设备提供唯一的RSA公钥。根据设备序列号将此公钥记录在db中。
将敏感凭据存储在适当的服务器上，我们将其称为“网关”。
当IoT设备通过网关进行身份验证时（使用其RSA）密钥），网关会使用存储的凭据为其打开会话，并将会话令牌交还给设备。
为了获得最佳安全性，网关是物理（或VPN）网关，因此来自IoT设备的所有流量通过网关，您就可以更好地控制防火墙规则和内容-理想情况下，可以防止设备直接（非VPN隧道）访问互联网。
这样，攻击者就会破坏设备可以打开一个会话，但永远无法直接访问凭据。
评论
是。问题的很大一部分是，此处要保护的是共享密码，即wifi密码。当可以对设备进行物理解剖时，共享秘密不是一个好主意。更好的设计会将设备（或其他计算机）的每个实例隔离到其自己的安全环境中，并在每个小工具与需要与之通信的系统之间使用唯一的安全通道。因此，相对于某些点对点2.4 GHz方案甚至是“ Esp Now”协议，wifi可能不是非常适合该应用程序。
–克里斯·斯特拉顿（Chris Stratton）
17/09/13在2:12
好点子。您可以通过使用WPA2企业客户端证书而不是SSID密码来解决共享机密问题（如果IoT设备足够大以至于可以具有TLS堆栈，则很多则不能）。我对Azure IoT中心一无所知，但我假设这些Azure设备连接字符串已经是每个设备唯一的字符串。不幸的是，这似乎在“ DIY无安全性”和“工业规模安全性”之间是非常干净的黑白，两者之间没有太多区别。
–麦克·恩斯沃思（Mike Ounsworth）
17/09/13在2:19
我想知道是否可以随意打开会话，为什么我需要凭据？
–安德鲁（Andrew Savinykh）
17年9月13日在8:58
@AndrewSavinykh取决于凭据是什么。也许他们所做的只是打开一个会话，在这种情况下，没有太多理由。但是，也许它们是Windows域AD凭据，或者可以访问通常不使用或无法从IoT设备访问的其他API。也许您对来自受感染设备的会话感到满意，但对于来自攻击者的笔记本电脑的会话则不太满意。是的，它很快就可以用于特定的用例。
–麦克·恩斯沃思（Mike Ounsworth）
17年9月13日在13:40
序列号？？？找到唯一的序列号应该不是问题，但是序列号不是秘密。它们没有用做密钥。在世界上哪个地方使用序列号作为“标准把戏”？
–吉尔斯'所以-不再是邪恶的'
17 Sep 14'6:27
#2 楼
威胁是真实存在的，但幸运的是，您不是第一个或只有一个具有此类安全问题的人。您需要的是ESP WiFi Manager，这是您需要的。
有了这个库，ESP可以没有保存的会话将切换到AP模式，并将托管一个Web门户。如果通过PC或智能手机连接到此AP，则可以通过网页配置WiFi凭据。
您不必对关键信息进行硬编码，并且可以在任何WiFi上使用设备
它的工作原理
ESP启动时，它会以Station模式设置并尝试连接到以前保存的访问点
如果不成功（或没有保存以前的网络），它将把ESP移到访问点模式并启动DNS和WebServer（默认ip 192.168.4.1） ）
通过浏览器（计算机，电话，平板电脑）使用任何支持wifi的设备连接到新创建的访问点
强制门户和DNS服务器，您将获得“加入网络”类型的弹出窗口，或者将您尝试访问的任何域重定向到配置门户。
选择其中一个访问点扫描，输入密码，点击保存
ESP将尝试连接。如果成功，它将控制权交还给您的应用。如果不是，请重新连接到AP并重新配置。
（ESP WiFi Manager文档）
评论
或仅在AP模式下下载记录或其他内容。希望张贴者不要试图将wifi本身用于资产跟踪。
–克里斯·斯特拉顿（Chris Stratton）
17年9月12日在23:23
@ChrisStratton :-)实际上，我正在尝试使用WiFi进行资产跟踪。幸运的是，我使用的WiFI网络是公开且开放的，但是当我需要使用另一个需要密码的网络时，我会担心其中的隐含含义。设备上还存在AzureIoT Hub连接字符串的事实。
–公羊
17年9月13日在12:13
@rams当然，读取设备的EEPROM并不是一项艰巨的任务。
– Bence Kaulics
17年9月13日在12:49
@rams在您的硬件上，可以读取EPROM。较新的设备可能具有一些安全的闪存区域，可以得到更好的保护。当然，这是一个已知的问题，需要片上支持才能正常工作。
– Sean Houlihane
17年9月14日在14:52
@SeanHoulihane-ESP8266没有EEPROM。它用于一切的SPI闪存（包括对Arduino功能的仿真）在ESP8266外部。即使在多芯片模块中，它也是一个独特的管芯，可以在不错的实验室中进行探测。
–克里斯·斯特拉顿（Chris Stratton）
17年9月14日在20:05
#3 楼
是的，如果您以纯文本形式保留密码，他们可以访问您的密码。好处是，许多wifi连接接口都接受哈希密码。虽然我使用的那些接受了md5散列并且md5并不是超级安全，但对于普通joe来说仍然是一个非常艰巨的挑战。根据您的配置文件，您可以声明哈希算法的名称，然后输入密码，或者使用wifi接口使用的默认值。
评论
如果他们可以提取在散列时有效的散列密码，那么如何防止他们使用它而又不会逆转密码呢？
–克里斯·斯特拉顿（Chris Stratton）
17 Sep 12'在23:19
@ChrisStratton你是对的。预防此问题的方法是针对Information Security SE，此问题要求防止凭据丢失。但是，如果没有其他软件，手机仍然无法使用哈希密码来连接网络。
–atakanyenel
17年9月12日在23:25
是的，实际上，在某些其他系统上重复使用wifi密码的情况下，它可以提供一些保护，但是对于未授权连接到该wifi接入点的保护不大。
–克里斯·斯特拉顿（Chris Stratton）
17年9月12日在23:28
@ChrisStratton是的，例如，MAC白名单比简单地拥有密码和对其进行哈希处理要安全得多，但是这些步骤通常是为了实现wifi安全性，而不是为了保护公共设备上凭据的私密性。
–atakanyenel
17年9月12日在23:34
不，MAC白名单只是个玩笑-根本没有秘密。当然，可以很容易地从被盗的ESP8266或其SPI闪存中提取MAC。 MAC白名单唯一可以帮助解决的问题是，反对使用GUI加入wifi网络的人，或者访问点正坐在那里等待来自客户端的连接，该连接可能有一天会出现，但从未连接过-例如，剑在石头上的东西。
–克里斯·斯特拉顿（Chris Stratton）
17 Sep 12'在23:37
#4 楼
简单的答案-是的。可以办到。至少必须进行某种混淆处理以提供最小的保护。
评论
混淆使查找设备的工作方式变得更加困难，但是它对于防止设备克隆无济于事。防止提取凭证是没有用的：您要做的就是在仿真器中运行固件。
–吉尔斯'所以-不再是邪恶的'
17年9月14日在6:31
完全同意。我给出此类答案的动机是要注意<必须考虑IoT网络安全>。 @Mike Ounsworth提供了详细的答案，提出了使用AES和/或RSA基础结构的解决方案建议。我正在考虑再给出一个答案，但是我不确定如何使用加密技术（我在支付和银行解决方案领域也有多年经验）。我的想法是，我们必须提供实用/平衡的建议，因为通常人们会避免深入研究密码学来保护他家后院的物联网设备。
– Amit Vujic
17-09-14在11:48
如果人们因为不愿意弄清楚如何制造安全设备而想要制造不安全的设备，我认为没有理由启用它们。
–吉尔斯'所以-不再是邪恶的'
17年9月14日在23:02
我的经验是人们想学习，但同样，安全级别和复杂性之间必须达到平衡。支付行业中有一个关于SET的著名故事（en.wikipedia.org/wiki/Secure_Electronic_Transaction），它非常安全，但实施起来很复杂，并且由于实践而失败。
– Amit Vujic
17年9月14日在23:16
混淆会增加复杂性，而不会提高安全性。那不是平衡。
–吉尔斯'所以-不再是邪恶的'
17年9月14日在23:25
评论
我认为@Mike Ounsworth和Bence Kaulics的答案一起给了我一个不错的选择。不幸的是，我不能将两者都标记为已接受答案。