Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

ESP: Luki bezpieczeństwa i bugi

03 Gru 2019 09:05 150 8
  • Moderator Mikrokontrolery Projektowanie
    Tak można to rozumieć, co spowoduje problem z podmianą oprogramowania w celu wyeliminowania innych luk bezpieczeństwa. Chyba zapędzili się w kozi róg tym bardziej, że sprzedali już ponad 100mln sztuk (dane ze stycznia 2018).
  • Poziom 35  
    mipix napisał:
    niektóre przyszłe produkty z tym kontrolerem będą miały zablokowaną możliwość zmiany oprogramowania.

    O ile producenci tych produktów z ESP32 będą sobie tego życzyli.

    dondu napisał:
    Tak można to rozumieć, co spowoduje problem z podmianą oprogramowania w celu wyeliminowania innych luk bezpieczeństwa. Chyba zapędzili się w kozi róg tym bardzie

    Proponuję zapoznać się z aktualną dokumentacją eFuse dla ESP32:
    https://www.espressif.com/sites/default/files...ation/esp32_technical_reference_manual_en.pdf (rozdział 20), oraz
    https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/efuse.html
  • Moderator Mikrokontrolery Projektowanie
    khoam napisał:
    dondu napisał:
    Tak można to rozumieć, co spowoduje problem z podmianą oprogramowania w celu wyeliminowania innych luk bezpieczeństwa. Chyba zapędzili się w kozi róg tym bardzie

    Proponuję zapoznać się z aktualną dokumentacją eFuse dla ESP32:
    https://www.espressif.com/sites/default/files...ation/esp32_technical_reference_manual_en.pdf (rozdział 20), oraz
    https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/efuse.html


    Czytałem tylko artykuł wskazany w pierwszym poście a w nim:

    Cytat:
    The attack works against eFuse, a one-time programmable memory where data can be burned to the device. The ESP32 official documentation describes why the attack works: "Each eFuse is a one-bit field which can be programmed to 1 after which it cannot be reverted back to 0." By burning a payload into the device’s eFuse, no software update can ever reset the fuse and the chip must be physically replaced or the device discarded.


    Nie jestem specjalistą ESP32, więc wytłumacz proszę.
  • Poziom 35  
    dondu napisał:
    Czytałem tylko artykuł wskazany w pierwszym poście a w nim:

    No właśnie, ale już nie znalazła się tam informacja, że wymaga to bezpośredniego fizycznego dostępu do MCU w danym urządzeniu oraz wymaga "pewnych" przeróbek w samym pcb i w niektórych przypadkach otwarcia metalowej obudowy ESP32, jeśli jest - nie mam tu na myśli prostych i tanich płytek deweloperskich z AliExpress, na których wykonano testy "penetracyjne", bo to było prostsze.

    Ponadto rekomendacje Espressif były i są jasno sprecyzowane w odniesieniu do zabezpieczeń ESP32 (o ile ktoś ich potrzebuje, rozumie i używa):
    • Use per-device unique keys for Secure Boot and Flash Encryption.
    • Generate per-device unique keys stored in flash for application uses, rather than using a single shared key across all devices.


    Zastosowanie się do powyższych zasad gwarantuje, że "złamanie" jednego ESP32 w jednym egzemplarzu danego urządzenia, nie będzie skutkowało "złamaniem" zabezpieczeń we wszystkich innych ESP32 w tych samych urządzeniach tzn. z tym samym firmware. Mądry posłucha, a głupi "zaoszczędzi".

    Tak wygląda jeden z etapów "hackowania" po zdjęciu metalowej obudowy ESP32:

    ESP: Luki bezpieczeństwa i bugi
  • Moderator Mikrokontrolery Projektowanie
    Czy dobrze zrozumiałem, że przeciętny użytkownik ESP32 programowanego np. w środowisku Arduino nie wykorzystuje zalecanych zabezpieczeń i jest przez to podatny na atak bez konieczności fizycznego dostępu do układu?
  • Poziom 35  
    dondu napisał:
    Czy dobrze zrozumiałem, że przeciętny użytkownik ESP32 programowanego np. w środowisku Arduino nie wykorzystuje zalecanych zabezpieczeń i jest przez to podatny na atak bez konieczności fizycznego dostępu do układu?

    Nie, atak można wykonać mając fizyczny dostęp do układu - w zacytowanym przez Ciebie artykule w pierwszym poście jest napisane:
    "A security researcher has identified a local-access technique"

    Nie wiem, kto to jest "przeciętny użytkownik ESP32 programowanego np. w środowisku Arduino", sam dopiero raczkuję. Znajomość Arduino HAL, czy też jego brak nie ma znaczenia. Arduino HAL w ESP32 w całości oparty jest na ESP-IDF. Potrzebna jest więc znajomość architektury ESP32 oraz ESP-IDF. Nie też ma znaczenia, czy ktoś tworzy oprogramowanie w Arduino IDE, VSC, Eclipse czy w każdym innym IDE.