4 Decimalization Attack

 

4.1 Introduzione

 

Il primo ATM fu l’IBM 3624s, introdotto negli Stati Uniti circa nel 1980, e i metodi da esso usati per la generazione del PIN sono tutt'ora alla base dei nuovi algoritmi di generazione dei pin.                                                                                                                                                                                   

Il perno su cui si basa la generazione dei PIN è la tavola di decimalizzazione che associa ad un valore esadecimale un numero decimale.  Nel paragrafo 4.2 illustreremo la tecnica per la generazione di PIN più diffusa. La tecnica IBM 3624-Offset fu progettata in modo che gli ATM offline fossero capaci di verificare i PIN dei clienti senza avere bisogno della memorizzazione dei dati di un cliente. Poi presenteremo i vari attacchi che sono stati portati alla tavola di decimalizzazione. Dopodichè nel paragrafo 4.3 vedremo perché questa tavola non è ritenuta sicura da molti "Hardware Security Module"(modulo di sicurezza hardware, che dispone di particolari API progettate in modo da rispondere solamente con YES/NO alla prova dell'inserimento del PIN di un cliente), affrontando in maniera più approfondita,  i vari attacchi alla tavola di decimalizzazione. Per primo presenteremo un semplice schema "statico" composto da 2 passi,  dopodiché presenteremo uno schema "adattivo" che sarà capace, tramite l'uso di un albero binario di ricerca e Pin di prova cifrati; di ridurre il numero di ipotesi necessarie e infine presenteremo uno schema adattivo che usa l'offset del PIN, nell'ipotesi che l'assalitore non conosca nessun PIN di prova.    

 

4.2 Generazione PIN 

 

L’IBM 3624-Offset e il metodo di generazione del PIN

Il metodo IBM 3624-Offset fu sviluppato per supportare la prima generazione di ATM e fu largamente adoperato. Il metodo fu progettato in modo che gli ATM offline sarebbero stati capaci di verificare i PIN dei clienti senza avere bisogno di memorizzare i conti da manipolare in un database di record. Inoltre, fu sviluppato uno schema dove i PIN dei clienti potevano essere calcolati a partire dal  numero di conto del cliente stesso a partire da una cifratura con chiave segreta. Il numero di conto è reso disponibile al cliente su scheda magnetica, quindi l'ATM ha bisogno solo di immagazzinare in modo sicuro una sola chiave crittografica. Un esempio del calcolo del PIN è mostrato in figura 4.2. Il numero di conto è rappresentato usando cifre ASCII, e poi interpretato come un input esadecimale per l'algoritmo di cifratura DES. In seguito viene fatta la cifratura con la chiave segreta “PIN generation”; l’output è convertito in esadecimale e solo le prime quattro cifre non vengono scartate. Inoltre poiché le quattro cifre potrebbero contenere le cifre ‘A’-‘F’, non disponibili su una tastiera numerica standard, e che quindi potrebbero confondere i clienti, esse sono mappate con cifre decimali usando una “Tavola di decimalizzazione” (Figura 4.1).

                                                                                                                    

        Figura 4.1 - Tavola di decimalizzazione

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

                                                                                              

                                                                                           

                                 

                                   

           Numero di conto           4  5 5  6   2 3 8 5  7 7 5 3   2 2 3 9

           Cifratura DES                3 F 7 C   2 2 0 1  0 0 CA  8 A B 3

 

           Scarto cifre non usate e prendo  3F7C

           Mapping con la tavola di decimalizzazione  3572            

 

           Passi per cambiare il PIN iniziale                                         

 

           PIN iniziale         3572 (+)

           Offset                4244 (=)

           New PIN            7816

                   Figura 4.2-IBM 3624-offset Metodo di generazione del PIN

 

  

Nell’esempio il PIN di 3F7C diventa 3572. Per permettere ai possessori della carta di cambiare il proprio PIN, si somma al PIN originale un Offset (associato univocamente ad ogni numero di conto), generando così un nuovo PIN. Quando un ATM verifica un PIN, sottrae semplicemente l'offset e confronta il risultato ottenuto con il PIN iniziale.

 

Moduli API di sicurezza hardware

I centri di controllo delle banche e gli ATM usano Hardware Security Module (HSM), che offrono protezione da possibili attacchi portati da impiegati corrotti della banca. Un HSM è un processore su cui gira un software che offre servizi relativi alla crittografia e alla sicurezza. L’API dell’HSM contiene operazioni per generare e  verificare i PIN, decifra le chiavi di zona quando vengono scambiate tra banche, e supporta un'ampia gamma di funzioni per la gestione della chiave. Qualunque impiegato della banca che ha accesso al computer HSM, può effettuare operazioni come la verifica di un PIN, mentre altre operazioni, come il settaggio di nuove chiavi di cifratura, possono essere effettuate solo con l'autorizzazione da parte di più impiegati fidati. Un esempio di funzione per la verifica del PIN è mostrato in figura 4.5.

 

           Encrypted_PIN_Verify(                              

                    A_RETRES , A_ED ,                              // return codes 0=yes 4,19=no

                    trial_PIN_kek_in , PINver_key ,              // encryption keys for enc inputs

                    (UCHAR*) "3624 " "NONE      "             // PIN block format

                    "      F"                                                  // PIN block pad digit

                    (UCHAR*) "                     ",

                    trial_PIN ,                                               // Encrypted PIN Block

                    I_LONG(2) ,

                    (UCHAR*) "IBM-PINO" "PADDIGIT"  , // PIN verification method

                    I_LONG(4)  ,                                          // number of PIN digits = 4

                    "0123456789012345"                              // Decimalization table

                    "0123456789012     "                               // PAN_Data

                    "0000                     "                               // offset data

                                                       );

                                       Figura 4.3-Codice di esempio per Verifica del PIN

 

 

Gli input cruciali a Encrypted_PIN_Verify sono la tavola di decimalizzazione, il PAN_Data (che contiene il numero personale dell'account)  e l’Encrypted PIN Block (EPB). I primi due sono forniti in chiaro e sono il punto debole di questo sistema di sicurezza.

Oltre ai parametri di input, su citati, tutti gli altri dati presenti nella funzione Encrypted_PIN_Verify dipendono dal sistema informatico della banca, quindi non dovrebbero interessare un ipotetico attaccante. Come si può notare anche dai commenti in figura, questi dati sono le chiavi di cifratura, il formato del PIN_block, il tipo del metodo di verifica da usare, il numero di cifre che compongono il codice PIN e l'Offset.

Gli altri valori sono delle costanti (A_RETRES e A_ED) rappresentanti gli outputs della funzione, ossia i codici 0 o 4,19 corrispondenti rispettivamente a una risposta affermativa e negativa alla richiesta di verifica [8].

 

 

4.3 Attacchi alla tavola di decimalizzazione

Supponiamo che un impiegato di banca malintenzionato, si sia impossessato di un PAN_Data e tramite la funzione Encrypted_PIN_Verify può effettuare vari attacchi passando come input la tavola di decimalizzazione, il PAN_Data, l'offset e l'EPB. Alcuni circuiti bancari permettono l'inserimento di PIN di prova in chiaro quando non viene utilizzata la tavola di decimalizzazione. In questo caso è necessario abilitare il comando CCA Clear_PIN_Encrypt, che creerà un EPB a partire dal PIN scelto. Quando l'inserimento del PIN in chiaro non è disponibile per l'attaccante, egli può solamente inserire il PIN in un ATM reale e quindi intercettare l'EPB corrispondente ad ogni tentativo. In ogni caso l'attaccante può solamente ottenere blocchi di PIN cifrati; egli sarà quindi costretto a passare, come argomento della funzione Encrypted_PIN_Verify, gli EPB di prova che intende utilizzare per l'attacco.

Considereremo tre schemi d'attacco; dopo un certo numero di iterazioni questa funzione sarà in grado di fornirci le cifre che sono contenute nel PIN originale; a tal punto non resterà che trovare il corretto ordine d'immissione.

Infine siamo passati all'analisi di un nuovo caso dove  abbiamo a disposizione un EPB ma il possessore del conto ha cambiato il suo PIN sfruttando il proprio offset; sarà quindi necessario effettuare alcune modifiche agli algoritmi precedenti in maniera tale da considerare anche l'Offset usato per manipolare il PIN originale.

 

Schema iniziale

 

Lo schema iniziale consiste di 2 passi. Il primo passo determina quali cifre sono presenti nel PIN. Il secondo passo consiste nel trovare tutti i possibili PIN composti da queste cifre.

Poniamo Dorig come tavola di decimalizzazione originale. Per una data cifra i, consideriamo una tavola di decimalizzazione binaria Di che gode della seguente proprietà: Di ha 1 nella posizione x se e solo se Dorig ha la cifra i in quella posizione. In altre parole:

 

                               Di[x] = 1 se Dorig [x] = i

                               Di[x] = 0 altrimenti       

 

Ad esempio, per una tavola standard : 

 

Dorig =

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

                                                                                              

                                                                                           

                                 

 

D3  =

0

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

0

0

0

1

0

0

0

0

0

0

0

0

0

1

0

0

                                                                                              

                                                                                           

                        

 

Nella prima fase, confrontiamo il PIN originale mappato con la tavola di decimalizzazione Di e il PIN di prova 0000 tramite la funzione Encypted_PIN_Verify. Il test fallisce quando il PIN originale contiene la cifra i. Ad esempio se il PIN è 7816  e la tavola di decimalizzazione è D7 la funzione farà un matching tra 1000 e e 0000. In questo modo, effettuando al più 10 confronti, è possibile determinare  tutte le cifre che compongono il PIN originale.

Nella seconda fase dell’attacco, per ottenere il PIN ricercato, è necessario provare tutte le possibili combinazioni delle cifre trovate nella prima fase. Il numero di combinazioni possibili è strettamente legato al numero di cifre differenti contenute nel PIN. La seguente tabella mostra tutte le possibili combinazioni necessarie a trovare un PIN quando esso è composto da una, due, tre o quattro cifre differenti.

 

 

Simboli che compongono il PIN 

 Possibilità

A

AAAA(1)

AB

ABBB(4), AABB(6), AAAB(4)

ABC

AABC(12), ABBC(12), ABCC(12)

ABCD

ABCD(24)

                                                        

Dalla tavola si evince che, quando il PIN da trovare è composta da 3 differenti cifre (3° riga della tabella), tutte le possibili combinazioni di PIN formati da queste cifre, sono 36 (Figura 4.4), e rappresentano il caso peggiore per l'attaccante. Inoltre è necessario sommare a queste 36 ipotesi le 10 ipotesi necessarie per determinare tutte le cifre che compongono il PIN ottenute nella fase precedente, per cui, nel caso peggiore, questo approccio necessiterà di 46 tentativi.

 

AABC

ABCA

ABAC

ACBA

CBAA

BCAA

BACA

CABA

CAAB

BAAC

ACAB

AACB

BBAC

BACB

BABC

BCAB

CABB

ACBB

ABCB

CBAB

CBBA

ABBC

BCBA

BBCA

CCAB

CABC

CACB

CBAC

BACC

ABCC

ACBC

BCAC

BCCA

ACCB

CBCA

CCBA

4.4-Tabella delle combinazioni con 3 cifre differenti

 

Schema adattivo

 

Siccome la funzione analizzata in precedenza ritorna solo valori affermativi o negativi, possiamo utilizzare questi risultati in un albero di ricerca binario. Ogni nodo v contiene un confronto tra porig mappato con la tavola di decimalizzazione Dv e un PIN pv. Si parte dal nodo radice e si percorre l’albero lungo il percorso determinato dai risultati dei confronti effettuati.

Assumiamo che porig sia il PIN originale cioè un quartetto di cifre esadecimali; ad ogni nodo controlliamo se vale il confronto Dv(porig) = pv, cioè controlliamo se porig, mappato con la tavola di decimalizzazione Dv, sia uguale a pv. Se il confronto è positivo ci spostiamo sul figlio sinistro, altrimenti ci spostiamo sul figlio destro.

Consideriamo lo schema iniziale come esempio. Per semplicità assumiamo che il PIN originale consista di due cifre binarie, e la tavola di decimalizzazione mappi 0 con 0 ed 1 con 1:

 

Dorig =

0

1

0

1

 

La figura 4.5 mostra l’albero di ricerca corrispondente a questa configurazione.

 

Figura 4.6 L’albero di ricerca per lo schema statico

 

Partiamo dalla radice e verifichiamo se la cifra 0 è presente nel PIN finale, se lo è dobbiamo determinarne la posizione, quindi ci spostiamo sul figlio destro altrimenti sappiamo che nel PIN finale non è presente uno 0, quindi p = 11. Ora se il primo test è fallito andiamo a verificare la posizione dello 0, quindi la tavola di decimalizzazione cambierà in D01  e il PIN di prova sarà 10; se il test non fallisce allora p = 10, altrimenti 0 sarà in un'altra posizione. Il passo finale quindi sarà in grado di determinare se p = 01 o p = 00 che sono le ultime possibilità rimaste.

Lo svantaggio maggiore dello schema statico è che il numero di confronti necessari dipende strettamente da PIN originale porig. Ad esempio, il metodo necessita di soli 9 tentativi per porig = 9999 (perché, dopo aver accertato che le cifre da 1 ad 8 non appaiono in porig, 9999 è l’unica possibilità rimanente), ma vi sono casi in cui sono richieste 46 ipotesi.

Ora illustreremo un esempio dell'algoritmo adattivo per trovare un PIN di quattro cifre utilizzando la tavola di decimalizzazione modificata Dv, i PIN di prova cifrati 0000,0001,0010,0100,1000,1111 e porig.

Con l'algoritmo adattivo possiamo associare ad ogni nodo v nell’albero una lista Pv di PIN. In particolare, la lista associata al nodo radice contiene tutti i PIN, 164, mentre per ogni nodo interno: se è figlio sinistro, la lista associata contiene i PIN del padre che soddisfano il confronto, altrimenti, se è figlio destro, la lista associata contiene i PIN del padre che non soddisfano il confronto. Infine la lista di ogni foglia conterrà un solo elemento, cioè un PIN originale porig.

Un metodo per produrre un albero di ricerca perfetto, che richieda cioè il più piccolo numero possibile di confronti nel caso peggiore, è considerare tutti i possibili alberi di ricerca e scegliere il migliore. Ma questo approccio è chiaramente inefficiente a causa della complessità esponenziale di tempo rispetto al numero di possibili PIN e tavole di decimalizzazione.

Sostituiamo la ricerca esaustiva con la seguente euristica: scegliamo i valori di Dv e di pv per ogni nodo v nel seguente modo: assumiamo che Pv sia la lista associata ad ogni nodo v; scegliamo quella per cui la probabilità di Dv(p) = pv, (ove  p Є Pv), sia quanto più vicina ad 1/2. Ciò assicura che i sottoalberi di destra e di sinistra siano approssimativamente della stessa dimensione, rendendo l’albero bilanciato. Con questa euristica otterremo che lista dei PIN di un nodo interno conterrà circa la metà dei PIN del nodo padre.

Questo schema può essere ulteriormente migliorato considerando la seguente osservazione: ricordando che il PIN originale porig è un numero di quattro cifre esadecimali, non è necessario determinarle esattamente. Tutto ciò di cui abbiamo bisogno è stabilire il valore di p = Dorig (porig). Ad esempio, non è necessario distinguere tra 012D e ABC3, poiché per entrambi p = 0123. Possiamo quindi costruire l’albero di ricerca basandoci sul valore di p invece che di porig. In generale è necessario che ogni tavola di decimalizzazione Dv soddisfi la seguente proprietà; per ogni coppia di cifre esadecimali x ed y, deve valere che: Dorig[x] = Dorig[y] => Dv[x] = Dv[y]. Alla luce di queste considerazioni, il numero di possibili PIN si riduce da 164 a 104.

 

Consideriamo l'esecuzione dell'algoritmo adattivo per il PIN originale porig  = 3491. Scegliamo ad ogni passo una opportuna tavola di decimalizzazione e un opportuno PIN di prova cifrato, adattandoli ai risultati ottenuti volta per volta. In questo modo cerchiamo di ottenere un albero di ricerca il più bilanciato possibile.

Il numero iniziale di possibili PIN è 104 = 10000; nel nostro esempio, scegliamo come tavola di decimalizzazione iniziale :

 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1 0 0 0 0 0 1 0 0 0 1 0 0 0 0 0

 

 

 

 

e come PIN di prova: p = 0000.

A questo punto, confrontiamo il PIN di prova cifrato p, con il risultato ottenuto mappando il PIN originale 3491 con la tavola di decimalizzazione scelta, ovvero 0000; se il confronto è positivo, sappiamo che il PIN originale non contiene 0 e 6, ossia le cifre corrispondenti alla posizione degli 1 nella tavola di decimalizzazione. Quindi dalla radice ci spostiamo sul figlio destro, passando da 10000 possibili PIN a 4096. Proponiamo ora uno schema per riassumere, per ogni posizione, quali sono le possibili cifre che apparterranno al PIN finale.

 

1a Posizione 2a Posizione 3a Posizione 4a Posizione
1-2-3-4-5-7-8-9 1-2-3-4-5-7-8-9 1-2-3-4-5-7-8-9 1-2-3-4-5-7-8-9

 

Per il secondo confronto utilizziamo come tavola di decimalizzazione:

 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0

 

 

 

 

e il PIN di prova cifrato: p=0000.

A questo punto il risultato negativo del confronto, tra il PIN di prova cifrato p, con il risultato ottenuto mappando il PIN originale 3491 con la tavola di decimalizzazione scelta, ovvero 0001; ci dirà che: la cifra 1 è contenuta con certezza nel PIN originale ma il nostro schema non ci informa ancora sull'esatta posizione . Dal nodo corrente ci spostiamo sul figlio destro, passando da 4096 possibili PIN a 1695.

 

Per il terzo confronto utilizziamo la tavola di decimalizzazione:

 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 1 1 1 1 1 0 0 0 0 0 1 1 1 1 1

 

 

 

 

e il PIN di prova cifrato: 1111.

Il risultato negativo del confronto, tra il PIN di prova cifrato p, con il risultato ottenuto mappando il PIN originale 3491 con la tavola di decimalizzazione scelta, ovvero 1101; ci dirà che: si devono eliminare i PIN che sono composti esclusivamente dalle cifre 1,2,3,4,5. Dal nodo corrente ci spostiamo sul figlio destro, passando da 1695 possibili PIN a 1326.

 

1a Posizione 2a Posizione 3a Posizione 4a Posizione
1-2-3-4-5-7-8-9 1-2-3-4-5-7-8-9 1-2-3-4-5-7-8-9 1-2-3-4-5-7-8-9

 

 

Per il quarto confronto utilizziamo la tavola di decimalizzazione:

 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0

 

 

 

 

e il PIN di prova cifrato: 0000.

Il risultato positivo del confronto, tra il PIN di prova cifrato p, con il risultato ottenuto mappando il PIN originale porig con la tavola di decimalizzazione scelta, ovvero 0000; ci dirà che: la cifra 7 non è presente nel PIN finale. Dal nodo corrente ci spostiamo sul figlio sinistro, passando da 1326 possibili PIN a 736.

 

1a Posizione 2a Posizione 3a Posizione 4a Posizione
1-2-3-4-5-8-9 1-2-3-4-5-8-9 1-2-3-4-5-6-8-9 1-2-3-4-5-8-9

 

Per il quinto confronto utilizziamo la tavola di decimalizzazione:

 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0

 

 

 

 

e il PIN di prova cifrato: 0000.

Il risultato positivo del confronto, tra il PIN di prova cifrato p, con il risultato ottenuto mappando il PIN originale 3491 con la tavola di decimalizzazione scelta, ovvero 0000; ci dirà che: la cifra 8 non è presente nel PIN finale. Dal nodo corrente ci spostiamo sul figlio sinistro, passando da 736 possibili PIN a 302.

 

1a Posizione 2a Posizione 3a Posizione 4a Posizione
1-2-3-4-5-9 1-2-3-4-5-9 1-2-3-4-5-9 1-2-3-4-5-9

 

Procedendo in questo modo saremo in grado di determinare il PIN corretto con un numero di confronti inferiore allo schema statico(figura 4.7).

 

N° di tentativi

Numero di PIN Possibili Tavola di Decimalizzazione Dv PIN di prova cifrati Dv(porig) pv=Dv(porig)
1 10000 1000001000100000 0000 0000 Si
2 4096 0100000000010000 0000 0001 No
3 1695 0111110000011111 1111 1101 No
4 1326 0000000100000000 0000 0000 Si
5 736 0000000010000000 0000 0000 Si
6 302 0010000000001000 0000 0000 Si
7 194 0001000000000100 0000 1000 No
8 84 0000110000000011 0000 0100 No
9 48 0000100000000010 0000 0100 No
10 24 0100000000010000 1000 0001 Si
11 6 0001000000000100 0100 1000 No
12 4 0001000000000100 0010 1000 No
13 2 0000100000000010 0100 0010 No

Figura 4.7 Esempio dell'esecuzione dell'algoritmo adattivo

 

 

Schema adattivo con offset del PIN

 

Quando l’attaccante non conosce nessun PIN di prova cifrato, e non può cifrare i PIN utilizzati per i propri tentativi, può decidere di manipolare l’offset utilizzato per modificare il PIN del cliente. Questo schema è caratterizzato dalle due stesse fasi dello schema iniziale, quindi il primo obiettivo da perseguire è quello di determinare le cifre presenti nel PIN.

Assumiamo che un EPB contenente il PIN corretto sia intercettato dall’attaccante, e che, per semplicità, l’intestatario del conto non abbia cambiato il PIN e l’offset sia 0000. Usando le seguenti tavole di decimalizzazione l’attaccante può determinare quali cifre siano presenti nel PIN:

                                

                                 Di[x] = Dorig [x] + 1 se Dorig [x] = i,

                                 Di[x] = Dorig [x] altrimenti.

 

Ad esempio, per la tabella:

 

Dorig =

0 1 2 3 4 5 6 7 8 9 A B C D E F
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

 

 

 

 

 

il valore di D7 è:

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
0 1 2 3 4 5 6 8 8 9 0 1 2 3 4 5

 

 

 

 

 

Ad esempio se il PIN è 7816 e la tavola di decimalizzazione è D7 , il PIN decimalizzato sarà 8816, quindi la funzione farà il matching tra 8816 e l'EPB intercettato più l'Offset 0000, uguale a 7816, ovviamente il test fallirà quando la cifra i è contenuta nel PIN. Ogni volta noi saremo dotati del corretto EPB e Offset. Come per lo schema iniziale, la seconda fase determina la posizione delle cifre presenti nel PIN, ed è ancora dipendente dal numero di cifre ripetute nel PIN originale.  Determiniamo la posizione delle singole 4 cifre sommando un offset al PIN ipotizzato dall'attaccante cercando un match. Gli offset utilizzati per determinare le giuste posizioni delle cifre ottenute, se sono tutte differenti, sono: 0001, 0010, 0100, e 1000 (la posizione dell'uno indica la posizione della cifra). Consideriamo il caso comune in cui tutte le cifre del PIN siano differenti, come, ad esempio, 1583. Per esempio per determinare la posizione della cifra 8, utilizziamo la tavola di decimalizzazione D8.

 Alla funzione  Encrypted_PIN_Verify passeremo l'EPB intercettato, il PAN_Data, la tavola dei decimalizzazione modificata corrispondente alla cifra di cui vogliamo trovare la posizione (nell'esempio D8), e l'offset 0001. Encrypted_PIN_Verify calcola il PIN originale mappato con la tavola modificata:

