SSL một chiều có thể bảo mật thiết bị IoT không?

Tôi đang xem xét một thiết bị IoT được kết nối với mạng cục bộ của mình (cài đặt mặc định, không có VPN, không có NAT, không có DMZ) có hoặc không có truy cập Internet. Thiết bị của tôi sẽ chạy như một máy chủ HTTP cung cấp cơ chế RPC với xác thực và ủy quyền. Nó tự quảng cáo với mDNS và tôi nói chuyện với nó bằng ứng dụng di động hoặc RaspberryPi của tôi.

Dường như tiêu chuẩn trong phát triển IoT là phải có SSL (hai chiều) lẫn nhau. Điều đó có nghĩa là SSL một chiều không thể bảo mật các đề tài của tôi? Tại sao?

Ghi chú:

• Tôi hiểu sự khác biệt về kỹ thuật giữa SSL một chiều và hai chiều, tôi không hiểu tại sao một chiều (gần như) không bao giờ được xem xét trong sản xuất IoT.
• Tôi hiểu rằng có SSL tương hỗ cho một thiết bị cục bộ là khó khăn: bạn cần chia sẻ khóa công khai của máy chủ và chứng chỉ cho khách hàng và ngược lại. Mặt khác, một chiều, có vẻ dễ dàng hơn (không yêu cầu hành động của người dùng).
• Một số thiết bị được sản xuất hàng loạt như Philips Hue thà mở điểm cuối http cục bộ và không bảo mật hơn mã hóa SSL một chiều. Tại sao một người sẽ đưa ra lựa chọn này?
• Tôi hy vọng câu hỏi này không dựa trên ý kiến. Xin lỗi nếu đây là trường hợp.

SSL / TLS hoạt động tốt khi "máy chủ" ở vị trí đã biết (tên máy chủ cố định) có thể khớp với CN của chứng chỉ mà nó xuất trình.

Điều này không hoạt động tốt cho thiết bị trên mạng gia đình (ví dụ: hầu hết các thiết bị IoT) vì chúng có xu hướng nhận địa chỉ IP được cấp từ các khối RFC1918 và không có mục DNS. Điều này có nghĩa là chúng không thể được cấp chứng chỉ (chúng cũng có thể nhưng hầu hết các trình duyệt sẽ từ chối chúng). Đây là lý do tại sao các thiết bị như Philips Hue sử dụng các điểm cuối HTTP không bảo mật của thiết bị, về cơ bản chúng dựa vào quyền truy cập vào mạng được bảo mật để bảo vệ thiết bị.

Khi sử dụng TLS lẫn nhau, đó là khi thiết bị đang kết nối với một số dịch vụ trung tâm, khách hàng có khóa chứng nhận / khóa riêng để xác thực rằng nó có thể hành động thay mặt chủ sở hữu với máy chủ trung tâm đó.

Để làm rõ câu hỏi của bạn, bạn không cần phân phối cert / key máy chủ cho tất cả các máy khách, chỉ cần chứng chỉ của CA cấp chứng chỉ là cần thiết để chứng minh chứng chỉ được tin cậy.

BIÊN TẬP:

Một ví dụ điển hình về kết nối thiết bị cục bộ được bảo mật là ánh sáng Tradfri của IKEA sử dụng COAP trên DTLS với khóa chia sẻ trước (trong mã QR) trên thiết bị được sử dụng để tạo khóa cho mỗi máy khách. Điều này đảm bảo quyền truy cập vật lý để thiết lập máy khách mới và bảo vệ dữ liệu trong chuyến bay trên mạng cục bộ.

Nói chung, TLS tốt cho nhiều hơn x.509, nhưng nhiều triển khai chỉ giới hạn ở mức x.509.

x.509 là một kỹ thuật cho một sự tin tưởng gián tiếp an toàn. "A" tin tưởng "B", nếu "B" có chứng chỉ, được ký bởi "C" và "C" được tin cậy bởi "A". Điều đó cũng hoạt động trong cuộc sống thực; bạn tin tưởng người mà bạn không biết, nếu một lá thư được trình bày có chữ ký của người bạn tin tưởng. Có thể bạn thấy cạm bẫy: nếu bức thư nói, xin vui lòng cho một tách cà phê bạn sẽ không đưa xe của bạn. Do đó, thông tin bổ sung trong chứng chỉ cũng có liên quan đến phạm vi tin cậy. Đó là lý do tại sao một máy chủ thường có tên dns hoặc địa chỉ IP trong chứng chỉ của nó. Nói chung, bạn có thể bao gồm các thông tin khác nhau (ví dụ: "đèn phòng khách"), nhưng nhiều triển khai cũng ít nhất được cấu hình sẵn để sử dụng / kiểm tra công cụ DNS / IP. Và tất cả chỉ hoạt động nếu ai đó quan tâm đến người đáng tin cậy "

Nếu bạn có thể dành thời gian cho nó, hãy kiểm tra việc triển khai của bạn, nếu nó cũng cung cấp các bộ mật mã PSK. Nếu không, có lẽ bạn có thể điều chỉnh "kiểm tra xác thực" của chứng chỉ máy chủ. Nhưng nó đòi hỏi rất nhiều đọc để tìm một giải pháp tốt. Và đôi khi việc triển khai TLS được sử dụng chỉ không cung cấp điều đó.