Các tiêu chuẩn để giữ cho bảo mật của thiết bị được cập nhật


8

Với các thiết bị IoT thường được xây dựng với tỷ suất lợi nhuận thấp và thông số kỹ thuật năng lượng thấp, chức năng thường bị giới hạn ở mức cần thiết. Nhưng đối với một thiết bị dự kiến ​​sẽ tồn tại trong một số năm, sẽ có các lỗ hổng bảo mật và các vấn đề cần khắc phục (xem ví dụ về botnet Mirai)

Là nhà sản xuất IoT, làm cách nào tôi có thể kích hoạt vá hoặc nâng cấp thuật toán mã hóa hoặc giao thức bảo mật từ xa hoặc chỉ cần đảm bảo rằng thiết bị được giữ an toàn? Tôi nên tuân theo những tiêu chuẩn nào?


1
Tôi sợ câu trả lời hầu hết thời gian là 'sử dụng các giải pháp độc quyền'.
Helmar

Mặc dù là một chủ đề thú vị và có liên quan, câu hỏi này không thể có loại câu trả lời cụ thể mà các trang web SE được bảo lưu. Nó cũng có khả năng nhanh chóng lèo lái vào lãnh thổ của ý kiến.
Chris Stratton

1
Cảm ơn @Gilles - điều đó mang lại câu hỏi đúng về chủ đề.
Rory Alsop

Câu trả lời:


5

Làm thế nào để các nhà sản xuất IoT cho phép vá hoặc nâng cấp các thuật toán mã hóa hoặc giao thức bảo mật từ xa hoặc đơn giản để đảm bảo rằng thiết bị được giữ an toàn?

Một số lượng lớn các nhà sản xuất IoT có một giải pháp đơn giản cho vấn đề này: "đừng bận tâm" . Những người này có xu hướng là cùng các nhà phát triển thêm mật khẩu mặc định (hoặc thậm chí không thể thay đổi) vào thiết bị của họ, điều này dẫn đến Mirai ngay từ đầu.

Như đã đề cập trong câu trả lời của Rory , có những chi phí lớn để cung cấp cả cơ chế và thời gian phát triển thực tế để thiết kế và triển khai các bản sửa lỗi. Tôi nghi ngờ rằng nếu không có áp lực pháp lý (hoặc nhu cầu của người tiêu dùng, dường như không phải vậy), sẽ không có động cơ nào để nhà sản xuất tăng giá sản phẩm của họ để tăng cường bảo mật. Úc dường như đang thực hiện bước này bằng cách xem xét một hệ thống xếp hạng bảo mật bắt buộc cho tất cả các thiết bị IoT.

Tôi nghĩ rằng đối với hầu hết các nhà sản xuất, ý tưởng tốt nhất là nhờ người khác xử lý bảo mật. Cũng giống như hầu hết các nhà phát triển web sử dụng khung thành lập như DjangoRuby on Rails để tránh làm cho các giống sai lầm hơn và hơn, các nhà phát triển IOT nên làm như vậy. Có một số tùy chọn, tùy thuộc vào độ phức tạp của thiết bị của bạn:

  • Các thiết bị cao cấp hơn có thể sử dụng các hệ điều hành như Ubuntu IoT hoặc Windows 10 IoT Core , nơi các bản cập nhật bảo mật được thực hiện bởi nhà phát triển hệ điều hành và được đẩy tự động. Phần lớn trong số này không dành riêng cho IoT, nhưng tốt hơn nhiều so với mỗi thiết bị IoT sử dụng hệ điều hành nội bộ tùy chỉnh không có khả năng nhận bất kỳ bảo trì nào.

  • Các thiết bị cấp thấp như mô-đun ESP8266 có lẽ hạn chế hơn, vì chúng không thể chạy các hệ điều hành phức tạp như vậy và có xu hướng chạy mã được phát triển riêng cho thiết bị đó. Vẫn còn các tùy chọn như Mongoose OS cung cấp các bản cập nhật firmware không dây

Các nhà sản xuất IoT thường nên tận dụng các giải pháp hiện có nếu có. Các nhà phát triển web thường không tạo lại một khung web cho mỗi trang web mới, vậy tại sao IoT phải khác biệt đáng kể? Câu trả lời của Rory cung cấp một danh sách các tính năng tuyệt vời cần được triển khai bởi một hệ điều hành tốt cho IoT và chỉ cần sử dụng "Hệ điều hành IoT" sẽ không khắc phục được tất cả các vấn đề của bạn. Như hướng dẫn Windows IoT này giải thích, người ta phải thực hiện các bước để đảm bảo phần cứng và phần sụn được bảo mật cũng như chính hệ điều hành. Các ý tưởng trong câu trả lời của Rory khá toàn diện về vấn đề này.

Dưới đây là một số ví dụ từ các hệ điều hành tôi đã đề xuất về những hệ thống họ sử dụng để nâng cấp bảo mật:


3

Moran đã đăng dự thảo IETF này với tiêu đề Kiến trúc cập nhật phần sụn cho thiết bị Internet of Things vào ngày 30 tháng 10 năm 2017.

