Aangezien er veel Chinese bedrijven zijn die het PCB-ontwerp gemakkelijk kunnen reverse-engineeren en het .hex-bestand uit de microcontrollers kunnen extraheren (zelfs van de veilige flitser), moeten embedded ontwikkelaars wat meer bescherming aan hun producten toevoegen. In mijn geval “gebruik ik een STM32F103 en wil ik de crypto-IC ATSHA204A op mijn PCB toevoegen om mijn IP te beschermen. Door dit te doen, hoop ik zelfs als ze de .hex uit de MCU kunnen halen en het bord kunnen klonen, zal het hex-bestand weigeren te werken als het de crypto-chip op de PCB niet kan herkennen.
Deze crypto-IC heeft een uniek serienummer dat werd tijdens de fabricage geschreven en kan altijd worden gelezen. Het heeft ook enkele functies, zoals een beveiligd gebied om enkele geheime gegevens te bewaren, de mogelijkheid om willekeurige getallen te genereren en deze naar de host te sturen via I2C of enkeldraads, de mogelijkheid om SHA-256-hash van een bepaalde string te berekenen, enzovoort. / p>
Nu probeer ik te begrijpen hoe ik ermee zou moeten werken, aangezien ik een beetje een noob ben op het gebied van authenticatie. Van wat ik heb begrepen door het lezen van de datasheet, is de workflow als volgt:
Personalisatie van de crypto-IC:
-
Het beveiligde gebied in de crypto chip zal worden gevuld door de host (STM32F103 in mijn geval) met een willekeurige geheime sleutel voor elk product, maar één keer.
-
De geheime sleutel zal ook aanwezig zijn in de hosts-flash geheugen.
Authenticatie van het bord (ik begrijp het, wat waarschijnlijk verkeerd is):
-
De host vraagt om een willekeurig nummer van de crypto-IC. Vervolgens genereert de host een aaneengeschakelde string met de geheime sleutel en het willekeurige nummer (nonce?), En berekent de SHA-256-hash ervan.
-
Nu moet de host de willekeurige sleutel terug naar de crypto-IC en verwacht dat deze dezelfde string genereert met de geheime sleutel in de crypto-IC en de SHA-256-hash ervan berekent.
-
Crypto-IC stuurt de berekende hash terug naar de host en de host vergelijkt de hashes.
-
Als de hashes overeenkomen, valideer je. Als ze dat niet doen, weigert de host te werken.
De workflow is waarschijnlijk verkeerd, maar het belangrijkste idee zou iets moeten zijn dat er dicht bij ligt. Kan iemand dit uitleggen?
Antwoord
De workflow is waarschijnlijk verkeerd, maar het belangrijkste idee zou moeten zijn iets in de buurt.
Nee, dit is in wezen nutteloos. Dit zou prima zijn als je je crypto-IC bijvoorbeeld zou gebruiken om de authenticiteit van een extra apparaat (bijvoorbeeld een printer die verifieert dat de cartridge door hetzelfde bedrijf is gemaakt).
Het helpt u niet, omdat " weigert te werken " vliegt niet als iemand de machinecode van uw firmware heeft: het vinden van de cheque in de gedemonteerde machinecode is meestal niet dat moeilijk. Dan is het net zo goed als het vervangen van een " sprong naar “stoppen en niets doen” " door een " spring naar “start nuttige functionaliteit “"; meestal moet een byte worden gewijzigd.
Je moet het interessante deel van je firmware in de permanente opslag versleutelen (meestal de ingebouwde flash van de MCU). Alleen een bootloader die de crypto-chip gebruikt om de hoofdfirmware te decoderen blijft ongecodeerd. Bij het opstarten decodeert de bootloader de firmware naar het RAM.
Klein probleem daar: je zou behoorlijk slim moeten zijn, hardware-gewijs, zodat je niet sluit gewoon een logic analyzer aan tussen je MCU en de crypto-IC en snuif de gedecodeerde bytes op.
Er zijn tijdelijke oplossingen die dingen verdoezelen door wild in het geheugen rond te springen tijdens het decoderen van dingen enz. Het probleem is dat er niets is geheim daarover, is het gewoon wat meer werk om te begrijpen hoe het rondspringen wordt gedaan vanuit machinecode. (En als het je lukt om een enkel stuk machinecode op die bus in te voegen waardoor de MCU zijn volledige RAM via een of andere pin naar buiten streamt, dan is het ook game over; het maakt niet echt uit of je weet waar dat stukje code komt in RAM terecht, je vindt het later in de dump, het is alleen belangrijk dat het op een gegeven moment wordt uitgevoerd.)
Met andere woorden, als je echt denkt dat je firmware is dat commercieel interessant (mensen overschatten dat enorm! Voor dingen die niet voornamelijk firmware zijn, zoals voor vrijwel elk consumentenapparaat en elke industriële besturing, is het meestal moeilijk om alle onderdelen te vinden en de hetzelfde / soortgelijk apparaat goedkoper dan het origineel, en het volledig herschrijven van de firmware is in vergelijking daarmee vaak eenvoudig), dan is uw enige kans om geheimhouding, gecodeerde opslag en veilige uitvoering te integreren (zodat RAM-dumping onmogelijk is).
Er zijn microcontrollers die dat doen. Ze zijn meestal wat duurder.Maar zoals u wel kunt raden, als u zich bijvoorbeeld in een defensieomgeving bevindt waar u moet certificeren dat er niet met de firmware kan worden geknoeid, dan is dat uw juiste keuze.
Nintendo maakt apparaten waarvan de financiële prikkel om niemand hun firmware te laten lezen of zelfs wijzigen sterk is:
Het onvermogen van gebruikers om software op hun consoles uit te voeren waarvoor geen licentie is verleend door Nintendo, is cruciaal voor hun bedrijfsmodel. Daarom is het van het grootste belang dat je het controleren van de handtekeningen van games niet kunt omzeilen, en daarom gaat een Nintendo Switch alles uit de kast met meerdere beschermingslagen. Zoals je kunt raden, is dat geen garantie – er waren gewoon hobbyisten (zelfs niet mensen met een crimineel / commercieel belang!) Die een manier vonden om dat te omzeilen.
Maar je zult één ding opmerken: alleen omdat het moeilijk is om perfect te maken, wil nog niet zeggen dat het het niet waard is om het moeilijker te maken om je apparaat te klonen. In mijn bescheiden ervaring capituleren kloners meestal zodra u moet weten hoe een apparaat werkt om het te kopiëren, anders zouden ze in de positie verkeren dat er ingenieurs zijn die uw werk min of meer zouden kunnen doen, en die ingenieurs werken meestal in uw sector, niet in een vervalsingslaboratorium. Een goed afschrikmiddel is daarom de firmware versleuteld in flash plaatsen. Het is niet perfect, maar op het moment dat ze de logic analyzer eruit moeten halen en weken moeten besteden aan reverse-engineering van uw in-RAM-decoderingsprotocol, alleen om iets te krijgen dat ze misschien zouden kunnen kopiëren, zou voldoende kunnen zijn dat ze het financiële risico te hoog vinden en voor wat iets anders.
Reacties
- " mensen overschatten dat ", maar mensen overschatten net zo goed de kosten van reverse-engineering.
- Bedankt voor het geweldige antwoord, ik kan niet stemmen omdat ik niet genoeg reputatie heb. Ja, het ' is in principe onmogelijk om het 100% veilig te maken, maar het toevoegen van een zeer eenvoudige beveiligingsmaatregel met een $ 0,3 crypto-chip kan de kosten van reverse engineering verhogen van ongeveer $ 3 naar misschien 5 cijfers, terwijl de vereiste tijd wordt verhoogd van een paar dagen naar een paar maanden als de beveiliging slim genoeg is ontworpen. En het zou de hackers kunnen afstoten (afhankelijk van het financiële potentieel van het product). Ik denk dat ik verder ga door het " interessante deel " van de hoofdfirmware.
- Ik ' schaal uw schatting omlaag naar " waarbij de tijd wordt vergroot van een uur naar misschien een paar dagen ", en de kosten zijn in beide gevallen in wezen irrelevant. De kosten zijn " in wezen gratis " voor iedereen die ' de elektronische tools heeft laten liegen hoe dan ook, en zelfs als dat niet het geval is, geeft 200 € plus een laptop je een redelijke start.
- Moet ik dan opgeven en helemaal geen bescherming gebruiken? 🙂
- @NotReallyaMaster die ' is aan jou; Ik ' heb de hele laatste alinea van mijn antwoord aan die vraag gewijd.