Czy utrzymywanie certyfikatów w pamięci zewnętrznej jest złą praktyką?

Pracujemy nad AWS-IoT za pomocą mikrokontrolera STM32.

Do dzisiaj pisaliśmy certyfikaty do pamięci flash i blokowaliśmy pamięć flash przed odczytem zewnętrznym. Wraz ze wzrostem kodu aplikacji, mamy coraz mniej miejsca we flashu, więc planowaliśmy przenieść certyfikat zewnętrznie na kartę SD / EEPROM i czytać zawsze, gdy był potrzebny przed połączeniem z AWS-IoT.

Uwagi:

• Zasady napisane dla tej rzeczy pozwolą tylko urządzeniom o określonych nazwach łączyć się z tym konkretnym certyfikatem.

• Można publikować tylko na 2 kanałach (nazwa i kanał przesyłania danych), które są podłączone do procesora danych, który zignoruje wszelkie nieuczciwe pakiety do niego przychodzące.

• Jeśli rzecz opublikuje / zasubskrybuje jakikolwiek inny temat, AWS natychmiast ją rozłączy.

Jeśli wykryję, że urządzenie zostało skradzione / nieuczciwe, dezaktywujemy klucz z serwera.

Co może zrobić exploit z certyfikatami (RootCA, klucz serwera, klucz klienta)?

Czy złą praktyką jest przechowywanie certyfikatów dla takich przypadków użycia w pamięci zewnętrznej, do której dostęp może uzyskać exploit?

Wspominacie o „certyfikatach”, ale z kontekstu myślę, że macie na myśli dwie różne rzeczy.

• Twoje urządzenie ma klucz prywatny , który jest unikalny dla tego urządzenia i nie jest znany poza urządzeniem. Ten klucz identyfikuje twoje urządzenie. Każdy, kto ma dostęp do tego klucza, może podszyć się pod urządzenie. Oznacza to, że mogą w szczególności:

  • Publikuj prawidłowe, ale niepoprawne dane w kanałach, na których Twoje urządzenie jest uprawnione do publikowania.
  • Opublikuj nieprawidłowe dane, które zostaną zablokowane dla legalnego urządzenia.
  • Możliwe, że w zależności od przypadku użycia ujawnią pewne prywatne informacje właściciela urządzenia.

  Ten klucz prywatny powinien pozostać poufny.

• Twoje urządzenie prawdopodobnie ma co najmniej jeden klucz publiczny , który pozwala mu rozpoznać, z którymi serwerami rozmawia. Jest w porządku, jeśli ktoś może przeczytać ten klucz: jest publiczny. Ale osoba atakująca nie powinna mieć możliwości modyfikacji klucza. W przeciwnym razie mogą komunikować się z urządzeniem i podszywać się pod serwer. To może pozwolić im na takie rzeczy jak:

  • Wciśnij aktualizację oprogramowania do urządzenia.
  • Wciśnij aktualizację konfiguracji do urządzenia.
  • Spraw, aby urządzenie przesyłało dane do innej lokalizacji.

Dobrą wiadomością jest to, że ta analiza zagrożeń nie jest tak naprawdę istotna. Nie musisz poświęcać żadnego bezpieczeństwa ! (Przynajmniej nie właściwości poufności i autentyczności - jeśli przechowujesz rzeczy na zewnątrz, dostępność jest hitem, ponieważ jest to jeden element systemu, który może zaginąć).

Tak długo, jak masz co najmniej 128 bitów pamięci, do których możesz zapisać przynajmniej raz, które posiadasz i więcej, możesz wdrożyć bezpieczne rozwiązanie do zdalnego przechowywania. Użyj ograniczonej przestrzeni na urządzeniu do przechowywania tajnego klucza. Ten tajny klucz musi być unikalny dla każdego urządzenia; STM32 ma sprzętowy RNG, dzięki czemu można go wygenerować na urządzeniu podczas pierwszego uruchomienia. Jeśli twoje urządzenie nie miało sprzętowego RNG, możesz wygenerować klucz w bezpiecznej lokalizacji poza urządzeniem i wstrzyknąć go do urządzenia.

Za pomocą tego klucza użyj uwierzytelnionego szyfrowania dla rzeczy, które przechowujesz poza urządzeniem. Aby odczytać niektóre dane z pamięci zewnętrznej, załaduj je, odszyfruj i zweryfikuj. Jeśli chcesz zapisać niektóre dane w pamięci zewnętrznej, zaszyfruj je i podpisz. Gwarantuje to, że dane są tak poufne i autentyczne jak dane w pamięci wewnętrznej.

