Che cos'è la PKI?

PKI è l'acronimo di infrastruttura a chiave pubblica, ovvero la tecnologia alla base dei certificati digitali. Un certificato digitale ha uno scopo simile alla patente di guida o al passaporto: è un documento di identità che prova la tua identità e fornisce determinati vantaggi. Un certificato digitale consente al suo proprietario di crittografare, firmare e autenticare. Di conseguenza, PKI è la tecnologia che consente di crittografare i dati, firmare digitalmente i documenti e autenticarsi utilizzando i certificati.

Ci sono una serie di requisiti richiesti dalle aziende per quanto riguarda l'implementazione di infrastrutture a chiave pubblica efficaci. Innanzitutto, se gli utenti non possono trarre vantaggio dalla crittografia e dalle firme digitali nelle applicazioni, una PKI non ha valore. Di conseguenza, il vincolo più importante di una PKI è la trasparenza. Il termine trasparenza significa che gli utenti non sono tenuti a comprendere come la PKI gestisce chiavi e certificati per poter sfruttare i servizi di crittografia e firma digitale. Una PKI efficace è trasparente. Oltre alla trasparenza dell’utente, per fornire la chiave richiesta e i servizi di gestione dei certificati un’azienda deve implementare in una PKI i seguenti elementi:

• Certificati di chiave pubblica
• Un repository di certificati
• Revoca del certificato
• Backup e ripristino delle chiavi
• Supporto per il non ripudio delle firme digitali
• Aggiornamento automatico di coppie di chiavi e certificati
• Gestione delle cronologie delle chiavi
• Supporto per la certificazione incrociata
• Software lato client che interagisce con tutto quanto sopra in modo sicuro, coerente e affidabile

Nota: Il termine "lato client" si riferisce ai client delle applicazioni e ai server delle applicazioni. I requisiti della PKI sono gli stessi sia per i client delle applicazioni che per i server ed sono entrambi "client" dei servizi di infrastruttura.

Anche tutti questi requisiti devono essere soddisfatti per avere una PKI automatica, trasparente e utilizzabile.

Affinché la crittografia a chiave pubblica fornisca un valore, gli utenti devono essere certi che le altre parti con cui comunicano siano “al sicuro”, ovvero che le loro identità e le loro chiavi siano valide e affidabili. Per fornire questa garanzia, tutti gli utenti di una PKI devono disporre di un'identità registrata.

Queste identità vengono archiviate in un formato di certificato di chiave pubblica digitale con standard X.509. Le autorità di certificazione (CA) rappresentano le persone, i processi e gli strumenti per creare certificati digitali che legano in modo sicuro i nomi degli utenti alle loro chiavi pubbliche. Nella creazione dei certificati, le CA agiscono come agenti di fiducia in una PKI. Finché gli utenti si fidano di una CA e delle sue politiche aziendali per l'emissione e la gestione dei certificati, possono fidarsi dei certificati emessi dalla CA. Questo è noto come fiducia di terze parti.

Le CA creano certificati per gli utenti firmando digitalmente un set di dati che include le seguenti informazioni (e elementi aggiuntivi):

1. Il nome dell’utente nel formato di un nome distinto (Distinguished Name, DN). Il DN specifica il nome dell’utente e qualsiasi attributo aggiuntivo richiesto per identificare l’utente in modo univoco (ad esempio, il DN potrebbe contenere il numero di dipendente dell'utente).
2. Una chiave pubblica dell'utente. La chiave pubblica è necessaria affinché altri possano effettuare la crittografia per l'utente o verificare la firma digitale dell'utente.
3. Il periodo di validità (o durata) del certificato (una data di inizio e una data di fine).
4. Le operazioni specifiche per utilizzare la chiave pubblica (sia per crittografare i dati, verificare le firme digitali o entrambi).

La presenza firma della CA su un certificato significa che qualsiasi manomissione del contenuto del certificato sarà facilmente rilevata. La presenza della firma della CA su un certificato si comporta come un sigillo antimanomissione su un flacone di pastiglie: qualsiasi manomissione del contenuto di un certificato viene facilmente rilevata. Finché sarà possibile verificare la firma della CA su un certificato, il certificato avrà integrità. Poiché l’integrità di un certificato può essere determinata verificando la firma della CA, i certificati dispongono di sicurezza intrinseca e possono essere distribuiti in modo completamente pubblico (ad esempio, tramite sistemi di directory accessibili pubblicamente).

Gli utenti che recuperano una chiave pubblica da un certificato possono essere certi che la chiave pubblica è valida. Ovvero, gli utenti possono ritenere che il certificato e la chiave pubblica associata appartengano all'entità specificata dal nome distinto. Gli utenti ritengono inoltre che la chiave pubblica si trovi ancora nel periodo di validità definito. Inoltre, gli utenti hanno la certezza che la chiave pubblica può essere utilizzata in modo sicuro nel modo per cui è stata certificata dalla CA.

La PKI è una parte fondamentale della spina dorsale strategica dell’informatica. La PKI è importante perché la tecnologia basata sui certificati aiuta le organizzazioni a stabilire firme, crittografia e identità affidabili tra persone, sistemi e cose.

Man mano che i modelli aziendali diventano sempre più dipendenti dalle transazioni elettroniche e dai documenti digitali e i sempre più dispositivi compatibili con Internet sono collegati alle reti aziendali, il ruolo di un'infrastruttura a chiave pubblica non è più limitato a sistemi isolati come posta elettronica protetta, smart card per l'accesso fisico o traffico web crittografato. Oggi si prevede che le PKI supportino un numero maggiore di applicazioni, utenti e dispositivi in ecosistemi complessi. E con normative di settore e governative più severe in materia di sicurezza dei dati, i sistemi operativi e le applicazioni aziendali tradizionali stanno diventando più dipendenti che mai da un'infrastruttura PKI aziendale per garantire la fiducia.

Che cos'è il furto dell'autorità di certificazione o della chiave privata di root?

Il furto dell'autorità di certificazione (CA) o delle chiavi private root consente a un utente malintenzionato di assumere il controllo dell'infrastruttura a chiave pubblica (PKI) di un'organizzazione e di emettere certificati falsi, come avvenuto l'attacco Stuxnet. Qualsiasi compromissione di questo tipo può forzare la revoca e la riemissione di alcuni o tutti i certificati precedentemente emessi. Un compromesso di root, come una chiave privata di root rubata, mina la fiducia della tua PKI e può facilmente indurti a ristabilire una nuova infrastruttura di CA di emissione associata e di root. Questo può essere molto costoso oltre a danneggiare l'identità aziendale di un'impresa.

L'integrità delle chiavi private di un'organizzazione, in tutta l'infrastruttura, dal root alle CA di emissione, fornisce la base di fiducia fondamentale della sua PKI e, come tale, deve essere salvaguardata. La migliore pratica riconosciuta per la protezione di queste chiavi critiche consiste nell'utilizzare un modulo di sicurezza hardware (HSM) certificato FIPS 140-2 Livello 3, un dispositivo a prova di manomissione che soddisfa i più elevati standard di sicurezza e garanzia.

PKI e SSL, sebbene differenti, sono entrambe soluzioni basate su certificati che stabiliscono “fiducia” grazie ai certificati emessi da un'autorità di certificazione (CA), che si tratti di fiducia pubblica (SSL) o fiducia privata (PKI).

La PKI è un intero framework composto da hardware, software, politiche e altro. Una PKI include anche una CA, ovvero ciò che emette i certificati digitali per stabilire la fiducia. In genere, tale CA viene governata internamente in base a politiche e procedure in linea con i livelli di sicurezza e garanzia richiesti dall'organizzazione.

L’SSL è uno dei principali casi d’uso di PKI. Comprende anche una CA che emette certificati, ma questa deve essere riconosciuta dai browser come CA pubblicamente attendibile. E sebbene ci siano molti casi d’uso per la PKI, lo scopo dell’SSL è proteggere i dati sensibili trasferiti tramite comunicazioni online, come le operazioni di online banking o e-commerce.

I casi d’uso principali per la PKI possono essere determinati esaminando le applicazioni che utilizzano più comunemente i certificati digitali, come ad esempio:

Casi d'uso tradizionali

Queste applicazioni fondamentali per i criteri commerciali rendono evidente che la PKI è una parte strategica della struttura portante dell'IT.

• Certificati SSL per siti Web e servizi rivolti al pubblico
• Reti private e reti virtuali private (VPN)
• Applicazioni e servizi basati su cloud pubblici
• Applicazioni basate su cloud privati
• Sicurezza della posta elettronica
• Autenticazione utente Enterprise
• Autenticazione del dispositivo
• Autenticazione basata su cloud privata
• Firma di documenti/messaggi
• Firma del codice

(Vedi i dettagli nella tabella sottostante).

Casi d'uso nuovi ed emergenti

Si è assistito anche a una rinascita della PKI da parte di casi d'uso legati a DevOps che ne stanno determinando una maggiore adozione, come ad esempio:

• Servizi basati su cloud
• Consumatore mobile
• Internet of Thing (IoT)
• Applicazioni mobili orientate al consumatore
• Criteri Dispositivo personale (Bring-Your-Own-Device, BYOD) e gestione dei dispositivi mobili interni
• e-commerce

(Vedi i dettagli nella tabella sottostante).

E alcuni esperti prevedono casi d'uso futuri man mano che la tecnologia e l'intelligenza artificiale diventeranno ancora più avanzate.

La differenza tra le chiavi private e pubbliche è che una viene utilizzata per crittografare, mentre l’altra viene utilizzata per decrittare.

Una chiave pubblica viene utilizzata per crittografare le informazioni, rendendole essenzialmente illeggibili a chiunque non sia il destinatario previsto. Quindi quel destinatario dispone di una chiave privata con cui è poi in grado di decrittare le informazioni.

Inoltre, una chiave pubblica è pubblicamente disponibile per un insieme di utenti che potrebbero aver bisogno di inviare informazioni riservate in modo confidenziale. Ad esempio, la chiave pubblica di qualcuno potrebbe essere disponibile per i colleghi all'interno di un'organizzazione tramite una directory condivisa. Al contrario una chiave privata è accessibile solo dalla persona che riceve le informazioni e quindi l’unica persona in grado di decrittare con successo ciò che è stato crittografato.

Insieme, le chiavi pubbliche e private assicurano che le informazioni, i dati e le comunicazioni vengano crittografati prima di essere trasmessi e decrittati in modo sicuro dalla parte appropriata.

Un'azienda deve essere in grado di recuperare i dati crittografati quando gli utenti perdono le chiavi di decrittografia. Ciò significa che l’azienda di cui l’utente fa parte ha bisogno di un sistema per il backup e il ripristino delle chiavi di decrittazione.

Ci sono due ragioni per cui il backup e il ripristino delle chiavi sono così importanti per le aziende:

1. Gli utenti dimenticano le password. Per un’azienda la perdita dei dati dovuta al fatto che gli utenti perdono le password necessarie per accedere alle proprie chiavi di decrittazione è potenzialmente catastrofica. Informazioni preziose andrebbero perse per sempre se non fosse possibile recuperare in modo sicuro quelle chiavi. Inoltre, a meno che gli utenti non sappiano di poter sempre recuperare i propri dati crittografati (anche se dimenticano le password), alcuni utenti non crittograferebbero le loro informazioni più preziose e sensibili per paura di perderle, anche se quelle informazioni sono quelle che andrebbero maggiormente protette.
2. Gli utenti possono perdere, rompere o danneggiare i dispositivi in cui sono archiviate le loro chiavi di decrittazione. Ad esempio, se le chiavi di decrittazione di un utente sono memorizzate su una scheda magnetica, è possibile che il campo magnetico sulla scheda venga danneggiato. Anche in questo caso, la perdita permanente di quelle chiavi di decrittazione può essere disastrosa. Gli utenti non hanno la facoltà di ripristinare i dati crittografati a meno che non venga eseguito il backup delle loro chiavi di decrittografia.

La differenza tra backup e deposito delle chiavi

I requisiti commerciali per il backup e il ripristino delle chiavi possono essere completamente separati dalle richieste delle forze dell'ordine per il deposito delle chiavi, un argomento ampiamente discusso dai media.

• Deposito delle chiavi significa che una terza parte (come un agente federale) può ottenere le chiavi di decrittografia necessarie per accedere alle informazioni crittografate. Lo scopo del deposito delle chiavi è quello di aiutare con le forze dell'ordine, ed è molto dibattuto a causa della linea sottile tra l'interesse pubblico (come la sicurezza nazionale) e la libertà e la privacy individuali.
• I requisiti di backup e ripristino delle chiavi si concentrano sulle esigenze commerciali fondamentali esistenti, indipendentemente dai requisiti delle forze dell'ordine.

Quali chiavi richiedono il backup?

Le uniche chiavi che richiedono il backup sono le chiavi di decrittografia degli utenti. Finché un agente attendibile (ad esempio, la CA) esegue il backup in modo sicuro delle chiavi di decrittografia degli utenti, la sicurezza non viene compromessa e i dati dell'utente possono sempre essere ripristinati. Tuttavia, la firma delle chiavi ha requisiti diversi da quelli delle chiavi di decrittazione. In effetti, come descritto nella sezione successiva, il backup delle chiavi di firma distrugge uno dei requisiti di base di una PKI.

Ripudio si verifica quando una persona nega l’essere coinvolta in una transazione. Ad esempio, quando qualcuno afferma che una carta di credito è stata rubata, ripudia la responsabilità per le transazioni che si verificano con quella carta in qualsiasi momento dopo aver segnalato il furto.

Non ripudio significa che una persona non può negare con successo il coinvolgimento in una transazione. Nel mondo dei documenti cartacei, la firma di un individuo lo vincola legalmente alle sue transazioni (addebiti sulla carta di credito, contratti commerciali, ecc.). La firma impedisce il ripudio di tali transazioni.

Nel mondo elettronico, il sostituto della firma basata su penna è la firma digitale. Tutti i tipi di e-commerce richiedono firme digitali poiché l'e-commerce rende obsolete le firme tradizionali basate su penna.

La chiave privata di firma

Il requisito fondamentale per il non ripudio è che la chiave utilizzata per creare le firme digitali, ossia la chiave di firma, sia generata e archiviata in modo sicuro sotto l'esclusivo controllo dell'utente in qualsiasi momento. Eseguire il backup della chiave di firma non è accettabile. A differenza delle coppie di chiavi di crittografia, non vi è alcun requisito tecnico o aziendale per eseguire il backup o il ripristino di coppie di chiavi di firma precedenti quando gli utenti dimenticano le password o perdono, rompono o corrompono le chiavi di firma. In questi casi, è accettabile che gli utenti generino nuove coppie di chiavi di firma e continuino a utilizzarle da quel momento in poi.

La necessità di due coppie di chiavi

È complesso supportare contemporaneamente il backup, il ripristino e il non ripudio delle chiavi. Per supportare il backup e il ripristino delle chiavi, è necessario eseguire il backup delle chiavi di decrittografia in modo sicuro. Ma per supportare il non ripudio, le chiavi utilizzate per la firma digitale non possono essere sottoposte a backup e devono essere sempre sotto il controllo esclusivo dell'utente.

Per soddisfare questi requisiti, una PKI deve supportare due coppie di chiavi per ogni utente. Un utente deve sempre disporre di una coppia di chiavi corrente per la crittografia e la decrittografia e una seconda coppia di chiavi per la firma digitale e la verifica della firma. Nel tempo, gli utenti avranno numerose coppie di chiavi che dovranno essere gestite in modo appropriato.

Le coppie di chiavi crittografiche non devono essere utilizzate ad oltranza, ma devono essere aggiornate nel tempo. Di conseguenza, ogni organizzazione deve considerare due questioni importanti:

1. Aggiornamento delle coppie di chiavi degli utenti. Il processo di aggiornamento delle coppie di chiavi dovrebbe essere trasparente per gli utenti. Questa trasparenza significa che gli utenti non devono capire quale aggiornamento delle chiavi deve essere effettuato e non sperimenteranno mai un "Denial of Service" perché le loro chiavi non sono più valide. Per garantire la trasparenza e prevenire il Denial of service, le coppie di chiavi degli utenti devono essere aggiornate automaticamente prima della scadenza.
2. Mantenere, se del caso, la cronologia delle precedenti coppie di chiavi. Quando le coppie di chiavi di crittografia vengono aggiornate, è necessario conservare la cronologia delle chiavi di decrittografia precedenti. Questa “cronologia delle chiavi” consente agli utenti di accedere a qualsiasi chiave di decrittografia precedente per decrittare i dati. (Quando i dati vengono crittografati con la chiave di crittografia di un utente, solo la chiave di decrittografia corrispondente, la chiave accoppiata, può essere utilizzata per la decrittografia). Per garantire la trasparenza, il software lato client deve gestire automaticamente la cronologia delle chiavi di decrittazione degli utenti.

La cronologia delle chiavi deve anche essere gestita in modo sicuro dal sistema di backup e ripristino delle chiavi. Ciò consente il ripristino sicuro dei dati crittografati, indipendentemente dalla chiave pubblica di crittografia utilizzata per crittografare originariamente i dati (e, per estensione, indipendentemente dal momento in cui i dati sono stati crittografati).

Quando una coppia di chiavi di firma viene aggiornata, la chiave di firma precedente deve essere eliminata in modo sicuro. Ciò impedirà a qualsiasi altra persona di accedere alla chiave di firma ed è accettabile poiché non è necessario conservare le chiavi di firma precedenti.

Come accennato in precedenza, la CA agisce come una terza parte fidata, emettendo certificati agli utenti. Le aziende devono inoltre distribuire tali certificati in modo che possano essere utilizzati dalle applicazioni. I repository di certificati archiviano i certificati in modo che le applicazioni possano recuperarli per conto degli utenti.

Il termine “repository” si riferisce a un servizio di rete che consente la distribuzione di certificati. Negli ultimi anni, il settore IT conviene che la migliore tecnologia per i repository di certificati è fornita dai sistemi di directory conformi a LDAP (Lightweight Directory Access Protocol). LDAP definisce il protocollo standard per accedere ai sistemi di directory.

Diversi fattori guidano questa posizione di consenso:

• L’archiviazione dei certificati nelle directory e il recupero dei certificati da parte delle applicazioni per conto degli utenti fornisce la trasparenza necessaria per essere utilizzata nella maggior parte delle aziende
• Molte tecnologie di directory che supportano LDAP possono essere scalate per:
  • supportare un numero molto elevato di voci
  • rispondere in modo efficiente alle richieste di ricerca grazie ai metodi di archiviazione e recupero delle informazioni
  • venir distribuite in tutta la rete per soddisfare anche i requisiti delle organizzazioni più distribuite

Inoltre, le directory che supportano la distribuzione dei certificati possono memorizzare altre informazioni sull'organizzazione. Come discusso nella sezione successiva, la PKI può anche utilizzare la directory per distribuire le informazioni sulla revoca del certificato.

Oltre a verificare la firma della CA su un certificato (come discusso in precedenza in “Quali sono i ruoli dei certificati e delle autorità di certificazione?”), Il software applicativo deve anche essere sicuro che, al momento del suo utilizzo, il certificato sia ancora affidabile. La CA deve revocare i certificati che non sono più affidabili. Esistono numerosi motivi per cui potrebbe essere necessario revocare un certificato prima della fine del suo periodo di validità. Ad esempio, la chiave privata (la chiave di firma o la chiave di decrittografia) corrispondente alla chiave pubblica nel certificato potrebbe essere compromessa. In alternativa, la politica di sicurezza di un'organizzazione può imporre che i certificati dei dipendenti che lasciano l'organizzazione debbano essere revocati.

In queste situazioni, gli utenti del sistema devono essere informati che proseguire con l'uso del certificato non è più considerato sicuro. Prima di ogni utilizzo è necessario verificare lo stato di revoca di un certificato. Di conseguenza, una PKI deve incorporare un sistema di revoca dei certificati scalabile. La CA deve essere in grado di pubblicare le informazioni riguardanti lo stato di ogni certificato nel sistema in modo sicuro. Il software applicativo, per conto degli utenti, deve quindi verificare le informazioni sulla revoca prima di ciascun utilizzo di un certificato.

La combinazione tra pubblicazione e utilizzo coerente delle informazioni sulla revoca dei certificati costituisce un sistema di revoca completo. Il mezzo più diffuso per la distribuzione delle informazioni sulla revoca dei certificati è che la CA crei elenchi di revoche di certificati (CRL) protetti e pubblichi questi CRL in un sistema di directory. I CRL specificano i numeri di serie univoci di tutti i certificati revocati.

Prima di utilizzare un certificato, l'applicazione lato client deve controllare il CRL appropriato per determinare se il certificato è ancora affidabile. Le applicazioni lato client devono verificare la presenza di certificati revocati in modo coerente e trasparente per conto degli utenti.

La certificazione incrociata estende le relazioni di fiducia di terze parti tra i domini dell'Autorità di certificazione. Ad esempio, due partner commerciali, ciascuno con la propria CA, potrebbero voler convalidare i certificati emessi dalla CA dell'altro partner. In alternativa, una grande organizzazione distribuita può richiedere più CA in diverse aree geografiche. La certificazione incrociata consente a diversi domini CA di stabilire e mantenere relazioni elettroniche affidabili.

Il termine certificazione incrociata si riferisce a due operazioni:

1. Stabilire una relazione di fiducia tra due CA (eseguita raramente). In caso di certificazione incrociata bilaterale, due CA si scambiano in modo sicuro le proprie chiavi di verifica. Queste sono le chiavi utilizzate per verificare le firme delle CA sui certificati. Per completare l'operazione, ciascuna CA firma la chiave di verifica dell'altra CA in un certificato denominato "certificato incrociato".
2. Verificare l'affidabilità di un certificato utente firmato da una CA con certificazione incrociata (eseguito frequentemente). Si tratta di questo. L’operazione, eseguita dal software lato client, viene spesso definita “camminare su di una catena di fiducia". La “catena” si riferisce a un elenco di convalide di certificati incrociati che vengono “percorse” (o tracciate) dalla chiave CA dell’utente, la quale esegue la verifica alla chiave CA richiesta per convalidare il certificato dell'altro utente. Quando una catena di certificati incrociati viene percorsa, si deve controllare ogni certificato incrociato per assicurarsi che sia ancora attendibile. I certificati utente devono poter essere revocati e lo stesso vale per i certificati incrociati. Questo requisito viene spesso trascurato nelle discussioni sulla certificazione incrociata.

Quando si discutono i requisiti per le PKI, le aziende spesso trascurano i requisiti per il software lato client. (Ad esempio, molte persone si concentrano solo sul componente CA quando discutono di PKI). In definitiva, tuttavia, il valore di una PKI è legato alla capacità degli utenti di utilizzare la crittografia e le firme digitali. Per questo motivo, la PKI deve includere un software lato client che operi in modo coerente e trasparente tra le applicazioni sul desktop (e-mail, navigazione Web, moduli elettronici, crittografia di file/cartelle, ecc.).

Un’implementazione PKI coerente e di facile utilizzo all’interno del software lato client riduce i costi operativi della PKI. Inoltre, il software lato client deve essere tecnologicamente abilitato per supportare tutti gli elementi di una PKI. Il seguente elenco riassume i requisiti che il software lato client deve soddisfare per garantire che gli utenti di un’azienda ottengano un’infrastruttura PKI utilizzabile e trasparente (e, di conseguenza, accettabile).

• Certificati di chiave pubblica Per garantire la fiducia di terze parti, tutte le applicazioni abilitate per la PKI devono utilizzare i certificati in modo coerente e affidabile. Il software lato client deve convalidare la firma della CA sui certificati e assicurarsi che i certificati rientrino nel periodo di validità.
• Backup e ripristino delle chiavi Per garantire che gli utenti siano protetti dalla perdita di dati, la PKI deve supportare un sistema per il backup e il ripristino delle chiavi di decrittografia. Per quanto riguarda i costi amministrativi, è inaccettabile che ciascuna applicazione provveda al proprio backup e ripristino della chiave. Al contrario, tutte le applicazioni client abilitate per la PKI dovrebbero interagire con un unico sistema di backup e ripristino della chiave. Le interazioni tra il software lato client e il sistema di backup e ripristino della chiave devono essere sicure e il metodo di interazione deve essere coerente in tutte le applicazioni abilitate per la PKI.
• Supporto per il non ripudio Per fornire supporto di base per il non ripudio, è il software lato client a dover generare le coppie di chiavi utilizzate per la firma digitale. Inoltre, il software lato client deve garantire che le chiavi di firma non vengano mai sottoposte a backup e rimangano sempre sotto il controllo degli utenti. Questo tipo di supporto deve essere coerente in tutte le applicazioni abilitate per la PKI.
• Aggiornamento automatico delle coppie di chiavi Per consentire la trasparenza, le applicazioni lato client devono avviare automaticamente l'aggiornamento delle coppie di chiavi degli utenti. Ciò deve essere fatto in conformità con le politiche di sicurezza dell'organizzazione. Non è accettabile che gli utenti debbano sapere che le loro coppie di chiavi richiedono un aggiornamento. Per soddisfare questo requisito in tutte le applicazioni abilitate per la PKI, il software lato client deve aggiornare le coppie di chiavi in modo trasparente e coerente.
• Gestione delle cronologie delle chiavi Per consentire agli utenti di accedere facilmente a tutti i dati crittografati per loro (indipendentemente da quando sono stati crittografati), le applicazioni abilitate per PKI devono avere accesso alle cronologie delle chiavi degli utenti. Il software lato client, da parte sua, deve essere in grado di ripristinare in modo sicuro le cronologie delle chiavi degli utenti.
• Repository di certificati scalabile Per ridurre al minimo i costi di distribuzione dei certificati, tutte le applicazioni abilitate per la PKI devono utilizzare un archivio di certificati comune e scalabile.

Supporto a nuove applicazioni

Spesso è difficile per le applicazioni utilizzare la PKI. Secondo il report sulle tendenze PKI e IoT del 2019 di Ponemon Institute, le due sfide più significative che le organizzazioni continueranno ad affrontare per quanto riguarda l’abilitazione delle applicazioni all’utilizzo della PKI, è l'incapacità di una PKI esistente di supportare nuove applicazioni e l'incapacità di modificare le applicazioni legacy.

(Vedi i dettagli nella tabella sottostante).

Mancanza di proprietà chiara

Lo stesso sondaggio ha anche rilevato che la principale sfida nell'implementazione della PKI continua ad essere la mancanza di una chiara proprietà della sua funzione. Ma nell'ambiente PKI di oggi, è necessaria una gestione adeguata, soprattutto se si considera che:

• l’infrastruttura è distribuita, con molti certificati emessi a molte persone, luoghi e cose
• è necessario proteggere più "cose" ora che mai e gestire certificati di vita più brevi
• i certificati proteggono le applicazioni aziendali critiche e le interruzioni possono essere costose e difficili da diagnosticare

una corretta visibilità dei certificati nella tua infrastruttura, aiuta non solo a centralizzare la gestione PKI all’interno di un reparto specifico, ma anche tramite uno strumento software che fornisce un unico pannello di controllo per il monitoraggio e il reporting dei certificati.

Esistono diversi standard e normative, soprattutto a livello regionale e/o governativo, ma le due principali certificazioni di sicurezza più importanti quando si distribuisce PKI sono:

• Common Criteria EAL Livello 4+
• FIPS 140-2 livello 3