Drivrutinscertifikat och signaturer i Windows: en komplett guide

I Windows har drivrutiner och deras digitala signaturer blivit en viktig del av systemsäkerheten. Utöver att bara aktivera en skrivare, ett grafikkort eller ett smartkort, är det viktiga idag att systemet kan verifiera att programvaran är äkta, legitim och kommer från en betrodd leverantör.

Om du någonsin har stött på meddelanden som "Windows kan inte verifiera utgivaren av den här drivrutinen" eller certifikatrelaterade fel när du installerar en drivrutin, vet du hur frustrerande det kan vara. I den här artikeln kommer vi lugnt att förklara hur drivrutinssignering fungerar i Windows (både i kärn- och användarläge), vilka krav som ändras beroende på Windows-versionen, hur du signerar dina egna drivrutiner och vilka alternativ du har för att säkert inaktivera signaturverifiering när du inte har något annat val.

Vad är drivrutinssignering i Windows och varför är det så viktigt?

Drivrutinssignering är helt enkelt processen att associera en digital signatur (baserad på certifikat) med ett drivrutinspaket. Denna signatur appliceras vanligtvis på paketets katalogfil (.CAT) eller direkt på drivrutinsbinärfilerna (.SYS, .DLL, etc.) med hjälp av inbäddade signaturtekniker.

Under enhetsinstallationen använder Windows dessa digitala signaturer för två huvudsyften : att verifiera att paketet inte har ändrats sedan det signerades (integritet) och att bekräfta programvaruleverantörens identitet (drivrutinsutgivaren). Om något inte stämmer överens visas en varning, eller i strängare scenarier blockeras installationen eller inläsningen av drivrutinen.

I 64-bitarsversioner av Windows Vista och senare introducerade Microsoft en ganska tydlig policy: alla drivrutiner i kernelläge måste signeras för att laddas, med väldigt få undantag. Detta placerar drivrutiner i samma säkerhetskategori som resten av systemets binärfiler, eftersom en sårbarhet på kernelnivå kan kompromettera datorn helt.

Reglerna har blivit strängare med tiden . Från och med Windows 10 version 1507 måste alla drivrutiner som signerats via Microsoft Hardware Development Center använda SHA-2. Den äldre SHA-1-hashen har föråldrats av kryptografiska säkerhetsskäl, och Microsoft har gradvis fasat ut den i hela ekosystemet.

Det finns en viktig detalj: binärfiler för drivrutiner i kernelläge som signerats med dubbla certifikat (SHA-1 + SHA-2) utfärdade av enheter som inte tillhör Microsoft kan ha problem på system äldre än Windows 10 , eller till och med orsaka krascher på Windows 10 och senare. För att förhindra detta släppte Microsoft uppdatering KB3081436, som inkluderar korrekta filhashningar och korrigerar laddningsbeteendet i dessa fall.

Översikt över drivrutinssignering i Windows

För att helt förstå hur allt detta fungerar är det bra att separera begreppen. Å ena sidan finns drivrutinskodsignaturen ( kärnläge eller användarläge), och å andra sidan installationssignaturkraven för Plug and Play (PnP)-enheter. Även om de är relaterade är de inte exakt samma sak: du kan ha en drivrutin som är korrekt signerad på binärnivå, men som inte uppfyller några ytterligare installationskrav.

Microsoft tillhandahåller specifik dokumentation om digitala signaturer för kärnmoduler i Windows Vista och senare system , med detaljerad information om vilka certifikat som är giltiga, hur man konstruerar förtroendekedjor och vilka hashalgoritmer som stöds (för närvarande SHA-2). För drivrutiner som överför skyddat innehåll (ljud och video med DRM, PUMA, PAP, PVP-OPM, etc.) finns det också särskilda kodsigneringskrav inriktade på att skydda multimediainnehåll.

