Secure Boot

Nesten alle embedded systemer krevet et nivå av sikkerhet som sikrer at enheten ikke kan bli kompromittert eller tuklet med. Secure boot representerer den første barrieren i en hvilken som helst lagdelt sikkerhetstilnærming, og sikrer at boot-up prosessen er beskyttet mot skadevare ved å tillate at bare legitime og klarerte programvarer får kjøre på systemet før operativsystemet (eller hoved-applikasjonen) starter opp. For å forhindre at skadevare får tilgang til systemet, avhenger secure boot av en såkalt Chain-of-Trust (CoT) – En metode hvor hver enkelt boot program er påkrevd å verifisere en digital signatur av den neste programvaren mot kjente og pålitelige nøkler før den gir fra seg kontrollen. 

Hvis et problem detekteres under boot prosessen vil bootloaderen stoppe systemet fra å fortsette videre til neste steg. I stedet kan den starte opp en gjenopprettingsprosess for å gjenopprette enheten til en sikker tilstand. Gjenopprettingsmekanismene kan for eksempel basere seg på å laste inn en eldre versjon av programvaren som tidligere har vist seg å fungere, eller så kan prosessen legge til rette for at ny programvare kan lastes inn på nytt gjennom en lokal eller ekstern tilkobling. 

For at secure boot CoT skal være pålitelig, må CoT være forbundet til en uforanderlig Root-of-Trust (RoT) lagret i hardware. Dette vil typisk (men ikke utelukkende) inkludere: 

• En primær bootloader som støtter secure boot 
• Støtte for hardware-akselerert kryptografiske operasjoner 
• Kritiske konfigurasjonsdata 
• Et trygt sted å lagre kjente og pålitelige nøkler 

Boot ROM (primær bootloader) skal helst støtte secure boot siden den allerede er uforanderlig og må derfor implisitt bli ansett som en pålitelig software-komponent. Vær oppmerksom på at Boot ROM, slik som all annen kode, kan inneholde svakheter som kan påvirke secure boot prosessen, og det er derfor anbefalt å gjøre seg kjent med hvorvidt prosessoren har ulike kjente feil og sikkerhetshull. Dersom Boot ROM ikke implementerer secure boot kan det i noen tilfeller (f.eks. mikrokontrollere) være mulig å utvide Boot ROM med en skrivebeskyttet bootloader i intern flash som implementerer dette. 

Kritiske konfigurasjonsdata inkluderer innstillinger som kan endre eller påvirke bootprosessen, slik som hvilket boot medium (f.eks. eMMC) enheten skal laste inn programvare fra, og i hvilken rekkefølge dersom flere kilder er tilgjengelig, hvorvidt debug porter og/eller secure boot er aktivert med mer. Her lønner det seg å gjøre seg ekstra godt kjent med prosessorens (sikkerhets)datablad for å få oversikt over hvilke konfigurasjoner som er kritiske for boot prosessen. 

De kjente og pålitelige nøklene er essensielle for å sikre at bare legitim programvare får kjøre under boot prosessen. Hvorvidt om nøklene er et sett av X509 sertifikater eller nøkler i råformat, avhenger av prosessorens evner. Sistnevnte format er mer realistisk på mikrokontrollere der kryptografiske operasjoner relatert til Public Key Infrastructure (PKI) som oftest ikke er tilgjengelig. Selv om de pålitelige nøklene, i kryptografisk forstand, ikke er ansett som hemmelig, så er det veldig viktig at nøklene ikke kan bli erstattet eller tuklet med av en motpart. Normalt sett blir slike nøkler installert av Original Equipment Manufacturer (OEM) i one-time programmable (OTP) minne, f.eks. i prosessorens innebygde eFuse, under produksjon av enheten for å sikre at de ikke kan bli modifisert på et senere tidspunkt. 

Digitale signaturer bruker Public Key Cryptography, et kryptografisk system som bruker matematisk forbunnede nøkkelpar, for å lage en elektronisk analog av en skriftlig signatur. Hvert nøkkelpar består av en privat nøkkel og en korresponderende offentlig nøkkel. For tiden godkjenner “Digital Signature Standard FIPS 186-5” [7] både RSA, ECDSA og EdDSA signaturalgoritmer, hvorpå de to førstnevnte er mest vanlig å finne i dagens utvalg av embeddedprosessorer. Vær oppmerksom på at algoritmene har domene-parametere som avgjør styrken på signatur-algoritmen (se [8] for mer informasjon), og at prosessoren kan sette begrensninger for hvilke algoritmer og styrker som støttes. 

Secure boot utnytter digitale signaturer for å gi følgende sikkerhetstjenester [7]: 

• Data integritet 
• Autentisering av opphav 
• Ikke-avvisning (non-repudiation) 

