L'architettura della JCA

L'architettura della JCA

Il principio fondamentale su cui si basa la Java Cryptography Architecture è quello di permettere all'utente di utilizzare i servizi di crittografia offerti senza doversi preoccupare di quella che è l'implementazione del servizio stesso. L'indipendenza dall'algoritmo è raggiunta definendo dei tipi di crittografia, che sono per lo più servizi, detti "engine", e classi che ne forniscono l'implementazione, le quali sono dette "engine class".

L'indipendenza dall'implementazione, invece, è raggiunta usando un'architettura basata sui provider. Con il termine provider o "fornitore di servizi crittografici[1]" ci riferiamo ad uno o più package che implementano, effettivamente, uno o più servizi di crittografia.

Per quanto riguarda, invece, l'interoperabilità, con questo termine si intende che il prodotto di un provider deve essere compatibile con quello di un altro. In questo modo ciò che è stato costruito con un provider può essere utilizzato in servizi implementati da un altro, riuscendo a superare quelli che possono essere i limiti implementativi di un fornitore o di un altro.

Le "Engine Class"

Le engine class definiscono astrattamente i servizi per la crittografia, cioè sono classi definite abstract, e per questo non forniscono l'implementazione vera e propria del servizio.

La JCA rappresenta l'insieme dei package della sicurezza, presenti nella JDK 2, relativi alla crittografia, e racchiude anche le engine class, le quali saranno istanziate da un utente per eseguirne le operazioni corrispondenti. Quindi queste classi definiscono i metodi che permettono l'accesso a un servizio crittografico. Un utente può scegliere tra una gamma di dodici engine class, qui di seguito elencate, dove le ultime tre sono introdotte nella ultima versione di JDK:

MessageDigest: calcola il message digest[2] di dati specifici;

Signature: calcola e verifica la firma digitale;

KeyPairGenerator : genera una coppia di chiavi asimmetriche, pubblica e privata specifiche per un dato algoritmo;

KeyFactory : convertire una chiave crittografica di tipo Key da opaca, a trasparente e viceversa;

CertificateFactory: crea certificati per chiavi pubbliche e Liste di Revoca dei Certificati (CRL);

Keystore: utilizzato per creare e gestire un keystore[5];

AlgorithmParameters: gestisce i parametri di un particolare algoritmo, inclusi i parametri di codifica e decodifica;

AlgorithmParameterGenerator: genera un set di parametri relativi ad un particolare algoritmo;

SecureRandom: genera di numeri random e pseudo-random;

CertPathBuilder: utilizzata per la costruzione di catene di certificati[6];

CertPathValidator: utilizzata per l'operazione di verifica della validità di un certificato;

CertStore: utilizzata per il recupero di certificati da qualche contenitore.

Ad essere precisi, le engine class forniscono l'interfaccia per quelle che sono le funzionalità di un particolare servizio, in maniera del tutto indipendente dall'algoritmo utilizzato. Ad esempio la engine class Signature fornisce i metodi di accesso alle funzioni per la firma digitale, indipendentemente da quello che sarà il provider installato sulla macchina. L'effettiva implementazione, per ciascun algoritmo, dovrebbe essere fornita dalla classe SignatureSPI, come per SHA1withDSA SHA1withRSA e MD5withRSA

Quindi le engine class forniscono solo l'interfaccia di un certo servizio, mentre l'effettiva implementazione è lasciata ai Service Provider Interface, SPI. Questo significa che per ogni engine class c'è una corrispondente classe astratta SPI, il cui scopo è quello di definire i metodi che quel provider deve implementare.

Ogni chiamata ad un metodo di un'istanza di una engine class contiene al suo interno, in maniera invisibile all'utente, una chiamata allo stesso metodo di un'istanza di una classe SPI. La relazione tra una engine class ed una classe SPI è stata standardizzata; ad ogni engine class corrisponde una classe astratta con lo stesso nome più il suffisso "SPI". I metodi di una engine class sono tutti definiti final.

Quindi, dato che i metodi di una engine class sono interfacce per le classi sottostanti, allora un'istanza di queste classi non sarà ottenibile con il costrutto new ma si otterrà tramite l'invocazione del metodo getInstance(), il quale, in genere, avrà più implementazioni per lo stesso obiettivo, ognuna differente dalle altre per il tipo di parametri passati; in ogni caso questi concetti saranno spiegati più in dettaglio nel prosieguo della tesi.

In precedenza si è detto che queste classi implementano in qualche modo dei servizi che sono offerti da dei provider, che dovranno essere installati sulla macchina per usufruirne dei servizi. Il modo in cui è possibile invocare un algoritmo implementato da un provider o l'algoritmo di un provider in particolare è spiegato nel paragrafo successivo.

I provider dei servizi crittografici

Per usufruire di un servizio, per un particolare algoritmo, un provider deve invocare la sottoclasse SPI corrispondente a quel servizio e fornire l'implementazione per tutti i metodi astratti in essa definiti.