När det gäller publiceringsarbetsflödet finns det flera sätt att skicka drivrutiner till Microsoft Hardware Portal . För produktionsdrivrutiner är standardmetoden att köra tester med HLK eller den äldre HCK och ladda upp både binärfilen och testloggarna. För klientbaserade scenarier i Windows 10 kan attesteringssignering användas, vilket minskar behovet av automatiserad testning samtidigt som validering och signering av Microsoft bibehålls.

Alternativet för testsignering , som är utformat för intern utveckling och testning, är fortfarande tillgängligt. Detta alternativ använder icke-offentliga certifikat eller certifikat utfärdade av en privat PKI. Dessa drivrutiner laddas endast om systemet är konfigurerat i testläge eller med specifika policyer som tillåter testdrivrutiner.

Undantag och korssignerade kontrollanter

I tidiga versioner av Windows 10 är så kallade " korssignerade drivrutiner" fortfarande tillåtna under vissa villkor. Dessa är drivrutiner som signerats av leverantören med ett Authenticode-certifikat som är kedjat till ett mellanliggande certifikat som signerats av Microsoft, vilket kringgår hela hårdvaruportalprocessen.

Microsoft har flera undantag för att förhindra att redan distribuerade system blir ostartbara. Korssignerade drivrutiner är tillåtna i följande situationer: datorn har uppgraderats från en tidigare version av Windows till Windows 10 version 1607 ; säker start är inaktiverad i BIOS/UEFI; eller drivrutinen är signerad med ett certifikat som utfärdats före den 29 juli 2015, som är kopplat till en korssignerad certifikatutfärdare som stöds.

För att minska risken för att systemet blir oanvändbart blockeras inte startdrivrutiner även om de inte följer de nya policyerna, men Programkompatibilitetsassistenten kan flagga dem och föreslå att de tas bort eller byts ut. Tanken är att undvika att störa startsekvensen, utan att gradvis ta bort icke-kompatibla drivrutiner.

Signeringskrav för Windows-versionen

Signeringskraven varierar beroende på den specifika operativsystemversionen och om datorn använder säker start. Generellt sett kan signeringspolicytabellen för klientutgåvor sammanfattas enligt följande:

• Windows Vista och Windows 7och även Windows 8+ med säker start inaktiveradI 64-bitarscertifikat krävs en signatur, medan en signatur inte är obligatorisk i 32-bitarscertifikat. Signaturen kan bäddas in i filen eller i en tillhörande katalog, och den obligatoriska algoritmen är SHA-2. Certifikatkedjan måste avslutas i standardiserade betrodda rötter för kodintegritet.
• Windows 8 och 8.1, och Windows 10 version 1507 och 1511 med säker start aktiveradBåde 32-bitars och 64-bitars drivrutiner kräver signerade drivrutiner. Inbäddad signering eller katalogsignering är fortfarande tillåten med SHA-2, och förlitar sig på standardrötter för kodintegritet.
• Windows 10 versionerna 1607, 1703 och 1709 med säker startKravet skärps och signaturer måste vara förankrade i specifika Microsoft-rotcertifikat (Microsoft Rot Authority 2010, Microsoft Root Certificate Authority och Microsoft Root Authority).
• Windows 10 version 1803 och senare med säker startSamma signaturkrav som är förankrade i de tidigare nämnda Microsoft-root-auktoriteterna bibehålls, för både 32-bitars och 64-bitars system.

Förutom att signera drivrutinskoden måste paketet också uppfylla signeringskraven för Plug and Play-enhetsinstallation . Det betyder att .INF-filer, kataloger och binärfiler måste vara korrekt länkade och återspeglas i signaturen för att enhetsinstallationsprogrammet (och Enhetshanteraren ) ska kunna betrakta dem som giltiga.

Det finns också speciella typer av drivrutiner, till exempel ELAM (Early Launch Anti-Malware) , som laddas mycket tidigt i startprocessen för att skydda systemet mot skadlig kod på låg nivå . Dessa drivrutiner har ytterligare signerings- och certifieringskrav som dokumenterats i Early Launch Anti-Malware Guide.