Một tóm tắt quan trọng được nêu ra tại máy tính Bleeping

  • Cơ chế cập nhật phải hoạt động như nhau ngay cả khi nhị phân phần sụn được phân phối qua Bluetooth, WiFi, UART, USB hoặc các phương tiện khác.
  • Cơ chế cập nhật phải hoạt động theo kiểu phân phối quảng bá, cho phép các bản cập nhật tiếp cận nhiều người dùng cùng một lúc.
  • Bảo mật đầu cuối (mật mã khóa công khai) phải được sử dụng để xác minh và xác thực hình ảnh phần sụn.
  • Các cuộc tấn công rollback phải được ngăn chặn.
  • Tất cả thông tin cần thiết để thiết bị đưa ra quyết định về việc cài đặt bản cập nhật phải phù hợp với RAM có sẵn của thiết bị IoT bị ràng buộc. Điều này ngăn chặn kiệt sức viết flash.
  • Mất điện bất cứ lúc nào trong quá trình cập nhật không được gây ra lỗi cho thiết bị.
  • Cơ chế cập nhật chương trình cơ sở không được yêu cầu thay đổi các định dạng tệp chương trình cơ sở hiện có.
  • Cơ chế cập nhật firmware mới phải có khả năng hoạt động với bộ tải khởi động nhỏ, dành riêng cho hầu hết các thiết bị IoT.
  • Cơ chế cập nhật phải chiếm nhiều quyền. Ví dụ: bản cập nhật chương trình cơ sở cho thiết bị cơ sở hạ tầng quan trọng sẽ phải được ký bởi cả tác giả chương trình cơ sở và chủ sở hữu / nhà điều hành thiết bị.
  • Kiến trúc cập nhật firmware IoT mới phải hỗ trợ các tệp kê khai.

Đây là rất nhiều một dự thảo, vì đây là một lĩnh vực mới. Kỳ vọng của tôi là nó sẽ được điều khiển bởi quy định nhiều hơn là theo nhu cầu của người tiêu dùng, vì người tiêu dùng thực sự không quan tâm đến các cập nhật hoặc bảo mật trừ khi chúng ảnh hưởng trực tiếp đến chúng. Bất kỳ cải tiến trong lĩnh vực này sẽ ảnh hưởng đến chi phí của thiết bị.


1

Nếu phần sụn của thiết bị của bạn có thể được thực hiện ít phức tạp hơn bộ tải khởi động cần thiết cho một bản cập nhật từ xa được bảo mật, thì không thực hiện cập nhật từ xa .

Tôi biết sự đồng thuận là có một bộ tải khởi động an toàn và mạnh mẽ, với xác thực tiền điện tử công khai mạnh mẽ, cơ chế cuộn qua an toàn, có thể là ngăn xếp mạng cơ bản, sau đó đặt lên trên RTOS, với ngăn xếp mạng IP + TLS đầy đủ, sau đó thêm trên đầu trang của ứng dụng của bạn. Đây là sự điên rồ thuần túy cho một thiết bị năng lượng thấp chi phí thấp. IMHO, điều này dẫn đến các sản phẩm được cập nhật mỗi tuần hoặc lâu hơn, điều này có xu hướng làm phiền người dùng vì đôi khi các bản cập nhật bắt đầu không đúng lúc, thất bại hoặc phá vỡ một cái gì đó. Cập nhật cũng tiêu tốn rất nhiều năng lượng, vì vậy người dùng phải sạc thường xuyên hơn. Và an ninh vẫn còn lâu mới được đảm bảo vì bề mặt tấn công là lớn.

Thiết bị của bạn đang thực hiện cảm biến / kích hoạt cơ bản, có thể một số kích hoạt / hiển thị cục bộ nhưng không nhiều? Bỏ qua tất cả

Viết mã kim loại trần, sử dụng một ngăn xếp rất cơ bản, kiểm tra kỹ lưỡng, thực hiện một số xác minh chính thức nếu có thể. Và sau đó bạn có thể tương đối tự tin rằng thiết bị của bạn sẽ không gặp vấn đề về bảo mật trong thập kỷ tới.

Nếu tất cả những gì bạn có là một cái búa, mọi thứ trông giống như một cái đinh. Và đó là lý do tại sao hầu hết các lập trình viên cố gắng viết mã để bảo mật mã hiện có không bảo mật của họ. Viết ít mã không phải lúc nào cũng đến một cách tự nhiên.


Đáng buồn thay, đó là một quan điểm sai lầm, nếu bạn nhìn vào tất cả các bằng chứng. Bạn không thể dựa vào bảo mật trong bất kỳ khoảng thời gian nào. Và những gì làm cho bạn nghĩ rằng nhiều thập kỷ sẽ là đủ? Và ngay cả khi bạn đang dựa vào một cái gì đó như SSL cho comms và bạn nghĩ rằng nó an toàn, bạn vẫn tìm thấy những sai sót đã tồn tại trong nhiều năm. Bạn cần một ngăn xếp comms mạnh (như BearSSL cho các nền tảng nhúng nhỏ) sẽ ổn, nhưng nó vẫn cần phải được cập nhật. Vì vậy, câu hỏi được hỏi về các tiêu chuẩn cho điều này - một bài đăng nói rằng nó không cần thiết chỉ là không phải là một câu trả lời.
Rory Alsop

2
Đây là chế độ xem hợp lệ vừa phải nếu bạn đang sử dụng MCU dựa trên flash có giới hạn với tối đa RTOS và tự tin rằng bạn sẽ không cần thêm chức năng hoặc sửa lỗi chức năng sau khi vận chuyển. Nhưng một khi bạn bắt đầu sử dụng một hệ điều hành chính thức, bề mặt tấn công chỉ quá lớn để cho rằng sẽ không có vấn đề gì mà bạn không biết tại thời điểm vận chuyển.
Chris Stratton

2
Một điều kiện cần thiết khác để không cần cập nhật mã là: nếu thiết bị của bạn không nghe các gói từ Internet, bao gồm trả lời các gói của chính nó. Nói cách khác, nếu thiết bị của bạn không có kết nối Internet. Ngay khi bạn kết nối với mạng, bạn cần cập nhật chống lại các cuộc tấn công mạng sẽ được phát hiện.
Gilles 'SO- ngừng trở nên xấu xa'
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.