PIN originale decimalizzato = 1593

 

A questo punto la funzione sommerà l'offset all'EPB intercettato:

 

EPB intercettato + offset dell'ipotesi = 1583 + 0001 = 1584

 

Nel caso dell'offset 0001 non troveremo match tra il PIN calcolato dalla funzione e la somma tra l'EPB intercettato e l'offset dell'ipotesi; nell'esempio, per la cifra 8 avremo un match positivo per l'offset 0010; quindi 8 si troverà nella posizione corrispondente alla cifra 1 nell'offset.

 

Offset dell'ipotesi

Tavola di decimalizzazione dell'ipotesi EPB Intercettato EPB Intercettato + Offset dell'ipotesi PIN originale decimalizzato Risultato
0001 0123 4567 9901 2345 1583 1584 1593 NO
0010 0123 4567 9901 2345 1583 1593 1593 SI
0100 0123 4567 9901 2345 1583 1683 1593 NO
1000 0123 4567 9901 2345 1583 2583 1593 NO

 

 

 

Questa procedura è ripetuta finché non sono note le posizioni di tutte le cifre che compongono il PIN originale. Il caso peggiore è quello in cui sono presenti due cifre differenti, mentre il caso migliore è quello in cui tutte le cifre sono uguali; mediamente sono richieste circa 16 ipotesi per determinare il PIN corretto.

 

 