Signera en drivrutin för Windows 10, Windows 8.x och Windows 7

Om du är drivrutinsutvecklare eller arbetar i en miljö där anpassade drivrutiner distribueras måste du följa Windows Hardware Compatibility Program (WHCP) med hjälp av lämpliga verktyg för varje version: HLK för Windows 10 och HCK för tidigare versioner.

När det gäller Windows 10 är det typiska arbetsflödet: ladda ner Hardware Lab Kit (HLK) som motsvarar varje version av Windows 10 du vill stödja, installera testmiljön och kör ett fullständigt certifieringspass på en klient som kör den versionen. Varje körning genererar en testlogg.

Om du har testat drivrutinen på flera versioner kommer du att ha flera loggar. Vanligtvis kombineras alla loggar till en enda rapport med den senaste versionen av HLK. Denna kombination förenklar inlämningen till hårdvaruportalen och gör att en enda signatur kan täcka flera systemversioner.

När du har posterna skickar du drivrutinsbinärfilen och de kombinerade HLK-resultaten till instrumentpanelen i Windows Hardware Developer Center . Där väljer du vilken typ av signatur du vill ha (till exempel produktion, attestering etc.), konfigurerar överföringsegenskaperna och väntar på att Microsofts automatiserade process genererar de signerade katalogerna och returnerar det certifierade paketet till dig.

En liknande metod används för Windows 7, Windows 8 och Windows 8.1, men med lämpligt hårdvarucertifieringspaket (HCK) för varje version. Microsoft har en användarhandbok för detta paket som förklarar testnings-, validerings- och inlämningsprocessen.

Drivrutinssignering för versioner före Windows 10 version 1607

Innan Windows 10 version 1607 släpptes krävde många typer av drivrutiner ett Authenticode-certifikat i kombination med en Microsoft-korssignatur. Denna teknik, känd som korssignering, gjorde det möjligt för tillverkare att signera sina drivrutiner och låta Windows acceptera dem som om de var "välsignade" av Microsofts infrastruktur.

Drivrutiner som krävde denna signaturmodell inkluderade drivrutiner för kärnläge , drivrutiner för användarläge som interagerar nära med kärnan och drivrutiner som används för att spela upp eller bearbeta skyddat innehåll (DRM-skyddat ljud och video). De senare inkluderade PUMA- eller PAP-baserade ljuddrivrutiner, samt videodrivrutiner som hanterar utdataskydd (PVP-OPM).

Kodsignering för skyddade multimediakomponenter har sina egna riktlinjer, eftersom förtroendekedjan och certifikattillägg måste säkerställa att skyddat innehåll inte lätt kan avlyssnas eller manipuleras.

Praktisk användning av SignTool för att signera drivrutiner i kernelläge (Windows 7 och 8)

I praktiken är det ledande verktyget för att signera binärfiler i Windows SignTool , som ingår i Windows SDK. För kernellägesdrivrutiner i Windows 7 och 8 finns det flera alternativ som är särskilt användbara för signering och verifiering.

Bland de viktigaste parametrarna för SignTool är: /ac för att lägga till ett ytterligare certifikat (till exempel Microsofts korscertifikat) , /f för att ange filen som innehåller signeringscertifikatet (till exempel en .pfx), /p för lösenordet för den PFX:en, /fd för att ange hashalgoritmen (till exempel /fd sha256 för att tvinga fram SHA-256, eftersom SHA-1 är den historiska standardinställningen).

Parametern `/n`, "Common Name of Certificate", är också viktig , eftersom den låter dig välja rätt certifikat från Windows certifikatarkiv med hjälp av dess Common Name. För att lägga till tidsstämplar kan du använda `/t` med en klassisk Authenticode-server eller `/tr` med en RFC 3161-kompatibel server, vilket är det modernaste och mest rekommenderade alternativet.

