Làm cách nào để bảo mật liên lạc giữa ứng dụng và thiết bị IoT?

Tôi hiện đang làm việc trong một dự án bao gồm giao tiếp Bluetooth giữa một ứng dụng di động (hiện đang sử dụng nền tảng Ionic) và một thiết bị nhúng. Để so sánh, sản phẩm của chúng tôi tương tự như một khóa thông minh .

Bảo mật là mối quan tâm lớn nhất và chúng tôi đang tìm cách để đảm bảo phần cứng và phần mềm của chúng tôi không bị hack. Những bước chúng ta nên làm để đảm bảo hệ thống của chúng tôi được an toàn?

Chỉnh sửa: Có, chúng tôi hiện đang mã hóa thông tin liên lạc và sử dụng HTTPS khi thiết bị liên lạc với máy chủ của chúng tôi.

Để đảm bảo rằng thiết bị của bạn đủ an toàn, tôi có một số mẹo:

1. Thêm một số mã hóa vào giao tiếp Bluetooth. Tôi khuyên bạn nên giữ các khóa mã hóa không khí. Ví dụ: bạn có thể yêu cầu người dùng quét mã QR trên thiết bị, được in trong hộp, v.v. tại thiết lập ban đầu của ứng dụng di động, có thể bằng phím AES? Tùy bạn Điều này là để ngăn người khác nhìn thấy mật khẩu được truyền qua không trung với văn bản đơn giản.
2. Nếu bạn có thể, hãy tránh xa chế độ ECB (sử dụng CBC) của thuật toán mã hóa bạn chọn, vì nó có thể cung cấp một số thông tin về dữ liệu được truyền. Thông tin thêm về điều đó có thể được tìm thấy ở đây .
3. Trên truyền dữ liệu bluetooth, đảm bảo bao gồm một số ID duy nhất để thông báo không thể lặp lại (ví dụ: bạn có thể bao gồm dấu thời gian). Bạn cũng có thể thực hiện một số hệ thống giống TOTP.
4. Đặt một cổng trên thiết bị cho phép dễ dàng flash, để trong trường hợp bạn nhận ra phần mềm có lỗi (và vì lý do nào đó bạn không thể cập nhật OTA), thiết bị không phải là một chặn giấy đắt tiền, chỉ là một thiết bị cần phải được cắm vào PC và được flash vào phần mềm mới.
5. Bổ sung: Để đảm bảo rằng ai đó có chứng chỉ gốc giả mạo (có thể tự cấp và cài đặt trên thiết bị khách) không thể chặn liên lạc máy chủ của bạn, hãy xác minh chứng chỉ HTTPS. Đây là một SO yêu cầu nó cho Android, bạn cũng có thể tìm thấy các tài nguyên tương tự cho iOS .

Ngoài ra, nếu bạn muốn tìm hiểu thêm về mật mã và mã hóa, bạn sẽ sử dụng để bảo mật thiết bị của mình, hãy kiểm tra ebook (miễn phí) này . Nó nói rất nhiều về việc triển khai tốt và xấu các thuật toán mã hóa, và sẽ giúp bạn bảo mật sản phẩm của mình. (Lưu ý 1: Xin vui lòng, vui lòng không tạo thuật toán của riêng bạn. Lưu ý 2: Tôi không liên kết với crypto101 hoặc lvh.)

Nếu bạn có thể có TCP đầu cuối, thì hãy sử dụng TLS đầu cuối (ví dụ: với HTTPS).

Đừng phát minh lại bánh xe, đặc biệt là khi nói về mật mã - hầu hết mọi người đều hiểu sai. Trừ khi thiết bị quá hạn chế về tài nguyên để hỗ trợ TLS, nếu bạn xuống mức AES, bạn sẽ làm sai . Lỗi số 1 là mã hóa và quên xác thực - nếu bạn có kênh được mã hóa giữa máy chủ của mình và người trung gian, thay vì kênh được mã hóa giữa máy chủ và thiết bị của bạn, thì mã hóa không mang lại lợi ích gì . Nếu bạn không thể sử dụng TLS, hãy đảm bảo rằng bất kỳ giao thức nào bạn đang sử dụng đều xác thực mọi thứ và mã hóa những gì cần được bảo mật.

