Da der er mange kinesiske virksomheder, der let kan reverse engineering af printkortdesignet og udtrække .hex-filen ud af mikrokontrollerne (selv fra den sikre flash), skal indlejrede udviklere tilføje noget mere beskyttelse til deres produkter. I mit tilfælde bruger jeg en STM32F103, og jeg vil tilføje crypto IC ATSHA204A på min PCB for at beskytte min IP. Ved at gøre dette håber jeg selvom de kan få .hex ud af MCUen og klone tavlen, vil hex-filen nægte at arbejde, hvis den ikke kan genkende crypto-chip på printkortet.
Denne crypto IC har et unikt serienummer, der blev skrevet under fremstillingen, og den kan altid læses. Det har også nogle funktioner såsom et sikkert område til at holde nogle hemmelige data, evnen til at generere tilfældige tal og sende det til værten via I2C eller en-ledning, evnen til at beregne SHA-256 hash af en given streng og så videre. / p>
Nu prøver jeg at forstå, hvordan jeg skal arbejde med det, da jeg er en slags noob om godkendelsesemnet. Fra det, jeg har forstået ved læsning af databladet, vil arbejdsgangen være sådan:
Tilpasning af krypto IC:
-
Det sikre område i kryptoen chip udfyldes af værten (STM32F103 i mit tilfælde) med en tilfældig hemmelig nøgle for hvert produkt, kun en gang.
-
Den hemmelige nøgle vil også være til stede i værtsblinket hukommelse.
Autentificering af tavlen (min forståelse, hvilket sandsynligvis er forkert):
-
Værten anmoder om et tilfældigt tal fra krypto-IC. Derefter genererer værten en sammenkædet streng med den hemmelige nøgle og det tilfældige tal (nonce?), Og beregner SHA-256-hash af den.
-
Nu skal værten sende tilfældig nøgle tilbage til krypto-IC og forvent af den at generere den samme streng med den hemmelige nøgle inde i krypto-IC og beregne SHA-256 hash af den.
-
Crypto-IC sender den beregnede hash tilbage til værten, og værten sammenligner hashes.
-
Hvis hashes matcher, skal du validere. Hvis de ikke gør det, nægter værten at arbejde.
Workflowet er sandsynligvis forkert, men hovedideen burde være noget tæt på det. Kan nogen forklare dette?
Svar
Workflowet er sandsynligvis forkert, men hovedideen skal være noget tæt på det.
Nej, dette er dybest set ubrugeligt. Det ville være fint, hvis du f.eks. bruger din crypto IC til at validere ægtheden af en tilføjelsesenhed (f.eks. en printer, der bekræfter patronen, blev lavet af det samme firma).
Det hjælper ikke dig fordi " nægter at arbejde " vinder ikke, hvis nogen har din firmwares maskinkode: at finde afkrydsningsfeltet i den adskilte maskinkode er normalt ikke at hårdt. Derefter er det så meget som at erstatte en " hoppe til “stop og ikke gøre noget” " med en " spring til “start med nyttig funktionalitet “"; typisk involverer det ændring af en byte.
Du skal kryptere den interessante del af din firmware i den permanente opbevaring (typisk MCUs indbyggede flash). Kun en bootloader, der bruger crypto-chippen at dekryptere den vigtigste firmware ville forblive ukrypteret. Ved opstart dekrypterer bootloaderen firmwaren til RAM.
Lille problem der: Du skulle være temmelig klog, hardware-vis, så man ikke kunne vedhæft bare en logisk analysator mellem din MCU og krypto-ICen og sniff de dekrypterede bytes.
Der er løsninger, der tilslører ting ved vildt at hoppe rundt i hukommelsen, mens de dekrypterer ting osv. Problemet er, at der ikke er noget hemmeligt om det, er det bare lidt mere arbejde at forstå, hvordan man springer rundt fra maskinkode. (Og hvis du formår at indsætte et enkelt stykke maskinkode på den bus, der får MCU til at streame hele sit RAM via en eller anden pin, så er det også spillet over; det betyder ikke rigtig for dig, om du ved hvor det stykke kode ender i RAM, du finder det senere i dumpen, det er kun vigtigt, at det bliver udført på et eller andet tidspunkt.)
Med andre ord, hvis du virkelig tror, din firmware er det kommercielt interessant (folk overvurderer det vildt! For ting, der ikke hovedsagelig er firmware, såsom for omkring enhver forbrugerindretning og enhver industriel kontrol, er det normalt svært at finde alle dele og bygge samme / lignende enhed billigere end originalen, og fuldstændig omskrivning af firmwaren er ofte let sammenlignet med det), så er din eneste chance for at integrere hemmelig opbevaring, krypteret lager og sikker udførelse (så RAM-dumping er umulig).
Der er mikrokontrollere, der gør det. De er normalt lidt dyrere.Men som du kan gætte, hvis du f.eks. Er i et forsvarsmiljø, hvor du har brug for at certificere, kan firmwaren ikke manipuleres med, ja, det er din vej at gå.
Nintendo fremstiller enheder, hvor det økonomiske incitament til ikke at lade nogen læse deres firmware eller endda ændre det er stærkt:
Brugernes manglende evne til at køre software, der ikke blev licenseret af Nintendo på deres konsoller, er kritisk for deres forretningsmodel. At være ude af stand til at omgå kontrol af spilets underskrifter er derfor altafgørende, og det er derfor, at en Nintendo Switch går ud med flere lag af beskyttelse. Som du kan gætte, er det ingen garanti – der var simpelthen hobbyister (ikke engang mennesker med en kriminel / kommerciel interesse!) At fandt en måde omkring det.
Men du vil bemærke én ting: Bare fordi det er svært at gøre perfekt, betyder det ikke, at det ikke er værd at gøre det sværere at klone din enhed. I min ydmyge oplevelse kapitulerer typisk kloner så snart du har brug for forståelse af, hvordan en enhed fungerer for at kopiere den – ellers ville de være i stand til at have ingeniører, der kunne udføre dit arbejde mere eller mindre, og de ingeniører arbejder typisk i din sektor, ikke i noget forfalsket laboratorium. En god afskrækkende virkning er at sætte firmwaren krypteret i flash. Det er ikke perfekt, men i det øjeblik de skulle komme ud af logikanalysatoren og bruge uger på reverse engineering af din in-RAM-dekrypteringsprotokol, bare for at få noget, som de måske kan kopiere, kunne være nok til, at de anser den økonomiske risiko for høj og går efter noget noget andet.
Kommentarer
- " mennesker overvurderer vildt at ", men folk overvurderer lige så vildt omkostningerne ved reverse engineering.
- Tak for det gode svar, kan ikke opvote for ikke at have nok omdømme. Ja det er ' dybest set umuligt at gøre det 100% sikkert, men tilføjelse af en meget enkel sikkerhedsforanstaltning med en $ 0,3 crypto-chip kan øge omkostningerne ved reverse engineering fra nogle 3-cifrede $ til måske 5-cifret, samtidig med at den krævede tid øges fra et par dage til et par måneder, hvis sikkerheden er designet smart nok. Og det kunne frastøde hackerne (afhængigt af produktets økonomiske potentiale) Jeg tror, jeg vil komme videre ved at kryptere " interessant del " af den vigtigste firmware.
- I ' Skal dit estimat ned til " stigende tid fra en time til måske et par dage ", og omkostningerne er dybest set irrelevante i begge tilfælde. Omkostningerne ville være " i det væsentlige gratis " for alle, der ' har de elektroniske værktøjer liggende rundt alligevel, og selvom ikke, giver 200 € plus en bærbar computer dig en rimelig start.
- Så skal jeg give op og slet ikke bruge nogen beskyttelse? 🙂
- @NotReallyaMaster at ' er op til dig; Jeg ' har dedikeret hele det sidste afsnit af mit svar på det spørgsmål.