L'architettura della JCE

L'architettura della JCE

Nei paragrafi precedenti abbiamo potuto vedere quale sia la struttura architetturale della JCA. Ai più attenti non potrà essere sfuggito il fatto che il provider fornito di default dalla Sun Micorsystem, appunto SUN, presenta alcune lacune, per non dire che manca totalmente, nella gestione dell'algoritmo RSA e nella trattazione dei cifrari, indispensabili per effettuare operazioni di cifratura e decifratura. Per riempire tale vuoto lasciato nella JCA, la Sun Microsystem ha dotato tutto l'ambiente delle JCE cioè di estensioni aggiuntive alla crittografia della JCA. Queste estensioni quindi aggiungono quei servizi mancanti di cui parlavamo precedentemente. È stato necessario mettere queste estensioni separatamente dalla JDK perchè al momento della creazione della piattaforma i limiti presenti sull'esportazione di alcuni standard ne hanno impedito l'introduzione.

Le estensioni JCE implementano ed estendono le tecniche crittografiche definite dalla JCA, fornendo provider alternativi a "SUN". Per inciso la JCE ha il compito di fornire un'implementazione completa delle funzionalità di cifratura e decifratura dichiarate dalla JCA. La JCA e la JCE sono molto simili tra loro, basandosi sugli stessi principi di progetto. In più la JCE offre supporto per i cifrari simmetrici a blocchi e a flusso, per i cifrari asimmetrici e per quelli con password; infine offre supporto anche per i meccanismi di MAC[1], per il Key Generator  e il Key Agreement

Le classi che costituiscono la JCE si differenziano da quelle della JCA per via di una diversa dislocazione all'interno della piattaforma Java. Infatti le API della JCE sono tutte raccolte sotto il package javax.crypto e i rispettivi package sottostanti.

Le classi principali sono le seguenti:

Cipher: per la cifratura e decifratura di dati mediante uno specifico algoritmo;

CipherInputStream e CipherOutputStream: incapsulano il concetto di canale sicuro, combinando tra loro oggetti Cipher con oggetti InputStream e OutputStream per gestire direttamente la cifratura e decifratura direttamente durante la comunicazione;

KeyGenerator: genera chiavi sicure per algoritmi simmetrici e per lo scambio Diffie-Hellmann (DH);

SecretKeyFactory: per la conversione di una chiave di tipo Key in chiavi opache o trasparenti;

SealedFactory: per la costruzione di oggetti serializzabili che incapsulano il cifrario semplificando la memorizzazione ed il trasferimento di oggetti cifrati;

KeyAgreement: per la gestione dei protocolli per concordare una chiave;

Mac: offre le funzionalità di MessageAuthentication Code.

Con la nuova versione della piattaforma di Java, il JDK 1.4, la Sun Microsystem ha dotato il linguaggio di un nuovo provider, il cui nome è "SunJCE".  Il package di questo provider include molte implementazioni e algoritmi che non verranno affrontati in questa tesi, oltre ai seguenti argomenti, invece, inerenti a quelli che sono gli argomenti affrontati:

un'implementazione degli algoritmi di cifratura DES, TripleDES e Blowfish, in diverse modalità[2]: ECB, BCB, CFB, OFB e PCBC;

un'implementazione di MD5 con DES-CBC PBE[3] definito in PKCS#5 ;

una SecretKeyFactory per la conversione bidirezionale tra oggetti "opachi" DES, TripleDES e PBE e un "Key material" trasparente;

un'implementazione dello schema di padding[4] definito in PKCS#5.

Tra gli altri provider esistenti, uno che merita una nota particolare, anche perchè direttamente utilizzato per l'implementazione della tesi, è il package Bouncy Castle, il più completo provider di JCE e in licenza gratuita. Questo package offre molti servizi crittografici; tra questi, fornisce il supporto per i seguenti algoritmi:

Blowfish;

DES e DESede, che equivale al TripleDES della SunJCE;

IDEA;

RC2, RC4, RC5,RC6;

Rijndael, che equivale a AES di SunJCE;

Skipjack e Twofish;

RSA, DSA, Diffide-Hellmann;

MD2, MD5, SHA-1 e RipeMD160.

Inoltre fornisce la possibilità di leggere certificati in formato X.509, sia per la versione 2 che per la versione 3, come avviene all'interno di JCA con la classe java.security.cert.CertificateFactory. Quello che rende particolare questo aspetto, comunque, è la possibilità di leggere sia il formato di codifica PEM[5], sia quello DER .

La grossa limitazione di questo package è la scarsa documentazione fornita, che ne rende complicata la comprensione e l'utilizzo.