Przechowywanie bezpiecznego klucza w pamięci urządzenia wbudowanego

Pracuję na wbudowanym urządzeniu, które wysyła / odbiera dane i zapisuje je w trybie zaszyfrowanym (tryb zaszyfrowany). Jakie jest teraz najlepsze podejście do przechowywania kluczy (użyłem MCU ARM CORTEX serii M)?

1-Przechowywanie kluczy w pamięci SRAM i w każdej sekwencji rozruchowej, wstrzyknij klucze do wbudowanego MCU i zapisz je w pamięci SRAM. Myślę, że to najlepszy sposób, kiedy MCU wyczuje penetrację (z czujnikiem sabotażu lub ...) może szybko usunąć SRAM i zresetować się. Wada: jeśli atakującemu uda się przekazać sabotaże i dostęp do urządzenia, jak bezpieczna jest pamięć SRAM (przed eksploracją kodu). Nie mogę znaleźć żadnej zdolności bezpieczeństwa dla tej pamięci w MCU.

2-Generuj klucze i przechowuj je w pamięci flash podczas programowania MCU. Obsługa pamięci flash MCU CRP (ochrona odczytu kodu), która zapobiega eksploracji kodu, a przy pomocy wewnętrznego silnika AES i silnika RNG (generowanie liczb losowych) możemy utworzyć losowy klucz i zaszyfrować pamięć flash i zapisać ten losowy klucz w OTP ( pamięć programowalna jednorazowo - 128-bitowa pamięć szyfrowana), następnie podczas wykonywania kodu dekodujemy pamięć flash kluczem RNG i dostęp do klucza początkowego i kodów. Wada: klucze przechowywane w nieulotnej pamięci, sabotaże będą bezużyteczne, a atakujący będzie miał dużo czasu na wydobycie kluczy.

3-przechowywany klucz w pamięci EEPROM, kombinacja 2 powyższych podejść, klucz przechowywany w pamięci nieulotnej, ale gdy manipuluje wyczuciem penetracji, pamięć EEPROM jest kasowalna.

