APPENDICE

PKI

In Windows 2000 è possibile utilizzare la crittografia a chiave pubblica. La crittografia a chiave pubblica è usata per rendere sicure le attività sulle reti aperti come Internet. Essa consente di criptare i dati e verificare l’identità dei client e dei server utilizzando i certificati. La sfida con questa tecnologia è tenere traccia dei certificati. 

Una PKI (Public Key Infrastructure) fornisce la capacità di usare, gestire, e trovare certificati a chiave pubblica.

Microsoft Windows 2000 include una PKI che consente di sfruttare i benefici della crittografia a chiave pubblica, all’interno delle attività produttive di un'organizzazione. A differenza delle PKI fornite da terze parti, che comporta costi aggiuntivi per l’acquisto della licenza e integrazione all’interno dell’organizzazione, con Windows 2000 PKI è rilasciato come parte del sistema operativo, non richiede nessuna licenza aggiuntiva, ed normalmente integrata all’interno della rete.

La PKI di Windows 2000 è stata realizzata per raggiungere i seguenti obiettivi:

• Interoperabilità, ovvero l’abilità di scambiare messaggi, certificati, e servizi con altri componenti dello standard PKI. Infatti Microsoft ha abbracciato alcuni standard relativi alla PKI e gli ha implementati nei suoi prodotti. Tra gli standard PKI supportati da Windows 2000 ricordiamo X.509, SSL, IPSec. Nella tabella 1 vengono presentati tutti gli standard PKI inglobati in Windows 2000.

Tabella 1 - Standards PKI supportati da Windows 2000  

• Sicurezza, fornita utilizzando sia gli standard indicati nella tabella 1, sia i migliori algoritmi di sicurezza, quali RSA E DSS (crittografia a chiave pubblica), MD4, MD5 e SHA-1 (algoritmi di hash), RC2 e RC4 (crittografia a chiave segreta). Inoltre, sfruttando l’integrazione con Active Directory, è possibile memorizzare in essa i certificati, le CRL (Certificate Revocation List) con tutte le informazioni associate, consentendo poi di specificare chi può accedere a queste informazioni e come, attraverso i meccanismi di sicurezza di Active Directory. 
• Flessibilità, ovvero l’abilità di configurare il rilascio, la distribuzione e l’uso dei certificati in modo da soddisfare le esigenze specifiche dell’organizzazione. La flessibilità consente di ottenere due benefici: 

1. Costi più bassi. Una PKI ben configurata non comporta nessuna spesa aggiuntiva (acquisto server o moduli aggiuntivi, licenze per certificati) per installarla all’interno della rete dell'organizzazione.
2. Maggiore sicurezza. Installando e configurando solo le componenti della PKI necessarie, si elimina il rischio di utilizzare componenti che forniscono un servizio non sicuro.

            La configurazione di una PKI passa attraverso i seguenti passi:

1.      Scelta del modello di CA (Certificate Authority, Autorità di certificazione). Il primo passo nella configurazione di una PKI è la scelta del modello gerarchico di CA da utilizzare. Esistono diversi modelli che hanno i propri vantaggi e limiti dal punto di vista tecnico e politico, modelli che possono anche essere combinati; per esempio, un'organizzazione potrebbe scegliere di demandare la gestione dei certificati ad una autorità esterna, mentre un'altra organizzazione potrebbe scegliere di creare al suo interno una autorità di certificazione. Questo passo è quindi fondamentale nella configurazione di una PKI.

2.      Scelta del criterio di validazione. In questo passo si determina cosa succede quando un utente tenta di usare un certificato; per esempio, controllare che il certificato non sia stato revocato, o non sia scaduto, oppure verificare l’autenticità della CA che ha rilasciato il certificato.  

3.      Scelta dei delegati. In questo passo, si individuano le persone o i gruppi responsabili del controllo dell’accesso alle informazioni sui certificati. Tale controllo è facilitato da tool forniti da Windows 2000, tool basati sui Criteri di gruppo di Active Directory. Questi criteri consentono: di rilasciare automaticamente certificati ogni qualvolta viene aggiunto un nuovo utente; di stabilire quali certificati sono di fiducia; di decidere quali impostazioni dei criteri di gruppo possono e/o devono essere ereditati dagli oggetti di più basso livello. 

