|
|
|
|
Sono stati finora descritti i concetti e gli strumenti che consentono di progettare una infrastruttura per lo scambio sicuro di informazioni e per l’autenticazione degli utenti. Si è cercato di evidenziare le problematiche, i vantaggi e i limiti di ciascuna soluzione, ed è stata sottolineata l’importanza del dimensionamento del sistema.
Il nostro obiettivo è ora quello di studiare e definire un contesto operativo che consenta l’implementazione di questi servizi in un ambito universitario. Vogliamo offrire la possibilità a studenti, professori e dipartimenti di avviare o prendere parte ad una infrastruttura che consenta il reciproco ed inconfutabile riconoscimento, e semplifichi la gestione delle comunicazioni.
I requisiti fondamentali sono: · L’utilizzo di standard aperti e non proprietari· La scelta di una struttura che possa poi essere inserita in un contesto più ampio al momento dell’avvio di un eventuale progetto di carattere, ad esempio, nazionale.· L’utilizzo di strumenti semplici e di uso comune, quali la posta elettronica, per offrire i servizi di cui si ha bisogno
I servizi che vogliamo offrire agli utenti sono: · Firma di documenti elettronici· Cifratura di documenti elettronici· Posta elettronica sicura S/MIME
Gli strumenti di cui abbiamo bisogno sono: · Un Client per svolgere funzioni di posta elettronica S/MIME, di cifratura e firma di documenti elettronici.· Un Server CA per svolgere le operazioni di validazione e emissione di certificati necessari per l’utilizzo del Client
Per via del contesto in cui ci muoviamo presteremo inoltre particolare attenzione alle specifiche e alle direttive in materia di firma elettronica, di PKI, e di Certification Authorithy emesse dall’AIPA, congiuntamente alle norme legislative italiane in materia.
La progettazione della struttura di una PKI è, come è già stato notato, un elemento molto delicato.
Generalmente l’inserimento della propria struttura all’interno di una PKI avviene quando è già definito un contesto più ampio, e la struttura è stata già avviata, almeno ai livelli superiori. La scelta si riduce allora a valutare se sia opportuno avviare una propria sub-CA, o se sia preferibile appoggiarsi ai servizi di certificazione di una CA già avviata. Non bisogna trascurare l’impegno richiesto dalla gestione di una CA, e dall’espletamento di tutte le procedure e le misure di sicurezza. L’avvio di una sub-CA ha senso solamente nel caso in cui ci si attenda di servire un vasto bacino di utenti omogenei tra loro.
Poiché non è stato definita nessuna proposta di PKI a livello nazionale o locale, il nostro progetto sperimentale non può appoggiarsi a nessuna struttura già avviata, e l’unica soluzione possibile al fine di testare le funzionalità di PKI è quello di avviare una mini-CA di tipo stand-alone, ossia indipendente (root-CA).
Per garantirci però da possibili sviluppi futuri, predisporremo il nostro progetto all’eventualità che · sia avviato un progetto di PKI Universitario a livello nazionale o locale· sia studiata una forma di integrazione con il sistema delle CA autorizzate dall’AIPA (in un contesto generale, e non universitario) e già operative a livello nazionale
La predisposizione consiste nell’adozione degli standard nazionali e internazionali e nell’implementazione di alcune specifiche di interoperabilità AIPA definite di comune accordo con le CA nazionali già autorizzate: queste specifiche non fanno parte di standard o normative ufficiali, ma sono fortemente raccomandate per garantire l’interoperabilità a livello di semantica dei certificati.
5.2 - GLI STRUMENTI Il progetto si configura, per il suo carattere sperimentale, e per l’assenza di proposte o disposizioni universitarie in merito, come una proposta di carattere dipartimentale. Si cercherà dunque di mostrare il funzionamento di una proposta di PKI a livello dipartimentale, nel suo ciclo di funzionamento completo.
La configurazione sarebbe però del tutto analoga nel caso si volesse implementare una PKI che serva un’intera Facoltà, e subirebbe solo leggere modifiche nel caso fosse necessaria una proposta di ampiezza universitaria.
Avremo bisogno per i nostri scopi di · Una Certification Authority Dipartimentale· Un Client personale per ciascun utente
5.2.1 - Certification Authority Dipartimentale La Certification Authority Dipartimentale è l’entità che rilascia i certificati pubblici per il dipartimento. La sua gestione deve essere strettamente controllata, e l’accesso deve essere consentito solamente al personale di segreteria addetto. Deve essere prestata particolare cura alla protezione della chiave privata, e deve essere implementata su sistemi operativi sicuri quali Unix o Windows NT.
La Certification Authority di cui abbiamo bisogno deve offrire un numero di funzionalità molto limitate dato il carattere sperimentale e il numero ridotto di utenti da servire, la sua struttura risulterà dunque molto semplice. I suoi compiti sono quelli di:
Poiché si è scelto di avviare una root-CA dipartimentale, non c’è nessun altro ente che possa certificarne l’identità, perché questa CA è la massima autorità (anche se solo a livello dipartimentale, per ora).
La CA dunque genera una coppia di chiavi, ed emette un certificato di identità contenente la sua chiave pubblica e i suoi dati identificativi. Questo certificato di chiave pubblica viene firmato con la sua stessa chiave privata. Il certificato si dice allora auto-firmato, e la sua validità non è verificabile con le normali procedure di certificazione: infatti questa è l’origine dell’intera catena di certificazione. I client che vogliono usufruire di questa struttura di certificazione devono poter disporre del certificato della CA tramite un canale sicuro, generalmente questo certificato è fornito assieme al software stesso. Questo è l’unico punto debole della catena, se il certificato della CA è sicuro e non contraffatto, tutte le altre comunicazioni potranno essere verificate con certezza tramite i meccanismi ampiamente esposti.
La CA dipartimentale si occupa di verificare: che l’utente che ha presentato la richiesta sia un professore del dipartimento, o uno studente della facoltà di Ingegneria; che sia regolarmente iscritto, e sia in regola con il pagamento delle tasse universitarie. Queste verifiche sono responsabilità della segreteria studenti che amministra la CA dipartimentale. Le informazioni sottoposte a certificazione vanno verificate secondo controlli incrociati per garantirne la veridicità. Le richieste sono presentate dal client in formato PKCS #10, e devono contenere · La chiave pubblica dello studente· I dati identificativi dello studente
3) Emissione di Certificati di Chiave Pubblica Se i requisiti sono rispettati la CA provvederà ad emettere un certificato contenente
· Chiave pubblica dello studente o professore: la lunghezza minima, come definito nel contesto normativo, è di 1024 bit· Nome, Cognome, Codice Fiscale, Numero di matricola e ruolo nella struttura universitaria, codificati nel campo Common Name (CN) secondo le proposte avanzate nel documento AIPA per l’interoperabilità:Esempio:
CN= Bruno/ Coletta/ CLTBRN73M24H501R/ 09090945/ Studente - Ing. Telecomunicazioni
· Periodo di validità del certificato: durata predefinita di un anno per chiavi di 1024 bit· Attributi per l’uso della chiave per operazioni di cifratura, firma digitale, posta sicura.
5.2.2 - CLIENT PERSONALE Il client è l’applicativo che mette a disposizione di studenti e professori i servizi offerti dalla PKI implementata. Le sue funzioni principali sono:
5.3 - Vantaggi e limiti della proposta L’implementazione di una Public Key Infrastructure consente una notevole semplificazione delle procedure di gestione:
· L’attività di sportello, che oggi verte principalmente sul rilascio di documenti cartacei, verrebbe notevolmente semplificata;· La gestione delle procedure che necessitano dell’interazione con database esterni, ad esempio quelli della Pubblica Amministrazione, sarebbe automatizzata;· L’archiviazione elettronica dei documenti garantirebbe una maggior sicurezza ed una più facile reperibilità delle informazioni.
I principali limiti di questa proposta sono la semplice conseguenza del suo carattere innovativo:
|
