Condividi tramite


Firma Authenticode per sviluppatori di giochi

L'autenticazione dei dati è sempre più importante per gli sviluppatori di giochi. Windows Vista e Windows 7 hanno una serie di funzionalità, ad esempio i controlli genitori, che richiedono che i giochi siano firmati correttamente per garantire che nessuno abbia manomesso i dati. Microsoft Authenticode consente agli utenti finali e al sistema operativo di verificare che il codice del programma provenga dal proprietario legittimo e che non sia stato alterato o danneggiato accidentalmente. Questo articolo illustra come iniziare a autenticare il gioco e come integrare l'autenticazione in un processo di compilazione giornaliero.

Nota

A partire dal 1° gennaio 2016, Windows 7 e versioni successive non considerano più attendibile alcun certificato di firma del codice SHA-1 con una data di scadenza del 1° gennaio 2016 o versione successiva. Per altre informazioni, vedere Imposizione di Windows per la firma del codice Authenticode e il timestamp.

Background

I certificati digitali vengono usati per stabilire l'identità dell'autore. I certificati digitali vengono emessi da terze parti attendibili note come Autorità di certificazione (CA), ad esempio VeriSign o Thawte. L'autorità di certificazione è responsabile della verifica che il proprietario non stia sostenendo un'identificazione falsa. Dopo l'applicazione a una CA per un certificato, gli sviluppatori commerciali possono aspettarsi una risposta all'applicazione in meno di due settimane.

Dopo che la CA decide di soddisfare i criteri, genera un certificato di firma del codice conforme a X.509, il formato di certificato standard del settore creato dall'Unione internazionale delle telecomunicazioni, con estensioni versione 3. Questo certificato identifica l'utente e contiene la chiave pubblica. Viene archiviato dalla CA per riferimento e viene fornita una copia elettronicamente. Allo stesso tempo, si crea anche una chiave privata, che è necessario mantenere al sicuro e che non è necessario condividere con nessuno, anche la CA.

Dopo aver ottenuto una chiave pubblica e privata, è possibile iniziare a distribuire il software firmato. Microsoft fornisce strumenti per eseguire questa operazione in Windows SDK. Gli strumenti usano un hash unidirezionale, producono un digest a lunghezza fissa e generano una firma crittografata con una chiave privata. Combinano quindi la firma crittografata con il certificato e le credenziali in una struttura nota come blocco di firma e la incorporano nel formato di file dell'eseguibile. Qualsiasi tipo di file binario eseguibile può essere firmato, inclusi DLL, file eseguibili e file CAB.

La firma può essere verificata in diversi modi. I programmi possono chiamare la funzione CertVerifyCertificateChainPolicy e SignTool (signtool.exe) possono essere usati per verificare una firma dal prompt della riga di comando. Esplora risorse include anche una scheda Firme digitali in Proprietà file che visualizza ogni certificato di un file binario firmato. La scheda Firme digitali viene visualizzata solo in Proprietà file per i file firmati. Inoltre, un'applicazione può essere autocertificata usando CertVerifyCertificateChainPolicy.

La firma Authenticode non è utile solo per l'autenticazione dei dati da parte degli utenti finali, ma è necessaria anche per l'applicazione di patch di account utente limitati e da controlli genitori in Windows Vista e Windows 7. Inoltre, le tecnologie future nei sistemi operativi Windows possono anche richiedere che il codice sia firmato, quindi è vivamente consigliato che tutti gli sviluppatori professionisti e dilettanti acquisiscono un certificato di firma del codice da una CA. Altre informazioni su come eseguire questa operazione sono disponibili più avanti in questo articolo in Uso di un'autorità di certificazione attendibile.

Il codice del gioco, i patcher e i programmi di installazione possono sfruttare ulteriormente la firma authenticode verificando che i file siano autenticati nel codice. Questo può essere usato per la sicurezza di rete generale e anti-inganno. Il codice di esempio per verificare se un file è firmato è reperibile qui: Esempio di programma C: Verifica della firma di un file PE e codice di esempio per controllare la proprietà di un certificato di firma in un file firmato è disponibile qui: How To Get Information from Authenticode Signed Executables (Come ottenere informazioni da file eseguibili firmati Authenticode).

Introduzione

Per iniziare, Microsoft fornisce strumenti con Visual Studio 2005 e Visual Studio 2008 e in Windows SDK per eseguire e verificare il processo di firma del codice. Dopo aver installato Visual Studio o Windows SDK, gli strumenti descritti in questo articolo tecnico si trovano in una sottodirectory dell'installazione, che può includere una o più delle opzioni seguenti:

  • %SystemDrive%\Programmi\Microsoft Visual Studio 8\SDK\v2.0\Bin
  • %SystemDrive%\Programmi\Microsoft Visual Studio 8\VC\PlatformSDK\Bin
  • %SystemDrive%\Programmi\Microsoft Visual Studio 9.0\SmartDevices\SDK\SDKTools\
  • %SystemDrive%\Programmi\Microsoft SDKs\Windows\v6.0A\bin\

