Java Cryptography Architecture - JCA

Java Cryptography Architecture - JCA

La Java Cryptograghy Architecture [4] rappresenta l'insieme di tutte le classi, presenti nello standard JDK, che sono rivolte alla gestione della crittografia. La JCA fa parte dell'ambiente runtime di Java; l'idea di progetto che sta dietro a questa architettura è quella di fornire una piattaforma in cui le API presenti siano indipendenti dall'applicazione, e anche interoperabili. Inoltre l'obiettivo è anche quello di rendere i servizi il più possibile indipendenti ed estendibili in futuro. L'utente non deve preoccuparsi di quelli che sono i concetti base di un algoritmo di crittografia o di quella che può essere la sua implementazione, ma semplicemente di adoperare la classe giusta per l'operazione desiderata.

Figura : Architettura della JCA per il JDK 1.2 - tratto da [1]

Le API della sicurezza Java sono una componente importante del linguaggio, tanto da riuscire ad offrire un'implementazione sia a basso che ad alto livello, delle funzionalità crittografiche presenti. Tutte le API relative alla crittografia sono contenute nel package java.security e nei suoi sotto-package.

La prima versione delle API, nel JDK 1.1, prevedeva solo l'introduzione della piattaforma per il supporto a poche funzioni crittografiche; le uniche funzionalità implementate erano per la firma digitale e il calcolo del digest di un messaggio.

Nell'ultima versione dello standard, cioè quella di Java 2, l'architettura della piattaforma crittografica è stata notevolmente ampliata, introducendo l'infrastruttura per la gestione e il supporto dei certificati X.509 e rendendo il controllo degli accessi molto più accurato, flessibile ed estendibile.

L'indipendenza degli algoritmi è raggiunta grazie alla definizione di tipi di crittografia detti "engines", e alla definizione di classi, chiamate "classi engines" che dichiarano le funzionalità di un particolare tipo crittografico.

L'aspetto più significativo dell'organizzazione architetturale comunque è rappresentata dal provider, il quale permette l'implementazione di molteplici e interoperabili funzionalità crittografiche.

I provider, riferiti anche con il nome di Cryptographic Service Provider, sono gli artefici della realizzazione dell'interoperabilità della piattaforma. Forniscono package o insiemi di package che implementano uno o più servizi crittografici. Il vantaggio di questa organizzazione della piattaforma è che ciascuna implementazione può interagire con le altre senza che si abbiano problemi di compatibilità tra provider; quindi, ad esempio, un generatore di chiavi può essere implementato tramite un provider, mentre le chiavi prodotte potrebbero essere utilizzate in funzionalità che sono implementate da un altro provider ancora. Un provider può essere installato sia dinamicamente, tramite opportune chiamate all'interno del codice, oppure staticamente, tramite installazione di alcuni file sulla macchina, in apposite posizioni note all'ambiente runtime di Java. Ogni provider ha un proprio fornitore che ha il compito di fornire tutto il necessario per il suo funzionamento, oltre ad un eventuale descrizione del funzionalità svolte. Una volta installati, sulla stessa macchina possono coesistere ed anche interoperare diversi provider anche di diversi produttori.

Cryptographic Service Provider

Nel JDK 1.1, un provider poteva contenere le funzionalità per la firma digitale, la generazione del digest di un messaggio e la generazione di coppie di chiavi. Con lo standard Java 2 sono stati aggiunti cinque tipi di servizi: produttore di chiavi, gestore e produttore di keystore, gestore dei parametri degli algoritmi, generatore dei parametri degli algoritmi e produttore di certificati. 

La versione standard della Sun Microsystem per l'ambiente runtime di Java viene fornita con un provider di default, chiamato SUN. Questo provider è integrato nella versione attuale del JDK. Ambienti runtime di Java di altri fornitori potrebbero non supportare gli stessi provider di default. I package del provider SUN includono l'implementazione per molte funzionalità di crittografia classica, come l'algoritmo DSA per la firma digitale e per la creazione delle coppie di chiavi, gli algoritmi MD5 e SHA-1 per il calcolo del digest, l'implementazione di un algoritmo di generazione di numeri pseudo-random, SHA1PRNG, e l'implementazione degli algoritmi per la gestione dei certificati e delle catene di certificati. Come è facile notare, non tutte le funzionalità della crittografia sono implementate dal provider SUN, ed inoltre non tutte le funzionalità fornite sono completamente sviluppate. Questo fatto ha portato alla Java Cryptography Extension (JCE) .

Durante le operazioni di crittografia è possibile specificare, per un'istanza di una classe, un provider particolare oppure lasciare che sia la Virtual machine a determinare il provider da utilizzare per il motore sottostante.

Il funzionamento della JCA è gerarchico, cioè la JCA delega le chiamate delle varie classi al motore interno, il quale deve estendere la Service Provider Interface (SPI) per la classe specifica. Sia la classe istanziata dall'utente che la SPI relativa sono classi astratte, mentre la classe estesa dal provider sarà una classe concreta e sarà la stessa che eseguirà l'operazione vera e propria. Quindi se si vuole calcolare un digest di un messaggio non specificando il provider, l'utente invocherà una chiamata alla classe opportuna, la quale delegherà al rispettivo SPI il compito di definire il provider. La scelta del provider viene effettuato in base all'algoritmo richiesto e ai provider installati.

Accesso alla JCA

Proprio per l'organizzazione gerarchica della JCA e per rispettare la specifica di indipendenza della piattaforma molte delle classi presenti in JCA sono astratte. Questo implica che se si istanzia un oggetto di quella classe non lo si farà con il classico new, ma facendo una chiamata al metodo getInstance(). Come argomento del metodo, generalmente viene specificato l'algoritmo richiesto; nel caso in cui non venga specificato il provider da utilizzare, questo sarà anche l'unico parametro, altrimenti sarà presente anche un parametro per il nome identificativo del provider scelto.