4.      Gestione di caratteristiche di sicurezza avanzata. Esistono delle organizzazioni che hanno delle particolari esigenze di sicurezza. Per esempio, in Dipartimento della Difesa americana specifiche tre livelli di sicurezza per le sue CA: alto, medio e basso. In questo passo vengono individuare tale esigenze, e attraverso i tool forniti da Windows 2000, vengono incluse della configurazione della PKI. 

• Facilità d’uso, per gli amministratori, per gli utenti che ottengono e usano i certificati, ma anche per gli sviluppatori che creano applicano basate sulla PKI. Infatti Windows 2000 fornisce diversi strumenti per facilitare l’utilizzo della PKI. Gli utenti possono utilizzare Certificate Request Wizard (richiamandolo da Internet Explorer o Windows 2000 Certificate Manager), che con una autocomposizione, fornisce all’utente una serie di pagine da riempire con le informazioni personali, e inoltra la richiesta alla CA responsabile. Il compito degli amministratori è facilitato da Microsoft Management Console, che include una finestra di gestione dei certificati, consentendo di eseguire varie operazioni di gestione di una PKI, come la revoca dei certificati, l’analisi delle loro proprietà, ect..Per quanto riguarda gli sviluppatori, possono utilizzare sia CryptoAPI che SSPI, per realizzare applicazioni che interagiscono con la PKI.

In figura 1 sono mostrate le componenti della PKI in Windows 2000. Questa figura rappresenta una vista logica che non implica requisiti fisici per server separati; infatti molte funzioni possono essere combinati su un singolo server. L’elemento più importante è rappresentato da Microsoft Certificate Services, un servizio che consente all’organizzazione, che utilizza la PKI, di agire come una autorità di certificazione (CA), e quindi in grado di rilasciare e gestire certificati digitali. Active Directory, il servizio di Microsoft 2000 che consente di individuare le risorse nella rete aziendale in maniera efficiente, viene utilizzata come servizio di pubblicazione per la PKI.

	Figura 1 - Componenti di PKI in Windows 2000

La PKI non sostituisce l’esistente modello di autenticazione di Windows 2000, basato sul Domain Controller (DC) e sul Key Distribution Center (KDC) di Kerberos; piuttosto, PKI interagisce con questi servizi. In particolare: il Domain Client gestisce il processo di logon con le smartcard, il Domain Administrator applica i Criteri di gruppo, mentre il Key Distribution Center Domain Controller viene usato nel processo di logon al dominio.

Per ulteriori informazioni si può consultare la sezione Riferimenti.

EFS

Encrypting File System (EFS) realizza la cifratura e la decifratura di file attraverso uno schema basato sulla crittografia a chiave pubblica e sui certificati a chiave pubblica. I file vengono cifrati con l’algoritmo di cifratura simmetrico DES, utilizzando come chiave una chiave generata in maniera casuale, detta File Encryption Key (FEK). La FEK è cifrata utilizzando la chiave pubblica dell’utente, e viene memorizzata, insieme con il file cifrato, in uno speciale attributo EFS, chiamato Data Decryption Field (DDF) (fig. 2). 

    Figura 2 - Cifratura in EFS

Per la decifratura si utilizza la chiave privata dell’utente: la FEK viene decifrata con la chiave privata e poi utilizzata per decifrare il file, utilizzando l’algoritmo DES (fig. 3).

    Figura 3 - Decifratura in EFS

La FEK viene anche cifrata con  la chiave pubblica ottenuta dal certificato del Recovery Agent, e memorizzata, insieme con il file cifrato, nell’attributo Data Recovery Field (DRF). Il Recovery Agent è un ruolo associato ad una persona (in genere l’amministratore di sistema) dell’organizzazione in cui viene utilizzato EFS, per eseguire le operazione di recovery dei file cifrati. Questa operazione viene eseguita quando l’utente dei file cifrati perde la chiave privata o lascia l’organizzazione. Durante l’operazione di recovery, la FEK viene decifrata con la chiave privata del Recovery Agent, e poi utilizzata per decifrare il file dell’utente (fig. 4).

    Figura 4 - Recovery in EFS

