1001 maniere di garantire la realizzazione di un sistema chiuso e non interoperabile

Sistemi chiusi

ing. Gianni Becattini

2

Sistemi chiusi

Basta. Abbiamo parlato fin troppo di sistemi aperti, lasciandone l’essenza all’intuizione.

La buona abitudine di parlare di tutto sempre in termini positivi non sempre è benefica. In

certi casi, bisogna conoscere il peccato per evitarlo ed affrontare i problemi guardandoli dritti

negli occhi.

Questa volta vorrei insomma approfondire un tema particolarmente delicato ed impor-

tante, che ritengo essere di massima importanza per gli operatori del settore e di considerevo-

le interesse economico per la Pubblica Amministrazione e quindi di noi tutti.

Definizioni

Ma quando è che un sistema è aperto? Definirlo in termine di caratteristiche tecniche non

è facilissimo mentre è facilissimo farlo in termini di risultati. Direi che “un sistema è aperto

quando consente sviluppi da parte di terzi senza eccessiva dipendenza dal fornitore originale”. Poiché

molti sanno dove sono nato e che anche io appartengo a codesta lodata categoria, qualcuno

mi potrebbe dire, in vernacolo toscano: “Obbravo grullo! Insegnagnene anche.... Chetati, che poi si

fa icchèssivole...”. Ci potrebbe essere un fondo di verità (attimo di dubbio), ma poi no... ...sono

convinto, come illustrerò meglio, che sul lungo periodo, la fornitura di sistemi aperti sia an-

che conveniente per chi li realizza.

L’eterno paragone, il PC

Ci si potrebbe chiedere se un PC si possa considerare come un sistema aperto o come uno

chiuso, ma il discorso si farebbe complicato, in quanto sul fenomeno PC entrano in gioco fat-

tori del tutto anomali per la particolare posizione di Microsoft nella galassia che abitiamo.

Certo che siamo sempre meno proprietari dei nostri computer, più o meno forzati a usare i

programmi di Redmond e ad aggiornarli di continuo con nuove versioni, a meno che non si

decida di saltare il fosso e passare a soluzioni open source, che comportano tuttavia una serie

di controindicazioni.

3

Se la domanda viene posta a Michele, un mio amico che fa lo studente di ingegneria, ci di-

rà che niente è più cupamente chiuso del mondo Microsoft, e lo dirà sottovoce e guardandosi

attorno, convinto che le spie di Billy siano ovunque, pronte a imbottire di tritolo l’auto di ogni

evangelizzatore di soluzioni aperte. Ma a ben vedere, la dittatura del colosso americano po-

trebbe essere annoverata tra quelle “illuminate”, ed è proprio in ciò che sta la sua straordina-

ria potenza. Immaginiamo un mondo dove il PC, il monitor, il mouse o qualunque altro pro-

gramma dovesse essere necessariamente Microsoft. Vuoi comprare un programma CAD? Lo

compri da Microsoft, se ce l’ha, se no aspetti... Vuoi aggiungere una stampante? La compri da

Microsoft, se ce l’ha, se no puoi acquistarla altrove e chiedere a Microsoft un’offerta, perché la

stessa, e solo la stessa, provveda all’integrazione, sperando che non ne approfitti troppo e che

ti possa chiedere, diciamo, “solo” centomila cocuzze...

Sorridete? Fate male, perché quello che sembra un paradosso è semplicemente la regola

per un certo numero di Sistemi di Bigliettazione Elettronica.

Andiamo a fondo

Questo tuttavia è un articolo tecnico e quindi le considerazioni terminano qui, tanto

ognuno è perfettamente in grado di formarsi la propria opinione circa le conseguenze perni-

ciose dell’adozione un sistema chiuso.

Quello che approfondiremo, nelle note che seguono, è l’esame tecnico delle soluzioni fina-

lizzate a rendere chiuso il sistema e l’acquirente prono alla volontà del fornitore.

Protezioni hardware

Nel caso del PC, la protezione del fornitore è qualche volta costituita dalla famosa “chia-

vetta”, detta anche dongle, un tempo montata sulla porta della stampante parallela, oggi più

