Pagamenti online, transazioni strette fra due poli

Pagamenti online, transazioni strette fra due poli

Si sta affermando l’esigenza di conciliare le attese di sicurezza dei pagamenti di consumatori con quelle delle società che effettuano commercio elettronico. Ci sono strumenti per ottemperare a cioò, come il nuovo Set “three domain model”. Il caso di PagoSicuro.

Molto spesso capita di intrattenere conversazioni generiche con utenti finali, circa l’affidabilità o meno dei mezzi di pagamento elettronico, con particolare riferimento agli acquisti effettuati via Internet. Tra le domande che più frequentemente mi sono poste dai consumatori vi sono quelle sull’intercettabilità dei numeri di carta, seguite dalla falsificazione dei numeri stessi e del loro utilizzo fraudolento. Il consumatore, infatti, ha una paura (giustificata e persistente) che i suoi soldi siano sottratti e di non poterli più recuperare. In quanto a ripudio delle transazioni, allo stato attuale si può dire che il cliente sia abbastanza tutelato (può, nella maggior parte dei casi, ripudiare la transazione), per cui è più uno spavento associato a problemi pratici di rigenerazione della carta, che altro. Ma l’utente finale è solo una variabile, pur importantissima, dell’ambiente. Sicuramente un altro attore di rilievo è il merchant. Quest’ultimo è ancor più concentrato sulle problematiche di sicurezza, in quanto deve, da un lato, avere la garanzia che il detentore del numero di carta sia effettivamente quello che dichiara di essere (è il merchant, infatti, essere più penalizzato in caso di ripudio di una transazione) e, dall’altro, proteggere la propria struttura da eventuali attacchi di malicious hacker. E c’è qualcosa anche per il versante “issuer”. Anche questo segmento, infatti, appartenente principalmente al mondo bancario, a soffrire delle eventuali debolezze della catena, in maniera diretta e/o indiretta.

Quanto finora illustrato riguarda le problematiche di sicurezza. Tuttavia esiste anche una serie di esigenze di natura pratica, che investono tutti i poli della transazione, con particolare riferimento all’utente finale. Ne parleremo in maniera più diffusa tra poco. Parliamo, invece, del problema dei malicious hackers. Accantoniamo per un attimo l’argomento sniffing (intercettazione) della transazione buyer/merchant, in quanto è stato detto sin troppo su questa problematica che, pur essendo ovviamente attuale, è affiancata da altri “issues”.

È stato ormai comprovato che la maggior parte degli attacchi, finalizzati all’acquisizione dei numeri di carte di credito per un successivo riutilizzo, avvengono sui database dei merchant. Questi, infatti, sono acceduti dai cracker nelle maniere più disparate e soprattutto per due ragioni fondamentali. Le prime riguardano le debolezze intrinseche a livello di protezione perimetrale. Le infrastrutture dei merchant (non sempre, ovviamente), possono soffrire di security flaw, che possono essere potenzialmente sfruttabili dagli attacker per scopi fraudolenti. Le seconde concernono le debolezze intrinseche a livello di database management/architecture. Come abbiamo detto prima, i merchant conservano, in molti casi, i numeri di carta di credito sui propri database server. Gli attacchi che si sono susseguiti negli ultimi mesi (ricordiamo i casi di CdUniverse e Creditcards.com) hanno dimostrato che a volte bisognerebbe ulteriormente rafforzare le protezioni delle basi di dati, o adottare un modello operativo che sposti la custodia delle informazioni su un gateway centralizzato in grado di interfacciarsi con la massima flessibilità e affidabilità al sistema bancario. Per dovere di cronaca, comunque, non solo i merchant sono stati oggetto di questo tipo di attacco: i casi WesternUnion Bank e Visa Uk ne sono un esempio tangibile.

Esiste poi un’altra problematica, relativa al fenomeno delle “not present card”, fondamentalmente legata all’esistenza dei generatori di numeri di carta di credito. Quelli ben progettati riescono molto spesso ad ottenere una transazione a buon fine e, ovviamente, l’eventuale end user realmente possessore della carta va risarcito. Dal punto di vista tecnologico di base, un aiuto consistente è dato dalla crittografia e dai certificati digitali. L’adozione dei crittosistemi Ssl (Secure Socket Layer – v2/v3) e Transport Layer Security (Tls v1) è sicuramente un passo avanti per la protezione delle transazioni. Di fatto, l’esigenza di proteggersi dagli sniffing attack è quasi del tutto soddisfatta, in quanto intervenire su quel segmento è davvero complesso da porre in essere. Rimangono le problematiche legate all’autenticazione tra i poli. Nel 1997 ha visto la luce il protocollo Set (Secure electronic transaction). Il Set prevede una sinergia tra digital certificate e crittosistemi, finalizzata all’autenticazione dell’identità del titolare di carta (cardholder), del commerciante (merchant) e della banca che gestisce la transazione. Il fattore positivo di Set 1.0 consisteva nel fatto che il cardholder colloquiava direttamente con la banca emittente, sia a livello di autenticazione sia a livello di pagamento. Lo scambio effettivo, poi, avveniva tra la banca del commerciante e la banca del cardholder stesso. Di conseguenza, la transazione avveniva solo tra poli muniti di certificati digitali validi e quindi sempre identificati come legittimi: ogni soggetto decifrava solo le informazioni a lui relative verificando sempre le firme digitali di chi invia i messaggi. La vera limitazione della diffusione del Set è stata la sua complessità. Per quanto riguarda Set 1.0, il problema era che la struttura era complessa, richiedeva l’installazione di software sofisticati, sia sulla macchina del cardholder sia su quello del merchant.