Ett möjligt arbetsflöde skulle vara att samla drivrutinsbinärfilerna i en arbetskatalog eller till och med kopiera allt till Windows SDK:s bin-mapp. Hämta sedan kodsigneringscertifikatet och, om nödvändigt, Microsofts korscertifikat (till exempel CrossCert som motsvarar den certifikatutfärdare som utfärdade ditt certifikat). Placera båda i samma katalog som du kommer att köra SignTool från.

När allt är klart kan exempelkommandot se ut ungefär så här: `signtool sign /ac CrossCert.crt /f CodeSign.pfx /p password1234 /fd sha256 /tr http://timestamp.globalsign.com/tsa/r6advanced1 filter.sys` . Detta genererar en modern signatur med SHA-256, inkluderar korscertifikatet och lägger till RFC 3161-tidsstämpeln, vilket är avgörande för att signaturen ska förbli giltig även efter att certifikatet har löpt ut.

När signaturen är klar rekommenderas det att verifiera med ett kommando som `signtool verify -v -kp filter.sys` . Flaggan `-v` visar detaljerad information, medan `-kp` kontrollerar signaturen mot drivrutinskriterier i kernelläge. Om utdata indikerar att signaturen är giltig och förtroendekedjan slutar med en accepterad rot är drivrutinen redo för driftsättning.

Det är viktigt att komma ihåg att katalogfilen (.CAT) i många fall också signeras. Processen upprepas: .CAT-filen signeras, verifieras och när allt är i ordning installeras drivrutinen normalt på systemet.

Signatur för attestering och skapande av CAB-paket

Microsoft erbjuder attestering som ett relativt enkelt sätt att distribuera drivrutiner, särskilt på Windows 10-klientsystem. Leverantören ansvarar för att drivrutinen uppfyller kraven, och Microsoft validerar och signerar den helt enkelt, vilket i vissa fall undviker hela uppsättningen HLK-tester.

För att skicka in en drivrutin via attestering förbereds vanligtvis en CAB-fil som paketerar de viktigaste komponenterna i paketet. En typisk CAB innehåller själva binärdrivrutinen (.SYS), INF-filen (.INF) som Windows använder under installationen, felsökningssymbolerna (.PDB) för felsökning och ibland .CAT-kataloger som Microsoft använder som referens för att verifiera strukturen (även om de sedan genererar sina egna kataloger för slutlig distribution).

Att skapa det är enkelt: samla alla filer som ska signeras i en enda katalog, till exempel C:\Echo. Från en kommandotolk med administratörsbehörighet, se MakeCabs hjälp för att se dess alternativ och förbered en DDF-fil med nödvändiga direktiv, som anger vilka filer som ska komprimeras, vilket kabinett som ska genereras och i vilka undermappar de ska organiseras inom CAB:n.

För exemplet med Echo-styrenheten kan DDF-filen ställa in utdatanamnet till Echo.cab, aktivera MSZIP-komprimering och definiera en destinationskatalog (DestinationDir=Echo) så att det inte finns några lösa filer i rotkatalogen för cab. Sedan listas de fullständiga sökvägarna till Echo.inf och Echo.sys så att MakeCab inkluderar dem.

När DDF-filen är klar, kör något i stil med `MakeCab /f Echo.ddf` . Verktyget visar hur många filer det har inkluderat, den uppnådda komprimeringsnivån och i vilken mapp (vanligtvis Disk1) den resulterande CAB-filen har placerats. Öppna helt enkelt Echo.cab-filen med Utforskaren för att bekräfta att den innehåller allt som förväntas.

Signera CAB-certifikatet med ett EV-certifikat och skicka det till Partners Center

Innan paketet laddas upp till Microsofts hårdvaruportal är det standardpraxis att signera CAB:en med ett EV-certifikat (Extended Validation) . Dessa certifikat, som har striktare auktoritetsvalidering, ger ökat förtroende och krävs ofta för vissa typer av signaturer.

