Lý do không cho rằng địa chỉ MAC của thiết bị là duy nhất

Trong trường hợp bạn kiểm soát việc cung cấp phần cứng và có thể xác định rằng tất cả các thiết bị có cùng kiểu phần cứng thực sự có địa chỉ MAC duy nhất cho giao diện mạng của chúng, có bất kỳ nhược điểm nào khi viết mã sử dụng giả định đó không? (Lưu ý dựa trên một số câu trả lời: Tôi sẽ không viết mã mạng bằng giả định này. Đây chỉ là một cách chạm nhẹ để có uuid trên mỗi thiết bị mà không phải tạo và cập nhật thủ công ổ cứng thiết bị với id trước đó triển khai đến hiện trường)

Cơ sở của vấn đề này là tôi đang nghiên cứu triển khai triển khai loại IOT phần cứng riêng cho khách hàng. Chúng tôi sẽ cung cấp một bộ thiết bị phần cứng có khả năng kết nối mạng để cài đặt ở các địa điểm từ xa. Các thiết bị này sau đó sẽ liên lạc lại với API bằng cách gửi tin nhắn. Để giảm độ phức tạp thiết lập, tôi đã hy vọng gửi địa chỉ MAC của giao diện mạng trên thiết bị trong tin nhắn, để buộc các tin nhắn này trở lại "device_id" ở phía API. Tôi nghĩ rằng bằng cách làm cho nó một cái gì đó không phải được thiết lập trên thiết bị trước khi sử dụng, nó có thể được truy vấn trong khi hoạt động bình thường. Tôi có thể giả định rằng chúng ta có thể xác định rằng các địa chỉ MAC của mỗi thiết bị trên thực tế là duy nhất,

Dựa trên các tuyên bố của bạn mà bạn có thể xác nhận trong quá trình cung cấp rằng MAC của nhà sản xuất trên thực tế là duy nhất trong mạng lưới các thiết bị bạn đang tạo (điều này không chắc chắn, mặc dù vậy), có lẽ bạn đang tiến hành tốt, nhưng hãy xem xét các câu hỏi sau:

• Bạn đang sử dụng MAC để kiểm tra bảo mật (xác thực, ủy quyền)? Nếu vậy, một MAC là không đủ. Thậm chí đừng xem xét nó. Sử dụng cấu trúc mật mã và truyền bất kỳ yêu cầu xác thực nào một cách an toàn.

• 48 bit có đủ rộng không? Có lẽ là vậy, nhưng đáng để hỏi.

• Bạn có bao giờ cần sửa chữa một thiết bị bằng cách thay thế nic của nó không?

• Nếu bạn thay thế toàn bộ thiết bị hoặc thay thế thiết bị của mình, bạn có cần liên kết địa chỉ mới với khóa hiện tại trong cơ sở dữ liệu của mình để đảm bảo thu thập dữ liệu liên tục cho vị trí triển khai không?

• Sẽ có bất kỳ giao diện bảo trì nào mà người dùng (được ủy quyền hay không) có thể thay đổi nic ở cấp độ ROM, trình điều khiển hoặc hệ điều hành? Kẻ tấn công có thể giới thiệu lỗ hổng trong dữ liệu của bạn nếu chúng muốn sửa đổi MAC.

• Dữ liệu của bạn có bao giờ được kết nối với các nguồn dữ liệu khác bằng MAC làm khóa không?

• Bạn có bao giờ sử dụng MAC cho bất kỳ mục đích kết nối mạng nào ngoài việc điều hướng lớp LAN 2 mà thiết bị được kết nối (có dây hoặc không dây) không?

• Mạng LAN mà các thiết bị của bạn được kết nối, là một mạng riêng hay một mạng lớn mà các máy khách tạm thời (như điện thoại di động của nhân viên) sẽ kết nối với?

Nếu câu trả lời của bạn là

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

sau đó tôi không thể nghĩ ra bất kỳ lỗ hổng thực sự nào trong kế hoạch của bạn.