L’architettura EFS è stata implementata in Windows 2000. EFS risiede nel kernel ed è fortemente integrato con NTFS (fig. 5).

    Figura 5 - Implementazione di EFS in Windows 2000

In particolare, EFS in Windows 2000 è composto da:

Driver EFS. Il driver EFS si trova logicamente sul top di NTFS. Esso comunica con EFS Service per richiedere i DDF, DRF, le chiavi per la cifratura dei file, e altre servizi. Queste informazioni vengono passate al FSRTL (File System Run-Time Library) per eseguire varie operazioni sul file system (lettura, scrittura) in maniera trasparente.

EFS FSRTL. File System Run-Time Library è un modulo dentro il driver EFS che implementa delle chiamate a NTFS per gestire varie operazioni sul file system come letture, scritture di file e directory cifrati, così come le operazioni di cifratura, decifratura e recovery di file di dati quando vengono letti o scritti su disco. L’esecuzione di queste operazioni avviene in maniera trasparente per l’utente.

EFS Service. EFS Service comunica con il driver EFS. Nella modalità utente si interfaccia con CryptoAPI per fornire le FEK e per generare i DDF e DRF. EFS Service fornisce inoltre il supporto per le API Win32, che sono interfacce di programmazione per la cifratura, decifratura, recovery.

API Win32. Sono interface di programmazione per eseguire operazioni di cifratura, decifratura e recovery dei file, ed importare ed esportare i file cifrati (senza decifrarli).

Per ulteriori informazioni si può consultare la sezione Riferimenti.

SSPI

Per fornire la compatibilità con i client esistenti, Windows 2000 supporta protocolli multipli di sicurezza; l’elemento strutturale del sistema operativo che fornisce questo supporto è chiamato Security Support Provider Interface (SSPI). Tale interfaccia è una API Win 32 che le applicazioni e i servizi di sistema usano per sfruttare i meccanismi di sicurezza, mentre nascondono la complessità dei protocolli di sicurezza: sfruttando SSPI, gli sviluppatori di applicazioni possono creare applicazioni che usano i protocolli di sicurezza di Windows 2000.

SSPI lavora come un processo ad un livello intermedio, cosi che gli amministratori possono scegliere tra una varietà di Security Support Providers (SSPs). Per esempio, l’autenticazione Kerberos e NTML sono implementati come SSPs in Windows 2000, così che le applicazioni scritte con SSPI possono usare sia l’autenticazione NTLM che quella Kerberos, a seconda della configurazione del client e del server.

        Figura 6 - SSPI interfacciato ai protocolli di sicurezza

Per ulteriori informazioni si può consultare la sezione Riferimenti.

IPSec

Il sistema operativo Microsoft Windows 2000 Server semplifica la realizzazione e gestione della sicurezza su rete con Windows IP Security, che rappresenta una implementazione del IP Security Protocol (IPSec). Tale protocollo, sviluppato dalla Internet Engineering Task Force (IETF) per supportare l’autenticazione a livello di rete, l’integrità dei dati e la cifratura, è stata integrata con i meccanismi di sicurezza di Windows 2000 Server, per creare una piattaforma ideale per salvaguardare le comunicazioni in Internet e Intranet.

I benefici derivanti dalla integrazione di IPSec con Windows 2000 Server, rivolti per lo più agli amministratori di rete, includono:

• Standard Aperto. IPSec fornisce uno standard aperto in alternativa alle tecnologie di cifratura proprietaria del protocollo IP.
• Trasparenza. IPSec lavora al di sotto del Transport Layer nell’architettura OSI, divenendo trasparente alle applicazioni e agli utenti.
• Autenticazione. Forti servizi di autenticazione rendono impossibile a chiunque, anche a coloro che falsificano l’identità, di intercettare i dati che viaggiano lungo la rete. Come algoritmo di autenticazione viene usato HMAC.
• Confidenzialità. Sono presenti dei servizi in grado di evitare degli accessi non autorizzati ai dati che viaggiano nella rete. Tale requisito è ottenuto implementando l’algoritmo DES nella modalità Cipher Block Chaining (CBC).
• Integrità dei dati. L’autenticazione IP degli header dei pacchetti, attraverso l’utilizzo dell’algoritmo HMAC, assicurano l’integrità dei dati durante la comunicazione.
• Dynamic rekeying. Durante la stesse comunicazioni, esiste una rekeying dinamico, ovvero un riassegnamento e scambio delle chiavi tra i due estremi della comunicazione, rendendo complicato qualsiasi attacco.
• Link end to end sicuro. Windows IPSec fornisce link end to end tra utenti dentro lo stesso dominio o appartenenti a domini diversi.
• Gestione centralizzata. La gestione è affidata agli amministratori di rete, che si preoccupano di creare degli appropriati livelli di sicurezza basati su vari criteri, quali utenti, gruppi di lavoro, ecc…
• Flessibilità. La flessibilità di Windows IPSec consente di applicare le politiche di sicurezza all’intera organizzazione o ad una singola workstation.

