Abbiamo visto nei capitoli precedenti che è possibile instaurare diversi livelli di sicurezza per i nostri Web service in base alle più svariate esigenze e che alla base dei meccanismi di sicurezza vi sono chiavi e certificati. Si è creata di conseguenza la necessità di prevedere adeguati meccanismi di scambio per questi file per evitare di risolvere un problema introducendone un altro.
Problematiche e soluzioni per la distribuzione
E’ possibile scegliere una soluzione che richieda l’uso di chiavi simmetriche, ma questo comporta la necessità di un canale di distribuzione sicuro che a sua volta necessita di un ulteriore scambio di file per la relativa instaurazione, scambio che dovrà avvenire all’esterno dei protocolli usati per la comunicazione sicura da instaurare per non inficiarne la sicurezza, probabilmente con uno scambio che avviene fisicamente o per mezzo dei canali più disparati che a loro volta potranno portare ad esporre i sistemi a diversi rischi.
La divisione in chiavi pubbliche e private ha alleviato il problema rimuovendo la necessità di distribuire le chiavi private, ma rimane il problema della creazione e distribuzione dei certificati, che può avvenire anch’essa nei più svariati modi. Un modo è quello in cui il fornitore di servizi crea e distribuisce certificati e chiavi da usare per accedere ai servizi. Un simile meccanismo centralizzato tende però ad instaurare un legame troppo forte con il fornitore di servizi che dovrà servire tutti coloro che faranno richiesta con quanto necessario, un meccanismo che mal si presta ad ambienti dinamici e non risolve il problema degli scambi insicuri.
Altro modo è quello in cui il fornitore di servizi si limita a controfirmare un CSR, ma anche questo sistema continua a presentare un collo di bottiglia, cioè il passaggio attraverso il fornitore dei servizi, un sistema che mal si presta a soddisfare logiche dinamiche complesse. Altro problema, c’è la possibilità che un servizio sia creato tramite cascata di diversi servizi, nel qual caso si dovranno verificare le credenziali su diversi livelli.
La soluzione può consistere nell’utilizzo di una PKI (Public Key Infrastructure), un’infrastruttura pubblica a supporto della distribuzione e identificazione di chiavi pubbliche, in grado di abilitare utenti e sistemi a distribuire dati in modo sicuro su Internet o reti, verificando l’identità degli attori coinvolti.
Gli elementi di una PKI
La tipica PKI è basata su hardware, software, policy e standard per creare, gestire, distribuire e revocare chiavi e certificati digitali, certificati che costituiscono l’elemento cardine per affermare un’identità e associarla a una chiave pubblica contenuta in un certificato.
Tipicamente una PKI include diversi elementi tra i quali l’autorità di certificazione (CA, Certificate Authority) che agisce come elemento radice della catena di fiducia fornendo servizi che consentono l’autenticazione delle identità di utenti, sistemi e altre entità. Un’autorità di registrazione chiamata CA subordinata e certificata da una CA radice, rilascia certificati per usi specifici. Un database dei certificati memorizza le richieste dei certificati, eventuali problemi/anomalie e revoche degli stessi. Vi sono infine gli store dei certificati che risiedono sui computer degli utenti per immagazzinare certificati e chiavi private.
La distribuzione dei certificati alle entità richiedenti avviene in seguito alla verifica dei richiedenti, una procedura che avviene mediante la controfirma del certificato mediante la chiave privata della CA stessa. Le CA usano certificati radice fidati per instaurare catene di fiducia. Questo da un lato permette di creare sistemi considerati sicuri, dall’altro la catena creata è tanto sicura quanto il suo anello più debole.
Se una CA è compromessa la sicurezza dell’intera PKI è a rischio. Inoltre ci sono diversi standard che coprono i aspetti differenti dell’instaurazione della PKI (ad esempio l’X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework) ma non vi sono direttive governative predominanti in grado di sostenere questi standard. E’ possibile sottomettere un CSR (Certificate Signing Request) presso le principali CA quali Symantec, GlobalSign o Comodo. E’ anche possibile eseguire delle richieste a scopo di test presso le CA che lo consentono, o presso il sito eduPKI, utile a generare e sottomettere CSR per i test.
Per concludere, accenniamo che vi sono altri sistemi utili allo scopo, un sistema alternativo si basa su un meccanismo non prettamente gerarchico nel quale invece di affidarsi ad un gerarchia top-down ci si basa sull'autenticazione tra utenti. Anche questo sistema ovviamente ha dei punti che si prestano ad attacchi e funziona fintanto che gli utenti si comportano in modo onesto (Web of trust). Applicato nel mondo reale nel quale questi meccanismi si instaurano proprio perché non è detto che gli utenti si comportino in modo onesto, tale meccanismo può funzionare per scopi limitati, ad esempio in contesti delimitati come all’interno di aziende nelle quali vi sia una supervisione.