Hãy nhớ rằng, bạn không cần MAC độc đáo trên toàn cầu để thực hiện điều này; bạn chỉ cần đảm bảo rằng tập hợp con của các thiết bị Internet gọi API của bạn là duy nhất. Giống như một nic trùng lặp được gán ở hai thành phố khác nhau không thể va chạm vì chúng ở trên các mạng LAN khác nhau, bạn không thể có thông tin chính về cơ sở dữ liệu trên MAC nếu nó không gọi API của bạn.

Địa chỉ MAC không phải là duy nhất

Có thể có, và sẽ trùng lặp với MAC. Có một số lý do cho điều đó, một lý do là chúng không cần phải là duy nhất (trên toàn cầu).

MAC phải là duy nhất trên mạng cục bộ, vì vậy ARP / NDP có thể thực hiện công việc của nó và công tắc biết nơi gửi các datagram đến. Thông thường (không nhất thiết) điều kiện tiên quyết được thực hiện và mọi thứ hoạt động tốt, đơn giản vì khả năng có hai MAC giống nhau trên cùng một mạng LAN, ngay cả khi chúng không phải là duy nhất, là khá thấp.

Một lý do khác là đơn giản là tồn tại nhiều thiết bị hơn là có địa chỉ. Mặc dù địa chỉ 48 bit nghe có vẻ như có đủ địa chỉ cho mọi người cho đến cuối ngày, nhưng thực tế không phải vậy.

Không gian địa chỉ được chia thành hai nửa 24 bit (phức tạp hơn một chút, nhưng hãy bỏ qua các chi tiết nhỏ nhặt). Một nửa là OUI mà bạn có thể đăng ký với IEEE và chỉ định cho công ty của bạn khoảng 2000 đô la. 24 bit còn lại, bạn làm bất cứ điều gì bạn muốn. Tất nhiên bạn có thể đăng ký một số OUI, đó là những gì người chơi lớn hơn làm.

Lấy Intel làm ví dụ. Họ đã đăng ký tổng cộng 7 OUI, cung cấp cho họ tổng cộng 116 triệu địa chỉ.
Mainboard của máy tính của tôi (sử dụng chipset X99) cũng như mainboard của máy tính xách tay của tôi cũng như mainboard của mọi máy tính dựa trên x86 mà tôi sở hữu trong suốt 10-15 năm qua đã có card mạng Intel như một phần của chipset. Chắc chắn có hơn 116 triệu máy tính dựa trên Intel trên thế giới. Do đó, MAC của họ không thể là duy nhất (theo nghĩa duy nhất trên toàn cầu).

Ngoài ra, các trường hợp đã được báo cáo về việc ... rẻ hơn ... các nhà sản xuất chỉ đơn giản là "đánh cắp" địa chỉ từ OUI của người khác. Nói cách khác, họ chỉ sử dụng một số địa chỉ ngẫu nhiên. Tôi cũng đã nghe nói về các nhà sản xuất chỉ sử dụng cùng một địa chỉ cho một phạm vi sản phẩm hoàn chỉnh. Điều đó không thực sự phù hợp hoặc có nhiều ý nghĩa, nhưng bạn có thể làm gì về nó. Những card mạng tồn tại. Xin nhắc lại: Khả năng nó trở thành một vấn đề thực tế vẫn còn rất thấp nếu địa chỉ được sử dụng cho mục đích của chúng, bạn cần phải có hai trong số chúng trên cùng một mạng LAN để nhận thấy.

Bây giờ, phải làm gì về vấn đề của bạn?

Giải pháp có thể đơn giản hơn bạn nghĩ. Các thiết bị IoT của bạn có thể sẽ cần một số khái niệm về thời gian, thông thường thời gian sẽ tự động có được thông qua NTP. Độ chính xác điển hình của NTP là trong phạm vi micro giây (vâng, đó là vi mô chứ không phải milli). Tôi chỉ chạy ntpq -c rlđể chắc chắn và được bảo 2 ^-20 .

