Abbiamo già parlato in un altro articolo dell'architettura della crittografia nel linguaggio Java.
Oggi proponiamo un esempio di come poter ottenere un Message Digest da un  testo in chiaro.



import java.io.UnsupportedEncodingException;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import java.util.logging.Level;
import java.util.logging.Logger;

public class Main {

    public static void main(String[] args) {

        try {
            byte[] testoChiaro = "This is a test!".getBytes("UTF8");
            MessageDigest md = MessageDigest.getInstance("MD5");
            //visualizzo il provider utilizzato
            System.out.println("Provider:\n"+md.getProvider().getInfo());
            //cifro il messaggio
            md.update(testoChiaro);
            System.out.println("Message Digest:\n" + new String(md.digest(), "UTF8"));
        } catch (NoSuchAlgorithmException ex) {
            Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
        } catch (UnsupportedEncodingException ex) {
            Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
        }

    }
}

JCA-Java Criptography Architecture

Abbiamo già parlato di crittografia per quanto riguarda il linguaggio Java.
Ora parleremo di JCA, il framework di base per la crittografia, è costruito intorno alla J2SA(Java 2 Security Architecture).
Si basa sui principi della Criptography Service Provider Architecture:

• indipendenza dell'implementazione(Algorithm indipendences)
• interoperabilità
• estendibilità

L'indipendenza dell'implementazione o Algorithm indipendences utilizza classi astratte di tipo "engines" che dichiarono le funzionalità di un dato tipo di algoritmo crittografico, impiega poi classi "provider" che implementano un certo insieme di funzionalità crittografiche per un Criptographic Service Provider(CSP).

In genere un'applicazione crittografica può richiedere genericamente un'implementazione di un dato algoritmo senza curarsi di quale provider lo fornisca, infatti una volta installati possono coesistere uno o più CSP anche di differenti produttori, il provider di default si chiama SUN ed è integrato nel JDK.
In Pratica:

• Engine class: definiscea crypto service in an absract class senza implementazione
• Service provider interface: provvede ad una crypto interface dell'applicazione via "engine"

Cryptographic service provider: ogni classe "engine" ha una corrispondente SPI che definisce esattamente un crypto method implementato da CSP. 

Principali engine class:

• KEY: defisce le funzionalità condivise da chivi "opache"
• KEY SPEC:definisce una chiave di tipo trasparente
• KeyFactory:prende una chiave di tipo KEY "opaca" o "trasparente"
• KeyPairGenerator:genera una coppia di chiavi assimentriche
• AlgorithmParameters: gestisce i parametri di un algoritmo
• AlgorithmParametersGenerator:genera i set di parametri di un algoritmo
• MessageDigest:calcola l'hash di dati specifici
• SecureRandom:genera numeri causali o pseudo casuali
• Signature:appone e verifica la firma digitale
• CertificateFactory:crea e revoca certificati di chiavi pubbliche
• KeyStore:crea e gestisce un database(Keystore) di chiavi e certificati sicuri.

Il provider SUN include:un'implementazione dell'algoritmo DSA (Digital Signature Algorithm), un algoritmo MD5 e SHA-1 di MessageDigest, un KeyPairGenerator per DSA, AlgorithmParameter ed AlgorithmParameterGenerator per DSA, un KeyFactory per DSA, un CertificateFactory  per certificati X.509 e per CRLs, un'implementazione del KeyStore proprietario JKS.

Le estensioni JCE(Java Cryptographic Extension) e JSSE(Java Secure Sockects extension) implementano ed estendono le tecniche  crittografiche definite dalla JCA fornendo CSP alternativi a SUN.
Invece i restanti set di package offrono funzionalità di sicurezza aggiuntive e sono quindi complementari alla JCA.

• JAAS:servizi di autenticazione, amministrazione e autorizzazione
• CertPath:gestione dei certificati e catene di certificati
• JGSS:meccanismi di comunicazione generici e specifici per beyberos v5

JCE

Java Cryptographic Extension

La JCE ha il compito di fornire  un'implementazione completa delle funzionalità di cifratura e decifratura dichiarate dalla JCA.
JCE offre supporto:

• cifrari simmetrici a blocco e a flusso
• cifrari asimmetrici
• cifrari con password