Processen varierar något beroende på leverantören av EV-certifikat, men den allmänna idén är att använda SignTool igen, den här gången riktad mot CAB. Ett typiskt kommando kan vara: SignTool sign /s MY /n "Företagsnamn" /fd sha256 /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp /td sha256 /v C:\Echo\Disk1\Echo.cab , vilket lägger till en SHA-256-signatur med en SHA-256-tidsstämpel till lagringsarrayen.

Efter signeringen går du till Microsoft Partner Center , närmare bestämt hårdvaruinstrumentpanelen, och loggar in med din organisations inloggningsuppgifter. Därifrån väljer du alternativet "Skicka ny hårdvara", laddar upp den signerade CAB-filen och fyller i inlämningsegenskaperna: produktnamn, typ av signatur som krävs, om du vill ha en testsignatur eller bara en produktionssignatur, etc.

Det är viktigt att inte aktivera alternativen för testsignering om du letar efter en produktionsdrivrutin. I avsnittet om obligatoriska signaturer väljer du de varianter du vill inkludera i paketet (till exempel signaturer för olika Windows-versioner eller arkitekturer).

När formuläret är ifyllt klickar du på Skicka och låter portalen bearbeta paketet. När Microsoft har signerat drivrutinen visar panelen att inlämningen har bearbetats och låter dig ladda ner den signerade drivrutinen , vanligtvis tillsammans med de kataloger och metadata som krävs för distributionen.

Kontrollera att kontrollanten är korrekt signerad

När paketet är nedladdat är det dags att kontrollera att allt är i sin ordning. Det första steget är att extrahera filerna från leveransen till en tillfällig mapp och öppna ett kommandotolksfönster med administratörsbehörighet . Därifrån kan du använda SignTool för att verifiera signaturerna som tillämpats på nyckelbinärfilerna.

Ett grundläggande kommando skulle vara `SignTool verify Echo.sys` , som snabbt kontrollerar signaturens giltighet. För en mer grundlig verifiering kan du använda ` SignTool verify /pa /ph /v /d Echo.sys` , där `/pa` indikerar användningen av Authenticode-policyn, `/ph` lägger till hashverifiering och `/v` genererar detaljerad utdata med all information om certifikatkedjan.

För att granska de utökade nyckelanvändningarna (EKU:erna) för certifikatet som används för signering kan du använda Utforskaren i Windows: högerklicka på binärfilen, välj Egenskaper, gå till fliken "Digitala signaturer", välj relevant post och klicka på "Information". Från "Visa certifikat" och fliken "Information" kan du kontrollera fältet "Utökade nyckelanvändningar" för att bekräfta att det innehåller lämpliga tillägg för kodsignering eller drivrutinssignering.

Den interna processen i vissa signeringsarbetsflöden innebär att Microsoft återinför sin egen SHA-2-signatur i binärfilen och tar bort alla signaturer som kunden har tillämpat om de inte följer gällande policyer. En ny Microsoft-signerad katalogfil genereras också och ersätter alla tidigare .CAT-filer som skickats av leverantören.

Testa och installera drivrutinen i Windows

När drivrutinen har signerats är det nödvändigt att verifiera att den installeras och fungerar korrekt på målsystemet. Från en administratörskonsol kan verktyg som devcon användas för att automatisera installationen. Om paketet till exempel innehåller en echo.inf-fil som definierar en enhetsrot\ECHO, räcker det med att helt enkelt köra `devcon install echo.inf root\ECHO` i lämplig katalog.

Under den här processen, om allt är korrekt signerat, bör du inte se varningar som "Windows kan inte verifiera utgivaren av den här drivrutinen". Om de visas indikerar det att något i förtroendekedjan eller i katalogerna är feljusterat, och du bör granska både signaturerna och rotcertifikaten som är installerade på systemet.