Khả năng hai thiết bị của bạn được bật lần đầu tiên ở cùng một micrô giây chính xác là rất thấp. Điều đó thường có thể xảy ra (đặc biệt là nếu bạn bán hàng triệu trong số đó trong một thời gian rất ngắn, xin chúc mừng thành công của bạn!), Chắc chắn. Nhưng nó không có khả năng lắm - trong thực tế nó sẽ không xảy ra. Vì vậy, tiết kiệm thời gian sau lần khởi động đầu tiên trên cửa hàng vĩnh viễn.

Thời gian khởi động của thiết bị IoT của bạn sẽ giống nhau trên mọi thiết bị. Ngoại trừ điều đó không đúng chút nào .
Với bộ hẹn giờ độ phân giải cao, thời gian khởi động khác nhau đáng kể ngay cả trên cùng một thiết bị, mọi lúc. Có thể chỉ một vài đồng hồ tích tắc khác nhau (hoặc vài trăm nghìn, nếu bạn đọc thứ gì đó như bộ đếm thời gian của CPU), vì vậy không hoàn toàn độc đáo, nhưng nó chắc chắn sẽ thêm một số entropy.
Tương tự, thời gian cần connectđể quay lại lần đầu tiên bạn truy cập trang web API của mình sẽ hơi khác nhau, nhưng có thể đo được, mỗi lần khác nhau. Tương tự, getaddrinfosẽ mất một lượng thời gian hơi khác nhau, có thể đo được cho mọi thiết bị khi lần đầu tiên tìm kiếm tên máy chủ API web của bạn.

Kết hợp ba hoặc bốn nguồn entropy đó (địa chỉ MAC, thời gian bật nguồn lần đầu tiên, thời gian khởi động lần đầu tiên, kết nối thời gian) và tính toán một hàm băm từ đó. MD5 sẽ làm tốt cho mục đích đó. Ở đó, bạn là duy nhất.

Mặc dù điều đó không thực sự đảm bảo tính duy nhất, nhưng "khá nhiều" đảm bảo nó, với một cơ hội thất bại có thể phủ nhận. Bạn sẽ phải có hai thiết bị có MAC giống hệt nhau được bật lần đầu tiên trên cùng một micro giây và mất cùng thời gian để khởi động và kết nối với trang web của bạn. Điều đó sẽ không xảy ra. Nếu điều đó xảy ra, bạn nên bắt đầu chơi xổ số ngay lập tức bởi vì trong tất cả các lần xuất hiện, bạn được đảm bảo sẽ giành chiến thắng.

Tuy nhiên, nếu "sẽ không xảy ra" là không đủ đảm bảo, chỉ cần chuyển cho mỗi thiết bị một số tăng liên tục (được tạo trên máy chủ) trong lần đầu tiên chúng truy cập API web của bạn. Hãy để thiết bị lưu số đó, xong.

Vì vấn đề ở đây thực sự là Vấn đề XY, tôi sẽ giải quyết vấn đề đó là: làm thế nào để có được một mã định danh duy nhất cho một phần cứng trong lần đầu tiên khởi động mà không phải tải trước số nhận dạng lên chúng. Tất cả các phương pháp tốt thực sự làm sôi sục một điều: có một nguồn entropy.

Nếu phần cứng của bạn có thứ gì đó được thiết kế để trở thành nguồn entropy phần cứng (lưu ý: về cơ bản, đây là yêu cầu đối với bất kỳ triển khai thiết bị IoT thích hợp nào vì nó cần cho TLS, vì vậy, phần cứng của bạn nên được thiết kế theo ý đó), chỉ cần sử dụng nó. Nếu không, bạn phải sáng tạo.

