I TPM sono la radice di tutte le funzioni di sicurezza

Scarica il whitepaper. Clicca QUI carica una copia del White paper in formato PDF.

 

Introduzione

Siamo tutti d’accordo sul fatto che la sicurezza degli ATM deve essere garantita nella massima misura possibile senza ridurne l’usabilità. Tuttavia, idee e opinioni su come si possa raggiungere questo obiettivo non sono unanimi.  Naturalmente, parte di questa confusione nasce dalla concorrenza tra i fornitori, con diversi prodotti di sicurezza che attirano l'attenzione dei clienti. Ma esistono anche informazioni errate che confondono i clienti e, in ultima analisi, portano a implementazioni scadenti vulnerabili agli attacchi.

Questo articolo raccoglie i principi fondamentali della sicurezza dei sistemi, partendo da come i singoli sistemi informatici dovrebbero essere protetti per poi discutere il caso di utilizzo unico delle reti ATM che, ovviamente, richiedono il massimo livello di protezione. Le reti ATM non solo hanno la responsabilità di milioni di dollari in contanti, ma rappresentano anche un potenziale punto di ingresso ai sistemi informativi e autorizzativi bancari in grado di trasferire grandi quantità di denaro in tutto il mondo. Un ATM compromesso potrebbe costare a una banca molto di più rispetto ai contanti contenuti in cassaforte.

Per iniziare, esaminiamo alcuni luoghi comuni per quanto riguarda la sicurezza. Forse il maggior pregiudizio sulla sicurezza del sistema è il fraintendimento del concetto di sicurezza a più livelli. È vero che non esiste un sola soluzione ottimale per la protezione di un sistema complesso: sono necessari più blocchi coordinati. Tuttavia, questo concetto è spesso frainteso e si pensa significhi che più è complessa la sicurezza, più il sistema sarà sicuro. Semplicemente non è così. Esistono tecniche crittografiche fondamentali che possono essere semplici, discusse apertamente e ben comprese e che devono costituire il nucleo di qualsiasi architettura di protezione. Tali tecniche non solo forniscono una sicurezza quantificabile, ma sono anche facili da utilizzare e non richiedono requisiti impossibili agli utenti per farle funzionare.

Illustriamolo con un rapido esempio. Siamo tutti abituati a sistemi PC che richiedono un nome utente e una password per accedere. Poiché il sistema di sicurezza basato sulla password è stato attaccato dagli hacker, le organizzazioni hanno creato delle regole per la creazione di password sempre più complesse, estremamente poco intuitive per gli utenti legittimi: modifiche regolari delle password, nessun riutilizzo di password già adottate, composizioni complicate e difficili da ricordare e così via. Microsoft ha trovato una soluzione con "Windows Hello".

Windows Hello combina il riconoscimento dei dispositivi hardware tramite crittografia basata su TPM con il riconoscimento biometrico del viso. Questo è, infatti, molto simile a un concetto di sicurezza ben noto all’industria ATM: chip e pin. Con Windows Hello il chip è il TPM, un processore crittografico simile al chip su una carta di pagamento, e le informazioni biometriche prendono il posto del pin. Questo sistema non solo è più sicuro di qualsiasi altro sistema che utilizza la combinazione “username +  password”, ma è anche straordinariamente facile da usare. Non solo posso accedere al mio tablet Surface semplicemente guardandolo, ma posso farlo in un istante, più velocemente di quanto io possa digitare una sola lettera della mia password. È possibile che un sistema sia più sicuro e più facile da usare? Assolutamente. Dobbiamo abbandonare l’idea che non può esserci alcun guadagno senza dolore – la sicurezza reale non richiede troppe complicazioni per l’utente.

Avrete notato che abbiamo introdotto il concetto di TPM nel paragrafo precedente. Questo documento si basa sul sistema TPM come "core root of trust" nell’ambiente informatico. Il TPM è un chip a semiconduttore sicuro costituito da un'architettura di sicurezza progettata dal Trusted Computing Group (TCG) composto daoltre 100 aziende, tra cui Intel, Microsoft, HP e IBM. Il loro lavoro ebbe inizio nel 1999 con l'obiettivo di creare un nucleo sicuro per i dispositivi informatici, in modo che tutta la sicurezza informatica potesse essere costruita a partire da quel nucleo sicuro. La buona notizia è che i TPM sono completamente standard in tutti i nuovi dispositivi PC e lo sono da molti anni. La cattiva notizia è che molte organizzazioni non sanno nemmeno di avere questo gioiello di sicurezza all'interno dei loro dispositivi informatici e non ne fanno uso. Questo documento è un tentativo di cambiare questa situazione, soprattutto per il nostro settore ATM. Dopotutto, abbiamo più bisogno di sicurezza informatica rispetto alla maggior parte dei settori.

