Obiettivi della sicurezza (!!!) 🟩
Vogliamo creare delle reti che abbiamo certe garanzie di sicurezza, soprattutto:
- Confidenzialità, non vorremmo che il nostro messaggio sia intercettabile e leggibili da persone intermedie
- Integrità: non vogliamo che messaggi possano essere cambiati senza intervento del sender
- Autenticazione: vorremmo sapere con chi stiamo parlando, e vorremmo essere sicuri che non stiano mentendo sull’identità.
- Sicurezza operativa(Availability): vorremmo essere in grado di poter continuare a fornire il servizio (quindi non sia possibile dossare, o installare malware che modifichino il comportamento del servizio).
Questi sono stati trattati un po’ in Theoretical Notions of Security.
Questi principi possono essere messe in pratica con specifiche politiche nella fase di invio dei messaggi, implementate nei vari livelli o firewall per poter identificare tentativi di intrusione.
Come vengono raggiunti questi obiettivi
Vedremo in seguito che il primo obiettivo viene raggiunto senza molti problemi utilizzando la crittografia, mentre le altre due con le funzioni di hashing. Il quarto con la creazione di protocolli solidi.
Un principio di sicurezza 🟩
La sicurezza del messaggio non dovrebbe essere basato sull’algoritmo utilizzato per codificare, ma solamente sull’utilizzo della chiave.
Il primo è molto facile da recuperare, o farci reverse engineering, ne abbiamo parlato qui in breve Classical Cyphers#On security of cipher
Tipologie di attacchi (!!) 🟨
Se è possibile l’attaccante può avere moltissimi vettori di attacchi che possono incrinare i principi di sicurezza che abbiamo enunciato sopra
- eavesdrop: spiare la conversazione (eventualmente rubando password e dati)
- Impersonation: impersonare un altro soggetto (o la macchina di un soggetto).
- Hijacking dirottare una sessione in corso, quindi controllare le richieste che fai, magari ti mando su una copia di paypal falsa, o
- Denial of service: negare il servizio agli utenti legittimi, questo sulla sicurezza operativa.
Crittografia
La crittografia diventa una delle tecnologie chiave per poter garantire i principi di sicurezza.
Alcune tipologie di cifrari simmetrici 🟩
Approfonditi in Block Ciphers che solitamente sono utilizzati negli scambi di messaggi simmetrici. Elenco qui alcuni cifrari classici:
- Cifrario mono-alfabetico (sostituzione) (come codice cesare, in cui c´è una mappatura per ogni singola lettera ad altra lettera).
- Cifrario poli-alfabetico (in cui la criptazione dipende anche dalla posizione).
- Cifrario a blocchi, come DES, AES etc.
Importante diventa anche l’hashing, che serve un sacco per poter mantenere l’integrità del messaggio.
Il problema principale di questo metodo è lo scambio delle chiavi, che dovrebbe essere sicura anche questa parte. Ma solitamente cifrari asimmetrici come RSA risolvono questa parte.
La soluzione ottima per questo metodo è utilizzare un sistema a chiave pubblica PKI per scambiarsi la chiave privata con cui continuare le transazioni da lì in poi.
Tipologie di attacco 🟩
i principali metodi di attacco sono
Cipher-text only attack:
- Forza bruta, in cui cerco la chiave
- Statistical analysis attack (per cercare alcuni pattern che possono esistere per rompere il cifrario).
Oltre a questi ho anche classici attacchi col plain text: chosen-plaintext attack, known plaintext attack, questi mi permettono un pò più informazioni. Se si ha segretezza perfetta come per OTP allora è sicuro, ma è difficile averlo.
Chiavi di sessione e RSA 🟩
Si è parlato di questo ambito per abbastanza, ma non la ritengo molto interessante quindi non la metto, è però molto importante, ma credo tu sappia come funzioni quindi non la scrivo.
Semmai due note sulle chiavi di sessione, è molto semplice, in pratica dato che RSA è molto più lento e costoso (in termini di energia) dei cifrari a chiave simmetrica utilizzo RSA per scambiarmi la chiave con cui faccio la crittazione simmetrica, questa è la chiave di sessione.
da notare che la combinazione di Cifrari simmetrici e asimmetrici riescono a dare forti garanzie (non assolute, perché i cifrari possono essere comunque rotti) di confidenzialità fra le persone.
Autenticazione
Protocollo di autenticazione 🟩
Il libro prova a costruire passo passo un protocollo di autenticazione (cioè una serie di passaggi che finiscono per riuscire ad asserire l’identità con cui si stia comunicando).
- Protocolli di autenticazione passo passo
Dato che lo scambio di password è sempre vulnerabile a playback attack. Ci costruiamo un segreto temporaneo, la nonce, che è una mini specie di challenge utilizzata per convincere dell’identità. Se provo a rimandare la nonce criptata con una chiave privata, allora potrei dire che sono ALICE.
E dato che la nonce è unica, non è vulnerabile a playback attack.
-
Ultimo protocollo con NONCE e PKI
R è la nonce
Nel nuovo sistema con la nonce e il sistema chiave pubblica e chiave privata è ancora vulnerabile a MITM. Dato che Eve può sempre mettersi in mezzo, e praticamente avere in chiaro tutti i collegamenti, dovremmo cercare di identificare in qualche modo la chiave pubblica della identità giusta. (devo prendere la chiave pubblica da un servizio fidato, queste sono le certification autorities, CA).
Certificate authorities 🟩
Sono dei servizi utili ad identificare l’identità di una persona, e sono in grado di giustificare la corrispondenza della chiave pubblica con una certa identità. Generano per te la chiave pubblica E privata. Per protocolli come TLS-SSL protocol sono fondamentali.
Ovviamente la sicurezza dipende dai processi di autenticazione di questa CA (potrebbe chiederti la carta d’identità, o altre informazioni simili), che potrebbe essere vulnerabile anche essa. (nella storia sono anche stati hackerati, quindi hanno molte coppie di chiavi messe a gente falsa).
Integrità del messaggio 🟩
Potremmo utilizzare il PKI, per firmare con la nostra chiave privata (e poi CA per trovare la chiave pubblica per poter verificare il messaggio) in questo modo il nostro interlocutore è sicuro dell’integrità del nostro messaggio e dell’autenticità di chi me lo sta mandando (con le CA).
Se poi si fa la stessa cosa mandando un messaggio già cifrato, allora ho anche segretezza, senza nessun problema!
Ma poi, dato che è molto costoso firmare un messaggio tanto lungo, solitamente si firma solamente l’hash del messaggi originale, quindi rende molto più efficiente il protocollo. ma anche il fatto che in questo modo posso firmare messaggi molto corti! Ho sempre un codice della stessa linguaggio.
Funzione di hashing 🟩
Ci sono un sacco di caratteristiche che dovrebbero tutte le funzioni di hashing soddisfare
- Un digest fisso, di una certa lunghezza.
- Pre-image collision, dovrebbe essere difficile trovare un altro messaggio con lo stesso hash.
- Una proprietà che dovrei soddisfare è il fatto che se cambio un bit di input cambi di molto l’output, ossia ci sia pochissima correlazione fra input e output! (certamente cose lineari non ci piacciono)
Esempio di hash brutto Internet checksum
Un esempio di hash brutto è l’internet checksum perché è molto facile poter creare una collisione!
È in grado di rilevare solamente errori idioti (quelli fatti senza l’intelligenza di un EvE che prova a cambiarti i bit, ma sono abbastanza random!)
Protocollo Mail sicura 🟩
<img src="/images/notes/image/universita/ex-notion/Sicurezza delle reti/Untitled 9.png" alt="image/universita/ex-notion/Sicurezza delle reti/Untitled 9">
<img src="/images/notes/image/universita/ex-notion/Sicurezza delle reti/Untitled 10.png" alt="image/universita/ex-notion/Sicurezza delle reti/Untitled 10">
Praticamente generiamo una chiave simmetrica, poi se vogliamo firmarla e metterci un coso di integrità MAC possiamo farlo, cifriamo con chiave pubblica di bob presa da CA la nostra chiave e mandiamo il pacco con Messaggio privato, magari firmato, e chiave criptata.
Bob riceve e riesce a ricavare tutto quanto possibile per verificare l’integrità del messaggio e comprendere il messaggio!
Protocollo SSL
Trattato un po’ meglio (con altri dettagli) in TLS-SSL protocol Se rendiamo il socket sicuro, rendiamo sicuro tutto quello che c’è sotto, quindi dal livello 4 in giù, vedi Architettura e livelli 1, 2 per dettagli sulla stack. In questo modo le applicazioni possono decidere se utilizzare o meno questo protocollo, dato che è sotto di essa.
-
Slide presentazione ssl
Implementazione Toy-SSL 🟨+
Utilizzando il sistema presentato sopra riescono a cambiare un segreto (come una chiave condivisa per comunicare, ma sarà un robo per creare un set di chiavi, o il vettore di inizializzazione)
Il set di chiavi sono utilizzati per invio direzionale e verifica di integrità direzionale (quindi sono 4 chiavi). Che sono generate dalla Master Key scambiata dalla prima fase.
CARATTERISTICHE PACCHETTI SSL 🟥
Durante il trasferimento dei dati vogliamo avere anche altre caratteristiche che aiutino a mantenere la sicurezza di questo protocollo:
- Numerazione per evitare che eve duplichi pacchetti o simili.
- Verifica di integrità ha un proprio hash MAC (hashato è anche la numerazione a livello SSL).
-
Slide record and sequence numbers
COMMON ATTACKS
Reorder attack, utilizzo le sequence numbers per numerare i records, così sono sicuro che non può riordinare dato che non possiede le chiavi
Replay attack riutilizzo anche in questo momento le nonce
Truncation attack vogliamo anche avere un modo per terminare in modo sicuro la comunicazione, cioè non dovremmo permettere a Eve di terminare la comunicazione per noi. Per fare questo mettiamo anche una parte tipologia di messaggio in ogni MAC. (importante il fatto che è su due versi la chisura!)
Implementazione SSL (skip)
Questo è uguale al toy SSL alla fine… Solo con qualche accorgimento in più, non è importante sta parte
- handshake è leggermente più complicato, c’è anche una fase di autenticazione dell’utente e scelta dell’algoritmo crittografico asimmetrico.
- Alla fine mando anche MAC di tutti i messaggi di handshake per prevenire tampering, come l’eliminazione degli algoritmi più forti per poter provare a bruteforcare meglio.
Record Format
in questo modo si chiamano i pacchetti di SSL, contengono cose simili a quanto abbiamo descritto per il toy SSL
La cosa particolare è che i dati e il mac sono entrambi criptati con la chiave simmetrica che abbiamo derivato prima, in modo simile a quanto fatto dal toy-SSL.
IPsec
Moved to IPSec protocol
Firewalls
Vogliamo cercare di filtrare quello che entra dall’esterno. mentre in generale ci fidiamo di quello che è presente all’interno del firewall (quindi se riesco a controllare una macchina che sia dentro avrei pieno accesso).
Obiettivi dei Firewalls 🟨-
L’obiettimo principale dei Firewalls è proteggere da attacchi esterni, esempi di attacchi potrebbero essere
- Vorrei evitare DoS, ossia permettere senza problemi di aprire delle porte TCP senza andare a chiuderne una.
- Non devo permettere la modifica arbitraria dei dati (che hanno conseguenze penali credo)
- Permettere l’accesso solamente a utenti autenticati
Per fare ciò possono avere a disposizione tre tipologie di firewalls, quelly che iltrato senza avere uno stato quelli con uno stato, ma anche le application gateways (che controllano il contenuto di quello che esce e quello che entra).
-
Slide obiettivi
Access control List 🟨+
<img src="/images/notes/image/universita/ex-notion/Sicurezza delle reti/Untitled 29.png" alt="image/universita/ex-notion/Sicurezza delle reti/Untitled 29">
In sede diversa, questa strategia è stata analizzata anche in analisi delle autorizzazioni nei sistemi operativi. Vedi Sicurezza OS. Vogliamo permettere certe cose, e negarne altre. La ACL è solamente una lista di regole di permessi e negazioni, con specificazione di source, address, protocollo, porta di arrivo e di partenza e flag…
Con queste regole posso implementare senza problemi il Stateless filtering
Stateless/Stateful Packet filtering 🟩
-
Alcuni pacchetti vengono droppati quando ci sono certe informazioni all’interno del pacchetto.
-
Informazione come Source e destination IP
-
Port numbers for TCP or UDP
-
ICMP messages
-
Syn and Ack bits, and maybe more
-
Slides Stateless packet filtering
-
More examples of these
Quando una cosa non ha molto senso da sola, e ha bisogno di tenere conto dello stato della connessione allora abbiamo bisogno di utilizzare uno stateful packet filtering in cui si monitora la storia della connessione TCP una volta che la connessione è stata aperta.
Application gateway and IDS 🟩
Fanno a vedere il contenuto, e gli header dei pacchetti che provengono dall’interno. TODO meglio, il prof ha saltato.
Intrusion detection systems /turn
Vogliamo cercare di capire se siamo sotto attacco, quindi se qualcuno fa port scanning, oppure packet filtering pesante da certe cose, oppure provare a vedere se il contenuto del pacchetto potrebbe essere dannoso.
Demilitarized 🟩
https://doubleoctopus.com/security-wiki/network-architecture/demilitarized-zone/
in pratica è possiamo considerarla come una rete di appoggio per accedere a una rete untrusted esterna, come Internet.
Solitamente in questa DMZ ci mettiamo cose come Email, web servers e cose simili. È una zona quarantinata, cioè per interagire col network interno si passa di nuovo d aun firewall, questo per garantire maggiore protezione della roba interna, solitamente molto più importante.