May mắn thay, hầu hết mọi máy tính từng được chế tạo đều có một nguồn entropy tuyệt vời: bộ dao động tinh thể (đồng hồ). Tốc độ của một tinh thể nhất định không chỉ phụ thuộc vào sự thay đổi nhiệt độ tinh tế, mà còn chịu sự trễ của nhiệt độ theo những cách phi tuyến. Tuy nhiên, để đo entropy, bạn cần một đồng hồ thứ hai để hẹn giờ đầu tiên. Điều này có nghĩa là, bất cứ khi nào máy tính của bạn có ít nhất hai đồng hồ bạn có thể lấy mẫu, bạn có thể sử dụng tỷ lệ của một cái được đo bằng cái kia như một nguồn entropy chất lượng rất cao.

Tôi không muốn trả lời trực tiếp câu hỏi vì có những câu trả lời rất hay khác nhưng thay vào đó tôi muốn đề xuất một giá trị khác phù hợp hơn có thể có sẵn để sử dụng làm id thiết bị.

Nếu được hỗ trợ bởi phần cứng của bạn, bạn có thể cân nhắc sử dụng SMBIOS UUID. Đây là một id duy nhất cho bo mạch chính và do đó là thiết bị. Hãy nhớ rằng ngay cả các thiết bị IoT có thể có nhiều NIC (LAN & WiFi), vì vậy nếu bạn chọn tuyến MAC, bạn vẫn cần tìm một phương pháp chọn một cách nhất quán.

Ngoài ra, trong khi UUID là duy nhất thì không nên sử dụng cho mục đích bảo mật vì nó chỉ được đảm bảo là duy nhất trong một môi trường thân thiện.

Tôi ghét giả sử có vấn đề XY vì thường OP có lý do phức tạp mặc dù thực hiện mọi thứ theo cách họ đang làm nhưng bạn có thể muốn xem xét các phương pháp khác để tạo số nhận dạng duy nhất cho mỗi thiết bị, như địa chỉ MAC , được "tích hợp" vào thiết bị và không yêu cầu tạo số nhận dạng của riêng bạn.

Nếu tất cả các thiết bị từ cùng một nhà sản xuất (hoặc thậm chí tốt hơn, cùng một kiểu máy), bạn có thể sử dụng số sê-ri để tạo mã định danh. Mặc dù vậy, điều này không hoạt động tốt trên các thiết bị từ các nhà sản xuất khác nhau, ngay cả khi bạn kết hợp nó với tên nhà sản xuất và số kiểu, bởi vì các định dạng số sê-ri khác nhau và có thể các API khác nhau để lấy số sê-ri trong trường hợp thiết bị nhúng / độc quyền . Một thay thế cho số sê-ri thiết bị có thể là số sê-ri của bo mạch chủ, CPU hoặc đĩa cứng (tôi tin rằng việc cấp phép Windows sử dụng kết hợp cả hai).

Cũng đáng nhớ rằng các trình định dạng hệ thống tệp thường tạo một ID duy nhất cho mỗi hệ thống tệp. Trừ khi bạn chuẩn bị tất cả các thiết bị từ cùng một hình ảnh (mà tôi khuyên bạn nên làm, vì những lý do không liên quan), mỗi đĩa cứng sẽ có một ID duy nhất được lưu trữ trong hệ thống tệp mà bạn có thể sử dụng.

Mặc dù đã nói rằng, thực sự không có lý do gì để không sử dụng địa chỉ MAC, đặc biệt nếu là một phần trong quy trình cung cấp của bạn, bạn có thể xác định rằng chúng thực sự là duy nhất (mặc dù điều này thậm chí không cần thiết, giả sử chúng ta đang nói không nhiều hơn Một vài ngàn thiết bị ở đây). Tất nhiên, hãy nhớ rằng bất cứ điều gì bạn sử dụng đều có thể bị giả mạo bởi thiết bị, vì vậy đừng dựa vào điều này để xác thực trong một môi trường không tin cậy (bạn nói đó là một thiết lập riêng tư nên có lẽ đây là một môi trường "đáng tin cậy" mà bạn không quan tâm đến việc khách hàng của bạn giả mạo thiết bị của họ so với máy chủ của họ, nhưng rõ ràng họ nên ghi nhớ điều này nếu việc quản lý thiết bị được bàn giao cho bên thứ ba hoặc người dùng cuối).