applicazioni su:

• Data
• I/O streams
• Serializable Object

in meccanismi quali:

• MAC(Message Authentication Code)
• KeyGenerator/KeyAgreement

JCA-Message Digest

Java Criptography Architecture offre la classe "engine" MessageDigest astratta che provvede a fare da design per offrire la funzionalità di cifratura di messaggi sicuri con algoritmo SHA-1 o MD5, questo messaggio criptato è detto: Message Digest o semplicemente indicato con MD.

Un message digest è un messaggio in chiaro di lunghezza variabile tradotto in un messaggio "sicuro" di lunghezza fissa.

Un MD ha due proprietà:

1. se x->h(x), e y ed x sono diversi, non si può avere h(y)=h(x)
2. non si possono avere collisioni 

Ad esempio in Internet è utilizzato MD5-128 bit che non garantisce nulla per quanto riguarda la collisione.
Le API Java sono:

• MessageDigest.getInstance("MD5")  per ottenere un MD
• .update(plaintext) per calcolare MD con il testo in chiaro
• .digest() per leggere il message digest

JCA-Message Authentication Code(MAC)

MACs usa una chiave per preservare l'integrità del messaggio.JCA supporta gli algoritmi:

• HMAC/SHA-1
• HMAC/MD5

Le API Java sono:

• KeyGenerator.getInstance("HMACMD5") e .generateKey() per generare la chiave
• Mac.getInstance("HMACMD5") crea un oggetto MAC
• .init(plaintext) e .doFinal() inizializza un MAC object
• .update(plaintext) e .doFinal() calcolano il MAC object con testo in chiaro

Java Cryptography

Il linguaggio Java divide la sicurezza in due livelli:

• un livello basso di sicurezza JVM Layer:garbage collection,class file verification, etc.
• un livello alto di sicurezza Application Layer:sandbox, security policy, security APIs, etc.

Fino a JDK 1.4 esistevono package esterni per creare applicazioni sicure:

• JCE (Java Cryptography Extension)
• JSSE (Java Secure Socket Extension)
• JAAS (Java Authentication and Authorization Service)

Dalle versioni successive a JDK 1.4 sono state aggiunte due nuove funzionalità:

• JGSS (Java General Security Service)
• CertPath API (Java Certificate Path API)

JVM Layer

JVM Layer

JVM Layer: Java Virtual Machine

• è responsabile dell'indipendenza della piattaforma
• è responsabile della macchina astratta
• ha un set di istruzioni
• può manipolare la memoria a runtime
• non interpreta il codice Java ma il bytecode
• il bytecode è memorizzato nei class file

JVM Layer: Class file structure
Il class file è composto da:

• da una "magic" costant OxCAFEBABE
•  version number
• Access flag
• "costant pool"
• Informazioni sulla classe corrente(nome, superclasse, etc.)
• Informazioni a riguardo i metodi e le proprietà di una classe
• Informazioni di Debbugging

JVM Layer: The Class File Verification

• Verifica di base della struttura della classe
• Verifica base del "looks" delle:
  
  referenze di classe
  referenze dei campi
  referenze sei simboli
• Verifica del bytecode
• Verifica effettiva:
  
  referenze di classi
  accesso e modifica dei campi e metodi chiamati

Application Layer

Application Layer:Class verification

•  Il class loader carica le classi su richiesta
• Riduce la memoria usata
• Enforces type-safety alongside the JVM
• Migliora il tempo di risposta del sistema
• Istanze di classe caricate:
  Primordial/bootstrap class loader
  System class loader
  Application class loader
• Il class loader è chiamato è chiamato dalla JVM
• Il class loader è responsabile di caricare le classi e di dargli un namespace
  
• Associa le classi caricate ad un dominio di protezione

Protection domain

• associa i permessi alla classe per quanto riguarda le locazioni, i certificati, etc.
• è definito dalla security policy
• la security policy di default si riferisce al system-wide policy ed implementa la policy di default per la sandbox 
• policy addizionali sono user-defined
• si possono avere una o più policy security
• tutte le referenze alla security policy sono specificate nel security property file localizzato nella directory di installazione del JDK(o JRE)

Certificate X.509