I mer komplexa scenarier är det möjligt att skapa inskickningar med flera drivrutiner . Vanligtvis skapar man separata undermappar i filstrukturen, en för varje drivrutinspaket (DriverPackage1, DriverPackage2, etc.), och justerar DDF-filen så att varje uppsättning .SYS- och .INF-filer placeras i en egen undermapp i CAB:n. MakeCab samlar sedan allt i ett enda skåp som är klart att skickas till portalen.

Förarsignaturer från användarens synvinkel

Ur slutanvändarens perspektiv uppfattas drivrutinssignering som ett inbyggt säkerhetsfilter i Windows . Precis som med signerade applikationer är tanken att försäkra användaren om att programvaran kommer från en legitim källa och inte har ändrats. Men när det gäller drivrutiner är kravet högre eftersom de arbetar med en mycket hög behörighetsnivå.

När en drivrutin är korrekt signerad och släppt via officiella kanaler distribuerar Windows Update eller operativsystemet självt den ganska transparent. Detta gör det enkelt för användare att få uppdaterade och fixade versioner utan att behöva söka efter något manuellt, med försäkran om att de har klarat Microsofts filter.

Problemet uppstår när du behöver installera drivrutiner som inte är digitalt signerade eller vars signatur inte längre accepteras enligt gällande policyer (till exempel när du försöker använda äldre hårdvara på nyare system). I dessa situationer blockerar Windows installationen eller visar upprepade varningar, vilket tvingar dig att tillgripa mer avancerade lösningar för att fortsätta.

Metoder för att installera osignerade drivrutiner (och deras risker)

Det finns flera sätt att installera drivrutiner som inte följer signaturpolicyerna, men det är viktigt att komma ihåg att varje metod medför en annan risknivå . En tillfällig justering som återställs vid omstart är inte detsamma som att helt inaktivera integritetskontroller.

En vanlig metod är att starta Windows med obligatorisk användning av signerade drivrutiner tillfälligt inaktiverad . För att göra detta, starta om datorn och öppna avancerade alternativ (till exempel från Start-menyn genom att trycka på Skift medan du klickar på Starta om), gå till Felsök > Avancerade alternativ > Startinställningar och välj alternativet "Inaktivera tvingande drivrutinssignatur". Systemet startar sedan utan att kräva signaturer, vilket gör att du kan installera drivrutinen. Vid omstart återigen kommer skyddet att återappliceras automatiskt.

Ett annat alternativ, endast tillgängligt i Windows 10/11 Pro och senare utgåvor , är att använda grupprincipredigeraren (gpedit.msc). I Användarkonfiguration > Administrativa mallar > System > Drivrutinsinstallation kan du redigera principen "Kodsignering för enhetsdrivrutiner" och ställa in den på Inaktiverad. Efter omstart kommer Windows att vara mycket mer försiktig med osignerade drivrutiner eller drivrutiner med tvivelaktiga signaturer.

För test- och utvecklingsscenarier finns en funktion som heter Windows testläge . Den aktiveras från en administratörskonsol genom att köra kommandot bcdedit och gör det möjligt att läsa in drivrutiner som signerats med testcertifikat utan att behöva skicka dem genom den offentliga infrastrukturen. I det här läget visas vanligtvis en vattenstämpel på skrivbordet som indikerar att systemet är i testläge.

Slutligen finns det mest extrema alternativet: att helt inaktivera kontrollen av drivrutinsintegritet med hjälp av bcdedit.exe (med parametern nointegritychecks). Detta gör systemet helt sårbart för installation av alla drivrutiner, oavsett om de är legitima eller inte, och bör endast användas i mycket specifika fall och med full förståelse för vad du gör.

Verkliga faror med att inaktivera förarsignering

Att inaktivera detta skydd är inte bara en liten olägenhet; det öppnar dörren för ett av de svåraste hoten att upptäcka: rootkits på drivrutinsnivå . Dessa installerar sig själva som legitima drivrutiner, men när de väl har laddats har de SYSTEM-behörigheter och möjligheten att övervaka eller manipulera systemet på en mycket låg nivå.

