Có phải là một thực tế xấu để giữ chứng chỉ trên bộ nhớ ngoài?

Chúng tôi đang làm việc trên AWS-IoT bằng vi điều khiển STM32.

Đến ngày hôm nay, chúng tôi đã viết chứng chỉ cho đèn flash và khóa đèn flash khỏi việc đọc bên ngoài. Khi mã ứng dụng tăng lên, chúng tôi sẽ nhận được ít không gian hơn trên flash, vì vậy chúng tôi đã lên kế hoạch di chuyển chứng chỉ ra bên ngoài trên thẻ SD / EEPROM và đọc bất cứ khi nào cần trước khi kết nối với AWS-IoT.

Ghi chú:

• Chính sách được viết cho điều này sẽ chỉ cho phép các thiết bị có tên cụ thể kết nối trên chứng chỉ cụ thể đó.

• Điều này chỉ được phép xuất bản thành 2 kênh (tên và kênh cung cấp dữ liệu) được kết nối với bộ xử lý dữ liệu sẽ bỏ qua mọi gói tin lừa đảo đến với nó.

• Nếu điều đó xuất bản / đăng ký vào bất kỳ chủ đề nào khác, AWS sẽ ngắt kết nối điều đó ngay lập tức.

Nếu tôi phát hiện một thiết bị bị đánh cắp / lừa đảo, chúng tôi sẽ hủy kích hoạt khóa khỏi máy chủ.

Người khai thác có thể làm gì với các chứng chỉ (RootCA, khóa máy chủ, khóa máy khách)?

Có phải là một thực tế xấu khi giữ các chứng chỉ cho usecase đó trên một bộ lưu trữ ngoài mà người khai thác có thể truy cập không?

Bạn đề cập đến các chứng chỉ của Nhật Bản, nhưng từ ngữ cảnh, tôi nghĩ bạn đang đề cập đến hai điều khác nhau.

• Thiết bị của bạn có một khóa riêng , là duy nhất cho thiết bị này và không được biết đến bên ngoài thiết bị. Phím này xác định thiết bị của bạn. Bất cứ ai có thể truy cập khóa đó đều có thể mạo danh thiết bị. Điều đó có nghĩa là họ có thể, đặc biệt:

  • Xuất bản dữ liệu hợp lệ, nhưng không chính xác trên các kênh mà thiết bị của bạn được ủy quyền hợp pháp để xuất bản.
  • Xuất bản dữ liệu không hợp lệ sẽ bị cấm thiết bị hợp pháp.
  • Có thể, tùy thuộc vào trường hợp sử dụng, để lộ một số thông tin riêng tư của chủ sở hữu thiết bị.

  Khóa riêng này tốt hơn vẫn được giữ bí mật.

• Điện thoại của bạn có thể có ít nhất một công chính, mà để cho nó nhận ra máy chủ nó đang nói chuyện với. Sẽ ổn thôi nếu ai đó có thể đọc khóa này: nó công khai. Nhưng kẻ tấn công không thể sửa đổi khóa. Nếu không, họ có thể giao tiếp với thiết bị và mạo danh máy chủ. Điều này có thể cho phép họ làm những việc như:

  • Đẩy một bản cập nhật firmware cho thiết bị.
  • Đẩy một bản cập nhật cấu hình cho thiết bị.
  • Làm cho thiết bị tải dữ liệu của nó đến một vị trí khác.

Tin tốt là phân tích mối đe dọa này thực sự không liên quan lắm. Bạn không cần phải hy sinh bất kỳ bảo mật ! (Ít nhất không phải là thuộc tính bảo mật và tính xác thực - nếu bạn lưu trữ bên ngoài, thì tính khả dụng sẽ bị ảnh hưởng, vì đó là một phần của hệ thống có thể bị mất.)

Miễn là bạn có ít nhất 128 bit lưu trữ mà bạn có thể ghi vào ít nhất một lần, mà bạn có và hơn thế nữa, bạn có thể thực hiện một giải pháp lưu trữ từ xa an toàn. Sử dụng bộ nhớ trên thiết bị có không gian giới hạn để lưu trữ khóa bí mật. Khóa bí mật này phải là duy nhất cho mỗi thiết bị; STM32 có RNG phần cứng, vì vậy bạn có thể tạo nó trên thiết bị trong lần khởi động đầu tiên. Nếu thiết bị của bạn không có RNG phần cứng, bạn có thể tạo khóa ở vị trí ngoài thiết bị an toàn và đưa nó vào thiết bị.

Với khóa này, hãy sử dụng mã hóa được xác thực cho những thứ bạn lưu trữ trên thiết bị. Khi bạn muốn đọc một số dữ liệu từ bộ nhớ ngoài, hãy tải nó, giải mã và xác minh nó. Khi bạn muốn ghi một số dữ liệu vào bộ nhớ ngoài, hãy mã hóa và ký tên. Điều này đảm bảo rằng dữ liệu được bảo mật và xác thực như dữ liệu trong bộ nhớ trong.

Mã hóa được chứng thực là đủ để đảm bảo tính bảo mật và tính xác thực của dữ liệu, nhưng nó không hoàn toàn đảm bảo tính toàn vẹn của nó .