Rozważam LPC18S57FBD208 (kora m3 z 1 MB pamięci flash, 180 MHz, 136 KB SRAM, 16 KB EEPROM i kontroler TFT LCD, które muszę napędzać 7 "TFT LCD i 128-bitowym silnikiem kryptograficznym AES), czy jest jakaś lepsza sugestia?

Żadna z tych opcji nie jest szczególnie lepsza ani gorsza od innych, ponieważ wszystkie są bardzo niepewne. Idę z opcją 4.

1. SRAM jest najbezpieczniejszym miejscem do przechowywania kluczy, ale nigdy nie wolno wstrzykiwać ich ze świata zewnętrznego. Muszą być ZAWSZE generowane w procesorze podczas uruchamiania. Robienie czegokolwiek innego natychmiast unieważnia resztę - jest to automatycznie niepewne.

2. Nie przechowuj kluczy w nieulotnej pamięci, masz rację. Nie ma znaczenia, czy zabezpieczysz pamięć EEPROM lub pamięć flash przed odczytem. Bezpiecznik do odczytu kodu można łatwo odwrócić. Atakujący musi jedynie odszyfrować (usunąć lub wytrawić chemicznie czarne opakowanie epoksydowe, aby odsłonić wewnątrz silikonową matrycę). W tym momencie mogą zakryć część matrycy, która jest nieulotnymi komórkami pamięci (te sekcje są bardzo regularne i chociaż poszczególne komórki pamięci są zbyt małe, aby je zobaczyć, większa struktura może być) i mały kawałek czegoś nieprzezroczyste dla UV jest maskowane w tej sekcji. Następnie atakujący może po prostu zapalić światło UV na chipie przez 5-10 minut i zresetować wszystkie bezpieczniki, w tym bezpiecznik CRP. Pamięć OTP może teraz zostać odczytana przez dowolnego standardowego programistę.

Lub, jeśli są dobrze finansowane (powiedzmy, że zdobycie tych kluczy jest dla kogoś warte więcej niż 1000 USD), mogą po prostu odczytać komórki pamięci bezpośrednio za pomocą kilku rodzajów mikroskopów elektronowych.

Aby być bezpiecznym, klucze należy usunąć, a nie ukryć.

3. Nie, z tych samych powodów powyżej.

Teraz przejdź do opcji 4:

4. Po prostu użyj szyfrowania. Dystrybucja kluczy to rozwiązany problem. Więc skorzystaj z tego łatwo dostępnego rozwiązania. Układ powinien korzystać ze swojego RNG i należy wziąć pod uwagę różne inne kwestie, aby zapewnić wystarczającą podaż entropii, a moduł ładujący powinien uruchomić się bezpośrednio w programie, który generuje potrzebne tajne klucze, które powinny mieć ogólny cel rejestruje się i przenosi bezpośrednio do SRAM, gdzie pozostanie do skasowania.

Istnieje jednak problem polegający na tym, że nic oprócz CPU nie ma pojęcia, czym jest tajny klucz. Nie ma problemu: użyj kryptografii klucza publicznego. To, co masz w pamięci OTP, to Twój klucz publiczny. Ten klucz może odczytać każdy, możesz go umieścić na wymianie stosu, możesz pomalować go na boku tankowca literami o wysokości 5 stóp, to nie ma znaczenia. Wspaniałą rzeczą w kryptografii klucza publicznego jest to, że jest asymetryczna. Klucz do szyfrowania czegoś nie może go odszyfrować, co wymaga klucza prywatnego. I odwrotnie, klucz do odszyfrowania czegoś zaszyfrowanego kluczem publicznym nie może być użyty do zaszyfrowania czegoś. Procesor generuje tajne klucze, używa przechowywanego klucza publicznego do SZYFROWANIA tajnych kluczy i po prostu wysyła je przez USB lub RS232 lub cokolwiek zechcesz. Czytanie tajnego klucza wymaga klucza prywatnego, które nie muszą być przechowywane, wysyłane ani nigdy w ogóle związane z chipem. Po odszyfrowaniu tajnego klucza za pomocą klucza prywatnego (gdzie indziej, poza układem), jesteś gotowy. Masz bezpiecznie przesłany tajny klucz, który został WYGENEROWANY całkowicie w układzie scalonym, bez konieczności przechowywania czegokolwiek poza kluczem publicznym - który, jak wspomniano wcześniej, wcale nie musi być chroniony przed odczytaniem.

Ten proces jest formalnie nazywany kluczową negocjacją i używa go każda rzecz. Używałeś go już kilka razy dzisiaj. Istnieje wiele zasobów i bibliotek do obsługi tego. Proszę, nigdy nie „wciskaj” kluczy do niczego.

I ostatnia rzecz do wspomnienia: wszystko to jest dyskusyjne, ponieważ klucz AES można łatwo odzyskać za pomocą ataków z kanału bocznego, które siedzą na zasilaczu i mierzą drobne zmiany w bieżącym pobraniu oraz czas między tymi zmianami spowodowanymi odwracaniem bitów w procesorze jako rejestry. To w połączeniu ze znajomością sposobu działania AES (lub dowolnego z bardzo niewielkiego zestawu możliwych algorytmów szyfrowania, które można zastosować) sprawia, że ​​odzyskanie klucza jest stosunkowo łatwe i niedrogie. Nie pozwoli na odczytanie klucza, ale może zawęzić przestrzeń klawiszy do czegoś absurdalnie małego, na przykład 255 możliwych kluczy. Układ również nie może go wykryć, ponieważ jest nadrzędny.

Ten został pokonany AES-256 zaszyfrowanych bootloaderów na „bezpiecznych” procesorów kryptograficznych i to nawet nie jest takie trudne. O ile mi wiadomo, nie ma prawdziwych sprzętowych środków zaradczych dla tego ataku. Jednak to same algorytmy szyfrowania i to, jak wymagają procesora do odwracania bitów, powoduje tę podatność. Podejrzewam, że algorytmy oporne na kanały boczne lub kanały boczne będą musiały zostać (i mam nadzieję) zostać opracowane.

Tak więc, w obecnej postaci, prawdziwą odpowiedzią na to, jak bezpiecznie przechowywać klucz (a nawet po prostu używać klucza tymczasowego) na urządzeniu wbudowanym jest: nie możesz.

Ale przynajmniej jeśli generujesz nowy klucz za każdym razem przy użyciu negocjacji klucza w opcji 4, atak bocznego kanału może naruszyć klucz używanego kanału i tylko wtedy, gdy mają czas na monitorowanie mocy, podczas gdy szyfruje dane . Jeśli często negocjujesz nowe klucze generowane wewnętrznie, może to zapewnić przydatne zabezpieczenia.

Generuj klucze i przechowuj je tak krótko, jak to możliwe.