Tutorials

9. Distribuzione di Chiavi Pubbliche

Le chiavi pubbliche, a differenza delle chiavi private, non necessitano di riservatezza, ma la loro distribuzione deve comunque garantirne l'autenticazione e l'integrità. - Autenticazione: Deve essere

Le chiavi pubbliche, a differenza delle chiavi private, non necessitano di riservatezza, ma la loro distribuzione deve comunque garantirne l'autenticazione e l'integrità.

  • Autenticazione: Deve essere certa l'identità del proprietario della chiave pubblica.
  • Integrità: Deve essere possibile identificare qualsiasi modifica alla chiave.

Vedremo due schemi principali che garantiscono queste caratteristiche:

1. Distribuzione tramite Public Key Authority (Autorità a Chiave Pubblica) 2. Distribuzione tramite Public Key Certificates (Certificati a Chiave Pubblica)

1. Distribuzione Tramite Public Key Authority

Questo schema prevede un'autorità centrale fidata che mantiene un elenco delle chiavi pubbliche di tutti gli aderenti al sistema.

Funzionamento:

Quando un utente richiede una chiave pubblica, l'autorità la cifra utilizzando la propria chiave privata. Questo garantisce sia l'integrità (la chiave non è stata alterata) che l'autenticazione (la chiave proviene effettivamente dall'autorità).

  • Requisito: I richiedenti devono conoscere la chiave pubblica dell'autorità e devono averla ottenuta in una forma sicura (_out-of-band_, ad esempio inclusa in un pacchetto software fidato).

Scenario di Scambio Chiavi con Public Key Authority:

Supponiamo che Alice (A) e Bob (B) vogliano scambiarsi le chiavi pubbliche tramite un'autorità centrale (Auth):

1. Alice richiede la chiave pubblica di Bob: A invia una richiesta ad Auth per la chiave pubblica di B, allegando un timestamp per prevenire attacchi di replay. 2. Auth risponde ad Alice: Auth invia la chiave pubblica di B, concatenata con una copia della richiesta originale di A e il timestamp, il tutto cifrato con la chiave privata di Auth. 3. Alice contatta Bob: A comunica a B la sua volontà di scambiare chiavi. Invia un messaggio con la propria identità e un nonce (N1​), cifrando il tutto con la chiave pubblica di B (precedentemente ricevuta da Auth). Questo passaggio serve a dimostrare ad A che B possiede la chiave privata corrispondente alla chiave pubblica ricevuta da Auth. 4. Bob richiede la chiave pubblica di Alice: B, analogamente ad A, invia una richiesta ad Auth per la chiave pubblica di A, allegando un timestamp. 5. Auth risponde a Bob: Auth invia la chiave pubblica di A, concatenata con la richiesta originale di B e il timestamp, il tutto cifrato con la chiave privata di Auth. 6. Bob risponde ad Alice: B invia un messaggio ad A inserendo il nonce N1​ precedentemente ricevuto da A e accodandone uno nuovo N2​. Il messaggio è cifrato con la chiave pubblica di A. Questo verifica l'identità di B ad A e viceversa. 7. Alice conferma a Bob: A invia il nonce N2​ a B, cifrandolo con la chiave pubblica di B.

Resilienza a Compromissione dell'Autorità:

L'algoritmo è composto da 7 passi per garantire la sicurezza anche in caso di compromissione dell'autorità. Se un attaccante riesce a compromettere l'autorità e modificare le chiavi pubbliche conservate, l'algoritmo non si chiude correttamente e la compromissione viene facilmente rilevata.

Ottimizzazioni:

  • I passi 1-5 non devono essere eseguiti tutte le volte. Alice e Bob possono fare caching delle chiavi pubbliche e aggiornarle periodicamente.
  • I passi 3, 6, 7 devono sempre essere eseguiti prima di iniziare una comunicazione per essere certi dell'integrità delle chiavi pubbliche presenti in cache.

Criticità dell'Autorità Centrale:

L'utilizzo di un'autorità centrale presenta due criticità principali:

  • Scalabilità: Non scala facilmente all'aumentare del numero di chiavi gestite (memorizzate e/o richieste). Potrebbe diventare un collo di bottiglia del sistema.
  • Single Point of Failure: La compromissione dell'autorità porta alla compromissione di tutte le chiavi pubbliche da essa gestite.

2. Distribuzione Tramite Public Key Certificates

Un approccio alternativo e più scalabile è l'utilizzo di certificati digitali. Questi permettono lo scambio di chiavi pubbliche senza la necessità di contattare autorità centrali ad ogni richiesta, pur mantenendo un alto livello di sicurezza.

Concetto di Certificato Digitale:

Un certificato digitale garantisce l'autenticità e l'integrità della chiave pubblica in esso contenuta. Un certificato contiene molte informazioni, tra le quali le più importanti sono:

  • Una chiave pubblica.
  • Le informazioni identificative del proprietario della chiave pubblica.
  • Una firma digitale dell'intero contenuto, effettuata da una terza parte considerata affidabile (una Certificate Authority - CA).

Ruolo della Certificate Authority (CA):

  • La CA è coinvolta solamente in fase di emissione dei certificati, non in ogni scambio di chiavi. Questo la rende non un collo di bottiglia.
  • Possono esistere più CA che si dividono il compito di emettere certificati, aumentando la decentralizzazione e la resilienza.
  • Una volta emessi, i certificati sono scambiati direttamente dalle parti senza ricorrere a soggetti terzi.
  • Anche in questo caso, è necessaria la conoscenza della chiave pubblica della CA, che deve essere ottenuta in modo sicuro (_out-of-band_).

Gestione della Fiducia (Trust Chain):

Quando un ricevente ottiene un certificato con una chiave pubblica, può trovarsi in diverse situazioni:

1. CA Fidata e Nota: Il ricevente considera affidabile la CA firmataria e già possiede la relativa chiave pubblica. Può quindi verificare l'integrità del certificato ed estrarre la chiave in esso contenuta. 2. CA Non Fidata: Il ricevente non considera affidabile la CA firmataria. La chiave ricevuta viene scartata. 3. CA Sconosciuta: Il ricevente non conosce la CA firmataria e non ne possiede la chiave pubblica. Il ricevente richiede alla CA firmataria il suo certificato e ripete il processo di verifica su quella CA. Questo può portare alla creazione di una catena di certificati fidati.

La relazione tra le CA deve essere reciproca (mutual trust) per garantire la piena interoperabilità del sistema.

Esempio di Catena di Certificati:

Supponiamo una catena di fiducia: Bob → CA3 → CA1 → CA2, dove Alice si fida di CA2. Se Alice necessita della chiave pubblica di Bob:

1. Richiede il certificato a Bob. 2. Non conosce CA3, quindi richiede il certificato di CA1 (il firmatario di CA3). 3. Non conosce CA1, quindi richiede i suoi certificati, tra i quali ne trova uno firmato da CA2, di cui Alice si fida. Si genera quindi una catena di certificati fidati fino a una "root CA" fidata (CA2 per Alice). La stessa procedura si applica se Bob richiede la chiave di Alice.

3. Certificati X.509

X.509 (versione 3) è uno standard ampiamente adottato per la rappresentazione e gestione dei certificati digitali. Definisce la struttura e il contenuto dei certificati, includendo:

  • Informazioni identificative del proprietario della chiave pubblica.
  • Informazioni identificative della CA.
  • Algoritmo di firma usato per firmare il certificato (es. RSA + SHA-256).
  • Modalità di revoca di un certificato.

Il formato risale al 1993, con la versione 3 rilasciata nel 1995 e revisionata nel 2000.

Campi Principali di un Certificato X.509:

Un certificato è identificato da:

  • Version: Indica la versione dello standard (1, 2 o 3).
  • Serial Number: Un numero univoco assegnato dalla CA al certificato.
  • Signature Algorithm: Specifica l'algoritmo di firma utilizzato (e i relativi parametri).
  • Period of Validity: Date di inizio e fine validità del certificato (Not Before, Not After).

La CA firmataria è identificata dai campi:

  • Issuer Name: Nome della CA.
  • Issuer Unique ID (opzionale): Identificatore univoco della CA (usato se l'Issuer Name è stato riutilizzato).

Il soggetto per cui è emesso il certificato è identificato da:

  • Subject Name: Nome del soggetto.
  • Subject Unique ID (opzionale): Identificatore univoco del soggetto (usato se il Subject Name è stato riutilizzato).

La sezione Public Key contiene:

  • L'algoritmo crittografico a cui la chiave fa riferimento.
  • Eventuali parametri.
  • La chiave pubblica stessa.

La sezione Signature contiene:

  • L'algoritmo di firma.
  • Eventuali parametri.
  • L'hash dell'intero contenuto del certificato, cifrato con la chiave privata della CA.

La sezione Extension (introdotta con la versione 3) contiene campi aggiuntivi che specificano categorie di informazioni aggiuntive:

  • Authority Key Identifier (AKID): Identificatore numerico del certificato contenente la chiave pubblica della CA.
  • Subject Key Identifier (SKID): Identificatore numerico del certificato e della chiave pubblica in esso contenuta.
  • Key Usage: Indica gli utilizzi consentiti della chiave pubblica (es. digitalSignature, keyEncipherment, keyAgreement).
  • Private Key Usage Period: Indica il periodo di validità della chiave privata corrispondente alla chiave pubblica nel certificato.
  • Certificate Policies: Indica le policy a cui il certificato aderisce.
  • Policy Mapping: Usato per i certificati di CA emessi da altre CA, per mappare l'equivalenza delle policy.
  • Subject Alternative Name (SAN): (Opzionale) Indica i nomi di dominio alternativi su cui il certificato può essere utilizzato (es. dns:*.wikipedia.org).
  • Extended Key Usage (extKeyUsage): Specifica gli scopi aggiuntivi per cui la chiave può essere usata (es. serverAuth, clientAuth).

Revoca dei Certificati X.509:

I certificati X.509 possono essere revocati (resi non validi) anche se non sono ancora formalmente scaduti (ovvero il loro Not After non è stato raggiunto). Motivi comuni di revoca includono:

  • Compromissione (ipotetica o reale) della chiave privata del soggetto.
  • Modifica dei dati del soggetto (es. cambio nome azienda).
  • Compromissione (ipotetica o reale) della chiave privata della CA stessa.

Ogni CA mantiene un elenco dei certificati da lei emessi e successivamente revocati. Questa lista, firmata dalla CA, contiene i numeri seriali e le date di revoca dei certificati.

4. Certificati e Firma Digitale (Valore Legale)

Affinché una firma digitale possa avere valore legale (in Italia):

  • L'associazione tra chiave pubblica e identità deve essere effettuata da un soggetto autorizzato.
  • La chiave pubblica deve essere contenuta in un certificato firmato da una CA registrata e autorizzata presso AGID (Agenzia per l'Italia Digitale).
  • La generazione, distribuzione e manutenzione delle chiavi deve avvenire seguendo specifiche e requisiti ben precisi.

Esempio da Manuale Operativo "Aruba" (Prestatore di Servizi Fiduciari):

  • Le CA utilizzano certificati self-signed, non firmati da altre CA. La loro diffusione avviene tramite pubblicazione sul sito web della CA, su directory server e sul sito di AGID.
  • Le CA di Aruba utilizzano RSA a 4096 bit.
  • Le chiavi rilasciate dalla CA per gli utenti sono di tipo RSA a 2048 bit, generate con e=65537.
  • La coppia di chiavi dell'utente viene generata sul dispositivo dell'utente stesso. La chiave pubblica viene inviata alla CA sotto forma di Certificate Signing Request (CSR), conforme allo standard PKCS#10.