• Nếu có nhiều hơn một đoạn dữ liệu, thì khi thiết bị đọc lại một đoạn dữ liệu, không thể chắc chắn đây là đoạn dữ liệu chính xác. Giải pháp: bao gồm một định danh duy nhất trong nội dung của từng đoạn (ví dụ như bắt đầu mỗi đoạn với một trong những "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• Nếu bạn cập nhật dữ liệu tại một số điểm, thì khi bạn đọc lại, bạn không thể chắc chắn rằng bạn đang nhận được phiên bản mới nhất của dữ liệu đó. Nếu ai đó có thể sửa đổi bộ nhớ ngoài, họ không thể đặt dữ liệu giả vì điều đó sẽ không kiểm tra tính xác thực, nhưng họ có thể khôi phục dữ liệu cũ, vì những gì đã được xác thực vẫn là xác thực. Giải pháp: trong mỗi khối dữ liệu được lưu trữ bên ngoài, bao gồm một bộ đếm mà bạn tăng lên mỗi khi bạn viết một phiên bản mới của đoạn dữ liệu đó. Khi bạn đọc một đoạn trở lại, hãy xác minh rằng đó là phiên bản dự kiến.

Để tránh làm hỏng thiết bị trong trường hợp bộ nhớ ngoài bị hỏng hoặc bị mất, trong không gian hạn chế bạn có không gian trên bộ nhớ trong, bạn nên ưu tiên mọi thứ cần thiết để đặt lại thiết bị về trạng thái tốt, ví dụ như cài đặt lại nhà máy . Ưu tiên thứ hai sẽ là những cân nhắc về hiệu suất.

Một chút bối cảnh

Vì bạn đang sử dụng MQTT với AWS IoT, nên bạn sẽ sử dụng chứng chỉ X.509 để xác thực và bảo mật. Amazon có một chút hướng dẫn về cách bạn nên bảo mật chứng chỉ của mình, vì vậy tôi sẽ trích dẫn điều đó tại đây:

Chứng chỉ cho phép các khóa bất đối xứng được sử dụng với các thiết bị. Điều này có nghĩa là bạn có thể ghi khóa riêng vào bộ nhớ an toàn trên thiết bị mà không bao giờ cho phép tài liệu mật mã nhạy cảm rời khỏi thiết bị.

Vì bạn hiện đang sử dụng Bảo vệ Đọc ra (RDP) của STM32 , nhưng tất cả những kẻ tấn công kiên quyết nhất sẽ gặp khó khăn khi truy cập chứng chỉ của bạn trong sơ đồ hiện tại của bạn:

Bảo vệ Đọc ra toàn cầu cho phép mã chương trình cơ sở nhúng (được tải sẵn trong bộ nhớ Flash) để bảo vệ chống lại kỹ thuật đảo ngược, bán phá giá bằng các công cụ gỡ lỗi hoặc các phương thức tấn công xâm nhập khác.

• Cấp 0 - Không bảo vệ (mặc định)
• Cấp 1 - Bộ nhớ flash được bảo vệ chống đọc bằng cách gỡ lỗi hoặc đổ mã theo mã được nạp RAM
• Cấp độ 2 - Tất cả các tính năng gỡ lỗi bị vô hiệu hóa

Là lưu trữ bên ngoài sẽ được an toàn?

Nó có lẽ không phải là như an toàn . Nếu khóa riêng của khách hàng của bạn bị đánh cắp, kẻ tấn công có thể gửi dữ liệu dường như từ thiết bị của bạn, khi thực tế không phải vậy. Mặc dù không rõ dữ liệu nào bạn đang gửi, bất kỳ dữ liệu không đáng tin cậy nào cũng có thể là rủi ro bảo mật.

Những bit nào tôi cần giữ riêng tư?

Khi bạn tạo chứng chỉ thiết bị trên AWS IoT, bạn sẽ thấy một hình ảnh như thế này:

^{Hình ảnh từ trang Tạo và Kích hoạt Chứng chỉ Thiết bị của tài liệu AWS IoT.}

Khóa riêng là thứ bạn thực sự cần giữ ... riêng tư và chắc chắn nên được lưu trữ trên bộ nhớ được bảo vệ đọc nếu có thể. Khóa công khai và chứng chỉ được thiết kế để chia sẻ, vì vậy nếu bạn hết dung lượng, bạn có thể di chuyển chúng sang bộ nhớ ngoài một cách an toàn. Bạn có thể có thêm một chút ngữ cảnh trên trang Làm thế nào để SSL / TLS hoạt động? tại Sàn giao dịch bảo mật thông tin và mật mã khóa công khai trên Wikipedia. Tôi nghĩ rằng tôi sẽ làm cho bạn một sự bất đồng nếu tôi không đưa hình ảnh này vào để giải thích tại sao khóa riêng cần phải bí mật:

.

^{Hình ảnh từ Wikipedia , được phát hành vào phạm vi công cộng.}

Khóa chung của thiết bị của bạn là những gì AWS IoT sử dụng để ký tin nhắn để gửi đến thiết bị của bạn (nhưng nó không chứng minh được ai đang gửi tin nhắn ). Vì vậy, thực sự, đó không phải là một thảm họa lớn nếu ai đó đánh cắp khóa công khai, bởi vì nó không có nghĩa là một bí mật.

Khóa riêng là thứ mà thiết bị của bạn sử dụng để giải mã tin nhắn, do đó, vấn đề lớn hơn một chút nếu kẻ tấn công đánh cắp thứ này.

Bạn cũng hỏi chuyện gì sẽ xảy ra nếu kẻ tấn công lấy trộm chứng chỉ RootCA. Nếu ai đó lấy trộm khóa riêng của AWS IoT , điều đó sẽ là thảm họa, nhưng chứng chỉ RootCA trên thiết bị của bạn không phải vậy . Các RootCA.crtmà Amazon cung cấp cho bạn là hoàn toàn công cộng , và mục đích là để bạn có thể xác minh rằng bạn không bị tấn công trong bất kỳ cách nào (có thể là một man-in-the-middle giả vờ là máy chủ AWS IOT của).

Những thiết bị bị tấn công có thể gây thiệt hại gì?

Thiết bị bị đánh cắp của bạn chỉ có thể thực hiện các hành động được liệt kê trong chính sách . Cố gắng tuân theo nguyên tắc đặc quyền tối thiểu ; chỉ cấp cho thiết bị của bạn những đặc quyền mà nó hoàn toàn cần , vì vậy nếu điều tồi tệ nhất xảy ra, nó không thể tàn phá quá nhiều. Đối với trường hợp cụ thể của bạn:

Điều này chỉ được phép xuất bản tới 2 kênh (tên của nó và kênh cung cấp dữ liệu) được kết nối với bộ xử lý dữ liệu sẽ bỏ qua mọi gói tin lừa đảo đến với nó.

Điều đó thật tốt. Bất kỳ cuộc tấn công nào cũng nên được tách biệt với hai chủ đề MQTT mà thiết bị có thể xuất bản, vì vậy nó sẽ không gây hại lớn.

Lý tưởng nhất là bạn muốn hệ thống tổng thể của bạn có một thiết kế sao cho việc mổ xẻ một đơn vị chỉ phá vỡ đơn vị đó chứ không phải hệ thống nói chung.

Đặc biệt nếu bạn đang lưu trữ các khóa trong một bộ nhớ riêng biệt để chúng giao tiếp với giao diện điện tiêu chuẩn giữa các chip, thì chúng chỉ nên là các khóa đã an toàn để xuất bản hoặc duy nhất cho trường hợp vật lý cụ thể đó của thiết bị.

Nếu một khóa riêng lẻ được trích xuất từ ​​một thiết bị duy nhất và bắt đầu bị lạm dụng hoặc hiển thị trong một khối lưu lượng truy cập phải từ nhiều bản sao trái phép, thì bạn có thể cấm khóa đó ở phía máy chủ.

Các khóa của bạn dĩ nhiên phải có thuộc tính không phải là thứ mà một bên trái phép có thể đoán từ một vài ví dụ được trích xuất hoặc tạo các trường hợp tương thích ban đầu của riêng họ - tức là, bạn cần một bản ghi các khóa bạn đã tạo trong đó các khóa hợp lệ chỉ là một phần nhỏ và không thể đoán trước của một không gian khả năng lớn, hoặc nếu không bạn cần phải ký các khóa bạn tạo và làm cho hệ thống của bạn chỉ chấp nhận một khóa kết hợp với bằng chứng chữ ký của nó.

Bạn nên cố gắng giữ bí mật khóa khách hàng (nhưng hiểu hàm ý của việc mất nó (1), như được mô tả trong các câu trả lời khác). Khóa công khai của máy chủ và chứng chỉ chung AWS rất quan trọng để bảo mật ở đầu thiết bị không phải vì bạn muốn giữ bí mật mà vì bằng cách thay thế chứng chỉ AWS (trên thiết bị bị xâm nhập), kẻ tấn công có thể thuyết phục thiết bị thực hiện trao đổi với máy chủ của kẻ tấn công hoặc trao đổi thông tin liên lạc của bạn với AWS.

Bằng cách này (2), kẻ tấn công có thể loại bỏ bảo mật TLS, điều này có thể làm giảm đủ bảo mật để họ có thể đảo ngược khóa máy khách.

Theo lý do này, khóa duy nhất an toàn để lộ trong thiết bị bộ nhớ ngoài là khóa chung của máy chủ. Thay đổi điều này (3) sẽ chỉ cho phép thiết bị của bạn bị buộc phải kết nối với dịch vụ AWS giả mạo, điều mà có lẽ khó có thể truy cập được. Ngay cả việc rò rỉ chỉ khóa này cũng có thể cho phép ai đó rình mò hoặc giả mạo một số truyền (ví dụ: nếu lớp TLS có thể bị hạ cấp bằng cách nào đó).

Vì vậy, tóm lại, rủi ro không chỉ đơn giản là rò rỉ thông tin, có rủi ro nếu phần sụn (được cho là đáng tin cậy) có thể được cung cấp với thông tin bảo mật không đáng tin cậy.