Ett rootkit av den här typen kan fånga upp internettrafik, infoga falska certifikat, omdirigera anslutningar till webbplatser som kontrolleras av angripare, blockera installation av antivirusprogram och underlätta inträde av annan skadlig kod. Allt detta kan göras praktiskt taget utan några synliga spår för användaren, och även för många traditionella säkerhetslösningar.

Genom att använda de högsta behörigheterna blir dessa skadliga drivrutiner praktiskt taget osynliga och svåra att ta bort . I många fall är den enda realistiska lösningen att formatera datorn helt och börja om från början, vilket innebär en betydande förlust av tid och data om det inte finns några uppdaterade säkerhetskopior.

Därför är det klokt att vara misstänksam när ett program ber dig att inaktivera drivrutinssignering för att installera "något magiskt". När det är möjligt är det bättre att leta efter alternativ eller signerade versioner , även om det innebär att ge upp viss föråldrad hårdvara eller specifik funktionalitet.

Windows-drivrutiner kontra tillverkardrivrutiner

När du installerar kringutrustning och komponenter erbjuder Windows vanligtvis generiska drivrutiner som låter dig använda hårdvaran på ett grundläggande sätt. Till exempel kan en multifunktionsskrivare skriva ut utan problem med den generiska drivrutinen, men om du vill skanna, använda den automatiska dokumentmataren eller komma åt avancerade alternativ behöver du nästan säkert tillverkarens officiella drivrutin.

Detsamma gäller ljudkort, grafikkort och andra komplexa enheter: med generiska drivrutiner fungerar datorn, men du förlorar funktioner, prestandaoptimeringar och avancerade konfigurationsverktyg. I många fall erbjuder officiella drivrutiner även specifika buggfixar som aldrig ingår i Microsofts generiska drivrutiner.

Det bästa stället att ladda ner dessa drivrutiner är alltid hårdvarutillverkarens officiella webbplats . När du söker på Google ser du ofta först tredjepartssidor fulla av misstänkta "drivrutinsnedladdare" eller installationsprogram. Om länken inte kommer från tillverkarens domän är det bäst att ignorera den.

Om drivrutinssignering förblir aktiverad kommer många av dessa tvivelaktiga paket att blockeras av Windows när de upptäcker att de är ogiltig programvara eller att signaturerna inte är i rätt ordning. Detta fungerar som ett extra säkerhetslager mot klumpiga eller rentav skadliga installationsprogram.

Praktiskt fall: Signeringscertifikatfel med GPU-drivrutiner i Windows 7

På datorer med äldre operativsystem som 64-bitars Windows 7 är det relativt vanligt att man stöter på problem med att installera moderna drivrutiner för grafikkort eller annan ny hårdvara. Ett typiskt exempel är felet "Signeringscertifikaten är inte installerade. Installera de certifikat som krävs" när man försöker installera Nvidia- drivrutiner för GPU:er som GTX 1060 eller GTX 950.

I många fall, även om användaren inaktiverar drivrutinssignering vid start, fungerar inte drivrutinen efter omstart eftersom signeringspolicyn återaktiveras. Lösningar som att installera alla tidigare versioner av drivrutinen, använda alternativa installationsprogram (som Snappy Driver Installer), tillämpa SHA-2-stöduppdateringar (som KB3033929) eller ominstallera från Enhetshanteraren har provats utan framgång.

En praktisk lösning som har fungerat innebär att manuellt extrahera innehållet i installationsprogrammet för version 474.11 (den senaste WHQL-drivrutinen för Windows 7) till en mapp och, från Enhetshanteraren, uppdatera GPU-drivrutinen genom att välja alternativet att söka efter drivrutinen i datorn och välja den mappen. Samma metod kan misslyckas med senare versioner, till exempel 474.14, om installationsprogrammet inte känner igen INF-filerna som giltiga för det systemet.

