Slik signerer du drivere i Windows trinn for trinn

Å signere en driver i Windows kan ved første øyekast virke som noe bare svært avanserte utviklere kan gjøre, men hvis du jobber med enheter, tilpassede drivere eller testmiljøer , vil du uunngåelig støte på dette kravet. I moderne systemer, spesielt 64-biters systemer, stoler ikke lenger Windows på hvilken som helst binærfil som prøver å infiltrere kjernen: det krever gyldige digitale signaturer, moderne algoritmer som SHA2 og i mange tilfeller sertifisering gjennom Microsoft.

I de følgende linjene skal vi rolig undersøke nøyaktig hva det betyr å signere en driver, hva forskjellene er mellom kjernemodus og brukermodus , hvordan det påvirker 64-biters Windows 7, 8, 8.1 og 10, hvilken rolle verktøy som SignTool eller Visual Studio spiller, og hvilke alternativer du har for både utviklingsmiljøer (test- eller selvsignerte sertifikater) og offentlige utgivelser med sertifikater utstedt av en pålitelig instans.

Hva er driversignering i Windows, og hvorfor er det obligatorisk?

Driversignering i Windows innebærer å knytte en digital signatur til en driverpakke (binærfiler, INF-filer, katalog osv.) for å garantere to ting: at ingen har manipulert filene siden de ble opprettet, og at de virkelig kommer fra den angitte utgiveren (programvareleverandøren eller maskinvareprodusenten ).

I praksis brukes disse digitale signaturene til å bekrefte pakkens integritet og utgiverens identitet under installasjonen av en Windows-enhet . Hvis noe er galt (ødelagt signatur, upålitelig sertifikat, feil hash osv.), vil systemet vise advarsler, blokkere installasjonen eller rett og slett nekte å laste inn driveren.

Fra Windows Vista 64-bit og utover, og spesielt i Windows 7, 8, 8.1 og 10 x64, er sikkerhetspolicyen for kjernemodus klar: alle drivere som kjører i kjernen må være riktig signert . Ellers vil ikke driveren lastes inn, enheten kan bli ubrukelig, og det kan til og med oppstå blåskjermer hvis ugyldige binærfiler blir tvunget til å lastes inn.

Når du velger å sertifisere driveren din hos Microsoft, kan du sende den til valideringsprosessen for Windows Hardware Quality Labs (WHQL). Hvis driverpakken består sertifiseringstestene, gir Microsoft den sin offisielle WHQL-signatur . Dette forbedrer ikke bare tillit og kompatibilitet, men lar deg også distribuere driveren via Windows Update og andre distribusjonskanaler som støttes av Microsoft.

Det er viktig å huske på at fra og med Windows 10 versjon 1507, signeres alle drivere som signeres gjennom Microsoft Hardware Development Center med SHA2 som hash-algoritme . SHA1 er nå foreldet for disse scenariene, og blanding av eldre sertifikater kan forårsake problemer, spesielt på nyere systemer.

Forskjeller mellom driversignering i kjernemodus og brukermodus

Windows inkluderer drivere som kjører i kjernemodus og brukermodus . Signeringspolicyen er ikke helt den samme i begge miljøene, selv om den har en tendens til å bli strengere med hver ny versjon av operativsystemet.

Kjernemodusdrivere er de mest sensitive fordi de kjører i systemkjernen og har privilegert tilgang til minne og maskinvare. I 64-biters versjoner av Windows Vista og nyere må disse driverne signeres for å kunne lastes. Denne begrensningen er direkte relatert til systemstabilitet og beskyttelse mot skadelig programvare som prøver å injisere seg selv på lavt nivå.

På den annen side var drivere som opererer i brukermodus (for eksempel mange skriverdrivere og tilleggskomponenter) opprinnelig ikke underlagt et så strengt krav. Faktisk var det ikke et absolutt krav i eldre versjoner av Windows at disse driverne skulle signeres. Microsoft har imidlertid alltid anbefalt å signere dem av sikkerhetsmessige årsaker, og siden Windows 8 finnes det scenarier der signering er nødvendig for visse typer brukerdrivere.

Et typisk eksempel: en skriverdriver installert på en x64-datamaskin viser vanligvis en dialogboks under installasjonsprosessen som ber om brukerbekreftelse. I praksis må denne pakken signeres riktig for at installasjonen skal fortsette uten kritiske sikkerhetskrasj eller varsler.