Lo standard X.509 è stato definito da ITU-T(International Telecommunication Union-Telecommunication) definisce standard per i certificati a chiave pubblica ed un certification path validation algorithm.
Nel sistema X.509 una CA rilascia un certificato che associa una chiave pubblica ad un’identità fisica, e la modalità di controllo è stata approvata dall’IETF(Internet Engineering Task Force) ed è OCSP(Onlice Certificate Status Protocol).
X.509 include anche standard per le implementazioni di CRL(Certificate Revoca te List).
Un certificato X.509 ha la seguente struttura:

Campo	Descrizione	Valore
Version	Specifica la versione del certificato	INTEGER{v1(0),v2(1),v3(2)}
Certificate Serial number	E’ un valore intero univoco assegnato ad ogni certificato rilasciato da una CA.	INTEGER
Certificate Algotithm Identifier for Certificate Issuer’s Signature	Specifica l’algoritmo e la funzione hash usati dalla CA per firmare il certificato	Esempi: md5WithRSA sha-1WithRSA
Issuer	DN della CA che ha creato e firmato il certificato	CN = GTE CyberTrust Global Root OU = GTE CyberTrust Solutions, Inc. O = GTE Corporation C = US
Validity Period	Contiene due date, la data di inizio di validità del certificato e la data di fine validità	19/02/2008 to 19/02/2011
Subject	DN dell’utente del certificato, colui che è il proprietario del certificato e conserva la chiave privata	CN = Microsoft Internet Authority
Subject Public-Key Information	Specifica la chiava pubblica del certificato e con quale algoritno è stata generata	30 82 02 0a 02 82 02 01 00 a8 a5 a1 ab 6f 0d e8 43 1b fa d0 ae 27 a5 d8 00 bd aa 64 89 76 f8 ca .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. d2 3d f5 71 9f 02 03 01 00 01
Issuer Unique Identifier	E’ usato per distinguere univocamente la CA nel caso che il DN (della CA) sia stato riutilizzato	Usually Omitted
Subject unique identifier	E’ usato per distinguere univocamente il proprietario del certificato nel caso che il DN (dell’utente) sia stato riutilizzato	Usually Omitted
Extension	Campi di estensione. Tre categorie: key and policy subject and issuer attributes certification path constraints
Certification Authority’s Digital Signature		sh1, 3d 29 1d b8 ee 22 be e1 33 70 06 f2 ef c6 f9 db dd 03 bb 25

I certificati X.509 hanno utilizzo in:

• SSL
• S/MIME
• object-signing
• e-commerce

Digital certificaties e PKI

Quando si utilizza un sistema crittografico basato sulla chiave pubblica c’è da chiedersi, se è davvero la chiave pubblica del destinatario del nostro messaggio.
Per risolvere questo problema si è ricorso al digital certificates o certificato digitale. Questo certificato firmato digitalmente da una terza parte chiamata Certificate Authority(CA), è un documento che attesta un’associazione tra una chiave pubblica e l’identità di un soggetto.
La CA è l’unica agenzia responsabile per la certificazione delle chiavi pubbliche, dopo la generazione della coppia di chiavi pubblica e privata, l’utente dimostra la sua identità e la CA certifica con la propria chiave privata la chiave pubblica dell’utente.
La PKI(Public Key Infrastructure) ha una struttura gerarchica, ed è composta da:

• Certification Authority (CA)
• Registration Authority (RA)
• Repository
• Archive
• Users

La CA è una terza parte trusted(fidata), rilascia i certificati per l’utente e pubblica questi certificati, rispettando standard internazionali e norme nazionali in materia. Può revocare i certificati e mantiene copie delle chiavi private.
La RA invece verifica il contenuto dei documenti per la CA, e la chiave pubblica di quest’ultima è nota alla CA, una CA può avere più RA.
Il Repository contiene i componenti critici della PKI e LDAP(Lightweight Directory Access Protocol), memorizza e distribuisce i certificati e la lista dei certificati revocati, informazioni sulla PKI, le informazioni contenute non hanno bisogno di essere attendibili sono firmata dalla CA stessa.
Archive permette invece la verifica di firme vecchie, provando che la firma era valida nel momento in cui è stata posta.
Gli Users invece sono i proprietari del certificato che devono mantenere segreta la chiave privata.
In questo tipo di struttura gerarchia se si vuole ottenere un certificato digitale si deve:

1. Generare la coppia di chiavi pubblica/privata.
2. Fornire le chiavi, nome ed informazioni alla RA.
3. La RA convalida le credenziali ed invia la richiesta di certificato alla CA.
4. La CA genera un certificato per la chiave pubblica insieme ad altre informazioni e lo firma con la propria chiave privata.
5. Il richiedente ha così una coppia di chiavi pubblica/privata e la chiave pubblica è certificata.

La CA può revocare un certificato anche se il suo periodo di validità non è ancora scaduto, ma per altre condizioni come potrebbero essere:

• Compromissione delle chiave privata
• Informazioni non più valide
• Compromissione dell’algoritmo

La CA memorizza questi certificati nella CRL(Certificare Revocation List), la CRL può essere distribuita dalla CA nei seguenti modi:

• Modalità pull:download dalla CA quando necessario
• Modalidà push:la stessa CA la invia ad intervalli regolari
• Approccio ibrido: la CA la invia a repository intermedi dai quale si effettua il download quando necessario

I certificati sono generati secondo lo standard X.509 Digital Certificate Standard.

Digital Signature

La digital signature o firma digitale è basata sulla crittografia asimmetrica, essa rappresenta un sistema per autenticare un documento digitale garantendo il non ripudio.
La firma digitale si propone di risolvere tre problemi:

• Integrità, la garanzia che terze parti non abbiano modificato il contenuto del messaggio.
• Non ripudio chi trasmette il messaggio non può negare di averlo fatto.
• Autenticità, l’effettiva provenienza del mittente.

L’applicazione della firma digitale ad un messaggio avviene nei seguenti passi:

Passo 1

Al messaggio da inviare viene applicato un algoritmo di hash. Il risultato dell’applicazione dell’algoritmo ci da una sequenza composta da un numero fisso e univoco di bit chiamato MD(message digest).
Una funzione hash H deve alcune proprietà:

1. Deve essere difficile da invertire(resistente). Sia H(x)=y Є {0,1}n per x Dato y dovrebbe essere difficile trovare un qualsiasi z tale che H(z)=y
2. Resistente alla collisione:Dato x,y dovrebbe essere difficile che H(x)=H(y)

Le funzioni hash più comuni sono:

• MD5 a 128-bit, non garantisce la non collisione.
• RIPEMD a 160-bit, è una variante di MD5.
• SHA-1 a 160-bit anche questo non garantisce la collisione violata nel 2005, comunque rimane ancora sicura la variante SHA-2 o non si è ancora a conoscenza di attacchi.

Passo 2

Il message digest viene cifrato con la chiave privata del mittente, ed il risultato di questa operazione rappresenta la firma digitale del messaggio.

Passo 3

Il messaggio originale o in chiaro e la relativa firma digitale vengono inviati al destinatario.


Il ricevente per verificare la firma digitale effettua i seguenti passi:

Passo 1

Applica al messaggio ricevuto la stesso algoritmo hash del mittente ottenendo il digest del messaggio.

Passo 2

Utilizzando la chiave pubblica del mittente decifra la firma digitale ottenendo il digest del messaggio.

Passo 3

Confronta i due digest ottenuti e se questi risultano essere uguali, sono garantite:

• Autenticità
• Integrità

Gli algoritmi più comuni sono:

• MD2/RSA
• MD5/RSA
• SHA1/DSA
• SHA2/DSA

Crittografia a chiave pubblica

La crittografia a chiave pubblica o asimmetrica si basa sull’uso di una coppie di chiavi:

K=(K+,K-) 

La chiave pubblica K+ si diffonde ed è utilizzata per crittografare il messaggio, mentre la chiave privata K- viene tenuta segreta ed è utilizzata per decodificare il messaggio. Si codifica con una delle chiavi e si decodifica con la chiave privata K-. E’ estremamente difficile dedurre K- da K+, ed inoltre le due chiavi sono matematicamente correlate tra di loro.
La crittografia asimmetrica preserva la confidenzialità e l’integrità ma non l’autenticità.

