不假定设备MAC地址唯一的原因

如果您控制硬件的配置，并且可以确定所有具有相同硬件模型的设备的确确实具有用于其网络接口的唯一MAC地址，那么编写使用该假设的代码是否有不利之处？（请注意，基于一些答复：我不会使用这种假设来编写网络代码。这只是一种低接触的方式，每个设备都具有一个uuid，而无需在之前手动生成和更新具有ID的设备HDD部署到现场）

背景知识是，我正在研究为客户端实现私有硬件IOT类型的实现。我们将提供一组具有联网功能的硬件设备，以安装在远程位置。然后，这些设备将通过发送消息与API通信。为了降低设置的复杂性，我希望在消息中发送设备上网络接口的MAC地址，以便将这些消息绑定到API端的“ device_id”。我的想法是，通过使它不需要在使用前在设备上进行设置，就可以在正常操作期间对其进行查询。我可以放心地假设我们可以确定每个设备的MAC地址实际上是唯一的，

根据您在配置过程中可以确认制造商MAC实际上在您所创建的设备网络中是唯一的声明（虽然不一定，尽管可以确定），您可能是个不错的选择，但请考虑以下问题：

• 您是否正在使用MAC进行安全检查（身份验证，授权）？如果是这样，则MAC是不够的。甚至不用考虑。使用密码结构，并安全地传输任何身份验证请求。

• 48位足够宽吗？它可能是，但是值得一问。

• 您是否需要更换设备来维修设备？

• 如果确实要完全替换设备或替换其nic，是否需要将新地址与数据库中的现有键相关联，以确保部署位置的数据收集的连续性？

• 是否有任何维护界面，用户（无论是否经过授权）都可以通过该界面在ROM，驱动程序或操作系统级别更改nic？如果攻击者修改MAC，可能会在您的数据中引入缺陷。

• 是否会使用MAC作为密钥将您的数据与其他数据源结合在一起？

• 除了将设备连接到的第2层LAN（有线或无线）简单导航之外，您是否会将MAC用于任何联网目的？

• 您的设备将连接到局域网还是专用网络，还是将连接大量临时客户端（例如员工手机）？

如果你的答案是

NO, yes, no, no, no, no, no, private

那么我就不会想到您的计划中有任何真正的缺陷。

请记住，您不需要全局唯一的MAC即可实现此目的；您只需要确保调用您的API的Internet设备的子集是唯一的即可。就像在两个不同城市中分配的重复nic因为它们位于不同的LAN上而不会冲突一样，如果您从未调用过您的API，您就无法在MAC上发生数据库密钥冲突。

MAC地址不是唯一的

MAC可以重复，也可以重复。造成这种情况的原因有很多，其中之一是它们不必（全局）唯一。

MAC在本地网络上必须是唯一的，因此ARP / NDP可以完成其工作，并且交换机知道将传入数据报发送到的位置。通常（不一定）满足先决条件并且一切正常，仅仅是因为在同一LAN上拥有两个相同MAC的可能性（即使它们不是唯一的）也很低。

另一个原因是，仅存在的设备多于地址。虽然48位地址听起来似乎每个人的地址在年底之前都足够，但事实并非如此。

地址空间分为两个24位半部分（稍微复杂一些，但让我们忽略一些小细节）。一半是OUI，您可以向IEEE注册并以大约2000美元的价格分配给您的公司。剩下的24位，您可以随心所欲。当然，您可以注册几个OUI，这是较大的参与者所做的。

以英特尔为例。他们已经注册了7个OUI，总共给他们提供了1.16亿个地址。
我的计算机主板（使用X99芯片组），笔记本电脑的主板以及我在过去10到15年间拥有的每台基于x86的计算机的主板中，都有 Intel网卡作为该芯片组的一部分。当然，全球有超过1.16亿台基于Intel的计算机。因此，它们的MAC 不可能唯一（从全局意义上来说）。

另外，据报道，有一些案件……价格便宜……制造商只是在“偷”别人的OUI地址。换句话说，他们只是使用了一些随机地址。我听说过制造商也只将相同的地址用于完整的产品范围。两者都不是真正合规的，也不是很有意义，但是您能做些什么。这些网卡存在。再说一遍：如果将地址用于它们的预期用途，那么变成实际问题的可能性仍然很小，您需要在同一LAN上放置两个地址，以便注意。

现在，如何处理您的问题？

解决方案可能比您想像的要简单。您的物联网设备很可能需要一些时间概念，通常时间是通过NTP自动获取的。NTP的典型精度在微秒范围内（是的，这是微秒，而不是毫秒）。我只是跑ntpq -c rl了肯定一下，被告知2 ^-20。