4.4 Risultati

 

Esaminiamo l'algoritmo che utilizza lo schema adattivo,  ottenendo il grafico in Figura 4.8 che presenta sull'asse delle ascisse il numero dei PIN che possono essere individuati e su quello delle ordinate il numero dei tentativi necessari a determinare i PIN. Concludendo possiamo notare che il numero dei tentativi per determinare il PIN corretto nel caso peggiore, è sceso dai 45 dello schema statico ai 24 dello schema adattivo, mentre nel caso medio, si passa dai 24 tentativi dello schema statico ai 15 tentativi dello schema adattivo. Infatti come si può notare dal grafico, con lo schema adattivo, con solo 14-15 tentativi, in media, sono stati scoperti 2000 PIN corretti.

 

Figura 4.8 Distribuzione delle ipotesi richieste usando lo schema adattivo.

 

Questo attacco è stato implementato sull'IBM CCA, estraendo con successo i PIN generati con il metodo IBM 3624-Offset.

 

Conclusioni

Attualmente si stanno affrontando discussioni tra i produttori di HSM riguardanti la gestione degli ATM per prevenire gli attacchi che sono stati analizzati prima. È molto costoso  cambiare il software col quale interagisce  l’HSM, e anche se l’aggiornamento del software è più conveniente, il sistema avrà bisogno di essere collaudato; inoltre l’aggiornamento potrebbe comportare una fase di re-installazione costosa. Una valida alternativa è quella di  controllare le tavole di decimalizzazione che dovrebbero essere facili da perfezionare.

Nonostante gli HSM esistano da molto tempo, lo studio formale della loro sicurezza è  ancora agli albori.

Gli attacchi rivolti alla tavola di decimalizzazione non aggiungono solo un altro scenario di attacco per l’assalitore, ma confermano che lo sviluppo di nuove tecniche per la sicurezza è una delle sfide più difficili che i progettisti devono affrontare.