Den här typen av fall illustrerar hur känslig balansen kan vara mellan nya drivrutiner, SHA-2-certifikat och operativsystem som inte stöds . Det blir allt svårare att installera – och hålla säkra – moderna drivrutiner på äldre plattformar som inte längre får uppdateringar eller säkerhetspatchar.

Hur man upptäcker och åtgärdar problem med felaktiga drivrutiner

Även om drivrutiner är korrekt signerade kan de bli skadade eller inkonsekventa av många anledningar: konflikter med andra program, skadlig kod, avbrutna installationer, misslyckade Windows-uppdateringar etc. När detta händer slutar den drabbade enheten vanligtvis att fungera eller fungerar oregelbundet.

Det första diagnostikverktyget är Enhetshanteraren . Om du högerklickar på Start-knappen och väljer motsvarande alternativ öppnas en komplett lista över all upptäckt maskinvara. Om en enhet har ett drivrutinsproblem markeras den med en gul varningsikon.

I dessa fall är ett första försök till en lösning att högerklicka på enheten, välja "Uppdatera drivrutin" och låta Windows söka efter en mer lämplig drivrutin, antingen lokalt eller via Windows Update. Om det inte fungerar kan du avinstallera enheten (behålla drivrutinsprogramvaran eller inte) och starta om den så att Windows försöker installera om den från grunden.

Dessutom innehåller Windows en felsökare för hårdvara och enheter i inställningspanelen, specifikt i avsnittet "Uppdatering och säkerhet" > "Felsök". Den här guiden skannar systemet efter oregelbundenheter och föreslår automatiska åtgärder för att återställa funktionaliteten hos vissa drivrutiner.

Om en specifik drivrutinsuppdatering har orsakat problemet kan det vara bra att använda alternativet "Återställ drivrutin" på fliken "Drivrutin" i enhetsegenskaperna, förutsatt att Windows behåller den tidigare versionen. Detta återställer den problematiska installationen och kan återställa systemstabiliteten.

Visa och analysera drivrutiner från tredje part som är installerade på Windows

För att få större kontroll över vad som är installerat på ditt system kan du använda tredjepartsverktyg som Nirsofts DriverView , som visar en detaljerad lista över alla drivrutiner som är laddade på din dator. Det är ett gratis, portabelt verktyg som avsevärt förenklar drivrutinsgranskning.

DriverView använder ett mycket enkelt färgkodningssystem: Microsoft-drivrutiner med giltiga digitala signaturer visas med vit bakgrund , medan tredjepartsdrivrutiner (från tillverkare eller ytterligare programvara) är markerade med rött. Detta hjälper till att snabbt identifiera vilka pusselbitar som inte är direkt beroende av operativsystemet.

Listan kan sorteras efter kolumner, till exempel efter "Företag" för att gruppera alla drivrutiner från samma företag. Dessutom innehåller Visa-menyn vanligtvis ett alternativ för att dölja alla Microsoft-drivrutiner och endast visa drivrutiner från tredje part, så att du kan fokusera på de som mest sannolikt orsakar konflikter.

Om du dubbelklickar på valfri post öppnas ett fönster med detaljerad information om drivrutiner : version, fullständig sökväg, beskrivning, tillverkare, uppladdningsdatum etc. När det gäller okända eller misstänkta drivrutiner hjälper dessa uppgifter till att avgöra om de är en del av ett program vi faktiskt använder eller om det är värt att undersöka dem ytterligare och till och med avinstallera dem.

Med tanke på denna översikt är det tydligt att drivrutinssignering och certifikat i Windows inte bara är en formalitet, utan en grundläggande komponent för att upprätthålla systemstabilitet och säkerhet. Att förstå hur drivrutiner signeras, vilka krav som varierar mellan Windows-versioner, vilka verktyg som finns för validering och hur man ska reagera när en drivrutin är osignerad eller misslyckas gör att vi kan få ut det mesta av vår hårdvara samtidigt som vi förblir vaksamma mot lågnivåhot.