Så här signerar du drivrutiner i Windows steg för steg

Signera en drivrutin i Windows kan vid första anblicken verka som något som bara mycket avancerade utvecklare kan göra, men om du arbetar med enheter, anpassade drivrutiner eller testmiljöerFörr eller senare kommer du att stöta på detta krav. I moderna system, särskilt 64-bitarssystem, litar Windows inte längre på vilken binärfil som helst som försöker smyga sig in i kärnan: det vill ha giltiga digitala signaturer, moderna algoritmer som SHA2 och, i många fall, certifiering från Microsoft.

I följande rader ska vi lugnt undersöka vad det exakt innebär att signera en kontrollant, vilka skillnader det finns mellan kärnläge och användarlägeHur det påverkar 64-bitars Windows 7, 8, 8.1 och 10, vilken roll verktyg som SignTool eller Visual Studio spelar, och vilka alternativ du har för både utvecklingsmiljöer (test- eller självsignerade certifikat) och offentliga utgåvor med certifikat utfärdade av en betrodd auktoritet.

Vad är drivrutinssignering i Windows och varför är det obligatoriskt?

Drivrutinssignering i Windows innebär att man associerar en digital signatur till ett drivrutinspaket (binära filer, INF-filer, kataloger etc.) för att garantera två saker: att ingen har manipulerat filerna sedan de skapades och att de verkligen kommer från den angivna utgivaren (programvaruleverantören eller tillverkaren av hårdvara).

I praktiken används dessa digitala signaturer under installationen av en Windows-enhet för att verifiera paketets integritet och utgivarens identitet. Om något inte stämmer överens (skadad signatur, opålitligt certifikat, felaktig hash etc.) kommer systemet att visa varningar, blockera installationen eller helt enkelt vägra att ladda drivrutinen.

Från och med Windows Vista 64-bitarsversioner, och särskilt i Windows 7, 8, 8.1 och 10 x64, är säkerhetspolicyn för kernelläge tydlig: alla drivrutiner som ska köras i kärnan Den måste vara korrekt undertecknad.Annars laddas inte drivrutinen, enheten kan sluta fungera och blå skärmar kan till och med uppstå om ogiltiga binärfiler tvingas laddas.

När du bestämmer dig för att certifiera din drivrutin med Microsoft kan du skicka den till valideringsprocessen för Windows Hardware Quality Labs (WHQL). Om drivrutinspaketet klarar certifieringstesterna beviljar Microsoft sin certifiering. officiell WHQL-signaturDetta förbättrar inte bara förtroendet och kompatibiliteten, utan låter dig också distribuera drivrutinen via Windows Update och andra distributionskanaler som stöds av Microsoft.

Det är viktigt att komma ihåg att från och med Windows 10 version 1507 signeras alla drivrutiner som signerats via Microsoft Hardware Development Center med hjälp av SHA2 som en hashalgoritmSHA1 har blivit föråldrat för dessa scenarier, och att blanda gamla certifikat kan orsaka problem, särskilt på nyare system.

Skillnader mellan drivrutinssignering i kernelläge och användarläge

I Windows, drivrutiner som körs i kärnläge och användarlägeSigneringspolicyn är inte exakt densamma i båda miljöerna, även om den tenderar att bli strängare med varje ny version av operativsystemet.

Kärnlägesdrivrutiner är de känsligaste eftersom de körs i systemkärnan och har privilegierad åtkomst till minne och hårdvara. I 64-bitarsversioner av Windows Vista och senare är dessa drivrutiner De måste vara undertecknade för att debiteras. Denna begränsning är direkt relaterad till systemstabilitet och skydd mot malware att den försöker injicera på låg nivå.

Å andra sidan var drivrutiner som fungerar i användarläge (till exempel många skrivardrivrutiner och ytterligare komponenter) ursprungligen inte föremål för en sådan strikt skyldighet. I äldre versioner av Windows var det faktiskt så. Det var inte ett absolut krav att dessa drivrutiner signeras. Microsoft har dock alltid rekommenderat att signera dem av säkerhetsskäl, och sedan Windows 8 finns det scenarier där signering krävs för vissa typer av användardrivrutiner.

Ett typiskt exempel: en skrivardrivrutin som är installerad på en x64-dator visar vanligtvis en dialogruta under installationsprocessen som ber om användarbekräftelse. I praktiken är det paketet Den måste vara korrekt signerad så att installationen kan fortsätta utan blockeringar eller kritiska säkerhetsvarningar.