Visa ha fatto tesoro di questa esperienza non proprio positiva e ha creato una soluzione Set based ma più snella, denominata 3dm, Three Domain Model. Lo scopo di 3dm è garantire l’autenticazione completa delle parti in gioco. In questo caso, tuttavia, il modulo software che l’utente deve scaricare è costituito da un plug in. Le componenti più complesse del sistema sono affidate ai server. I tre “domini” consistono nellla banca “acquirer”, che si occupa degli online merchant, l'”issuer”, cioè l’istituto di credito emittente, e nella struttura per l’interoperabilità dei soggetti. Questo sistema ha dalla sua una metodica di riscontri sull’identità del poli decisamente robusta. Rimane da determinare definitivamente che ruolo avrà il database delle carte di credito solitamente gestito dal merchant: se scomparirà del tutto o in maniera modulata, come sarebbe plausibile, o se rimarrà al suo posto, con le implicazioni del caso.

Le perplessità in ordine al mercato italiano (e non solo) riguardano innanzitutto il punto di vista dei costi: aderire a questo sistema (che funzionerà solo per Visa) non dovrebbe essere una migrazione del tutto indolore, basta guardare, per esempio, ai servizi di electronic wallet basati sul 3dm che Visa ha messo a disposizione dei propri issuer, alla modica cifra entry di cinquantamila dollari e ventimila come fee a regime (fonte Visa international). In secondo luogo va tenuto in considerazione un affidamento, forse eccessivo, che si fa al mondo delle smartcard a livello di home computing. A quel che risulta attualmente, Visa ed Abi stanno lavorando molto alla diffusione nel nostro paese delle carte a microprocessore, ma una volta per tutte dobbiamo fare i conti con un fattore determinante: la espansione degli smartcard reader. Fino a quando questo limite di fatto non sarà superato non si potrà essere certi della riuscita del progetto.

C’è anche chi propone un Three Domain Model, modulato in maniera differente, e con diverse tecnologie. Senza scendere troppo nei particolari, si tratta di un sistema basato su una smartcard con relativo lettore e un relativo software che, al momento in cui scriviamo, funziona solo con Microsoft Internet Explorer (Netscape è in fase di testing). Il sistema utilizzatosi propone di garantire sicurezza relativamente al non ripudio (firma digitale associata all’utilizzo della carta), alla non intercettabilità (i numeri di carta di credito utente non vengono immessi nella transazione, in quanto sono quelli della SmartCard a viaggiare), il database carta di credito del merchant scompare in quanto se ne fa carico l’azienda emittente della smart card che li archivia nel suo database e, a sua volta, li utilizza per colloquiare con il circuito bancario. Anche in questo caso abbiamo un’ulteriore visione del Three Domain Model, costituita dall’azienda emittente della smart card, polo bancario e merchant.

