Vihamielisen koodin voi pysäyttää Secure Bootin avulla

Teknologian suosio on kasvamassa sulautetuissa laitteissa. Niiden tyypillinen käyttö kriittisessä infrastuktuurissa vaatii kovennettua suojausta ja secure boot on tärkeä osa tätä kokonaisuutta. Secure boot on myös nousemassa vaatimukseksi turvallisuusstandardeissa, kuten IEC62443-4-2:ssa.

Ensimmäinen kokemukseni sulautetusta secure bootista on vuoden 2002 tienoilta, jolloin valoimme Nokian puhelinten laitteistoturvallisuuden perustuksia. Vaikuttaa siltä, että lopputulos oli kelvollinen, sillä Nokia on käyttänyt kyseistä turvallisuusarkkitehtuuria yli miljardissa puhelimessa. Puhelinturvallisuuden kehityshistoriasta kiinnostuneille suosittelen seuraavaa kirjoitusta: Historical insight into the development of Mobile TEEs

Secure bootin perustoteutus ei ole mutkikas. Kun käynnistetty sovellus lataa seuraavan sovelluskerroksen, lataava sovellus tarkistaa ja varmistaa ladattavan sovelluksen allekirjoitukset. Tätä kutsutaan luottamusketjuksi. Ensimmäinen ohjelmanpätkä ladataan järjestelmäpiirin sisäiseltä ROM:lta, jonka koskemattomuuteen voidaan suoraan luottaa. Tämä ROM-koodi luottaa kertaohjelmoitavasta eFuse:sta löytyvään avaimeen ja käyttää tätä avainta varmistaakseen seuraavaksi ladattavan ohjelmiston.

Joskus käytetään erillistä Trusted Platform Module (TPM) -piiriä käyttöjärjestelmätasolla tapahtuvaan tallennustilan salaukseen. Luottamusketju voidaan toisinaan katkaista tähän ja olettaa salatulla levyllä sijaitseva ohjelmisto turvalliseksi. Tällainen ratkaisu on hieman vähemmän turvallinen, sillä se ei pysäytä kaikkia eri skenaariota, joissa hyökkääjä voi vaikuttaa ohjelmistoon.

Yllä mainitut mekanismit ovat yleisesti tunnettuja ja toteutukset varsin samankaltaisia. Varianssia syntyy vasta kun lisävaatimukset monimutkaistavat tarvittavaa ratkaisua.

Miten on mahdollista kokeilla kehitysasteella olevaa softaa, jos laite hyväksyy vain sallittuja ohjelmistoja? Täytyykö jokainen keskeneräinen versio valtuuttaa testausta varten kuten virallinen julkaisu? Onko jokaisen kehittäjän mahdollista allekirjoittaa ohjelmistoja halutessaan?

Eroavaisuudet kehityslaitteiden ja tuotantolaitteiden välillä saattavat aiheuttaa yhteensopivuusongelmia. Olisi parasta, että molemmat laitteet olisivat mahdollisimman samanlaisia.

Helpoin ratkaisu on käyttää kahta eri laitevarianttia tuotantoon ja kehitystyöhön. Huonona puolena on, että kehittäjä ei tällöin välttämättä voi ajaa julkaistua ohjelmistoa omassa laitteessaan. Jos tuotanto-ohjelmisto on salattu, tätä voi olla haastavaa välttää.

Vaihtoehtoinen tapa on sallia ohjelmistokehitys rajatusti aidoissa tuotantolaitteissa. Tällöin kehittäjät voivat sallia kehitettävän ohjelmiston käyttämisen omissa laitteissaan. Oikein toteutettuna tämä on sekä turvallista, että kätevää.

Secure bootin aktivoinnin lisäksi usein JTAG, sekä muut debuggaukseen käytettävät laitteistoväylät kytketään pois käytöstä. Tämä tehdään siksi, että näiden laitteistoväylien avulla hyökkääjä voisi kiertää secure bootin. Tästä on myös haittaa – mikäli laite lakkaa toimimasta tai käyttäytyy oudosti, sitä ei voida enää tutkia tavalliseen tapaan.

Secure bootin allekirjoitusavaimien ja niiden käytön suojaaminen on tärkeää. Jos avaimet vuotavat tai niitä käytetään väärin, secure bootin suojaus on murrettu. Turvallisuuden palauttaminen tällaisen murron jälkeen voi olla vaikeaa, vaikka teknisesti avaimien vaihtaminen olisikin mahdollista. Kriittisien allekirjoitusavaimien säilytys Hardware Secure Module (HSM) -yksikössä olisi erinomainen, mutta usein kohtuuttoman kallis vaihtoehto.