您的两个设备在完全相同的微秒内首次打开的可能性非常低。当然，这是有可能发生的（尤其是如果您在很短的时间内卖出了数百万个，祝贺您成功！）。但这不太可能-实际上不会发生。因此，节省了在永久存储区上首次启动后的时间。

IoT设备的启动时间在每个设备上都相同。除非那不是真的。
给定高分辨率计时器，即使在同一设备上，每次引导时间都明显不同。也许只有几个时钟滴答不同（或者，如果您读到类似CPU的时间戳计数器，则可能是几十万个），因此虽然不是很独特，但是肯定会增加一些熵。
同样，connect第一次访问API网站所花费的时间会略有不同，但是每次都可以不同。同样，getaddrinfo初次查找Web API的主机名时，每个设备所花费的时间会略有不同，并且是可衡量的。

连接这三个或四个熵源（MAC地址，第一次上电时间，第一次启动时间，连接时间），并从中计算出一个哈希值。MD5可以很好地达到此目的。在那里，你是独一无二的。

尽管这不能真正保证唯一性，但它“相当”可以保证它具有失败的可能性。您将必须拥有两个具有相同MAC的设备，这些设备在同一微秒内首次打开，并且花了完全相同的时间启动和连接到您的站点。那不会发生。如果发生这种情况，您应该立即开始玩彩票，因为从所有方面来看，您都一定会中奖。

但是，如果“将不会发生”还不足以作为保证，则只需在每个设备首次访问您的Web API时向它们依次传递一个数字（在服务器上生成）即可。让设备存储该号码，完成。

由于这里的问题实际上是XY问题，因此我将解决以下问题：如何在首次启动时为硬件获取唯一的标识符，而不必将标识符预加载到它们上。所有好的方法实际上归结为一件事：拥有熵的来源。

如果您的硬件具有某种设计来作为硬件熵源（请注意：这基本上是任何正确的IoT设备实现的要求，因为TLS需要它，因此在设计硬件时应牢记这一点），只需使用它即可。如果没有，那么你必须要有创造力。

幸运的是，几乎每台制造过的计算机都具有出色的熵源：晶体振荡器（时钟）。给定晶体的速率不仅取决于细微的温度变化，而且甚至会以非线性方式受到温度滞后的影响。但是，要测量熵，您需要第二个时钟来计时。这就是说，只要您的计算机上至少有两个时钟，您就可以采样，就可以将一个时钟速率（由另一个时钟速率测量）用作高质量的熵源。

我不想直接回答这个问题，因为还有其他非常好的回答，但是我想建议另一个更合适的值，该值可以用作设备ID。

如果硬件支持，则可以考虑使用SMBIOS UUID。这是主板以及设备的唯一ID。请记住，即使是IoT设备也可以具有多个NIC（LAN和WiFi），因此，如果您选择MAC路由，您仍然需要找到一种一致选择方法。

同样，尽管UUID是唯一的，但不应将其用于安全目的，因为只能保证它在友好的环境中是唯一的。

我讨厌假设出现XY问题，因为通常OP有一个很好的理由，尽管这样做的原因很复杂，但是您可能想研究其他方法来为每个设备生成唯一的标识符，例如MAC地址，是“内置”在设备中的，不需要生成您自己的标识符。

如果所有设备都来自同一制造商（或者更好的是同一型号），则可以使用序列号生成标识符。但是，即使您将其与制造商名称和型号结合使用，这在来自不同制造商的设备上也无法很好地实现，因为在嵌入式/专有设备的情况下，序列号格式不同，并且用于获取序列号的API可能不同。设备序列号的替代方法可能是主板，CPU或硬盘的序列号（我相信Windows许可使用了这些的组合）。

还应该记住，文件系统格式化程序通常为每个文件系统生成一个唯一的ID。除非您从同一映像准备所有设备（出于不相关的原因，我建议这样做），否则每个硬盘将已经在您可以使用的文件系统中存储了唯一的ID。

话虽这么说，但实际上没有理由不使用MAC地址，尤其是如果在配置过程中您可以确定它们实际上是唯一的（尽管甚至没有必要，假设我们所讨论的不超过几千个设备）。当然，请记住，您使用的任何内容都可能被设备欺骗，因此请勿在不可信的环境中依赖此身份进行身份验证（您说这是私有设置，所以大概这是一个“可信的”环境，您不会关心您的客户端将自己的设备欺骗到自己的服务器上，但是如果将设备的管理移交给第三方或最终用户，他们显然应该牢记这一点。