Lưu trữ khóa an toàn trong bộ nhớ của thiết bị nhúng


10

Tôi đang làm việc trên một thiết bị nhúng gửi / nhận dữ liệu và lưu trữ chúng ở chế độ bản mã (chế độ được mã hóa). Bây giờ cách tiếp cận tốt nhất để lưu trữ khóa (Tôi đã sử dụng MCU dòng ARM CORTEX M) là gì?

1-Lưu trữ các khóa trong bộ nhớ SRAM và trong mỗi trình tự khởi động, tiêm các khóa vào MCU được nhúng và lưu trữ chúng trong bộ nhớ SRAM. Theo cách tốt nhất tôi nghĩ, sau đó khi MCU cảm nhận được sự thâm nhập (với cảm biến giả mạo hoặc ...), nó có thể xóa SRAM nhanh chóng và tự thiết lập lại. Nhược điểm: nếu kẻ tấn công thành công để vượt qua các tampers và truy cập vào thiết bị, bộ nhớ SRAM an toàn đến mức nào (chống lại việc khai thác mã). Tôi không thể tìm thấy bất kỳ khả năng bảo mật nào cho bộ nhớ này trong MCU.

2-Tạo khóa và lưu trữ chúng trong bộ nhớ flash trong lập trình MCU. CRP hỗ trợ bộ nhớ flash của MCU (bảo vệ đọc mã) ngăn chặn việc khai thác mã và với sự hỗ trợ của công cụ AES bên trong và công cụ RNG (tạo số ngẫu nhiên), chúng ta có thể tạo một khóa ngẫu nhiên và mã hóa bộ nhớ flash và lưu trữ khóa ngẫu nhiên đó trong OTP ( bộ nhớ lập trình một lần - bộ nhớ được mã hóa 128 bit), sau đó trong quá trình thực thi mã, chúng tôi giải mã bộ nhớ flash bằng khóa RNG và truy cập vào khóa và mã ban đầu. Nhược điểm: Khóa được lưu trữ trong bộ nhớ không bay hơi, tampers sẽ vô dụng và kẻ tấn công có nhiều thời gian để khai thác khóa.

Khóa 3 được lưu trong bộ nhớ EEPROM, kết hợp 2 cách tiếp cận ở trên, khóa được lưu trong bộ nhớ không bay hơi nhưng khi làm giảm cảm giác thâm nhập thì EEPROM có thể xóa được.

