Prepariamoci, perché sta
arrivando la nuova moda, la soluzione di tutti i problemi: la sicurezza
della transazione. La cattiva notizia è che non è una
novità, e che non risolverà tutti i problemi di
sicurezza. La buona notizia è che almeno si tratta
effettivamente di un buon meccanismo, che in alcuni contesti può
essere molto utile.
Vediamo innanzitutto il problema con un esempio, un classico di questo
periodo: il phishing. Come è noto, il phishing utilizza diverse
tecniche, tipicamente legate all'invio di messaggi di posta elettronica
con mittente falsificato, allo scopo di "rubare" le credenziali di un
utente. Gli obiettivi vanno dagli account su E-Bay fino agli account
sui siti di home banking. Convincendo l'utente a connettersi a un sito
fasullo, dall'aspetto uguale a quello del sito della banca e inducendo
l'utente a fornire username e password, il malintenzionato riesce a
farsi consegnare le cedenziali dell'utente, e utilizzarà poi
queste credenziali per effettuare delle operazioni. L'idea della
sicurezza della transazione è invece che l'utente,
anziché dare username e password al sito, legittimo o meno che
sia, quando vuole effettuare una transazione firmi con firma
elettronica un "ordine" contenente la transazione che vuole effettuare,
e invii l'ordine firmato al server: chi intercettasse questo ordine non
avrebbe le credenziali dell'utente, dato che la chiave privata se ne
resta al sicuro sul sistema dell'utente, e della transazione non se ne
farebbe niente, se non al più bloccarla o proseguirla
effettivamente alla banca. Anziché cifrare e autenticare la
comunicazione con SSL, si è cifrata ed autenticata la singola
transazione.
Tutto chiaro? Non direi. La differenza reale, in questo caso, non sta
nel passaggio da autenticazione della comunicazione ad autenticazione
della transazione, ma da autenticazione con username e password a
meccanismo a chiave pubblica. Lo stesso effetto si sarebbe ottenuto se
il sito di home banking avesse utilizzato l'autenticazione del client
SSL: il sito pirata non entra in possesso delle credenziali
dell'utente, dato che la chiave privata se ne resta sul client, e
quindi non sarebbe in grado di accedere al sito di home banking; SSL
è già protetto contro attacchi di man in the middle.
Questo naturalmente senza entrare nel merito delle altre pessime
pratiche in uso anche da parte delle banche, che facilitano il phishing
e
di cui ho già scritto. Per inciso, molte altre idee interessanti si possono trovare in
questo articolo, a dimostrazione del fatto che più che nuove tecnologie, contro il phishing servono soprattutto buone pratiche.
La sicurezza delle transazioni allora a cosa serve? In realtà
può servire a molto. Per prima cosa, perché si possa
utilizzare è necessario che il servizio che si vuole rendere
sicuro sia implementabile come transazioni. Ad esempio, non è
utilizzabile per servizi come la telefonia su IP (almeno, non per
proteggere la conversazione). Viceversa, è già utilizzata
per la posta elettronica (PGP, S/MIME). Tuttavia esistono da
tempo protocolli per autenticare come transazioni, ad esempio, i
pagamenti effettuati su Internet con carta di credito.
SET,
introdotto nel febbraio del 1996, è stato uno dei primi
protocolli di questo tipo. Senza entrare troppo nel merito del
protocollo (che è in disuso), l'idea principale è che al
momento in cui un acquirente preme il pulsante "buy" di un sito di
commercio elettronico, genera e firma una transazione composta
essenzialmente di due parti (legate fra di loro dalla firma
elettronica):
- una descrizione del servizio o del prodotto acquistato, con il relativo costo, destinata al venditore
- le informazioni di pagamento, (nome, numero di carta di
credito ecc.) cifrate con la chiave pubblica di un cosidetto Payment
Gateway verso la banca
L'idea è che l'acquirente è impegnato dall'ordine che ha
firmato (maggiore tutela per il venditore), il venditore deve avere un
ordine firmato e associato ad una descrizione del prodotto o servizio
per richiedere il pagamento (maggiore tutela per l'acquirente), le
frodi on-line sono molto più difficili che con il semplice
numero di carta di credito (maggiore tutela per l'emittente della
carta) e le informazioni personali e di pagamento non sono mai
conservate in chiaro sul sito del venditore, che non vi ha accesso
(tutela della privacy dell'acquirente fino all'anonimato, almeno per
quanto riguarda il veditore, e nessun elenco di numeri di carta di
credito da rubare dal sito del venditore).
I vantaggi sono quindi molti, e la protezione dal phishing è
fornita dall'uso della firma elettronica... perché allora non
stiamo già usando tutti da anni questo o altri protocolli
simili? Perché invece si continua ad utilizzare il numero di
carta di credito, magari con "protezioni" come la generazione di numeri
unici per ogni transazione? Le ragioni sono diverse, ma le principali
direi che sono due:
- perché non si è sentita la necessità
di implementare meccanismi robusti di più difficile utilizzo,
quando il problema del commercio elettronico non era tanto di tutelarsi
dalle truffe quanto quello di avere una diffusione ed un utilizzo reali;
- perché l'implementazione è più complessa.
Mentre sul primo punto ormai si potrebbe obiettare, almeno per quanto
riguarda l'home banking, il secondo punto merita attenzione:
l'autenticazione della transazione richiede di implementare dal lato
client un meccanismo di generazione, visualizzazione e firma delle
transazioni. Questo è probabilmente la causa principale della
mancata diffusione di queste tecnologie.
Immaginiamoci ora che si decida di implementare in modo diffuso
l'autenticazione della transazione anziché quella della
connessione. Non è difficile prevedere allora che si debba
arrivare ad uno standard: mentre ad esempio le banche hanno un rapporto
diretto con i loro clienti, e quindi possono proporre client o
componenti personalizzati da installare sul PC, questa strada non
è percorribile per un più generico commercio elettronico,
e del resto non ci si può aspettare che un utente abbia decine
di componenti personalizzati sul proprio PC (che è generalmente
già abbastanza instabile di suo). Una strada che porti ad uno
standard non si percorre certo in tempi brevi, e quindi non credo che
avremo per questa via una soluzione generale al problema del phishing,
almeno per un po'. Magari, con un po' più di lungimiranza da
parte di chi ha la forza di imporre al mercato, se non standard, almeno
prassi, non saremmo a questo punto: i problemi affrontati da SET sono
noti da più di dieci anni.
Io mi immagino invece che in tempi brevi ci sarà un fiorire di
certificati utente per SSL, il che permetterà di affrontare
meglio il problema immediato, che peraltro dubito che abbia una
soluzione che non passi dall'educazione dell'utente e dall'abbandono
della pratica commerciale di non turbare la quiete dell'utente con
pensieri come la sicurezza dei suoi soldi.
Comunque sia, nel momento in cui si arrivasse ad uno standard per la
firma delle transazioni, non è difficile ipotizzare anche che
questo standard venga implementato all'interno dei browser. La prima
conseguenza è che, come per le Certification Authority,
conterà di più il modello commerciale a supporto che i
modelli teorici (in teoria le Certification Authority sono terze parti
fidate, di fatto non è l'utente che sceglie la CA di cui fidarsi
per accedere ad un sito, e nella pratica quello che conta è
essere una delle CA incluse nella distibuzione dei browser). Se non ci
sarà un cambio di mentalità, si porrà anche
lì il problema di far eseguire le transazioni all'utente "in
modo trasparente" e senza turbarlo con i dettagli sulla sicurezza, e in
definitiva si apriranno altri scenari per attaccare il rapporto fra
cliente e venditore (per inciso, non è curioso che nei browser
ci sia un alert che ci chiede se vogliamo trasmettere dei dati in
chiaro a un server con un comando POST, ma non ci sia un pulsante per
sapere quali sono i dati che stiamo per trasferire?). Non
dimentichiamoci che stiamo discutendo di protezioni dal phishing, che
si basa proprio sul poter ingannare l'utente grazie alla
disinformazione e disattenzione dell'utente ai "dettagli tecnici"
("Cosa vuole questa finestra? Io comunque dico sì...") e alle
cattive pratiche da parte di venditori e banche nella gestione di SSL e
del rapporto con il cliente. Se si pensa che l'autenticazione della
transazione sia una grande protezione contro questi problemi, credo che
possa essere utile ricordare il caso di Microsoft Quicken (precursore
di Microsoft Money) e del Chaos Computer Club, che già nel 1997
aveva realizzato un applet AciveX
che sul sistema client accodava transazioni illegittime a quelle
legittime: l'utente poi autorizzava il tutto. Dato che stiamo parlando
di phishing, quindi di tecniche basate sull'ingannare l'utente, credo
che sia interessante anche vedere la risposta di Microsoft di allora,
in coda allo stesso articolo oppure da
qui.
Insomma, la sicurezza della transazione è inutile? No,
può offrire molte protezioni e può offrire molte
garanzie, ma per il phishing e per molti altri problemi si può
fare altro molto prima; non dimentichiamo che la maggior parte delle
banche non usa neppure i certificati lato client semplicemente per non
dare all'utente l'onere di installarli; figuriamoci i problemi a
introdurre la firma della transazione. Autenticare la transazione
fornisce all'utente una protezione veramente importante, a suo tempo
già sfruttata in SET: se non c'è una transazione firmata,
la controparte (venditore, banca...) non può sostenere che
c'è stato un ordine. Il che naturalmente rappresenta una
protezione per l'utente solo se poi il contratto che regola il rapporto
non dice il contrario. E come sempre quando si ha a che fare con la
firma elettronica, se la chiave privata viene compromessa tutto quello
che viene firmato diventa, per definizione, autentico.
C'è un ultimo passaggio da affrontare. Si comincia a sentire
dire che la sicurezza della transazione rende inutile la sicurezza di
rete. Per fortuna non tutti i fautori dell'autenticazione della
transazione sostengono questa assurdità, che indica spesso una
visione molto parziale della sicurezza. Non approfondiamo oltre: come
sempre, l'introduzione di una nuova tecnologia non rende inutili le
altre, che coprono altri problemi ed altre vulnerabilità. I
sistemi continuano ad essere critici: l'utente deve continuare a
preoccuparsi della sicurezza del suo PC, per evitare problemi come
quello di Quicken, e il venditore deve continuare a preoccuparsi della
sicurezza del suo server per evitare che la fase di autenticazione
della transazione venga aggirata. Almeno, la responsabilità
dell'utente non dovrebbe dipendere più dalla sicurezza del
server.