Il merchant che vuole aderire al circuito non paga commissioni, ma quote graduali sul transato. In cambio riceve la soluzione chiavi in mano per la gestione delle transazioni. Le operazioni di inserimento nel ciclo biologico aziendale sembrano sufficientemente rapide, le partnership tecnologiche di tutto rispetto ed il il sistema di sicurezza decisamente robusto, ma la classica casalinga di Voghera (e anche quella di Pioltello, come il medico di Caltanissetta, tutte persone poco esperte e pazienti, insomma) devono dotarsi di un lettore smartcard, di un software per la gestione del sistema e del browser Internet Explorer. Questi sono generalmente forniti dall’azienda ma, atteso che il prezzo della soluzione lato client (limitatamente al periodo di offerta) è di 15 mila lire (18 mila se aggiungiamo le tremila lire di credit card check), l’utente deve mettere in conto un periodo di alcune settimane per effettuare la registrazione, ricevere il kit, montarlo ed installare il software, confermare la registrazione e concluderla, compilare il Rid per l’autorizzazione dell’accredito delle 15mila lire per le spese di spedizione di cui sopra, andare in banca per autorizzarlo. Il tutto per effettuare transazioni solo sul proprio computer (a meno che gli alberghi, i terminali delle sale Vip degli Aeroporti, i computer degli amici e quelli portatili aziendali non siano dotati di uno smartcard reader compatibile con “quella” smart card). Tutto molto bello, molto potente ma poco pratico, soprattutto dal lato end user. I limiti potrebbero risiedere sia nella difficoltà di implementazione lato client sia nella disponibilità dell’utente a fornire i propri dati di carta di credito all’azienda fornitrice del sistema. E che dire degli stessi issuer? Qualcuno ha chiesto loro se sono disponibili affinché un unico repository conservi una così alta percentuale di numeri di carta? Sarebbe interessante, inoltre, verificare il funzionamento del software in presenza di un personal firewall, insomma: se Visa ha fatto tanto per ridurre la complessità forse anche chi ha ideato quest’altro sistema dovrebbe seguirne l’esempio, ma effettivamente non è così facile. Chi si occupa di security analisys e di assessment (verifica delle vulnerabilità, pentest, policy e bug reporting per capirci) spesso si trova ad assistere a dissertazioni sulla definizione di three domain. Si nota una certa difficoltà, da parte di alcuni, nel comprendere finanche le componenti di questo modello. Molto spesso, infatti, si inserisce come terzo dominio il buyer, a discapito di uno degli altri tre. Ciò non è del tutto esatto. In entrambe le visioni del 3dm di cui abbiamo parlato finora, il buyer non è un dominio, ma una variabile indipendente. In poche parole: se vuole comprare si deve adeguare. Se da un lato, infatti, 3dm gli dà come unica incombenza l’uso di una smartcard Visa, l’ altro aumenta ulteriormente la complessità dell’entrata del buyer nel circuito ma non identifica la comunità utente come un dominio.

Se così fosse, si potrebbe pensare ad un nuovo paradigma, che potremmo definire Four domain o 4dm, che poi , sempre forse, è il più coerente, secondo alcune correnti di letteratura. Pagosicuro adotta il “Four domain” e riprende il concetto che abbiamo descritto all’inizio e che anche gli altri due esempi hanno seguito: il Db dei numeri di carta di credito non è più di competenza del Merchant: resta competenza esclusiva degli Issuer. La verifica della bene emissione viene effettuata direttamente (via gateway) con il circuito dell’issuer. I riscontri sull’identità del merchant sono evidentemente finalizzati ad una maggiore robustezza.Il valore aggiunto nei confronti del buyer è dato dalla presenza di un’assicurazione sulla transazione, fornita da PagoSicuro agli utenti registrati. Atteso che anche i non registrati possono effettuare acquisti con un merchant associato a PagoSicuro, ma senza assicurazione, la registrazione non implica l’immissione di numeri carta, ma soltanto dei dati personali, cautelati su un database offline con crittosistemi a 128bit/key. Per effettuare la transazione il wannabe user deve inserire un Pin e la sua data di nascita, che verranno confrontati con altre informazioni immesse durante la registrazione, dopo n tentativi di login fallito il record viene disabilitato. Tutte le procedure di interazione tra il buyer e PagoSicuro sono gestite da crittosistema; all’utente non sono richiesti strati aggiuntivi di software né ulteriori procedure di registrazione. Per la gestione del PIN non c’è bisogno di smartcard: è stato pensato un duplice crittosistema implementabile eventualmente con una chiave Usb. In questo modo i costi potrebbero rimanere sufficientemente contenuti e, soprattutto, non c’è necessità di lettori od altro. Con PagoSicuro si può gestire una transazione da qualsiasi macchina dotata di un browser, ecco allora che anche le sale Vip degli aeroporti si aprono al commercio elettronico di massa.

A giudicare dalle note tecniche generali, sembra che Pagosicuro abbia rivolto particolare attenzione al lato merchant. Per ognuno di questi, infatti, la struttura genera un certificato X.509 installabile su un browser (contenente ovviamente una coppia di chiavi pubblica-privata correlate); inoltre vengono assegnati un Pin ed una password. La spedizione delle credenziali avviene in maniera esterna a Pagosicuro. Quando il merchant deve interoperare con Pagosicuro, deve collegarsi (via https) al sito con il browser dove è stato installato il certificato X.509. Durante la fase di autenticazione sul web server, una funzione di hashing provvede a generare una stringa di lunghezza fissa, che viene analizzata per il matching con quella corrispondente memorizzata nel database. Il limite massimo dei tentativi falliti (comunque registrati) è di tre. Un ulteriore strato di sicurezza sarà possibile, per ora dal lato merchant, dall’implementazione di token Usb. Per chi non avesse confidenza con certi concetti, ricordiamo che una funzione di hashing ha le caratteristiche di prendere in input una stringa di lunghezza variabile e di fornire in output una stringa di lunghezza fissa modificata (criptata) rispetto alla stringa sorgente. Non è possibile risalire alla stringa originaria partendo dalla stringa “hashed”. L’hashing viene utilizzato anche nella verifica lato buyer, unitamente alla tecnica delle random question. Una volta effettuata l’autenticazione sul sito Web, il Merchant/Amministratore può accedere ai dati di sua competenza compatibilmente con le regole di firewalling implementate ed i ruoli Sql server definiti per l’accesso al database.