Dunque un provider è un insieme di package che forniscono l'implementazione ai servizi crittografici offerti.

La Sun Microsystem fornisce, nell'istallazione della JDK, un provider di default chiamato "SUN". I servizi offerti dal provider della SUN includono:

L'implementazione dell'algoritmo DSA;

L'implementazione degli algoritmi MD5 e SHA-1 per il calcolo del digest;

Le funzioni per un generatore di coppie di chiavi pubbliche e private DSA;

Un AlgorithmParameter per l'algoritmo DSA;

Un AlgorithmParameterGenerator per l'algoritmo DSA;

Un'implementazione dell'algoritmo proprietario "SHA1PRNG[7]" come SecureRandom

Una CertificateFactory per i certificati di tipo X.509 e per le CRL;

Un'implementazione del keystore proprietario chiamato "JKS".

Ogni istallazione di un SDK di Java prevede l'installazione di uno o più provider, a seconda dell'esigenza e dell'utilizzo che ne deve fare l'utilizzatore. Quando si aggiungono dei nuovi provider all'architettura del sistema Java, questi possono essere richiamati in due modalità: dinamicamente o staticamente.

La JCA offre anche un insieme di metodi, i quali costituiscono le API della crittografia in Java. Alcune di queste API sono state introdotte per permettere all'utente di interrogare la piattaforma Java su quali provider dispone al momento e su quali servizi offrono.

L'utente Java, quindi, ha in mano i mezzi per potersi configurare a proprio piacimento l'ambiente a runtime, installando più provider e specificando anche la priorità che devono avere tra di loro. Con il termine priorità si intende che i provider vengono montati sulla piattaforma con un certo ordine, il quale sarà indispensabile per decidere, a tempo di esecuzione, quale provider andare a caricare nel caso in cui nell'applicazione non sia specificato.

La classe Provider

Questa classe, presente come le altre nel package java.security, è un'interfaccia comune per package o insiemi di package, fornendo i metodi necessari per accedere al nome del provider, al numero della versione e ad altre informazioni.

Per fare in modo tale che, in un'architettura come quella di JCA, un utente possa decidere quale provider utilizzare, semplicemente specificandolo come parametro nella chiamata di un metodo, occorre che il provider che implementa questi servizi aggiunga alla sua implementazione una sottoclasse della classe Provider. Il costruttore di questa sottoclasse ha il compito di settare alcune proprietà utili al provider stesso. Infatti, ad esempio, in Java 2 SDK, le API usano una di queste proprietà per cercare i servizi che un provider fornisce. In altre parole questa sottoclasse specifica il nome delle classi che implementano i servizi.

Quando un gruppo di sviluppatori implementa dei servizi, può rivolgere maggiormente l'attenzione su aspetti software piuttosto che quelli hardware, oppure può cercare o meno l'indipendenza dalla piattaforma; la JCA invece cerca di considerare più aspetti possibili lasciando sia all'utente finale che allo sviluppatore la libertà di scegliere ciò di cui hanno bisogno.

Installare un provider

Nel paragrafo 2.1.2 di questo capitolo, avevamo accennato al fatto che un provider, non presente sulla macchina, potesse essere caricato staticamente oppure dinamicamente.

Quando si parla di installazione statica di un provider bisogna seguire le indicazioni che sono state date nel primo capitolo nel paragrafo su come installare la JCE (par. e 1.3.2).

Per quanto riguarda invece l'installazione dinamica di un provider, il discorso si fa interessante e merita un minimo di spiegazione.

Per poter installare dinamicamente un provider occorre utilizzare alcune delle funzionalità offerte dalle classi Provider, la cui descrizione è stata fatta nel paragrafo 2.1.2, e Security, presenti nel package java.security

La classe Security

La classe Security gestisce tutte le proprietà e i metodi relativi alla sicurezza, oltre ad offrire un metodo statico per la gestione dei provider. I metodi di questa classe sono tutti definiti come static e non sono mai istanziati. I metodi per aggiungere o rimuovere un provider ma anche per settare le proprietà di sicurezza possono essere eseguiti solo da programmi fidati[9]. Di seguito vengono riportati alcuni metodi contenuti nel package java.security.Security che rappresentano le operazioni che si possono eseguire per sapere quali provider sono installati e per aggiungere o rimuovere dinamicamente un provider.

Per sapere quali provider sono installati sulla macchina possiamo invocare il seguente metodo:

oppure

Il primo metodo ritorna un vettore contenente tutti i provider installati, nell'ordine con cui sono stati memorizzati all'interno del file java.policy. Il secondo metodo invece ritorna un oggetto provider rappresentante quello specificato come parametro; se il provider specificato non è installato ritorna null

Per gestire l'aggiunta di un provider possiamo utilizzare i seguenti due metodi:

oppure