TPM – il "core root of trust”

Cosa significa “core root of trust” e perché il TPM ha un ruolo centrale nella sicurezza informatica? Per capirlo, è importante comprendere che tutta la sicurezza informatica si basa sull'uso intelligente della crittografia. La crittografia è un metodo di elaborazione che converte i dati da un formato "chiaro" a un formato apparentemente casuale e viceversa.

Quando i dati o le informazioni sono in forma chiara, possono essere utilizzati per uno scopo specifico. Quando i dati vengono crittografati, non possono essere utilizzati fino a quando non vengono decrittografati. Il fattore fondamentale da apprezzare in merito alla crittografia e alla decrittografia è che, per crittografare o decrittografare i dati, è necessaria una "chiave" sicura. Senza la chiave, i dati crittografati sono inutili. In effetti, il significato della parola “chiave” in questo senso non è diversa da quello di una chiave per cassaforte. Se la chiave di una cassaforte viene smarrita, non è possibile accedervi per prendere l’oro al suo interno. In informatica, l’oro è costituito dai dati protetti dal processo di crittografia.

Adesso la questione importante da capire è che la chiave stessa deve essere in chiaro per essere utilizzata per decifrare un messaggio. Ciò significa che è necessario disporre di un modo per memorizzare la chiave in modo sicuro. Sì, è possibile crittografare tale chiave con un'altra chiave. Questo processo renderebbe sicura la chiave originale, ma poi sorgerebbe un altro problema: dove memorizzare la seconda chiave. Certo, possiamo avere una catena di chiavi (e molto spesso questa catena esiste per davvero). Ma la chiave iniziale deve essere conservata in un luogo sicuro e in forma chiara. Dove è possibile memorizzare la chiave master in chiaro all'interno di un computer? La risposta è: non sul disco rigido (o SSD). È impossibile memorizzare una chiave in chiaro sul drive in modo sicuro; un hacker in grado di accedere fisicamente al drive può sempre trovare la chiave in chiaro Il software da solo non può proteggerlo se un utente malintenzionato ha accesso fisico.

Si arriva al TPM. Il TCG ha progettato il TPM come un caveau dell’hardware per i segreti ed è integrato dentro la scheda madre. In alcuni casi il TPM può trovarsi all'interno  della CPU. È stato progettato appositamente per conservare le chiavi in modo sicuro. Ma si tratta di molto di più di un semplice deposito chiavi – ne parleremo nella prossima sezione. Per il momento, consideriamo che un sistema informatico potrebbe avere una catena di chiavi, ma che la chiave all'inizio di tale catena deve essere in chiaro e deve essere memorizzata in maniera sicura in modo che possa essere utilizzata solo per scopi attendibili. Il TPM è un deposito sicuro per questo.

CRTM – core root of trust measurement

Come anticipato in precedenza, il TPM non è solamente un deposito chiavi speciale. Pensate al primo problema che un deposito chiavi sicuro riscontra durante il suo primo giorno di lavoro. Se qualcuno dice al TPM: “Per favore, posso avere la chiave in chiaro?" come si fa a sapere chi chiede la chiave? Va bene memorizzare una chiave in modo sicuro, ma a chi darete quella chiave? Si tratta di un codice legittimo che chiede di utilizzare la chiave o è un malware? Può trattarsi di un hacker che ha modificato il software sul PC con un malware e poi chiede educatamente: “Per favore, TPM, posso usare la chiave?" Vedete il problema – non è sufficiente essere un deposito chiavi super sicuro. È necessario autenticare il software che richiede di utilizzare tali chiavi. Entra in gioco il secondo asso nella manica del TPM – il core root of trust measurement (CRTM).

Il CRTM funziona con una catena di fiducia che inizia all'accensione. L'hardware e il TPM lavorano insieme per "misurare" la sequenza di avvio del PC dall'avvio iniziale al BIOS/UEFI e per avviare il sistema operativo. “Misura" se uno qualsiasi dei software sul PC è stato modificato o manomesso durante il processo di avvio. Questo processo è noto come Secure Boot, una caratteristica standard dei nuovi core del PC che utilizzano il firmware UEFI per avviare il PC.

Per facilitare il Secure Boot, il progetto TPM ha introdotto un concetto chiamato PCR (Platform Configuration Registers). I valori di PCR vengono calcolati dal TPM in un processo chiamato "estensione del PCR" in modo simile alla creazione di un blockchain e di conseguenza i PCR hanno un'impronta univoca (cioè una serie di hashes) della sequenza di avvio del PC. Se i valori corrispondenti ai PCR attivati non sono stati modificati, si può concludere che il software di avvio del PC non è stato modificato e tutto ciò è garantito dal chip TPM. È impossibile che il malware abbia modificato anche un singolo byte del software di avvio misurato senza influire sui valori PCR.