Prima di poter essere utilizzato, Windows IPSec deve essere configurato dagli amministratori di rete, attraverso quattro passi. Innanzitutto, vanno valutate le informazioni che devono essere trasmesse in rete e in Internet, considerando tutti i possibili scenari di comunicazione, al fine di individuare eventuali debolezze.

Successivamente, l’amministratore crea, se necessario, nuovi scenari di comunicazione, creando un modello prefissato che determina il flusso delle informazioni. Ciascuno degli scenari individuati può avere differenti politiche di sicurezza; le informazioni raccolte sono utili per determinare il livello di sicurezza per ciascun scenario, che dipenderà dal tipo di informazione trasmessa e dalla vulnerabilità del canale di trasmissione. Windows 2000 fornisce uno strumento per svolgere questo lavoro, Security Manager, che consente agli amministratori di creare, in maniera molto semplice, i vari livelli di sicurezza necessari.

Come ultimo passo, l’amministratore di rete deve definire i criteri di sicurezza, settando i relativi algoritmi, da assegnare a gruppi di computer o a singoli computer. Anche per questa operazione si può utilizzare Security Manager.

Prima che i pacchetti possano essere trasmessi da una computer ad un altro, deve essere stabilita una Security Association (SA). Una SA è un insieme di parametri che definiscono i servizi e i meccanismi, come le chiavi, necessarie per proteggere le comunicazioni. Per creare tali SA, viene utilizzato il protocollo Internet Security Association and Key Management Protocol (ISAKMP). Inoltre, poiché questo protocollo non è collegato a nessun algoritmo per la generazioni di chiavi, durante la creazione di una SA opera insieme con il servizio Oakley.

Il servizio Oakley è un protocollo per la determinazione delle chiavi, che usa l’algoritmo di Diffie-Helmann per lo scambio delle chiavi.

A questo punto può avvenire la comunicazione tra due computer. La figura 7 mostra un esempio di comunicazione tra due computer, denominati Host A e Host B, che utilizzano Windows IPSec.

Nell’esempio, Alice su Host A trasmette dati ad Bob su Host B. In particolare, Alice esegue un’applicazione che utilizza il protocollo TCP/IP, per esempio FTP, e trasmette i dati a Bob.

I criteri di sicurezza assegnati dall’amministratore a Host A e Host B, determinano il livello di sicurezza della comunicazione. Questi criteri vengono raccolti dal Policy Agent, e da questi vengono passati al driver di IPSec e al servizio ISAKMP/Oakley, che li utilizza, su ciascun computer, per determinare la chiave e una SA. I risultati del servizio ISAKMP/Oakley sono passati al driver di IPSec, che li utilizza per cifrare i dati.

Dopodiché il driver di IPSec trasmette i dati cifrati a Host B. Il driver di IPSec sull’Host B decifra i dati ricevuti e li invia all’applicazione.

        Figura 7 - Funzionamento di IPSec in Windows 2000

Per ulteriori informazioni si può consultare la sezione Riferimenti.

CryptoAPI

CryptoAPI (Cryptography API) è una API molto complessa che consente agi sviluppatori di creare una comunicazione sicura su reti non di fiducia, fornendo alle applicazioni servizi per poter nascondere le informazioni alle persone non autorizzate; tutto ciò senza che lo sviluppatore sia a conoscenza dell’implementazione degli algoritmi con cui lavora.

La comunicazione protetta è basata su tre principi: 

a)      autenticazione;

b)      integrità;

c)      privacy,

principi che vengono garantiti dalle funzioni di CryptoAPI.

