Có bất kỳ lợi thế trong việc mã hóa dữ liệu cảm biến không riêng tư?


20

Một số trang web, chẳng hạn như bài viết này về mã hóa đầu cuối cho IoT , đề nghị rằng tất cả lưu lượng truy cập được gửi qua mạng IoT nên được mã hóa, nói:

Các doanh nghiệp, cơ quan chính phủ và các tổ chức khác nên áp dụng [sic] một chiến lược mã hóa-mọi thứ mã hóa để bảo vệ chống lại các vi phạm kích hoạt IoT.

Tôi có thể hiểu sự cần thiết phải mã hóa bất kỳ dữ liệu nào có thể được bảo mật, chẳng hạn như các lệnh để khóa / mở khóa thiết bị 'khóa thông minh', nhưng có thực sự cần thiết phải mã hóa mọi thứ , như cảm biến báo cáo việc đọc bộ điều chỉnh nhiệt hiện tại không?

Có phải chỉ đơn giản là trường hợp "mã hóa mọi thứ" ngăn mọi người quên mã hóa dữ liệu thực sự cần được mã hóa, hoặc có lợi ích thực sự từ việc sử dụng mật mã, mặc dù có thêm sức mạnh, thời gian và chi phí của nó?


5
Bạn sẽ ngạc nhiên về những gì bạn có thể nhận được từ việc đọc nhiệt kế đơn giản. Quay lại khi tôi đang ép xung, tôi đã vẽ biểu đồ nhiệt độ của máy tính. Tôi có thể phát hiện ra lò quay vòng trong biểu đồ đó (rõ ràng), nhưng tôi cũng có thể theo dõi chuyển động của mặt trời trên bầu trời, phát hiện khi đèn phòng được bật hoặc tắt, và cho biết khi ai đó bước vào hoặc rời khỏi phòng - và thực hiện đoán chính xác hợp lý như họ đã ở đâu.
Đánh dấu

Câu trả lời:


25

Hoàn toàn, bởi vì:

  1. Một thiết bị và kênh an toàn có nghĩa là bạn có thể tin tưởng vào dữ liệu . Đúng, nhiệt độ thực tế không quá riêng tư, nhưng kẻ tấn công có thể cung cấp nhiệt độ giả và gây ra phản ứng không mong muốn (ví dụ: bật hệ thống sưởi không cần thiết). Đây là cách stuxnet hoạt động, bằng cách báo cáo sai tốc độ của máy ly tâm, khiến hệ thống điều khiển làm cho chúng đi nhanh hơn cho đến khi chúng bị hỏng. Lưu ý rằng một kênh bảo mật không chỉ được mã hóa mà còn được xác thựcbảo vệ toàn vẹn . Tính toàn vẹn là những gì quan trọng ở đây.
    Mã hóa một mình không cho phép bạn tin tưởng vào dữ liệu: kẻ tấn công có thể sửa đổi dữ liệu được mã hóa ngay cả khi họ không biết chính xác những gì họ đang sửa đổi. Ngay cả xác thực một mình cũng không cho phép bạn hoàn toàn tin tưởng vào dữ liệu, vì dữ liệu xác thực có thể được phát lại. Bạn cần một giao thức đảm bảo tính toàn vẹn dữ liệu.
  2. Thật khó để phân biệt sự khác biệt giữa thiết bị bị lỗi và thiết bị bị xâm nhập. Phát hiện và sửa chữa các lỗi là khó khăn và tốn kém, vì vậy không phải sửa chữa các thiết bị (hoặc gỡ lỗi toàn bộ hệ thống) là đáng để đặt một số bảo mật.
  3. Trong một hệ sinh thái rộng lớn hơn, bạn không muốn một số thiết bị có mã hóa và một số thì không, vì điều này làm tăng chi phí, bảo trì và quản lý thiết bị. Nếu bạn không thể nói, chắc chắn, sẽ không có dữ liệu riêng tư nào được truyền đi trong một vài năm trên hệ thống (không chỉ thiết bị), thì có thể an toàn hơn khi thiết kế nó ngay bây giờ.
  4. Định nghĩa của bạn về dữ liệu riêng tư có thể sai và trừ khi bạn kiểm tra dữ liệu đó với kiểm toán viên và chuyên gia quản lý trên các khu vực bạn vận hành, giả sử rằng dữ liệu đó là riêng tư. Các tọa độ GPS và thậm chí các địa chỉ IP có thể được coi là nhận dạng cá nhân bởi một số khung pháp lý.