Den generelle ideen er at selv om kravet ikke er universelt i brukermodus, presser Microsoft i økende grad på for at all driverrelatert programvare skal signeres . Signering av dem muliggjør pålitelig verifisering av hvem som opprettet dem, oppdagelse av manipulering og en reduksjon i risikoen for at skadelige komponenter slipper gjennom forkledd som legitime drivere.

Signaturkrav og SHA-algoritmer i forskjellige versjoner av Windows

Et av de mest problematiske aspektene er kompatibilitet mellom Windows-versjoner og hash-algoritmer som SHA1 og SHA2 . Mange utviklere støter på drivere som fungerer på ett system, men ikke på et annet, hovedsakelig på grunn av endringer i signaturpolicyer.

I eldre systemer, som 64-biters Windows 7 eller 8, var det vanlig å jobbe med sertifikater og signaturer basert på SHA1, selv om Microsoft allerede hadde advart om at SHA1 ikke var tilstrekkelig sikkerhetsmessig . Etter hvert som systemene utviklet seg til Windows 8.1 og 10, ble SHA2 standarden for kode- og driversignaturer.

I praksis valgte noen produsenter å signere kjernemodusbinærfiler ved å legge inn doble sertifikater (SHA1 og SHA2) utstedt av andre enheter enn Microsoft. Disse dobbeltsignerte binærfilene kan i visse tilfeller ikke lastes inn på versjoner før Windows 10 , og på noen Windows 10-systemer kan de til og med forårsake alvorlige krasj eller blåskjermer.

For å redusere disse problemene har Microsoft gitt ut spesifikke oppdateringer, for eksempel oppdatering KB 3081436. Installasjon av denne oppdateringen på berørte systemer korrigerer inkompatibiliteter med visse SHA2-signerte drivere, og en liste over referanse-SHA-hashverdier finnes i delen «Mer informasjon – Fil-hashinformasjon» i den støtteartikkelen.

Hvis du distribuerer drivere som må fungere på flere versjoner av Windows, er det viktig å gjennomgå de versjonsspesifikke signeringskravene som Microsoft tilbyr. Disse spesifiserer hvilke algoritmer som er gyldige, hvordan bakoverkompatibilitet håndteres og hvilke signaturkombinasjoner (katalog, innebygd binærfil, kryssertifikater osv.) som offisielt aksepteres.

Signering av brukermodusdrivere: anbefalinger og ressurser

Selv om kjernen ofte får mest oppmerksomhet, fortjener også signering av drivere i brukermodus å bli vurdert. Microsoft håndhevet det ikke strengt fra starten av, men anbefaler det på det sterkeste for å bevare systemsikkerheten og gi sluttbrukeren tillit.

Signaturen til en brukermodusdriver har i hovedsak samme funksjon som i kjernemodus: den identifiserer driverleverandøren (produsent, ISV osv.) og bekrefter at pakken ikke har blitt endret siden den ble signert. Når en bruker for eksempel installerer en skriver med brukermodusdrivere på en x64-basert datamaskin, kan installasjonsveiviseren vise en dialogboks som spør om utgiveren er klarert. Hvis signaturen er gyldig og sertifikatet tilhører en anerkjent instans, går installasjonen smidigere og med langt færre advarsler.

Microsoft tilbyr en rekke dokumenter og veiledninger som går dypere inn i signeringsprosessen, hvorav mange opprinnelig ble utviklet for kjernemodus, men som også kan brukes i brukermodus. Hovedartikkelen om driversignering og underemnet «Slik versjonssignerer du en kjernemodul» i veiledningen for kodesignering i kjernemodus er gode utgangspunkt for å forstå den generelle logikken bak kodesignering i Windows.

I tillegg inneholder installasjonen av Windows Driver Kit (WDK) en hjelpefil kalt selfsign_readme.htm , som ligger i selfsign- katalogen . Dette dokumentet forklarer hvordan du genererer testsertifikater og hvordan du bruker dem under utvikling, noe som er spesielt nyttig når du ennå ikke har et sertifikat utstedt av en klarert rotinstans.

Oppsummert, selv om en brukermodusdriver teknisk sett kan fungere uten signatur i noen tilfeller, er det best å behandle den som om den var obligatorisk. Fra et sikkerhets-, merkevareimage- og kompatibilitetsperspektiv for Windows-installasjonsveiviseren er signering av driveren den mest fornuftige tilnærmingen.

