Slik signerer du drivere i Windows trinn for trinn

Signering av 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øerFør eller siden kommer du til å 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 å snike seg inn i kjernen: den ønsker gyldige digitale signaturer, moderne algoritmer som SHA2, og i mange tilfeller sertifisering gjennom Microsoft.

I de følgende linjene skal vi rolig undersøke hva det egentlig vil si å signere en kontrollør, hvilke forskjeller det er mellom kjernemodus og brukermodusHvordan 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 klarert instans.

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

Driversignering i Windows innebærer å tilknytte en digital signatur til en driverpakke (binære filer, 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 produsenten av maskinvare).

I praksis brukes disse digitale signaturene under installasjonen av en Windows-enhet til å bekrefte pakkens integritet og utgiverens identitet. Hvis noe ikke samsvarer (ø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 skal kjøre i kjernen Den må være korrekt signert.Ellers vil ikke driveren lastes inn, enheten kan slutte å virke, og det kan til og med oppstå blåskjermer hvis ugyldige binærfiler blir tvunget til å lastes inn.

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

Det er viktig å huske på at fra og med Windows 10 versjon 1507, er alle drivere signert gjennom Microsoft Hardware Development Center signert med SHA2 som en hash-algoritmeSHA1 har blitt foreldet for disse scenariene, og blanding av gamle sertifikater kan forårsake problemer, spesielt på nyere systemer.

Forskjeller mellom driversignering i kjernemodus og brukermodus

Windows støtter drivere som kjører i kjernemodus og brukermodusSigneringspolicyen 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 senere er disse driverne De må signeres for å bli belastet. Denne begrensningen er direkte relatert til systemstabilitet og beskyttelse mot malware at den forsøker å injisere på et lavt nivå.

På den annen side var drivere som opererer i brukermodus (for eksempel mange skriverdrivere og tilleggskomponenter) opprinnelig ikke underlagt en så streng forpliktelse. Faktisk, i eldre versjoner av Windows Det var ikke et absolutt krav at disse driverne 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 som er installert på en x64-datamaskin viser vanligvis en dialogboks under installasjonsprosessen som ber om brukerbekreftelse. I praksis viser den pakken Den må være korrekt signert slik at installasjonen kan fortsette uten blokkeringer eller kritiske sikkerhetsvarsler.

Den generelle ideen er at selv om kravet ikke er universelt i brukermodus, presser Microsoft i økende grad på for at det skal all driverrelatert programvare må signeresÅ signere dem muliggjør pålitelig verifisering av hvem som opprettet dem, oppdagelse av manipulering og en reduksjon i risikoen for at ondsinnede komponenter sniker seg inn mens de utgir seg for å være legitime kontrollører.

Signaturkrav og SHA-algoritmer i forskjellige versjoner av Windows

Et av de mest problematiske aspektene er kompatibiliteten mellom Windows-versjoner og hash-algoritmer som f.eks. SHA1 og SHA2Mange utviklere støter på drivere som fungerer på ett system, men ikke på et annet, og mye av skylden ligger i endringer i signeringspolicyer.

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 advarte om at SHA1 var ikke tilstrekkelig sikkerEtter hvert som det har blitt gjort fremskritt mot Windows 8.1 og 10, har SHA2 blitt 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, i visse tilfeller, De klarer ikke å laste inn i versjoner før Windows 10og 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 gir en liste over referanse SHA hash-verdier i delen «Mer informasjon – Informasjon om filhash» i den støtteartikkelen.

Hvis du skal distribuere drivere som må fungere på flere versjoner av Windows, er det viktig å gjennomgå signaturkrav per versjon detaljert av Microsoft. Der spesifiseres 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 oppmerksomhet. Microsoft håndhevet det ikke så strengt fra starten av, men det gjorde de... anbefaler på det sterkeste å ivareta sikkerheten av systemet og gi sluttbrukeren trygghet.

Signaturen til en brukermodusdriver utfører i utgangspunktet de samme funksjonene som i kjernemodus: identifiserer leverandøren av behandlingsansvarlig (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-datamaskin, kan installasjonsveiviseren vise en dialogboks som spør om utgiveren er klarert. Hvis signaturen er gyldig og sertifikatet tilhører en gjenkjent enhet, går installasjonen smidigere og med langt færre advarsler.

Microsoft tilbyr en rekke dokumenter og veiledninger som går dypere inn i signeringsprosessen, mange av dem opprinnelig utviklet for kjernemodus, men også anvendelige for brukermodus. Hovedartikkelen om sjåførens signatur og underemnet «Slik versjonssignerer du en kjernemodul» i veiledningen for kjernemodus-kodsignering er gode utgangspunkt for å forstå den generelle logikken bak kodesignering i Windows.

I tillegg inneholder installasjonen av Windows Driver Kit (WDK) en hjelpefil kalt selvsignering_lesmeg.htm, som ligger i katalogen selvsigneringDette 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, bør den behandles som om den var obligatorisk. Dette skyldes sikkerhet, merkevareimage og kompatibilitet med Windows-installasjonsveivisere. Å signere sjåføren er det mest fornuftige å gjøre..

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. kommandoer SignToolDette verktøyet, som er inkludert i Windows SDK, 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 Funksjonene til SignTool er som følger:

• /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å den signeres. alle relevante binærfiler i prosjektet (for eksempel .sys-filer) og også katalogfilen (.cat) som grupperer settet med filer i pakken.

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

Et typisk scenario innebærer å anskaffe riktig kodesigneringssertifikat, for eksempel et Sertifikat for «Microsoft Cross Certificate» utstedt av GlobalSign eller en annen pålitelig instans. Du plasserer kryssertifikatet (CrossCert.crt) i arbeidskatalogen din sammen med hovedsertifikatet for kodesignering (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 kryssertifisering og henter et tidsstempel fra GlobalSigns RFC 3161-server. Tidsstempelet er viktig fordi det beviser at filen ble signert på en dato da sertifikatet var gyldig, selv om det senere utløper.

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 Den fremtvinger en detaljert utdata, som viser detaljert informasjon om sertifikatkjeden og alternativet -kp Den verifiserer signaturen i henhold til kjernemodusdriverens spesifikke kriterier for kodesignering. 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 .cat-filen av pakken. Når både binærfilene og katalogen er riktig signert, kan driveren installeres på Windows 7 og 8 x64 uten sikkerhetsproblemer, og under installasjonsveiviseren skal informasjonen om den klarerte utgiveren og standard systemvinduer vises.

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