Questo è un concetto estremamente importante nell’ambito della crittografia. La cosiddetta "funzione hash protetta" è una funzione simile alla crittografia che converte un blocco di dati in una stringa di caratteri di lunghezza fissa che funge da impronta digitale dei dati originali. Se i dati cambiano, l'impronta digitale cambia. Si tratta quindi di un modo sicuro di rilevare anche la modifica più leggera di un software di grandi dimensioni. Il TPM utilizza una variante di hashing chiamata HMAC. Un HMAC è un "hash con chiave", il che significa che solo chi ha la chiave sicura corretta è in grado di generare o verificare l'hash HMAC. È una sorta di "hash crittografato".

C'è un motivo per cui abbiamo approfondito questa parte. Questo è il modo in cui la tecnologia TPM garantisce che il software principale nell'ATM sia sicuro al 100%. Non si può modificare nemmeno un singolo bit di software nella sequenza di avvio di un ATM protetto da un TPM senza rompere la crittografia moderna. È anche il concetto che approfondiremo in questo documento per mettere in sicurezza tutto il resto dell’ATM.

Ora disponiamo di un software core sicuro: e per quanto riguarda il software applicativo?

Su un ATM Windows 10 ci sono due importanti tecnologie Microsoft che prendono il controllo: BitLocker e Device Guard (ora noti come Windows Defender Application Control ‒ WDAC). BitLocker è la tecnologia di crittografia del drive Microsoft. È in grado di crittografare l'intero disco rigido o SSD e, soprattutto, salva la chiave di crittografia del drive “nel TPM”. In realtà è un po' più complicato del semplice salvataggio della chiave nel TPM: facciamo un po’ di chiarezza.

Teniamo presente che non è sufficiente memorizzare le chiavi in modo sicuro, ma è essenziale elaborare "chi" chiede la chiave prima di consegnarla. Il TPM ha un altro nuovo trucco chiamato "sealing” - sigillare la chiave. Quando il drive di un ATM viene crittografato per la prima volta in un ambiente sicuro e una nuova chiave viene generata da Windows, questa chiave viene quindi crittografata utilizzando una chiave separata chiamata key-encryption-key, o KEK. La KEK stessa viene ulteriormente crittografata in un processo chiamato "sealing" utilizzando i valori PCR e una chiave privata del TPM. All'avvio dell'ATM, la chiave KEK diventa disponibile solo se sono state convalidate tutte le impronte digitali del software principale misurate dai PCR, il che significa che il BIOS e il codice Windows non sono stati manomessi, come spiegato in precedenza. Utilizzando la KEK, Windows decrittografa la chiave di crittografia del drive e la utilizza per decrittografare il drive intero. Una volta recuperata la KEK, Windows “chiude la porta” KEK. Ciò avviene "estendendo" la PCR 11, il che significa che la PCR 11 viene modificata dopo che la KEK è stata dissigillata, in modo che nessun altro possa successivamente recuperare la KEK. La KEK viene mantenuta sicura dal TPM fino alla successiva sequenza di avvio e resa nuovamente disponibile solo se i PCR confermano che nessuno dei software principali è stato manomesso, quindi blocca nuovamente l’ingresso non appena la KEK viene resa disponibile a BitLocker per decrittografare il drive.

