Intro to SSL/TLS

Network Security

Gene Itkis

2

Sicurezza in rete

• Sicurezza a livello applicativo– Pros: concepita ad hoc per le applicazioni– Cons: richiede l’utilizzo di più meccanismi

• Sicurezza a livello trasporto– Pros: fornisce interfacce comuni a tutti i servizi applicativi– Cons: richiede piccole modifiche alle applicazioni

• Sicurezza a livello rete– Pros: funziona con applicazioni che non si curano affatto della

sicurezza– Consente di attraversare in modo sicuro domini non sicuri– Cons: può richiedere modifiche a livello Sistema Operativo

3

Meccanismi di sicurezza

• Network levevel– IPSec

• Transport levevel– SSL (Secure Socket Layer)

• Application levevel– S/MIME– PGP– Kerberos– SET

4

5

Modelli di sicurezza (1)

•Ci sono due modi per fornire un trasporto sicuro (cioè non intercettabile da orecchie maliziose durante la trasmissione):

– Usare un'infrastruttura di trasporto sicura• Il protocollo non cambia, ma ogni pacchetto

trasmesso nello scambio di informazioni viene gestito in maniera sicura dal protocollo di trasporto

– Usare un protocollo sicuro a livello applicazione• Si usa un protocollo anche diverso, che si occupa di

gestire la trasmissione delle informazioni.

6

Modelli di sicurezza (2)

– HTTPS (RFC 2818)• Introdotto da Netscape, trasmette i dati in HTTP semplice su un

protocollo di trasporto (SSL) che crittografa tutti i pacchetti. • Il server ascolta su una porta diversa (per default la porta 443), e

