Microsoft usa TPM contro pirateria Windows: attivazione KMS rivoluzionata

Microsoft prepara una modifica profonda al funzionamento di Key Management Service (KMS) il sistema usato da aziende, enti pubblici e grandi organizzazioni per attivare Windows senza collegare ogni singolo computer ai server cloud di Redmond. L’obiettivo dichiarato consiste nel legare l’infrastruttura KMS a una prova crittografica prodotta dall’hardware, rendendo molto più difficile trasformare un comune PC, un container o una macchina virtuale improvvisata in un falso server di attivazione.

La novità riguarda direttamente anche gli emulatori KMS, compresi progetti come py-kms e i servizi pubblici ai quali alcuni strumenti di attivazione non autorizzata inviano periodicamente le richieste di rinnovo. Non significa però che ogni metodo descritto in passato smetterà di funzionare da un giorno all’altro. Microsoft ha annunciato una transizione graduale: i primi messaggi di preparazione compariranno su Windows Server 2025 da agosto 2026, mentre l’attestazione hardware diventerà obbligatoria con la successiva versione di Windows Server.

La società guidata da Satya Nadella non intende eliminare KMS bensì conservarlo come servizio aziendale legittimo, aggiungendo una verifica capace di distinguere un host autorizzato da un software che si limita a riprodurne le risposte di rete.

Perché KMS può essere emulato con relativa facilità

KMS nasce per semplificare l’attivazione di grandi quantità di installazioni Windows e Office. In una rete aziendale, i client individuano normalmente il server attraverso un record DNS di tipo SRV oppure ricevono il suo indirizzo tramite configurazione manuale. La comunicazione utilizza per impostazione predefinita la porta TCP 1688 e un protocollo basato su chiamate RPC (Remote Procedure Call).

Il computer da attivare utilizza una GVLK, cioè una Generic Volume License Key pubblicata dalla stessa Microsoft. Non si tratta di una chiave che concede una licenza: serve soltanto a configurare Windows come client KMS. Il possesso della GVLK, quindi, non dimostra che l’utente abbia acquistato il diritto di usare il sistema operativo.

Il server KMS legittimo deve invece disporre di una chiave specifica dell’organizzazione, oggi indicata da Microsoft come CSVLK. L’amministratore attiva tale chiave presso Microsoft e il server può poi gestire localmente le richieste provenienti dai dispositivi coperti dal contratto di volume licensing.

Il protocollo tradizionale, tuttavia, concentra buona parte della fiducia nella risposta restituita dal server. Un emulatore come py-kms replica quel comportamento: ascolta sulla stessa porta, interpreta la richiesta del client e genera una risposta formalmente compatibile. Dal punto di vista di Windows, almeno finché non entra in gioco un ulteriore controllo, il servizio può apparire simile a un KMS autorizzato.

È proprio tale separazione fra identità dichiarata e identità verificata che Microsoft vuole ridurre: non basta più che un programma sappia “parlare la lingua di KMS”; il server dovrà anche produrre una prova legata a un componente hardware considerato attendibile.

Che cosa cambia con KMS Hardware Secured

La nuova architettura, presentata come KMS Hardware Secured, introduce l’attestazione basata su TPM. Il server KMS dovrà dimostrare sia la propria identità hardware sia l’integrità dell’ambiente nel quale opera. Microsoft potrà quindi verificare che la richiesta provenga da un dispositivo riconosciuto e che alcuni elementi rilevanti non abbiano subito alterazioni.

Il chip TPM 2.0, sul quale basa il suo funzionamento anche Secure Boot, è un componente crittografico, discreto oppure integrato nel processore o nel firmware, capace di generare chiavi private che non risultano esportabili come normali file. Può inoltre associare l’uso di una chiave a determinate misurazioni della piattaforma.

Durante l’avvio, firmware e sistema operativo registrano nei Platform Configuration Registers (PCR) del TPM le impronte crittografiche dei componenti caricati. Il meccanismo prende il nome di Measured Boot. Un servizio remoto può ricevere una dichiarazione firmata relativa a tali registri e valutare se il computer si trova nello stato atteso.