Come si può vedere, abbiamo costruito il software di base passo dopo passo, assicurandoci che ogni step utilizzi i PCR per far sì che non si sia verificata alcuna manomissione, fino al completamento del processo di avvio e al caricamento di Windows. Ora dobbiamo avviare il software applicativo ATM e verificare che tutti gli eseguibili non siano stati manomessi prima di utilizzarli. In altre parole, estendiamo ulteriormente gli stessi concetti di controllo dell'impronta crittografica di ogni componente software prima di utilizzarlo. Questa parte finale della catena di avvio viene eseguita da Windows WDAC (o da software di terzi con funzionalità simili). Questo processo viene spesso chiamato whitelisting e dà come risultato l'hash (cioè l'impronta digitale calcolata) di ogni eseguibile che viene controllato prima di consentirne l'esecuzione.

Attivare la whitelist in un ATM

Il modo migliore per attivare la whitelist nel software ATM utilizzando Windows WDAC (o un altro software di whitelisting) consiste nell'utilizzare quella che è nota come la "certificate rule". Richiede che il software implementato sull'ATM sia stato pre-firmato dallo sviluppatore del software stesso. Quindi, ad esempio, i file eseguibili di Windows 10 sono firmati da Microsoft con la loro chiave privata. Ciò significa che chiunque può verificare che i file eseguibili di Windows non siano stati modificati o manomessi durante il transito e che si trovino nello stato identico in cui si trovavano al momento della firma da parte di Microsoft, semplicemente verificandoli utilizzando la chiave pubblica firmata in codice da Microsoft. Per ottenere la conferma da parte di WDAC è sufficiente creare una "certificate rule" che indichi che gli eseguibili firmati da Microsoft sono sicuri da utilizzare. 

Allo stesso modo, il software di KAL è sempre firmato dalla chiave privata con firma del codice di KAL. I nostri clienti possono verificare che il software KAL non sia stato manomesso installando il certificato di firma del codice KAL su ogni ATM.

Ma che dire di altri software che non possono essere pre-firmati in questo modo? La banca ha tre opzioni:

1. Chiedere al fornitore di firmare il codice.
2. Licenziare il fornitore. (Esistono realmente fornitori di ATM che non firmano il loro codice nel 2020? Apparentemente sì).
3. Utilizzare una "regola hash".

Una regola hash è una regola che viene aggiunta ai criteri della whitelist per WDAC, in base alla quale la banca calcola un hash per ciascuno dei file provenienti da un fornitore che non ha firmato i propri file eseguibili. In altre parole, si tratta di firmare il codice in loro vece. Ovviamente questa pratica non è valida quanto firmare il codice all’inizio, in quanto qualsiasi manomissione verificatasi durante il transito tra il fornitore e la banca non può essere rilevata (anche se potrebbero esserci altri meccanismi per garantire una trasmissione sicura).

Un secondo aspetto negativo dell'implementazione in questo modo è che la banca deve creare una "regola hash" per ogni file eseguibile; molto meno elegante rispetto alla semplice installazione del certificato pubblico del fornitore nell'ATM, che copre quindi tutti gli eseguibili di quel fornitore, compresi tutti gli aggiornamenti futuri.

E adesso cosa accade?

Una volta raggiunto questo punto, l'ATM è attivo e funzionante e tutto il software è stato verificato crittograficamente. Non è consentito eseguire alcun eseguibile che sia stato in qualche modo manomesso o modificato. Nemmeno un singolo bit dei gigabyte di software eseguibili su un ATM moderno può essere violato senza essere rilevato e bloccato.

Tuttavia, non ci siamo ancora. Un ATM protetto in questo modo è a prova di sicurezza per quanto riguarda la modifica non autorizzata del suo stack di software. Ma non finisce qui. L'inserimento di malware nell'ATM non è l'unico metodo per attaccare un ATM. Ora esamineremo come il TPM può aiutare ad evitare altri tipi di attacco.

Capire cosa possono fare i TPM

Le capacità di un TPM non riguardano solo la protezione del processo di avvio di un ATM. È la “core root of trust” che permette anche di proteggere tutto il resto. Passiamo a un libro favoloso scritto dai membri del Trusted Computing Group, Will Arthur, David Challener e Kenneth Goldman. Il libro, "A Practical guide to TPM 2.0", è straordinario ed è un tesoro di idee che mi hanno ispirato a scrivere questo white paper. Il libro è scaricabile gratuitamente da qui.

Il modo migliore per riassumere rapidamente questo libro in questo documento è quello di concentrarsi sui 53 casi di utilizzo elencati nel libro. Con il permesso degli autori, riproduco i casi di utilizzo riportati di seguito:

Diamo un'occhiata ai casi di utilizzo sopra riportati. La prima cosa da notare è che i TPM non riguardano solo la sicurezza del processo di avvio. Come detto in precedenza, il TPM è il core root of trust che consente di proteggere, passo dopo passo, ciò che facciamo con gli ATM. Naturalmente, ogni caso di utilizzo di cui sopra potrebbe fare al caso nostro. E ricordate che questi casi di utilizzo riguardano la protezione di quell'elemento in modo protetto tramite crittografia.

Prendiamo ad esempio ‒ 40 "chiavi VPN". Normalmente, una VPN viene impostata tra un ATM e un server installando certificati digitali (ovvero chiavi pubbliche firmate) sui due sistemi. Ma cosa succede se qualcuno attacca i certificati? I certificati memorizzati in un ambiente Windows protetto da TPM con il blocco descritto in questo documento non sono modificabili. Tuttavia, possiamo fare un ulteriore passo avanti. Le chiavi VPN possono essere sigillate attraverso i PCR utilizzando il TPM. Ciò significa che nel momento in cui la VPN sta per essere configurata, le chiavi necessarie per configurarla possono essere rese disponibili solo se i PCR sono nello stato corretto. Qualsiasi differenza e la connessione VPN viene rifiutata. Si consideri ora che questo concetto può essere applicato a entrambi i lati del tunnel VPN. Non solo i PCR devono essere nello stato corretto sul lato ATM, ma possono anche essere richiesti di essere nello stato corretto per il server ATM nel data center. In questo caso, avremmo confermato crittograficamente che sia l’ATM che il server ATM sono in uno stato sicuro prima della connessione. Sappiamo che tutti gli eseguibili che sono stati eseguiti sia sull’ATM che sul server ATM fino a quel punto sono integri e non manomessi e permettiamo ai due di connettersi se, e solo se, questo requisito è soddisfatto da entrambi i sistemi.

Tutte le idee contenute nell'eBook non sono presentate in questo white paper. Vi sono casi di utilizzo aggiuntivi applicabili specificatamente agli ATM che devono essere discussi, progettati e implementati. Mi auguro che l'industria ATM lo faccia per via di una o più commissioni. Ne discuteremo più avanti.

Protezione delle connessioni di rete

Nella sezione precedente abbiamo cominciato a parlare della protezione della rete. Ora esaminiamo questo aspetto in un po' più in dettaglio, in quanto si tratta di un caso di utilizzo di particolare importanza per gli ATM. È chiaro che non solo vogliamo che gli ATM siano sicuri individualmente, ma anche che qualsiasi sistema server di backend che tocchiamo sia sicuro e senza compromessi.  Guardiamo lo schema riportato di seguito:

 

 

Il diagramma mostra lo scenario di connessione in una tipica banca di grandi dimensioni con servizi ATM sofisticati. Gli ATM si connettono a un gestore terminali che coordina i servizi da più server di backend. Un HSM (modulo di sicurezza hardware) fornisce servizi di crittografia e aiuta con la suddivisione in zone dei pin. Una volta che una transazione è stata effettuata e deve essere autorizzata, viene inviata al sistema bancario principale se si tratta di una transazione "On Us" o agli schemi di carte di pagamento se si tratta di una transazione "Off Us".

Consideriamo ora un mondo di sicurezza utopico dove ogni ATM e ogni server è dotato di un TPM (il che è vero in tutti gli hardware recenti), tutti i sistemi sono stati verificati dall'avvio con misurazioni PCR e tutte le connessioni TLS e i VPN sono stati impostati utilizzando certificati non sigillati dal TPM e pertanto sono garantite crittograficamente per evitare qualsiasi tipo di manomissioni. Una vera e propria utopia. Siamo ad agosto del 2020 ed è veramente triste vedere che pochissime banche hanno raggiunto questo livello di sicurezza.

Un potenziale problema legato all’implementazione è rappresentato dalla scalabilità e dal clustering. Come si crea un cluster di server se le connessioni sono legate a TPM singoli? Vedere il caso di utilizzo n. 47 riportato sopra "Un insieme di server agisce come un unico server". Il TCG ci ha già pensato.

Protezione delle connessioni dei dispositivi hardware dell'ATM

Questo documento finora si è concentrato sul PC-core dell'ATM e su come garantire che il software sia privo di malware dopo l'avvio e durante il suo funzionamento. Passiamo ora ai singoli dispositivi hardware all'interno dell'ATM: il lettore di schede, il tastierino e, naturalmente, il distributore di contanti. Quanto sono sicure le connessioni tra il PC-core e i singoli dispositivi? Nella maggior parte degli ATM, queste sono connessioni USB che possono essere manomesse fisicamente. Se queste connessioni hanno dati chiari, l'ATM è vulnerabile agli attacchi - anche se è privo di malware. Discutiamone di nuovo con un diagramma: 

 

 

Come potete vedere, ho disegnato le connessioni USB come un cloud per indicare il rischio di attacco. Il TPM protegge il PC-core, ma i cavi USB sono a rischio di attacco se non sono protetti. Probabilmente, proteggere queste connessioni è responsabilità del fornitore di hardware ATM. Tuttavia, la situazione non è così semplice in quanto dipende anche dai requisiti di interoperabilità tra i dispositivi hardware e il resto del sistema. Per esempio, se i messaggi al CDM (distributore di contanti) sono criptati end-to-end, dove dovrebbe essere "l’altra estremità"? Se, ad esempio, l'altra estremità termina presso il gestore terminali è necessario discutere e concordare molti requisiti di interoperabilità.

È anche chiaro che anche il distributore di contanti non è ancora messo in sicurezza su molti ATM – ne sono testimonianza i vari "attacchi blackbox" riportati dai media. Un attacco blackbox di un ATM si verifica quando gli hacker intercettano la connessione al CDM ed erogano contanti utilizzando il proprio PC-core. La maggior parte degli ATM moderni ha una connessione criptata dal PC core al CDM, ma KAL sospetta che il design della sicurezza lasci molto a desiderare, poiché alcuni di questi ATM non hanno i TPM. Cerchiamo di essere molto chiari: Nessun TPM = Nessuna Sicurezza Modalità “oscure” per crittografare la connessione utilizzando chiavi protette da magia non equivalgono a sicurezza. Ma soltanto a oscurità e speranza. Se il vostro fornitore di hardware non può pubblicare informazioni su come le chiavi di crittografia sono protette, è molto chiaro che ciò è dovuto al fatto che le chiavi non sono protette correttamente.

XFS4IoT e protezione dei dispositivi hardware

La buona notizia è che il comitato XFS del settore ATM sta discutendo come proteggere la prossima generazione di dispositivi ATM. Alcuni di voi potrebbero aver sentito parlare della prossima versione di XFS 4.0 che è stata chiamata XFS4IoT. La parte IoT dimostra l'intenzione delle specifiche di essere pronte per il mondo IoT moderno. Ci sono diversi obiettivi principali per XFS4IoT:

1. La specifica è indipendente dal sistema operativo. Significa che gli ATM possono avere Windows, ma anche Linux o qualsiasi altro sistema operativo, all'interno dell'ATM.
2. È compatibile con il cloud. I dispositivi ATM possono esporre i servizi direttamente al cloud. I “cervelli” dell’ATM possono essere nel cloud e non solo all'interno dell’ATM. Ad esempio, il lettore di schede potrebbe esporre i suoi servizi al cloud. Il distributore di contanti potrebbe esporre i suoi servizi al cloud.
3. I servizi Web esposti in questo modo devono essere protetti. XFS4IoT sarà dotato di sicurezza integrata per garantire la sicurezza end-to-end dei dispositivi. Il protocollo di trasporto è stato selezionato come Web Sockets protetto da TLS con certificati su entrambi i lati. Inoltre, ciascun dispositivo XFS4IoT può disporre di un elemento hardware sicuro per consentire la sicurezza end-to-end della connessione. Tale connessione può terminare all'interno dell'ATM stesso (come è comune oggi) o può terminare su un server cloud.

Il diagramma seguente illustra il concetto:

Gli ATM XFS4 possono essere progettati come gli ATM convenzionali (immagine di sinistra), dove i dispositivi si collegano a un'applicazione software sul PC-core, o possono esporre un servizio sicuro al cloud (immagine di destra). Nel secondo caso potrebbe non esserci un PC-core all'interno dell'ATM e ciascun dispositivo potrebbe essere completamente indipendente l'uno dall'altro, ma fisicamente vicino e lavorando in tandem, orchestrato dall'applicazione cloud.

La cosa più importante da notare sono le caselle verdi etichettate "HSE". “HSE” è l'acronimo di "hardware secure element" e la specifica XFS, ovviamente, lascia scegliere ai fornitori di hardware come implementarla al meglio. È ovvio che l'HSE deve essere un TPM o deve contenere un sottoinsieme di funzioni TPM. Come minimo, l'HSE deve essere in grado di:

• Memorizzare le chiavi private in modo sicuro
• Implementare una "core root of trust measurement" (CRTM) per assicurarsi che solo il firmware protetto possa utilizzare l'HSE
• Implementare servizi di crittografia e firma

KAL ha discusso questi temi con il comitato TCG e quest’ultimo ha dichiarato di essere lieto di aiutare il settore ATM a fare un brainstorming delle opzioni. In effetti, il TCG ha già fatto dei progressi con i concetti di "mini TPM". Uno è il design DICE di TCG e l’altro è il design MARS, sempre di TCG. DICE e MARS sono pronti per l'uso nel settore ATM? Dobbiamo scoprirlo.

Una domanda interessante è scoprire se i TPM standard possono essere utilizzati come l’HSE all’interno di ogni dispositivo. Da un punto di vista economico, la risposta potrebbe essere positiva - i TPM costano meno di un dollaro in termini di OEM (original equipment manifacturer). DICE costerebbe ancor di meno. Per la nostra industria, che protegge milioni di dollari di fondi dei consumatori, il costo di un TPM o di qualsiasi altro tipo di HSE difficilmente costituirà l’ostacolo principale.

Gli ATM hanno una seconda root of trust: l’EPP

Abbiamo discusso della protezione dei dispositivi nella sezione precedente, ma adesso dobbiamo mettere in evidenza un dispositivo unico nel contesto della sicurezza: l'EPP (encrypting pin pad). L’EPP è, infatti, una root of trust indipendente all'interno dell'ATM. È altamente sicuro, è regolamentato tramite i requisiti PCI PED e ogni EPP è gestito individualmente e monitorato globalmente dall’industria. Dispone della propria misurazione CRTM del proprio firmware e si autodistrugge se viene rilevata una manomissione. È davvero molto sicuro.

Tuttavia, l’EPP presenta un pro e un contro per il settore. Dato che l’EPP fornisce un certo livello di sicurezza per gli ATM (tra poco ne discuteremo i limiti), le banche lo hanno sfruttato per garantire le transazioni ATM. L’EPP memorizza la chiave master della banca in modo sicuro e utilizzando una catena di chiavi garantisce che il pinblock  sia protetto e che i messaggi di comunicazione tra ATM e host siano crittografati e protetti (MAC). Un buon sistema di sicurezza. Tuttavia, non si tratta di una sicurezza sufficiente.

L’EPP non è disponibile all'avvio di un ATM e non sarà disponibile fino a quando Windows non si è avviato e i SP XFS (i driver hardware dell’ATM) non sono stati avviati. Dunque l’EPP non ha nulla da dire sulla validità del software all'interno dell'ATM. Se un'applicazione ATM infetta da malware desidera accettare un pin o proteggere (MAC) un messaggio all'host ATM, l'EPP farà la sua parte. Il perimetro di protezione dell’EPP è troppo piccolo per poter contribuire a proteggere l’intero ATM. È una perla di sicurezza in un insieme di software potenzialmente non protetto in cui non esiste un TPM.

Come aggiornare il software quando è protetto da un TPM?

In questa fase il lettore forse pensarà che se non è possibile modificare un software all'interno di un ATM protetto da un TPM, sarà difficile eseguire aggiornamenti software validi. Teniamo presente che il software applicativo è protetto mediante una regola di certificazione. È firmata dallo sviluppatore dell'applicazione (che potrebbe essere la banca stessa o il fornitore di fiducia della banca). Serve soltanto che il software aggiornato venga firmato con la chiave privata sicura dell'organizzazione di sviluppo software e l'ATM accetterà la modifica. È davvero semplice.

Le modifiche al software di base misurate dai PCR richiedono un passaggio aggiuntivo. Il software di base può essere aggiornato completamente in maniera remota senza una visita in loco da parte del tecnico, ma richiede la creazione di una chiave temporanea durante il processo di installazione sigillata contro i PCR non modificati. Una volta completata l'installazione, le nuove chiavi vengono sigillate attraverso l'intero set di PCR. Facile.

Ricordate l’esempio precedente su Windows Hello: una buona protezione non è necessariamente difficile da utilizzare. Infatti, la sicurezza di classe mondiale offerta alle banche dalla protezione TPM è più facile da utilizzare e garantisce la sicurezza crittografica rispetto ai metodi tradizionali.

Difesa contro gli attacchi fisici

Anche se non lo abbiamo detto in modo specifico prima, gran parte della discussione precedente riguarda la protezione dell'ATM da attacchi sia fisici che a livello del software. Un metodo di attacco comune sugli ATM consiste nel rimuovere il drive, modificare il software e ripristinare le modifiche su quell'ATM e su altri ATM. Questo metodo di attacco non è possibile se il drive è crittografato e la catena di avvio è protetta dal TPM.

Un altro tipo di attacco consiste nel tentare di "forzare" il TPM e provare varie chiavi in rapida successione. Il TPM è dotato di una protezione “anti-hammering”  incorporata che blocca questo problema. 

Infine, esistono altri tipi di attacchi estremi che potrebbero comportare interferenze dirette con l'elettronica della scheda madre. Un attacco simile sarebbe costoso da intraprendere, poiché richiede attrezzature specialistiche e finora non è accaduto, per quanto ne sappiamo. Tuttavia, esistono metodi economici per la protezione da tali attacchi, come l'uso di resina per proteggere le connessioni elettroniche esposte sulla scheda madre.

Attenzione alle soluzioni magiche

La protezione degli ATM e dei PC con i TPM come root of trust è l'unico modo noto e pubblicato per proteggere completamente i sistemi informatici. Il nostro settore dovrebbe chiedersi perché la sicurezza basata sui TPM non sia più comune nelle reti ATM. Naturalmente, diverse aziende vorranno competere sul mercato per vendere i loro prodotti di sicurezza. Questo è prevedibile. Ma è molto importante che le banche non si fidino di soluzioni illusorie. Ecco un elenco di cose a cui fare attenzione:

Mito: “Non è necessario un elemento hardware sicuro"

È impossibile memorizzare le chiavi private sul disco / SSD di un ATM in modo sicuro. Il motivo è che per quanto possa essere lunga la catena di chiavi, deve esserci una chiave in chiaro iniziale. Se la chiave è "nascosta" sul drive, è sempre possibile recuperarla. Alcune soluzioni affermano di generare la chiave all'avvio. Ma è necessario un codice in chiaro per generare questa chiave. Deve essere in chiaro perché non abbiamo ancora decifrato il drive. Se è in chiaro, può molto semplicemente essere decodificato dal codice eseguibile che sarà in chiaro prima della decifratura del drive.

Esaminiamo questo punto da un’altra prospettiva. Se fosse stato possibile tenere le chiavi in modo sicuro in un ATM utilizzando solo tecniche software, il nostro settore non avrebbe dovuto ricorrere agli EPP...

Mito: “Non è necessario alcun elemento di sicurezza hardware, in quanto le chiavi sono memorizzate sulla rete"

Se l’ATM non è abbastanza sicuro da tenere le chiavi in modo sicuro a causa dell’assenza di un TPM, è impossibile risolvere questo problema semplicemente spostando le chiavi in una postazione di rete. Ecco perché: quando l'ATM si avvia, deve accedere alla rete per ottenere la chiave sicura. Non dispone quindi di un metodo sicuro per autenticarsi sulla rete in quanto non dispone di un deposito chiavi. Ciò significa che il server di rete non sa "chi sta chiedendo la chiave". Ad esempio, quando BitLocker memorizza le chiavi nella rete, ha comunque bisogno di un TPM per autenticarsi nella rete. Nessun TPM = Nessuna Sicurezza.

Mito: “Non c’è bisogno di chiavi di crittografia"

Il fornitore sostiene che l'archiviazione delle chiavi non è necessaria perché dispone di una tecnologia magica che consente la crittografia senza chiavi. Ebbene, sarebbe davvero troppo bello per essere vero. Perché il mondo ha sempre avuto problemi con le tecniche di gestione delle chiavi quando non c’è nemmeno bisogno delle chiavi? Tutte le tecniche di crittografia conosciute, quali 3DES, AES e RSA, richiedono chiavi private. Le chiavi private si chiamano così perché devono essere memorizzate in modo sicuro. Ciò che rende sicuro un sistema di crittografia è che le chiavi sono scelte tra un numero davvero enorme di possibilità. Ad esempio, 3DES ha almeno 2¹¹² chiavi. Ci vorrebbero 30 anni per provare tutte le chiavi, a una velocità di 5 miliardi al secondo per tentativo. Con AES ci vorrebbero 10²² anni alla stessa velocità.

Mito: “Il nostro algoritmo è riservato"

La sicurezza reale si basa su standard aperti e algoritmi aperti insieme a chiavi riservate. L'unico aspetto di un sistema di sicurezza che dovrebbe essere riservato sono le chiavi. Se le chiavi vengono compromesse, dopo averle cambiate il sistema è di nuovo sicuro.

Mito: “Gli elenchi di controllo di accesso (ACL) ci mantengono al sicuro"

Il controllo degli accessi viene facilmente eluso in assenza di un blocco TPM. Ci sono anche altri inconvenienti legati alle ACL, che non approfondiremo qui, ma è sufficiente dire che le ACL da sole  sono una protezione insufficiente per gli ATM.

Conclusioni

Mi auguro che il lettore abbia compreso il motivo per cui il TPM è fondamentale per la sicurezza informatica e quindi fondamentale per la sicurezza ATM. Spero che sia anche chiaro che la maggior parte delle banche hanno ancora modo di mettere in sicurezza la propria rete in modo crittograficamente garantito. È inoltre importante notare che qualsiasi sistema di sicurezza di questo tipo deve essere progettato tenendo conto dell'interoperabilità. Poiché la presenza di più fornitori e più soluzioni di prodotto sono una parte standard del panorama tecnologico ATM odierno, non sarebbe possibile che i lockdown vengano implementati da ciascun fornitore in modo indipendente. Ciò creerebbe un ATM inutilizzabile.

Spero che questo documento sia l'inizio di un processo che consentirà di sviluppare specifiche di sicurezza interoperabili utilizzando le basi crittografiche messe a disposizione dai TPM. Il Trusted Computing Group ci ha offerto il suo aiuto. Spetta ora ai vari comitati del nostro settore – XFS4IoT, ATMIA ed EST – insieme a banche e fornitori, progettare i passi successivi.

Ringraziamenti

Desidero ringraziare le seguenti persone per il loro contributo a questo progetto:

• Michael Moltke (NCC Group Denmark)
• Kit Patterson (KAL)
• Arthur, David Challener e Kenneth Goldman per aver scritto l'eBook sui TPM e David Challener per aver organizzato il supporto dal TCG

Per qualsiasi domanda, non esitate a contattarci a Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.