PKI.

Slides:



Advertisements
Presentazioni simili
La firma digitale Cover presentazione
Advertisements

Autenticazione ed uso dei certificati: realizzazione di una semplice certification Authority Luca Bechelli Security Consultant
EGEE-II INFSO-RI Enabling Grids for E-sciencE EGEE and gLite are registered trademarks Sicurezza in EGEE Vincenzo Ciaschini Roma.
Certification Authority
Microsoft Visual Basic MVP
Certification Authority
Configuring Network Access
Public Key Infrastructure
Safe.dschola.it Attenti alle sovrapposizioni! Procedure Reali Procedure Qualità Procedure Privacy Le politiche per la privacy e la sicurezza non si risolvono.
La sicurezza nelle Griglie
SISL – GE.CO. 2 Presentazione del servizio (1) Il sistema consente alle aziende e ai loro intermediari, tramite lutilizzo della firma digitale, di ottemperare.
Seminario CNIPA – Roma 10 febbraio 2005 La Carta Nazionale dei Servizi ed il T-government – G. Manca La CNS: applicabilità, requisiti tecnici, aspetti.
L’uso dei database in azienda
Firma elettronica Concetti e meccanismi
Posta elettronica ( ) chiocciola" comunemente letta at Identificativo dellutente Identificativo del computer centrale sul quale risiede.
Documento informatico Ingegneria Informatica 31 marzo 2006 Prof. Pieremilio Sammarco.
Parma, 20 marzo 2003 Francesco Schinaia Firma Digitale e strumenti di accesso ai servizi
17/12/02 1 Direzione Sviluppo Servizi su rete, Banche dati IRIDE Infrastruttura di Registrazione e IDEntificazione.
Certification Authority Fase I : Setup e Configurazione Componenti del gruppo : Marino Pasquale Marra Maria Cristina Molaro Alfonso Rullo Esterino.
1 Novità sul protocollo TLS. Seminario di : Calabrese Luca - estensione per il Wireless. - IC.
La nuova funzionalità Ammortizzatori in deroga verrà attivata a tutti i soggetti indicati dallente (siano essi già presenti in web forma – progettisti,
1 Titolo Presentazione / Data / Confidenziale / Elaborazione di... ASP. Net Web Part e controlli di login Elaborazione di Franco Grivet Chin.
Modulo 7 – reti informatiche u.d. 2 (syllabus – )
INTRODUZIONE l sistema operativo è il primo software che lutente utilizza quando accende il computer; 1)Viene caricato nella memoria RAM con loperazione.
SmartCard per la Firma Digitale Progetto Firma&Clic Schema Attività della Registration Authority COMUNE DI PAVIA.
“ Firma Digitale “ Informatica e Teleradiologia
Il Comune di Pavia è tra i pochi comuni italiani a svolgere direttamente funzioni di Registration Authority.
“La firma elettronica per Pavia Digitale”
FIRMA DIGITALE, AUTENTICAZIONE E GESTIONE DEL DOCUMENTO ELETTRONICO
This information is confidential and is intended for the use for which has been produced; any other use is not permitted without the authors prior written.
Un problema importante
SERVER DI POSTA ELETTRONICA INTRANET
Configurazione di una rete Windows
Il processo per generare una Firma Digitale
Registrazione alle istanze on-line
Carta Regionale dei Servizi
Analisi e sperimentazione di una Certification Authority
UNIVERSITÀ DEGLI STUDI DI PAVIA Anno accademico 2009/2010 Sicurezza e frodi informatiche in Internet: la Firma Digitale come garanzia di autenticità e.
MCSA Mobile Code System Architecture Infrastruttura a supporto della code mobility Pierfrancesco Felicioni Reti di Calcolatori L.S. 2005/2006.
L’esperienza della Regione Lazio - GOVERNMENT Ing. Vincenzo Bianchini Amministratore Unico Laziomatica.
LECCE – 18/09/2008 Interoperabilità Europea, G. Manca Interoperabilità europea e italiana dei servizi di firma elettronica e conservazione digitale dei.
PKI e loro implementazione Corso di Sisitemi Informativi Teledidattico A.A. 2006/07
Basi di dati e Relazioni Uno schema di relazione R(X) è costituito da un simbolo (nome della relazione) R e da una serie di attributi X={A 1, A 2, …, A.
Lucia Melotti 1/14 Bologna, 7 luglio 2004 Aspetti di sicurezza nello scambio di messaggi XML tra un partner ebXML ed un Web Service di Lucia Melotti Relatore:
Bonjour Post-It servizio di post-it distribuito di Elisa Rondini.
Reti di calcolatori LS1 Service Middleware Reti di calcolatori LS progetto di Andrea Belardi Infrastruttura dedicata alla gestione di servizi disponibili.
Servizi Internet Claudia Raibulet
Universita` degli studi di Perugia Corso di Laurea in Matematica Attribute Certificate Valentina Hamam Rosa Leccisotti.
1 Certificati a chiave pubblica strutture dati che legano una chiave pubblica ad alcuni attributi di una persona sono firmati elettronicamente dall’ente.
Tecnologie di Sicurezza in Internet APPLICAZIONI Public Key Infrastructures AA Ingegneria Informatica e dell’Automazione.
UNITA’ 04 Uso Sicuro del Web.
Il documento informatico e la gestione flussi documentali nelle pubbliche amministrazioni italiane: scenario di riferimento ed aspetti tecnici Antonio.
COS’E’ L’ARCHIVIAZIONE SOSTITUTIVA
Agenda – Parte II La creazione del documento informatico e la firma digitale La classificazione del documento e il protocollo informatico La trasmissione.
La firma digitale. Che cosa é la firma digitale? La firma digitale è una informazione aggiunta ad un documento informatico al fine di garantirne integrità.
1 Prof. Stefano Bistarelli Dipartimento di Scienze e-government: oggi.
Postecom B.U. CA e Sicurezza Offerta Sicurezza Scenario di servizi ed integrazioni di “Certificazione”
Le basi di dati.
Padova, 17 novembre
Repository fornitori Genova, Il repository fornitori è: ▪un archivio autocertificazioni e certificazioni enti (ex art. 38, D.Lgs. 163/2006),
Firma Digitale e Certificatori Giovanni Manca Ufficio Standard, architetture e metologie
Applicazione Presentazione Sessione Trasporto Rete Data link Fisico OSI Processo / Applicazione Trasporto Rete- Internet Interfaccia di.
PPT- Postecert PEC – 05/2009 Postecert Posta Elettronica Certificata.
“Virtual Organisation” in un contesto di Federazioni di Identità Workshop congiunto INFN CCR - GARR 2012 Napoli, Istituto.
La Carta Regionale dei Servizi e i suoi molteplici usi, dalla Sanità ai Servizi degli Enti Locali.
La Carta Nazionale dei Servizi è un documento informatico, rilasciato dalla Pubblica Amministrazione, che permette l’identificazione in rete del titolare.
Barbara Gramolotti Ufficio S.I.T. – Settore Urbanistica, Comune di Novi Ligure Progetto Mude Piemonte: notifica preliminare di cantiere ex art. 99 DLGS.
Risultati Leapfrog IP per una comunicazione sicura e affidabile Cristiano Novelli ENEA, XML-Lab.
Cenni di Crittografia Luigi Vetrano TechnoLabs S.p.A. L’Aquila, Aprile 2011.
Procedure per la richiesta di certificazione e per l'autenticazione alla VO Cometa Accesso all’infrastruttura del Consorzio COMETA in modalità GRID.
Transcript della presentazione:

PKI

Firma digitale ed elettronica La firma digitale esprime un atto volontario di sottoscrizione e, sotto il profilo tecnico organizzativo, deve essere basata su un certificato qualificato (quindi rilasciato da una trusted part detta Certification Authority che, per quanto previsto dalla vigente legislazione nazionale deve essere iscritta nell’elenco pubblico dei certificatori) e creata mediante un dispositivo di firma sicuro (in genere una smart card). La direttiva europea e la nascita del commercio elettronico, hanno introdotto altri tipi di firma applicabili in contesti diversi da quello di un documento, come per esempio quello dei messaggi di posta elettronica: in questo caso si parla di firma elettronica.

Rete di Fiducia Validità della firma: Esiste una rete di fiducia (meccanismo utilizzato in PGP) Vi è una infrastruttura gerarchica di certificazione, o Public Key Infrastructure (PKI) Il primo approccio prevede che ogni utente si preoccupi di notificare la propria chiave pubblica alle persone con le quali ha necessità di scambiare informazioni in modo sicuro. Lo scopo della PKI è invece quello creare e mantenere un ambiente affidabile per la diffusione delle chiavi pubbliche, così da legare in modo sicuro la chiave pubblica con il possessore, con la caratteristica fondamentale della trasparenza rispetto all’utente.

PKI-principi L’idea di fondo è che nulla impedisce che un certificato possa a sua volta essere firmato. È necessario, innanzi tutto, un soggetto che si occupi della pubblicazione dei certificati: è evidente che questo soggetto debba essere una terza parte. Non è proponibile l’idea di delegare all’ente preposto alla pubblicazione dei certificati il compito di identificare il soggetto (dovrebbe avere una presenza capillare che non giustificherebbe i costi di gestione)

Componenti di una PKI End Users Certification Authorities Registration Authorities Certificate Directories Root CA(s) Certification Practice Statements (CPS) Certificate Management Protocols & APIs Personal Security Environments (PSE)

Componenti certificati: in cui si attesti che l’utente è effettivamente il possessore di quella chiave pubblica Una Autorità di Certificazione (CA Certification Autority) che attesta questa affermazione. L’uso di una CA evita ad ogni utente di verificare direttamente la correttezza delle chiavi pubbliche degli altri utenti con cui interagisce. La CA è la terza parte fidata del modello generale per la sicurezza di rete.

Divisione dei compiti Ci si orienta verso una divisione dei compiti: Chi verifica l’identità del soggetto (la Registration Authority o RA), con una struttura che possa anche fornire una capillare assistenza agli utenti Chi emette e pubblica il certificato (la Certification Authority o CA), che è sostanzialmente un’entità centralizzata che deve invece garantire standard tecnici e di sicurezza di massima qualità

Requisiti di una CA il garantire la massima disponibilità delle informazioni: il sistema deve essere quanto più possibile fault-tolerant; il garantire la massima sicurezza: nessuno deve accedere a risorse cui non è autorizzato ad accedere (questo punto e il precedente sono inglobati nel piano di sicurezza della CA); la necessità di formulare una politica di certificazione, ossia un insieme di regole che indichino il campo di applicabilità di ogni certificato (non tutti i certificati vengono rilasciati per tutti gli scopi); l’obbligo di pubblicare un corretto ed esaustivo manuale operativo, che descriva esattamente tutte le procedure relative alla gestione dei certificati stessi; Una CA deve garantire la massima interoperabilità con tutti i possibili client, il che implica automaticamente che la CA deve essere sempre costantemente aggiornata sulle ultime tecnologie in fatto di certificazione. Tale struttura è molto più orientata, per motivi di sicurezza, al concetto di centralità rispetto che a quello di capillarità.

Una CA è realmente quello che sostiene di essere !!! La procedura di certificazione è iterabile. CA può essere certificata o da un organismo pubblico preposto a questo compito (che sarà a sua volta una CA) o da un’altra CA di livello superiore che sia legalmente abilitata a certificare la CA in questione Pertanto, il certificato della CA (che dovrà essere reso pubblico) risulta a sua volta firmato da un’altra CA. A monte di tutto ciò ci sarà una CA che non sarà certificata da nessun’altra: tale CA, che sarà ovviamente la CA pubblica per eccellenza, disporrà di un certificato “self-signed”.

CA Root CA

CA radice In Italia tale ruolo è ricoperto dall’Autorità per l’Informatica nella Pubblica Amministrazione (AIPA). Il certificato a monte di ogni catena di certificazione prende il nome di certificato radice (root certificate) e, analogamente, la CA a monte di ogni catena prende il nome di CA radice (o root CA);

Operazioni basilari sui certificati registrazione: è il processo preliminare mediante il quale un soggetto si notifica presso una RA (o, dove non prevista, direttamente presso la CA); inizializzazione: è il momento in cui l’utente o il client ottengono i valori necessari per iniziare le comunicazioni con l’infrastruttura PKI (generalmente mediante uno scambio Diffie-Hellman[1]); certificazione: è il processo mediante il quale la CA rilascia un certificato per la chiave pubblica del soggetto; aggiornamento: è così definita l’obbligatoria generazione di una nuova coppia di chiavi una volta scaduta la precedente (ogni certificato ha, infatti, un proprio periodo di validità);

Operazioni basilari sui certificati verifica di un certificato: l’operazione mediante la quale chi riceve il certificato verifica la firma digitale appostavi dall’ente certificatore, realizzata recuperando il certificato del certificatore e verificandolo a sua volta, fino a giungere alla root CA (che, come già detto, ha il certificato preinstallato in macchina). Si noti che, per motivi di efficienza, talvolta si usa allegare in una firma digitale non solo il certificato utente, ma anche quello della CA che lo ha firmato… revoca di un certificato: l’operazione mediante la quale un certificato viene annullato, o per scadenza o perché venuti a mancare i presupposti per la sua validità (manomissione, cambio di identità giuridica del soggetto, ecc.).

Revoca Dovendo la CA garantire la verificabilità delle firme antecedenti la revoca anche in tempi successivi alla revoca stessa. La CA dovrà suddividere i certificati in due liste: quella dei certificati attivi quella dei certificati revocati (la Certificate Revocation List o CRL).

Interazione CA Certificate Repository (X.500, DNS, etc.) signed message CA Certificate Repository (X.500, DNS, etc.) name, public-key certificate query

Protocolli

Revoca Chi deve essere autorizzato a richiedere la revoca di un certificato: per i privati cittadini: è il titolare stesso del certificato che detiene la facoltà di richiederne la revoca eventualmente l’anagrafe, in caso di decesso Nel caso di società: ????? Ci sarà un ritardo tra la decisione di revoca e l’effettiva verificabilità della operazione stessa !!!!!! E’ questo uno dei problemi ancora irrisolti della Firma digitale.

Certificate Verification To verify a certificate: You need the issuer’s certificate and CRL: Name: Anish Bhimani Issuer: SAIC Serial: 0x0AF Key: a4653d73b95483jh Issuer’s Signature: F54673HGMABS8496FH3J Name: SAIC Issuer: California Dept. of Commerce CA Serial: 0x016a7f Key: b47326fh482faiwn83j523 Issuer’s Signature: F63GHDJ28F7CHL238CXN3DJ Name: SAIC Issuer’s Signature: F63GHDJ28F7CHL238CXN3DJ Revoked Certs: 0x0A3 (2/7/97), 0x087, (11/2/96)

Protocolli LDAP: certificate retrieval PKCS #10: certification requests S/MIME CRS: certification request syntax Cisco CMS: Certificate Management Syntax IETF CMP: Certificate Management Protocol (Entrust-based)

Lo standard Lo standard per i certificati attualmente utilizzato è l’ITU-T X.509 versione 3. Esso definisce le informazioni di base che devono essere contenute in un certificato ed un regola di codifica con cui trasformare questo oggetto in una sequenza di byte da trasmettere in rete

Certificato X.509 Certificate ::= SIGNED { SEQUENCE { version [0] Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONALV2, subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONALV2, extensions [3] Extensions OPTIONALV3} NOTA: V2 = da versione 2 in poi, V3 = da versione 3 in poi

Semplice certificato

Definizione dei campi Certificate Serial Number: identificatore univoco (tra tutti quelli emessi dalla CA) del certificato. Validity Period: coppia di date che determina la validità del certificato (data di inizio e di fine). Subject: l’intestatario del certificato e le informazioni ad esso relative (ad esempio per un utente umano potrebbero essere nome, cognome, indirizzo, data di nascita, ecc., per un utente server Web l’indirizzo IP).

Definizione dei campi Subject Public Key Information: è l’informazione vera e propria che viene certificata. Questa informazione comprende la chiave pubblica dell’utente e l’algoritmo a cui essa è applicabile. Issuer: nome della CA che ha emesso il certificato. CA’s Digital Signature: la firma digitale dell’intero certificato. Questa è calcolata su tutti gli altri campi del certificato.

Definizione dei campi extension, novità introdotta nella v3 di X.509, contiene le possibili estensioni del certificato, che, data la loro importanza, meritano un approfondimento a parte. Le estensioni sono così definite: Extension ::= SEQUENCE { extnId EXTENSION.&id ({ExtensionSet}), critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING }

Estensioni Le estensioni sono campi aggiuntivi al certificato non sempre previsti dallo standard. Non vengono inserite in un ordine specifico e quindi, dispongono di un identificatore che consenta, in caso di estensione non nota al programma che riceve il certificato, di ignorarla e passare oltre. Fondamentale, in questo caso, diventa però il flag critical: con tale flag settato l’intero certificato dovrà essere considerato non valido se l’applicazione non è in grado di gestire l’estensione in questione (cosa che non avverrebbe, invece, col flag impostato a false).

Classi di estensioni key and policy information extensions, che contengono informazioni sullo scopo per il quale la chiave o il certificato possono essere usati

subject and issuer information extensions, che consentono di definire nomi alternativi (alias) per subject e issuer del certificato, oltre ad alcuni attributi aggiuntivi; certification path constraints extensions, che contengono informazioni sul percorso di certificazione del certificato stesso e, in particolare, se il titolare del certificato è una CA in quest’ultimo caso, possono essere specificati i vincoli imposti a nome e policy dei certificati rilasciati (ad esempio si può stabilire che il subject di tutti i certificati rilasciati da ABC cominci con “ABC Certificate no. ”).

CRL X.509 definisce anche tutta una serie di strutture accessorie ai certificati. Tra queste vanno citate: la CRL (Certificate Revocation List – o, più precisamente, la Certificate List, di cui la CRL è una specializzazione –È una lista di numeri di serie di certificati e delle relative date di revoca), l’AttributeCertificate (la cui definizione ricorda quella di un certificato normale, ma il cui corpo è costituito da una lista di attributi il cui funzionamento ricalca quello delle estensioni, delle quali il certificato di attributo è comunque corredato).

La PKI stabilisce anche molti altri aspetti, tra i quali è fondamentale la revoca dei certificati (quando un certificato viene invalidato prima della sua data di scadenza, bisogna stabilire dei meccanismi con cui avvertire tutti quelli che potrebbero riceverlo ed erroneamente assumerlo come valido).

Certificati per l’autorizzazione In tal caso il certificato viene indicato come Privilege Attribute Certificate (PAC), e le differenze dal certificato X.509v3 standard sono: Subject: questo campo indica l’utente che sta ricoprendo il ruolo rappresentato dal PAC. Esso quindi memorizza un riferimento al certificato dell’utente. Attributes List: insieme di coppie attributo – valore, che rappresentano le credenziali/privilegi che il ruolo è autorizzato a ricoprire.