spesso in forma USB. Si è sempre trovato finora un qualche informatico volpino capace di

renderla inoffensiva, in modo da gabbare il produttore del software con copie abusive. Oltre-

tutto la chiavetta è totalmente inutile, dal punto di vista dell’utente, che non si mette certo a

4

piangere se può trasformarla in un portachiavi. Certo è che le protezioni hardware sono sem-

pre più toste.

Nei Sistemi di Bigliettazione Elettronica si ha sempre un dongle a tutela del fornitore, dalle

dimensioni fisiche ben più grandi della chiavetta USB. In essi, infatti, la chiavetta è costituita

da tutta la non trascurabile infrastruttura hardware a corredo del sistema stesso, ad esempio

le validatrici montate sui bus (tanto per parlare di corda in casa dell’impiccato...), con una

fondamentale differenza: se il dongle interessa all’utente più o meno quanto un cucchiaio di

olio di fegato di merluzzo, gli apparati costituiscono una componente ineliminabile, in quanto

indispensabile, dell’Automatic Fare Collection System.

Ovvio è, quindi, che un Sistema di Bigliettazione Elettronica ben si presta a diventare

chiuso se non si adotta la contromisura di imporre una serie di vincoli di apertura, utili non

solo per non assumere un ruolo subordinato verso chi vende la tecnologia ma anche per ren-

dere possibile l’integrazione tra apparati e sistemi diversi, oggi sempre più importante dato il

numero crescente di sistemi elettronici chiamati a convivere sugli autobus e nelle stazioni.

Come mio solito, per competenza, limiterò la mia analisi agli apparati di bordo, che sono

anche gli ospiti elettivi del batterio della chiusura.

L’applicazione

Gli apparati di bordo, che d’ora in poi per brevità chiamerò anche ADB, potrebbero essere

classificati come “sistemi embedded” (fig. 1) , ma di tipo un po’ particolare.

Secondo Wikipedia, “con il termine sistema embedded (sistema incapsulato, dedicato) si iden-

tifica genericamente un sistema elettronico a microprocessore, progettato appositamente per una deter-

minata applicazione, con una piattaforma hardware ad hoc, integrato nel sistema che controlla e in gra-

do di gestirne tutte o parte delle funzionalità”. E fin qui ci siamo.

5

“Contrariamente ai computer generici”, continua Wikipedia, “un sistema embedded ha dei com-

piti conosciuti già durante lo sviluppo, che eseguirà dunque grazie ad una combinazione hard-

ware/software specificamente studiata per la tale applicazione”. E qui cominciamo a non esserci più,

soprattutto con l’esempio riportato da Wikipedia relativo alle centraline ABS delle auto. I no-

stri ADB, infatti, per essere aperti, devono poter svolgere non solo i compiti conosciuti duran-

te lo sviluppo, bensì essere appunto “aperti”, stante la continua evoluzione dei SBE.

Gli ADB sono insomma dei particolari sistemi embedded che devono consentire al biso-

gno di poter scrivere nuove applicazioni o modificare quelle esistenti.

Strumenti di sviluppo

Per fare questo, non basta disporre delle necessarie competenze, ma si deve disporre di

quegli strumenti che consentano di scrivere un programma in un linguaggio ad alto livello

(es. C/C++) e tradurlo nel relativo codice macchina che il processore dell’ADB può eseguire

(applicazione eseguibile).

6

Questo insieme di strumenti, detti in genere strumenti di sviluppo (“development tools”) so-

no tutt’altro che banali, e comprendono, per limitarsi agli elementi più comprensibili da parte

dei non addetti:

cross-compilatore – è un programma che opera su PC e traduce un file testuale, scritto

secondo le regole di un linguaggio convenzionale, in un “modulo” scritto in meta codi-

ce rilocabile, da usarsi nei passaggi successivi per la creazione dell’applicazione ese-

guibile.

librerie – librerie di funzioni già pronte, proprie del linguaggio utilizzato.

linker – consente di mettere assieme i moduli generati dal cross-compilatore e di colle-

garli alle librerie; permette anche la “localizzazione”, ossia la trasformazione del meta

codice rilocabile in codice effettivo eseguibile.

loader/debugger – strumenti per trasferire l’applicazione così creata nell’ADB e pro-

varla con una serie di facilità.

Gli strumenti di sviluppo sono specifici di un certo microprocessore, quello usato

nell’ADB, e non sono quindi intercambiabili, al pari delle medicine che fanno venire il latte al-

le partorienti che, con tutta la buona volontà del medico, non possono essere usate contro le

polmoniti (cfr. E. De Filippo, Napoli milionaria, Napoli, 1945).

Possiamo quindi mettere un primo punto fermo:

1° legge dei sistemi chiusi - mai rendere disponibili gli strumenti di sviluppo per l’ADB.

Si osservi che l’apertura da questo punto di vista non coincide necessariamente con lo

“open source”. Chi sviluppa un applicazione non deve per forza distribuirla a chiunque sotto

forma sorgente. Il punto importante è che sia comunque possibile ad altri scrivere nuove ap-

plicazioni.

7

I/O e sistema operativo

Se ho superato la legge n.1, me ne torno in ufficio bel bello con il mio pacco sotto al brac-

cio, contenente gli strumenti di sviluppo, (oh, come mi voglio divertire, oh come mi voglio diverti-

re...) e... potrei scoprire che il mio pacco... contiene un “pacco” (nella partenopea accezione).

Spieghiamoci con un esempio che, mi auguro, dovrebbe risultare comprensibile a tutti.

Consideriamo il seguente frammento di codice C:

int a=5,b=7,c;

c = a + b;

La notazione è sufficientemente intuitiva e anche un non addetto comprende facilmente

che con questa notazione si intende richiedere al nostro ADB di eseguire una somma di due

valori. Ma, cui prodest? Qualunque operazione di elaborazione è del tutto inutile se alla fine

non è prevista una qualche operazione di emissione del risultato, che può tradursi nelle azio-

ni più differenti (visualizzazione di un messaggio sul display, su un PC collegato,

l’accensione di un LED, lo squillo di una tromba... beh, più modestamente, il suono del bip...).

L’esecuzione di operazioni di I/O (ingresso/uscita) non è generalmente semplice, e richie-

de tra l’altro una perfetta conoscenza dell’hardware dell’apparato. Anche sul PC, un pro-

grammatore scende ben difficilmente a studiarsi lo schema elettrico delle singole schede, ma

utilizza invece dei “servizi” messi a disposizione di una entità software chiamata “sistema

operativo”. Per completare l’esempio, il nostro amico softwarista potrebbe completare così il

programmino di cui sopra:

int a=5,b=7,c;

c = a + b;

printf (“%d”, c);

La funzione printf è una funzione tipica del linguaggio C che viene attuata per visua-

lizzare il risultato c sfruttando appunto i servizi del sistema operativo.

Si osservi che molti sistemi operativi standard (es. Windows o Linux) offrono milioni di

servizi assolutamente inutili per un sistema embedded e non offrono invece le funzioni indi-

spensabili per un ADB (vai a trovare in Windows la funzione “leggi / scrivi / verifica biglietto

8

magnetico”....). I servizi necessari all’ADB devono essere quindi presenti e (ben) documentati

a parte.

Possiamo quindi enunciare un’altra importante legge:

2° legge dei sistemi chiusi - mai documentare l’I/O ed il sistema operativo dell’ADB. Se proprio lo devi fare, fallo solo parzialmente (es. consegna i manuali di Windows).

Potremo dire di avere superato le prime due leggi dopo aver scritto un programma non

banale, dopo che lo avremo compilato e lo avremo provato (e solo allora).

I cosiddetti “kit di sviluppo” (Software Developer Kit, SDK) includono tutto quanto abbia-

mo descritto in precedenza. La loro disponibilità rappresenta la regola per la maggior parte di

apparati embedded (vedansi ad esempio i “POS”). Solo nel nostro mondo della bigliettazione

elettronica sono rari come le mosche bianche.

Potremmo quindi derivare un corollario che sintetizza le prime due leggi:

Corollario – non rendere mai disponibile il kit di sviluppo dell’ADB.

La sicurezza

Abbiamo affermato che gli apparati di bordo sono gli ospiti elettivi del batterio della

chiusura. Essi presentano, a loro volta, un’area ben particolare ove questi dannosi microorga-

nismi tendono ad annidarsi: quello della sicurezza. E questo per due motivi:

l’argomento sicurezza è “politically correct”; nessuno ci criticherà mai per averla fatta

troppo robusta;

i meccanismi di sicurezza, per la loro stessa natura, ben si prestano ad essere usati an-

che al fine della chiusura del sistema.

Ho raccolto una affermazione molto qualunquista ma non scevra di una certa saggezza

popolare: in assenza di grandi organizzazioni dedite alla falsificazione dei titoli di viaggio

elettronici, la sicurezza dei SBE è servita finora più a proteggere i fornitori dagli acquirenti

che non gli acquirenti dai malandrini....

9

Lo schema della sicurezza dei SBE è più o meno sempre basato su moduli SAM. Non vo-

gliamo spiegarne ancora una volta i meccanismi in questa sede. Diciamo solo che i moduli

SAM sono quelli che ospitano e custodiscono le chiavi crittografiche su cui si basa la sicurezza

del sistema, che, non esistendo quindi allo stato “libero”, si ritengono adeguatamente protet-

te.

Senza il possesso delle chiavi crittografiche, il legittimo proprietario del SBE non è in gra-

do di far produrre altre SAM o altre carte, ma è vincolato ogni volta ad approvvigionarsi dal-

lo stesso fornitore, delle cui quotazioni egli è in completa balìa. E’ una condizione molto simi-

le, anche se ben più grave, di quella tipica di molti siti Internet della prima ora, su cui è inter-

venuto anche il legislatore. Se non è pensabile che siti come bancaditalia.it o fiat.com, tanto

10

per dire una grulleria, possano risultare registrati a nome di Gennaro Mazzalabate o di Anto-

nio La Quaglia, così non appare del tutto logico che le chiavi di sicurezza di una grande com-

pagnia di trasporto pubblica appartengano ad un fornitore.

Ammesso quindi che non confligga con la Legge (quella con la “L” maiuscola”), mi sento

di enunciare la

3° legge dei sistemi chiusi – registrare a proprio nome le chiavi della sicurezza e non consegnarle mai al cliente.

Gli standard

Uno standard tecnico è un insieme di norme o di requisiti predeterminati. In pratica esso

è un documento formale che stabilisce criteri tecnici, metodi o processi uniformi. Ma anche

negli standard si aggirano i nostri pericolosi microorganismi della chiusura. Oibò, si potrebbe

obiettare, sembrerebbe proprio il contrario!

In effetti, scopo degli standard è quello diametralmente opposto alla chiusura ma un loro

perverso side effect è proprio questo. Infatti:

l’indicazione di uno standard definito ammanta di virtù colui che lo sbandiera e tran-

quillizza l’acquirente, che abbassa così la propria soglia di precauzione;

l’inserire chiusure nelle aree marginali non definite dagli standard garantisce

l’impossibilità della interoperabilità con altri apparati simili ed assicura una tranquilla

vecchiaia al fornitore.

Una situazione di questo tipo si verifica spesso con l’impiego di smart card in accordo al-

lo standard Calypso, che non ha ancora terminato di definire ad oggi tutti livelli necessari ad

un Sistema di Bigliettazione Elettronica (vedi figura). In pratica si ha:

livelli 1 e 2 – perfettamente definiti (ISO 14443B 1-4 e 7816 1-4);

livello 3 – perfettamente definito, utile, indispensabile, ma non fa quello che i più cre-

dono. La ENV 1545 definisce infatti le possibili strutture dei dati, non la struttura dati

11

della carta. In parole semplici: se devi usare un campo data, la ENV-1545 ti dice come

lo devi codificare, ma non definisce un “tracciato record” della carta.

livello 4 – perfettamente definito, almeno per quanto ci serve;

livello 5, 6 e 7 – in corso di definizione e comunque definiti “in casa” in tutti i sistemi

che conosco.

Calypso è oggi la cosa più vicina ad una soluzione per il problema dell’apertura, ma, in

attesa dello standard, si deve stare molto attenti alle pericolose implicazioni dei livelli 5, 6 e 7.

E’ infatti in essi che, come facilmente intuibile, si generano le peggiori infezioni della

“chiusurite”. Posso avere carte e SAM assolutamente standard, posso avere le chiavi della si-

curezza, ma se non so dove stanno i dati sulla carta, il loro significato e le regole per proces-

12

sarli sono ancora una volta tagliato fuori dal mio stesso sistema. Ecco quindi piombare come

un falco la

4° legge dei sistemi chiusi – dichiarare uno standard ma non comunicare tracciato e semantica dei dati né le relative regole di processo

Corollario: non rilasciare mai le specifiche del sistema – altri fornitori potrebbero offrire una im-plementazione migliore della tua.

Per completezza va detto che anche i biglietti magnetici sono similmente vulnerabili, de-

finendo gli standard relativi (es. ENV 753, ISO 15457) solo gli aspetti fisici e di registrazione. Il

senso dei dati è indefinito più o meno come in Calypso.

Terminator strikes back!

Come in tutti i thriller deteriori, all’ultima scena il cattivo sembra morto ma poi.... zzzack!

....non era morto bene e agguanta per la caviglia la povera vittima che si credeva ormai salva.

Alla stessa maniera, a sera il povero responsabile del SBE se ne va sotto la doccia stanco e

felice, ripassandosi mentalmente le regole: “..allora, ho i tools di sviluppo, tutte le informazioni su-

gli ADB, seguo uno standard, ho definito i tracciati dati, i loro significati, le regole di processo....”

Mai fare la doccia in un thriller! Le maniere di creare un sistema chiuso non sono finite e

la sagoma dell’assassino non tarderà a delinearsi dietro il vetro della doccia.

Penso che questo appuntamento sia già stato fin troppo pesante, mi limiterò quindi a cita-

re solo alcuni esempi di ulteriori possibili focolai di infezione:

usare parti fuori dagli standard, ad esempio smart card e SAM che nessuno conosce.

Direi che questo potrebbe essere annoverato tra i colpi da maestro del buon chiusuri-

sta;

utilizzare sub processori (fig. 2) per l’esecuzione di funzioni critiche per il sistema, di

cui non si forniscano le stesse informazioni (kit di sviluppo ecc.) che non per l’ADB.

13

Basti pensare ad un sottosistema indipendente per il processo delle carte contactless

che mi limitasse volutamente all’impiego di alcune carte e non altre.

mancanza di informazioni sui protocolli di comunicazione o addirittura loro crittogra-

fazione;

mancanza di informazioni sulla semantica dei file o sulle configurazioni o addirittura

loro crittografazione;

ecc. ecc.

Come si vede, mille sono le maniere per mantenere chiuso un sistema e mille devono per-

tanto essere le cautele che si pongono in atto nella realizzazione di un Sistema di Bigliettazio-

ne Elettronica.

Conclusioni

I sistemi chiusi e non interoperabili sono dannosi per chi li acquista e quindi, nel nostro

caso, anche per la collettività.

14

Molte situazioni di chiusura nascono da una precisa strategia e richiedono investimenti

cospicui (mettere a punto sistemi crittografati, creare blocchi ecc.); anche l’apertura richiede

investimenti in misura pari o addirittura superiore (realizzare la documentazione, rendere di-

sponibili i kit di sviluppo ecc.).

L’apertura di un sistema non è mai casuale. L’apertura consegue ad una precisa volontà

del fabbricante e non si implementa semplicemente omettendo azioni di chiusura, bensì con

l’esecuzione di un piano preordinato e complesso finalizzato a trasferire le necessarie infor-

mazioni agli sviluppatori e a facilitarne il compito anziché ostacolarlo.

Resto a disposizione via mail g.becattini@aep-italia.it .