L’autenticazione è garantita in CryptoAPI dai certificati digitali, che sono gli equivalenti della carta d’identità; CryptoAPI fornisce agli sviluppatori anche gli algoritmi di autenticazione, come Kerberos.

L’integrità è ottenuta attraverso le firme digitali e le funzioni hash. In particolare le funzioni hash possono verificare che un determinato file sia stato modificato o meno, mentre le firme digitali identificano l’utente o il programma che utilizzano i dati.

La codifica dei dati, attraverso diversi possibili algoritmi di crittografia, consente a CryptoAPI di fornire la privacy ai dati e ai messaggi che vengono trasmessi in rete.

CryptoAPI offre una ampia scelta di algoritmi, che sono implementati nei CSP (Cryptographic Service Provider). Tra quelli a disposizione, ricordiamo:

• Provider crittografico di base di Microsoft: è disponibile fuori dagli USA per ovviare ai problemi di esportazione; la lunghezza della chiave è ridotta .

• Provider crittografico avanzato di Microsoft: identico al precedente, ma la lunghezza della chiave è più lunga.

• Provider crittografico DSS di Microsoft: implementa SHA (Standard Hash Algorithm) e DSS (Digital Signature Standard).

• Provider crittografico DSS e Diffie-Helmann di Microsoft: implementa DSS e Diffie-Helmann.

• Provider crittografico RSA/Schannel di Microsoft: implementa RSA per la firma digitale e MD4+SHA come algoritmo di hash.

Per ulteriori informazioni si può consultare la seguente pagina WEB www.dia.unisa.it/~ads/corso-security/www./CORSO-9900/CryptoAPI/index.htm.

X.500

Lo standard X.500 è stato sviluppato dall’ISO (International Standard Organization), ed è un insieme di regole che definiscono un servizio di directory distribuito contenente tutte le informazioni sugli utenti e sulle infrastrutture a cui appartengono. Per consentire ad un utente autorizzato di interrogare e di accedere alle informazioni contenute nella directory, da qualsiasi punto della rete, esse possono essere sparse tra tutti i server presenti. Per ulteriori informazioni su X.500 si possono consultare i seguenti siti:

1. www.nexor.com/info/directory.htm

2. www.hg.nasa.gov/hg/x500.html

3. www.rfc-editor.org/rfc-index.html

LDAP

LDAP (Lightweight Directory Access Protocol) è uno standard che definisce le operazioni che un proprio client può eseguire per interrogare o modificare gli oggetti nella directory.

Nel caso specifico di Active Directory, si possono utilizzare le seguenti API:

API in C di LDAP: è un insieme di API in linguaggio C sul LDAP;

API di ADSI (Active Directory Service Interface): consente di gestire gli accessi ad Active Directory esponendo gli oggetti memorizzati nella directory. ADSI, però, è uno standard proprietario di Microsoft disponibile attualmente per Novell NDS (NetWare Directory Service), Windows NT e sue applicazioni, come IIS (Internet Information Service).

In generale il protocollo LDAP supporta i linguaggi programmazione C/C++, Visual Basic; inoltre consente di aggiungere nuovi metodi e proprietà agli oggetti, fornendo agli sviluppatori la possibilità di creare applicazioni personalizzate in grado di manipolare gli oggetti della directory. 

Per ulteriori informazioni su LDAP si possono consultare i seguenti siti:

1. www.umich.edu/~dirsvcs/ldap

2. www.wanderlist.com/ldap

3. www.rfc-editor.org/rfc-index.html

RPC

RPC (Remote Procedure Call) è una API di alto livello che consente ai processi di comunicare a vicenda attraverso i confini del processo o della macchina.

RPC fa sì che l’applicazione server esponga le funzioni, che implementano certi servizi, ai client che possono essere sparsi sulla rete, senza che lo sviluppatore si occupi dei meccanismi di trasporto adottati per passare le chiamate; tra le sue applicazioni è disponibile anche la SSPI.

RPC possiede anche un proprio meccanismo di sicurezza, detto RPC autenticato.

Per ulteriori informazioni su RPC si possono consultare i seguenti siti:

1. www.rdg.opengroup.org/onlinepubs/9629399/toc.htm

2. www.rfc-editor.org/rfc-index.html