Den allmänna idén är att, även om kravet inte är universellt i användarläge, så driver Microsoft alltmer på för att det ska all drivrutinsrelaterad programvara måste vara signeradAtt signera dem möjliggör tillförlitlig verifiering av vem som skapade dem, upptäckt av manipulering och en minskning av risken för att skadliga komponenter smyger in medan de utger sig för att vara legitima kontrollanter.

Signaturkrav och SHA-algoritmer i olika versioner av Windows

En av de mest besvärliga aspekterna är kompatibiliteten mellan Windows-versioner och hashalgoritmer som t.ex. SHA1 och SHA2Många utvecklare stöter på drivrutiner som fungerar på ett system men inte på ett annat, och mycket av skulden ligger på förändringar i signeringspolicyer.

I äldre system, som 64-bitars Windows 7 eller 8, var det vanligt att arbeta med certifikat och signaturer baserade på SHA1, även om Microsoft redan varnade för det. SHA1 misslyckades med säkerhetenI takt med att framsteg har gjorts mot Windows 8.1 och 10 har SHA2 blivit standarden för kod- och drivrutinssignaturer.

I praktiken valde vissa tillverkare att signera kernellägesbinärfiler genom att bädda in dubbla certifikat (SHA1 och SHA2) utfärdade av andra enheter än Microsoft. Dessa dubbelsignerade binärfiler, i vissa fall, De misslyckas med att ladda i versioner före Windows 10och på vissa Windows 10-system kan de till och med orsaka allvarliga krascher eller blå skärmar.

För att mildra dessa problem släppte Microsoft specifika patchar, till exempel uppdatering KB 3081436. Installation av den här uppdateringen på berörda system korrigerar inkompatibiliteter med vissa SHA2-signerade drivrutiner och ger en lista över... referens SHA-hashvärden i avsnittet ”Mer information – Information om filhash” i den supportartikeln.

Om du ska distribuera drivrutiner som behöver fungera på flera versioner av Windows är det viktigt att granska signaturkrav per version detaljerad av Microsoft. Där specificeras vilka algoritmer som är giltiga, hur bakåtkompatibilitet hanteras och vilka signaturkombinationer (katalog, inbäddad binär, korscertifikat etc.) som officiellt accepteras.

Signering av drivrutiner i användarläge: rekommendationer och resurser

Även om kärnan ofta får mest uppmärksamhet förtjänar även signering av drivrutiner i användarläge uppmärksamhet. Microsoft tillämpade det inte så strikt från början, men det gjorde de... rekommenderar starkt att bevara säkerheten av systemet och ge slutanvändaren förtroende.

Signaturen för en drivrutin i användarläge utför i princip samma funktioner som i kärnläge: identifierar leverantören av kontrollanten (tillverkare, ISV, etc.) och bekräftar att paketet inte har ändrats sedan det signerades. När en användare installerar till exempel en skrivare med användarlägesdrivrutiner på en x64-dator kan installationsguiden visa en dialogruta som frågar om utgivaren är betrodd. Om signaturen är giltig och certifikatet tillhör en igenkänd enhet går installationen smidigare och med betydligt färre varningar.

Microsoft tillhandahåller en serie dokument och handledningar som fördjupar signeringsprocessen, många av dem ursprungligen utformade för kernelläge men även tillämpliga på användarläge. Huvudartikeln om förarens underskrift och underavsnittet ”Hur man versionssignerar en kärnmodul” i handledningen för kodsignering i kärnläge är bra utgångspunkter för att förstå den allmänna logiken bakom kodsignering i Windows.

Dessutom innehåller installationen av Windows Driver Kit (WDK) en hjälpfil som heter självsignering_läsmig.htm, som finns i katalogen självsigneringDet här dokumentet förklarar hur man genererar testcertifikat och hur man använder dem under utveckling, vilket är särskilt användbart när du ännu inte har ett certifikat utfärdat av en betrodd rotauktoritet.

Sammanfattningsvis, även om en användardrivrutin tekniskt sett kan fungera utan en signatur i vissa fall, bör den behandlas som om den vore obligatorisk. Detta beror på säkerhet, varumärkesimage och kompatibilitet med Windows installationsguider. Att skriva kontrakt med föraren är det mest förnuftiga man kan göra..

