Eftersom det finns många kinesiska företag som enkelt kan omvandla PCB-designen och extrahera .hex-filen ur mikrokontrollerna (även från den säkra flashen), måste inbäddade utvecklare lägga lite mer skydd till sina produkter. I mitt fall använder jag en STM32F103 och jag vill lägga till krypto IC ATSHA204A på min PCB för att skydda min IP. Genom att göra detta hoppas jag även om de kan få ut .hex ur MCU och klona kortet, kommer hex-filen att vägra att fungera om den inte kan känna igen kryptokrets på kretskortet.
Denna krypto-IC har ett unikt serienummer som skrevs medan den tillverkades, och den kan alltid läsas. Det har också vissa funktioner som ett säkert område för att hålla hemlig data, förmåga att generera slumptal och skicka det till värden via I2C eller en tråd, förmåga att beräkna SHA-256 hash av någon given sträng och så vidare. / p>
Nu försöker jag förstå hur jag ska arbeta med det eftersom jag är en slags noob om autentiseringsämnet. Från vad jag har förstått från att läsa databladet kommer arbetsflödet att vara så här:
Anpassning av crypto IC:
-
Det säkra området i crypto chipet kommer att fyllas av värden (STM32F103 i mitt fall) med någon slumpmässig hemlig nyckel för varje produkt, bara en gång.
-
Den hemliga nyckeln kommer också att finnas i värdens blixt minne.
Autentisering av tavlan (Min förståelse, vilket förmodligen är fel):
-
Värden begär ett slumptal från krypto-IC. Sedan genererar värden en sammanhängande sträng med den hemliga nyckeln och slumptalet (nonce?) Och beräknar SHA-256-hash av den.
-
Nu ska värden skicka slumpmässig nyckel tillbaka till krypto-IC och förvänta dig att den genererar samma sträng med den hemliga nyckeln inuti krypto-IC och beräknar SHA-256-hash av den.
-
Crypto-IC skickar den beräknade hashen tillbaka till värden och värden jämför hasharna.
-
Om hasharna matchar, validera. Om de inte gör det vägrar värden att arbeta.
Arbetsflödet är förmodligen fel, men huvudidén borde vara något nära det. Kan någon förklara detta?
Svar
Arbetsflödet är förmodligen fel, men huvudidén borde vara något nära det.
Nej, det här är i princip värdelöst. Det skulle vara bra om du t.ex. skulle använda din krypto-IC för att validera äktheten av en tilläggsenhet (säg, en skrivare som verifierar patronen gjordes av samma företag).
Det hjälper inte dig eftersom " vägrar att arbeta " kommer inte att flyga om någon har din firmware maskinkod: att hitta kontrollen i den demonterade maskinkoden är vanligtvis inte att hårt. Då är det lika mycket som att ersätta en " hoppa till ”stopp och gör ingenting” " med en " hoppa till ”start med användbar funktionalitet ”"; det innebär vanligtvis att byta byte.
Du måste kryptera den intressanta delen av din firmware i den permanenta lagringen (vanligtvis MCU: s inbyggda blixt). Endast en bootloader som använder kryptokretsen för att dekryptera huvud firmware skulle förbli okrypterad. Vid start dekrypterar bootloader firmware till RAM.
Litet problem där: Du skulle behöva vara ganska smart, hårdvarumässigt så att man inte kunde ”t bifoga bara en logisk analysator mellan din MCU och krypto-IC: n och sniffa de dekrypterade byten. hemligt om det, det är bara lite mer arbete att förstå hur man hoppar runt från maskinkod. (Och om du lyckas sätta in en enda maskinkod på den bussen som får MCU att strömma ut hela RAM-minnet via någon stift, så är det också över, det spelar ingen roll för dig om du vet var den kodkoden hamnar i RAM, du hittar den senare i dumpningen, det är bara viktigt att den körs någon gång.)
Med andra ord, om du verkligen tror att din firmware är det kommersiellt intressant (människor överskattar det väldigt mycket! För saker som inte är främst firmware, som till exempel för alla konsumentenheter och någon industriell kontroll, är det vanligtvis svårt att hitta alla delar och bygga samma / liknande enhet billigare än originalet, och det är ofta enkelt att skriva om firmware helt enkelt jämfört med det), då är din enda chans att integrera hemlig förvaring, krypterad lagring och säker körning (så att RAM-dumpning är omöjligt).
Det finns mikrokontroller som gör det. De är vanligtvis lite dyrare.Men som du kan gissa, om du till exempel befinner dig i en försvarsmiljö där du behöver certifiera, kan inte firmware manipuleras, det är din väg att gå.
Nintendo tillverkar enheter där det ekonomiska incitamentet att inte låta någon läsa sin firmware eller till och med modifiera den är stark:
Användarnas oförmåga att köra programvara som inte licensierades av Nintendo på sina konsoler är avgörande för deras affärsmodell. Därför är det avgörande att inte kunna kringgå kontrollen av spelets signaturer, och det är därför en Nintendo Switch går ut med flera lager av skydd. Som du kan gissa, är det ingen garanti – det fanns helt enkelt hobbyister (inte ens personer med ett kriminellt / kommersiellt intresse!) Att hittade ett sätt kring det.
Men du kommer att märka en sak: Bara för att det är svårt att göra perfekt betyder det inte att det inte är värt att göra det svårare att klona din enhet. Enligt min ödmjuka upplevelse kapitulerar vanligtvis kloner så snart du behöver förståelse för hur en enhet fungerar för att kopiera den – annars skulle de ha möjlighet att ha ingenjörer som kan göra ditt arbete mer eller mindre, och dessa ingenjörer arbetar vanligtvis inom din sektor, inte i något förfalskat laboratorium. En bra avskräckande följaktligen är att sätta firmware krypterad i flash. Det är inte perfekt, men i det ögonblick de skulle behöva ta ut logikanalysatorn och spendera veckor på in-RAM-dekrypteringsprotokoll, bara för att få något som de kanske kan kopiera, kan räcka för att de anser att den ekonomiska risken är för hög och går för lite annat.
Kommentarer
- " människor överskattar vilt att ", men människor överskattar lika vilt kostnaden för reverse engineering.
- Tack för det fantastiska svaret, kan inte rösta för att de inte har tillräckligt med rykte. Ja det ' är i princip omöjligt att göra det 100% säkert, men att lägga till en mycket enkel säkerhetsåtgärd med ett $ 0,3-kryptokort kan öka kostnaden för omvänd teknik från några tre siffror $ till kanske 5-siffror, samtidigt som man ökar den erforderliga tiden från några dagar till några månader om säkerheten är tillräckligt smart. Och det kan avvisa hackarna (beroende på produktens ekonomiska potential) Jag tror att jag kommer att gå vidare genom att kryptera " intressant del " av den huvudsakliga firmware.
- I ' Skalar din uppskattning ner till " ökar tiden från en timme till kanske några dagar ", och kostnaden är i princip irrelevant i båda fallen. Kostnaden skulle vara " väsentligen fri " för alla som ' har de elektroniska verktygen liggande runt ändå, och även om inte, 200 € plus en bärbar dator ger dig en rimlig start.
- Då ska jag ge upp och inte använda något skydd alls? 🙂
- @NotReallyaMaster som ' är upp till dig; Jag ' har tillägnat hela det sista stycket i mitt svar på den frågan.