Gli strumenti seguenti sono i più utili per la firma del codice:

Strumento di creazione certificati (MakeCert.exe)

Genera un certificato X.509 di test, come file .cer, che contiene la chiave pubblica e una chiave privata, come file con estensione pvk. Questo certificato è solo a scopo di test interno e non può essere usato pubblicamente.

pvk2pfx.exe

Crea un file con estensione pfx (Personal Information Exchange) da una coppia di file .cer e pvk. Il file pfx contiene sia la chiave pubblica che quella privata.

SignTool (SignTool.exe)

Firma il file usando il file pfx. SignTool supporta la firma di file DLL, file eseguibili, file di Windows Installer (.msi) e file cab (.cab).

Nota

Durante la lettura di altre documentazione, è possibile trovare riferimenti a SignCode (SignCode.exe), ma questo strumento è deprecato e non è più supportato. Usare invece SignTool.

 

Uso di un'autorità di certificazione attendibile

Per ottenere un certificato attendibile, è necessario applicare a un'autorità di certificazione (CA), ad esempio VeriSign o Thawte. Microsoft non consiglia alcuna CA rispetto a un'altra, ma se si vuole integrare nel servizio Segnalazione errori Windows (WER), è consigliabile usare VeriSign per rilasciare il certificato, perché l'accesso al database WER richiede un account WinQual che richiede un ID VeriSign. Per un elenco completo delle autorità di certificazione di terze parti attendibili, vedere Microsoft Root Certificate Program Members.For a complete list of trusted third-party certificate authorities, see Microsoft Root Certificate Program Members. Per altre informazioni sulla registrazione con WER, vedere "Introducing Segnalazione errori Windows" in ISV Zone(Introduzione alla Segnalazione errori Windows) nella zona ISV.

Dopo aver ricevuto il certificato dalla CA, è possibile firmare il programma usando SignTool e rilasciare il programma al pubblico. Tuttavia, è necessario prestare attenzione a proteggere la chiave privata, contenuta nei file con estensione pfx e pvk. Assicurarsi di mantenere questi file in una posizione sicura.

Esempio di utilizzo di un certificato di test

I passaggi seguenti illustrano la creazione di un certificato di firma del codice a scopo di test, seguito dalla firma di un programma di esempio Direct3D (denominato BasicHLSL.exe) con questo certificato di test. Questa procedura crea rispettivamente .cer e file con estensione pvk, ovvero le chiavi pubbliche e private, che non possono essere usate per la certificazione pubblica.

In questo esempio viene aggiunto anche un timestamp alla firma. Un timestamp impedisce che la firma diventi non valida alla scadenza del certificato. Il codice firmato ma privo di timestamp non verrà convalidato dopo la scadenza del certificato. Pertanto, tutto il codice rilasciato pubblicamente deve avere un timestamp.

Per creare un certificato e firmare un programma

  1. Creare un certificato di test e una chiave privata usando lo strumento di creazione del certificato (MakeCert.exe).

    Nell'esempio della riga di comando seguente viene specificato MyPrivateKey come nome file per il file di chiave privata (con estensione pvk), MyPublicKey come nome file del certificato (.cer) e MySoftwareCompany come nome del certificato. Rende anche autofirmato il certificato, in modo che non abbia un'autorità radice non attendibile.

    MakeCert /n CN=MySoftwareCompany /r /h 0 /eku "1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.13" /e 12-31-2020 /sv MyPrivateKey.pvk MyPublicKey.cer
    
  2. Creare un file pfx (Personal Information Exchange) dal file di chiave privata (con estensione pvk) e dal file di certificato (.cer) usando pvk2pfx.exe.

    Il file pfx combina le chiavi pubbliche e private in un singolo file. L'esempio della riga di comando seguente usa i file con estensione pvk e .cer del passaggio precedente per creare il file pfx denominato MyPFX con la password your_password:

    pvk2pfx.exe -pvk MyPrivateKey.pvk -spc MyPublicKey.cer -pfx MyPFX.pfx -po your_password
    
  3. Firmare il programma con il file Personal Information Exchange (pfx) usando SignTool.

    È possibile specificare diverse opzioni nella riga di comando. L'esempio della riga di comando seguente usa il file pfx del passaggio precedente, fornisce your_password come password, specifica BasicHLSL come file da firmare e recupera un timestamp da un server specificato:

    signtool.exe sign /fd SHA256 /f MyPFX.pfx /p your_password /v /t URL_to_time_stamp_service BasicHLSL.exe
    

    Nota

    L'URL del servizio timestamp viene fornito dalla CA ed è facoltativo per il test. È importante che la firma di produzione includa un'autorità di timestamp valida o che la firma non venga convalidata alla scadenza del certificato.

     

  4. Verificare che il programma sia firmato tramite SignTool.

    L'esempio della riga di comando seguente specifica che SignTool deve tentare di verificare la firma in BasicHLSL.exe usando tutti i metodi disponibili fornendo un output dettagliato:

    signtool.exe verify /a /v BasicHLSL.exe
    

    In questo esempio SignTool deve indicare che il certificato è allegato, mentre indica anche che non è attendibile, poiché non viene emesso da una CA.

  5. Considerare attendibile il certificato di test.

    Per i certificati di test è necessario considerare attendibile il certificato. Questo passaggio deve essere ignorato per i certificati forniti da una CA, perché tali certificati verranno considerati attendibili per impostazione predefinita.

    Solo nei computer in cui si vuole considerare attendibile il certificato di test, eseguire quanto segue:

    certmgr.msc
    

    Fare quindi clic con il pulsante destro del mouse su Autorità di certificazione radice attendibili e scegliere Tutte le attività | Importazione. Passare quindi al file con estensione pfx creato e seguire i passaggi della procedura guidata, inserendo il certificato nelle autorità di certificazione radice attendibili.

    Al termine della procedura guidata, è possibile avviare il test con il certificato attendibile in tale computer.