Signera kärnlägesdrivrutiner i Windows 7 och 8 med SignTool

När man arbetar med 64-bitars Windows 7 och 8 är ett av de vanligaste sätten att signera drivrutiner i kernelläge att använda kommandoradsverktyget. kommandon SigntoolDet här verktyget, som ingår i Windows SDK, låter dig både signera filer och verifiera befintliga signaturer, och det erbjuder ett brett utbud av alternativ som passar olika scenarier.

Några av de viktigaste alternativen Funktionerna i SignTool är följande:

• /ac: anger ett ytterligare certifikat, till exempel ett korscertifikat som länkar ditt certifikat till en betrodd rotauktoritet.
• /f: anger filen som innehåller signeringscertifikatet (vanligtvis en .pfx).
• /p: anger lösenordet som är kopplat till signeringscertifikatet som lagras i .pfx-filen.
• /fddefinierar hashalgoritmen som används när filsignaturen skapas, till exempel, /fd sha256 för att generera en signatur baserad på SHA256 (om inget anges är SHA1 vanligtvis standardvärdet i äldre versioner).
• /n «Certifikatets vanliga namn»: låter dig välja ett specifikt certifikat från Windows certifikatarkiv baserat på dess vanliga namn (CN).
• /t: anger en tidsstämplingsserver som är kompatibel med Microsoft Authenticode-schemat.
• /tr: indikerar en tidsstämpelserver som är kompatibel med RFC 3161, modernare och rekommenderas för nya implementeringar.

När du arbetar med ditt drivrutinsprojekt är det viktigt att veta vilka filer som behöver signeras. För att en drivrutin ska installeras korrekt i Windows 7 eller 8 måste den signeras. alla relevanta binärfiler i projektet (till exempel .sys-filer) och även katalogfilen (.cat) som grupperar filuppsättningen i paketet.

Du har två huvudalternativ: du kan kopiera filerna till en arbetskatalog där du har SignTool tillgängligt, eller direkt flytta dem till Windows SDK bin-mappen och kör verktyget därifrån. Det viktiga är att du har både binärfilerna och certifikaten som du ska använda för signering till hands.

Ett typiskt scenario innebär att man anskaffar lämpligt kodsigneringscertifikat, till exempel ett Certifikat för "Microsoft Cross Certificate" utfärdat av GlobalSign eller annan betrodd myndighet. Du placerar det korscertifikatet (CrossCert.crt) i din arbetskatalog tillsammans med ditt huvudsakliga kodsigneringscertifikat (till exempel CodeSign.pfx) och kör ett kommando som liknar detta:

signtool signera /ac CrossCert.crt /f CodeSign.pfx /p lösenord1234 /tr http://timestamp.globalsign.com/tsa/r6advanced1 filter.sys

Det här kommandot genererar en signatur som inkluderar korscertifiering och hämtar en tidsstämpel från GlobalSigns RFC 3161-server. Tidsstämpeln är viktig eftersom den bevisar att filen signerades på ett datum då certifikatet var giltigt, även om det senare upphör att gälla.

Efter att filen har signerats är det dags att kontrollera att allt är korrekt. Detta görs vanligtvis med ett verifieringskommando som:

signtool verifiera -v -kp filnamn.sys

Alternativet -v Den tvingar fram en detaljerad utdata som visar detaljerad information om certifikatkedjan och alternativet -kp Den verifierar signaturen enligt kärnlägesdrivrutinens specifika kriterier för kodsignering. Om allt går bra kommer du att se ett resultat som indikerar att signaturen och certifikatkedjan är korrekta.

Slutligen rekommenderas det Upprepa samma signerings- och verifieringsprocess med .cat-filen av paketet. När både binärfilerna och katalogen är korrekt signerade kan drivrutinen installeras på Windows 7 och 8 x64 utan säkerhetsproblem, och under installationsguiden bör informationen om den betrodda utgivaren och standardsystemfönstren visas.

För att fördjupa sig i alla verktygets varianter har Microsoft en omfattande referens för SignTool-kommandon, samt en Specifik handledning för kodsignering i kernelläge och dokumentation dedikerad till digitala signaturer för kärnmoduler i Windows. Dessa resurser förklarar specialfall, avancerade parametrar och särdrag för varje systemversion.