Signering av kjernemodusdrivere i Windows 7 og 8 ved hjelp av SignTool

Når du arbeider med 64-biters Windows 7 og 8, er en av de vanligste måtene å signere kjernemodusdrivere på å bruke kommandolinjeverktøyet SignTool , som er inkludert i Windows SDK. Dette verktøyet lar deg både signere filer og verifisere eksisterende signaturer, og det tilbyr et bredt spekter av alternativer som passer til ulike scenarier.

Noen av de viktigste alternativene i SignTool er følgende:

• /ac: spesifiserer et tilleggssertifikat, for eksempel et kryssertifikat som kobler sertifikatet ditt til en klarert rotautoritet.
• /f: indikerer filen som inneholder signeringssertifikatet (vanligvis en .pfx).
• /p: oppgir passordet som er knyttet til signeringssertifikatet som er lagret i .pfx-filen.
• /fd: definerer hash-algoritmen som brukes når filsignaturen opprettes, for eksempel, /fd sha256 for å generere en signatur basert på SHA256 (hvis ingenting er spesifisert, er SHA1 vanligvis standardverdien i eldre versjoner).
• /n «Vanlig navn på sertifikatet»lar deg velge et bestemt sertifikat fra Windows-sertifikatlageret basert på dets vanlige navn (CN).
• /t: spesifiserer en tidsstemplingsserver som er kompatibel med Microsoft Authenticode-skjemaet.
• / tr: indikerer en tidsstempelserver som er kompatibel med RFC 3161, mer moderne og anbefalt for nye implementeringer.

Når du jobber med driverprosjektet ditt, er det viktig å vite hvilke filer som må signeres. For at en driver skal installeres riktig på Windows 7 eller 8, må alle relevante prosjektbinærfiler (f.eks. .sys-filer) og katalogfilen (.cat) som grupperer pakkefilene signeres.

Du har to hovedalternativer: du kan kopiere disse filene til en arbeidsmappe der du har SignTool tilgjengelig, eller flytte dem direkte til bin-mappen i Windows SDK og kjøre verktøyet derfra. Det viktigste er at du har både binærfilene og sertifikatene du skal bruke til signering lett tilgjengelig.

Et typisk scenario innebærer å anskaffe riktig kodesigneringssertifikat, for eksempel et «Microsoft Cross Certificate» utstedt av GlobalSign eller en annen klarert instans. Du plasserer dette kryssertifikatet (CrossCert.crt) i arbeidskatalogen din sammen med ditt primære kodesigneringssertifikat (for eksempel CodeSign.pfx) og kjører en kommando som ligner på denne:

signtool sign /ac CrossCert.crt /f CodeSign.pfx /p passord1234 /tr http://timestamp.globalsign.com/tsa/r6advanced1 filter.sys

Denne kommandoen genererer en signatur som inkluderer kryssertifikatet og henter et tidsstempel fra GlobalSign RFC 3161-serveren. Tidsstempelet er avgjørende fordi det beviser at filen ble signert på en dato da sertifikatet var gyldig, selv om det utløper senere.

Etter at du har signert filen, er det på tide å bekrefte at alt er riktig. Dette gjøres vanligvis ved hjelp av en bekreftelseskommando som for eksempel:

signtool verifisere -v -kp filnavn.sys

Alternativet -v fremtvinger detaljert utdata, og viser detaljert informasjon om sertifikatkjeden, og alternativet -kp verifiserer signaturen i henhold til kjernemodusdriverspesifikke kodesigneringskriterier. Hvis alt går bra, vil du se et resultat som indikerer at signaturen og sertifikatkjeden er riktige.

Til slutt anbefales det å gjenta den samme signerings- og verifiseringsprosessen med pakkens .cat-fil. Når både binærfilene og katalogen er riktig signert, kan driveren installeres på Windows 7 og 8 x64 uten sikkerhetsproblemer, og informasjonen om den klarerte utgiveren og standard systemvinduer skal vises under installasjonsveiviseren.

For å gå dypere inn i alle verktøyets variasjoner, har Microsoft en omfattende referanse for SignTool-kommandoer, samt en spesifikk veiledning for kjernemodus-kodesignering og dokumentasjon dedikert til digitale signaturer av kjernemoduler i Windows. Disse ressursene forklarer spesialtilfeller, avanserte parametere og de spesifikke funksjonene til hver systemversjon.