Anteprima
Vedrai una selezione di 3 pagine su 9
Domande di Teoria di Sicurezza dell'Informazione Pag. 1 Domande di Teoria di Sicurezza dell'Informazione Pag. 2
Anteprima di 3 pagg. su 9.
Scarica il documento per vederlo tutto.
Domande di Teoria di Sicurezza dell'Informazione Pag. 6
1 su 9
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

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

Dettagli
Publisher
A.A. 2017-2018
9 pagine
1 download
SSD Ingegneria industriale e dell'informazione ING-INF/05 Sistemi di elaborazione delle informazioni

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher piscoTech di informazioni apprese con la frequenza delle lezioni di Sicurezza dell'Informazione M e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli Studi di Bologna o del prof Montanari Rebecca.