Salausavainten kierrättäminen säännöllisesti on hyvä tapa tietoturvallisuudessa, mutta lähes mahdotonta pääavaimien kohdalla sulautetussa secure bootissa. Useimmissa piireissä pääavain voidaan vaihtaa vain muutaman (1–9) kerran. Tämä raja on liian alhainen säännölliseen avainten kierrätykseen.

Allekirjoituksen eristäminen omaan vaiheeseen voi olla mahdotonta, vaikka tämä onkin yleinen tapa Windows-ohjelmistojen allekirjoituksessa. Tästä syystä ohjelmiston kokoaminen vaatii tuotanto-avaimien käyttämisen. Tämä tuo lisää vaatimuksia julkaisuputken toteutukselle.

Turvallisen laitteen valmistaminen vaatii luottamusta tuotantoympäristöön. Tämä voi olla haastavaa, jos tuotanto ulkoistetaan.

Mikäli ohjelmisto tallennetaan salattuna, tuotannon on ohjelmoitava salausavain. Joskus tuotanto myös generoi laite sertifikaatin (kuten IDevID) laitteelle. Molemmat vaativat luottamusta fyysiseen ohjelmointi ympäristöön; sertifikaatin tuottaminen voi vaatia jopa internet-yhteyttä.

Useimmat piirit eivät oletusarvoisesti aktivoi secure boottia, joten se on erikseen otettava käyttöön eFusen avulla.

Jokainen järjestelmäpiiritoimittaja tarjoaa oman toteutuksensa secure bootista. Ne voivat tarjota hyviä ratkaisuja useisiin ongelmiin, mutta myös synnyttää valmistajakohtaisia ongelmia. Kaikki puhelimiin tarkoitetut SoC-piirit tarjoavat hyvin samankaltaiset secure boot -ominaisuudet, mikä luultavasti johtuu Nokian aikaisesta vaikutuksesta. Teollisten laitteiden keskuudessa kaksi yleisintä secure boot -käyttöön sopivaa piiriperhettä ovat NXP iMX ja Xilinx ultrascale+.

NXP iMX -sarjalla on kypsä toteutus hyvillä työkaluilla ja ominaisuuksilla. Esimerkki yhdestä edistyneemmästä ominaisuudesta on mahdollisuus turvallisesti tutkia kentällä rikkoutuneita laitteita.

Xilinx ultrascale+ on varsin ainutlaatuinen piiri integroidulla FGPA:lla. Tämä piiri tarjoaa laajoja ominaisuuksia peukaloimissuojattujen laitteiden kehitykseen. Dokumentaatio keskittyy pääosin näihin edistyneisimpiin ominaisuuksiin ja jättää tavallisemmat turvallisuusominaisuudet vähemmälle. Samaan aikaan tämä piiri sisältää epätavallisia piirteitä, kuten SHA-3 tiivisteen käyttö allekirjoituksessa. Tämä vähentää allekirjoituksen tuottamiseen käytettävien ratkaisujen määrää.

On varmasti houkuttelevaa ajatella secure boottia yhtenä yksinkertaisena aktivoitavana piiriominaisuutena. Todellisuudessa secure bootin toteuttaminen täydessä laajuudessaan vaatii huomiota monella osa-alueella. Secure boot -ratkaisun toteuttaminen ensimmäistä kertaa voi aiheuttaa yllättäviä ja vaikeasti ennustettavia seurannaisvaikutuksia eri prosesseihin ja osiin järjestelmässä.

Joku ystävällinen aikamatkaaja voisi lähettää tämän kirjoituksen vuoteen 2002 luettavakseni – se olisi säästänyt paljon tutkimustyötä. Valitettavasti viimeaikaiset tutkimukset osoittavat, että ei ole helppoa löytää aikamatkaajia Internetistä.

Secure boot -ratkaisun rakentaminen tuo usein esille olemassaolevia aukkoja tietoturvassa. Näiden aukkojen paikkaaminen voi olla tärkeää, mutta on hyvä myös muistaa, ettei välttämättä ole mahdollista korjata kaikkia aukkoja kerralla. On tärkeää ylläpitää tasapainoinen näkymä tietoturvariskeihin.

Arvaan, että iso osa loppuun asti lukeneista on mukana sulautetussa secure boot -projektissa tai suunnittelemassa sellaista. Toivon, että tämä kirjoitus antaa teille ideoita ja varmuutta matkalla kohti turvallisempaa boottia!