ESP32 Ota "beveiligen"

Ik gebruik OTA op mijn ESP32's die via mijn server het juiste .BIN bestand downloaden en uitpakken.
Nu wil ik dit graag "beveiligen" zodat ik zeker weet dat er een .BIN file wordt gedownload vanuit mijn server.

Nu las ik hier laatst dat je bepaalde gegevens in een .BIN bestand kunt toevoegen en dat voordat je de .BIN file uitpakt kunt "uitlezen".

Hoe kan ik dit het beste doen?
Het mooiste zou zijn als ik via Platformio bijvoorbeeld enkele "flags" kon toevoegen (met een eigen code of text) die ik voordat het uitgepakt wordt kan controleren.

Hoe gaat zoiets in z'n werk? Kan zo snel niets vinden op google

Een .bin file is een gewoon file net als elk ander file.
Op de zaak deden we daar een stukje certifikaat achteraanplakken, gewoon door naar het bestand te schrijven in append mode. Je kunt schrijven wat je wilt zolang je de rest van het bestand maar ongewijzigd laat.

Op de ESP kun je dat dan weer controleren : Bestand open en laatste x bytes lezen.

PS:
Dat kan ook op de command-line met redirect.
Iets als 

 echo "goedgekeurd bBuster" >> ESP-app.bin

Let wel op de dubbele >> tekens. Die voegen toe aan het eind van de file.

[Bericht gewijzigd door deKees op (22%)]

Ik weet niet in hoeverre jij "standaard library" dingen gebruikt om die OTA update te doen. Als dat iets is van: "nieuwe binary staat op die-en-die URL" en dan gaat alles verder vanzelf, dan is het misschien wat tricky om het goed te krijgen.

In theorie zou je bijvoorbeeld de eerste 4k tot "header" moeten maken. Daarin kan je vanalles zetten als: "dit is versie XYZ" en "geschikt voor hardware bbuster-23". Die kan je dan al-dan-niet controleren. Maar iedereen kan daar zomaar inzetten wat ie wil. Om het ECHT veilig te krijgen moet je iets doen als een digitale handtekening over "de rest van de binary" toevoegen. De private key hou jij voor je, de hardware "in het veld" weet de public key. Die controleert de handtekening en gebruikt de nieuwe firmware alleen als die klopt.

Maar om dit helemaal veilig te krijgen moet je dus eigenlijk de hele binary downloaden, checksummen en handtekening controleren voordat je hem programmeert en in flash zet. En je wilt dus niet bijvoorbeeld hem twee keer downloaden, 1x om te checksummen en 1x om echt te programmeren. Dan loop je het risico dat iemand een man-in-the-middle aanval doet met eerst de normale laten downloaden en zodra de checksum geverifieerd is een andere er voor in de plaats zetten.

Als iets simpler alternatief kan je het website HTTPS certificaat goed controleren.

Anderzijds, als je dat kan, dan heb je de digitale-handtekeningen-library toch al in je flash staan....

@dekees: Dan beveilig je dus tegen "foutjes" met een onjuist bin bestand. Zoals in die andere thread met de foute bin op de SD kaart. Maar niet tegen een kwaadwillende hacker die een hexdump van je update-file bekijkt, daar dan "stuur de wachtwoorden naar hacking.com" aan toevoegt en dan gewoon de "goedgekeurd door bbuster" weer er achter zet....

[Bericht gewijzigd door rew op (11%)]

Volgens mij geeft rew het beste antwoord: via https downloaden.