si usa uno schema di URI diverso (introdotto da https:// )

– S-HTTP (RFC 2660)• Poco diffuso, incapsula richieste e risposte HTTP in un

messaggio crittografato secondo o un formato MIME apposito (MIME Object Security Services, MOSS), o un formato terzo (Cryptographic Message Syntax, CMS).

• E' più efficiente ma più complesso.

7

Protocollo SSL

• Garantisce– Privatezza della comunicazione

• Cifratura a chiave simmetrica

– Autenticazione Server• Utilizzo di certificati digitali per scambio di chiavi

– (opzionale) Autenticazione Client– Integrità dei dati ( Mac dei record SSL )

8

Architecture

IP

TCP

SSL

Application (HTTP)

9

History

• 1993 – Mosaic (“browser #1”)• 1994 – Netscape Browser released

– SSL v1 design complete – never released– SSL v2 released in Navigator 1.1

• Badly broken (bad seeds for PRNG)

• 1995 – Explorer released– PCT (MS), SSL v3 (Netscape)

• 1996-1999 – TLS 1.0• 1999 – WTLS

10

SSL choices

• Connection-oriented– SSL, TLS do not support UDP– But WTLS does

• No non-repudiation– But signatures are used for AKE

• “Only protects the pipe”– Attacks are mounted on data before and after

“the pipe”

11

OpenSSL

• Software crittografico open source, basato sulla libreria SSLeay sviluppata da Eric A. Young e Tim J. Hudson

• Inizialmente (23/12/98) destinata alla diffusione come libreria per l’implementazione dei protocolli SSL e TLS, negli anni è stata integrata con funzionalità crittografiche avanzate che la rendono la più diffusa e utilizzata in ambito open souce ( e non…) per strumenti di firma, cifratura dati e comunicazioni sicure

• Disponibile sulla maggior parte delle piattaforme Unix proprietarie e open source (Linux, OpenBSD ecc…), nonché sui sistemi Microsoft

12

Alternative architectures

• Separate Layer– Over TCP: SSL– Over IP: IPSec

• Application-Specific– SHTTP

• Parallel – Kerberos; Kerberos with TLS?

13

Protocollo SSL

• Presentato nel 1994 da Netscape Communication Corporation che successivamente rilasciò nel 1996 la v3.

• SSL introduce un ulteriore livello nell'architettura ISO/OSI che si colloca tra il livello Applicazione e quello Trasporto

• Una variante, seppur minima, del protocollo è divenuta standard con il nome TLS (RFC 2246)

14

Protocollo SSL

Garantisce:– Privatezza della comunicazione

• Cifratura a chiave simmetrica

– Autenticazione Server• Utilizzo di certificati digitali per scambio di chiavi

– (opzionale) Autenticazione Client– Integrità dei dati ( Mac dei record SSL )

15

TLS/SSL in dettaglio

• E’ un protocollo di livello 5 (sessione) che opera quindi al di sopra del livello di trasporto

• E’ composto da due livelli:– TLS Record Protocol: opera a livello più basso,

direttamente al di sopra di un protocollo di trasporto affidabile come il TCP

• E’ utilizzato per incapsulare (offrendo servizi di sicurezza) protocolli del livello superiore, tra cui l’Handshake Protocol

– TLS Handshake Protocol: si occupa della fase di negoziazione in cui si autentica l’interlocutore e si stabiliscono le chiavi segrete condivise

16

TLS: Architecture

• TLS definisce il Record Protocol per trasferire I dati dell’applicazione e del TLS

• La sessione viene stabilita utilizzando l’Handshake Protocol

TLS Record Protocol

Handshake Protocol

Alert Protocol

ChangeCipher Spec

18

No lock symbol means no security and no encryption.No one knows to click here.

If anyone ever checked, the site business identity cannot be verified.

Standard way to access a Web site via non-secure connection.

Example: I want to book and buy a ticket on line.

19

OK, I’m ready to purchase and give my credit card – to United right?

It really is United right?

Lock symbol appears because I am about to enter credit card info but unbeknownst to most everyone, it is clickable

Click-1 shows that this certificate was issued to www.itn.net. Who is this? And what do they have to do with United Airlines?

Click on the “Details” tab to dig deeper.

20

You have to dig really deeply into crypto-arcanery to get to the identity information such as it is.

Click-2 gives access to the contents of the server’s digital certificate. The site business identity is still not available.

Click on the “Subject” field to dig deeper.

21

We learn the hard way that this is actually not United at all. The Web pages still say United and yet its not United. How often is that going on? A lot!

Finally, after 3 clicks, the authenticated identity of the site business owner is available. It is right after the ‘O = ‘ and in this case it is GetThere.com, Inc. Intuitive and accessible… NOT. Really usable identity information…NOT.

AND IT IS NOT EVEN UNITED AIRLINES THAT I AM ABOUT TO GIVE MY CREDIT CARD TO.

22

TLS: Overview

• Viene stabilita una sessione – Accordo sugli algoritmi– Calcolo del segreto comune– Autenticazione

• Vengono trasferiti i dati dell’applicazione– Viene garantita privacy e integrità

23

TLS: Privacy

• Cifra il messaggio così da non poter essere letto da terzi

• Usa la convenzionale crittografia a chiave segreta– DES, 3DES– RC2, RC4– IDEA

AMessage Message

B$%&#!@

24

TLS:Key Exchange

• Occorrono metodi sicuri per scambiare la chiave segreta

• Si usa la crittografia a chiave pubblica– “key pair” is used - either one can encrypt and

then the other can decrypt– slower than conventional cryptography– share one key, keep the other private

• Le scelte sono RSA o Diffie-Helmann

25

TLS: Integrity

• Vengono calcolati Message Authentication Code (MAC) a lunghezza fissa– Include l’hash del messaggio– Include un segreto condiviso– Include un numero di sequenza

• Il MAC viene trasmesso assieme al messaggio

26

TLS: Integrity

• Il destinatario ricalcola il MAC– deve essere identico al MAC trasmesso MAC

• TLS utilizza sia MD5 che SHA-1

A BMessage’

MAC’

MAC

=?

Message

MAC

27

TLS: Authentication

• Verifica l’identità dei partecipanti

• L’autenticazione del Client e opzionale

• I certificati sono utilizzati per associare la chiave, o altri attributi al proprietario

ACertificate

B

Certificate

28

Possibile autenticazione di U

• 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.

29

TLS: Record Protocol

30

TLS Record Protocol

• Riceve i dati dal livello superiore, li suddivide in blocchi, eventualmente li comprime, calcola il MAC, cifra il tutto e trasmette il risultato dell’elaborazione

• Tipi di dati consegnati al Record Protocol: “handshake protocol”, “alert protocol”, “change cipher spec protocol” e “application protocol”

• Il Record Protocol opera sempre all’interno di uno stato, che definisce gli algoritmi di compressione, cifratura e autenticazione e i parametri relativi (come le chiavi)– Vengono mantenuti 4 stati: gli stati di lettura (per i record ricevuti)

e scrittura (per l’invio dei record) correnti e gli stati di lettura e scrittura pendenti

31

TLS Record Protocol

• Una volta che i parametri di sicurezza sono stati settati e le chiavi generate, gli stati della connessione possono essere istanziati rendendoli correnti

• Gli stati correnti devono essere aggiornati per ogni record elaborato e includono i seguenti elementi:– stato della compressione (stato corrente dell'algoritmo di

compressione)– stato della cifratura (comprende la chiave e altre informazioni

necessarie a definire lo stato dell'algoritmo, per esempio l'ultimo blocco nel caso di un cifrario a blocco in modalità CBC)

– MAC secret– numero di sequenza: valore incrementato dopo ogni record

32

TLS Record Protocol

I parametri di sicurezza definiti per uno stato sono settati fornendo i seguenti valori:

• connection end: specifica se l’entità in questione è il client o il server• bulk encryption algorithm: indica l’algoritmo di cifratura e i relativi

parametri, come la lunghezza della chiave• MAC algorithm: indica l’algoritmo di autenticazione ed i parametri

relativi• compression algorithm: indica l’algoritmo di compressione e i relativi

parametri• master secret: sequenza di 48 byte condivisa tra i due interlocutori• client random: 32 byte casuali forniti dal client• server random: 32 byte casuali forniti dal server

33

Handshake Protocol

• E’ costituito da tre sotto-protocolli (“change cipher spec”, “alert” e “handshake”) che permettono ai due interlocutori di negoziare i parametri di sicurezza e notificare condizioni di errore

• E’ responsabile della negoziazione di una sessione, che è costituita dai seguenti parametri:– session identifer: identificatore della sessione scelto dal server– peer certificate: certificato X.509 dell'interlocutore -- può mancare– compression method: algoritmo di compressione– cipher spec: algoritmi di cifratura e autenticazione e relativi

parametri crittografici– master secret– is resumable: flag che indica se la sessione può essere utilizzata

per iniziare nuove connessioni

34

MAC in SSL record

• Ogni blocco viene numerato e autenticato con MAC.• MAC= H(blocco, numero, K, stringhe note)• numero = 64 bit. 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.

35

TLS: Handshake

• Negoziazione del Cipher-Suite Algorithms– Symmetric cipher to use– Key exchange method– Message digest function

• Calcola e condivide il master secret

• Opzionalmente consente di autenticare server e/o client

36

Handshake Phases

• Messaggi di Hello

• Messaggi per lo scambio di Certificati and Chiavi

• Messaggi di Change CipherSpec e Finished

37

TLS: ServerKeyExchange

Client

ClientHello

Server

ServerHello Certificate ServerKeyExchange

38

TLS: Hello

• Client “Hello” – inizia la sessione– Propone la versione del protocollo– Propone la cipher suite– Il Server sceglie protocol e suite

• Il Client può richiedere l’uso di cached sessions– Il Server sceglie se accordare la richiesta

39

Server hello

• S riceve il msg (client hello) da U• S seleziona 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.

40

TLS: Key Exchange

• Il Server invia un certificato contenente la chiave publlica (RSA) o i parametri Diffie-Hellman

• Il Client invia il “pre-master” secret cifrato al server usando il messaggio Client Key Exchange

• Viene calcolato il Master secret – Si usano i valori random usati nei messaggi Client

and Server Hello

41

Costruzione del master secret

• U costruisce un pre-master secret P (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.

• 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.

42

A cosa serve M ?

• S e U utilizzano M per generare le chiavi (sia per il cifrario simmetrico sia per le funzioni MAC) e per altri scopi...

• Nota: Le chiavi utilizzate da S e U sono diverse ma note ad entrambi. Ciò rende il protocollo ancora più sicuro.

43

TLS: Certificate Request

Client

ClientHello

Server

ServerHello Certificate ServerKeyExchange CertificateRequest

44

TLS: Client Certificate

Client

ClientHello

ClientCertificate ClientKeyExchange

Server

ServerHello Certificate ServerKeyExchange CertificateRequest

45

Come vengono usati i certificati• I certificati consentono ai Web server ed ai client

l’autenticazione prima di stabilire una connessione per mezzo delle chiavi pubbliche

• I certificati sono parte del protocollo SSL per l’utilizzo di connessioni sicure: per sfruttare connessioni SSL un Web server deve ottenere ed installare un certificato

• I certificati possono essere essere adottati sia dal client che dal server solo con SSL 3.0

46

Public Key Certificates

• X.509 Certificate associano le chiavi all’identità deio possessori

• Certification Authority (CA) crea il certificato– Rispetta le politiche e verifica le identità– Firma i certificati – L’utente deve verificare che il Certificato sia

valido

47

Validare un Certificate

• Bisogna riconoscere la CA fidata nella certificate chain– Ogni CA può essere certificata da un’altra CA

• Occorre verificare che il certificato non sia stato revocato– La CA pubblica la Certificate Revocation List

(CRL)

48

X.509: Certificate Content

• Version

• Serial Number

• Signature Algorithm Identifier– Object Identifier (OID)

– e.g. id-dsa: {iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 1}

• Issuer (CA) X.500 name

• Validity Period (Start,End)

• Subject X.500 name

• Subject Public Key

– Algorithm

– Value

• Issuer Unique Id (Version 2 ,3)

• Subject Unique Id (Version 2,3)

• Extensions (version 3)– optional

• CA digital Signature

49

Subject Names

• X.500 Distinguished Name (DN)

• Associato ad un nodo della gerarchia di directory (X.500)

• Ogni nodo ha un Relative Distinguished Name (RDN)– Un percorso per raggiungere il nodo padre– Un set unico di coppie attributo/valore

50

Example Subject Name

• Country at Highest Level (e.g. US)

• Organization typically at next level (e.g. CertCo)

• Individual below (e.g. Common Name “Elizabeth” with Id = 1)DN = {

• C=US; • O=CertCo; • CN=Elizabeth, ID=1}

51

Version 3 Certificates

• Version 3 X.509 Certificates supporta formati ed estensioni alternative per i nomi– X.500 names– Internet domain names– e-mail addresses– URLs

• Un Certificato può includere più di un nome

52

Certificate Signature

• RSA Signature– Crea l’hash del Certificato– Lo cifra usando la chiave privata della CA

• Signature verification – Decifra la firma usando la chiave pubblica della

CA– Verifica l’hash

53

TLS: Change Cipher Spec, Finished

Client

[ChangeCipherSpec] Finished

Application Data

Server

[ChangeCipherSpec] Finished

Application Data

54

TLS: Change Cipher Spec/Finished

• Change Cipher Spec– Chiede di iniziare l’utilizzo della Cipher Suite

concordata

• Finished– Invia una copia dell’handshake ed apre una

nuova sessione– Permette la validazione dell’handshake

55

U 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 codificando FU con SHA e MD5 lo invia a S.

56

S: 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.

57

TLS: Using a Session

Client

ClientHello (Session #)

[ChangeCipherSpec] Finished

Application Data

Server

ServerHello (Session #)

[ChangeCipherSpec] Finished

Application Data

58

Changes from SSL 3.0 to TLS

• Fortezza rimossa

• Aggiunti messaggi di Alert

• Modifiche al calcolo dell’hash

• Nuova Protocol version 3.1 in ClientHello, ServerHello

59

TLS: HTTP Application

• HTTP è la più comune applicazione di TLS – https://

• Richiede TLS-capable web server

• Richiede TLS-capable web browser– Netscape Navigator– Internet Explorer– Cryptozilla

• Netscape Mozilla sources with SSLeay

60

Web Servers

• Apache-SSL

• Apache mod_ssl

• Stronghold

• Roxen

• iNetStore

61

Other Applications

• Telnet

• FTP

• LDAP

• POP

• SSLrsh

• Commercial Proxies

62

TLS: Implementation

• Cryptographic Libraries– RSARef, BSAFE

• TLS/SSL packages– SSLeay– SSLRef

63

X.509 Certificate Issues

• Certificate Administration is complex– Hierarchy of Certification Authorities– Mechanisms for requesting, issuing, revoking

certificates

• X.500 names are complicated

• Description formats are cumbersome (ASN.1)

64

X.509 Alternative: SDSI

– SDSI: Simple Distributed Security Infrastructure (Rivest, Lampson)

• Merging with IETF SPKI: Simple Public-Key Infrastructure in SDSI 2.0

• Eliminate X.500 names - use DNS and text

• Everyone is their own CA

• Instead of ASN.1 use “S-expressions” and simple syntax

65

TLS “Alternatives”

• S-HTTP: secure HTTP protocol, shttp://

• IPSec: secure IP

• SET: Secure Electronic Transaction– Protocol and infrastructure for bank card

payments

• SASL: Simple Authentication and Security Layer (RFC 2222)

66

Protocollo SSL

67

Riassumendo• PGP fornisce sicurezza per una

specifica applicazione

• SSL opera sullo strato di trasporto; fornisce sicurezza ad ogni applicazione TCP

• SSL: usato fra WWW browsers, servers per e-commerce (shttp).

• SSL servizi offerti:

– Autenticazione server

– Codifica dati

– Autenticazione client (opzionale)

Autenticazione Server:

– browser con SSL include chiavi pubbliche per CA fidate

– Browser richiede certificato del server alla CA fidata

– Browser usa la chiave pubblica della CA per estrarre la chiave pubblica del server dal certificato

68

Riassumendo

Sessione SSL crittata:• Browser genera chiave

simmetrica di sessione, la codifica con la chiave pubblica del server e invia la codifica al server

• Server decodifica la chiave di sessione con la sua chiave pubblica

• Browser e server concordano che messaggi futuri saranno crittati

• I dati inviati nel socket TCP sono codificati con la chiave di sessione

• SSL: base del livello di trasporto sicuro (Transport Layer Security, TLS).

• SSL può essere usato anche per altre applicazioni (non Web) ad es., IMAP.

• L’autentica del cliente può essere fatta in modo analogo (usando certificati del cliente)

• Uso di chiavi di sessione generate ad hoc permette di limitare l’uso della chiave pubblica (+ veloce, + sicuro)

69

Handshake Protocol

• ClientHello– Messaggio con il quale il client indica quali algoritmi supporta in ordine

di preferenza e inserisce un valore casuale• ServerHello

– Risposta del server che indica quali algoritmi (compressione, cifratura, autenticazione) ha scelto, il codice identificativo della sessione e un numero casuale

• [Certificate]– Messaggio contenente il certificato del server

• ServerKeyExchange– Messaggio contenente la chiave pubblica RSA o un valore per effettuare

uno scambio Diffie-Hellman• [CertificateRequest]

– Il server può richiedere al client un certificato

70

Handshake Protocol

• Change cipher spec– E’ un protocollo che consiste di un solo messaggio che viene

crittato e compresso in base allo stato corrente della connessione– Tale messaggio viene inviato sia dal client che dal server per

notificare che i record successivi verranno protetti con gli algoritmi e le chiavi di cifratura appena negoziati

• Alert– Messaggi di controllo ed errore per notificare all’interlocutore una

particolare situazione o un evento– Tipi di messaggi: chiusura della connessione, errore nella verifica

del MAC o nella decifratura, vari tipi di errore relativi ai certificati

71

Cipher suite

Key exchange methods:– RSA: richiede il certificato del destinatario– Fixed DH: richiede che entrambi abbiano il

certificato– Ephemeral DH: vengono scambiate chiavi

ephemeral firmate, sono richiesti i certificati per ambo le parti

– Anonymous DH: non occorre autenticazione delle chiavi DH, vulnerabile all’attacco men-in-the-middle

– Fortezza: Fortezza key exchange

72

Cipher suite

• CipherAlgorithm: RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza

• MACAlgorithm: MD5 or SHA-1• CipherType: stream or block• IsExportable: true or false• HashSize: 0, 16 or 20 bytes• Key Material: used to generate write keys• IV Size: size of IV for CBC

73

Possibili modi di utilizzo

• Porti dedicati per ogni applicazione che utilizza SSL– quello che avviene di fatto

• Uso del porto comune e negoziazione della sicurezza come parte del protocollo applicativo

• Uso di SSL negoziato durante l’apertura della normale connessione TCP/IP

74

Porti

• https 443• ssmtp 465• snntp 563• sldap 636• spop3 995• ftp-data 889• ftps 990• imaps 991• telnets 992• ircs 993

75

Differenze tls/ssl

• TLS usa HMAC, SSL usa un precursore

• TLS MAC utilizza un maggior numero di meccanismi di compressione rispetto a SSL MAC

• TLS definisce alert codes aggiuntivi

• Altre differenze minori

• TLS può implementare SSL

76

SSL & ACL

• Con gli odierni server web, utilizzati con protocollo HTTPS (HTTP over SSL) è possibile definire delle ACL basate sui possibili dati presenti nei certificati degli utenti abilitati all’accesso, – Es: campo “Organization” del Distinguished Name del

certificato utente

oppure consentire l’accesso esclusivamente ad un sottoinsieme di utenti i cui certificati sono contenuti in un repository

77

SSL & ACL• Vantaggi:

– Gestione di parte dell’autenticazione demandata alla CA• In caso di utente malevolo, la revoca da parte della CA del certificato ha

come effetto l’impossibilità di accedere a qualunque sistema ( che ha prelevato l’ultima CRL…)

– Obbligo di revisione delle credenziali di accesso alla scadenza del certificato utente

– Semplificazione delle procedure di registrazione: l’identificazione dell’utente è stata già fatta dalla CA

– Single Sign On– Possibile centralizzazione/semplificazione delle funzioni di

Autenticazione e Autorizzazione– …

78

SSL con APACHE

• la Apache Software Foundation non include nel progetto Apache Httpd il modulo per il supporto di SSL

• esistono due progetti open source che si propongono di garantire il supporto di SSL :mod ssl e Apache-SSL , ed entrambi gestiscono le connessioni sicure appoggiandosi alle librerie del progetto OpenSSL

• esistono altre implementazioni commerciali di moduli SSL per Apache:"Covalent Raven SSL Module For Apache”, la distribuzione IBM di Apache "IBM Http Server".

79

Direttive per l’uso di SSL•SSLSessionCache: imposta il tipo di memorizzazione della cache

•SSLEngine è la direttiva che abilita o disabilita le connessioni SSL

•SSLProtocol controlla la versione del protocollo che verrà usata durante le transazioni sicure. Es. SSLProtocol All -SSLv2

•SSLCertificateFile e SSLCertificateKeyFile contengono banalmente il path ai file certificato e chiave del server

•SSLRequireSSL :usata nelle sezioni "<directory>" ci consente di rendere accessibili alcune aree del nostro server solo attraverso connessioni sicure

•SSLCipherSuite permette di configurare gli algoritmi crittografici che il client può usare quando viene stabilita la connessione

80

Così…

• SSL non garantisce l’identità delle parti. Permette la cifratura delle comunicazioni tra client e server

• La cosa più importanti nelle transazioni è: conchi ho a che fare?

• Come fare a garantire ciò sul web ?

Commercio Elettronico

82

Schema della doppia codifica

83

Commercio elettronico

• A: acquirente, con accesso a Internet.• B: venditore, con catalogo elettronico in Internet.• A consulta il catalogo di B, sceglie la merce da acquistare e attiva la

transazione.• B fornisce ad A la propria chiave pubblica.• Il PC di A automaticamente:

– prepara l’ordine elettronico m;– genera una chiave k con cui codifica m m’;– codifica k con la chiave pubblica di B k’;– invia m’ e k’ a B.

• Il computer di B automaticamente:– decodifica k’ con la chiave privata di B;– con k decodifica m’ e ottiene l’ordine.

• B spedisce la merce.

problema del pagamento

84

Pagamento con carta di credito (schema teorico)

• CC indichi la Società della Carta di credito.• A consulta il catalogo di B, sceglie la merce da acquistare, fornisce i dati

della propria Carta di credito e attiva la transazione.• Il PC di A compie automaticamente due operazioni:

– prepara l’ordine elettronico senza i dati della Carta di credito e lo invia a B;

– prepara la nota di debito con i dati della Carta di credito e con riferimento a B; codifica questa nota con un sistema di doppia codifica e la invia a CC.

• CC decodifica la nota di debito, effettua i controlli rituali, contabilizza l’addebito su A e l’accredito su B, comunica a B il buon esito contabile dell’operazione.

• B riceve il messaggio da CC ed evade l’ordine.• Sistema sicuro ma informaticamente complesso (2 collegamenti

indipendenti).

85

Pagamento con carta di credito (schema reale 1a)

Protocollo SSL (Secure Socket Layer)

• Sviluppato da Netscape e utilizzato anche da Microsoft.• m contiene sia i codici della merce sia le coordinate della carta

di credito.• m viene cifrato da A con un sistema a doppia codifica.• m viene inviato a B.• L’inoltro delle coordinate della carta di credito a CC è a cura del

venditore B.

86

Osservazioni sulla sicurezzaPro

• k viene generata presso il mittente A, cambia ad ogni transazione e non esce dal PC di A.

• A è sicuro di ordinare merce da un fornitore B affidabile, la cui garanzia è fornita indirettamente da CC.

• B è sicuro di ricevere tramite CC il corrispettivo della merce spedita.

Contro

• B viene a conoscere le coordinate della carta di credito di A: la sicurezza del sistema pertanto è anche in funzione dell’etica di B, non valutabile a priori.

87

Pagamento con carta di credito (schema reale 1b)

Variante del precedente

• m contiene sia i codici della merce sia le coordinate della carta di credito.

• m viene cifrato da A con un sistema a doppia codifica.• m viene inviato a CC.• L’inoltro dell’ordine al venditore B è a cura di CC.

Scompaiono i contro.

88

Pagamento con carta di credito (schema reale 2)

Protocollo SET (Secure Electronic Transaction)

• Sviluppato su iniziativa di Visa e Mastercard (CC).• Le coordinate della carta di credito sono prima codificate con

la chiave pubblica di CC poi affiancate ai codici della merce: il tutto forma il messaggio m, che viene codificato con hB .

• B al ricevimento di m’ estrae le coordinate della carta di credito - che sono cifrate - e le invia a CC.

• CC le decodifica e autorizza B a spedire la merce.

89

Osservazioni sulla sicurezza

Pro

• A è sicuro di ordinare merce da un fornitore B affidabile, la cui garanzia è fornita indirettamente da CC.

• B è sicuro di ricevere il corrispettivo della merce spedita.• B non viene a conoscere le coordinate della carta di credito di A: la

sicurezza del sistema pertanto dipende solo dell’etica di CC, che si presume altissima.

Contro

• Sistema nuovo, complesso, in corso di diffusione.

90

Secure electronic transact. (SET)Limiti di SSL in applicazioni e-

commerce. Garanzie su

– validità carta di credito (rubata?)

– Autorizzazione azienda (per transazione)

SET• Progettato per transazioni con

carta di credito

• Fornisce sicurezza fra:

– cliente

– negoziante

– banca negoziante

• Tutti hanno certificati

• Il numero della carta di credito è fornito in modo crittato (negoz. non vede il numero in chiaro)

– Previene frodi da parte del negoziante

• Tre componenti software :

– Browser

– Server negoziante

– Gateway cliente