Algoritmo di decrittografia RollingCode

Dopo l’algoritmo di crittografia affrontato nell’articolo “Algoritmo di crittografia RollingCode”, altre parte importante della codifica RollingCode è quella che riguarda la decrittografia dell’informazione ricevuta.

 

Anche in questo caso la parte che esegue la decrittografia è stata concepita per poter essere implementata su microcontrollori aventi risorse molto limitate e proprio per questo motivo, anche  l’algoritmo di decrittografia non richiederà particolari risorse sia in termini di tempo di esecuzioni sia in termini computazionali. Anche questa parte prevede l’utilizzo della chiave a 64 bit utilizzata durante la crittografia e che permetterà di decifrare l’informazione criptata inviata dal trasmettitore.

 

Anche questo algoritmo, come per quello di crittografia, può essere schematizzato e riassunto dal seguente schema:

 

 

 

In questo caso il processo di decrittografia è composto essenzialmente da cinque parti, le prime tre simili al processo di crittografia, ossia generazione della chiave (sempre a partire da quella in possesso dalla sorgente e dal ricevitore) e esecuzione della crittografia dei dati da inviare, mentre le altre due si occupano di verificare se la procedura di decrittografia è stata eseguita nel modo corretto (confrontando i risultati ottenuti con la parte di codice non crittografata) e di recuperare il “Sync Counter”:

 

  1. come nella fase di crittografia, questa fase si occupa di eseguire il “padding” del “Serial Number” (indicato con “S.N.” nella figura) con i due “SEED”, ovvero vengono accodati ai 28 bit del “Serial Number” altri 4 bit contenenti il valore “2”, nel caso del “SEED1”, e il valore “6”, nel caso del “SEED2”, in modo da ottenere due word distinte da 32 bit (i bit vengono accodati dal bit più significativo del “Serial Number”).

Volendo prendere ancora l’esempio dell’articolo precedente, se consideriamo un “Serial Number” con il valore “0x5A5A5A5” avremo che nel primo caso atteniamo una word pari a  “0x25A5A5A5”, mentre nel secondo caso otteniamo una word di valore “0x65A5A5A5” (considerando una rappresentazione dei bit di tipo big-endian).

 

  1. anche per la decrittografia, in questa fase interviene la chiave a 64 bit che nello schema è chiamata con il nome “MANUFACTURER KEY”.

Questo procedimento utilizza il valore della chiave citata precedentemente e i valori ricavati con il passo precedente per ricavare, attraverso due applicazioni della routine di decrittografia “KEELOQ DECRYPT”, le due word da 32 bit (“CRIPTO KEY 1/2” e “CRIPTO KEY 2/2”) che unite insieme andranno a formare la chiave a 64 bit che verrà utilizzata nella fase di decrittografia dei dati.

Anche in questo caso, considerando una “MANUFACTORY KEY” con il valore “0x0011223344556677” e due valori “0x8899AABB” e “0xCCDDEEFF” per “CRIPTO KEY 1/2” e “CRIPTO KEY 2/2”, la chiave a 64 bit utilizzata nell’ultimo passaggio avrà il valore “0x8899AABBCCDDEEFF”.

Anche per questi esempi i valori utilizzati sono a scopo esemplificativo e quindi non hanno nessun riscontro con i risultati reali che si ottengono applicando l’algoritmo.

 

  1. questo passaggio è quello che esegue la decrittografia vera e propria dei dati ricevuti, ossia dando in ingresso alla routine di decrittografia “KEELOQ DECRIPT ” la chiave ricavata nei passaggi precedenti e i 32 bit criptati del codice ricevuto (nella figura indicati con “HOPPING PART”); in uscita si otterrà una word da 32 bit che sarà composta dal “Sync Counter”, “Serial Number”, il “Button Status” e i bit di “OVR” opportunamente combinati (vedere l’articolo “Codifica Rolling Code – Introduzione 1 di 5) e non criptati.

 

  1. questo passaggio è quello che si occupa di controllare se la decrittografia è stata eseguita nel modo corretto, infatti, andando a confrontare i primi 10 bit del “Serial Number” e i “Button Status” ricavati dalla decrittografia, con i medesimi ma dei bit ricevuti “in chiaro”, è possibile verificare se l’operazione di decrittografia è stata eseguita in modo corretto o meno. Un esito negativo di questo confronto può essere dovuto a degli errori durante le operazioni di decrittografia o alla ricezione di un codice “Rolling Code” criptato con una chiave differente da quella utilizzata dal nostro algoritmo.

 

  1. quest’ultima fase (non presente in figura) è quella che si occupa semplicemente di recuperare il “Sync Counter” per poterlo confrontare con il contatore memorizzato dal ricevitore nella ricezione precedente (argomentazione affrontata nell’articolo “Introduzione alla codifica RollingCode).

 

Anche in questo caso i passaggi vengono implementati con delle semplici operazioni sui bit, che possono essere eseguite con semplicità e in poco tempo anche da microcontrollori con risorse limitate.

 

Una volta terminato l’algoritmo di crittografia si procederà alla verifica del “Sync Counter” e quindi all’esecuzione o meno delle operazioni che dovranno essere svolte dal ricevitore (per la procedura di verifica del “Sync Counter” vedere l’articolo “Introduzione alla codifica RollingCode).

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend