Studio e progettazione di una soluzione di firma elettronica conforme alla normativa italiana

Università degli Studi di Padova

D MC L I

Studio e progettazione di una soluzione di irmaelettronica conforme alla normativa italiana

Tesi di laurea triennale

Laureando

Marco NegroRelatore

Prof. Mauro Conti

Azienda ospitante

Accenture Technology SolutionsTutor aziendale

Paolo Colombo

A A 2012-2013

Marco Negro: Studio e progettazione di una soluzione di irma elettronica conformealla normativa italiana, Tesi di laurea triennale, Feb 2013.

La disumanità del computer sta nel fatto che, una volta programmato e messo infunzione, si comporta in maniera perfettamente onesta.

— Isaac Asimov

Alla mia famiglia,ai miei amici,

a te

Sommario

Al termine del ciclo di studi per il conseguimento della laurea triennale in in-formatica lo studente e tenuto a svolgere un’attivita di stage obbligatoria pressoun ente ospitante o internamente all’universita. Se svolta presso un’azienda l’at-tivita prevede la programmazione di un piano di lavoro con precisi obiettivi daperseguire, per un impegno di circa 300 ore.

Il contenuto di questo documento riguarda l’ambiente lavorativo in cui ha tro-vato sede lo stage, le attivita di studio e di af iancamento alle fasi operative e unavalutazione personale dell’esperienza svolta.

Il mio apporto al progetto ospitato da Accenture prevedeva l’af iancamento algruppo di lavoro che si occupa dello sviluppo di un sistema per la irma elettronicadi documenti in formato PDF su dispositivi tablet. Il sistema prodotto verra utiliz-zato dagli agenti del richiedente per sottoscrivere contratti con i propri clienti. Lasoluzione ha come requisito fondamentale l’essere abilitante per la validita legaledella irma elettronica, secondo le normative vigenti.

Il mio lavoro si e basato sul raggiungimento di obiettivi precisi quali• studio approfondito della normativa;• studio delle tecnologie necessarie per lo sviluppo di una soluzione di irmaelettronica;

• supporto alla progettazione del sistema;• sviluppo di integrazioni per testare l’interazione tra i vari componenti delsistema.

Disclaimer

Accenture Technology Solutions garantisce ai suoi clienti la massima riserva-tezza nel trattamento di dati sensibili quali software e hardware utilizzati nel pro-dotto inale, con igurazioni dell’infrastruttura,metodologie di sviluppo ematerialeinformativo. Il cliente, il software di gestione delle irme e le funzioni da esso of-ferte verranno anonimizzati sostituendoli con nomi inventati. Qualora si riconoscauno qualsiasi di questi identi icativi in un prodotto o ente reale la si deve ritenerecome una pura casualita.

v

Indice

1 Il contesto aziendale 11.1 Accenture e Accenture Technology Solutions . . . . . . . . . . . . . 11.2 Servizi offerti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Aree di intervento e clienti . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Accenture Delivery Methods . . . . . . . . . . . . . . . . . . . . . . . 31.5 Riconoscimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 La firma elettronica 52.1 Validita della irma elettronica . . . . . . . . . . . . . . . . . . . . . . 52.2 Le tipologie di irma . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Firma elettornica . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Firma elettronica avanzata . . . . . . . . . . . . . . . . . . . 62.2.3 Firma elettronica quali icata . . . . . . . . . . . . . . . . . . 72.2.4 Firma digitale . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 La irma grafometrica . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Il collegamento con il documento . . . . . . . . . . . . . . . . . . . . 102.5 La validazione temporale . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Il progetto aziendale 133.1 Il progetto Firma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 La irma grafometrica come soluzione . . . . . . . . . . . . . 143.2 Funzionalita richieste . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Il software di irma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4 L’architettura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 223.5 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Lo stage 254.1 Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 Gli obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.2 Piani icazione del lavoro . . . . . . . . . . . . . . . . . . . . . 26

4.2 Studio della normativa . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2.1 Direttiva 1999/93/CE . . . . . . . . . . . . . . . . . . . . . . 274.2.2 Codice dell’amministrazione digitale . . . . . . . . . . . . . . 284.2.3 Determinazioni DigitPA . . . . . . . . . . . . . . . . . . . . . 29

4.3 Studio delle tecnologie abilitanti . . . . . . . . . . . . . . . . . . . . . 294.3.1 HSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3.2 Trusted timestamping . . . . . . . . . . . . . . . . . . . . . . 31

vii

Indice

4.3.3 Certi icati e crittogra ia in ambiente Microsoft Windows . . 324.4 Studio del componente di irma . . . . . . . . . . . . . . . . . . . . . 35

4.4.1 Ambiente di test . . . . . . . . . . . . . . . . . . . . . . . . . . 354.4.2 Studio di HandSign Server . . . . . . . . . . . . . . . . . . . . 364.4.3 Studio dell’SDK HandSign Mobile Client per Android . . . . 43

4.5 Supporto alla progettazione . . . . . . . . . . . . . . . . . . . . . . . 474.5.1 Speci ica di interfaccia . . . . . . . . . . . . . . . . . . . . . . 474.5.2 Piani icazione e progettazione dei test . . . . . . . . . . . . . 55

4.6 Supporto allo sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . 594.6.1 Applicativo Android di prova . . . . . . . . . . . . . . . . . . 594.6.2 Sviluppo del plug-in di prova per l’HSM . . . . . . . . . . . . 62

5 Valutazione retrospettiva 675.1 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.2 Preparazione accademica e mondo del lavoro . . . . . . . . . . . . . 67

Glossario 69

Acronimi 73

Bibliografia 75

viii

Elenco delle figure

2.1 Procedura di collegamento dei dati al documento . . . . . . . . . . . 112.2 Procedura di veri ica del collegamento dei dati al documento . . . . 11

3.1 Use case delle funzionalita offerte dal sistema . . . . . . . . . . . . . 193.2 Diagramma di attivita della procedura di irma richiesto . . . . . . 203.3 Schema del funzionamento del sistema di irma . . . . . . . . . . . . 233.4 Architettura del sistema di irma . . . . . . . . . . . . . . . . . . . . 23

4.1 Diagramma Gantt delle attivita piani icate . . . . . . . . . . . . . . . 274.2 Esempio di dispositivi HSM. . . . . . . . . . . . . . . . . . . . . . . . 314.3 Documento con stringhe per irma. . . . . . . . . . . . . . . . . . . . 404.4 Documento con campi irma . . . . . . . . . . . . . . . . . . . . . . . 414.5 Schermata di visualizzazione del documento da irmare . . . . . . . 454.6 Interfaccia di irma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.7 Visualizzazione del documento dopo l’apposizione della prima irma 464.8 Diagramma di distribuzione del sistema . . . . . . . . . . . . . . . . 494.9 Creazione di una procedura di irma . . . . . . . . . . . . . . . . . . 514.10 Avvio di una procedura di irma . . . . . . . . . . . . . . . . . . . . . 524.11 Registrazione di una irma . . . . . . . . . . . . . . . . . . . . . . . . 534.12 Accettazione di una procedura di irma . . . . . . . . . . . . . . . . . 544.13 Annullamento di una procedura di irma . . . . . . . . . . . . . . . . 544.14 Schema dell’ambiente utilizzato per lo sviluppo . . . . . . . . . . . . 62

ix

1 Il contesto aziendale

In questo capitolo si descrive il contesto aziendale che ha ospitato lo stage.L’attività è stata accolta da Accenture Technology Solutions ma il progetto nelquale si colloca lo stage è gestito da Accenture. Il contenuto del capitolo riporta inbreve la storia di queste due aziende e i servizi che esse offrono.

1.1 Accenture e Accenture Technology Solutions

Accenture e unamultinazionale di consulenza aziendale che comprende consu-lenza direzionale, servizi tecnologici e outsourcing.

Le sue origini risalgono al 1989 quando un gruppo di partner della divisionedi consulenza dell’Arthur Andresen si separarono dall’azienda madre e presero ilnome di Andersen Consulting. Le attivita principali su cui si focalizzava erano laconsulenza e i servizi tecnologici, orientati all’integrazione di sistemi su larga sca-la e al miglioramento dei processi aziendali. Lo stesso anno Andersen Consultingde inisce la sua struttura e i suoi processi interni; la societa si evolve e passa da afornitore di servizi tecnologici, consulenza manageriale e outsourcing.

Il 1 gennaio 2001 Andersen Consulting cambia il proprio nome in Accenture.Fin dal 1989 la societa non era altro che una partnership di entita private a livellolocale, dislocate in oltre 40 paesi. Sempre nel 2001 i partner Accenture deciserodi rivedere la struttura dell’azienda e la trasformarono in una corporation. Questascelta permise di favorire la crescita della societa e la costruzione di un capitale. Il19 luglio Accenture si quota alla borsa di New York, con il simbolo ACN.

Oggi Accenture serve i suoi clienti in oltre 120 paesi e conta piu di 257.000 di-pendenti. In Italia le societa del gruppo Accenture impiegano oltre 10.500 personenelle sedi di Milano, Roma, Torino, Napoli e in altri uf ici minori.

Accenture Technology Solutions e una societa del gruppo Accenture che si oc-cupa di sviluppare soluzioni applicative. E presente in Italia da settembre 2002con oltre 2.800 professionisti. Mette al servizio dei consulenti Accenture speciali-sti che hanno il compito di sviluppare programmi, produrre soluzioni applicativee gestire infrastrutture.

Offre servizi di realizzazione di sistemi informativi e applicativi ex-novo e la ge-stione di quelli gia esistenti attraverso interventi di manutenzione, miglioramentodelle performance e formazione dell’utilizzatore inale.

1

1 Il contesto aziendale

1.2 Servizi offerti

Il gruppo Accenture offre tre tipi di servizi.Management Consulting: af iancamento del cliente per l’individuazione di pos-

sibili cambiamenti strategici utili per l’incremento delle prestazioni dell’a-zienda. Alcuni dei servizi offerti sono l’incremento delle attivita analitiche,risk management, aiuto all’impiego di software aziendale basato su piatta-formamobile, miglioramento dell’ef icienza energetica, miglioramento dellasostenibilita ambientale e ottimizzazione della gestione delle relazioni con iclienti.

Technology: sviluppo e fornitura di soluzioni tecnologiche. Accenture fornisce aipropri clienti le soluzioni concrete richieste, spesso come naturale conse-guenza di una fase di consulting. Le tipologie di prodotti forniti vanno dal-la realizzazione di infrastrutture hardware, per le architetture di rete delleaziende e per i data center, allo sviluppo e integrazione di software o appli-cativi custom.

Outsourcing: Accenture offre ai propri clienti una gammadi servizimirati alla ge-stione di interi processi aziendali. Attraverso questo tipo di soluzioni i clientipossono focalizzarsi sul proprio obiettivo delegando ad Accenture la gestio-ne di processi aziendali, infrastrutture e applicazioni. Un esempio di serviziofornito in outsourcing e l’Infrastructure Outsourcing che prevede la creazio-ne ex-novodell’infrastruttura IT oppure lamigrazione della stessa dal clientead Accenture. Tali soluzioni permettono di ottenere una riduzione dei costidi gestione e di aggiornamento e la costruzione di un ambiente scalabile e dialta af idabilita.

1.3 Aree di intervento e clienti

Accenture copre con i suoi servizi svariate aree dimercato, operando nei settoridi produzione, lavorazione, terziario e per le pubbliche amministrazioni.

I servizi rivolti ad aziende produttive, come ad esempio agroalimentari, mi-nerarie e altre produzioni di materie prime, includono la fornitura di soluzioniindustriali per l’automazione di processi e impianti e per l’incremento dell’ef i-cienza energetica. Servizi di outsourcing e ottimizzazione della gestione e conta-bilita aziendale sono utilizzati da enti come pubbliche amministrazioni, agenzieaerospaziali e aziende private di ogni settore.

Accenture, nell’ultimo anno, annovera tra i suoi clienti 92 delle 100 aziende For-tune Global 100 e oltre tre quarti delle Fortune Global 500. In Italia lavora per 15tra i primi 20 gruppi inanziari nazionali, le prime 4 societa assicurative e 11 tra iprimi 15 gruppi industriali.

2

1.4 Accenture Delivery Methods

1.4 Accenture Delivery Methods

Per garantire al cliente un’elevata qualita del servizio richiesto, Accenture hasviluppato un insieme di metodologie per guidare i propri team in tutte le fasilavorative. Queste metodologie, de inite rigorosamente e facilmente ripetibili, so-no essenziali per garantire performance di alto livello in termini di riduzione deicosti, incremento della produttivita, rispetto delle scadenze, riduzione dei costi emiglioramento della qualita del processo produttivo.

Gli Accenture Delivery Methods si dividono nelle seguenti categorie:Management de iniscono una disciplina di condotta per garantire che i prodot-

ti richiesti vengano forniti in modo adeguato. Un esempio di ManagementMethod e l’Accenture Delivery Methods for Program, Project and Service Ma-nagement che ha lo scopo di piani icare e gestire tutte le azioni richieste persviluppare un qualsiasi tipo di progetto.

Implementation guidano i processi di progettazione, sviluppo e tutti i loro sot-toprocessi. Esempi di questa categoria sono metodi per lo sviluppo di pro-getti basati sul modello agile, progetti per lo sviluppo di applicativi custome progetti per il testing.

Operations guidano la fornituradi servizi come l’ApplicationOutsourcing, l’InfrastructureOutsourcing e il Business Process Outsourcing.

1.5 Riconoscimenti

A prova della propria qualita, Accenture ha ottenuto svariati riconoscimenti epremi tra i quali si possono riportare:

• nel 2012 si e classi icata all’internodiTop100MostValuableGlobalBrands;• nel 2012 si e posizionata al 69° posto dellaWorld’sMost Powerful Brands;• nel 2012 e stata insignita del premio Corporate Market of the Year;• nel 2012 si certi icata come Top Employers 2012 Italia per l’eccellenzadelle sue strategie in ambito HR;

• classi icata 6° nel 100 Best Corporate Citizens 2012 di Corporate Respon-sibility Magazine;

• inclusa nella Fortune Global 500, una classi ica delle 500 piu grandi corpo-razioni mondiali stilata per ricavi, per dieci anni consecutivi (2002-2011).

3

2 La firma elettronica

Per capire come è stato progettato l’intero sistema e che tipo di software è statoselezionato per la firma, è necessario analizzare il quadro normativo italiano perquanto concerne la firma elettronica. Tutti i concetti esposti in questo capitolo sonostati studiati durante la prima fase del periodo di stage.

2.1 Validità della firma elettronica

La normativa italiana riguardante la irma elettronica e composta da varie tipo-logie di documenti: Decreti Legislativi (D.Lgs.), Decreti del Presidente del Consigliodei ministri (DPCM), determinazioni DigitPA e delibere CNIPA. DigitPA e l’Ente na-zionale per la digitalizzazione della pubblica amministrazione (ex CNIPA: CentroNazionale per l’Informatica nella Pubblica Amministrazione); ha competenze nelsettore delle tecnologie dell’informazione e svolge funzioni di natura progettuale,tecnica e operativa al ine di creare valore attraverso la realizzazione dell’ammini-strazione digitale[11].

Il punto di partenza e il D.Lgs. n. 82 del 7 marzo 2005, chiamato Codice dell’Am-ministrazione Digitale (CAD), e successive modi iche.

All’articolo 21 e possibile trovare l’attribuzionedella validita legale ai documen-ti informatici sottoscritti con irma elettronica:

Il documento informatico sottoscritto con irma elettronica avanza-ta, quali icata o digitale, formato nel rispetto delle regole tecniche di cuiall’articolo 20, comma 3, che garantiscano l’identi icabilità dell’autore,l’integrità e l’immodi icabilità del documento, ha l’ef icacia prevista dal-l’articolo 2702 del codice civile. L’utilizzo del dispositivo di irma elettro-nica quali icata o digitale si presume riconducibile al titolare, salvo chequesti dia prova contraria.

Come speci icato dal precedente articolo, il documento informatico sottoscrittocon irma elettronica avanzata, quali icata o digitale, concetti trattati nella Sezione2.2, ha la stessa validita del documento cartaceo.

5

2 La irma elettronica

2.2 Le tipologie di firma

Prima di eseguire un’analisi della normativa con suf iciente dettaglio e utilecomprendere le varie tipologie di irma, quale di queste e stata selezionata e per-che. Questo ci permette di escludere dalla successiva analisi i dettagli tecnici ri-guardanti le tipologie di irme scartate.

Prendiamo le de inizioni dall’articolo 1, De inizioni, del D.Lgs. 7 marzo 2005, n.82 e successivi aggiornamenti. Tra gli aggiornamenti apportati a questo articolo ciinteressa in particolar modo quello del D.Lgs. 30 dicembre 2010, n. 235, che conl’articolo 1 introduce la de inizione di irma elettronica avanzata e con l’articolo 14le attribuisce piena validita giuridica.

2.2.1 Firma elettornica

Art. 1, comma 1, lettera q)irma elettronica: l’insieme dei dati in forma elettronica, allegati op-

pure connessi tramite associazione logica ad altri dati elettronici, utiliz-zati come metodo di identi icazione informatica;

Questo e il tipo di irma piu semplice e, come si legge dall’articolo 21 del D.Lgs. 7marzo 2005, n.82, non e utilizzabile per la sottoscrizione di un documento infor-matico.

La irma elettronica semplice prevede l’aggiunta al documento di un insieme didati che ha lo scopo di identi icare il irmatario. Con “metodo di identi icazione in-formatica” si intende un qualsiasi strumento di autenticazione, il quale puo andaredalla coppia username e password a un codice PIN.

Per semplicita e chiarezza, questo tipo di irma sara indicato nel resto di questodocumento come “ irma elettronica semplice”.

2.2.2 Firma elettronica avanzata

Art. 1, comma 1, lettera q-bis)irma elettronica avanzata: insieme di dati in forma elettronica al-

legati oppure connessi a un documento informatico che consentono l’i-denti icazione del irmatario del documento e garantiscono la connes-sione univoca al irmatario, creati con mezzi sui quali il irmatario puòconservare un controllo esclusivo, collegati ai dati ai quali detta irmasi riferisce in modo da consentire di rilevare se i dati stessi siano statisuccessivamente modi icati.

La irma elettronica avanzata e un’evoluzione della irma elettronica semplicee comporta tre nuove caratteristiche per i dati che la compongono:

1. connessione univoca al irmatario;

6

2.2 Le tipologie di irma

2. creati conmezzi sui quali il irmatario puo conservare un controllo esclusivo;3. collegati ai dati ai quali la irma si riferisce.Con la prima caratteristica si vuole indicare che, a differenza della irma elettro-

nica semplice, l’insieme dei dati connessi al documento deve identi icare univoca-mente il irmatario. Imetodi di identi icazione informatica nonpermettono, infatti,l’associazione univoca al irmatario. Basti pensare a come e possibile ottenere unacoppia di username e password o il codice PIN di un altro utente.

Questa de inizione non speci ica la tipologia dei dati richiesti ma indica che essidevono essere caratteristici del irmatario. Dati di questo tipo si possono ottenere,ad esempio, richiedendoli a un ente apposito che prima di effettuare l’erogazioneidenti ica il richiedente per mezzo di un pubblico uf iciale o entita preposta e loassocia univocamente ai dati forniti. Un’altra tipologia di dati validi a questo sco-po e quella che solo il irmatario puo produrre: viene quindi concesso l’utilizzo dicaratteristiche biometriche suf icientemente accurate. Questa seconda considera-zione e di cruciale importanza perche, se la raccolta dei dati viene fatta unitamenteall’identi icazione del irmatario, puo evitare l’uso di un certi icato digitale.

Il secondopunto indica che l’apposizionedella irmadeveavvenire tramitemez-zi sui quali il irmatario deve possedere il controllo esclusivo. Questo e possibilenel caso di irma con certi icato usando una smart card oppure un sistema di irmaremota di proprieta del sottoscrivente. Per la sottoscrizione con dati biometriciquesto vincolo e implicitamente soddisfatto perche la produzione dei parametriusati per la irma e fatta direttamente dal irmatario.

L’ultimo punto impone la necessita di collegare i dati che compongono la ir-ma con il documento sottoscritto di modo da poter rilevare eventuali modi icheapportate in seguito alla irma. Solitamente l’integrita del documento si puo otte-nere aggiungendo al documento “un’impronta” dello stesso calcolata usando unafunzione hash e irmata utilizzando una chiave privata.

2.2.3 Firma elettronica qualificata

Art. 1, comma 1, lettera r)

irma elettronica quali icata: un particolare tipo di irma elettroni-ca avanzata che sia basata su un certi icato quali icato e realizzata me-diante un dispositivo sicuro per la creazione della irma.

Oltre a dover rispettare tutte le caratteristiche della irma elettronica avanzata,per la irma quali icata vengono delineati altri due requisiti: i dati allegati al do-cumento devono basarsi su un certi icato quali icato e la generazione della stessadeve essere realizzata mediante un dispositivo sicuro.

In questo caso e richiesto l’uso di un certi icato quali icato che deve essere as-sociato al irmatario in modo univoco e deve essere rilasciato da un’autorita certi-icata. L’utilizzo di un certi icato aggiunge alla irma la proprieta del non ripudio.

7


Essendo richiesto un certi icato quali icato non e piu possibile utilizzare dati ditipo biometrico.

E inoltre richiesto l’uso di un dispositivo sicuro per la generazione della irma.I requisiti obbligatori per tali dispositivi sicuri di irma sono dettati:

• a livello internazionale della direttiva 1999/93/CE, allegato III del 13 dicem-bre 1999;

• sul piano generale dal D.Lgs. 7 marzo 2005, n.82, e successive modi iche,articolo 35;

• sul piano tecnico dalla bozza delle nuove Regole tecniche irma digitale[22],che sostituiranno quelle de inite nel DPCM 30 marzo 2009 a ine iter di ap-provazione, articoli 11 e 12.

2.2.4 Firma digitale

Art. 1, comma 1, lettera s)

irma digitale: un particolare tipo di irma elettronica avanzata ba-sata su un certi icato quali icato e su un sistema di chiavi crittogra iche,una pubblica e una privata, correlate tra loro, che consente al titolaretramite la chiave privata e al destinatario tramite la chiave pubblica,rispettivamente, di rendere manifesta e di veri icare la provenienza el’integrità di un documento informatico o di un insieme di documentiinformatici.

L’ultimo tipo di irma, quella digitale, e equivalente a quella elettronica qua-li icata ma si basa sulla crittogra ia asimmetrica per la generazione della irmastessa[7].

L’utilizzo di questo tipo di crittogra ia permette a chiunque sia in possesso dellachiave pubblica di veri icare che il documento sia effettivamente integro e che ilirmatario sia quello associato al certi icato.In questa de inizione non e speci icata la necessita di utilizzare un dispositivo

sicuro ma e comunque necessario dal fatto che, perche facente parte della cate-goria di irme elettroniche avanzate, la irma deve essere prodotta con mezzi suiquali il irmatario ha il controllo esclusivo. Nelle regole tecniche sono speci icatenel dettaglio le caratteristiche che tale dispositivo deve possedere.

2.3 La firma grafometrica

La irma grafometrica e un particolare tipo di irma elettronica avanzata che uti-lizza, come dati allegati al documento che identi icano univocamente il irmatario,un insieme di parametri biometrici caratterizzanti la irma autografa.

8

2.3 La irma grafometrica

L’insieme delle informazioni raccolte per comporre la irma grafometrica com-prende sia dati statici che dinamici e precisamente possono essere:

• immagine della irma. Questa immagine e inserita nel documento e lo rendesimile, dal punto di vista dell’utente, a un classico documento cartaceo. E l’u-nico dato che si puo vedere direttamente aprendo il documento informaticoed e un dato di tipo statico;

• velocita di scrittura;• angolo di inclinazione della penna;• pressione esercitata sulla super icie;• accelerazione del movimento;• numero di sollevamenti della penna.Vi sono sul mercato numerosi prodotti che permettono l’acquisizione di que-

sti dati, chiamati comunemente “pad”. L’avvento di smartphone e tablet dotati ditouch screen ha reso possibile il loro utilizzo per questo scopo, accompagnati daun’apposita penna.

Oltre ai dispositivi di acquisizione della irma e necessario considerare i pro-dotti software che si occupando della gestione e analisi dei dati acquisiti. Vari pro-duttorimettono a disposizione soluzioni in grado di gestire e preparare questi datiper il salvataggio su documenti digitali. Assieme agli strumenti di gestione, sono difondamentale importanza algoritmi e applicazioni di analisi in grado di garantirela possibilita di eseguire una veri ica di corrispondenza tra due irme.

La irma grafometrica e caratteristica di ogni singola persona e come tale non epossibile garantire una veri ica certa al 100%. Per questomotivo i software di ana-lisi devono confrontarsi con due parametri molto importanti: il False AcceptanceRate (FAR) e il False RejectionRate (FRR). Questi due fattori, espressi in percentua-le, indicano con quale frequenza una irma falsa viene considerata come autenticae con quale frequenza una irma autentica viene ri iutata. La calibrazione di questiparametri puo essere fatta in fase di acquisizione del pro ilo di irma del irmata-rio. I fornitori non indicano i valori che i loro prodotti utilizzano, quindi il grado diaf idabilita che garantiscono. L’obiettivo e cercare di calibrare l’acquisizione dellairma in modo da ottenere un buon compromesso tra usabilita e af idabilita, cer-cando di massimizzare il ri iuto delle irme false e l’accettazione di quelle vere. Eaccettabile il compromesso di aumentare la percentuale di ri iuto di irme auten-tiche a fronte di minimizzare l’accettazione di irme false. Dei valori indicativi perquesti due parametri possono essere FAR < 0.6% e FRR < 2.8%[18].

La variabilita nel tempo e un altro fattore considerato della irma grafometrica.I software di veri ica tengono conto di questa caratteristica e sono in grado di ac-cettare l’evoluzione del pro ilo calligra ico di un utente. L’evoluzione della irma,unita al fatto che anche il irmatario stesso non riuscira mai a produrre due irmeidentiche, rende questo sistema di sottoscrizione resistente ad attacchi basati sulriutilizzo di irme valide da parte di malintenzionati.

9


Per queste ragioni l’acquisizione di dati dinamici, oltre all’immagine classicadella irma, rende questo tipo di sottoscrizione molto piu af idabile della irmaautografa classica.

2.4 Il collegamento con il documento

Un altro aspetto che merita particolare attenzione e il collegamento della ir-ma al documento. Questa caratteristica deve essere garantita per evitare che lairma risulti valida in seguito alla modi ica dei dati sottoscritti. Nel caso particola-re del formato PDF le caratteristiche che deve possedere una irma elettronica ela metodologia con la quale questa deve essere integrata nel documento sono de-lineate con lo standard PDF Advanced Electronic Signatures (PAdES), pubblicatodall’European Telecommunications Standards Institute (ETSI) con l’identi icativoTS 102 778[14] e derivato dallo standard ISO 32000-1[17].

Per collegare una irma ad un documento, e quindi permettere l’immodi icabili-ta dello stesso, si utilizza il concetto di “impronta” di un dato elettronico. L’impron-ta e la rappresentazione del documento elettronico composta da una sequenza disimboli binari di lunghezza issa; viene generata da una funzione chiamata “fun-zione hash” e viene usata come identi icativo univoco del documento. Le funzionihash garantiscono che non sia possibile ricostruire il contenuto di un documentopartendo dalla sua impronta; esse non hanno quindi una corrispondente funzioneinversa.

E possibile riassumere brevemente la procedura di aggiunta della irma al do-cumento, rappresentata in Figura 2.1, nei seguenti passaggi:

1. calcolo dell’impronta del documento attraverso una funzione hash;2. aggiunta dei dati riguardanti la irma (possono essere i dati in chiaro, i dati

criptati o una loro impronta) all’impronta del documento;3. calcolo dell’hash di questo nuovo insieme di dati;4. irma dell’ultimo hash calcolato con una chiave privata associata ad un cer-

ti icato;5. aggiunta della irmaprodotta nel punto 4, del certi icato associato alla chiave

privata usata al punto 4 e dei dati riguardanti la irma al documento.In questomodo l’integrita del documento e facilmente veri icabile da chiunque,

decifrando i dati aggiunti al documento con la chiave pubblica associata al certi-icato. La procedura di veri ica, rappresentata in Figura 2.2, comprende i seguentipassi:

1. calcolo dell’impronta del documento attraverso la funzione di hash;2. aggiunta all’impronta del documento i dati riguardanti la irma;3. calcolo dell’hash di questo nuovo insieme di dati;

10

2.4 Il collegamento con il documento

4. decifratura dell’impronta del documento e della irma con la chiave pubblicadel certi icato allegato;

5. confronto delle due impronte ottenute nei passi 3 e 4.

01001 … 11010

CIFRATURA

01001 … 11010

HASH

1

2

3

4

5

HASH

01001 … 11010

Figura 2.1: Procedura di collegamento dei dati al documento

01001 … 11010

01001 … 11010

12

3

4

5

01001 … 11010

HASH

01001 … 11010

DECIFRATURA

HASH

Figura 2.2: Procedura di veri ica del collegamento dei dati al documento

11


2.5 La validazione temporale

La normativa prevede il riconoscimento dell’esistenza di un’evidenza informa-tica in un tempo certo se questa e accompagnata da unamarca temporale. Le carat-teristiche che le marche temporali devono possedere sono delineate nello Schemadi DPCM Regole tecniche irma digitale, che sostituira il DPCM 30 marzo 2009 at-tualmente valido, e nella deliberazioneCNIPAn. 45del 21maggio2009. Se lamarcatemporale e stata creata secondo le regole de inite dalla normativa, l’esistenza, inun determinato momento, dell’evidenza informatica a essa associata e opponibi-le a terzi. Sebbene sia consigliata, l’apposizione di marche temporali ai documentiinformatici non e obbligatoria. L’uso di questo sistema e indicato per evitare che ilirmatario falsi ichi la data di apposizione della irma.La procedura per la generazione delle marche temporali e uguale a quella de-

scritta nella Sezione 2.4, sostituendo ai dati di irma la data e l’ora.Le regole tecniche contenute in Regole tecniche irma digitale de iniscono, nel

Titolo IV, Regole per la validazione temporalemediantemarca temporale, come vie-ne effettuata la validazione temporale, quali informazioni devono essere contenu-te nella marca temporale, le regole di utilizzo e gestione di chiavi e certi icati ele caratteristiche del servizio di marcatura temporale quali sicurezza, precisione,conservazione e metodologie di richiesta.

Nella deliberazione CNIPA n. 45 sono contenute, al Titolo IV e V, le regole spe-ci iche riguardanti il pro ilo dei certi icati usati per la marcatura temporale e leregole per la validazione temporale. Al Titolo V si trovano le regole che de inisco-no lametodologia di accesso al servizio, gli standard adottati per le strutture dati –e prescritto l’utilizzo di una struttura dati conforme allo standard RFC 3161[3] – ele modalita con le quali le marche devono essere inserite nei documenti cui fannoriferimento.

12

3 Il progetto aziendale

In questo capitolo viene descritto il progetto nel quale è stata avviata l’attivitàdi stage. Lo scopo di questo capitolo è fornire una visione generale del sistema e dialcune scelte implementative per contestualizzare l’apporto fornito durante il pro-getto formativo.

3.1 Il progetto Firma

Il progetto Firma e stato avviato in seguito alla richiesta di ItaTel di realizzare unsistema per la dematerializzazione dei contratti stipulati tramite i propri agenti. Ilprogetto si occupa di curare gli aspetti riguardanti la sicurezza del sistema, sia perquanto riguarda la parte hardware che software, che sara sviluppato e la gestionedel processo di irma dei contratti.

ItaTel e una grande compagnia di telecomunicazioni italiana che ha intrapreso,seguendo l’esempio della Pubblica Amministrazione, un processo di ammoderna-mento dei propri sistemi per dematerializzare la burocrazia riguardante i contrat-ti stipulati con i propri clienti. Tra i motivi principali che hanno portato a questadecisione si possono riportare:

• maggiore facilita di gestione dei documenti digitali;• risparmio economico nella generazione e gestione dei contratti;• maggiore velocita nella produzione, distribuzione, stoccaggio, ricerca e con-sultazione dei contratti;

• archivio documentale piu ecosostenibile.Data lamobilita degli agenti di ItaTel, e stato richiesto che il softwaredi compila-

zione e irmadei contratti sia disponibile per dispositivi tablet con sistemaoperati-voAndroid e iOS. L’intero sistema si dovra integrare con l’infrastruttura di gestionedelle anagra iche e di fatturazione preesistente.

Lo scopo del progetto Firma e di fornire un insieme di dispositivi hardware e diprodotti software tali da permettere la irma elettronica dei documenti, generati inseguito alla compilazionedei contratti, direttamentedadispositivi tablet. Il vincolopiu importante dell’intero progetto e che il sistema rispetti le direttive indicatedalla normativa italiana inmateria di irmaelettronica inmodo che i contratti sianovalidi legalmente in caso di contenzioso.

13


3.1.1 La firma grafometrica come soluzione

Il progetto Firmaprevede lo sviluppodi una soluzione cheutilizzi la irmagrafo-metrica. I dati che saranno associati al documento saranno quelli acquisiti tramiteil tablet e una penna apposita.

3.1.1.1 Motivazioni della scelta

Lemotivazioni che hannoportato all’utilizzo della irma grafometrica sonomol-teplici e vanno dalla semplicita di utilizzo al risparmio economico.

Utilizzando la irma elettronica avanzata, e in particolare quella grafometrica,si permette all’utente di irmare un documento in modo naturale, proprio come esolito fare con i documenti cartacei.

L’utilizzo di dati biometrici permette di evitare l’impiego di un dispositivo diirma di proprieta del irmatario. Il grande bacino di clienti del richiedente rendedecisamente dispendioso dotare tutti i irmatari di un dispositivo di irma, qualoranon ne fossero gia in possesso.

L’adozione della irma elettronica quali icata o digitale avrebbe costretto il ri-chiedente a fornire un dispositivo sicuro e un certi icato quali icato per la irma aogni suo cliente o implementare funzionalita per la irma remota. Questo tipo disoluzione, sempre per la mole di clienti e di contratti irmati quotidianamente, sa-rebbe di gran lunga piu dispendiosa dal punto di vista economico, computazionalee di adeguazione alla normativa. Adottare questo tipo di sistemi richiederebbe laregistrazione degli utenti e la fornitura dei dispositivi per generare la irma, impli-cando un’attesa di attivazione per irmatario e un ulteriore carico di responsabilitaper il fornitore del servizio.

3.1.1.2 Norme Specifiche

Adottando la irma grafometrica si devono soddisfare tutti i requisiti per la ir-ma elettronica avanzata. Questi requisiti sono elencati nella de inizione stessa deltipo di irma e nelle nuove Regole tecniche irma digitale reperibili sul sito di Digit-PA1. Di seguito saranno descritti e analizzati i requisiti che il sistema dovra soddi-sfare e le procedure operative che il richiedente e il fornitore dovranno adottareper risultare conformi alla normativa.

Riprendendo quanto detto durante l’analisi delle tipologie di irme, la irmaelettronica avanzata deve garantire:

1. connessione univoca al irmatario;2. creata con mezzi sui quali il irmatario puo conservare un controllo esclusi-

vo;1http://www.digitpa.gov.it/

14


3. collegata ai dati ai quali la irma si riferisce.Altri requisiti sono de initi nelle nuove Regole tecniche irma digitale al capitolo

V “Firma elettronica avanzata”.L’articolo 55,Disposizioni generali, indica chenon e necessario richiedereun’au-

torizzazione per la realizzazione di sistemi per la irma elettronica avanzata e chevi possono essere due tipi di soggetti:a) soggetti che erogano servizi di irma elettronica avanzata per utilizzarli nei

rapporti con terzi e realizzano soluzioni in proprio o richiedendole a fornitori;b) soggetti che realizzano soluzioni di irma elettronica per venderli a terzi.

Nel caso speci ico del progetto Firma, ItaTel e un soggetto di tipo a) mentreAccenture di tipo b).

L’articolo 56 detta le ulteriori caratteristiche obbligatorie che la irma elettro-nica avanzata deve garantire. Al comma 1 troviamo il seguente testo:

Le soluzioni di irma elettronica avanzata garantiscono:

a) l’identi icazione del irmatario del documento;

b) la connessione univoca della irma al irmatario;

c) il controllo esclusivo del irmatario del sistemadi generazione dellairma, ivi inclusi i dati biometrici eventualmente utilizzati per lagenerazione della irma medesima;

d) la possibilità di veri icare che il documento informatico sottoscrittonon abbia subito modi iche dopo l’apposizione della irma;

e) la possibilità per il irmatario di ottenere evidenza di quanto sotto-scritto;

f) l’individuazione del soggetto di cui all’articolo 55, comma2, letteraa);

g) l’assenza di qualunque elemento nell’oggetto della sottoscrizioneatto a modi icarne gli atti, fatti o dati nello stesso rappresentati;

h) la connessione univoca della irma al documento sottoscritto.

I punti a), b), c) e h) sono gia stati discussi durante lo studio dei vari tipi di irma,quindi focalizziamoci sugli altri.Alla lettera d) troviamo come requisito l’obbligo di fornire al irmatario un mo-do per veri icare che il contratto che ha sottoscritto non e stato modi icato dopol’apposizione della irma. Questa funzionalita si puo ottenere utilizzando, comede-scritto nella Sezione 2.4, un algoritmo di cifratura asimmetrico, cifrando i dati conla chiave privata e distribuendo la chiave pubblica per veri icare i dati.Alla lettera e) viene garantita al irmatario la possibilita di visualizzare quanto sot-toscritto e quindi il documento con le relative irme.Con la lettera f) si garantisce la possibilita di individuare in ogni momento il sog-getto che ha reso disponibile al irmatario la sottoscrizione del contratto tramite

15


irma elettronica. Anticipando l’analisi dell’articolo 60, le soluzioni di irma elet-tronica avanzata possono essere utilizzate solamente per rapporti giuridici tra ilsottoscrittore e il soggetto che eroga il servizio di irma.Alla lettera g) viene decretato che la irma sara valida se il documento elettronicoda irmare non contiene dei dati che possono modi icare il contenuto sottoscritto.Questo vincolo non rende possibile la irma di documenti contenenti macroistru-zioni, script e contenuto dinamico. Non e possibile, ad esempio, irmare un docu-mento contenente una data che si aggiorna automaticamente perche il documentoattuale non coinciderebbe con quello irmato.

Al comma 2 viene stabilito che la violazione di uno o piu dei vincoli indicati alcomma1 fa cessare la validita legale del documento elettronico e della irma a essoapposta (articoli 20, comma 1-bis, e 21, comma 2, del Codice).

L’articolo 57 “Obblighi a carico dei soggetti che erogano soluzioni di irma elettro-nica avanzata” elenca le condizioni alle quali deve sottostare il soggetto cheutilizzail servizio di irma elettronica avanzata comemetodo di sottoscrizione contrattua-le con i propri clienti. Di seguito sono riportati e commentati solamente i commi1, 2 e 3 poiche i restanti riguardano le relazioni con la pubblica amministrazione econ gli enti sanitari.

1. I soggetti di cui all’articolo 55, comma 2, lettera a) devono:

a) identi icare in modo certo l’utente tramite un valido documento diriconoscimento, informarlo inmerito agli esatti termini e condizio-ni relative all’uso del servizio, compresa ogni eventuale limitazionedell’uso, subordinare l’attivazione del servizio alla sottoscrizione diuna dichiarazione di accettazione delle condizioni del servizio daparte dell’utente;

b) conservare per almeno venti anni copia del documento di riconosci-mento e la dichiarazione di cui alla lettera a) ed ogni altra informa-zione atta a dimostrare l’ottemperanza a quanto previsto all’arti-colo 56, comma 1, garantendone la disponibilità, integrità, leggibi-lità e autenticità;

c) fornire liberamente e gratuitamente copia della dichiarazione e leinformazioni di cui alla lettera b) al irmatario, su richiesta di que-sto;

d) rendere note le modalità con cui effettuare la richiesta di cui alpunto c), pubblicandole anche sul proprio sito internet;

e) rendere note le caratteristiche del sistema realizzato atte a garan-tire quanto prescritto dall’articolo 56, comma 1;

f) speci icare le caratteristiche delle tecnologie utilizzate e come que-ste consentono di ottemperare a quanto prescritto,

g) pubblicare le caratteristiche di cui alle lettere e) ed f) sul propriosito internet;

16


h) assicurare, ove possibile, la disponibilità di un servizio di revoca delconsenso all’utilizzo della soluzione di irma elettronica avanzatae un servizio di assistenza.

In questo comma sono delineati gli accorgimenti che il soggetto erogante devesoddisfare. In particolare si nota la necessita di identi icare il irmatario, di infor-marlo in merito al servizio che si sta per utilizzare (lettera a) e di conservare tuttii documenti inerenti al contratto per almeno venti anni garantendone l’integrita. Irestanti punti assicurano al irmatario la reperibilita di quanto sottoscritto, la pos-sibilita di consultare le caratteristiche tecniche del sistema di irma e la possibilitadi utilizzare un servizio di revoca del consenso all’utilizzo della soluzione di irma.

2. Al ine di proteggere i titolari della irma elettronica avanzata ei terzi da eventuali danni cagionati da inadeguate soluzioni tecniche, isoggetti di cui all’articolo 55, comma 2, lettera a), si dotano di una co-pertura assicurativa per la responsabilità civile rilasciata da una societàdi assicurazione abilitata ad esercitare nel campo dei rischi industrialiper un ammontare non inferiore ad euro cinquecentomila.

3. Le modalità scelte per ottemperare a quanto disposto al comma 2devono essere rese note ai soggetti interessati, pubblicandole anche sulproprio sito internet.

Con questi ultimi due commi si vuole indicare che il soggetto erogante devepoter rispondere in caso di danni derivanti dall’utilizzo di questo tipo di servizioper almeno 500.000 euro.

Tutti gli accorgimenti contenuti in questo articolo sono stati noti icati al richie-dente che dovra provvedere a soddisfarli per conformarsi alla normativa.

L’articolo 58 delinea i requisiti che il soggetto che realizza la soluzione di irmadeve rispettare. I primi quattro commi sono rivolti ai soggetti che realizzano solu-zioni per la pubblica amministrazione. L’ultimo comma, il 5, indica che i soggettiche realizzano tali sistemi possono richiedere una certi icazione, secondo la normaISO/IEC 15408 livelli EAL1 o superiore, per dare evidenza del grado di sicurezzadella propria soluzione.

L’articolo 59 indica che il soggetto che realizza soluzioni di irma elettronicaavanzata puo farsi certi icare per la sicurezza del sistema per quanto riguarda leinformazioni a supporto di tale servizio e per la conformita alla normativa.

Come anticipato, l’articolo 60 riguarda le limitazioni all’uso della irma elettro-nica avanzata:

1. La irma elettronica avanzata realizzata in conformità con le di-sposizioni delle presenti regole tecniche, è utilizzabile limitatamente airapporti giuridici intercorrenti tra il sottoscrittore e il soggetto di cuiall’articolo 55, comma 2, lettera a).

L’ultimo articolo riguarda la possibilita di sostituire l’uso della irma elettronicaavanzata, nei confronti della pubblica amministrazione, con l’invio tramite posta

17


elettronica certi icata, con l’uso della Carta d’Identita Elettronica, della Carta Na-zionale dei Servizi o di altri strumenti a essi conformi. All’ultimo comma, il 6, vieneindicato l’impegno da parte di DigitPA di elaborare delle linee guida che facilitinola realizzazione di soluzioni di irma elettronica avanzata.

3.2 Funzionalità richieste

L’intero sistema deve permettere a un agente di compilare con i dati del clien-te un determinato tipo di contratto. Al termine della compilazione i dati sono in-viati a un server di controllo dell’applicativo tablet che si occupa di generare undocumento in formato PDF e inviarlo al sistema di gestione delle irme.

Appena il sistema avra acquisito e preparato il documento per il processo diirma dovra noti icare il server documentale che istruira l’applicativo installato sultablet per iniziare la irma.

All’inizio della procedura di irma il irmatario potra visualizzare il documen-to da irmare, selezionare il campo irma da siglare, apporre la irma, accettare oannullare la procedura di irma in ogni istante e visualizzare il documento irmato.

Al termine della procedura di irma il sistema eseguira le operazioni necessarieper inalizzare il documento, sigillandolo in caso di accettazione o eliminandolo incaso di ri iuto. Completate tali operazioni, il sistema documentale sara noti icatodella ine del processo di irma e potra ottenere i documenti irmati o richiedernel’eliminazione.

In Figura 3.1 viene riportato un diagramma delle funzionalita che il sistema an-dra ad offrire mentre in igura 3.2 viene presentato un diagramma di attivita cheschematizza i passaggi della procedura di irma.

3.3 Il software di firma

In questa sezione sara descritto il software selezionato per gestire il processodi irma e per l’incorporamento dei dati biometrici nel contratto. Come speci icatonel sommario, non e possibile fornire il nome esatto del software usato quindi inquesto documento sara chiamato HandSign.

Questo prodotto e stato selezionato per i seguenti motivi:• soddisfa tutti i requisiti funzionali e di sicurezza espressi nella normativa;• si integra con la maggior parte dei pad per la irma disponibili sul mercato;• offre un ottimo strumento di veri ica delle irme;• mette a disposizione dei system integrator una serie di Software develop-ment kits (SDKs) per sviluppare applicazioni che utilizzano le funzionalitadi irma;

18

3.3 Il software di irma

Cliente

Sistema documentale

1 - Caricamento di

un documento

3 - Acquisiziome del

risultato della procedura

di firma

2 - Inizio della

procedura di firma

4 - Visualizzazione del

documento da firmare

5 - Selezione del campo

firma da siglare

6 - Firma del campo

7 - Accettazione delle

firme apposte

8 - Rifiuto delle

firme apposte

9 - Visualizzazione

del documento firmato

Figura 3.1: Use case delle funzionalita offerte dal sistema

19


Processo di firma

Sistema documentale Sistema di firma Cliente

Caricamento

documento

Creazione

procedura

Inizio

procedura

Visualizzazione

documento

Seleziona del campo

firma

Apposizione

firma

Ci sono altri campi

da firmare

[Sì]

[Sì]

Continuare con

la procedura

Azione conclusiva

[No]

Eliminazione

documento

[No]

[Rifiuto]

Chiusura

documento[Accettazione]

Completamento

procedura

Acquisizione

risultati

Figura 3.2: Diagramma di attivita della procedura di irma richiesto

20

3.3 Il software di irma

• e altamente con igurabile e risulta molto versatile;• permette di integrarsi con Hardware Security Module (HSM) per le opera-zioni di cifratura e irma.

HandSign e costituito da un insieme dimoduli software perWindows e di libre-rie per dispositivi mobile basati su Android e iOS.

I moduli principali sono i seguenti:HandSign Server permette di caricare i documenti da irmare, con igurare la pro-

cedura di irma, registrare le irme e gestire i documenti una volta irmati ori iutati. Le funzionalita sono messe a disposizione tramite una serie di WebService basati sul protocollo Simple Object Access Protocol (SOAP) o tramiteuna semplice interfaccia web.

Utility di analisi della firma per lo studio forense delle irme. Permette di veri i-care se una irma appartiene a un particolare irmatario confrontandola conun pro ilo gia registrato oppure con un’altro set di dati biometrici.

HandSign Mobile SDK comprende delle librerie per Android e iOS. Mette a di-sposizione degli sviluppatori gli strumenti necessari per integrare nei propriapplicativi mobile le funzionalita di irma dei documenti.

Il funzionamento di questo prodotto rispecchia la procedura di irma descrittacon il diagramma di attivita presentato in Figura 3.2.

Come prima cosa e necessario caricare un documento da irmare. A questo do-cumento si puo associare una procedura di irma chiamata “work low”. Alla crea-zione di una procedura si possono determinare, in modo gra ico o inserendo dellestringhe particolari nel testo che saranno ricercate e sostituite, i campi irma, leazioni eseguibili dai vari utenti, le azioni da eseguire a ine procedura e altri detta-gli. Al termine della creazione del work low viene generata la procedura richiestae le viene associato un ID che verra usato in tutte le successive operazioni.

Tramite i Web Service e possibile eseguire varie operazioni tra le quali richie-dere le pagine del documento come immagini, inviare i dati biometrici, opportu-namente cifrati, per la irma di un campo, chiudere un work low completandolo ori iutandolo, ottenere informazioni sullo stato corrente del work low e ottenere ildocumento irmato.

Si procede quindi, sia da interfaccia web sia da applicazione mobile, con la ri-chiesta delle informazioni sul work low relativo a un dato ID e delle pagine deldocumento sotto forma di immagini. Il ile del documento non viene mai scambia-to tra client e server per evitare che vi siano contraffazioni durante la proceduradi irma. La con igurazione dei parametri di generazione delle immagini permettedi de inire il formato dei ile risultanti e la loro qualita visiva. L’interfaccia web diirma e l’applicativo mobile sono avviabili tramite uno speciale URL che contienel’indirizzo IP del server di irma e l’ID del processo di irma da utilizzare.

Una volta caricata la visualizzazione del documento vengono presentati al ir-

21


matario i vari campi che e possibile irmare. Selezionando un determinato campoirma, all’utente sara presentata l’interfaccia di irma su tablet mentre su PC sarapossibile selezionare se eseguire la irma utilizzando un pad o, in caso estremo,unmouse. L’utilizzo del mouse e consigliato per la sola valutazione del software inquanto non verranno raccolti dati sulla pressione e suimovimenti aerei. Al terminedell’acquisizione della irma e possibile accettarla oppure eseguirla nuovamenteper migliorarla.

Dopo l’acquisizione della irma, i dati biometrici vengono inviati al componenteHandSign Server che si occupa di salvarli nel documento e di collegarli indissolu-bilmente a esso attraverso la procedura descritta nella sezione 2.4. Se il work lowviene con igurato adeguatamente, durante la fase di creazione, e possibile indica-re l’uso di un HSM per la irma dell’hash del documento con una chiave privata diproprieta di ItaTel. Sempre in fase di creazione del work low e possibile indicarese utilizzare o meno un servizio di marcatura temporale.

In ogni momento il irmatario puo decidere, se permesso dalla con igurazionedel work low, di annullare il processo di irma o, se tutte le irme obbligatorie sonogia state apposte, di terminarlo con successo.

Al momento della chiusura di un work low tutti i ile utilizzati durante il pro-cesso di irma vengono eliminati e viene conservato solo il documento sigillatocontenente i dati biometrici. Con igurando propriamente il work low e possibileottenere tali documenti e cancellarli utilizzando i Web Service appropriati.

I passaggi necessari per eseguire la irma su dispositivi tablet, rappresentati inFigura 3.3, sono quindi i seguenti:

1. caricamento del documento;2. creazione della procedura e restituzione dell’URL con l’ID del work low;3. attivazione del software sul dispositivo client attraverso l’URL;4. richiesta delle immagini delle pagine del documento;5. irma dei vari campi da parte del cliente;6. invio dei dati biometrici criptati al server;7. chiusura del documento e richiesta dello stesso da parte del sistema di ge-

stione documentale.

3.4 L’architettura del sistema

La soluzione prevede la creazione di due reti LAN: una ospitera i server perla gestione della irma (chiamati HandSign Server) e una dedicata agli HSM. L’usodi dispositivi HSM ha la inalita di conservare in un dispositivo sicuro di irma lachiave privata usata per creare l’associazione tra i dati biometrici della irma e ildocumento irmato. Dei irewall si occuperanno di gestire il traf ico in entrata suqueste reti.

22

3.5 Strumenti utilizzati

URL

URL

1 2

3

5

6

4 7

ClienteTablet

Server documentale

HandSign Server

Figura 3.3: Schema del funzionamento del sistema di irma

In HandSign Server verra installato il sistema operativo Windows Server, comeindicato nei requisiti software di HandSign Server.

La Figura 3.4 riporta un semplice schema dell’architettura.

Firewall Firewall

HSM

Figura 3.4: Architettura del sistema di irma

3.5 Strumenti utilizzati

Nello svolgimento del progetto sono stati utilizzati i seguenti strumenti:

soapUI applicativo per il test dei Web Service basati sul protocollo SOAP. Tramitequesto programma e stato possibile utilizzare e provare le funzionalita offer-te dal componente server di HandSign. Attraverso questo strumento e possi-bile creare suite di test in grado di richiamare varie funzioni deiWeb Servicee di veri icare se le risposte sono corrette o meno. Sempre dall’interfaccia ditest e possibili de inire delle prove di carico.

23


Eclipse IDE per il linguaggio di programmazione Java. Attraverso l’installazionedi vari plug-in e possibile estendere le funzionalita di questo applicativo epermettere lo sviluppo di applicazioni anche in altri linguaggi di program-mazione. E stato utilizzato per provare le funzionalita dell’SDK per il sistemamobile Android.

Visual Studio IDE per lo sviluppo di applicativi per le piattaforme basate su siste-ma operativo Windows. Questo ambiente di sviluppo fornisce tutti gli stru-menti necessari per la creazionediWebServiceusando la tecnologiaASP.NETe il linguaggio C#. E stato utilizzato per lo sviluppo di plug-in di prova pertestare l’integrazione tra il software di irma e i dispositivi HSM.

VMWare Workstation software di virtualizzazione di sistemi operativi. Questoapplicativo e stato utilizzato per installare una versione di prova del siste-ma operativo che sara utilizzata in ambiente di produzione e che ospitera ilcomponente server del software di irma. E stato utilizzato anche per testa-re le funzionalita delle librerie fornite per lo sviluppo di applicativi mobileattraverso l’installazione di un sistema Android.

24

4 Lo stage

In questo capitolo viene illustrato il lavoro svolto durante l’attività di stage. Lapianificazione delle attività è stata guidata dalla definizione di obiettivi e dalle tem-pistiche stabilite per il progetto Firma.

4.1 Piano di lavoro

4.1.1 Gli obiettivi

Gli obiettivi principali che sono stati de initi per l’attivita di stage sono i seguen-ti:Comprendere la normativa studio delle varie tipologie di irma elettronica e del-

le relative normative italiane a riguardo (DPCM30marzo 2009, Deliberazio-ne CNIPA n. 45 del 21 mag 09, D.Lgs. 30 dicembre 2010, n. 235). Durante lostudio si dovra fare particolare attenzione al tipo di irma selezionata perla soluzione e quali oneri implica per il soggetto che realizza la soluzione diirma e per quello che la offre come servizio.

Individuare e studiare le tecnologie abilitanti dopoaver compreso i requisiti im-posti dalla normativa, e necessario individuare e comprendere quali tecno-logie dovranno essere utilizzate per rendere valida la soluzione. Oltre al soft-ware di irma sara necessario considerare, ad esempio, come collegare i datidi irma al documento.

Comprendere il funzionamento del componente di firma studiodi una soluzio-ne per la irma biometrica basata sul prodotto HandSign e supporto alla suaintegrazione utilizzando una tecnica di Firma Elettronica Avanzata (FEA)conforme alle normative studiate. Lo studio del componente prevede l’ana-lisi approfondita dei Web Service offerti e delle funzionalita dell’SDK per di-spositivi mobile basati su sistema Android. Lo studio riguardante i Web Ser-vice dovra concludersi con la stesura di un documento interno che descrivetutte le funzioni disponibili.

Supportare la progettazione e lo sviluppo della soluzione unavolta terminatala fase di studio delle normative e delle tecnologie e dopo aver concluso l’al-lineamento con lo stato attuale del progetto si procedera con la fase di sup-porto alla progettazione e allo sviluppo della soluzione. Questa attivita pre-vede l’aiuto alla stesura della documentazione tecnica e lo sviluppo di appli-

25

4 Lo stage

cativi di prova per testare le integrazioni tra le diverse parti che andranno acomporre il sistema di irma.

4.1.2 Pianificazione del lavoro

Lo svolgimento del progetto e strutturato nelle sottoattivita riportate di seguitoe in Figura 4.1.

4.1.2.1 Fase di studio

15 giorni (120 ore - 3 settimane)Studio delle normative Italiane riguardanti la firma elettronica

Durata: 6 giorniObiettivi: comprendere appieno quali requisiti deve soddisfare la irma di-

gitale per permettere di costituire una soluzione di irma che abbia va-lore legale.

Studio delle tecnologie abilitanti

Durata: 4 giorniObiettivi: studiare le soluzioni tecnologiche che permettono di soddisfare i

requisiti legali della irma elettronica avanzata.Studio del componente di firma biometrica

Durata: 5 giorniObiettivi: integrazione del prodotto software utilizzato per l’implementa-

zione della irma biometrica in un contesto speci ico di applicazione.

4.1.2.2 Fase di supporto alla progettazione e sviluppo

22 giorni (180 ore)Supporto alla progettazione delle integrazioni del software di firma

Durata: 16 giorniObiettivi: supporto alle fasi di progettazione delle integrazioni del prodotto

software di irma in un ambiente Telco pre-esistente.Supporto allo sviluppo delle integrazioni del prodotto SW di Firma

Durata: 6 giorniObiettivi: supporto alle prime fasi di sviluppo delle componenti di integra-

zione del prodotto SW di irma in un ambiente Telco pre-esistente.

26

4.2 Studio della normativa

ID Nome attività

1 Fase di studio

2 Studio delle normative Italiane riguardanti la firma elettronica

3 Studio delle tecnologie abilitanti

4 Studio del componente di firma biometrica in un contesto specifico di applicazione

5 Fase di supporto alla progettazione e sviluppo

6 Supporto alla progettazione delle integrazioni del SW difirma

7 Supporto allo sviluppo delle integrazioni del prodotto SW di Firma

03 06 09 12 15 18 21 24 27 30 03 06 09 12 15 18 21 24 27 30 02 05 08 11 14novembre 2012 dicembre 2012 gennaio 20

Figura 4.1: Diagramma Gantt delle attivita piani icate

4.2 Studio della normativa

Per capire il contesto del progetto e le criticita che esso comporta, il mio lavoroe cominciato con lo studio delle normative riguardanti la irma elettronica. Partedegli argomenti studiati durante questa fase sono stati riportati nel Capitolo 2 enon saranno riportati nuovamente.

Lo studio della normativa e stato condotto su diversi tipi di documenti che com-prendono Decreti Legislativi (D.Lgs.), Decreti del Presidente del Consiglio dei mi-nistri (DPCM), direttive del Parlamento europeo, deliberazioni CNIPA e determi-nazioni DigitPA.

4.2.1 Direttiva 1999/93/CE

Il primo documento analizzato e la direttiva 1999/93/CE del Parlamento eu-ropeo del 13 dicembre 1999. Questa direttiva ha lo scopo di de inire un quadrocomunitario per contribuire al riconoscimento giuridico delle irme elettronichefavorendone l’utilizzo nel mercato interno. Al ine del progetto, le sezioni di mag-giore interesse riguardano l’accesso al mercato, gli effetti giuridici delle irme elet-troniche, le raccomandazioni e i requisiti espressi negli allegati della direttiva.

Per quanto riguarda la validita legale, e interessante notare come l’Articolo 5indica agli stati membri di provvedere a rendere le irme elettroniche avanzate,basate su certi icato quali icato e create mediante un dispositivo per la creazionedi una irma sicura, ammissibili come prova in giudizio e valide per i dati in formaelettronica, come lo sono le irme autografe per i dati cartacei. Gli stati membri de-vono inoltre provvedere a non ritenere legalmente inef icace una irma elettronicain base al fatto che essa sia:

• in forma elettronica, o• non basata su un certi icato quali icato, o• non basata su un certi icato quali icato rilasciato da un ente accreditato, o• non creata con un dispositivo per la creazione sicura della irma.Con queste direttive e garantita la validita legale dei documenti in tutti gli stati

membri e la loro ef icacia nei rapporti internazionali.

27

4 Lo stage

Negli allegati alla direttiva europea e possibile trovare i requisiti imposti ai cer-ti icati quali icati, agli enti che rilasciano tali certi icati e ai dispositivi per la crea-zione di irma sicura. Al ine della realizzazione del progetto e utile considera-re l’allegato riguardante i requisiti dei dispositivi di irma, il terzo: la decisione2003/511/CE de inisce che le norme che sono considerate dagli Statimembri con-formi ai requisiti espressi in tale allegato sonoquelle indicatenel CWA14169 (mar-zo 2002, secure signature-creation devices). Tale CWA issa il traguardo di sicurez-za dei dispositivi a EAL 4+.

4.2.2 Codice dell’amministrazione digitale

Il D.Lgs. 7 marzo 2005, n.82, CAD e successive modi iche recepisce le diretti-ve europee dettate nella direttiva 1999/93/CE e provvede alla de inizione di unquadro normativo nazionale. Questo testo contiene articoli che de iniscono la va-lidita del documento informatico, del documento informatico sottoscritto con ir-ma elettronica avanzata e le caratteristiche delle irme elettroniche, dei certi icatiquali icati e dei dispositivi sicuri.

Le de inizioni di validita dei documenti elettronici e delle irme elettroniche sipossono trovare Capo II, Sezione I, Documento informatico. In questa sezione sonode initi i termini di validita dei documenti informatici, di documenti informaticisottoscritti con irme elettroniche, delle copie elettroniche di documenti analogici,e viceversa, e dei duplicati digitali dei documenti.L’articolo 21, comma 2, attribuisce al documento informatico sottoscritto con ir-ma elettronica avanzata, quali icata o digitale, se formato nel rispetto di quantode inito nelle apposite regole tecniche, la validita prevista dall’articolo 2702 delcodice civile1, quindi della scrittura privata.Una limitazione all’utilizzo della irma elettronica e imposta dall’articolo 21: conquesto articolo si richiede l’uso della sola irma elettronica quali icata o digitaleper le scritture private previste nell’articolo 1350 del codice civile, primo comma,numeri da 1 a 12 (atti riguardanti i beni immobili). Per i restanti tipi di atti (artico-lo 1350, comma 1, lettera 13) e ritenuta valida la sottoscrizione effettuata tramiteirma elettronica avanzata, quali icata o digitale.Le de inizioni delle irme elettroniche e dei loro limiti di validita sono contenu-

te nella Sezione II, Firme elettroniche e certi icatori, sempre nel Capo II, assieme aicriteri di validita per i certi icati quali icati e alle caratteristiche che i certi icatoriaccreditati devono possedere. Sempre in questa sezione, con l’articolo 35, si det-tano i requisiti principali che i dispositivi sicuri devono soddisfare, assieme allavalidita delle certi icazioni rilasciate da enti accreditati in un altro Stato membro.

Data la genericita degli articoli contenuti nel decreto e il carattere tecnico del-l’argomento, l’articolo 71 delega la de inizione di appropriate regole tecniche a1Ef icacia della scrittura privata: La scrittura privata fa piena prova, ino a querela di falso, della pro-venienza delle dichiarazioni da chi l’ha sottoscritta, se colui contro il quale la scrittura e prodottane riconosce la sottoscrizione, ovvero se questa e legalmente considerata come riconosciuta.

28

4.3 Studio delle tecnologie abilitanti

Decreti del Presidente del Consiglio dei Ministri o del Ministro delegato per lapubblica amministrazione e l’innovazione.

4.2.3 Determinazioni DigitPA

Le determinazioni DigitPA, che vanno a sostituire le delibere CNIPA, dettaglianoulteriormente le regole tecniche.

Il documento consultato al ine di approfondimento e la deliberazione CNIPA n.45 del 21 maggio 09 modi icata dalla determinazione DigitPA n. 69 del 28 luglio2010. Il testo di questa deliberazione include regole tecniche speci iche per il rico-noscimento e la veri ica del documento informatico. Un esempio dei contenuti diquesto documento sono i pro ili dei certi icati quali icati, delle marche temporali,le regole per la validazione temporale e quelle per la revoca dei certi icati.


Durante lo studio della normativa sono state individuate diverse tecnologie chesono richieste o che contribuiscono al raggiungimento della conformita alla nor-mativa. Alcune tra le piu importanti sono:

• utilizzo di un dispositivo HSM per la gestione sicura delle chiavi private;• utilizzo di Timestamp Authority per la validazione temporale;• certi icati quali icati e crittogra ia asimmetrica, in particolare in ambienteMicrosoft Windows.

4.3.1 HSM

Per l’apposizione di irme digitali e irme remote e necessario che le chiavi uti-lizzate, e i relativi processi, siano gestiti da un dispositivo chiamato Hardware Se-curityModule (HSM). ConHSMsi intendeunparticolaredispositivohardware il cuiscopo e quello di accelerare operazioni crittogra iche, creare, conservare e utiliz-zare chiavi elettroniche e fornire strong authentication per le operazioni di gestio-ne dei dati sensibili. Generalmente questi moduli vengono forniti come schede diespansione PCI o come dispositivi di rete utilizzabili attraverso protocollo TCP/IP.

Questi dispositivi sono costituiti da processori crittogra ici dedicati e permetto-no l’accelerazione delle operazioni di cifratura, la generazione ottimizzata di valorirandomici, la creazione e gestione di chiavi. I processori sono progettati per essereresistenti a manomissioni sia isiche che logiche, come il tampering oppure il busprobing. I requisiti di sicurezza crittogra ica che tali dispositivi devono possederesono elencati in standard come il Common Criteria (CC)[19].

Le motivazioni che spingono all’uso di dispositivi di questo tipo sono:• la generazione sicura di dati sensibili quali chiavi crittogra iche;

29

4 Lo stage

• il mantenimento di materiale sensibile in un ambiente sicuro;• l’utilizzo di materiale sensibile senza che questo esca dal dispositivo;• lo spostamento di operazioni crittogra iche dai server applicativi agli HSMin modo da incrementare le prestazioni.

A ini di creare copie di ripristino dei dati crittogra ici, molti fornitori permet-tono l’esportazione delle chiavi crittogra iche e del materiale sensibile dal dispo-sitivo, anche come testo in chiaro. Nella fase di esportazione delle chiavi si dovreb-be cifrare tutto il materiale prima dell’esportazione e utilizzare delle procedureappropriate in modo da mantenere un pro ilo di sicurezza elevato.

Data la criticita dell’impiego di questi dispositivi, molti modelli offrono la pos-sibilita di realizzare cluster di HSM per ottenere con igurazioni che garantisco-no high availability. Questa caratteristica garantisce la disponibilita delle funzio-nalita crittogra iche in caso di elevati carichi di lavoro oppure in occasione delmalfunzionamento di qualche dispositivo facente parte del cluster.

L’utilizzo delle funzionalita degli HSM e permesso da una serie di librerie cheil fornitore mette a disposizione degli sviluppatori. Tali librerie vengono general-mente con igurate attraversoun applicativo client che le installa nel sistemaopera-tivo in cui andranno usate; il software permette di preparare il collegamento congli HSM, installati nella rete locale o come schede PCI, e di impostare i parame-tri per realizzare una con igurazione in high availability. I fornitori di HSM forni-scono librerie che implementano Application Program Interface (API) crittogra i-che standard come PKCS#11, OpenSSL, JCE/JCA, Microsoft Cryptographic Applica-tionProgramming Interface (CAPI) eMicrosoft CryptographyAPI:Next Generation(CNG).

Tra i vari produttori di HSM i seguenti hanno fatto domanda di certi icazioneper un loro dispositivo presso l’Organismo di Certi icazione della Sicurezza Infor-matica (OCSI):

• ARX;• Thales e-Security Ltd.;• AEP Networks;• SafeNet.

Altri produttori noti sonoUtimaco, Oracle eRealSec. Una gamma indicativa di prez-zo di questi dispositivi puo essere quella compresa tra i $2.500 e i $30.000[16].Diversi esempi di questi dispositivi sono presentati nella Figura 4.2.

30


Figura 4.2: A destra due prodotti Utimaco, in alto a sinistra un HSM PCI di Thales e inbasso a sinistra un HSM SafeNet con PED e relative chiavi di autenticazione

4.3.2 Trusted timestamping

Per ottenere una validazione temporale opponibile a terzi e richiesto l’utiliz-zo di marche temporali, chiamate anche timestamps, emesse da autorita certi i-cate e conformi allo standard RFC 31612. Questo standard indica il formato dellarichiesta e della risposta di una marca temporale emessa dall’ente certi icato.

Grazie alla de inizione di un protocollo standard, il Time Stamping Protocol(TSP), le autorita di timestamping, note con il nomediTimeStampAuthority (TSA),possono offrire questa funzionalita comeWeb Service. Il software selezionato perla soluzione permette l’utilizzo di una TSA, in particolare offre all’utente la possi-bilita di indicare l’URL per l’invio della richiesta di una marca durante la fase dicreazione del work low.

Per la generazione di marche temporali e possibile creare un sistema propriooppure ricorrere a quelli offerti da terzi. Se si vuole realizzare un sistema adibitoalla creazione di marche temporali bisogna soddisfare dei requisiti espressi nelleregole tecniche e nella deliberazione CNIPA. Le regole tecniche impongono:

• conservazione su archivio nonmodi icabile dellemarche generate per alme-no vent’anni;

• le marche temporali devono contenere almeno l’insieme di dati speci icatonell’articolo 48, comma 1;

• le chiavi usate per la sottoscrizione delle marche vanno cambiate almenoogni tre mesi ma i certi icati a esse associati non vanno revocati;

2Deliberazione CNIPA n. 45 del 21 maggio 09, articolo 17

31

4 Lo stage

• il riferimento temporale assegnato a una marca deve coincidere con il mo-mento della sua generazione e vi puo essere una differenza al massimo di unsecondo rispetto alla scala UTC(IEN);

• garantire un tempodi risposta nella generazione dellemarche non superioreal minuto.

Nella deliberazione CNIPA e speci icata la conformita allo standard RFC 3161sia nel protocollo di richiesta sia nella struttura dati della marca temporale forni-ta come risposta. Per la realizzazione del sistema si deve considerare che le mar-che temporali, richiedendo una irma elettronica e il salvataggio su memoria nonmodi icabile, andrebbero gestite da dispositivi sicuri, come gli HSM.

Allo stato attuale il richiedente sta valutando se costruire un proprio sistema,se ricorrere a una TSA o se utilizzare il timestamp locale dell’HandSign Server. Larealizzazione di un sistema proprio di timestamping implicherebbe l’acquisto dialtri dispositivi sicuri, la conservazionedellemarche generate e l’adeguamento allanormativa. Utilizzando un ente che offre marche temporali tramite Web Service siintrodurrebbe un costo che varia in base al numero di richieste effettuate.

Per ottenere una valutazione approssimativa del costo di questo servizio si puoconsultare il listinodiDigiStamp[8]: questo ente offre soluzioni di fornituradimar-che a richiesta con costo a consumo – da $0,32 a $0,05 a marca o $19.000 annui sesono richieste piu di 360.000 marche l’anno – o sistemi completi preconfezionatiper $44.800.

4.3.3 Certificati e crittografia in ambiente Microsoft Windows

Per realizzare il collegamento della irma grafometrica al documento sottoscrit-to e necessario predisporre e con igurare il sistema per permettere la irma del-l’impronta del documento. Questa funzionalita e realizzata automaticamente dalsoftware di irma che utilizza dei certi icati speci ici e le capacita crittogra ichemesse a disposizione dal sistema operativo.

In ambienteMicrosoftWindows sono disponibili variemetodologie per esegui-re funzioni crittogra iche, le piu usate sono quelle offerte da OpenSSL e dal sistemaoperativo tramite le Microsoft CAPI.

4.3.3.1 OpenSSL

OpenSSL3 e un insieme di librerie open source che implementa i protocolli Se-cure Socket Layer (SSL) e Transport Layer Security (TLS). Il toolkit e distribuitocome un insieme di librerie C che implementano i vari protocolli, le operazionicrittogra iche e un tool utilizzabile da linea di comando.

3http://www.openssl.org/

32

http://www.openssl.org/


Le librerie offrono tutte le piu comuni funzioni crittogra iche e un insieme dimetodi per la creazione di chiavi asimmetriche, richieste di certi icati e certi icatiquali icati.

Attraverso il tool per linea di comando e possibile generare la propria chiaveprivata, irmare una richiesta per un certi icato e portare a termine tutte le opera-zioni che una Certi ication Authority (CA) svolge per l’approvazione di un certi i-cato. La procedura da seguire per la generazione di una chiave privata per la irmae un certi icato quali icato a essa associata e la seguente:

1. creazione di una chiave privata di tipo RSA utilizzando il comando “opensslgenpkey” speci icando il ile in cui salvare la chiave e la sua lunghezza. Adesempio, per generare una chiave tramite l’algoritmo RSA, lunga 4096 bit,protetta con la password “pkeypass” usando l’algoritmo Triple DES e salva-ta nel ile store.key, si puo usare il seguente comando: openssl genpkey-algorithm RSA -out store.key -des3 -pkeyopt rsa_keygen _-bits:4096 -pass pass:pkeypass;

2. creazione di una richiesta di certi icato per la chiave appena creata. E possi-bile creare una richiesta partendo da una con igurazione contenuta in un ileusando il seguente comando: openssl req -new -config cert_req.cfg-key store.key -out cert_req.csr. Il ile di con igurazione contienetutte le caratteristiche e le proprieta avanzate del certi icato che si desideraottenere;

3. invio della richiesta ad una CA. Se si intende simulare un’autorita di certi ica-zione a scopo di test e possibile generare il certi icato per cui e stata prepara-ta la richiesta utilizzando il seguente comando: openssl x509 -req -days730 -in cert_req.csr -CA ca_cert.crt -CAkey ca_pkey.pem -outsign_cert.crt -sha512. In questo caso il certi icato generato ha una vali-dita di 730 giorni ed e stato irmato con la chiave della CA con un algoritmoSHA 512.

4.3.3.2 Microsoft CAPI e CAPI CNG

La Cryptographic Application Programming Interface (CAPI) e un insieme diAPI incluse nei sistemi operativi MicrosoftWindows che permette allo sviluppato-re di utilizzare in modo sicuro funzionalita crittogra iche.

Le funzionalita messe a disposizione dalle CAPI comprendono:• gestione delle chiavi sia di sessione che asimmetriche (generazione, impor-tazione, esportazione, duplicazione ed eliminazione);

• cifratura e decifratura di dati;• irma e veri ica di dati;• calcolo di hash di dati;• gestione dei certi icati (creazione, stoccaggio, veri ica e revoca).

33

4 Lo stage

Questa interfaccia viene implementata da una serie di moduli chiamati Crypto-graphic Service Providers (CSP) i quali sono delle librerie che forniscono le funzio-nalita crittogra iche concrete e possono essere resi disponibili anche dai produt-tori di HSM.

ConWindows Vista viene introdotto un aggiornamento alle CAPI noto con il no-me di Cryptography API: Next Generation (CNG). Con questa nuova versione vienemigliorata tutta la struttura delle API, viene introdotta l’integrazione con il siste-ma delle smart card e viene aggiunto il supporto alla crittogra ica tramite curveellittiche.

A differenza delle CAPI di prima generazione, che de inivano i CSP comemoduliche forniscono sia le funzionalita di gestione delle chiavi sia le funzioni crittogra i-che, con le CNG viene introdotto il Key Storage Provider (KSP). Questo nuovo mo-dulo permette di differenziare la gestione delle chiavi dalle funzioni crittogra ichee ha il compito di isolare il materiale sensibile dal lusso di esecuzione dell’appli-cazione. Quando un’applicazione richiede l’uso di una determinata chiave privataquesta viene recuperata dal gestore delle chiavi appropriato, attraverso il key sto-rage router, come riferimento e non esce mai dal provider che la contiene. Unavolta ottenuto il riferimento alla chiave e possibile utilizzarla con un provider difunzioni crittogra iche di tipo CNG, per esempio per irmare un hash. Diverse im-plementazioni di questi provider sono fornite con l’installazione standard del si-stema operativoma altri produttori, ad esempio i fornitori di HSM, possono creareimplementazioni proprie sia hardware che software.

La creazione e la gestione dei certi icati nei sistemi operativi Windows si puocompiere sia da interfaccia gra ica, utilizzando un apposito snap-in della Micro-soft Management Console (MMC), oppure attraverso le applicazioni da linea dicomando certreq e certutil.

Se un certi icato viene generato con una di queste procedure viene richiesto dispeci icare il tipo di provider da utilizzare. Una volta creato il certi icato questopresentera un riferimento al CSP o al KSP che contiene la chiave privata utilizza-ta per irmare la richiesta. Le API mettono a disposizione dei metodi per ottene-re il riferimento a una chiave privata associata a un determinato certi icato, se inpossesso dell’utente.

Con igurando la connessione con un HSM e installando le implementazioni diCAPI e CNG fornite con il dispositivo sara possibile utilizzare come provider l’HSMstesso. Nella fase di creazione di una nova chiave sara possibile selezionare il pro-vider speci ico che fa uso del dispositivo. Tutte le operazioni che si vorranno svol-gere con questa determinata chiave saranno portate a termine dal provider che lagestisce e quindi dall’HSM.

34

4.4 Studio del componente di irma

4.4 Studio del componente di firma

Per comprendere il funzionamentodel componente di irma equali funzionalitasi dovranno utilizzare in fase di progettazione e stata avviata l’attivita di studio deivari moduli del sistema HandSign. I componenti software che sono stati analizzatie provati sono quelli riguardanti il modulo server e l’SDK per sistema operativoAndroid.

Data la quasi totalemancanza di documentazione tecnica riguardante le API deiWebService del server e dell’SDKperAndroid, lamaggior parte delle funzioni sonostate studiate mediante test.

L’intero sistema HandSign si basa su de concetti fondamentali:documento il documento elettronico che si vuole irmare. Il formato piu utilizzato

e quello PDF ma HandSign supporta anche Word ed Excel.workflow rappresenta la con igurazione del processo di irma. Questa con igura-

zione deve essere creata a partire da un documento gia caricato e de iniscele irme da apporre (posizione, ordine e obbligatorieta), l’azione da compie-re alla ine del processo e le operazioni eseguibili dall’utente (apposizione diirme non previste, aggiunta di commenti a penna o a tastiera, aggiunta di al-legati, salvataggio e stampa del documento). Sempre in questa con igurazio-ne si puo indicare l’uso di una TSA per la validazione temporale delle singoleirme e l’uso di un plug-in speci ico per generazione del collegamento tra lairma e il documento.

4.4.1 Ambiente di test

Per studiare le funzioni messe a disposizione dai moduli di HandSign e statocreato un ambiente di test con l’aiuto di VMware.

Come prima cosa e stata creata una macchina virtuale con sistema operativoWindows Server 2008 R2 SP1 a 64 bit nella quale e stato installato il pacchettoHandSign Server. In seguito e stata creata una seconda macchina virtuale con si-stema operativo Android 3.2.24 per provare le funzionalita dell’SDK attraverso unapplicativo creato appositamente.

Il computer isico, il server virtuale e il tablet virtuale sono stati collegati allamedesima rete LAN virtuale creata tramite VMware.

Con questa con igurazione e stato possibile studiare i Web Service esposti dalserver di irma utilizzando il software soapUI dalla macchina isica e il comporta-mento dell’SDK installandolo nel tablet virtuale.

4Sistema operativo modi icato appositamente per funzionare con architetture x86 reperito dahttp://www.android-x86.org/

35

http://www.android-x86.org/

4 Lo stage

4.4.2 Studio di HandSign Server

Con l’installazione del componente HandSign Server viene con igurato sul ser-ver un insieme di quattro Web Service, un applicativo per la veri ica delle irmeapposte e altri strumenti di con igurazione.

4.4.2.1 Web Services

IWebServices sono realizzati tramite il frameworkper applicazioniWebASP.NETe sono utilizzabili attraverso il protocollo SOAP. Sono quattro e permettono rispet-tivamente di gestire e processare sia documenti sia work low.

SOAP permette lo scambio di informazioni strutturate tra i Web Service e gliapplicativi client che li utilizzano. I dati sono rappresentati utilizzando il linguag-gio XML e sono trasferiti usando un protocollo a livello di applicazione come adesempio HTTP.

La struttura del protocollo SOAP e composta di tre elementi fondamentali:Envelope e l’elemento XML radice della struttura dati. Contiene gli altri due ele-

menti.Header se presente deve essere il primo elemento all’interno di Envelope. Puo

contenere informazioni speci iche dell’applicazione come ad esempio i datidi autenticazione.

Body e l’elemento principale, sempre contenuto nell’Envelope. All’interno del Bo-dy vanno posti gli elementi di chiamata, di risposta o di errore.

All’interno dell’elemento Body viene inserito un ulteriore elemento avente comenome quello della funzione che si vuole invocare. All’interno dell’elemento chia-mata vanno inseriti i parametri richiesti dalla funzione; l’elemento risposta, inve-ce, conterra i parametri in output dalla funzione. A ine esempli icativo di seguito eriportata la chiamata SOAP a una funzione chiamata “SayHello” che richiede comeparametro una stringa di nome “Name”:

1 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:foo="http://example.org/hello" >

2 <soap:Header/>3 <soap:Body>4 <foo:SayHello>5 <foo:Name>Pippo</foo:Name>6 </foo:SayHello>7 </soap:Body>8 </soap:Envelope>

Il messaggio SOAP di risposta, in genere, conterra all’interno dell’elemento Bo-dy un elemento avente lo stesso nome della funzione chiamata ma seguito da “Re-sponse” e contente i parametri di output:

36


1 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:foo="http://example.org/hello" >

2 <soap:Header/>3 <soap:Body>4 <foo:SayHelloResponse>5 <foo:Message>Hello Pippo!</foo:Message>6 </foo:SayHelloResponse>7 </soap:Body>8 </soap:Envelope>

Durante questa fase del progetto sono state testate approfonditamente tutte lefunzioni esposte da ogni singolo Web Service ma per brevita ne saranno descrittesolo alcune, quelle piu rilevanti ai ini della futura progettazione.

Gestione dei documenti (DocumentManagement)

Il Web Service DocumentManagement fornisce un insieme di funzioni per ca-ricare, per intero oppure per frammenti, i documenti, proteggerli con password,eliminarli, copiarli, sovrascriverli, scaricarli o ottenere le informazioni a essi asso-ciate.

La funzione UploadDocument permette l’upload del documento per intero de-inendone il nome e la durata della validita (in minuti). Il contenuto binario deldocumento viene caricato nel server inserendolo nel messaggio di richiesta dopoaverlo codi icato in . Un esempio di richiesta e la seguente:

1 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:com="HandSign.DocumentManagement" >

2 <soap:Header/>3 <soap:Body>4 <com:DocumentManagement>5 <com:DocumentName>Contratto.pdf</com:DocumentName>6 <com:Ttl>200</xyz:Ttl>7 <com:documentRawData> [documento in Base64] </com:

documentRawData>8 </com:DocumentManagement>9 </soap:Body>

10 </soap:Envelope>

Alla ine del caricamento viene restituito un messaggio di risposta contenenteun identi icativo associato al ile. L’identi icativo ottenuto come risposta puo es-sere utilizzato nelle chiamate alle altre funzioni per operare su un determinatodocumento.

Un’altra funzione importante e DeleteDocument che permette l’eliminazione diun documento dal server una volta completata la sua elaborazione. La chiamataalla funzione richiede come parametro l’identi icativo del documento.

37

4 Lo stage

Elaborazione dei documenti (DocumentProcessing)

Questo Web Service fornisce una serie di funzioni per l’elaborazione dei docu-menti e in particolare permette di svolgere le seguenti operazioni:

• aggiungere annotazioni a mano libera o da tastiera al documento;• aggiungere campi irma al documento;• aggiungere pagine o allegati al documento;• eseguire il parsing dei campi irma;• ottenere l’hash del documento;• convertire in immagini l’intero documento, una selezione di pagine oppureun’area;

• irmare un campo irma.Le funzioni offerte da questo Web Service non sono utilizzate direttamente da

applicativi client perche permettono di operare direttamente sul documento manon su di un work low. Queste funzionalita rientrano tra quelle “core” offerte dalserver e vengono a loro volta utilizzate dagli altri Web Service.

Gestione dei workflow (WorkflowManagement)

I work low sono creati, gestiti ed eliminati attraverso questoWeb Service. Sonoriproposte le funzioni di caricamento, download ed eliminazione di un documento,gia presenti in DocumentManagement. La struttura delle richieste e delle risposteche igurano sia inWork lowManagement e inDocumentManagement sono uguali.

Le funzionalita caratteristiche di questo Web Service permettono:• la creazione di un nuovo work low;• la consultazione dello stato e della con igurazione di un work low;• l’eliminazione di un work low.Alla creazionedi unnuovowork lowcon la funzioneCreateWork low e richiesta

una con igurazione in formato XML che indica, come descritto in precedenza, leazioni eseguibili dall’utente, la con igurazione dei campi irma, l’utilizzo di TSA odi HSM e l’operazione da eseguire alla conclusione del processo di irma.

La con igurazione dei campi irma puo essere fatta in due modi:1. de inendo un insieme di campi speci icando l’ordine di irma, le dimensioni,

le posizioni dei campi e altri parametri come il controllo biometrico dellairma;

2. ricercando nel testo del documento delle particolari stringhe e sostituendo-le con un campo da irmare. Il pattern delle stringhe segnaposto prevede deicaratteri di apertura e dei caratteri di chiusura. Tra questi due insiemi di ca-ratteri e possibile inserire dei parametri composti da coppie, separate tra di

38

loro da una virgola, di chiavi e valori che possono de inire l’ordine di irmadei campi, l’identi icativo dell’utente che deve apporre la irma (se e attiva lafunzionalita di identi icazione immediata del irmatario) e altri dettagli.

L’utilizzo della seconda modalita permette di creare un nuovo work low sola-mente caricando un documento contenente delle stringhe compatibili con il pat-tern de inito nella con igurazione. Questa soluzione permette di mantenere inva-riata la con igurazione da utilizzare.

Un esempiodi richiesta che indica il patternper il riconoscimentodelle stringhee la seguente:

1 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:com="http://com.HandSign">

2 <soap:Header/>3 <soap:Body>4 <com:CreateWorkflow>5 6 <com:documentId> … </com:documentId>7 8 <com: CreateWorkflowConfiguration>9 <![CDATA[

10 <workflowConfiguration>11 <DefaultWidth>100</DefaultWidth>12 <DefaultHeight>50</DefaultHeight>13 <signaturePluginConfiguration>14 <PdfSignatureProperties>15 <SignatureTimestampData>16 <Password />17 <SignatureHashAlgorithm>SHA1</

SignatureHashAlgorithm>18 <Uri ></Uri>19 <UserName />20 </SignatureTimestampData>21 </PdfSignatureProperties>22 <PdfSignatureCryptographicData>23 <SignatureHashAlgorithm>sha1</

SignatureHashAlgorithm>24 <SigningCertificateDescriptor>25 <Identifier> … </Identifier>26 <Type>Sha1Thumbprint</Type>27 <Csp>custom</Csp>28 </SigningCertificateDescriptor>29 </PdfSignatureCryptographicData>30 </signaturePluginConfiguration>31 <FinishAction>32 <ServerAction callSynchronous="0">http://www.google.

at</ServerAction>33 </FinishAction>34 <SigStringParsingConfiguration>35 <SigStringsForParsing>

39

4 Lo stage

36 <StartPattern>^sig</StartPattern>37 <EndPattern>^</EndPattern>38 <ClearSigString>1</ClearSigString>39 </SigStringsForParsing>40 </SigStringParsingConfiguration>41 <GeneralPolicies>42 <AllowSaveDocument>1</AllowSaveDocument>…43

44 </GeneralPolicies>45 </workflowConfiguration>46 ]]>47 </com:CreateWorkflowConfiguration>48 </com:CreateWorkflow>49 </soap:Body>50 </soap:Envelope>

Come prima cosa e richiesto l’identi icativo del documento, caricato in prece-denza con una delle altre funzioni analizzate, che vogliamo utilizzare per il proces-so di irma.

I primi parametri che vengono de initi sono le dimensioni che avranno i cam-pi irma una volta sostituiti alle stringhe. In seguito vengono indicati i parametriper l’utilizzo di una TSA per l’applicazione dei timestamp attraverso l’elementoSignatureTimestampData. In PdfSignatureCryptographicData viene speci i-cato l’utilizzo omeno del plug-in personalizzato per collegare la irma al documen-to. L’elemento FinishAction de inisce l’operazione da eseguire al termine dellaprocedura di irma mentre subito dopo troviamo la con igurazione del parsingdelle stringhe che indicano i campi irma. Nel momento in cui il documento vie-ne analizzato le stringhe che sono valide secondo il pattern de inito comportanol’inserimento di un campo irma; se si desidera rimuovere la stringa dal documen-to inale sara necessario assegnare il valore 1 all’elemento ClearSigString. Unesempio del risultato di questo processo e descritto dalla Figura 4.3 e dalla Figura4.4.

Figura 4.3: Documento PDF contenente le stringhe segnaposto per i campi irma

L’ultimo elemento, GeneralPolicies, ha lo scopo di controllare quali opera-zioni puo eseguire l’utente una volta iniziata la procedura.

40


Figura 4.4: Documento visualizzato nella schermata di irma dopo la creazione delwork low con riconoscimento delle stringhe segnaposto

Al termine della creazione delwork lowviene restituito come risultato un iden-ti icativo che dovra essere utilizzato per le operazioni riguardanti la procedura.

Una volta terminato l’utilizzo di un work low e possibile eliminare tutti i da-ti e i ile che sono stati creati durante la sua elaborazione attraverso la funzio-ne DeleteWorkflow. Questa funzione richiede come parametro l’identi icativo delwork low che si vuole eliminare e ritorna un messaggio di operazione terminatacon successo o unmessaggio di errore. Questa funzione non elimina il ile caricatoin origine e sul quale e stata creata la procedura di irma; per eliminare tale ilebisognera ricorrere alla funzione DeleteDocument.

Elaborazione dei workflow (WorkflowProcessing)

Quest’ultimoWeb Service consente l’elaborazione dei work lowma include an-che tutte le funzioni fondamentali degli altri inmodo da permettere l’utilizzo di unsolo servizio. Le funzioni che sono esposte e che risultano ripetute negli altri WebService svolgono le stesse azioni, accettando e restituendo le stesse strutture dati.

Le funzioni che sono proprie di questo Web Service sono:• irma di un campo associato a un determinato work low;• conferma della lettura del documento;• reperimentodelle paginedel documentoda irmare sotto formadi immagini;• annullamento dell’ultima operazione eseguita;• annullamento della procedura di irma;• accettazione e chiusura della procedura di irma.La funzione piu importante e quella di apposizione della irma, SignDocument.

I parametri richiesti da questa funzione sono l’identi icativo del work low, il codi-ce che identi ica il campo per cui si richiede l’apposizione della irma, l’immaginedella irma e i dati biometrici cifrati. I dati biometrici vengono codi icati in Base64e poi cifrati con un algoritmo a chiave simmetrica. La chiave usata per la cifratu-ra simmetrica viene a sua volta cifrata utilizzando la chiave pubblica associata aun certi icato di proprieta del server. In questo modo e garantita la sicurezza del

41

4 Lo stage

trasferimento (solo il server possiede la chiave privata per decifrare la chiave sim-metrica che protegge i dati biometrici) e le prestazioni risultano migliori rispettoall’utilizzo della sola cifratura asimmetrica.

Altre funzioni utili sono le seguenti:GetFile dato l’identi icativo di un ile si ottengono i dati binari codi icati in Ba-

se64.GetDocuemtnImages dato l’identi icativo di unwork low si ottiene la lista di iden-

ti icativi corrispondenti alle immagini generate per ogni pagina del docu-mento associato. Nella richiesta vanno speci icati i parametri di conversioneche sono: tipo di ile creato (JPG o PNG), qualita e dimensioni dell’immagine.

GetWorkflowInformation dato l’identi icativo di unwork low si ottengono le in-formazioni relative allo stato corrente del processo di irma.

GetDocumentHash dato l’identi icativo di un work low si ottiene l’hash del docu-mento allo stato corrente. E necessario per collegare i dati di irma ai datisottoscritti.

FinishWorkflow dato l’identi icativodi unwork lowchiude correttamente lapro-cedura di irma e il documento a essa associato.

RejectWorkflow dato l’identi icativo di un work low annulla l’operazione di ir-ma e chiude il documento a essa associato.

GetBiometricSignedDocument dato l’identi icativo di un work low restituisce idati binari codi icati in Base64 del documento che si sta irmando. Nel do-cumento sono contenute anche tutte le irme apposte accompagnate dai datibiometrici.

GetNonbiometricSignedDocument dato l’identi icativo di un work low si otten-gono i dati binari codi icati in Base64 del documento che si sta irmando sen-za dati biometrici. Questa funzione permette appiattire i vari livelli del docu-mento e di conservare nei campi irma solo l’immagine della sottoscrizione,rimuovendo tutti i dati biometrici e le irme elettroniche.

4.4.2.2 Integrazione con HSM

Per utilizzare un dispositivo HSM per il collegamento delle irme al documentoe necessario creare un apposito plug-in che implementa un’interfaccia speci icatada HandSign. Una volta preparato il componente e reso disponibile come libreriae possibile con igurare HandSign Server inmodo che venga utilizzato per eseguirele operazioni di irma di un hash con una chiave privata.

L’interfaccia che dovra essere implementata si chiama ISignPlugin e de iniscei seguenti metodi:

1. byte[] GetSigningCertificate(string certificateIdentifier,int identifierType)

42


2. byte[] SignHash(string certificateIdentifier,int identifierType, int hashAlgorithm, byte[] hash)

GetSigningCertificate ha lo scopo di de inire la segnatura del metodo chedovra recuperare il certi icato richiesto dato un suo identi icativo. Il certi icato puoessere ricercato per vari identi icativi e il piu utilizzato e lo Sah1Thumbprint checoincide con l’hash del certi icato stesso calcolato utilizzando la funzione SHA-1. Ilrisultato richiesto e il certi icato in formato grezzo quindi in array di byte.

SignHash de inisce la segnatura del metodo che si occupera di eseguire la ir-ma effettiva dell’hash del documento. Questa funzione viene richiamata al passo4 della procedura descritta nella Sezione 2.4. L’implementazione puo richiamarel’HSM se la chiave associata al certi icato utilizzato per la irma e contenuta in essoe se si utilizzano le funzionalita offerte dalle librerie fornite assieme al dispositivo,ad esempio tramite PKCS#11, CAPI o altre proprietarie.

L’utilizzo di questo componente durante la procedura di irma e indicato allacreazione del work low e in particolare dall’elemento “Csp” che deve avere co-me valore stringa “custom”, qualsiasi altro valore implica l’utilizzo della proceduraprede inita.

4.4.3 Studio dell’SDK HandSign Mobile Client per Android

Questo modulo consente la realizzazione di client mobile per dispositivi basatisu sistema operativo Android. L’SDK e fornito come libreria Android e puo essereutilizzato all’interno di altre app per permettere la irma di documenti. Il progettoprevede l’utilizzo di questa libreria da parte dell’applicazione che raccoglie i datidei contratti. Lo studio di questo componente ha lo scopo di analizzare le funzio-nalita offerte al ine di indicare agli sviluppatori quali sono le funzioni piu adatteper eseguire delle determinate azioni.

L’SDK e composto da un insieme di risorse, che vanno a comporre le scherma-te utilizzate per la visualizzazione e la irma di un documento, e da una libreria,contenente le classi che offrono le varie funzionalita. L’intera libreria e offuscata econsente l’utilizzo di un numero limitato di classi, attributi e metodi.

Tramite questo componente e possibile caricare un documento locale e irmar-lo, inserendodei campi irmaalmomento, oppureportare a termineunaproceduradi irma creata tramite i Web Service e avviata nel dispositivo attraverso un URLspeci ico. Nel caso speci ico del progetto l’applicativo mobile verra avviato attra-verso l’URL ottenuto come risultato della creazione di un work low. Questo indi-rizzo contiene l’IP pubblico del server di irma, la porta che offre il Web Service diregistrazione della irma e l’id del work low che si vuole processare.

Perminimizzare il traf ico di rete l’SDKpermette l’elaborazione delwork low inmodalita of line. In questo modo e possibile scaricare tutte le informazioni riguar-danti il documento da irmare (immagini delle pagine, informazione sui campi ir-ma e azioni eseguibili dall’utente), apporre tutte le irme richieste e solo almomen-

43

4 Lo stage

to della chiusura del processo caricare tutti i dati acquisiti nel server. Sebbene i da-ti biometrici vengano salvati sul dispositivo mobile cifrati, questo comportamentoriduce il livello di sicurezza. Un altro fattore negativo di questo comportamentopuo essere la perdita delle irme acquisite in caso di crash dell’app.

Le funzionalita messe a disposizione dell’utente sono:• apertura di un nuovo documento da irmare;• gestione di work low presenti nel dispositivo ( irmarli, sincronizzarli con ilserver, chiuderli, ri iutarli ed eliminarli dal dispositivo);

• aggiunta di annotazioni al documento;• invio del documento per email o salvataggio in locale.L’applicazione inale non prevede tutte queste funzionalita e l’utilizzo da parte

dell’utente dovra essere limitato alla visualizzazione del documento, all’apposizio-ne delle irme e all’accettazione o al ri iuto del processo. Le funzioni di salvataggiodel documento o l’apposizione di irme da documenti locali saranno disabilitate.

La classe principale che mette a disposizione le funzioni necessarie prende ilnome di DocumentHandler. Tra i metodi disponibili quelli analizzati sono:loadWorkflowFromUri richiede come parametro l’URL che identi ica un deter-

minato work low. Esegue automaticamente tutte le operazioni e le chiamateai Web Service necessarie per caricare la schermata di visualizzazione deldocumento. Tra i Web Service che vengono invocati sono inclusi quelli peril download delle pagine del documento come immagini e per il downloaddelle informazioni riguardanti il work low.

syncWorkflow richiede come parametro l’oggetto che rappresenta il work lowcorrentemente in fase di elaborazione. Questa funzione ha il compito di sin-cronizzare il work low locale con quello presente nel server.

DocumentHandler espone anche due parametri ad accesso pubblico:currentWorkflow procedura di irma correntemente in uso;workflowList lista delle procedure di irma salvate nella memoria locale del di-

spositivo.Il primo parametro e di tipo WorkflowHandler mentre il secondo e una lista

contenete piu istanze di questa classe. WorkflowHandler rappresenta un work-low e contiene le informazioni riguardanti le irme apposte, le irme da apporre,i permessi riservati all’utente e l’elenco dei ile e delle risorse utilizzate dalla pro-cedura di irma. I ile associati a un’istanza di WorkflowHandler possono essereeliminati dalla memoria locale del dispositivo richiamando la funzione, messa adisposizione dallo stesso oggetto, deleteWorkflow. Questa funzione richiede co-me parametro di input il contesto dell’applicazione, rappresentato da un’istanzadella classe Context.

DocumentHandler mette a disposizione dei metodi per de inire dei “listener”che vengono richiamati prima o dopo l’esecuzione di una determinata attivita. I

44


listener implementabili permettono di gestire i seguenti eventi:• apertura di un nuovo documento;• errore di un componente dell’SDK;• caricamento e conversione di un documento;• invio di un documento per email;• inizio dell’acquisizione di una irma;• completamento dell’acquisizione di una irma;• terminazione del work low;• annullamento del work low.Nelle Figure 4.5, 4.6 e 4.7 sono proposte, a titolo esempli icativo, alcune delle

schermate che vengono presentate per permettere la irma di un documento.

Figura 4.5: Schermata di visualizzazione del documento da irmare

45

4 Lo stage

Figura 4.6: Interfaccia di irma

Figura 4.7: Visualizzazione del documento dopo l’apposizione della prima irma

46

4.5 Supporto alla progettazione


Il supporto alla progettazione ha previsto l’af iancamento aimembri del gruppodi lavoro per la stesura dei documenti di Speci ica di Interfaccia, di Piani icazionedei Test e il Registro dei Test. Il primo documento, la Speci ica di Interfaccia, ha loscopo di indicare come sara composto il sistema che si andra a rilasciare; il secon-do, la Piani icazione dei Test, de inisce con che criteri si devono individuare i test,come questi devono essere progettati e che caratteristiche del sistema si voglio-no analizzare; il terzo, il Registro dei Test, elenca i test da eseguire con rispettivadescrizione, precondizioni e risultati attesi.

4.5.1 Specifica di interfaccia

Il documento di Speci ica di Interfaccia ha lo scopo di indicare come i sistemiesterni possono interagire con il sistema che si sta sviluppando fornendo tutte leinformazioni necessarie per l’integrazione del sistema. Questo documento de ini-sce i limiti del sistema che si sta sviluppando, le interfacce che quest’ultimo mettea disposizione di attori esterni e quelle che invece sono utilizzabili internamentedagli altri componenti.

Il sistema che il progetto Firma prevede di fornire comprende i seguenti ele-menti:

• due server che gestiscono la irma attraverso il software HandSign Server;• due HSM che si occupano della irma per collegare i dati biometrici al docu-mento;

• una libreria SDKperdispositivimobili chepermette di eseguire le operazionidi irma dato un determinato URL;

• eventualmente l’integrazione con una TSA.Gli attori esterni che andranno a utilizzare i moduli del sistema sono:• il server di gestionedocumentale chaha lo scopo creare le proceduredi irmae archiviare i documenti irmati, chiamato MobileAgent Server;

• un’app che si occupa dell’acquisizione dei dati per generare il contratto eche poi, attraverso le funzionalita dell’SDK, permette al cliente di apporre leirme, chiamata MobileAgent Client.

Le interfacce che saranno esposte verso il server di gestione documentale do-vranno prevedere la possibilita di eseguire le seguenti operazioni:

• caricamento di un documento;• creazione di un work low;• recupero del documento irmato contenente i dati biometrici;• recupero del documento irmato senza dati biometrici.

47

4 Lo stage

Quelle che invece saranno esposte all’app mobile consentono il solo avvio del-la procedura di irma attraverso l’URL che identi ica il work low creato dal serverdocumentale. Questa interfaccia verra estesa se sara richiesto l’utilizzo delle fun-zionalita per sincronizzaremanualmente lo stato del processo locale conquello delserver e la possibilita di eliminare i dati dal tablet una volta completate le irme.

Il diagrammadidistribuzione riportato in igura4.8descrive i componenti hard-ware, i componenti software in essi installati e le interfacce fornite.

4.5.1.1 Interfaccia per MobileAgent Server

L’interfaccia che verra esposta al server MobileAgent Server comprende alcu-ne delle funzioni offerte dal Web Service Work lowProcessing. Di seguito sarannodescritti i dettagli dei metodi esposti dall’interfaccia.UploadDocument: permette il caricamento di un documento

Input

DocumentName: nome del documento che si sta caricando. Nel server ilile verra salvato con questo nome

Ttl: numero di minuti che il server deve attendere dall’ultimo accessoal documento prima di eliminarlo

documentRawData: dati binari del documento codi icati in Base64Output

documentId: stringa che identi ica il documento caricatoCreateWorkflow: permette di creare un nuovo work low a partire da un docu-

mento gia caricato nel server e da una con igurazione appropriataInput

documentId: identi icativo del documento che si vuole irmareCreateWorkflowConfiguration: con igurazione che si vuoleutilizza-

re per la irma. Per maggiori dettagli riguardo questo parametrosi rimanda alla Sezione 4.4.2.1. La con igurazione deve essere unframmento XML ma contenuto in una sezione

Output

workflowId: stringa che identi ica il work low appena creato. Mobi-leAgent Server utilizzera questo id per generare l’URL richiesto peravviare il processo di irma da tablet

GetBiometricSignedDocument: permette di ottenere il documento contenente idati biometriciInput

workflowId: identi icativo del work low per il quale si vuole recupe-

48


«d

evic

e»

: S

erv

er

di firm

a

«e

xe

cu

tio

n e

nviro

nm

en

t»

: A

pp

lica

tio

n S

erv

er

«d

evic

e»

: T

SA

«d

evic

e»

: M

ob

ileA

ge

nt S

erv

er

«d

evic

e»

: H

SM

«d

evic

e»

: T

ab

let C

lien

t

«lib

rary

»

: H

an

dS

ign

Mo

bile

Clie

nt S

DK

*

*

Ta

ble

t A

nd

roid

o iO

S

*

*

1..

1

1..*

1..* *

Avvia

firm

a c

on

UR

L

«d

ocu

me

nt»

: C

hia

ve

priva

ta

SS

L

«lib

rary

»

: T

ime

Sta

mp

Se

rvic

e

SS

L

SS

L

Ric

hie

di

Tim

eS

tam

p

Firm

a h

ash

Ca

rica

me

nto

do

cu

me

nto

Re

cu

pe

ro d

ocu

me

nto

bio

me

tric

o

Re

gis

tra

firm

a

Ch

iam

ata

AP

I

SS

L

«lib

rary

»

: H

an

dS

ign

Se

rve

r

Sis

tem

i e

ste

rni

Sis

tem

a d

i firm

a

Re

cu

pe

ro d

ocu

me

nto

no

n

bio

me

tric

o

Figura 4.8: Diagramma di distribuzione del sistema

49

4 Lo stage

rare il documento contenente le irme e i dati biometriciOutput

DocumentId: stringa che identi ica il documentoSourceFileName: nome effettivo del ile indicato in fase di caricamen-

toSourceFileContent: contenuto binario del ile codi icato in Base64

GetNonbiometricSignedDocument: permettedi ottenere il documento contenen-te le irme solamente come immaginiInput

workflowId: identi icativo del work low per il quale si vuole recupe-rare il documento contenente le irme solamente come immagini

Output

DocumentId: stringa che identi ica il documentoSourceFileName: nome effettivo del ile indicato in fase di caricamen-

toSourceFileContent: contenuto binario del ile codi icato in Base64

4.5.1.2 Interfaccia per MobileAgent Client

L’interfaccia che verra esposta dall’SDK all’app MobileAgent Client compren-de una sola funzione che permette di avviare il processo di irma partendo da unURL. L’URL sara inviato al tablet da MobileAgent Server appena la creazione delwork low sara ultimata.loadWorkflowFromUri: dato l’URL di avvio del processo di irma si occupa di pre-

parare l’interfaccia gra ica per la visualizzazione del documento e per l’ap-posizione delle irmeInput

workflowUrl: URL contenente l’identi icativo del work low da elabo-rare, l’indirizzo IP del server di irma e l’indirizzo della porta allaquale e attivo il Web Service con il quale interagire

Output

non vengono restituiti output

4.5.1.3 Procedura di firma

La procedura di irma puo essere suddivisa sostanzialmente in tre fasi: creazio-ne e avvio della procedura, irma del documento e chiusura della procedura.

50


Per le procedure delineate si e deciso di utilizzare l’HSM per irmare l’hash deldocumento in modo da garantirne l’immodi icabilita. Per quanto riguarda il time-stamp sara utilizzato quello locale per la registrazionedei singoli campi irmamen-tre se ne usera uno apposito proveniente da una TSA per validare l’intero docu-mento al termine della procedura. Questa soluzione e stata pensata appositamen-te per ridurre il numero di marche autenticate da apporre ma e ancora in corso divalutazione da parte del cliente.

Creazione della procedura

La prima fase si occupa del caricamento del documento da irmare e della crea-zione della procedura di irma. I sistemi coinvolti sono:

• MobileAgent Server;• HandSign Server.L’avvio delle operazioni sara a carico di MobileAgent Server che carichera il

documento e creera un nuovo work low (Figura 4.9).

MobileAgent Server HandSign Server

UploadDocument

Id documento

CreateWorkflow

Id workflow

Figura 4.9: Creazione di una procedura di irma

Avvio della procedura

L’avvio della procedura di irma prevede la preparazione dell’interfaccia perla visualizzazione e l’acquisizione della irma dal tablet per mezzo di HandSignMobile Client SDK. I sistemi coinvolti sono:

• MobileAgent Client• HandSign Mobile Client SDK• HandSign ServerMobileAgent Client avvia il caricamento della procedura richiamando la fun-

zione [loadWork lowFromUri] di HandSign Mobile Client SDK, recuperando da

51

4 Lo stage

HandSign Server le informazioni riguardanti il work low, le immagini e l’hash deldocumento (Figura 4.10).

HandSign ServerMobileAgent ClientHandSign Mobile Client

SDK

loadWorkflowFromUri

GetWorkflowInformation

Informazioni workflow

GetDocumentImages

Immagini documento

GetDocumentHash

Hash docuemnto

Figura 4.10: Avvio di una procedura di irma

Firma del documento

L’acquisizione della irma del documento prevede l’apposizione della irma daparte del cliente, l’invio dei dati biometrici al server di irma e la irma dell’hashdel documento da parte dell’HSM. I sistemi coinvolti sono:

• HandSign Mobile Client SDK• HandSign Server• HSMAll’apposizione della irma da parte del cliente HandSign Mobile Client SDK ci-

fra i dati biometrici e li invia a HandSign Server. Il server procede elaborando ildocumento, aggiungendo i dati biometrici e un timestamp locale, per poi calcolar-ne l’hash. L’impronta ottenuta viene irmata dall’HSMepoi inserita nel documento.Completata la procedura di acquisizione della irma, HandSign Server restituiscea HandSign Mobile Client SDK le informazioni aggiornate sullo stato del work low.In ine HandSign Mobile Client SDK richiede le immagini e l’hash del documentoaggiornato. Il processo appena descritto e schematizzato in Figura 4.11.

52


Cliente

HandSign Mobile Client

SDK HandSign Server

Apposizione firma

HSM

SignDocument

Aggionta firma + timestamp locale al documento

Calcolo dell'hash

Richiesta firma hash

Hash firmato

Informazioni workflow

GetDocumentImages

Immagini documento

GetDocumentHash

Hash docuemnto

Figura 4.11: Registrazione di una irma

Chiusura della proccedura

Terminate le irme, l’utente puo concludere la procedura di irma accettando-la oppure, in ogni momento, annullandola. L’operazione di chiusura coinvolge iseguenti sistemi:

• HandSign Mobile Client SDK• HandSign Server• MobileAgent Server• TSANel caso in cui l’utente termini la procedura accettandola, HandSign Mobile

Client SDK noti ica HandSign Server dell’avvenuta accettazione. A questo puntoil server richiede una marca temporale alla TSA per poi aggiungerla al documen-to. Terminata la preparazione del documento MobileAgent Server viene noti icatodella terminazione della procedura, puo quindi richiedere i documenti irmati epoi eliminarli (Figura 4.12).

Se l’utente decide di annullare l’operazione HandSignMobile Client SDK richia-ma HandSign Server che noti ica MobileAgent Server della decisione dell’utente.In questo caso MobileAgent Server provvede alla sola eliminazione dei documenti(Figura 4.13).

53

4 Lo stage

Cliente


SDK HandSign Server

Accettazione

TSA

FinishWorkflow

Richiesta timestamp

Timestamp

MobileAgent Server

Notifica fine procedura

GetBiometricSignedDocument

Documento con dati biometrici

GetNonbiometricSignedDocument

Documento senza dati biometrici

DeleteWorkflow

DeleteDocument


Figura 4.12: Accettazione di una procedura di irma

Cliente


SDK HandSign Server

Annullamento

RejectWorkflow

MobileAgent Server


DeleteWorkflow

DeleteDocument

Notifica fine proceduta

Figura 4.13: Annullamento di una procedura di irma

54


4.5.2 Pianificazione e progettazione dei test

Nel documento Piani icazione dei Test sono elencate le metodologie e i critericon i quali si progettano, sviluppano ed eseguono i test, come si gestiscono i di-fetti riscontrati, l’ambiente di test da utilizzare, i tool che saranno impiegati e altridettagli di piani icazione come la formazione di team di test.

4.5.2.1 Criteri di definizione

I criteri di progettazione dei test sono stati delineati in modo da garantire lacreazione di un set adeguato di test. Si e richiesto di eseguire test che veri ichinoil comportamento delle funzionalita sotto analisi sia in caso di utilizzo correttoche scorretto. I test che analizzano il comportamento delle funzioni chiamate conparametri corretti comprendono i seguenti casi:

• chiamata della funzione con valori normali• chiamata della funzione con soli parametri obbligatori• chiamata della funzione con tutti i parametri disponibili• chiamata della funzione con i valori minimi ammessi• chiamata della funzione con i valori massimi ammessi• chiamata della funzione con valori di default• chiamata della funzione con valori nulli• chiamata della funzione con valori che rispettano vincoli di coerenza tra iparametri richiesti

mentre quelli corrispondenti ai comportamenti errati comprendono:• chiamata della funzione con parametri non conformi allo schema de inito(elementi XML con nome errato)

• chiamata della funzione con valori oltre i limiti accettati• chiamata della funzione senza l’uso di parametri• chiamata della funzione con piu parametri di quelli attesi• chiamata della funzione con valori nulli per parametri che non li accettano• chiamata della funzione con un tipo di dato errato• chiamata della funzione con valori non inclusi nella enumerazione richiestaper quel parametro

4.5.2.2 Progettazione dei test

Durante la fase di progettazione mi e stato assegnato il compito di speci icare itest a esito positivo di carattere generale che sono riportati di seguito.

55

4 Lo stage

T001: Caricamento di un documento per la creazione di un processo di irma contutti i dati richiestiCondizioni iniziali: MobileAgent Serverhaundocumentoprontoper essere

caricatoProcedura:

1. codi ica del documento PDF in Base642. compilazione della richiesta con il nome del ile, il documento co-

di icato e il TTL3. invio della richiesta

Risultati attesi: Il PDF e stato caricato e la risposta contiene l’identi icativoassegnato al documento

T002: Creazione di un work lowCondizioni iniziali: HandSign Server ha a disposizione un contratto in PDFProcedura:

1. compilazione della richiesta con l’id del documento da irmare e lacon igurazione

2. invio della richiestaRisultati attesi: Il work low e stato creato con successo ed e stato restituito

l’ID corrispondenteT003: Incorporazione di una irma nel documento

Condizioni iniziali:

1. HandSign Server ha un work low con campi irma2. HandSign Server ha ricevuto i dati biometrici di una irmadaun’ap-

plicazione clientProcedura: Partendo dal work low utilizzato

1. recuperare il documentId assegnato al ile caricato2. trovare il ile PDF nello storage di HandSign Server3. aprire il ile con il programma designato per la veri ica dei PDF

Risultati attesi: La irma e visibile nel documento e puo essere validata cor-rettamente dal software

T004: Applicazione del timestamp locale per ogni irma appostaCondizioni iniziali:

1. HandSign Server ha un work low con campi irma2. HandSign Server ha ricevuto i dati biometrici di una irmadaun’ap-

plicazione clientProcedura: Partendo dal work low utilizzato

56


1. recuperare il documentId assegnato al ile caricato2. trovare il ile PDF nello storage di HandSign Server3. aprire il ile con il programma designato per la veri ica dei PDF4. veri icare la validita del timestamp

Usando Adobe Reader la procedura e la seguente:1. cliccare sulla irma e poi su “Proprieta irma…”2. veri icare i dati nella sezione “Riepilogo validita”

Risultati attesi: In corrispondenza di “Riepilogo validita” e indicato “L’oradella irma proviene dall’orologio del computer del irmatario”

T005: Applicazione della marca temporale al documentoCondizioni iniziali:

1. HandSign Server ha un work low con campi irma2. HandSign Server ha ricevuto tutte le irme richieste3. il work low e stato completato con successo

Procedura: Partendo dal work low utilizzato1. recuperare il documentId assegnato al ile caricato2. trovare il ile PDF nello storage di HandSign Server3. aprire il ile con il programma designato per la veri ica dei PDF4. veri icare la validita del timestamp

Usando Adobe Reader la procedura e la seguente:1. cliccare sulla irma e poi su “Proprieta irma…”2. veri icare i dati nella sezione “Riepilogo validita”

Risultati attesi: Nella scheda “Data/Ora” sono riportati i dettagli della TSAe le caratteristiche della marca temporale

T006: Invio dell’ID del work low associato al PDF biometrico a MobileAgent Ser-verCondizioni iniziali: HandSign Server ha un work low completatoProcedura: Partendo da un work low attivo completarlo e veri icare che

MobileAgent Server sia noti icato con l’ID della procedura appena ter-minata. Utilizzare l’ID per recuperare il contenuto del PDF biometrico

Risultati attesi: Il contenuto del ile recuperato e un PDF valido contenentetutte le irme richieste e i relativi dati biometrici

T007: Invio dell’ID del work low associato al PDF non biometrico a MobileAgentServerCondizioni iniziali: HandSign Server ha un work low completato

57

4 Lo stage

Procedura: Partendo da un work low attivo completarlo e veri icare cheMobileAgent Server sia noti icato con l’ID della procedura appena ter-minata. Utilizzare l’ID per recuperare il contenuto del PDF non biome-trico

Risultati attesi: Il contenuto del ile recuperato e un PDF valido contenentetutte le irme richieste solamente come immagini

T008: Controllo della irma elettronicaCondizioni iniziali: Si e in possesso di un documento irmato con successo

attraverso il sistema di irmaProcedura: Aprire il ile PDF con l’applicativo de inito per l’analisi delle ir-

me (puo essere Acrobat Rader oppure quello consigliato da DigitPA)Risultati attesi: La irma e visibile e puo essere validata dal software. La

irma elettronica utilizzata per garantire l’integrita del documento evalida

T009: Controllo delle marche temporaliCondizioni iniziali: Si e in possesso di un documento irmato con successo

attraverso il sistema di irmaProcedura: Aprire il ile PDF con l’applicativo indicato per la veri ica dei

documenti. Usando Adobe Reader la procedura e la seguente:Timestamp locale:

1. cliccare sulla irma e poi su “Proprieta irma…”2. veri icare i dati nella sezione “Riepilogo validita”

Timestamp da TSA:

1. aprire il pannello “Firme”2. cliccare sull’ultima irma che risultera non visibile sul docu-

mento e poi su “Proprieta irma…”3. veri icare i dati nella sezione “Riepilogo validita”

Risultati attesi: I dati relativi alle marche temporali sono disponibili e va-lidi. I risultati attesi sono i medesimi di quelli indicati nei test T004 eT005

T010: Eliminazione documentoCondizioni iniziali: HandSign Server ha un work low completatoProcedura:

1. invio di una richiesta di eliminazione del work low concluso2. invio di una richiesta di eliminazione del documento caricato

Risultati attesi: Tutti i dati relativi al documento presenti nello stora-ge del server sono stati eliminati

58

4.6 Supporto allo sviluppo


Durante la fase di sviluppo si e proceduto con la produzione di piccoli compo-nenti software di prova.

Questa fase consisteva nella realizzazione di una piccola app per sistemi An-droid, che andasse a utilizzare le funzionalita che poi sarebbero state richieste daMobileAgent Client, e di un plug-in che permettesse l’integrazione con l’HSM.

4.6.1 Applicativo Android di prova

Durante lo studio della libreria HandSign Mobile Client SDK si e notato che laclasse adibita alla gestione di tutto il processo di irma non soddisfa automatica-mente tre requisiti:

1. permettere all’utente solamente le azioni di• visualizzazione del documento• irma del documento• annullamento dell’ultima operazione• accettazione della procedura• annullamento della procedura

2. sincronizzazione con il server alla registrazione di ogni singola irma3. eliminazione dei dati locali alla conclusione della proceduraLa soluzione adottata per risolvere il primo punto prevede l’eliminazione dal-

l’interfaccia gra ica dei pulsanti che permettono l’apertura di un documento salva-to sul tablet e l’eliminazione di alcune voci dal menu contestuale.

I punti due e tre sono stati risolti estendendo la classe DocumentHandler emo-di icandone le funzioni eseguite al termine dell’acquisizione di una irma e all’ac-cettazione e al ri iuto di una procedura.

Il funzionamento delle app Android e basato sull’estensione della classeActivity. Questa classe rappresenta un’attivita che puo essere lanciata da altreattivita o all’avvio dell’app stessa. E possibile avviare nuove attivita attraverso laclasse Intent e il metodo startActivityForResult, associando a esse un codiceche puo essere utilizzato per gestire i risultati al termine dell’esecuzione. Un og-getto di tipo Intent rappresenta il nuovo processo Android che si vuole avviare eper essere lanciato necessita, come parametri, dell’istanza Activity chiamante edella classe Activity che si vuole avviare. L’oggetto Intent permette di aggiun-gere ulteriori parametri, che l’attivita da lanciare potra richiamare durante la suaesecuzione, tramite il metodo putExtra. La classe Activity permette di gestire ilrisultato di attivita terminate attraverso il metodo onActivityResult.

La classe che estende DocumentHandler e stata chiamata MySing e puo esse-re avviata, per eseguire la procedura di irma, attraverso un oggetto Intent cui e

59

4 Lo stage

stato aggiunto l’URL da utilizzare. Il codice seguente permette di ottenere quantoappena detto:

1 // creazione di un nuovo oggetto Intent per avviare MySign2 Intent i = new Intent(this, MySign.class);3

4 // aggiunta all'intent dell'url da avviare5 i.putExtra("url", url);6

7 // avvio dell'attività8 this.startActivityForResult(i, SIGNDOCUMENT);

La classe DocumentHandler avvia automaticamente tutte le attivita necessa-rie per apporre le irme al documento. La registrazione di una singola irma pre-vede l’avvio di un’attivita speci ica, con il codice REQUESTSIGNCAPTURE. Per for-zare la sincronizzazione del work low, al termine dell’acquisizione di ogni irma,sara quindi suf iciente gestire la terminazione delle attivita aventi come codiceREQUESTSIGNCAPTURE attraverso ilmetodo onActivityResult. Il codice seguenteesegue la sincronizzazione del work low corrente utilizzando la funzionesyncWorkflow:

1 @Override2 protected void onActivityResult(int requestCode , int resultCode

, Intent data){3 // chiamata al metodo onActivityResult di DocumentHandler4 // per eseguire le operazioni predefinite e registrare5 // le firme acquisite nel workflow corrente6 super.onActivityResult(requestCode , resultCode , data);7

8 // se l'attività chiamata è la registrazione di una firma9 // e se il risultato è l'accettaizone della firma viene

10 // eseguita la sincornizzazione11 if(requestCode == REQUESTSIGNCAPTURE){12 if(resultCode == -1){13 syncWorkflow(currentWorkflow);14 }15 }16 }

Per eliminare i dati al termine dell’elaborazione di un work low non e possibileutilizzare lo stesso metodoma si possono indicare le procedure da eseguire all’ac-cettazione o all’annullamento di una procedura tramite i metodi setOnFinish esetOnCancel di DocumentHandler.

Questi due metodi richiedono come parametri rispettivamente le implementa-zioni delle interfacce FinishListener e CancelListener. Nel metodo che gesti-sce l’evento e suf iciente richiamaredeleteWorkflowdelwork lowcorrente. E uti-le de inire queste due nuove classi come interne alla classe che estendeDocumentHandler in modo da poter utilizzare direttamente il parametrocurrentWorkflow. Di seguito il codice dei due oggetti:

60


1 private class MyFinishListener implements FinishListener2 {3 @Override4 public boolean onFinish (String workflowId)5 {6 // rimozione dei dati locali7 currentWorkflow.deleteWorkflow(getApplicationContext());8 }9 }

10

11 private class MyCancelListener implements CancelListener12 {13 @Override14 public boolean onCancel (String workflowId)15 {16 // rimozione dei dati locali17 currentWorkflow.deleteWorkflow(getApplicationContext());18 }19 }

Come ultima cosa e necessario ride inire il metodo onCreate standard diMySign, che viene richiamatoall’esecuzionedella nuovaActivity, avviando il pro-cesso di irma utilizzando l’URL e aggiungendo la cancellazione dei dati alla termi-nazione del processo:

1 public void onCreate(Bundle savedInstanceState){2 // setup dei listener3 // viene richiamato alla chiusura del documento4 setOnFinish(new MyCancelListener());5

6 // viene richiamato al rifiuto del documento7 setOnCancel(new MyCancelListener());8

9 super.onCreate(savedInstanceState);10

11 // estrazione dell'intent associato all'attività12 Intent intent = getIntent();13 Bundle extras = intent.getExtras();14

15 // estrazione dell'url passato all'interno dell'intent16 String doc = extras.getString( ” u r l ”);17

18 // chiamata al metodo per caricare l'interfaccia di firma19 // a partire dall'url20 loadWorkflowFromUri(Uri.parse(doc));21 }

61

4 Lo stage

4.6.2 Sviluppo del plug-in di prova per l’HSM

Per provare l’integrazione con l’HSM e stato creato un plug-in da inserire nelcomponente HandSign Server. Il fornitore di HandSign ha messo a disposizioneuna serie di risorse per gli sviluppatori tra le quali e compresa l’interfaccia daimplementare utilizzando il linguaggio C#.

4.6.2.1 Ambiente di test

Non essendo disponibile l’HSM isico che sara utilizzato nella soluzione si eutilizzato un software di emulazione. Le librerie client fornite con questo HSMcomprendono JCE/JCA, PKCS#11, CAPI e CNG.

L’ambiente di test comprendequello utilizzato durante la fase di studio del com-ponente di irma con l’aggiunta di una nuova LAN virtuale, accessibile solo dal ser-ver di irma, contenente unamacchina virtuale sulla quale e stato installato l’emu-latore dell’HSM. In questo modo si e cercato di ricreare il piu fedelmente possibilel’architettura del sistema che sara installato. Tutti i dispositivi e le reti virtuali so-no state create tramite VMware nel PC adibito allo sviluppo. La Figura 4.14 riportaun’illustrazione esempli icativa dell’ambiente di test.

LAN VIRTUALE FIRMA LAN VIRTUALE HSM

HandSign Server virtuale

HSM virtuale

Tablet Android virtuale con

HandSign Mobile Client SDK

Workstation fisica di sviluppo

e test

Figura 4.14: Schema dell’ambiente utilizzato per lo sviluppo

4.6.2.2 Scelta della libreria

Per eseguire i test sono state valutate le seguenti librerie:• PKCS#11• Microsoft CAPI• Microsoft CNG

62


PKCS#11 permette di produrre software indipendente dalla piattaforma sul-la quale viene eseguito perche implementa un’interfaccia standard per le funzio-ni crittogra iche. PKCS#11 sembra la piu portabile ma si e notata la mancanza diun’implementazione in C#. Per utilizzare questa soluzione sarebbe necessario in-trodurre un’ulteriore libreria per rendere disponibili le funzioni PKCS#11 in C#,come ad esempio pkcs11.net. Questa soluzione e stata scartata perche non e risul-tato desiderabile introdurre un’ulteriore strato software.

La scelta e caduta su Microsoft CAPI e CNG. Queste librerie non comportanoaggiunta di ulteriore software e le varie implementazioni sono disponibili diretta-mente nel framework .NET, quindi anche per il linguaggio C#. Sono stati prodottidue plug-in differenti per CAPI e CNG perche la seconda e retrocompatibile e at-tualmente e permesso l’utilizzo di entrambe per la creazione di chiavi e certi icati.Come riportato nella Sezione 4.3.3.2, la gestione delle chiavi CAPI viene fatta daiCSPmentre quelle delle chiavi CNG dai KSP; sara necessario prestare attenzione alplug-in da usare in base al tipo di provider usato per la creazione della chiave perla irma.

4.6.2.3 Sviluppo del plug-in

Lo sviluppo di plug-in per la irma di un hash prevede l’implementazione del-l’interfaccia ISignPlugin e quindi dei metodi

1. byte[] GetSigningCertificate(string certificateIdentifier,int identifierType)

2. byte[] SignHash(string certificateIdentifier, int identifierType,int hashAlgorithm, byte[] hash)

E stata prodotta una libreria contenente due implementazioni: MyCSPSign, cheutilizza chiavi CSP, e MyCNGSign, che utilizza chiavi CNG.

Il primo metodo, GetSigningCertificate, permette di ottenere il certi ica-to associato alla chiave privata richiesta per l’apposizione della irma ed e ugualeper i due tipi di chiavi. I certi icati necessitano di essere salvati nell’archivio deicerti icati messo a disposizione dal sistema operativo, in particolare nella cartelladei certi icati personali, associati al computer e non all’utente. Il framework .NETmette a disposizione un set di funzioni C# che permette l’interazione con questoarchivio.

Come prima cosa e necessario creare un’istanza dello store dei certi icati, chepunta alla directory “Personal” della macchina locale, e aprirla in modalita di solalettura (non necessitiamo di apportare modi iche ai certi icati o allo store):

1 X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine);

2 store.Open(OpenFlags.ReadOnly);

63

4 Lo stage

Avendo un riferimento allo store e possibile cercare il certi icato usando unodei due tipi di identi icativo utilizzati da HandSign, lo Sha1Thumbprint o il Subjec-tKeyIdenti ier, tramite il metodo Find:

1 X509Certificate2Collection certColl = store.Certificates.Find(2 identifierType ,3 certificateIdentifier ,4 onlyValid5 );

Dove• identi ierType indica che tipo di parametro da usare per la ricerca, e di tipo

X509FindType e puo essere· X509FindType.FindByThumbprint

· X509FindType.FindBySubjectKeyIdentifier

• certificateIdentifier indica il valore da utilizzare per la ricerca, di tipostringa

• onlyValid indica se restituire solo i certi icati validi, di tipo booleanoIl metodo restituisce una collezione di certi icati ma cercando l’oggetto usando unparametro che lo identi ica univocamente otterremo un certi icato o nessuno. Ilcerti icato andra restituito come array di byte, e necessario quindi richiamare ilmetodo RawData di X509Certificate2.

Il secondo metodo, SignHash, permette di eseguire la irma di un hash, con undeterminato algoritmo, utilizzando la chiave privata associata al certi icato indica-to nel parametro certificateIdentifier. L’implementazione di questo metodorichiede, come prima cosa, la chiave privata con la quale effettuare la irma. Daquesta operazione il metodo e differente per chiavi CSP e CNG.

Se la chiave privata e gestita da un provider di tipo CSP e suf iciente accedereall’attributo PrivateKey del certi icato indicato per la irma. Questo oggetto rap-presenta un riferimento al CSP ed e quindi possibile eseguire la conversione a unoggetto di tipo RSACryptoServiceProvider per utilizzare le funzioni crittogra i-che:

1 X509Certificate2 cert = getCertificate(certificateIdentifier ,identifierType);

2 RSACryptoServiceProvider rsa = (RSACryptoServiceProvider)cert.PrivateKey;

A questo punto e possibile utilizzare le funzioni del provider per irmare il no-stro hash usando un determinato algoritmo:

1 byte[] sig = rsa.SignHash(hash, algorithmID);

Il parametro algorithmID e di tipo stringa e rappresenta l’Object identi ier (OID)dell’algoritmo da usare. Puo essere uno degli algoritmi supportati da HandSign:Sha1: CryptoConfig.MapNameToOID("SHA1");

64


Sha256: CryptoConfig.MapNameToOID("SHA256");

Sha512: CryptoConfig.MapNameToOID("SHA512");

Se invece la chiave privata e di tipo CNG il provider che gestisce le chiavi noncoincide con il provider che permette di eseguire funzioni di cifratura o irma. Da-to che CNG distingue tra provider di chiavi (KSP) e di servizi crittogra ici (CNGcryptographic provider) non e piu suf iciente eseguire la conversione della chiaveprivata a provider, come si faceva per CSP. Si dovra, invece, creare un’istanza delprovider richiesto usando la chiave privata CNG.

Per la generazione della irma e necessario usare un provider di servizi RSAcome RSACng, creato partendo dalla chiave CNG:

1 X509Certificate2 cert = getCertificate(certificateIdentifier ,identifierType);

2 RSACng rsaCng = new RSACng(cert.GetCngPrivateKey());

A questo punto e possibile utilizzare le funzionalita di irma offerte dal provider:1 byte[] sig = rsaCng.SignHash(hash, algorithmID);

dove il parametro algorithmID e di tipo CngAlgorithm e puo essere uno deglialgoritmi supportati da HandSign:Sha1: CngAlgorithm.Sha1

Sha256: CngAlgorithm.Sha256

Sha512: CngAlgorithm.Sha512

65

5 Valutazione retrospettiva

L’esperienza di stage presso Accenture mi ha permesso di provare il mondo dellavoro in campo informatico dal punto di vista di una grande azienda di consulenza.La struttura interna e la metodologia di lavoro dell’azienda mi hanno dimostratocome è importante ed essenziale lo sforzo di ogni singolo individuo e quanto sianecessario valorizzarlo.

5.1 Conoscenze acquisite

La fase iniziale della mia attivita di stage, quella dedicata allo studio, e stata difondamentale importanza emi ha permesso di acquisire sia conoscenze totalmen-te nuove sia integranti a quelle apprese durante i corsi universitari.

Un ambito che personalmente mi e sembrato molto stimolante, anche se nondirettamente collegato al mio percorso di studi, e stato lo studio delle normativeriguardanti la irma elettronica e le attenzioni da prestare per produrre soluzio-ni conformi a tali regole. Lo studio di questi documenti mi ha permesso di capirecome analizzare normative europee e italiane in merito a materie informatiche.

Per quanto riguarda l’ambio informatico ho appreso le differenze tra le varie ti-pologie di irme elettroniche, sempre secondo la normativa italiana, e gli strumentitecnologici necessari per implementarle. Tra le varie tecnologie studiate quella cheho trovato piu interessante e stata l’utilizzo delle CAPI di Microsoft. Attraverso lostudio di queste API ho compreso come il sistema operativo genera, gestisce e uti-lizza chiavi crittogra iche e certi icati, sia attraverso amministrazione con consoledi gestione sia attraverso la produzione di applicativi.

Sempre grazie a questa attivita di stage ho potuto integrare conoscenze che ave-vo gia appreso durante i corsi universitari o durante i progetti formativi: ho ap-profondito l’uso del linguaggio XML per lo scambio di dati (attraverso l’utilizzo delprotocollo SOAP), lo studio di nuovi linguaggi (C#) e lo sviluppo di applicazioni perdispositivi Android.

5.2 Preparazione accademica e mondo del lavoro

Terminata l’attivita di stage posso affermare che la preparazione accademicache mi e stata fornita durante il corso di studi e stata adeguata e rappresenta un

67

5 Valutazione retrospettiva

ottimo bagaglio culturale per l’inserimento nel mondo del lavoro.Le conoscenze acquisite immediatamente spendibili non sono state quelle no-

zionistiche o teoriche ma piuttosto i metodi di studio di nuove tecnologie e di la-voro in gruppo. Queste nozioni permettono un adattamento molto veloce ai variambiti lavorativi che il mondo dell’informatica offre.

Sono stati particolarmente utili i corsi che hanno previsto lo sviluppo di un pro-getto didattico in team perche mi hanno permesso di capire come possono esseregestiti i processi di sviluppo sia in gruppi di piccole dimensioni che in gruppi dilavoro piu strutturati e formali. In particolare il corso di Ingegneria del Softwaremi ha permesso di acquisire dimestichezza con la produzione di documentazionetecnica e con la suddivisione dei ruoli, richiesta anche durante lo stage.

Le conoscenzenozionistiche e teoriche si sono rivelate un’ottimabase alla qualee stato facile aggiungere nuovi concetti quali la irma elettronica e le tecnologie perla sua implementazione.

In de initiva mi ritengo soddisfatto del corso di laurea triennale in Informaticaperche mi ha fornito tutti gli strumenti necessari per affrontare in modo prepara-to e sereno questo periodo di prova del mondo del lavoro e sono sicuro che saraaltrettanto valido per un impiego futuro.

68

Glossario

API In informatica indica un protocollo utilizzato come interfaccia per la comuni-cazione tra varie componenti software. Gli sviluppatori si servono di questainterfaccia per integrare moduli all’interno di software personalizzato.

Base64 Sistema per la codi ica di dati binari in stringhe di caratteri. Questo tipo dicodi ica permette lo scambio di dati binari sotto forma di testo, ad esempioall’interno di email o frammenti XML.

CDATA Nel metalinguaggio XML indica una porzione del documento contenentecaratteri generici e non strutturati tramite tag.

CWA Standard sviluppatoduranteunworkshopdell’EuropeanCommittee for Stan-dardization (CEN). La partecipazione ai workshop e aperta a tutte le partiinteressate nella de inizione dell’accordo. Un CWA non valore di StandardEuropeo.

CA Ente di terza parte che rilascia certi icati digitali.CC Abbreviazione di Common Criteria for Information Technology Security Eva-

luation, e uno standard internazionale (IOS/IEC 15408) per la certi icazio-ne della sicurezza informatica. Il Common Criteria de inisce un frameworkattraverso il quale il richiedente di un sistema informatico puo de inire deirequisiti funzionali e di af idabilita riguardanti la sicurezza, il fornitore puoimplementare tali requisiti e gli enti di certi icazione possono valutare se lasoluzione prodotta soddisfa le richieste speci icate.

CAPI InsiemediAPI incluse nei sistemi operativiMicrosoftWindows chepermet-te allo sviluppatore di utilizzare in modo sicuro funzionalita crittogra iche.

CSP Insieme di librerie incluse nelle CAPI che forniscono le funzionalita critto-gra iche concrete. Possono essere prodotte da terzi e integrate facilmente nelsistema operativo e negli applicativi per estendere le funzioni crittogra icheprede inite.

CNG Nuova versione delle CAPI che ride inisce la struttura delle API e nemigliorale funzionalita.

DigitPA Ente nazionale per la digitalizzazione della pubblica amministrazione,trasformato da CNIPA in attuazione del D.Lgs. 177 del 1 dicembre 2009. Trai suoi scopi vi e quello di dettare regole tecniche inmateria di progettazione,realizzazione e gestione di sistemi informatici in uso alle amministrazioni.

69

Glossario

EAL Grado espresso con un valore numerico, assegnato ad un sistema informa-tico al termine della valutazione di sicurezza CC. I valori vanno da 1 a 7 eun alto grado EAL equivale all’implementazione di un numero maggiore difunzionalita di sicurezza.

FAR Valore numerico che indica in percentuale quanti falsi input vengono ritenutivalidi da un sistema di riconoscimento biometrico. Nel caso della irma gra-fometrica indica quante irme false vengono riconosciute come autentiche.Assieme al FRR, indica la bonta di un sistema di riconoscimento biometrico.

FRR Valore numerico che indica in percentuale quanti input corretti vengono ri-tenuti falsi da un sistema di riconoscimento biometrico. Nel caso della ir-ma grafometrica indica quante irme autentiche vengono riconosciute co-me false. Assieme al FAR, indica la bonta di un sistema di riconoscimentobiometrico.

HSM Particolare dispositivo hardware il cui scopo e quello di accelerare ope-razioni crittogra iche, creare, conservare e utilizzare chiavi elettroniche efornire per le operazioni di gestione dei dati sensibili.

HR In italiano risorse umane, usato in ambitomanageriale indica gli individui chefanno parte della forza lavoro di un’azienda. Il termine evidenzia il valoredei dipendenti come capitale, derivante dalle loro competenze e dalla loroprofessionalita.

IDE Applicativo che mette a disposizione del programmatore un set di strumentiper lo sviluppo di software.

JCA Parte della piattaforma Java che offre funzioni e classi riguardanti la sicu-rezza. JCA comprende un’architettura basata su “provider” e un set di APIche permette l’esecuzione di funzioni crittogra iche. Tra le funzionalita of-ferte e compresa la generazione di chiavi, la cifratura, il calcolo di hash e lagenerazione di numeri casuali.

JCE Nato come un pacchetto di espansione e poi incluso nella distribuzione Java2 SDK, estende le funzionalita crittogra iche offerte da JCA.

KSP Moduli per la gestione del materiale crittogra ico sensibile, introdotte dalleCNG. La funzionalita principale di questo modulo e quello di isolare i datisensibili, come ad esempio le chiavi crittogra iche, dal lusso di esecuzionedell’applicazione che li utilizza.

MMC Applicazionepresentenei sistemiMicrosoftWindowscon funzionalita pret-tamente amministrative. L’amministrazione delle varie funzionalita del si-stema e gestita attraversouna collezioneestendibile dimoduli chiamati snap-in.

70

Glossario

Modello agile Insieme di processi per lo sviluppo di prodotti software caratteriz-zato da una profonda interazione con il committente e dalla duttilita del pro-getto. Tra i principi fondamentali del modello agile c’e il rilascio frequente disoftware funzionante e la possibilita di modi icare i requisiti che il prodottodeve soddisfare anche durante stadi avanzati di sviluppo.

OID In informatica, un object identi ier e una stringa univoca utilizzata come no-me per un oggetto.

PAdES Insieme di restrizioni e requisiti, aggiunti allo standard PDF e ISO 32000-1, tali dal permettere l’utilizzo della irma elettronica avanzata all’interno didocumenti elettronici. Questo standard e pubblicato da ETSI con l’identi ica-tivo TS 102 778, utilizzabile per gli scopi delineati nella direttiva europea inmerito alla irma elettronica[10].

PKCS#11 Standard, il cui nome esteso e Cryptographic Token Interface Stan-dard, che de inisce un insieme di API, chiamate Cryptoki, per l’interazionecon dispositivi che gestiscono materiale e funzioni crittogra iche.

Risk Management In italiano “gestione del rischio”, comprende l’identi icazione,la valutazione e la gestione delle priorita dei rischi che l’attivita lavorativasotto analisi puo comportare. Al termine dell’identi icazione e della valuta-zione di un rischio si possiedono le conoscenze necessarie per svilupparedelle strategie per governarlo.

SSL Protocollo per la comunicazione sicura tra due entita attraverso Internet. SSLfornisce autenticazione, integrita dei dati e cifratura permettendo di preve-nire l’intercettazione e la falsi icazione deimessaggi. L’utilizzo della cifraturaa chiave asimmetrica permette, durante la fase di connessione, l’identi ica-zione reciproca degli interlocutori e lo scambio di una chiave simmetrica perla cifratura dei messaggi.

SOAP Protocollo per lo scambio dimessaggi strutturati tra componenti software,basato sul metalinguaggio XML. Data la sua versatilita e facilita di modella-zionedi dati strutturati, questo tipodi protocollo e utilizzato prevalentemen-te da Web Services.

SDK Insieme di strumenti e librerie che permettono lo sviluppo di software peruna determinata piattaforma o dispositivo. Generalmente sono compresedelle API, delle librerie per l’interazione con l’hardware per il quale si stasviluppando e una documentazione esaustiva.

Strong authentication Chiamata anche autenticazione a due fattori, la strong au-thentication si basa sull’utilizzo combinato di due di questi elementi:

• qualcosa di cui si e a conoscenza (una password o un PIN);• qualcosa che si possiede (una carta di credito o una pennetta USB);

71

Glossario

• qualcosa di unico che caratterizza l’individuo (le impronte digitali ol’iride).

Questo tipo di autenticazione e impiegata per proteggere dati sensibili comedati bancari o materiale crittogra ico.

System integrator Termine inglese che indica un ente o una persona che si occu-pa dell’unione e dell’integrazione di piu componenti di un sistema. Nel cam-po informatico l’integrazione consiste nel connettere e far dialogare tra diloro sistemi diversi, per caratteristiche e funzionalita, in modo da acquisire,manipolare e visualizzare dati.

TLS Aggiornamento della versione 3.0 di SSL che aumenta l’af idabilita e la sicu-rezza della connessione rispetto allo standard precedente.

UTC(IEN) Scala di tempo nazionale generata dall’Istituto Elettronico Nazionale(ora parte dell’Istituto Nazionale di Ricerca Metrologica).

72

Acronimi

API Application Program Interface.

CA Certi ication Authority.CAD Codice dell’Amministrazione Digitale.CAPI Cryptographic Application Programming Interface.CC Common Criteria.CNG Cryptography API: Next Generation.CNIPA Centro Nazionale per l’Informatica nella Pubblica Amministrazione, vedi

DigitPA.CSP Cryptographic Service Providers.CWA CENWorkshop Agreement.

D.Lgs. Decreto Legislativo.DigitPA Ente nazionale per la digitalizzazione della pubblica amministrazione.DPCM Decreto del Presidente del Consiglio dei ministri.

EAL Evaluation Assurance Level.ETSI European Telecommunications Standards Institute.

FAR False Acceptance Rate.FEA Firma Elettronica Avanzata.FRR False Rejection Rate.

HR Human resources.HSM Hardware Security Module.

IDE Integrated development environment.

JCA Java Cryptography Architecture.JCE Java Cryptography Extension.

KSP Key Storage Provider.

73

Acronimi

MMC Microsoft Management Console.

OCSI Organismo di Certi icazione della Sicurezza Informatica.OID Object identi ier.

PAdES PDF Advanced Electronic Signatures.PDF Portable Document Format.

SDK Software development kit.SOAP Simple Object Access Protocol.SSL Secure Socket Layer.

TLS Transport Layer Security.TSA Time Stamp Authority.TSP Time Stamping Protocol.

74

Bibliografia

Riferimenti bibliografici

[3] C. Adams et al. Internet X.509 Public Key Infrastructure Time-Stamp Protocol(TSP). RFC3161 (Proposed Standard). Internet EngineeringTask Force, ago.2001. : http://www.ietf.org/rfc/rfc3161.txt (cit. a p. 12).

[6] Decisione della Commissione del 14 luglio 2003 relativa alla pubblicazione deinumeri di riferimento di norme generalmente riconosciute relative a prodottidi irma elettronica conformemente alla direttiva 1999/93/CE del Parlamen-to europeo e del Consiglio. 2003/511/CE. 2003.

[7] Deliberazione CNIPA 21 maggio 09, n. 45. Regole riconoscimento e veri icadoc. informati. 2009 (cit. a p. 8).

[10] Direttiva 1999/93/CE del Parlamento europeo e del Consiglio del 13 dicembre1999 relativaadunquadro comunitario per le irme elettroniche. 1999/93/CE.1999 (cit. a p. 71).

[11] D.Lgs. 1 dicembre 2009, n. 177. Riorganizzazione del Centro nazionale perl’informatica nella pubblica amministrazione, a norma dell’articolo 24 dellalegge 18 giugno 2009, n. 69. 177. 2009 (cit. a p. 5).

[12] D.Lgs. 7 marzo 2005, n. 82. Codice dell’amministrazione digitale. 2005.

[13] DPCM30marzo 2009. Regole tecniche inmateria di generazione, apposizionee veri ica delle irme digitali e validazione temporale dei documenti informa-tici. 2009.

[14] ESI. Electronic Signatures and Infrastructures (ESI); PDF Advanced Electro-nic Signature Pro iles; Part 1: PAdES Overview - a framework document forPAdES. Rapp. tecn. ETSI TS 102 778-1 V1.1.1. ETSI Technical CommitteeElectronic Signatures e Infrastructures, 2009 (cit. a p. 10).

[17] ISO. Document management—Portable document format—Part 1: PDF 1.7.Rapp. tecn. 32000‒1:2008. International Organization for Standardization,2008 (cit. a p. 10).

[18] Giovanni Manca. «Il decalogo della irma grafometrica». In: Information Se-curity. 3a ser. 8 (feb. 2012), pp. 55–61 (cit. a p. 9).

75

http://www.ietf.org/rfc/rfc3161.txt

Bibliogra ia

[19] OCSI. Procedura di Accertamento di Conformità di un Dispositivo per la Crea-zione di Firme Elettroniche ai Requisiti di Sicurezza Previsti dall’Allegato IIIdella Direttiva 1999/93/CE. 2010 (cit. a p. 29).

[22] Schema di DPCM ai sensi degli articoli 20, comma 3, 24, comma 4, 28, comma3, 32, comma 3, lettera b), 35, comma 2, 36, comma 2 e 71, del D.Lgs. 7 marzo2005 n. 82. : http://www.digitpa.gov.it/sites/default/files/allegati_tec/Schema_Regole_tecniche-firme_elettroniche.pdf(cit. a p. 8).

Siti Web consultati

[1] Accenture: la crescita di un leader mondiale. : http://www.accenture.com / it - it / company / overview / history / Pages / growth - global -leader.aspx.

[2] Accenture Technology Solutions. : http://careers.accenture.com/it-it/about/technology/Pages/technology-solutions.aspx.

[4] Cryptographic Service Providers. 2012. : http : / / msdn . microsoft .com/it-it/library/windows/desktop/aa380245(v=vs.85).aspx.

[5] Cryptography API: Next Generation. 2012. : http://msdn.microsoft.com/it-it/library/windows/desktop/aa376210(v=vs.85).aspx.

[8] DigiStamp :: Price ofDigital Timestamps fromaTrustedTimestampAuthority.: http://www.digistamp.com/subpage/price/ (cit. a p. 32).

[9] DigitPA - Firmeelettroniche e certi icatori. 2013. :http://www.digitpa.gov.it/firme-elettroniche-certificatori.

[15] Fatti e cifre - Accenture Italia. : http : / / www . accenture . com / it -it/company/overview/history/Pages/growth-global-leader.aspx.

[16] HSMBuyers’ Guide - Documentation ReferenceMaterial - OpenDNSSEC. 2012.: https://wiki.opendnssec.org/display/DOCREF/hsm+Buyers'

+Guide (cit. a p. 30).

[20] OpenSSL: Documents, openssl(1). 2012. : http://www.openssl.org/docs/apps/openssl.html.

[21] RSA Security Information Security Glossary. : http://www.rsa.com/glossary.

76

http://www.digitpa.gov.it/sites/default/files/allegati_tec/Schema_Regole_tecniche-firme_elettroniche.pdf

http://www.digitpa.gov.it/sites/default/files/allegati_tec/Schema_Regole_tecniche-firme_elettroniche.pdf

http://www.accenture.com/it-it/company/overview/history/Pages/growth-global-leader.aspx



http://careers.accenture.com/it-it/about/technology/Pages/technology-solutions.aspx

http://careers.accenture.com/it-it/about/technology/Pages/technology-solutions.aspx

http://msdn.microsoft.com/it-it/library/windows/desktop/aa380245(v=vs.85).aspx




http://www.digistamp.com/subpage/price/

http://www.digitpa.gov.it/firme-elettroniche-certificatori

http://www.digitpa.gov.it/firme-elettroniche-certificatori



https://wiki.opendnssec.org/display/DOCREF/hsm+Buyers'+Guide

https://wiki.opendnssec.org/display/DOCREF/hsm+Buyers'+Guide

http://www.openssl.org/docs/apps/openssl.html

http://www.openssl.org/docs/apps/openssl.html

http://www.rsa.com/glossary

http://www.rsa.com/glossary

Studio e progettazione di una soluzione di firma elettronica conforme alla normativa italiana

Documents

Transcript of Studio e progettazione di una soluzione di firma elettronica conforme alla normativa italiana