8

Cảm biến báo cáo cho một bộ đọc nhiệt hiện tại cảm thấy rất riêng tư đối với tôi. Một tên trộm có thể sử dụng dữ liệu để tìm ra khi một người ở nhà. Sau khi ngôi nhà bị cướp, chủ sở hữu có thể quyết định nên kiện nhà sản xuất bộ điều nhiệt vi phạm quyền riêng tư của họ và do đó cho phép vụ trộm.

Đây có phải là loại rủi ro pháp lý mà một nhà sản xuất máy điều nhiệt muốn cho các sản phẩm của họ? Bạn có muốn tranh luận trước tòa án rằng công ty của bạn hoàn toàn ổn khi cung cấp cho kẻ trộm thông tin mà họ cần biết khi nào đột nhập vào nhà của khách hàng của bạn không?


1
Đó là điều nhạy cảm nhất mà mọi người cứ quên đi: nếu mọi người có một số cảm biến báo cáo một số dữ liệu có vẻ ngu ngốc, người ta có thể bắt đầu theo dõi toàn bộ thói quen hàng xóm chỉ bằng một ăng ten, và thụ động. ("ngu ngốc" có thể là đồng hồ đo điện, đồng hồ nước, nhiệt độ, ánh sáng xung quanh, mức âm thanh, lệnh chuyển đổi ánh sáng, v.v.).
Nipo

6

Có, có lợi thế để mã hóa tất cả các thông tin liên lạc. Bạn sẽ không đăng yêu cầu có bất kỳ lợi thế để khóa nhà của bạn, phải không?

Có câu hỏi không phải là liệu, mà là bao nhiêu, lợi thế có thể có.

Một trong những chuyên gia bảo mật vĩ đại nhất Bruce Schneier , người có một blog tuyệt vời , btw, sẽ nói với bạn rằng bạn không thể làm mọi thứ hoàn toàn an toàn. Những gì bạn có thể làm là làm cho chúng đủ an toàn để làm cho chi phí bẻ khóa chúng nhiều hơn lợi ích từ việc đó.

Về mặt tài chính thô, nếu phải trả 100 đô la để đột nhập vào một nơi nào đó và nhận được 5 đô la, kẻ xâm nhập tiềm năng sẽ bị ngăn chặn, mặc dù có thể đột nhập.

Nói một cách thô thiển, nếu tôi có báo động rõ ràng, camera an ninh, đèn pha kích hoạt chuyển động và một đàn chó săn, một tên trộm quyết đoán vẫn có thể đột nhập vào nhà tôi. Nhưng nếu ngôi nhà của bạn bên cạnh trông giống nhau và không có những vật cản như vậy ...

Bạn có thể đọc rất nhiều suy nghĩ của anh ấy về IoT, bởi Goggling cho Bruce Schneier iot, bao gồm

Thực tế ngẫu nhiên Bruce Schneier # 81

Bruce Schneier đã dạy Chuck Norris cách chia cho số 0 khi họ đứng im lặng trong thang máy.


5

Nó luôn là sự lựa chọn của nhà thiết kế / nhà phát triển. Nhưng sử dụng mã hóa và các biện pháp bảo mật khác trở thành một điều cần thiết trong những ngày này.