Uwierzytelnione szyfrowanie wystarcza do zagwarantowania poufności i autentyczności danych, ale nie do końca gwarantuje ich integralność .

• Jeśli jest więcej niż jeden fragment danych, wówczas gdy urządzenie odczytuje fragment danych, nie ma pewności, że jest to poprawny fragment. Rozwiązanie: to unikalny identyfikator w treści każdego fragmentu (np rozpocząć każdy kawałek z jednego "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• Jeśli w pewnym momencie zaktualizujesz dane, to po ich ponownym odczytaniu nie będziesz mieć pewności, że otrzymujesz najnowszą wersję tych danych. Jeśli ktoś może zmodyfikować pamięć zewnętrzną, nie może umieścić fałszywych danych, ponieważ nie udałoby się to sprawdzić autentyczności, ale może przywrócić stare dane, ponieważ to, co kiedyś było autentyczne, jest nadal autentyczne. Rozwiązanie: w każdym fragmencie danych przechowywanym zewnętrznie dołącz licznik, który zwiększasz za każdym razem, gdy piszesz nową wersję tego fragmentu. Po przeczytaniu fragmentu sprawdź, czy jest to oczekiwana wersja.

Aby uniknąć blokowania urządzenia w przypadku uszkodzenia pamięci zewnętrznej lub jej utraty w inny sposób, w ograniczonej przestrzeni na wewnętrznej pamięci należy priorytetowo potraktować wszystko, co jest potrzebne do zresetowania urządzenia do „dobrego” stanu, np. Przywrócenie ustawień fabrycznych . Drugim priorytetem będą względy wydajności.

Trochę kontekstu

Ponieważ używasz MQTT z AWS IoT, oczekuje się , że będziesz używać certyfikatów X.509 do uwierzytelniania i bezpieczeństwa. Amazon ma trochę wskazówek, jak zabezpieczyć swoje certyfikaty, dlatego zacytuję to tutaj:

Certyfikaty umożliwiają używanie kluczy asymetrycznych z urządzeniami. Oznacza to, że możesz wypalać klucze prywatne w bezpiecznym miejscu na urządzeniu, nie pozwalając wrażliwym materiałom kryptograficznym na opuszczenie urządzenia.

Ponieważ obecnie używasz funkcji ochrony przed odczytem (RDP) STM32 , wszyscy atakujący oprócz najbardziej zdeterminowanych będą mieli problemy z dostępem do certyfikatów w bieżącym schemacie:

Globalna ochrona przed odczytem pozwala wbudowanemu kodowi oprogramowania układowego (wstępnie załadowanemu do pamięci Flash) zabezpieczyć przed inżynierią wsteczną, zrzutem przy użyciu narzędzi do debugowania lub innymi atakami inwazyjnymi.

• Poziom 0 - Brak ochrony (domyślnie)
• Poziom 1 - Pamięć flash jest chroniona przed odczytem przez debugowanie lub zrzucanie kodu przez kod załadowany do pamięci RAM
• Poziom 2 - Wszystkie funkcje debugowania są wyłączone

Czy pamięć zewnętrzna będzie bezpieczna?

Prawdopodobnie nie jest tak bezpieczny . Jeśli klucz prywatny klienta zostanie skradziony, osoba atakująca może wysłać dane, które wydają się pochodzić z urządzenia, a tak naprawdę nie jest. Chociaż nie jest jasne, jakie dane wysyłasz, wszelkie niezaufane dane mogą stanowić zagrożenie bezpieczeństwa.

Jakie bity muszę zachować prywatność?

Podczas tworzenia certyfikatu urządzenia w usłudze AWS IoT powinieneś zobaczyć taki obraz:

^{Obraz ze strony Utwórz i aktywuj certyfikat urządzenia w dokumentacji AWS IoT.}

Klucz prywatny jest rzeczą, którą naprawdę musisz zachować ... prywatność i zdecydowanie powinien być przechowywany w pamięci chronionej przed odczytem, ​​jeśli to możliwe. Klucz publiczny i certyfikat zostały zaprojektowane do współdzielenia, więc jeśli zabraknie Ci miejsca, możesz bezpiecznie przenieść je do pamięci zewnętrznej. Możesz uzyskać nieco więcej kontekstu na stronie Jak działa SSL / TLS? na giełdzie stosów informacji i kryptografii klucza publicznego na Wikipedii. Myślę, że zrobiłbym ci krzywdę, gdybym nie zamieścił tego obrazu, aby wyjaśnić, dlaczego klucz prywatny musi być tajny:

.

^{Zdjęcie z Wikipedii , udostępnione jako własność publiczna.}

Klucz publiczny urządzenia jest tym, czego używa AWS IoT do podpisywania wiadomości, aby wysłać je na urządzenie (ale nie dowodzi, kto wysyła wiadomość ). Tak naprawdę to nie jest wielka katastrofa, jeśli ktoś ukradnie klucz publiczny, ponieważ nie jest to tajemnica.

Klucz prywatny jest co twoi zastosowania urządzenia do odszyfrowania wiadomości, więc jest to nieco większy problem, jeśli atakujący kradnie to.

Zapytałeś także, co by się stało, gdyby atakujący ukradł certyfikat RootCA. Gdyby ktoś ukradł klucz prywatny AWS IoT , byłoby to katastrofalne, ale certyfikat RootCA na twoim urządzeniu nie jest taki . To, RootCA.crtco daje ci Amazon, jest całkowicie publiczne , a celem jest sprawdzenie, czy nie jesteś w żaden sposób atakowany (najprawdopodobniej człowiek pośrodku udający serwery AWS IoT).

Jakie szkody może zhakować urządzenie?

Twoje skradzione urządzenie może wykonywać tylko czynności wymienione w polisie . Staraj się przestrzegać zasady najmniejszych przywilejów ; tylko przyznać urządzenie przywilejów to absolutnie potrzebuje , więc jeśli najgorsze zdarza się, że nie mogą siać spustoszenie za dużo. W konkretnym przypadku:

Dozwolone jest publikowanie tylko na 2 kanałach (jego nazwa i kanał przesyłania danych), które są podłączone do procesora danych, który zignoruje wszelkie przychodzące do niego nieuczciwe pakiety.

Dobre. Każdy atak powinien być izolowany tylko na dwa tematy MQTT, na które urządzenie może publikować, aby nie spowodował szkody na dużą skalę.

Idealnie byłoby, gdyby cały system miał taką konstrukcję, że rozcięcie pojedynczej jednostki psuje tylko tę jednostkę, a nie cały system.

Zwłaszcza jeśli przechowujesz klucze w odrębnej pamięci, tak aby krzyżowały się one ze standardowym interfejsem elektrycznym między układami scalonymi, powinny to być tylko klucze, które można już bezpiecznie opublikować lub unikalne dla tej konkretnej fizycznej instancji urządzenia.

Jeśli pojedynczy klucz zostanie wyodrębniony z jednego urządzenia i zacznie być nadużywany lub pojawia się w ruchu, który musi pochodzić z wielu nieautoryzowanych klonów, możesz zablokować ten klucz po stronie serwera.

Twoje klucze powinny oczywiście mieć właściwość polegającą na tym, że nie są czymś, co nieupoważniona strona może odgadnąć na podstawie kilku wyodrębnionych przykładów lub wygenerować własne oryginalne kompatybilne instancje - tzn. Albo potrzebujesz zapisu kluczy, które wygenerowałeś tam, gdzie są prawidłowe tylko niewielka i nieprzewidywalna część ogromnej przestrzeni możliwości, w przeciwnym razie musisz podpisać wygenerowane klucze i sprawić, że system zaakceptuje tylko klucz w połączeniu z dowodem podpisu.

Powinieneś starać się zachować klucz klienta w tajemnicy (ale rozumiesz konsekwencje utraty go (1), jak opisano w innych odpowiedziach). Klucz publiczny serwera i certyfikat publiczny AWS są ważne do zabezpieczenia na końcu urządzenia nie dlatego, że chcesz zachować w tajemnicy, ale dlatego, że zastępując certyfikat AWS (na zainfekowanym urządzeniu), osoba atakująca może przekonać urządzenie do przeprowadzenia wymieniać się z hostem atakującego lub pośrednio komunikować się z AWS.

W ten sposób (2) osoba atakująca może usunąć zabezpieczenia TLS, co może skutkować wystarczającym zmniejszeniem bezpieczeństwa, aby móc dokonać inżynierii wstecznej klucza klienta.

Zgodnie z tym rozumowaniem jedynym kluczem, który można bezpiecznie ujawnić w zewnętrznej pamięci, jest klucz publiczny serwera. Zmiana tego (3) pozwoliłaby tylko zmusić twoje urządzenie do połączenia się z nieuczciwą usługą AWS, do której prawdopodobnie trudno jest uzyskać dostęp. Nawet wyciek tylko tego klucza może pozwolić komuś na węszenie lub sfałszowanie niektórych transmisji (na przykład jeśli warstwa TLS może zostać w jakiś sposób obniżona).

Podsumowując, ryzyko nie polega wyłącznie na wyciekaniu informacji, istnieje ryzyko, że (rzekomo zaufane) oprogramowanie wewnętrzne może zostać dostarczone z niezaufanymi bezpiecznymi informacjami.