Để sử dụng TLS một cách an toàn, hãy nghĩ về những gì đảm bảo bạn cần phải có, theo quan điểm của từng người tham gia. Nói chung, thiết bị cần biết rằng nó đang nói chuyện với máy chủ hợp pháp. Điều đó có nghĩa là nó phải kiểm tra chứng chỉ của máy chủ. Thiết bị phải có chứng chỉ X.509 của cơ quan cấp chứng chỉ được ghi là đáng tin cậy; điều này đòi hỏi lưu trữ mà kẻ tấn công không thể sửa đổi, nhưng nó không yêu cầu bất kỳ sự bảo mật nào của việc lưu trữ. Lưu ý rằng bạn không nên mã hóa trực tiếp chứng chỉ của máy chủ, vì điều đó sẽ không cho phép bạn dễ dàng thay thế chứng chỉ đó nếu bị xâm phạm. Thay vào đó, thiết bị lưu trữ danh tính dự kiến(tên máy chủ) của máy chủ và chứng chỉ của cơ quan cấp chứng chỉ đảm bảo rằng khóa công khai nhất định thuộc về tên máy chủ dự kiến. Một lần nữa, đừng phát minh lại bánh xe, hãy dựa vào kiểm tra chứng chỉ được cung cấp bởi thư viện hoặc ứng dụng TLS của bạn.

Nếu máy chủ cần biết rằng nó đang nói chuyện với một khách hàng hợp pháp, thì mỗi khách hàng cần phải có chứng chỉ ứng dụng khách riêng. Điều đó đòi hỏi lưu trữ bí mật trên máy khách. Truyền chứng chỉ ứng dụng khách cho chức năng mở phiên TLS từ thư viện TLS của bạn hoặc đặt nó trong cấu hình ứng dụng.

Điều đó quan tâm đến việc đảm bảo liên lạc giữa máy chủ và thiết bị của bạn. Nếu ứng dụng di động có thể nói chuyện trực tiếp với thiết bị (ví dụ: cho phép ngắt kết nối hoạt động trong khi trên mạng wifi cục bộ), trước tiên bạn cần thực hiện ghép nối giữa công tắc thông minh và điện thoại di động. Ghép nối có nghĩa là trao đổi khóa, tốt nhất là trao đổi khóa công khai nếu tài nguyên cho phép, nếu không thì là thỏa thuận về khóa bí mật. Mục tiêu của việc ghép nối này là để đảm bảo rằng mỗi thiết bị biết ai đang nói chuyện với ai.

Bạn cũng cần bảo mật kênh điều khiển, cho dù kênh này đi trực tiếp từ thiết bị di động sang công tắc thông minh hay thông qua máy chủ. Hãy suy nghĩ về ủy quyền: có các cấp truy cập khác nhau đối với công tắc, ví dụ: cấp điều khiển cho phép thực hiện cấu hình lại và kênh cơ bản chỉ cho phép bật / tắt chuyển đổi? Điều này thường được xử lý bằng một bước xác thực sau khi thiết lập kênh bảo mật (TLS nếu có thể).

Một xem xét khác là cập nhật firmware. Đó là một điều khó khăn: một mặt, không có thứ gọi là bảo mật tuyệt đối, vì vậy bạn sẽ có các bản vá bảo mật để áp dụng ngay bây giờ. Mặt khác, một cơ chế nâng cấp firmware là một điều phức tạp và bản thân nó có thể có lỗi. Ít nhất, hãy chắc chắn rằng các bản nâng cấp firmware của bạn đã được ký. Dựa hoàn toàn vào tính bảo mật của kênh liên lạc để nâng cấp là tinh ranh, bởi vì độ tin cậy dựa trên kênh bảo mật lớn hơn so với xác minh bảo mật tĩnh và đôi khi bạn có thể muốn áp dụng các bản cập nhật firmware mà không cần kết nối mạng. Ngoài việc xác minh chữ ký, lý tưởng nhất là bạn nên có một số biện pháp bảo vệ chống lại rollback, để kẻ thù có thể '