In pratica, l’attestazione permette di rispondere a due domande che il vecchio scambio KMS non affrontava in modo altrettanto solido: “questo host possiede davvero l’identità hardware dichiarata?” e “il software che gestisce l’attivazione opera in un ambiente compatibile con quello approvato?”. Copiare un certificato, clonare una macchina virtuale o riprodurre le risposte RPC non dovrebbe più bastare, perché la parte privata della prova resta vincolata al TPM.

Ad oggi, però, Microsoft non ha ancora pubblicato tutti i dettagli del protocollo, dei certificati coinvolti e delle condizioni esatte applicate alla validazione. Non sappiamo, per esempio, quali misurazioni saranno obbligatorie, come saranno gestite le sostituzioni hardware o quali eccezioni saranno previste per infrastrutture isolate. Parlare già oggi di blocco assoluto di qualunque emulatore sarebbe quindi prematuro.

I falsi server KMS pubblici sono il bersaglio più evidente

Molti attivatori non installano un server nella rete locale. Configurano invece Windows con una GVLK e indicano l’indirizzo di un KMS pubblico controllato da terzi. Il computer contatta tale server, riceve un’attivazione temporanea e ripete l’operazione prima della scadenza.

Nel funzionamento ufficiale, un’attivazione KMS resta valida per 180 giorni. Il client prova normalmente a rinnovarla ogni sette giorni; se non raggiunge il server entro il periodo previsto, perde lo stato di attivazione. È il motivo per cui i metodi definiti Online KMS devono “telefonare a casa” periodicamente.

L’attestazione TPM colpisce proprio la debolezza di tali servizi. Un operatore può oggi creare numerose istanze virtuali del software, spostarle fra server e pubblicarle su Internet. Con una radice di fiducia hardware, ogni host dovrebbe invece presentare credenziali verificabili e associate a una piattaforma approvata.

Che cosa devono fare le aziende prima dell’obbligo

Microsoft inizierà a mostrare messaggi di preparazione su Windows Server 2025 da agosto 2026. La fase iniziale sembra quindi pensata per raccogliere informazioni e segnalare configurazioni non idonee, non per interrompere immediatamente il servizio. L’obbligo arriverà con la versione successiva di Windows Server, della quale la società non ha ancora indicato pubblicamente nome commerciale e data definitiva.

Gli amministratori dovrebbero partire dall’inventario degli host KMS: versione del sistema operativo, tipo di macchina fisica o virtuale, stato del TPM, firmware, modalità UEFI e configurazione di Secure Boot. È utile controllare anche quali chiavi CSVLK risultano installate, quali edizioni vengono attivate e se l’host riceve richieste da segmenti di rete inattesi.

Il comando slmgr.vbs /dlv mostra dati estesi sul canale di licenza, sull’host configurato, sull’intervallo di rinnovo e sugli errori registrati. In ambienti complessi conviene raccogliere tali informazioni in modo centralizzato prima che compaiano avvisi di incompatibilità.

Chi utilizza macchine virtuali dovrà verificare con il produttore dell’hypervisor il supporto all’attestazione richiesta da Microsoft.

Al momento i client come Windows 10 e Windows 11, nelle varie edizioni, continueranno a seguire il vecchio schema senza cambiamenti per ciò che riguarda il supporto KMS.

Non è la fine immediata degli attivatori, ma una barriera concreta

L’uso del TPM non elimina automaticamente la pirateria di Windows. Esistono tecniche che non dipendono da un server KMS tradizionale: modifiche ai dati della Software Protection Platform, ticket di licenza manipolati, sfruttamento di vecchi percorsi di aggiornamento e attacchi contro le verifiche locali. Microsoft aveva già bloccato nel 2025 il metodo noto come KMS38, ma sono comparsi strumenti che dichiarano di intervenire a un livello diverso.

È quindi più corretto parlare della possibile fine degli emulatori KMS privi di un’identità hardware valida, non della fine di ogni attivazione non autorizzata. Il rafforzamento obbliga chi sviluppa tali strumenti a superare una barriera crittografica, compromettere host legittimi o cercare strade alternative. Tutte opzioni più fragili e più facili da revocare rispetto alla semplice esecuzione di uno script Python.