Je kan allerlei grapjes op bestandsniveau bedenken, maar TLS (https) is goed uitgedacht, je kan met officiele certificaten werken (Let's Encrypt, DigiCert, Globalsign) en je hoeft eigenlijk nergens over na te denken. Je kan ook PKCS7 pakketten maken, dat is de manier die openssl gebruikt om een bestand te voorzien van certificaat zodat je dat weer kan controleren.

Klopt wel, de vraag is alleen "hoe ver moet je gaan".

Zo een ESP32 is voor een hacker meestal niet interessant genoeg om daar drastische maatregelen voor moeten te nemen. En alle security heeft zijn prijs. Dan wordt het voor de rechtmatige host ook veel ingewikkelder. Die sleutels moet je beheren, en als ze verlopen op tijd updaten, enz

En https is op zich wel een goed advies, maar het is mij nog niet gelukt om dat betrouwbaar aan de praat te krijgen op een ESP32. Het is er wel, en het werkt ook wel een beetje, maar geeft toch te vaak connectie problemen.

Is er geen mogelijkheid om met een ota password te werken?
Zelf gebruik ik ESP's icm met HA en ESPhome, en daar kun je in de config een password aan maken.

de ESP32 ondersteund redelijk standard al secure boot en firmware encryption.
Daarmee boeit het volgens mij al niet meer zoveel van welke server de firmware komt.
Een firmware die niet aan jouw signature voldoet boot gewoon niet, als dat is wat je wil.

Op 19 december 2023 21:52:49 schreef deKees:
Klopt wel, de vraag is alleen "hoe ver moet je gaan".

Zo een ESP32 is voor een hacker meestal niet interessant genoeg om daar drastische maatregelen voor moeten te nemen. En alle security heeft zijn prijs. Dan wordt het voor de rechtmatige host ook veel ingewikkelder. Die sleutels moet je beheren, en als ze verlopen op tijd updaten, enz

En https is op zich wel een goed advies, maar het is mij nog niet gelukt om dat betrouwbaar aan de praat te krijgen op een ESP32. Het is er wel, en het werkt ook wel een beetje, maar geeft toch te vaak connectie problemen.

Over het algemeen moet je ook niet vrezen voor een hacker die in een kelder jouw IP adressen zit te scannen, maar malware die om wat voor reden op je netwerk terecht komt en een bibliotheek van 9999 manieren heeft om andere apparaten te besmetten, waaronder misschien (ooit) OTA.

TLS kent heel veel encryptiemethodes en certificaten hebben ook weer heel veel verschillende algorithmen. Het kan best dat zo'n ESP nog niet lekker overweg kan met TLS1.3, Elliptic Curve of > SHA384 certificaten.

Bedankt voor alle reacties.
Ik gebruik deze library: https://github.com/JAndrassy/ArduinoOTA/blob/master/src/InternalStorag…

Zodra ik via mijn server aangeef dat er een update gereedstaat stuur ik via MQTT (of de esp zoekt zelf via http) de nieuwste versie op. Stel dat dat 1.0.2 is, dan download de esp32 via www.mijnwebsite.com/updates/1_0_2.bin het bestand en gaat het uitpakken.

In principe kan iemand dus op (iig windows) zijn hosts bestandje aanpassen dat www.website.nl naar zijn eigen server gaat en zo een ander bin bestand downloaden.

Een mega probleem is het niet, alleen zou ik het liever niet hebben.

Ik wil het het liefst "hardcoded" programmeren zodat ik geen problemen krijg met verlopen certificaten etc en een update niet meer kan downloaden.

Als ik het inderdaad ww kan beveiligen, of iet kan uitlezen voordat het gedownload wordt of het "mijn" bestand is zou dat het mooiste zijn. Uiteraard zou het niet gemakkelijk te "hacken" moeten zijn maar ik denk niet dat ik het 100% kan voorkomen.

@Stijnos: Heb je hier meer info over?

Kun je dan geen vertrouwde ip adressen geven?
In Vlan?
Afschermen van internet?

Hier zitten alle ESP's in eigen IoT vlan, geen toegang tot internet

Ze hangen bij klanten dus moeten verbinding hebben met internet.
En een hele tijd geleden gebruikte ik Raspberry Pi's die verbinding maakten met het IP adres van mijn server.

Tot ik op een dag bericht kreeg van de hostingpartij dat er brand was geweest en mijn servers niet meer bereikbaar waren. Bij het opnieuw inrichten kreeg ik nieuwe IP adressen (nog steeds geen idee waarom dat was, maar ben er iig geen klant meer).

Alle modules werkten niet meer en konden ook niet meer geüpdatet worden omdat het IP niet bereikbaar was. Dat wil ik niet nog een keer meemaken.

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/s…

Voorkomen dat iedereen de bestanden kan downloaden kan ook, maar...
Dat maakt het best wat ingewikkelder, althans om het goed te doen.

Als je dat toch wilt, zou je minio kunnen draaien. Je kunt dan vanaf je automatisering een link maken die bijvoorbeeld tijdelijk beschikbaar is. En die link dan via mqtt naar je devices sturen.

Deze link gaat over uploaden, maar hetzelfde kan voor downloaden.
- https://min.io/docs/minio/linux/integrations/presigned-put-upload-via-…

Wil je het echt profi aanpakken:
- https://min.io/docs/minio/linux/operations/external-iam/configure-open…

Ik ga het niet allemaal uitleggen, dat gaat ver buiten de scope van dit forum. Maar er is zat info te vinden online.