firma digitale - CESCOT

FIRMA DIGITALE
1
Prologo
• In origine crittografia = confidenzialità
• Diffusione delle reti: nuove funzionalità
– Identificazione: un sistema di elaborazione deve
essere in grado di accertare l’identità di un utente che
vuole accedere ai suoi servizi
– Autenticazione: il destinatario di un messaggio deve
essere in grado di accertare l’identità del mittente e
l’integrità del messaggio
– Firma digitale: funzionalità complessa richiesta
quando mittente e destinatario di un messaggio non si
fidano l’uno dell’altro (reciprocamente). Proprietà
simili alla firma cartacea
2
Firma manuale: proprietà
• La può generare solo una persona e non è
falsificabile
• Non è riutilizzabile (legata al documento su cui
è apposta)
• Il documento su cui è apposta non è
modificabile
• Non può essere ripudiata da chi l’ha generata
3
Firma manuale e firma digitale
• La firma digitale deve soddisfare le
proprietà di quella manuale
• La firma digitale è una stringa di bit e quindi
è facilmente duplicabile/copiabile. La firma
manuale no!!
• Firma manuale e firma digitale sono
fisicamente oggetti di natura
completamente diversa!
4
Digital signatures
• Authentic: Convinces the recipient that the
signer deliberately signed the document
• Unforgeable: Proof that the signer, and no one
else, deliberately signed the document
• Not reusable: Signature part of document and
cannot be moved to another document
• Unalterable: After the document is signed, it
cannot be altered
• Cannot be repudiated: The signer cannot
claim to not have signed the document
5
Digital signatures
• Firmare un messaggio con la chiave privata
K
SK(M)
• Verificare un firma con la corrispondente
chiave pubblica
VK(M)
• Autenticazione: il destinatario di un
messaggio riesce a provare l’identità del
mittente e l'integrità del messaggio.
6
Firma digitale: implementazione
ingenua
• Digitalizzazione della firma manuale, ad
esempio usando uno scanner
• Attacco: Copia e Incolla!!!
7
Osservazioni
• Occorre un cifrario commutativo, cioè
D(C(m)) = C(D(m)) = m
• RSA è commutativo
• Il documento firmato non è indirizzato ad uno
specifico destinatario
• Tutti possono fare la verifica
8
Proprietà del protocollo
• Può generare un firma solo una persona: colui
che conosce kA[priv] cioè A
• Non è riutilizzabile/copiabile/falsificabile: in
quanto è funzione del documento su cui è
apposta
• Il documento su cui è apposta non è modificabile:
in quanto anche la firma andrebbe nuovamente
generata
• Non può essere ripudiata da chi l’ha generata: in
quanto solo conoscendo kA[priv] è possibile
generarla
9
Comments
• Firmare prima dell’inserimento della
crittografia è molto più sicuro.
• Un altro modo potrebbe essere firmare
alla cieca.
• Consideriamo:
– Firma digitale = firma manuale
– Crittografia = busta
– Noi non firmiamo una busta sigillata senza
conoscere il relativo contenuto.
– Avrebbe poco valore giuridico …
10
Protocol based on hash function
A: Sign
• s=D(f(m),kA[priv])
• c=C(m,kB[pub])
• send <A,c,s>
B: Verify
• m*=D(c,kB[priv])
• if f(m*)=C(s,kA[pub])
//sign digest
//encrypt
//decrypt
//verify
– then yes else no
11
Autenticazione
• Identificazione: stabilire l’identità di un utente
• Autenticazione: qualcosa in più di
identificazione
• Mittente spedisce un messaggio al
destinatario
Destinatario autentica il messaggio se:
• identifica mittente
• verifica l’integrità del messaggio (messaggio non
modificato)
12
Message Authentication Code
• Immagine breve (e di lunghezza fissa) del
messaggio che può essere generata da un solo
mittente conosciuto dal destinatario
• Ottenuto attraverso una chiave segreta
condivisa tra il mittente e il destinatario
• Può essere usata per autenticare il messaggio:
identificazione e integrità
• Simile a firme digitali ma senza la proprietà
“non repudiation”
– Qualunque utente che può verificare un MAC è
anche capace di generare MAC per altri messaggi.
13
MAC
14
Esempio di MAC
• Otteniamo un MAC applicando una
funzione hash alla concatenazione di m e
della chiave k
• MAC non è invertibile. Può solo essere
calcolato di nuovo ma non invertito!!!
15
Esempio di autenticazione usando
MAC
A
B
16
Perché?
• L’intruso X non può spedire un messaggio a
B fingendosi A perché non conosce k
⇒IDENTIFICAZIONE
• L’intruso X intercettando (m, f(mk)) non
può modificare m perché non conosce k
⇒INTEGRITA’
17
Autenticazione + Confidenzialità
• A spedisce (Ck(m), f(mk)) a B
• B riceve (u, w)
• B conosce k quindi decodifica u
Dk(u) e risale a m*
• B conosce k quindi può calcolare f(m*k)
• B confronta f(m*k) con w
• Se f(m*k)= w, B conclude che m*=m
(integro) e che il mittente di m è
effettivamente A
18
CERTIFICATES, CERTIFICATION
AUTHORITIES AND PUBLIK-KEY
INFRASTRUCTURES
19
Certificati digitali
• Problema:
• la chiave pubblica con la quale stiamo cifrando
deve appartenere realmente al destinatario
del messaggio
• Si pone il problema dello scambio delle chiavi
(man-in-the-middle attack)
• I certificati digitali vengono usati per evitare
che qualcuno tenti di “spacciarsi” per un’altra
persona sostituendone la chiave pubblica
20
PKI - Certificates
• Un certificato semplifica l’operazione di stabilire se
una chiave pubblica appartiene al suo presunto
proprietario
• La forma in cui una pubblica PKI comunica le
informazioni chiave
• Crea un legame tra l’identità dell’utente e una
chiave pubblica
• Legame vincolante tra una chiave pubblica e
l'identità dell'utente
• Firmato da un emittente fidato
• Funzioni simili ad un certificato fisico
• Evita il man-in-the-middle attacks
21
Physical certificates
22
Distribuzione dei certificati
• Manuale o di persona. Quasi mai
realizzabile in pratica!
(passaporto: distribuzione manuale)
• Generati, custoditi e distribuiti da entità
fidate
– Certificate servers
– Public Key Infrastructures (PKI)
23
Certificate servers
• Database disponibili su rete
• Permettono agli utenti di
– richiedere l’inserimento del proprio certificato
nel database
– richiedere il certificato di qualcuno
24
Public key infrastructure
• Public-key infrastructure (PKI)
– Registration Authority (RA) tipicamente una persona
fisica
– Certification Authority (CA) tipicamente un software
• PKI è una collezioni di servizi e protocolli utili a:
–
–
–
–
Emettere,
Memorizzare
Validare
Revocare i certificati
25
Public key infrastructure
• Is there an “Internet PKI”?
– Several proposal for an Internet PKI exist: PGP,
PEM, PKIX, Secure DNS, SPKI and SDSI
– No single one has gained widespread use
• In the future:
– Several PKI operating and inter-operating in the
Internet
26
PKI – X.509 Certificates
X.509 Certificate Information
Subject: Distinguished Name,
Public Key Issuer: Distinguished Name,
Signature Validity: Not Before Date, Not After
Date
Administrative Info: Version, Serial Number
Extended Info: …
27
Distinguished Name Information
Defined by X.509 Standard
Common Name
Organization or Company
Organizational Unit
City/Locality
State/Province
Romagna
Country (ISO Code)
CN=Calisto Tanzi
O=Parmalat
OU=Management
L=Parma
ST=Emilia
C=IT
28
PKI - Certificates
• Il processo di certificazione si bassa sulla
fiducia:
– L'utente si fida del certificato rilasciato
dall'autorità emittente in quanto essa è
preposta a rilasciare "validi" certificati.
• L'emittente del certificato viene
comunemente chiamata autorità di
certificazione (CA)
29
PKI – Certificates Authorities
• Una sola Ca per il mondo intero?
– Impraticabile
• Invece:
– Molte PKI abilitano altre CA a certificare altre
CA.
• in pratica: una CA sta dicendo ai suoi utenti che
possono fidarsi di quanto affermato da una seconda
CA nel suo certificato
– Differenti certificati:
• Certificati End-user
• Certificati CA
30
PKI – Certificates Chains
31
PKI – CA Hierarchies
32
PKI - Validation
• Validation
– The information in a certificate can change over
time
– Need to be sure that the information in the
certificate is current and that the certificate is
authentic
• Two basic methods of certificate validation:
– Off-line validation: the CA can include a validity
period in the certificate — a range during which
the information in the certificate can be
considered valid
– On-line validation: the user can ask the CA directly
about a certificate’s validity every time it is used
33
PKI - Revocation
• Revocation
– the process of informing users when the
information in a certificate becomes unexpectedly
invalid
• subject’s private key becomes compromised
• user information changes (e.g., domain name of a
server)
• Off-line
– Within the validity periods, certificate revocation
method is critical
• On-line
– revocation problem becomes trivial
34
PKI - Revocation
• Certificate Revocation List (CRL)
– a list of revoked certificates that is signed and
periodically issued by a CA
– user must check the latest CRL during validation to
make sure that a certificate has not been revoked
• CRL Problems
– CRL time-granularity problem
• how often CRLs must be issued?
– CRL size
• incremental CRL
35
PKI – Registration Authorities
• I soggetti che richiedono un certificato
devono essere autenticati.
• L’autenticazione può essere fatta con
metodi tradizionali:
– Mail
– Fax
– Telefono
– Incontro fisico
36
INTERNET SECURITY:
SECURE SOCKET LAYER
37
Introduction
38
Introduction
• Security at the application level
– Pros: designed for application requirements
– Cons: requires multiple security mechanisms
• Security at the transport level
– Pros: provides common interface to security services
– Cons: requires (minor) modification to applications
• Security at the network level
– Pros:
• works also with security-ignorant applications
• can extend secure enclave across insecure areas
– Cons: may require modifications at the OS level
39
Introduction
• Security at the network level
– IPSec
• Security at the transport level
– SSL (Secure Socket Layer)
• Security at the application level
– S/MIME
– PGP
– Kerberos
– SET
40
SSL: Secure Socket Layer
• Protocollo proposto dalla Netscape
Communications Corporation
• Garantisce confidenzialità e autenticazione
delle comunicazioni su Internet
• Protegge da intrusioni, modifiche o
falsificazioni
• Crittografia ibrida
–
–
–
–
Cifrari Simmetici
Cifrari Asimmetrici
Certificati
MAC
41
SSL
42
SSL: Applicazioni
•
•
•
•
E-commerce
On-line trading
Internet banking
Any application where confidential data
(password, credit card number) needs to be
sent to a remote host
43
SSL - Implementation
• SSL Handshake crea un canale sicuro, affidabile
e autenticato tra client e server entro il quale
...
• ... SSL Record fa viaggiare i messaggi
incapsulandoli in blocchi cifrati e autenticati
• Handshake: definisce il canale ovvero una
suite crittografica che contiene i meccanismi di
cifratura e autenticazione e le relative chiavi
• Record: implementa il canale utilizzando la
suite per cifrare e autenticare i blocchi prima
di darli in pasto al TCP.
44
SSL: handshake e record
45
SSL – Sessions and Connections
• SSL Session
– Un'associazione di lunga durata tra un client e un
server
– Creato dal protocollo di Handshake
– Associato ad una serie di parametri di sicurezza
– Utilizzato per evitare la negoziazione costosa di
nuovi parametri di sicurezza
• SSL Connection
– Un collegamento tra un client e un server
– Le connessioni sono transitorie
– Ogni connessione è associata ad una sessione
46
SSL – Sessions and Connections
• Tra una qualsiasi coppia di soggetti
–Ci possono essere più connessioni
–Normalmente vi è una singola
sessione
47
SSL – Sessions and Connections
• Session state
– Session identifier: arbitrary byte sequence to
identify an active session
– Peer certificate: an X509.v3 certificate of the
peer; may be null
– Compression method: used to compress data
prior to encryption
– Cipher spec: specifies the data encryption
algorithm
– Master secret: 48 byte secret shared between
client and server
48
SSL – Sessions and Connections
• Connection State
– Client/Server random: Random byte
sequences used as identifier chosen by the
client and the server at each connection
– Client/Server write MAC secret key: Secret key
used in Message Authentication Code (MAC)
operations on data sent by the client/server
– Client/Server write secret key: Encryption key
for data encrypted by the client/server and
decrypted by the server/client
– Sequence Numbers
49
SSL – Record protocol
• SSL Record Protocol provides
– Confidentiality: The Handshake Protocol
defines a shared secret key used for
conventional encryption of SSL payloads
– Integrity: The Handshake Protocol defines a
shared secret key used to generate Message
Authentication Code
50
Client hello
• U manda a S un msg richiedendo una
connessione SSL
• U specifica le “prestazioni” di sicurezza
desiderate
– Versione del protocollo SSL sopportato
– Lista di algoritmi di compressione sopportati
– Cipher Suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA
• RSA: scambio chiavi di sessione
• 3DES_EDE_CBC: cifratura simmetrica
• SHA: funzione hash one-way per MAC
• U allega una sequenza di byte casuali
51
Server hello
• S riceve il msg (“client hello”) da U
• S selezione un algoritmo di compressione
tra quelli elencati da U
• S seleziona dalla cipher suite inviata da U
una cipher suite comune (tra U e S)
• S invia a U un msg (“server hello”)
contenente gli elementi selezionati e una
nuova sequenza di byte casuali
• Se U non riceve il msg “server hello”
interrompe la comunicazione
52
Scambio di certificati
• S si autentica con U inviandogli il proprio
certificato digitale (sequenza di certificati
emessi da diverse CA)
• Se i servizi offerti da S devono essere
protetti negli accessi, S può richiedere a U
di inviargli il suo certificato (autenticazione
di U con S)
53
Server hello done
• S invia il msg “server hello done” a U
• “Server hello done” sancisce la fine della
fase in cui ci si accorda sulla cipher suite e
sui parametri crittografici
54
Autenticazione del server al client
• S si autentica con uso di certificato
• No man-in-the-middle attack
• U controlla la attualità del certificato
ricevuto da S
• U controlla che il certificato sia firmato da
una CA tra quelle di cui si fida e che la firma
sia autentica
• Se S spedisce una lista di certificati si
controlla l’intera lista
55
Pre-master secret, Master secret
• U costruisce un pre-master secret P come
una nuova sequenza di byte casuali
• U spedisce P a S dopo averlo cifrato con la
chiave pubblica di S contenuta nel
certificato e l’algoritmo concordato
(nell’esempio U usa RSA)
• U combina P con alcune stringhe note +
byte casuali contenuti in “client hello” e
“server hello” e codifica il tutto con SHA e
MD5 ottenendo il master secret M
56
Costruzione di M al server
• S decifra il msg di U e ottiene P
• S calcola M nello stesso modo con cui U
aveva calcolato M a partire da P
• Nota: S può farlo perché dispone delle
stesse informazioni di cui dispone U
57
Autenticazione del client
• Se richiesto U può autenticarsi mediante
invio del suo certificato
• In pratica: Il sistema dispone di certificati
mentre gli utenti di solito no
• Quando richiesto per autenticare U si
procede con login e password
58
Invio del certificato di U (opzionale)
• Quando richiesto da S, U gli invia il suo
certificato
• Se non lo possiede, si interrompe il
protocollo
• Insieme al certificato, U allega e firma con
la sua chiave privata, la SSL-history
• S controlla il certificato e in caso di
anomalie interrompe il protocollo
59
Messaggi finished
• Questi messaggi vengono costruiti in base al
master secret e contengono tutte le
informazioni che i due partner si sono
scambiati durante la fase di handshake
• Permettono a U e S di effettuare un controllo
ulteriore sulle comunicazioni avvenute e di
accertarsi di possedere lo stesso master secret
• Permettono a U e S di accertarsi che non ci sia
stato un attacco di tipo man-in-the-middle
60
Client finished
• U invia a S il msg “finished” protetto
utilizzando M
• Costruzione di “finished”
FU = M + tutti msg di handshake scambiati
finora + identità di U
• U codifica FU con SHA e MD5 e lo invia a S
61
Server finished
• S verifica il msg finished di U ricalcolando il
tutto
• S invia a U il suo msg “finished” protetto
utilizzando M
• Costruzione di “finished”:
FS = M + tutti msg di handshake scambiati
finora (incluso il msg “finished” di U) + identità
di S
• S codifica FS con SHA e MD5 e lo invia a U
• U verifica il msg “finished” ricevuo da S
62
Client hello e server hello
• In questa fase U e S si scambiano byte
casuali (diversi ogni volta)
• M è funzione di queste sequenze di byte
casuali
• L’intruso non può riutilizzare i msg di
handshake di sessioni precedenti per
impersonare S in una successiva sessione
con U (replay attack)
63
SSL record protocol
• I dati vengono frammentati in parti di
lunghezza opportuna
• Ogni blocco viene numerato, compresso,
autenticato con MAC, cifrato con chiave
segreta e trasmesso usando il protocollo di
trasporto sottostante (TCP)
• Il destinatario opera in modo inverso al
mittente e restituisce il messaggio
all’applicazione sovrastante (HTTP, SMTP,
IMAP, etc.)
64
MAC in SSL record
• Ogni blocco viene numerato e autenticato con MAC
• MAC= H(blocco, numero, K, stringhe note)
• numero = 64 bit quindi no ripetizioni all’interno
della stessa sessione !!!
• Si previene così facendo l’uso fraudolento e iterato
dello stesso blocco nella stessa sessione
• Se un blocco viene perduto i blocchi successivi
vanno ricreati e rispediti
• MAC sono cifrati insieme al messaggio con chiave
simmetrica
65
Generazione sequenze casuali
• Sono contenute il “client hello”, “server hello”
e pre-master secret
• Da loro dipendono fortemente il master secret
e quindi le chiavi segrete di sessione
• La sequenza contenuta nel pre-master secret è
inviata da U a S in modo cifrato e la sua
impredicibilità è cruciale per la sicurezza del
canale SSL
• Se il generatore di sequenze pseudo-casuali
non è di qualità, l’intero protocollo si
indebolisce
66
Conclusioni
• SSL è sicuro quanto la più debole cipher
suite da esso sopportata
• Sarebbe meglio disabilitare nel proprio
browser tutti i protocolli con chiavi troppo
corte (esempio: cifrari simmetrici con chiavi
a 40 bit e asimmetrici con chiavi fino a 512
bit)
• Non effettuare connessioni con sistemi
anonimi perché si rischia che la propria
password venga estorta !!!
67
HTTPS
Hypertext Transfer Protocol Secure (HTTPS)
is a combination of the Hypertext Transfer
Protocol with the SSL/TLS protocol to provide
encryption and secure (website security
testing) identification of the server.
68
Difference from HTTP
• HTTPS URLs begin with "https://" and use
port 443 by default (instead port 80).
• HTTP is unsecure and is subject to man-inthe-middle and eavesdropping attacks
which can let attackers gain access to
website accounts and sensitive information.
HTTPS is designed to withstand such
attacks and is considered secure.
69
Network layer
• HTTP operates at the highest layer of the
OSI Model, the Application layer
• The security protocol operates at a lower
sub-layer, encrypting an HTTP message
prior to transmission and decrypting a
message upon arrival.
• HTTPS is not a separate protocol, but refers
to use of ordinary HTTP over an encrypted
Secure Sockets Layer (SSL) connection.
70
HTTPS as access control
• The system can also be used for client
authentication in order to limit access to a
web server to authorized users.
• the site administrator creates a certificate
loaded into the browser, for each user
• It is automatically checked by the server on
each reconnect to verify the user's identity,
potentially without even entering a
password
71