La chiave pubblica K+ può essere distribuita anche attraverso un canale “insicuro” come Internet, oppure essere pubblicata su un web site.

Il funzionamento è semplice, come si potrà notare dalla figura precedente, se Alice vuole inviare un messaggio a Bob, deve utilizzare per criptare un messaggio M, la chiave pubblica di Bob K+, spedisce questo messaggio a Bob, il quale con la sua chiave privata K- decodifica il messaggio. Lo stesso processo è uguale ed invertito nel caso in cui è Bob a volere inviare un messaggio ad Alice.

La crittografia asimmetrica, fonda su un solido principio matematico:l’uso di un problema complesso. Ovvero l’esecuzione di una funziona matematica facile da eseguire, ma difficile da invertire.
Alcuni algoritmi sono:

• Diffie-Hellmann (Logaritmo discreto)
• RSA (Fattorizzazione di interi con numeri primi grandi)
• EIGamail (Logaritmo discreto)
• EC-Elliptic Curve (Logaritmo discreto)

Gli algoritmi asimmetrici sono caratterizzati dall’essere onerosi dal punto di vista computazionale e quindi “lenti”. Questo inconveniente può essere attenuato o eliminato utilizzando una SessionKey, in questo caso riferendoci alla figura di cui sopra, se Alice vuole inviare un messaggio a Bob crea prima una chiave simmetrica, ad esempio con l’algoritmo DES: KDES. Cripta KDES con la chiave K+ pubblica di Bob e la invia a Bob.
Bob decripta il messaggio ricevuto con la propria chiave privata, ottiene quindi KDES e per le prossime comunicazioni verrà utilizzata questa chiave.

Crittografia a chiave privata

La crittografia a chiave privata o simmetrica preserva la confidenzialità.

Esiste una sola chiave utilizzata sia per la codifica che per la decodifica delle informazioni. La chiave viene scambiata in segreto tramite un canale sicuro, solo i due partecipanti alla conversazione conoscono la chiave.
Come è possibile vedere dalla figura di cui sopra, la crittografia a chiave privata funziona criptando un testo in chiaro che chiamiamo X utilizzando la chiave segreta K, otteniamo in questo modo un testo crittografato che chiamiamo Y=A(K,X) dove A è l’algoritmo scelto per criptare il messaggio. Il messaggio Y viene inviato al destinatario, il quale può decodificarlo utilizzando lo stesso algoritmo e la stessa chiave segreta con il quale Y è stato crittografato ottenendo così di nuovo il messaggio in chiaro X=A(K,Y).
Alcuni algoritmi per la crittografia simmetrica sono:

• DES(Data Encryption Standard)
• TripleDES
• AES(Advanced Encryption Stadard)
• RC2, RC4, e RC5 
• Blowfish 
• PBE

L’algoritmo DES è insicuro, mentre il TripleDES è un’evoluzione del DES considerato sicuro. L’algoritmo AES è invece considerato sicuro ed è adottato anche dal governo degli Stati Uniti d’America.
In generale la robustezza di questi algoritmi e di tutti gli algoritmi per la crittografia a chiave privata è strettamente legata alla lunghezza del testo che compone la chiave privata, ovvero più è lunga la chiave privata tanto più difficile è la decodifica del messaggio in tempo utile.

Crittografia

La crittografia è una scienza antica che si occupa di cifrare i messaggi tra un mittente ed un destinatario rendendo questi illeggibili a intrusi e malintenzionati. La crittografia in realtà è parte di una scienza più ampia detta crittologia, che oltre a comprendere la crittografia stessa comprende anche la crittoanalisi che si occupa di intercettare i messaggi di una connessione cifrata e tradurli. Gli algoritmi di crittografia possono essere divisi in due gruppi:

• A chiave privata o simmetrici
• A chiave pubblica o asimmetrici

Negli algoritmo a chiave privata, la chiave utilizzata per la codifica e decodifica dei dati è la stessa, mentre la crittografia a chiave pubblica o asimmetrica ha due chiavi una pubblica distribuita a tutti, l’altra privata che è tenuta segreta dal proprietario.
Il processo di crittazione dei messaggi è il processo per portare un messaggio in chiaro a testo crittografato, basato su una chiave e una funzione matematica.