Riassumendo: gli utenti registrati sono garantiti da un’assicurazione, colloquiano direttamente con il circuito carte di credito e bancario di competenza. Quelli non registrati possono, comunque, effettuare transazioni, ma senza assicurazione, con il beneficio del colloquio diretto con il circuito acquirer. I merchant si liberano dell’incombenza della gestione del card Db, fruiscono di un virtual Pos dedicato (si evitano quindi anche i problemi legati alla concentrazione dei Pos) e vengono di fatto sollevati da qualsiasi accertamento di bene emissione (e quindi rischio frode sul loro versante); il tutto con un fee annuo alla portata anche dei più piccoli e con un costo per operazione (cost x transaction) fisso.In questo sistema di pagamento, disponibile all’utente finale, mi dicono, da gennaio, chi ha gli oneri maggiori è proprio il gateway owner che, per forza di cose, deve investire moltissimo in sicurezza, policy e gestione delle transazioni: a loro un “in bocca al lupo”. Del resto è l’unico modo per conciliare esigenze di security alla praticità lato utente, una delle vere conditio sine qua non per la riuscita di un sistema di pagamento. L’altra è sicuramente data dall’utilizzo di piattaforme open, in grado di interloquire in qualsiasi momento con altri sistemi.

Sin qui una breve analisi di quel che offre l'”x”Domain model. A voi, buyer o merchant, la scelta. Valgono generalmente, comunque, alcune considerazioni di carattere tecnico, relative ai requisiti oggettivi che queste strutture dovranno avere.

I merchant, per la loro scelta di adesione al circuito, dovranno valutare il proponente guardando all’alta affidabilità dei sistemi, alle smart card con scelta del processore, al firewall con l’autenticazione dei poli.

Il primo requisito è importante per due motivi. Il primo è che un sistema di questo genere deve essere, per forza di cose, basato su architetture Ha (High Availability), per gestire improvvisi picchi di transazioni. Inoltre l’avvento di nuovi attacchi di tipo Distributed Denial of Service (della famiglia Naphta, per intenderci) richiedono l’impegno di sistemi operativi non vulnerabili a livello kernel, nonché di risorse replicate e ridondanti, ai fini della ripartizione equa del workload. Per quanto riguarda le smart card il “pericolo” dei power analisys è sempre dietro l’angolo. Qualcuno, prima o poi, vi inizierà a chiedere quale processore state utilizzando nella vostra smart card e se sia protetto contro quel determinato tipo di attacchi side channel. In tema di firewalling, la protezione perimetrale è d’obbligo, specie se vista in correlazione con la segmentazione dei componenti di rete: il Web Server, per intenderci, deve andare in Dmz, l’interazione con il Database deve essere vincolata da policy ben precise, così come l’autenticazione dei buyer. Se si utilizzano Token di qualsiasi genere, che la scelta cada su supporti facilmente distribuibili, poco costosi, riutilizzabili, anti tampering, e, soprattutto, trasparenti per l’utente finale.

L’interazione con altri sistemi di pagamento e soluzioni aperte, infine, è fondamentale nella misura in cui è importante avere una piattaforma che possa interagire, in qualsiasi momento, con gli altri standard de facto in materia di pagamenti. L’acquirente, dal canto suo, potrebbe valutare l’adesione ad un circuito a larga diffusione e possibilmente gratuito (la sicurezza non serve a nulla se non ci sono i merchant presso i quali acquistare, se poi per aderire bisogna spendere è ovvio chiedere di più); l’utilizzo di piattaforme oggettivamente sicure ma semplici da utilizzare (la sicurezza non serve più di tanto se per raggiungerla devono essere seguite procedure troppo complesse per un utente medio); la possibilità di un “cross use”, cioè di poter effettuare tutte le transazioni che si vuole, con più merchant possibili, indipendentemente dalla piattaforma che si sta usando in un determinato momento e, soprattutto, con tutte le carte di credito di cui si è dotati.