Theo một ví dụ, cảm biến báo cáo việc đọc bộ điều nhiệt hiện tại , có thể bị kẻ xâm nhập kiểm soát để gửi cho bạn tín hiệu sai. (Họ có thể có một số chiến lược để cướp bạn bằng cách làm như vậy, ai biết được?)

Bạn có thể đã nghe nói rằng bạn không thể tạo ra các hệ thống không thể truy cập được . Bạn chỉ làm cho các hệ thống khó vi phạm hơn!

Cho dù bạn đã thực hiện những bước nào, họ vẫn có thể phá vỡ chúng. Do đó tại sao phải thực hiện một số bước bổ sung để làm cho nó an toàn?


5

Ngoài các câu trả lời khác, nếu dữ liệu được gửi trong bản rõ thì nó có thể được sửa đổi.

Ngoài các vấn đề được đề cập, dữ liệu giả mạo có thể gây ra (biến nhiệt lên mức tối đa do nhiệt kế nằm giữa mùa hè nóng có thể dẫn đến nguy cơ hỏa hoạn, ví dụ) thao tác dữ liệu có thể dẫn đến thỏa hiệp thiết bị IoT và mọi thứ truy cập vào nó (cho ví dụ: máy tính xách tay của bạn có thể đang kiểm tra nhiệt độ, nhưng trang HTML hiển thị nhiệt độ có thể được thay thế khi truyền vi-rút máy tính được thiết kế để lây nhiễm vào mạng nội bộ của bạn hoặc dữ liệu JSON có thể được sửa đổi để xâm nhập vào ứng dụng đọc dữ liệu không đúng định dạng, v.v.).

Không phải việc triển khai bảo mật là không có rủi ro, đặc biệt là trong thế giới IoT. Bảo mật là khó, và việc thực hiện nó thường làm tăng đáng kể codebase và với số lượng lỗi (và do đó có thể là các vectơ tấn công / cơ hội khai thác). IoT hiếm khi được nâng cấp firmware, vì vậy khi một thiết bị IoT không có cập nhật tự động gặp sự cố, gần như đảm bảo sẽ cung cấp cho Botnet thêm các máy zombie.

Và đúng vậy, tự động nâng cấp không phải là không có vấn đề - từ các vấn đề riêng tư đến khả năng những kẻ bất lương sẽ kiểm soát nó nếu không được thực hiện đúng cách; nhưng nó sẽ có rủi ro thấp hơn so với hy vọng phần sụn đầu tiên của bạn sẽ không có bất kỳ lỗi bảo mật nào cho phép kẻ tấn công tăng thứ hạng zombie của chúng.


1
Nếu dữ liệu được gửi trong bản rõ thì nó có thể được sửa đổi. Điều này cũng không phải là điều ngược lại. Nếu dữ liệu được gửi trong bản rõ và được ký thì nó không thể được sửa đổi mà không bị phát hiện. (Nói chính xác hơn, để phát hiện các sửa đổi, việc truyền cũng cần được bảo vệ chống lại phát lại.) Ngược lại, dữ liệu được mã hóa có thể được sửa đổi nếu không được ký.
Gilles 'SO- ngừng trở nên xấu xa'

@Gilles bạn đúng, tất nhiên - Tôi không muốn phức tạp bằng cách đi vào quá nhiều chi tiết kỹ thuật, do đó, bằng "bản rõ" tôi đã ngụ ý "không có biện pháp bảo mật nào cả" (giống như hầu hết các thiết bị IoT ngày nay hoạt động). Nếu nhà sản xuất bận tâm với dữ liệu đã ký được bảo vệ chống lại phát lại, họ cũng gần như chắc chắn sẽ mã hóa dữ liệu thay vì gửi nó trong bản rõ (có lẽ họ chỉ cần tát lớp TLS khi di chuyển nếu họ bận tâm về bảo mật). Về mặt lý thuyết là có thể, tình huống bạn mô tả sẽ gần như không bao giờ xảy ra trong thực tế.
Matija Nalis
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.