vuoi
o PayPal
tutte le volte che vuoi
Sistema della fiducia con CA e con PGP
In un sistema a CA si ha un ente centralizzato che rilascia e gestisce i certificati, questo permet-
te di avere la fiducia e le garanzie sufficienti per permettere un meccanismo di firma digitale con
valore legale. PGP al contrario è decentralizzato, basato su uno scambio di chiavi con passaparo-
la tra utenti per cui non può garantire la firma con valore legale.
Quando viene fatta l’associazione tra classi e domini di sicu-
rezza? Quando due classi sono associate allo stesso dominio?
Quando è meglio far fare l’associazione dominio-diritti al Secu-
reClassLoader o all’AccessController e perché?
Al momento della defineClass() ogni classe viene associata dal suo defining Class Loader (che
sarà un SecureClassLoader) a un dominio di protezione sulla base del proprio CodeSource, cioè il
firmatario del codice e la sua provenienza, quindi a CodeSource uguale corrisponde stesso domi-
nio.
Per garantire che eventuali modifiche ai permessi siano sempre riflesse sull’applicazione e per
permettere nelle versioni più recenti di avere permessi legati all’utente occorre che l’associazione
dominio-permessi sia lazy e volatile cioè il caricamento avvenga al momento della verifica dei
permessi e sia distrutto subito dopo.
IPSec: procedimenti per creare pacchetto, che differenze ci
sono in ricezione in relazione con SSL e perché IPSec è più
performante?
Partendo dal pacchetto originale viene innanzitutto aggiunto l’header IPSec per AH/ESP conte-
nente i dati della SA corrispondente come il SPI e il numero di sequenza del pacchetto. Nel caso
dell’header di AH è presente un campo per l’autenticatore, calcolato su tutto il pacchetto esclu-
dendo i campi mutevoli come il TTL che per il calcolo sono impostati a 0. Nel caso di ESP è inve-
ce presente un campo per il padding usato nella cifratura.
4 di 9
IPSec utilizza un modello Encrypt then Authenticate mentre SSL un Authenticate then Encrypt,
perciò IPSec risulta più performante in quanto si può prima verificare l’autenticatore e in caso non
sia valido scartare il pacchetto e quindi non eseguire la decifrazione, SSL invece è sempre obbli-
gato a decifrare per poter verificare l’autenticatore.
PGP in generale
PGP è un modello di gestione delle chiavi distribuito in cui le chiavi pubbliche di ogni utente
sono distribuite per passaparola fra gli utenti e le chiavi pubbliche degli altri sono raccolte in un
opportuno portachiavi, ogni utente avrà poi anche un secondo portachiavi che contiene le proprie
chiavi private salvate come entry di:
• Chiave privata cifrata con una passphrase
• Chiave pubblica
• Identificatore della chiave pubblica
• Identificatore dell’utente per la chiave
• Momento della generazione
Il modello permette lo scambio di email e file sfruttando un cifrario simmetrico la cui chiave di
sessione è scambiata con un cifrario ibrido sfruttando la chiave pubblica di ogni destinatario. È
quindi garantita autenticazione, integrità e riservatezza, usando anche funzioni di compressione e
compatibilità.
La compatibilità si rende necessaria per rendere il modello interoperabile con molti programmi di
posta che sono in grado di riconoscere solamente una codifica ASCII a 8 bit e non quella a 6 bit
usata nel flusso binario, questo provoca un aumento delle dimensioni dei messaggi, compensato
da una funzione di compressione posta prima delle normali operazioni di cifratura per ridurre ulte-
riormente le ridondanze del messaggio e dopo le normali operazioni di firma per far sì che la firma
sia sul messaggio originale e non sulla sua compressione, permettendo quindi di evitare di dover
salvare anche il compresso per verificare in un secondo momento la firma.
Ogni messaggio scambiato ha quindi l’identificatore della chiave pubblica del mittente, la chiave
pubblica
di sessione cifrata con la chiave di ogni destinatario e l’identificatore della relativa chiave
pubblica, la firma sui primi due byte del messaggio e la firma sull’intero messaggio. Questo siste-
ma a identificatori permette di ridurre le dimensioni del messaggio stesso evitando di inviare tutti i
2048 bit della chiave. L’identificatore è composto dai 64 bit meno significativi della chiave pubbli-
ca che risultano essere raramente duplicati, per evitare comunque collisioni si fa prima la verifica
della firma su solo due byte e se questa va a buon fine, cioè è stata identificata la corretta chiave
pubblica del mittente, si procede a verificare l’intero messaggio.
Protocolli di identificazione
L’identificazione è un processo svolto in tempo reale che identifica una o entrambe le parti per
un dato istante di tempo, se si vuole mantenere per un periodo di tempo occorre poi ricorre all’au-
tenticazione dei messaggi.
Questi protocolli si possono basare su conoscenza di una password, possesso di una carta
magnetica o conformità di dati biometrici o comportamentali e sono svolti 3 passaggi (previa regi-
strazione iniziale in cui viene scambiato il termine di paragone per permettere l’identificazione):
dichiarazione dell’identità da parte dell’identificando, interrogazione e dimostrazione dell’identità. I
protocolli risultano quindi soggetti a diversi attacchi in cui il segreto può essere intercettato o rac-
colte abbastanza informazioni da dedurlo.
In generale il protocollo deve evitare quindi la trasferibilità (il verificatore non deve poter imper-
sonare la sorgente presso un’altra entità) e l’impersonamento (una terza parte non deve potersi
spacciare per la sorgente) anche se vengono ascoltati più scambi di identificazione e la terza par-
te viene coinvolta in uno o più.
L’identificazione può essere passiva con sempre la stessa prova d’identità o attiva con una pro-
va sempre diversa, entrambe le modalità permettono l’identificazione unilaterale, ma solo quella
attiva permetta la mutua. I protocolli passivi sono molto suscettibili ad attacchi per replica in cui il
segreto viene intercettato e riutilizzato, è inoltre possibile tentare un attacco di forza bruta con di-
zionario, dato che spesso le chiavi non sono perfettamente aleatorie, è quindi bene limitare il nu-
mero di tentativi possibili.
Gli scambi attivi possono essere basati su one-time password sfruttando un segreto iniziale e
una funzione unidirezionale applicata più e più volte a questo, il segreto non viene mai scambiato
per cui risulta perfettamente sicuro e anche se una password viene intercettata non potrà mai es-
sere riutilizzata. 5 di 9
Un’altra modalità di identificazione attiva è quella a challange-response in cui viene inviato un
numero casuale e l’identificando è tenuto a farne l’hash usando un segreto condiviso, decifrarlo o
firmarlo, si ha quindi la necessità di un PRNG crittograficamente sicuro e l’accortezza di usare i
numeri una sola volta per evitare attacchi con replica, tuttavia nel caso d’identificazione mutua
con due sfide di questo tipo si ha il rischio di attacchi di reflection e interleaving in cui l’attaccante
rispettivamente usa una seconda sessione d’identificazione per terminare correttamente la prima
o ripropone i messaggi di una parte all’altra e viceversa per autenticarsi presso entrambe.
Occorrono quindi soluzioni per evitare questi problemi: per la reflection il protocollo non deve
essere simmetrico e contenere l’identificatore del destinatario in ogni messaggio mentre per l’in-
terleaving occorre correlare fra loro i messaggi con numeri casuali fortemente legati.
Un’ultima modalità sono i protocolli a zero knowledge usati in sistemi di block chain encryption
in cui si usano sfide diverse ogni volta senza mai coinvolgere il segreto, sono estremamente com-
plessi e molto robusti.
Funzione hash: funzionamento con 2 messaggi di differente
lunghezza 700 bit e 1024 bit con blocchi di 256 bit
Nel secondo caso si hanno 4 blocchi della dimensione esatta, non c'è quindi necessità di fare
padding per poter eseguire la compressione iterata, nel primo caso invece il 3° blocco non risulta
completo e deve essere completato con un padding opportuno per garantire robustezza della
funzione.
Java JDK 1.2: strutture per gestire le politiche
Le politiche, cioè la corrispondenza fra dominio di protezione e permessi, sono gestite dall’unico
oggetto Policy correntemente attivo nella JVM. Quest’oggetto si occupa di restituire i permessi
disponibili sulla base del CodeSource (e del Principal nelle versioni più recenti) assegnato al do-
minio di protezione corrente.
Cifrari a blocchi: modello di Feistel
La rete di Feistel è il modello su cui tutti i cifrari a blocchi (ad eccezione dello standard attuale
AES) si basano per garantire la sicurezza computazionale sulla base di confusione e diffusione.
La rete prevede di spezzare ogni blocco in due parti, sottoporre la seconda a una funzione di
sostituzione per dare confusione, sommare il risultato in XOR con la prima parte e quindi portare
la seconda parte inalterata come prima e il risultato dello XOR come seconda per dare diffusione
attraverso una tecnica di trasposizione. Questo processo viene reiterato più volte, ognuna usando
una chiave diversa per la funzione di sostituzione, ognuna ottenuta da una chiave principale.
RSA: da cosa è garantita la sicurezza? Perché il messaggio
deve essere più piccolo del modulo? e
La sicurezza di RSA è garantita dalla difficoltà del problema della radice -esima e della fattoriz-
zazione di un numero che è il prodotto di due numeri primi molto grandi.
Poiché si lavora in algebra modulare occorre che per garantire la biunivocità della trasformazio-
ne tra cifrato e testo in chiaro, quest’ultimo sia strettamente minore del modulo, altrimenti si incor-
re nel problema di più testi in chiaro diversi corrispondenti allo stesso cifrato.
Java: a cosa serve il SecureClassLoader?
Si occupa di associare ogni classe caricata al suo corrispondente dominio di protezione sulla
base del CodeSource, cioè l’origine del codice e il suo firmatario.
Algoritmi di firma digitale asimmetrica: scopi e principali si-
stemi
L’obiettivo della firma digitale è garantire l’autenticazione del messaggio con non ripudio da par-
te dell’autore in quanto l’operazione di firma viene fatta utilizzando la chiave privata che solo l’au-
tore deve conoscere. A seconda di come la corrispondente chiave pubblica viene garantita la fir-
ma può avere o meno valore legale garantendo quindi che tutti possano verificare il documento,
sia reso inalterabile, non ripudiabile e che la fir