Tôi xem xét LPC18S57FBD208 (cortex m3 với bộ nhớ flash 1 MB, 180MHZ, 136KB SRAM, 16KB EEPROM và bộ điều khiển LCD LCD mà tôi cần để lái một màn hình LCD LCD 7 "và động cơ mã hóa AES 128 bit).

Câu trả lời:


18

Không có lựa chọn nào trong số đó đặc biệt tốt hơn hoặc tệ hơn các lựa chọn khác, vì tất cả chúng đều rất không an toàn. Tôi đang đi với tùy chọn 4.

  1. SRAM là nơi an toàn nhất để lưu trữ khóa, nhưng bạn không bao giờ được tiêm chúng từ thế giới bên ngoài. Chúng phải LUÔN LUÔN được tạo trong bộ xử lý, trong khi khởi động. Làm bất cứ điều gì khác ngay lập tức làm mất hiệu lực phần còn lại - nó tự động không an toàn.

  2. Không lưu trữ khóa trong bộ nhớ không biến đổi, bạn đã đúng về điều này. Sẽ không có vấn đề gì nếu bạn bảo vệ EEPROM hoặc bộ nhớ flash khỏi bị đọc. Mã cầu chì bảo vệ đọc được dễ dàng đảo ngược. Kẻ tấn công chỉ cần giải mã (loại bỏ hoặc khắc hóa học bao bì epoxy đen để lộ silicon chết bên trong). Tại thời điểm này, chúng có thể che đi phần chết là các ô nhớ không bay hơi (các phần này rất đều đặn và trong khi các ô nhớ riêng lẻ rất nhỏ để nhìn thấy, cấu trúc lớn hơn có thể) và một phần nhỏ của một cái gì đó mờ đục với UV được che dấu trên phần đó. Sau đó, kẻ tấn công có thể chiếu đèn UV vào chip trong 5-10 phút và đặt lại tất cả các cầu chì, bao gồm cả cầu chì CRP. Bộ nhớ OTP bây giờ có thể được đọc bởi bất kỳ lập trình viên tiêu chuẩn nào.

Hoặc, nếu họ được tài trợ tốt (giả sử, nhận được các khóa đó trị giá hơn 1000 đô la cho ai đó), họ có thể chỉ cần đọc các ô nhớ trực tiếp bằng một số loại kính hiển vi điện tử.

Để được an toàn, các khóa phải được xóa, không được che giấu.

  1. Không, vì những lý do tương tự ở trên.

Bây giờ, vào tùy chọn 4:

  1. Chỉ cần sử dụng mã hóa. Phân phối khóa là một vấn đề được giải quyết. Vì vậy, sử dụng giải pháp có sẵn. Chip nên sử dụng RNG của nó và nhiều cân nhắc khác phải được thực hiện để đảm bảo nó có đủ nguồn cung cấp entropy và bộ tải khởi động nên khởi động trực tiếp vào chương trình tạo (các) khóa bí mật cần có trong mục đích chung đăng ký và chuyển trực tiếp vào SRAM, nơi họ sẽ ở lại cho đến khi bị xóa.

Tuy nhiên, có một vấn đề, đó là không có gì ngoại trừ CPU có bất kỳ ý tưởng nào về khóa bí mật là gì. Không có vấn đề: sử dụng mật mã khóa công khai. Những gì bạn LÀM đã lưu trong bộ nhớ OTP là khóa chung của bạn. Khóa này có thể được đọc bởi bất cứ ai, bạn có thể đăng nó lên trao đổi ngăn xếp, bạn có thể vẽ nó ở bên cạnh một tàu chở dầu bằng chữ cao 5 feet, điều đó không thành vấn đề. Điều tuyệt vời về mật mã khóa công khai là nó không đối xứng. Khóa để mã hóa một cái gì đó không thể giải mã nó, đòi hỏi khóa riêng. Và ngược lại, khóa để giải mã thứ gì đó được mã hóa bằng khóa chung có thể được sử dụng để mã hóa thứ gì đó. Vì vậy, CPU tạo các khóa bí mật, sử dụng khóa chung được lưu trữ của bạn để ENCRYPT các khóa bí mật và chỉ cần gửi nó qua USB hoặc RS232 hoặc bất cứ điều gì bạn muốn. Đọc khóa bí mật yêu cầu khóa riêng của bạn, mà không cần phải được lưu trữ, gửi hoặc bao giờ liên quan đến chip. Khi bạn có khóa bí mật được giải mã bằng khóa riêng của mình (ở nơi khác, bên ngoài chip), bạn đã thiết lập. Bạn có một khóa bí mật được truyền an toàn được TẠO hoàn toàn trong chip, mà không phải lưu trữ bất cứ thứ gì ngoại trừ khóa chung - như đã nêu trước đó, không cần phải bảo vệ khỏi bị đọc.

Quá trình này được chính thức gọi là đàm phán quan trọng, và mọi thứ đều sử dụng nó. Bạn đã sử dụng nó nhiều lần ngày hôm nay. Có rất nhiều tài nguyên và thư viện có sẵn để xử lý nó. Xin vui lòng, đừng bao giờ 'tiêm' chìa khóa vào bất cứ điều gì.

Một điều cuối cùng cần đề cập: Tất cả những điều này là do xe AES có thể dễ dàng phục hồi bằng cách sử dụng các cuộc tấn công kênh bên, nằm trên nguồn cung cấp năng lượng và đo lường sự thay đổi phút trong bản vẽ hiện tại và thời gian giữa những thay đổi gây ra bởi các bit bị lật trong CPU như thanh ghi. Điều này, kết hợp với kiến ​​thức về cách AES (hoặc bất kỳ một trong số rất nhỏ các thuật toán mã hóa có thể sử dụng) hoạt động, làm cho việc khôi phục khóa tương đối dễ dàng và không tốn kém. Nó sẽ không cho phép đọc khóa, nhưng nó có thể thu hẹp không gian phím thành một cái gì đó nhỏ một cách lố bịch, như 255 phím có thể. Con chip cũng không thể phát hiện ra nó, vì nó là thượng nguồn.

Điều này đã đánh bại các bộ tải khởi động được mã hóa AES-256 trên các bộ xử lý tiền điện tử 'an toàn' và nó thậm chí không khó lắm. Theo tôi biết, không có biện pháp chống phần cứng thực sự cho cuộc tấn công này. Tuy nhiên, chính các thuật toán mã hóa và cách chúng yêu cầu CPU lật các bit, điều này gây ra lỗ hổng này. Tôi nghi ngờ rằng các thuật toán chứng minh kênh phụ hoặc kênh bên sẽ cần phải (và hy vọng là) đang được phát triển.

Vì vậy, ngay bây giờ, câu trả lời thực sự về cách lưu trữ khóa (hoặc thậm chí chỉ sử dụng khóa tạm thời) trên thiết bị nhúng một cách an toàn là: bạn không thể.

Nhưng ít nhất nếu bạn tạo khóa mới mỗi lần sử dụng đàm phán khóa trong tùy chọn 4, thì một cuộc tấn công kênh bên chỉ có thể làm tổn hại đến khóa của kênh đang sử dụng và chỉ khi họ có thời gian để theo dõi sức mạnh trong khi nó mã hóa dữ liệu . Nếu bạn thường xuyên đàm phán các khóa mới được tạo trong nội bộ, điều này có thể đủ khả năng bảo mật.

Tạo khóa và lưu trữ chúng trong thời gian ngắn nhất có thể.


Thực sự cảm ơn Metacollin thân yêu vì đã xóa tôi. Nhưng dự án của tôi bao gồm nhiều độc giả (chứa mcu) và nhiều MCU mục tiêu, Mỗi độc giả phải có thể đọc bất kỳ mục tiêu nào và bất kỳ mục tiêu nào cũng có thể được đọc bởi bất kỳ độc giả nào. về điều này tôi nghĩ họ phải đồng ý với một khóa duy nhất để vận chuyển dữ liệu. và dựa trên câu trả lời của bạn, tôi nghĩ rằng không có quá nhiều sự khác biệt giữa ví dụ vỏ bảo mật LPC18S57 và vỏ não chung STM32F429 m4 và vỏ não chung LPC1788 (lựa chọn rẻ hơn), tôi không làm dự án bí mật hàng đầu nhưng tôi muốn làm Điều này là an toàn như tôi có thể.
Mahmoud Hosseinipour

2
Tuyên bố của bạn rằng "Khóa AES có thể dễ dàng phục hồi" ít nhất là có thể nghi ngờ. Tôi hiểu nguyên tắc đằng sau kỹ thuật tìm hiểu những gì xảy ra trong bộ xử lý, dựa trên mức tiêu thụ hiện tại của nó. Tuy nhiên, nó giả định rằng mã hóa và giải mã là điều duy nhất mà cpu đang làm việc. Tuy nhiên, hầu hết các ứng dụng chỉ có 1 cpu hoạt động trên một loạt các tác vụ cùng một lúc. Trong một khối mã hóa AES, hàng chục hoặc hàng trăm ngắt có thể xảy ra khiến cho không thể tìm ra khóa, dựa trên các đỉnh hiện tại.
bakcsa83

2
Nếu khóa không nên được lưu trong flash, thì mã tương tự sẽ tạo ra khóa ... chỉ cần dịch mã op sang trình biên dịch và sau đó bạn có khóa, bất kể mã phức tạp đến mức nào.
Lundin

The wonderful thing about private key cryptography is that it is asymmetric. Mặc dù rõ ràng từ bài đăng của bạn rằng bạn biết điều này, tôi sẽ đề cập đến nó cho những người đọc khác ... s / private / public trong trích dẫn ở trên.
Radian

Bạn có thể bảo mật kênh giữa hai thiết bị bất kỳ bằng phương pháp 4, tuy nhiên, không có một số hình thức bí mật chung, bạn không thể đảm bảo tính xác thực của thiết bị mà bạn đang liên lạc. Nếu trường hợp sử dụng của bạn yêu cầu xác thực, bạn sẽ không có gì tốt hơn khi trao đổi khóa so với khi bạn chỉ lưu trữ một bí mật được chia sẻ duy nhất trong flash. Nếu bạn cần bảo mật tốt hơn, nên sử dụng chip mật mã.
Greg
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.