Integrazione dell'accesso al codice nel sistema di compilazione giornaliero

Per integrare l'accesso del codice a un progetto, è possibile creare un file batch o uno script per eseguire gli strumenti da riga di comando. Dopo aver compilato il progetto, eseguire SignTool con le impostazioni appropriate (come illustrato nel passaggio 3 dell'esempio).

Prestare particolare attenzione nel processo di compilazione per assicurarsi che l'accesso ai file con estensione pfx e pvk sia limitato al minor numero possibile di computer e utenti. Come procedura consigliata, gli sviluppatori devono firmare il codice solo usando il certificato di test fino a quando non sono pronti per la spedizione. Anche in questo caso, la chiave privata (con estensione pvk) deve essere mantenuta in una posizione protetta, ad esempio una stanza sicura o bloccata, e idealmente su un dispositivo crittografico, come una smart card.

Un altro livello di protezione viene fornito tramite Microsoft Authenticode per firmare il pacchetto Windows Installer (MSI). Ciò consente di proteggere il pacchetto MSI da manomissioni e danneggiamenti accidentali. Per altre informazioni su come firmare i pacchetti con Authenticode, vedere la documentazione relativa allo strumento di creazione MSI.

Revoca

Nel caso in cui la sicurezza della chiave privata sia compromessa o che alcuni eventi correlati alla sicurezza eseguano il rendering di un certificato di firma codice non valido, lo sviluppatore deve revocare il certificato. Non indebolirebbe l'integrità dello sviluppatore e l'efficacia del codice di firma. Una CA può anche emettere una revoca con un orario specifico; il codice firmato con un timestamp prima dell'ora di revoca verrà comunque considerato valido, ma il codice con un timestamp successivo non sarà valido. La revoca dei certificati influisce sul codice in tutte le applicazioni firmate con il certificato revocato.

Driver di firma del codice

I driver possono e devono essere firmati da Authenticode. I driver in modalità kernel hanno requisiti aggiuntivi: le edizioni a 64 bit di Windows Vista e Windows 7 impediranno l'installazione di tutti i driver in modalità kernel non firmati e tutte le versioni di Windows presenteranno un messaggio di avviso quando un utente tenta di installare un driver non firmato. Inoltre, gli amministratori possono impostare Criteri di gruppo per impedire l'installazione di driver non firmati in Microsoft Windows Server 2003, Windows XP Professional x64 Edition e edizioni a 32 bit di Windows Vista e Windows 7.

Molti tipi di driver possono essere firmati con una firma attendibile Microsoft, come parte del Programma di certificazione Windows di Windows Hardware Quality Labs (WHQL) o del Programma di firma non classificato (in precedenza denominato Driver Reliability Signature), che consente al sistema di considerare completamente attendibili questi driver e di installarli anche senza credenziali amministrative.

Come minimo, i driver devono essere firmati con Authenticode, perché i driver non firmati o autofirmati (ovvero firmati con un certificato di test) non riusciranno a essere installati in molte piattaforme basate su Windows. Per altre informazioni sulla firma di driver e codice e sulle funzionalità correlate, vedere Requisiti di firma dei driver per Windows in Windows Hardware Developer Central.

Riepilogo

L'uso di Microsoft Authenticode è un processo semplice. Dopo aver ottenuto un cer e creato una chiave privata, è una semplice questione di utilizzo degli strumenti forniti da Microsoft. È quindi possibile abilitare funzionalità importanti in Windows Vista e Windows 7, ad esempio i controlli genitori, e informare i clienti che il prodotto proviene direttamente dal suo proprietario legittimo.

Ulteriori informazioni

Per altre informazioni sugli strumenti e sui processi correlati al codice di firma, vedere i collegamenti seguenti: