Certification Authority

Overview Requisiti di progettazione di una gerarchia di CA Creazione di una CA Root Offline Validazione dei Certificati Pianificazione della pubblicazioni della CRL Installazione di una CA Subordinata

Identificare i requisiti per progettare una gerarchia di CA Scope del Progetto Applicazioni che usano una PKI Quali Account usano applicazioni PKI-Enabled? Come identificare i requisiti tecnici Come identificare i requisiti di Business

Applicazioni che usano una PKI Digital Signatures Smart Card Logon Encrypting File System Windows 2003 Certificate Services Internet Authentication Secure E-mail Software Code Signing Software Restriction Policy IP Security 802.1x

Quali Account Usano applicazioni PKI-Enabled? Utenti Computer Servizi

Come Identificare i requisiti Tecnici Per Chiedere Requisiti di sicurezza Quali sono le policy di sicurezza dell’azienda? Avete dei Business Partner? Dovete rispettare standard industriali ogovernativi? Requisiti Amministrativi Chi gestirà le CA? Chi gestirà i certificati? Requisiti di Disponibilità Quante CA richiede l’azienda? Come vengono distribuiti i certificati tra le CA?

Come Identificare i requisiti di Business Per Chiedere Requisiti di Accesso dell’Esterno Verranno rilasciati certificati a utenti esterni? I certificati verranno validati da reti esterne? Requisiti di disponibilità Verranno richiesti certificati a qualunque ora? Verranno richiesti servizi in ogni sede? Requisiti Legali Quali sono le politiche di sicurezza aziendali? Qual è la responsabilità dell’organizzazione?

Progettazione della gerarchia delle CA: Location Root Policy India Canada United States CA Hierarchy Based on Certificate Usage CA Hierarchy Based on Location CA Hierarchy Based on Departments CA Hierarchy Based on Organizational Structure Si usa una gerarchia di CA basata sulla location per: Rispettare i requisiti legali locali (gestione) Rispettare i requisiti di Business per la disponibiltà della CA

Passi per progettare i Requisiti Legali Security Policy 1 Creare il Certificate Practice Statement (CPS) 3 Certificate Practice Statement Creare la certificate policy 2 Certificate Policy Root CA Policy CA Issuing CA 4 Pubblicare il CPS sulla policy CA Sviluppare la security policy 1

Security Policy Definisce le classi di dati da proteggere e le misure da adottare: tra queste i certificati Tra l’altro stabilisce: Quali dati/applicazioni/servizi devono essere protetti con i certificati digitali Quali misure adottare per proteggere le chiavi private associate ai certificati (smart card, token, Hardware Security Module, ...) Quali misure usare per verificare l’identità di chi richiede un certificato

Certificate Policy Descrive le procedure adottate per validare l’identità di chi richiede un certificato prima della sua emissione È la policy di emissione del certificato che determina se ci si può fidare del certificato stesso Dovrebbe contenere le seguenti informazioni: Com’è verificata l’identità del richiedente L’uso dei certificati rilasciati dalla CA Il device in cui le chiavi private devono essere conservate La responsabilità del subject nel caso la chiave privata sia compromessa o persa Le policy di revoca, le procedure e le responsabilità

Certification Practice Statement Definisce le misure usate per rendere sicure le operazioni della CA e la gestione dei certificati È un documento pubblico che deve essere accessibile a tutte le entità che usano i certificati rilasciati dalla CA Deve contenere le seguenti informazioni: Come la CA applica le misure per la verifica delle identità prima del rilascio dei certificati La responsabilità dell’organizzazione in caso di frode verso un servizio protetto dal certificato nel caso in cui si dimostri il problema essere nel certificato Le circostanze che possono portare ad una revoca preventiva dei certificati Quando il CPS è inserito nel certificato di una CA si applica alla CA stessa e a tutte le subordinate

Come soddisfare i Requisiti di Sicurezza Azioni consigliate Mettere in sicurezza la root e la policy CA Rimuovere la root e la policy CA dalla rete Conservare le CA offline in un luogo sicuro Mettere in sicurezza l’issuing CA Controllare l’accesso alla sala server Rimuovere i servizi non usati sulla issuing CA Proteggere le chiavi private Usare Software CSP Usare smart cards o PC card token con PIN Usare Hardware Security Module Fornire requisiti di rilascio differenti Implementare CA separate per supportare template di certificate diversi per ogni tipo di requisito di rilascio

Come supportare i requisiti di Accesso Esterno Azioni consigliate Abilitare i client esterni a riconoscere i certificati Usare una CA commerciale Implementare cross certification Implementare qualified subordination Pubblicare le informazioni di CRL e AIA esternamente Gestire i certificati rilasciati agli utenti esterni Rilasciare certificati da una gerarchia di CA privata Trustare i certificati rilasciati da un’altra organizzazione Implementare la certificate trust lists Implementare cross certification o qualified subordination

Come supportare i Requisiti delle Applicazioni Azioni consigliate Minimizzare il numero di certificati rilasciati Implementare certificati con uso multiplo Minimizzare il numero di CA Pubblicare più certificate da una CA Gestire le CA basandosi sulle applicazioni Pubblicare ogni template di certificato da una CA dedicata

Progettazione di una struttura di CA gerarchiche Profondità raccomandata di una Gerarchia di CA Livelli di Sicurezza di una Gerarchia di CA Considerazioni nella scelta di una tipologia di CA Gestione della CA utilizzando la separazione dei Ruoli Linee Guida per la progettazione di una Gerarchia di CA

Profondità Raccomandata di una Gerarchia di CA Requisiti Profondità Raccomandata Bassa Sicurezza (1 livello) Root CA singola Poche richieste di certificati Bassi requisiti di sicurezza per la Sicurezza della CA Media Sicurezza (2 livelli) Root offline e subordinata online Una singola CA offline (disconnessa dalla rete) Una Issuing CA online Due o più CA per rilasciare ogni modello di certificato Alta Sicurezza (3-4 livelli) Offline root e offline policy Più issuing CA subordinate online Massimizzare la sicurezza Organizzazione grandi e geograficamente distribuite o a alta sicurezza

Livelli di sicurezza nella Gerarchia di CA Sicurezza per la root CA: Richiede i più alti livelli di sicurezza Richiede accesso minimo All’aumentare della distanza dalla root CA: Diminuisce la Sicurezza Aumenta l’accesso alle issuing CA Root CA Policy CA Issuing CA Maggiore Minore Facilità di accesso Sicurezza

Considerazioni per la scelta di un tipo di CA Decision point Standalone Enterprise Quando usarla CA Offline Issuing CA Active Directory Non richiede Active Directory Richiede Active Directory Tipo di Certificate Fornisce supporto per tipi di certificati standard Implementa i modelli di certificato Gestione della richiesta del Certificato Rilasciato o negato da un certificate manager Rilasciato o negato basandosi sulle permission del modello di certificato

Creazione di una gerarchia di CA Creazione di una CA Root Offline Validazione dei Certificati Pianificazione della pubblicazioni della CRL Installazione di una CA Subordinata

Creazione di una CA Root Offline: file CAPolicy.inf Il file CAPolicy.inf file definisce la configurazione dei Certificate Service Il file CAPolicy.inf definisce il: Certificate Practice Statement (CPS) Intervallo di pubblicazione della CRL Le impostazioni di rinnovo dei certificati La dimensione della chiave Il periodo di validità del certificato I percorsi CrlDP, AIA

LAB Creazione del CAPolicy.inf

Definire le impostazioni per una CA Root Offline Offline Root CA Database and Log Settings Standalone CA Policy Validity Period Computer Name Key Length CA Name Cryptographic Service Provider

Mettere in sicurezza una CA Offline con un HSM Un Hardware Security Module (HSM) fornisce: Key Storage e backup sicuro (HW) Accelerazione delle operazioni di crittografia Protezione e gestione delle chiavi private Load Balancing e failover tramite moduli HW

Linee Guida per distribuire una CA Root Offline Non collegare la CA alla rete Implementare CDP e AIA extension vuote Implementare un CSP HW o un HSM Scegliere una lunghezza di chiave supportate da tutti i protocolli e le applicazioni Usate un unico distinguished name per la CA Impelementate un periodo di validità lungo (10- 20 anni)

Lab Installazione di una CA Root Offline

Come le applicazioni verificano lo stato dei Certificati Processo Azione Certificate discovery Raccolgono i certificati delle CA dalla cache (CryptoAPI), Group Policy, applicazioni, AIA URL Path validation Validano i certificati con le chiavi pubbliche e i certificati che li rilasciano Revocation checking Verificano che nessun certificato sia revocato

Il Certificate Chaining Engine L’applicazione che riceve il certificato chiama il Certificate Chaining Engine per la verifica dei certificati Il Certificate Chaining Engine verifica: - il certificato presentato all’applicazione - il certificato della CA che lo ha rilasciato: l’Issuing CA - il certificato della CA che ha autorizzato l’Issuing CA - e così via fino a raggiungere una Root CA I certificati sono raccolti da - Cache delle CryptoAPI - Group Policy (NIENTE SCORCIATOIE !!!) - Authority Information Access (AIA) presente nei diversi certitificati In Parallelo si verificano le CRL (W2k3/win XP/W2k) Root CA Issuing CA Policy CA Computer or User Certificate

Test di validazione dei Certificati Criterio Time validity La data corrente cade tra la data di partenza e di scadenza del certificato Certificate recognition Il certificato usa un formato X.509 valido Certificate contents Tutti i campi richiesti sono completati Signature check Il contenuto del certificato non è stato modificato Revocation check Il certificato non è stato revocato Root check Il Certificato è concatenato a una trusted root CA Policy validation Il Certificato deve contenere le certificate o application policy richieste dall’applicazione Critical extensions L’applicazione riconosce le estensioni critiche

Tipi di CRL Caratteristiche CRL Base CRL Delta Certificati Contiene tutti i certificati revocati Contiene solo i certificati revocati dall’ultima CRL base Intervallo di Pubblicazione Pubblicata meno frequentemente Pubblicata più frequentemente Dimensione Grande Piccola Computer Client Riconosciuta da qualunque versione di Windows Riconosciuta da Windows XP o Windows Server 2003

Come vengono pubblicate le CRL Delta CRL #2 Delta CRL #3 Cert5 Cert5 Cert7 Revoke Cert5 Revoke Cert7 Time Cert3 Cert3 Cert5 Cert7 Base CRL #1 Base CRL #4

Dove creare i Publication Point External Web Server Active Directory FTP Server File Server Internet Internal Web Server Firewall Firewall Active Directory Web servers FTP servers File servers Pubblicare il certificato della root CA e la CRL in: Offline Root CA

Lab Modificare le extension CrlDP e AIA Modify ModifyCDPandAIA.cmd Run ModifyCDPandAIA.cmd Publish the CRL Publish the CA certificate

CA Subordinata: preparare l’Issuing CA Per preparare l’Issuing CA a rilasciare un certificato di CA subordinata Verificare che le estensioni AIA e CDP siano valide Configurate il periodo di validità massimo per tutti i certificati rilasciati Confgurate il periodo di validità per il modello di certificato della CA Subordinata

Passi per installare una CA Enterprise Subordinata Determinate la tipologia della parent CA Installate i Certificate Services Sottoponete la richiesta di certificato della CA Subordinata alla CA immediatamente superiore nella gerarchia di CA Installate il certificato della CA Subordinata

Considerazioni per configurare le estensioni AIA e CDP Utenti Strategia Esterni Pubblicate CRL e AIA esternamente Configurate il DNS perche faccia riferimento all’indirizzo IP esterno di pubblicazione della CRL Interni Non modificate la pubblicazione di default: Active Directory Il Web server della CA enterprise

Lab C: Implementazione di una CA Enterprise Subordinata