Il primo metodo inserisce il provider specificato come parametro come ultimo elemento della lista dei provider installati e ritorna il numero della posizione, che sarà pari a nel caso in cui il provider non venga aggiunto perchè già installato. Il secondo metodo invece permette si aggiungere un provider alla lista, specificandone lo posizione. Se il provider è già installato ritorna -1 e non lo aggiunge alla lista, altrimenti lo aggiunge nella posizione indicata e aggiorna tutti quelli successivi alla sua posizione traslandoli di una posizione indietro.

Se invece si intende rimuovere un provider dalla lista occorre invocare il seguente metodo:

Questo metodo rimuove dalla lista il provider specificato e l'aggiorna traslando di una posizione in avanti tutti quelli che seguivano il provider eliminato.

Quindi se, ad esempio, si intende aggiornare la priorità di un certo provider occorrerà per prima cosa eliminarlo dalla lista e dopodichè inserirlo specificano la posizione desiderata.  

È nostra intenzione mostrare il funzionamento della classe Security, nel caso in cui siano presenti più provider installati sulla macchina. Per fare ciò ci serviremo di un esempio a titolo dimostrativo.

Supponiamo di avere due provider installati, prov1 e prov2, dove il primo implementa sia l'algoritmo SHA1 sia l'algoritmo MD5, come supporto al calcolo del digest di un messaggio. Per quanto riguarda, invece, il secondo provider, questo implementa solo l'algoritmo MD5, ma all'interno del file java.security è presente con una priorità maggiore rispetto all'altro. Quando facciamo richiesta di creazione di un digest di un messaggio con algoritmo MD5, la classe Security sarà interrogata per sapere quale provider utilizzare. In questo caso essendo presente l'implementazione dello stesso algoritmo in entrambi i provider verrà selezionato quello con priorità maggiore, cioè prov2. Nel caso in cui, invece si desideri il digest di un messaggio con algoritmo SHA-1 allora la classe Security selezionerà ancora il provider con priorità maggiore, ma poi accorgendosi della mancanza dell'implementazione dell'algoritmo richiesto passerà alla selezione del restante provider, cioè prov1

Se invece volessimo, nel primo esempio, forzare l'esecuzione dell'algoritmo implementato dal provider prov1, dovremmo specificare alla classe Security quale provider andare a prendere.

Avremmo anche potuto specificare un provider non presente nelle lista del file java.security. Questo è possibile invocando il metodo seguendo e passando come parametro il nome del provider:

in questo modo sarà possibile aggiungere a runtime un nuovo provider alla lista di quelli già esistenti, come specificato in precedenza.

Infine c'è da aggiungere che queste operazioni sui provider sono possibili solo se l'applicazione o l'Applet sono considerate fidate e quindi hanno i permessi per compiere tali operazioni.

Consigli utili per scrivere un proprio provider

Come abbiamo già detto in precedenza un provider deve aggiungere a Java un supporto per uno o più algoritmi crittografici. Come il lettore saprà già, ci sono molti provider disponibili che affrontano, in maniera simile, tutto quanto serve per implementare la crittografia in Java. Può capitare ugualmente che una persona o un enete si trovi alle prese con la realizzazione di un provider. Le motivazioni che possono spingere una persona o un ente a ciò sono tante, ad esempio possono essere richiesti in un'applicazione algoritmi che sono poco trattati nelle JCE presenti, per problemi di licenza o costi troppo alti da parte delle JCE presenti, oppure semplicemente per la voglia di provare.

Questo, naturalmente, è un discorso che richiederebbe di entrare molto nel dettaglio di quello che è la struttura di un provider, infatti non si tratta solo di scrivere codice ma anche di rispettare licenze di programmi e diritti su algoritmi, rischiando di esulare da quello che è l'obiettivo di questa tesi.

Per chi fosse interessato, sono disponibili tutte le informazioni in un'apposita guida presente sul sito della Sun Microsystem[15]. In ogni caso, di seguito riportiamo quelli che sono i passi principali affrontati nel riferimento, in modo da dare, ad un lettore interessato, un'idea del lavoro da affrontare:

Comunque per scrivere ed eseguire il provider è necessario implementare la JCE, ed in particolare i seguenti tre package:

A partire dalla versione 1.2.1 della JCE di Sun un provider deve avere un interessante requisito: il provider deve essere approvato dalla Sun Microsystem, la quale deve firmarlo digitalmente. Sfortunatamente il requisito imposto sulla firma limita, il più delle volte, l'utilizzazione della JCE. Ottenere la firma richiede un procedimento lungo e difficile che però esula dall'argomento di questa tesi e perciò non la affronteremo. Per fortuna esistono numerosi provider JCE alternativi, open source, che offrono gli stessi servizi di Sun, ma che siccome sono stati scritti fuori dagli Stati Uniti sono utilizzabili liberamente. Tra questi uno dei più completi è Bouncy Castle[8], che verrà affrontato più avanti in questo capitolo.