Data integritet er en egenskap der data ikke har blitt modifisert fra det tidspunktet dataen ble generert, overført og lagret. Digitale signaturer avhenger av en Secure Hash Algorithm (SHA) for å sikre at dataen er i tilstand av integritet. SHA’er transformerer data til et unikt digitalt fingeravtrykk med fast lengde som er beregningsmessig umulig å forfalske og erstatte. Dette gjør at secure boot kan oppdage korrupt data som er forårsaket av både tilfeldige feil, men også feil som er gjort med hensikt. 

Autentisering av opphav gir en forsikring om at dataen kommer fra en legitim kilde (eieren av privat-nøkkelen). Når en digital signatur blir generert vil den originale dataen først bli hashet ved bruk av en Secure Hash Algoritme (f.eks. SHA256), for deretter å bli kryptert med den private nøkkelen. Resultatet er en digital signatur som kan legges til den originale dataen (f.eks. programvaren) som et bevis på at dataen er godkjent av underskriveren. For å verifisere den digitale signaturen, blir signaturen først dekryptert med den korresponderende offentlige nøkkelen. Deretter vil den som verifiserer kalkulere sin egen hashverdi av den originale dataen for så å sammenlikne den med den dekrypterte signaturen. Dersom hashverdiene samsvarer med hverandre, så kan den som verifiserer signaturen være forsikret om at dataen ikke er blitt modifisert i tillegg til at den kommer fra en pålitelig kilde. 

Ikke-avvisning (Non-repudiation på engelsk), i kryptografisk sammenheng, sikrer at den som er eieren av privat-nøkkelen ikke kan benekte å ha signert dataen samtidig som eieren påstår at privat-nøkkelen ikke er blitt kompromittert. Det er kritisk at privat-nøkkelen holdes hemmelig for at digitale signaturer skal kunne gi forsikringer om at dataen kommer fra en pålitelig kilde. Dersom privat-nøkkelen er gjort til kjenne for en motpart, altså kompromittert, vil ikke secure boot kunne gi noen forsikringer mot eksekvering av skadevare. I det tilfellet hvor man oppdager at en privat-nøkkel er blitt kompromittert, er det viktig at korresponderende offentlig nøkkel som ligger lagret på enheten blir opphevet slik at enheten kan ivareta sine sikkerhetsgarantier når det gjelder boot prosessen. 

Følgende diagrammer illustrerer prosessen ved å generere og verifisere digitale signaturer: 

Secure boot løsningen vil som oftest tilby flere andre sikkerhetsmekanismer og tjenester for å ivareta sikkerheten til en enhet, slik som: 

• Muligheten til å oppheve nøkler dersom de er blitt kompromittert (key revocation) 
• Beskytte mot tilbakestilling av programvare-versjon (rollback protection) 
• Gjenoppretting av enheten dersom programvaren er blitt korrupt eller tuklet med (device recovery) 
• Aktivering og oppsett av hardware-isolasjon gjennom bruk av såkalt Trusted Execution Environment (TEE) 

Dersom uhellet skulle være ute, så er opphevelse av nøkler og muligheten til å gjenopprette systemet viktige mekanismer for å gjøre systemet mer robust. Men vær klar over at det ikke er en erstatning eller unnskyldning for å ikke ivareta sikkerheten til privat-nøklene – som er utgangspunktet for de nevnte sikkerhetsgarantier som secure boot tilbyr. 

Bootloadere og secure boot er ofte oversett og implementert sent i utviklingsfasen av et produkt selv om bootloadere er kritiske og potensielt komplekse programmer. Secure boot gjør denne prosessen enda vanskeligere fordi man selv er ansvarlig for sikkerheten. Hvor mye erfaring og kunnskap et team trenger innenfor utvikling av bootloadere og secure boot løsninger avhenger av om man kan dra nytte av ferdige løsninger som allerede er kompatible, testet og verifiserte – enten via en tredjeparts leverandør eller via selskapet som utvikler selve prosessoren. På generelt grunnlag er det bedre å ta utgangspunkt i en løsning som allerede er testet og verifisert, og heller tilpasse eller konfigurere løsningen etter enhetens behov fremfor å utvikle en komplett løsning fra bunnen av. Uavhengig av hvilken løsning man går for så er det viktig at man starter utviklingsprosessen tidlig slik at man har mulighet til å rette opp i eventuelle svakheter som oppdages underveis. 

Til slutt, ikke bli lurt av en falsk følelse av sikkerhet! Secure boot sikrer at enheten booter opp til operativsystemet i en tilstand av integritet, men det vil fortsatt være mulig for en motpart å for eksempel angripe enheten gjennom åpne nettverksporter eller lage skadevare som eksekveres av operativsystemet. Secure boot er bare én av flere viktige brikker som må på plass for å sikre at et system kan operere trygt og sikkert.