Sicurezza delle applicazioni di rete Situazione standard 

Oggi si considera  la situazione standard, ovvero  il modo  in cui gli sviluppatori creano  le applicazioni di rete, una situazione abbastanza negativa, questo per i seguenti motivi : 

autenticazione ed autorizzazione basate su username e password  ne  deriva  un  problema  legato  principalmente  alle  reti  e  al  modo  in  cui  esse  sono organizzate, infatti quei dati sono potenzialmente sniffabili in rete: password snooping  

autenticazione basata  su  indirizzo  IP  ( questa è possibile  farla ad esempio nel caso dei  server web, o anche nel caso della suite di comandi R come rsh, rlogin, rcp, ...) 

in questo caso il problema sarebbe comunque l’IP spoofing  

Anche  a  voler  implementare  il meccanismo  più  sicuro,  rimangono  sicuramente  problemi  di carattere generale, come: 

data snooping / forging  shadow server / MITM 

 Per cercare di risolvere i problemi appena citati, presentiamo alcuni approcci possibili. 

Sicurezza di canale 

 

Questo approccio  consiste nel proteggere  i dati nel momento  in  cui  transitano all’interno del  canale. Come  vediamo  i  due  nodi  che  vogliono  comunicare  dei  dati  che  sono  indicati  in  rosso  (quindi  dati sensibili e che devono essere opportunamente protetti) decidono di comunicare tra  loro attraverso un canale protetto.  In questo  senso notiamo  che non  solo  vengono  solo protetti  i dati  in  rosso, ovvero quelli che i due nodi intendevano scambiarsi, ma anche i dati che casualmente si trovano a transitare su quel canale, perché la proprietà di sicurezza non è un attributo dei dati bensì un attributo del canale di trasmissione. Notiamo  anche  che  essendo  la  sicurezza una proprietà del  canale, una  volta  che  i dati escono e arrivano al nodo destinazione ritornano ad essere dei dati non protetti e quindi con tutte  le problematiche che conosciamo. In una situazione di questo tipo,abbiamo le seguenti possibilità: 

autenticazione  (singola o mutua, perché  il canale  si crea prima di  trasmettere  i dati quindi  se una delle due parti non si autentica noi ci possiamo anche rifiutare di aprire il canale), integrità e segretezza solo durante il transito nel canale 

nessuna possibilità di non  ripudio,  infatti  il non  ripudio è di  solito qualcosa di  inerente  i dati. Notiamo  che nel momento  in  cui  il destinatario estrae  i dati dal  canale,  avrà  la  certezza  che arrivino dalla controparte, che siano integri ma non lo può provare a terzi!  

richiede poca (o nulla) modifica alle applicazioni 

 

Sicurezza di messaggio (o dei dati) 

 

Questo approccio consiste nel prendere  i dati che  intendiamo proteggere ed  incapsularli all’interno di una busta sicura. A voler dare un’idea pratica di quanto stiamo dicendo, potremmo dire che  la prima soluzione vista  la possiamo realizzare con un tunnel sicuro  (quindi  IPsec) mentre  la soluzione corrente potrebbe essere realizzata sfruttando il formato PKCS‐7 che per l’appunto ci permette di realizzare una busta sicura. Il concetto che deve essere chiaro è che ogni singolo dato che deve essere protetto viene protetto  singolarmente  e  deve  essere  protetto  dal mittente.  Quindi  visto  che  il mittente  opera  in completa  autonomia,  andiamo  a  perdere  l’autenticazione  eventuale,  cioè  non  è  possibile  alcuna negoziazione preventiva prima di iniziare la trasmissione. Abbiamo un vantaggio derivante dal fatto che proteggiamo solo quello che veramente ci interessa proteggere. A questo punto è veramente possibile il non ripudio,  in quanto  il mittente avrà preso  i dati di partenza e  li avrà trasformati applicando ad essi tutta una serie di attibuti sulla base delle esigenza che aveva (es. voleva riservatezza e li ha cifrati, voleva autenticazione ed integrità e avrà messo un keyed‐digest, voleva il non ripudio allora avrà apposto una firma digitale con  tanto di certificato emesso da una CA ufficialmente  riconosciuta).  In questo senso  i dati  che  arrivano  al  destinatario  sono  dei  dati  diversi  rispetto  a  quelli  di  origine.  Quindi  volendo riassumere: 

autenticazione (singola), integrità e segretezza auto‐contenute nel messaggio  possibilità di non ripudio  richiede  modifica  alle  applicazioni  :  in  quanto  o  modifichiamo  l’applicazione  in  modo  che applichi le misure di sicurezza che vogliamo o dovremo realizzare un applicativo che a partire dai dati di origine li incapsuli in una busta sicura seguendo il formato PKCS‐7 ad esempio 

L’ultimo motivo, ovvero il fatto che richiede modifica alle applicazioni, è anche la motivazione base per cui  questa  soluzione  non  è  quella  diffusamente  adottata.  Ad  oggi  infatti,  la  tendenza  diffusa  delle aziende  è quella di delegare  la  sicurezza  ai  livelli  bassi, ovvero  alla  rete, quindi  nonostante  la prima soluzione  on  sia  proprio  quella  ottimale  in  quanto  non mi  permette  di  avere  il  non  ripudio,  non mi permette  di  sapere  se  i  dati  sono  stati  protetti  al  livello  applicativo,  è  comunque  quella  più  usata. Ovviamente è anche possibile fare un mix delle due soluzioni appena viste. 

Sicurezza interna alle applicazioni 

Quindi  in origine  il problema  ricadeva nelle mani degli  sviluppatori, ovvero ogni  sviluppatore  che  volesse  integrare  la  sicurezza nell’applicazione  che  si accingeva a creare, doveva crearsi  le proprie  routine o  le proprie classi per cifrare  i  dati  e  garantire  determinate  proprietà  di  sicurezza.  Ovviamente, questa situazione veniva ad essere replicata per ogni sviluppatore, quindi  la parte  in  comune  che  rimaneva  era  quella  di  rete,  in  quanto  nessuno  si sfruttavano i socket che costituiscono un’astrazione logica, e questo faceva sì che  ci  fosse  qualcosa  che  venisse  messo  a  fattor  comune.  Quindi  tante persone si sono messe a cercar di  risolvere questo problema pensando alla 

loro singola applicazione e per qualche anno, gli sviluppatori delle singole applicazioni hanno pensato a dei metodi  ad  hoc  per  rendere  sicura  la  loro  applicazione.  In  questa  situazione  in  cui  la  sicurezza  è selezionata internamente ad ogni singola applicazione, abbiamo vantaggi e svantaggi. Il vantaggio è che ogni  applicazione  pensa  da  sé  a  realizzare  la  sicurezza  e  quindi  il  problema  se  così  si  può  dire  è demandato all’applicazione e quindi la parte comune è relativa a sua volta alla parte bassa dello stack di rete, ma  fare  sicurezza  non  è  semplice  e  quindi  sono  possibili  tantissimi  errori  di  implementazione: infatti è possibile anche che qualcuno capisca la funzione ma sbagli a realizzarla. Altro grosso problema che per anni è  stata una macchia nera nel  campo della  sicurezza è  che questa  strada non garantisce l’interoperabilità (a meno che non fosse stato lo stesso sviluppatore a realizzare entrambe le entità che dovevano  comunicare  tra  loro).  Quindi  volendo  riassumere  in  modo  molto  sintetico,  per  questa soluzione i seguenti punti sono fondamentali: 

ogni applicazione implementa la sicurezza al proprio interno  la parte in comune si limita ai canali di comunicazione (socket)  possibili errori di implementazione (inventare protocolli di sicurezza non è semplice!)  non garantisce l’interoperabilità 

 Si è quindi pensato di estendere il concetto di socket in modo da realizzare un canale logico sicuro.    Sicurezza esterna alle applicazioni  

La situazione è cambiata quando qualcuno ha avuto l’idea di seguire il concetto logico  dei  socket  estendendoli  in modo  da  realizzare  un  canale  logico, ma sicuro.  Quindi  quelle  applicazioni  che  vogliono  dare  un  vero  valore  alla sicurezza  e  che  riconoscono  che  ralizzare  pratiche  di  sicurezza  è  un  lavoro estremamente  difficile,  usano  i  socket  sicuri. Ma  a  questo  punto  sorge  un problema  di  carattere  esistenziale:  nel  TCP/IP  non  esiste  il  livello  sessione, infatti sono distinti il livelli fino al 4 (ricordiamo sono fisico (1), datalink (2), rete (3), trasporto (4) ) dopodiché il 5,6 e 7 sono fusi in un tutt’uno che poi è quello che  viene  trattato  dalle  applicazioni.  Se  uno  esaminasse  in  dettaglio  la  pila ISO/OSI si accorgerebbe infatti che il livello sessione è quello in cui andrebbero concentrate  la maggior parte delle  funzionalità di  sicurezza  canale  in quanto 

una sessione altro non è che un canale logico! Quindi si è posto riparo a questo problema inventando un livello  sessione  sicura  (perché di  fatto  la  sessione non  sicura non esiste) ed è una piccola estensione sopra i socket. Ovviamente, da questa scelta di proporre un livello “sessione sicura” derivano una serie di vantaggi:   

abbiamo  semplificato  il  lavoro  degli  sviluppatori  applicativi  (infatti  cambia  che  nella  fase  di apertura  del  canale  dovremo  fornire  alle  primitive  dei  parametri  aggiuntivi  per  dire  quali funzionalità di sicurezza vengano aggiunte alla nostra applicazione, ma una volta fatto questo le write e le read funzioneranno in modo del tutto trasparente) 

evitiamo possibili errori di implementazione  poiché  non  abbiamo modificato  lo  stack  (infatti  quello  che  è  stato  fatto  è  creare  un  piccolo strato  che  copra  il  socket  solo parzialmente),  esiste  ancora  la  flessibilità,  in quanto  la  strada proposta  non  è  detto  che  debba  necessariamente  essere  scelta:  la  scelta  è  a  discrezione dell’applicazione. Se qualcuno pensa infatti che la libreria che lui ha sviluppato in proprio per la sua  applicazione  è  sicuramente migliore, potrà  continuare  ad usarla  (caso dell’applicazione  a destra in figura) 

 Questa ad oggi è la soluzione che va per la maggiore, e in particolare sono state sviluppate tre librerie o protocolli per implementare questo tipo di soluzione.  

Protocolli di sicurezza orientati al canale di comunicazione  Queste tre soluzioni le elenchiamo qui di seguito:  

1. SSL / TLS o SSL,  che  è  stato  successivamente  rinominato  in  TLS,  è  sicuramente  il  più  diffuso  al 

mondo 2. SSH 

o Il principale competitor di SSL è stato proprio questo, e ha avuto un momento di gloria soprattutto per quei problemi di politiche di esportazione che erano state imposte dagli USA.  Infatti SSH è stato sviluppato  in Finlandia, mentre SSL non si riusciva ad averlo  in versione  “forte”.  Da  quando  le  limitazioni  sull’esportazione  di materiale  crittografico sono state rimosse, e anche SSL è stato  liberalizzato, SSH è diventato una soluzione di nicchia 

3. PCT o È stato proposto da Microsoft come alternativa a SSL o nessuno  lo ha  implementato tranne Microsoft stessa, quindi Microsoft stessa a partire 

da Explorer 5 lo ha cancellato dai propri prodotti  Di queste tre, iniziamo con SSL in quanto come già detto è la soluzione più diffusa al mondo.  SSL (Secure Socket Layer) 

Lo troviamo nella maggior parte delle applicazioni, e in tutte le salse, non soltanto collegato con il web. Come  vediamo  è  stato  proposto  da  Netscape  Communications,  ed  implementa  un  protocollo  di trasporto sicuro (circa livello sessione, non è infatti né un livello 4 né propriamente un livello 5 in quanto come già detto nella realizzazione dello stack TCP/IP non esiste, quindi siccome è comunque utile, sta lì, da qualhe parte).  Quando apriamo un canale SSL o TLS quello che otteniamo sono le seguenti proprietà: 

o autenticazione : va intesa come peer autentication, autenticazione delle parti che instaurano il canale.  Infatti di default  l’autenticazione è del server, mentre è opzionale che  il server chieda l’autenticazione al client. Questo se ci pensiamo bene è qualcosa molto strano, in quanto le cose al  livello  logico dovrebbero essere  invertite.  In  realtà,  SSL è  stato  inventato per proteggere  il commercio elettronico dove  la  cosa più  importante è autenticare  il  server. E’ per questo  che l’opzione di default è quella ed è irremovibile : non si può configurare SSL per non autenticare il server,  in  quanto  quello  è  il  default.  Opzionalmente  si  può  richiedere  anche  al  client  di autenticarsi  

o riservatezza dei messaggi  :  tutti  i  canali che vengono  trasmessi  su un canale SSL  sono cifrati. Nelle  versioni  più  recenti  la  riservatezza  può  anche  essere  di  soli  zero  bit,  quindi  è  anche possibile  NON  AVERE  RISERVATEZZA.  Questo  dipende  dalla  configurazione  del  cliente  e  del server,  ed  è  stato  fatto  principalmente  perché  la  parte  di  cifratura  simmetrica  è  comunque pesante quindi per tutte  le applicazioni che non necessitano di questa proprietà di sicurezza è anche possibile rimuoverla richiedendo di fare riservatezza usando l’algoritmo NUL che richiede una chiave da zero bit 

 o autenticazione ed integrità dei messaggi : questa è ancora una volta una proprietà inamovibile, 

e sottolinea  il  fatto che autenticazione e  integrità sono molto più  importanti  in generale della riservatezza (ricordiamoci quanto detto dai militari secondo i quali solo il 10%‐20% dei messaggi che  loro  trasmettono  hanno  bisogno  si  riservatezza,  mentre  il  100%  hanno  bisogno  di autenticazione e integrità) 

 

o protezione  da  replay  e  da  filtering  :  trattandosi  di  un  ambiente  di  rete  e  quindi fondamentalmente  insicuro,    si  applica  anche  la  protezione  da  replay  (ritrasmissione  di pacchetti) e da filtering (ovvero cancellazione dei pacchetti). Degno di nota è che nel caso venga rilevato  un  attacco  di  replay  o  di  filtering,  la  reazione  è  quella  di  chiudere  il  canale  con conseguente blocco dell’applicazione. Questo significa che chi ci fa un attacco di quel tipo non riesce a farci fare qualcosa che non prevedevamo, ma riesce sicuramente a farci un Denial‐of‐Service. Questa non è da considerare una nota di demerito di SSL, ma è un problema generale delle  comunicazioni  in  rete:  in  ogni  caso  infatti  chi  gestisce  l’infrastruttura  di  comunicazione potrebbe impedire le comunicazioni se solo lo volesse. 

 SSL essendo collocato a questo  livello “4 e mezzo”, non dipende da una specifica applicazione. E’ stato pensato  così bene  che  si  adatta  facilmente  ad un qualunque protocollo  applicativo  che  si basi  su un canale  affidabile.  Notiamo  che  non  c’è  niente  dentro  SSL  che  dice  che  SSL  si  usa  con  TCP  :  se  noi avessimo  un  altro  protocollo  al  livello  di  trasporto  affidabile  lo  potremmo  usare  anche  con  quello. Ovviamente oggi TCP va per la maggiore, quindi alla fine SSL è applicabile facilmente a tutti i protocolli applicativi basati su TCP, come ad esempio HTTP, SMTP, NNTP, FTP, TELNET. Ad es. famoso HTTP sicuro (https non è un protocollo, ma è una URL, una abbreviazione per dire che vogliamo http sopra SSL!!!), che opera alla porta 443/TCP.  Porte ufficiali per applicazioni SSL  Qui vedete l’elenco di tutte le porte ufficiali che sono state riservate per l’uso delle versioni protette con SSL dei maggiori protocolli, quindi esattamente come si ha per https 443/tcp, abbiamo smtps 465/tcp a posto della classica porta 25. Questo perché c’è differenza tra usare  la versione normale e  la versione sicura. 

SSL ‐ autenticazione e integrità 

Vediamo come SSL realizza  le funzioni che abbiamo presentato.   All’atto dell’apertura del canale viene fatta la peer authentication. Il server si presenta con un proprio certificato X.509 valido perché il client lo sottoporrà ad una sfida di tipo asimmetrico. Per quanto riguarda l’autenticazione e l’integrità, dobbiamo distinguere la peer authentication dalla data authentication: 

1. Per  la  peer  authentication  siccome  si  deve  autenticare  prima  il  server,  il  server  si  autentica presentando la propria chiave pubblica all’interno di un certificato X.509:  

o un  server per essere un  server SSL deve possedere chiave privata e chiave pubblica e deve avere la chiave pubblica certificata (le chiavi pubbliche non si possono mandare in  giro così e devono essere all’interno di un certificato).  

o Ovviamente al server non basta mandare il certificato per dimostrare la propria identità  quando qualcuno manda ad un utente  il proprio certificato,  l’utente gli manda 

una  sfida  asimmetrica  per  vedere  che  lui  possiede  la  chiave  privata corrispondente alla pubblica che gli ha fornito.  

2. Il server una volta autenticatosi ha la possibilità di chiedere al client di autenticarsi: o questo  step  è  opzionale  ed  è  controllato  dal  server,  infatti  l’unico  schema  di 

autenticazione  supportato da SSL è quello dei certificati quindi può anche darsi che  il client  non  possieda  un  certificato  X.509,  nel  qual  caso  non  sarebbe  possibile  per  lui collegarsi al server. 

quando  ci  colleghiamo  al  portale della didattica  il  server  ci  chiede di dargli  il nostro certificato 

noi non ce l’abbiamo e gli diciamo di andare avanti lo stesso e di conseguenza il server ci chiede username e password 

per  alcuni  docenti  che  hanno  il  certificato  è  possibile  entrare  direttamente senza digitare username e password, poiché si viene riconosciuti direttamente dal certificato.  

Quello del portale della didattica è un server web con client authentication.  • Esso chiede se il client ha un certificato e se ha questo certificato gli fa la 

sfida e se viene superata correttamente il client può entrare.  • Questa  fase  è  opzionale  poiché  la  diffusione  di  certificati  non  è  così 

grande poiché vi sono problemi nell’utilizzarli. La gente ha difficoltà nel gestire correttamente le password, figuriamoci con le chiavi private che sono anche solo concettualmente più complicate.  

o Una volta  che un canale SSL è  stato  instaurato, abbiamo detto  che altre due  funzioni irremovibili  sono  autenticazione  e  integrità,  quindi  tutti  i  dati  vengono  protetti  per autenticazione  ed  integrità  tramite  keyed  digest.  In  particolare  lo  standard  definisce MD5 o SHA1 come algoritmi di hash di base con una chiave simmetrica concordata tra server e client.  In più per evitare  la cancellazione e  il  replay ogni  segmento SSL viene numerato  tramite un MID, message  identifier  (quindi  in questo modo non è possibile duplicare  o  cancellare  i  dati),  un  numero  progressivo.  Qui  a  differenza  di  quanto avevamo  detto  con  IPsec  in  cui  avevamo  precisato  che  poiché  IPsec  lavora  con  IP (servizio best‐effort senza garanzie di consegna né sull’ordine) non aveva la necessità di andare a numerare i pacchetti con 1,2,3 … ma li potevamo anche chiamare pippo,pluto, paperino…, qui invece sfruttando un protocollo di trasporto affidabile che mi garantisce consegna e ordine di consegna ha importanza che siano numeri e che siano progressivi!  

SSL – Riservatezza   Per quanto riguarda  la riservatezza,  il client genera una session key quindi una chiave generata al volo possibilmente mai più  riutilizzata.  La  chiave può essere  comunicata al  server  cifrandola  con  la  chiave pubblica del  server e  il  server, che ha  la chiave privata, provvederà a decifrarla e da  lì  in poi client e server useranno quella chiave per  la cifratura simmetrica dei dati con uno degli algoritmi ammessi da SSL  (RC2, RC4, DES, 3DES o  IDEA). Lo scambio di chiavi può anche essere concordata sfruttando Diffie Hellman oppure Fortezza‐KEA   (il sistema proprietario dei militari americani ed è una variante di Diffie Hellman).   SSL  

  A questo punto vediamo come opera SSL, e l’esempio di applicazione pratica che si è deciso di usare è quello di un browser che desidera parlare con un server. In generale, vediamo a destra un client SSL e a sinistra un server SSL. Seguiamo a questo punto le interazioni:  

1. Innanzitutto bisogna che il client dica al server che desidera parlare SSL; questo viene fatto con la url https. 

2. Una volta che il client ha avvisato il server e sta parlando SSL, la prima operazione svolta dai due nodi è quella di scambiarsi la loro configurazione di sicurezza :  

o Per configurazione di sicurezza si intende che ognuno dei due dichiara gli algoritmi che è in grado di supportare. Si tratta di una negoziazione: lo standard prevede che i due nodi scelgano l’algoritmo più forte in comune tra di loro (sia che si parli di riservatezza a sia che si parli di autenticazione e integrità). Quindi gli algoritmi sono stati messi in scala di preferenza.  

o Può  capitare  che  in questa  fase  i due nodi non  trovino niente  in  comune  fra di  loro, quindi il collegamento si può interrompere già a questo livello.  

3. Una  volta  che  i  sistemi  hanno  trovato  una  configurazione  comune  il  primo  passo  è  quello dell’autenticazione del server.  Il server manda  il proprio certificato che deve contenere come common name  (CN) o come subject alternative name di tipo DNSname  lo stesso  identificativo dell’applicazione a cui mi sto collegando. Poiché mandare  il certificato come detto non serve a niente perché essendo un dato pubblico chiunque può copiarlo, il client gli invia una sfida a cui deve  rispondere correttamente. Se  il  server non  risponde correttamente,  il collegamento può essere interrotto a questo punto. 

4. Opzionalmente  (ecco  il motivo  della  linea  tratteggiata  rappresentata  in  figura),  il  server  può chiedere anche al client di mandare  il certificato X.509 e di  rispondere ad una sfida. Anche  in questo caso se la sfida fallisce il collegamento viene interrotto. 

5. Se tutti questi passi hanno avuto successo il client e il server sono in grado di crearsi un canale sicuro sul quale gli attacchi  (frecce rosse) rimbalzeranno 

 Esistono varie versioni di SSL  (SSL‐2, SSL‐3, TLS 1.0, TLS 1.1). Dal punto di vista architetturale  il grosso cambiamento è  stato  introdotto quando  si è passati da SSL‐2 a SSL‐3.  Infatti SSL‐2 era   un protocollo molto basilare, mentre SSL‐3 cominciava a diventare un protocollo strutturato, ben  fatto.  Infine  il TLS aggiunge soltanto delle piccole modifiche e non cambia l’impianto.   Architettura di SSL‐3  

 SSL‐3, come vediamo, è stratificato sopra un protocollo di rete affidabile, quindi sopra questo (che ad esempio, come detto non è un vincolo, può essere TCP) vediamo il cosiddetto SSL Record Protocol, ossia un formato per trasportare dati da un capo all’altro del canale. Questo Record Protocol di SSL serve per “imbustare” i dati applicativi una volta che il canale è stato creato, ma viene anche utilizzato dal protocollo SSL nella prima fase, che è anche detta fase di handshake che viene quindi veicolata sopra il Record Protocol di SSL: l’ SSL Handshake Protocol è il protocollo con il quale ci si mette d’accordo su quali algoritmi andare ad usare. Quando capita che si verifichi un attacco SSL prevede un piccolo protocollo che serve per comunicare che si è verificato un errore. Questo protocollo prende il nome di  SSL  Alert Protocol con cui client e server si scambiano gli allarmi. E’ anche possibile dirante una sessione SSL decidere di cambiare o gli algoritmi o le chiavi o entrambi, e questo lo si fa con l’SSL Change Cipher Spec Protocol.  Architettura di SSL‐2  SSL‐2 come già detto è un protocollo estremamente più semplice  in quanto non prevede gli allarmi e non prevede di cambiare in corso di trasmissione i parametri o gli algoritmi decisi in fase di scambi della configurazione di sicurezza. 

Session‐id 

Adesso  consideriamo un piccolo problema.  L’introduzione di  SSL  complica non poco una  transazione Web.  

1. open, 2. GET page.htm, 3. page.htm, 4. close  1. open, 2. GET home.gif, 3. home.gif, 4. close  1. open, 2. GET logo.gif, 3. logo.gif, 4. close  1. open, 2. GET back.jpg, 3. back.jpg, 4. close  1. open, 2. GET music.mid, 3. music.mid, 4. close 

 Infatti  tipicamente  aprendo  con  il  server web  una  connessione  alla  porta  80  per  ottenere  la  pagina page.htm, quello che viene fatto è che il server ci trasmette la pagina,  e chiude (a meno di uso di http v1.1 che come sappiamo permette le connessioni persistenti). Nel momento in cui prova a visualizzare la pagina  si  accorge  che manca  l’oggetto  home.gif,  quindi  aprirà  una  nuova  connessione  e  richiederà l’oggetto home.gif, e  anche  lì una  volta  che  il  server  ci ha  fornito  l’oggetto  chiuderà  la  connessione. Questo  discorso  vale  per  ogni  oggetto  che  compone  la  pagina. Ma  se  per  ogni  oggetto  si  devono rinegoziare  parametri  crittografici  per  SSL  il  collegamento  si  appesantisce  molto.  Infatti,  la  fase  di negoziazione è l’unica in cui si utilizzano gli algoritmi asimmetrici che sono quelli più pesanti dal punto di vista computazionale, quindi andiamo a ripetere proprio la parte più pesante. Per evitare di rinegoziare ogni  volta  i  parametri  e  rifare  l’autenticazione,  e  quindi  appesantire  troppo  i  collegamenti,  è  stato introdotto  il concetto di SSL Session  Identifier. Si può cioè dire che ogni collegamento fa parte di una medesima sessione logica, ossia: 

• quando mi presento il server mi fornirà un numero, che sarà il Session Identifier, sottolineando il fatto che ha concluso con successo la transazione con noi  

• il  client  la  volta  successiva  il  client  potrà  fornire  questo  numero  identificativo  al  server  per sottolineare il fatto che già una volta hanno negoziato i parametri e si sono autenticati. Questa cosa  è  opzionale,  nel  senso  che  il  server  numera  sempre  tutte  le  sessioni,ma  se  vuole  può rifiutare  l’uso del Session  Identifier.  In particolare  lo può  rifiutare  in assoluto, quindi  rifiutarlo sempre,  oppure  anche  nel  caso  di  server  che  accetti  di  continuare  la  sessione  precedente potrebbe  non  accettare  il  Session  Identifier  dopo  un  certo  lasso  di  tempo.  Infatti,  i  Session Identifier  devono  essere  sempre  mantenuti  all’interno  di  una  tabella,  e  questa  potrebbe crescere molto  in  dimensioni  qualora  il  server  ricevesse  tante  richieste  al  secondo. Quindi  il suggerimento  è  accettare  il  Session  Identifier ma  limitarne  la  validità  nel  tempo  in modo  da avere anche un meccanismo per poter sfoltire quella tabella. Lo scopo non è quello di evitare l’handshake nell’arco di giorni, o di un  lungo periodo di tempo, bensì quando  io mi presento a raffica come nel caso di una pagina web. Infatti quello che viene detto è che la vita di un session identifier dovrebbe essere limitata a qualche minuto. 

Qui di seguito riportiamo la figura che mostra il modo in cui cambia la fase di handshake nel caso in cui il server accetti l’uso del Session Identifier: 

 

 

 

 

SSL con session‐ID 

 

Notiamo che i passi sono i seguenti: 

1. Come sempre bisogna che il client dica al server che desidera parlare SSL; questo viene fatto con la url https. 

2. A questo punto, ancora prima che  inizi  la  fase di  scambio della configurazione di sicurezza,  il client fornisce al server il Session Identifier.  

3. Il  server  a  questo  punto  dirà  che  il  client  dichiara  di  avere  il  “lasciapassare”, ma  potrebbe benissimo essere un impostore, che quindi ha scelto un numero a caso e ha indovinato, quindi se il client conosceva veramente il Session Identifier, e di fatto non ha solo avuto fortuna, allora puoi  farmi  le  tue domande, ma me  le dovrai  fare  su un  canale  sicuro!  Il  che  significa  che  le domande devono contenere il keyed‐digest fatto con l’algoritmo giusto, con la chiave giusta, e i dati dovranno essere cifrati con l’algoritmo giusto e così via. Se il client era un impostore, allora non riuscirà a mettere i codici di protezione giusti e verrà quindi rifiutato.  

 Quindi ancora una volta questa cosa mi permette al più di fare un DoS, ovvero terrò temporaneamente impegnato  il  server  per  controllare  i  dati.  Ma  poiché  il  keyed‐digest  è  la  prima  cosa  che  viene controllata, ed è anche quello più veloce da calcolare e quindi verificare, non appena quello non torna si chiude!  

Una piccola nota riguarda  il fatto che  lo scambio della configurazione di sicurezza avviene  in chiaro,  in quanto ancora non è stato creato il canale SSL, ma anche a voler conoscere gli algoritmi, non si sapranno comunque  le chiavi da usare che verranno  invece scambiate o concordate con uno degli algoritmi visti prima (RSA, DH o Fortezza‐KEA).  

 SSL‐3 record protocol  Una volta che viene creato  il canale, abbiamo detto che  i dati verranno automaticamente protetti nel momento in cui l’applicazione farà una write su questo socket sicuro. Quindi a partire da uno stream di dati applicativi, io provvederò a scriverli sul canale senza alcuna particolare preparazione. Quello che SSL o  TLS  fa  è  prendere  i  dati  applicativi  e  creare  i  cosiddetti  fragment,  ovvero  i  frammenti.  SSL  può trasmettere in un colpo solo fino ad un massimo di 214 byte, può anche trasmetterne di meno: quella è quindi  la dimensione massima di un frammento. E’  importante notare che  i frammenti SSL non hanno niente a che fare con i frammenti delle reti TCP‐IP. Ognuno di questi frammenti può essere opzionalmente compresso; la compressione non è obbligatoria ma è utile sia perché riduce la quantità di dati da trasmettere quindi migliora la velocità di trasmissione , sia perché tende a togliere  le similitudini che ci sono all’interno dei dati  ( e come già detto  in passato cifrare dei dati compressi è meglio che cifrare i dati normali, non soltanto per una minore quantità ma anche perché si è già tolta una ridondanza nei dati di partenza e quindi si complica la vita agli eventuali attaccanti).  Sul frammento, normale o compresso, viene calcolato un MAC tramite un keyed‐digest, e questo codice con  doppia  funzione  di  autenticazione  e  integrità  viene  aggiunto  in  coda. A  questo  punto  se  stiamo usando un algoritmo di cifratura a blocchi, viene  fatto  il padding  ,  in modo da renderlo di dimensioni 

opportune perché  l’algoritmo possa cifrarlo, e questo viene cifrato, e gli si aggiunge un piccolo header (che dichiara che questo è un frammento SSL).   

  Questo viene consegnato al livello sottostante, tipicamente il TCP, perché possa essere trasmesso.   TLS‐1.0 record format  Questo  pacchetto  costituito  da  header  insieme  al  payload  cifrato  corrisponde  esattamente  a  questo formato. 

 Analizzandolo nel dettaglio, notiamo che l’header è costituito dai seguenti campi: 

[uint8]  type  :  può  assumere  i  seguenti  valori  a  seconda  di  quello  che  sta  trasportando  : change_cipher_spec (20), alert (21), handshake (22), application_data (23) 

[uint16]  version  = major  number[uint8]  + minor  number[uint8]  ,  intesi  come major  e minor number di SSL, quindi vedremo una cosa curiosa che quando si è passati a TLS si è continuata la numerazione quindi nel TLS v1.0  in realtà noi troveremo 3.1 per dire che è  il successore di SSL 3.0 

[uint16]  length: mi dicono quanti sono  i dati che seguono. Anche se sono 16 bit,  la  lunghezza scritta qua dentro non può mai superare 214  . Notiamo che nel caso  in cui si stia trattando un record compresso, allora al massimo la compressione può aggiungere 1024 byte al blocco base. In ogni caso, una volta decompresso, la quantità di dati DEVE STARE ALL’INTERNO DI UN BUFFER DA 214 BYTE. Quindi, per il campo length, i valori possibili sono: 

<= 214 (record non compressi) per compatibilità con SSL‐2  <= 214 + 1024 byte (record compressi) 

TLS ‐ calcolo del MAC  Il calcolo del MAC viene fatto nel seguente modo. Si usa un algoritmo di digest (MD5 o SHA‐1), e viene usato nel seguente modo:  MAC = message_digest( key, seq_number || type || version || length || fragment ) 

  message_digest

dipende dall’algoritmo scelto  key

vengono  negoziate  due  chiavi  che  risponde  alla  direzionalità  in  cui  sta  avvenendo  lo scambio dati, una dal client al server, l’altra dal server al client. Quindi bisogna usare la chiave giusta per la direzione a cui corrisponde questo flusso di dati 

seq_number intero a 32 bit 

 

Quindi  il  keyed‐digest viene  calcolato  sulla  chiave e anche  su  tutto  il pacchetto  (header più payload) quindi non mi protegge solo i dati, ma anche tutti i campi dell’header. Viene protetto nella sua interezza tutto  il record TLS. Notiamo  inoltre che  il campo dedicato al numero di sequenza è un campo a 32 bit, questo significa che una volta che quel campo arriva al suo valore  limite 232 frammenti,  il canale verrà automaticamente chiuso perché altrimenti potrebbe verificarsi un overflow su questo campo e non si riuscirebbe più a riconoscere correttamente il replay. E’ da notare inoltre che nelle ultime versioni sia di Firefox che di  Internet Explorer, è stato  rimosso SSL‐2 dall’elenco dei protocolli di sicurezza abilitati e questo perché SSL‐2 conteneva dei bachi di sicurezza. 

SSL‐3: novità rispetto a SSL‐2  Vediamo quali novità ha introdotto SSL‐3 rispetto ad SSL‐2: 

compressione dei dati:  opzionale  viene fatta prima della cifratura (in quanto se fatta dopo non servirebbe!! ) 

opzionalità della cifratura dei dati:  per avere solo autenticazione e integrità 

possibilità di rinegoziare la connessione:  cambio periodico delle chiavi  cambio degli algoritmi 

 SSL‐3 handshake protocol  Concentriamoci a questo punto sull’Handshake Protocol. Questo è uno degli elementi caratterizzanti di SSL  e  lo  usiamo  come  esempio  per  capire  come  operando  su  un  canale  insicuro  si  possa  creare un’associazione sicura tra due nodi. In particolare l’Handshake Protocol assolve le seguenti funzioni: 

concordare una coppia di algoritmi per confidenzialità ed integrità dei dati   stabilire una chiave simmetrica tramite operazioni a chiave pubblica (RSA, DH o Fortezza‐KEA)  scambiare  dei  numeri  casuali  tra  client  e  server  per  la  successiva  generazione  le  chiavi  che serviranno per confidenzialità ed integrità 

negoziare il session‐id  scambiare i certificati necessari  

Confidenzialità dei dati 

Ci  sono un numero  troppo  elevato di  chiavi.  Infatti uno potrebbe essere portato a pensare  che questo problema  non  sussista  in  quanto  il  client  potrebbe inventare una chiave, comunicarla al server e il gioco è  fatto.  In  realtà  vengono messe dentro  tantissime chiavi: ad esempio per il MAC usiamo la chiave e poi tutto  il  record  costituito  da  header  più  payload.  Il MAC  lo  mettiamo  in  coda  al  pacchetto,  e  tutto 

questo viene cifrato con un algoritmo simmetrico che di solito  richiede non solo un  IV  (ovviamente è necessario un vettore di  inizializzazione se è stato scelto un algoritmo di tipo a blocchi) ma anche una chiave simmetrica che è diversa da quella che abbiamo utilizzato per calcolare il MAC.  

Rapporto tra chiavi e sessioni 

Ad  ogni  connessione  (che  è  una  cosa  diversa  dalla sessione  ,infatti  una  sessione  quella  a  cui  fa riferimento  il  session‐id  è  costituita  da  più connessioni,  mentre  una  connessione  è  un collegamento, un canale, un socket aperto e chiuso) il  client  e  anche  il  server  generano  un  numero casuale.  Questi  numeri  serviranno  per  alterare  in qualche  modo  quei  segreti  che  invece  saranno comuni  a  più  connessioni.  In  particolare  quello  che 

viene stabilito attraverso  la crittografia asimmetrica  (PKC) non è direttamente una chiave bensì  il pre‐master secret, ovvero un segreto comune a client e server, quindi  la prima volta se  io non ho già un session‐id  quello  che  viene  scambiato  è  questo  pre‐master  secret:  è  questo  quello  che  si mantiene quando viene riutilizzato un certo session‐id.  

Dall’unione  del  pre‐master  secret  e  dei  numeri  random  viene  generato  un master  secret.  I  numeri random (client random e server random) sono generati tra client e server ad ogni connessione:  

la prima  volta questi  random  sono usati per  creare  il master  secret  (solo  la prima  volta; per questo motivo la freccia è tratteggiata) 

invece, ad ogni connessione, questi numeri random assieme al master secret vengono usati per una  serie  di  algoritmi  per  generare  le  chiavi  per  il MAC,  le  chiavi  per  cifrare  e  il  vettore  di inizializzazione  (IV)  per  cifrare. Queste  chiavi  qui  sono  diverse  per  ogni  singola  connessione, quindi  ciò  che  un  server  si  va  a  tenere  in memoria  assieme  al  session‐id  quando  accetta  un session  identifier  è  gli  algoritmi  che  abbiamo  scelto,  il  pre‐master  secret  ed  anche  il master secret. Quindi come chiavi sono queste due quelle che lui si tiene, le altre sono calcolate di volta in volta.  

Le operazioni di chiave pubblica sono  fatte solo quando si genera un master secret, e sono  in questo modo ridotte.I meccanismi possono essere di due tipi: permanenti ed effimeri. 

Meccanismi permanenti  Il client decide una chiave simmetrica e la spedisce al server cifrandola con la chiave pubblica del server. Se qualcuno scopre la chiave privata del server è in grado di leggere tutte le informazioni generate (se si usa sempre la stessa chiave pubblica). 

Meccanismi “effimeri”  Si chiama meccanismo effimero un meccanismo che usa delle chiavi che non verranno mai più utilizzate. Quindi delle chiavi cosiddette usa e getta generate al volo.  Al posto di avere delle chiavi asimmetriche permanenti può creare le chiavi al volo (e generando al volo la chiave pubblica vuol dire che non la potrò fare certificare dalla CA perché la procedura è troppo lunga, quindi il server si genera al volo la chiave pubblica e la chiave privata e se la autocertifica attraverso un certificato X.509.  Inoltre  se uso DH  allora  sarà  adatto  in quanto DH è  veloce nella  generazione delle chiavi, mentre RSA è lento, quindi se voglio usare RSA come compromesso dovrò riusare la stessa chiave 

N volte (genererò una nuova chiave per il server dopo un certo lasso di tempo o dopo un certo numero di volte). Perché può essere utile  il meccanismo usa e getta? Perché attraverso questo meccanismo si può  garantire  la  perfect  forward  secrecy  :  noi  sappiamo  che  il  server  ha  una  chiave  pubblica  e  una chiave  private.  Immaginiamo  di  non  usare  la  soluzione  di  cui  abbiamo  appena  parlato, ma  di  usare sempre  la  stessa  coppia  chiave pubblica,  chiave private. Vuol dire  che  il  client  inventerà questo pre‐master  secret   e    lo manderà al  server cifrato con  la chiave pubblica del  server. Tutti  i client  faranno questa operazione. In mezzo c’è un cattivo che sta facendo sniffing, e registra tutti  i pacchetti e anche l’handshake. Se prima o poi nel future riesce a catturare la chiave private del server, allora sarà in grado di  andare  a  cifrare  tutti  quei  pacchetti. Viceversa,  se  la  coppia  chiave  pubblica,  chiave  private  viene cambiata  frequentemente, allora  il  cattivom  sarà  in grado di decrifrare  solo  i pacchetti  scambiati per quell’istante di tempo, non i pacchetti precedenti e nemmeno quelli futuri. Con i meccanismi effimeri la chiave privata del  server  viene usata non per  ricevere  il  segreto  cifrato bensì  solo per  la  firma della chiave pubblica che verrà poi usata per lo scambio dei dati. 

Il server SSL ha nel suo certificato essenzialmente 2 cose: 

1. il bit di  key usage  che  indica Digital Signature, per  indicare  che questo  certificato può essere usato  per  fare  firma  digitale  perché  altrimenti  lui  non  riuscirebbe  a  rispondere  alla  sfida asimmetrica 

2. ha anche il bit di KeyEncipherment per poter ricevere il pre‐master secret crifrato dal client 

Queste  sono  logicamente  due  funzioni  diverse.  Il  discorso  dei  meccanismi  effimeri  è  relativo  alla seconda di queste, perché se io sto facendo sniffing di traffico cifrato non sono in grado di leggerlo ma se riuscissi a conoscere  la chiave privata allora potrei ricostruire tutte  le sessioni.  In particolare, con  la chiave usata per KeyEncipherment posso non solo ricostruire tutte le sessioni ma potrò avere in chiaro le  sessioni  future.  Il meccanismo  si  chiama di perfect  forward  secrecy perché  viceversa  se  io non ho usato la chiave del server per fare entrambe le cose ma io ho usato la chiave privata del server solo per digital Signature per  firmare una seconda chiave che è quella con cui viene  fatto  lo scambio chiavi: è questa  qui  la  chiave  effimera  che  viene  generata  ad  ogni  connessione.  In  questo  modo  anche  se qualcuno ne viene a conoscenza quella chiave sarà valida solo per quella connessione per cui non inficia la sicurezza delle prossime connessioni (per questo si chiama “forward” secrecy, sicurezza in avanti). 

Questi  sono  esattamente  i  messaggi  che  vengono  scambiati  tra  client  e  server  durante  la  fase  di handshake. Le  linee  in nero rappresentano  i messaggi obbligatori ovvero quelli che vengono scambiati sempre a prescindere da quale siano gli algoritmi usati, quelle tratteggiate sono tipicamente delle cose opzionali. Vediamole in sequenza:  

Innanzitutto il client manda il cosiddetto “client hello” a cui il server risponde con il suo “server hello”.  

Se necessario il server invia il proprio certificato ed eventualmente una richiesta di un certificato al client  

Segue una parte opzionale di scambio chiave   Il client può mandare il suo certificato se ce l’ha  l’unico passo obbligatorio è il “client key exchange”;   il client deve promettere la verifica del certificato.   Lo  scambio  termina    sempre  con un doppio handashake di basso  livello, nel  senso  che  sia  il client  sia  il  server mandano un  comando  “change  cipher  spec”  (fino  a questo punto  tutto  lo scambio è avvenuto in chiaro);  

I messaggi di handshake vengono protetti  a posteriori;   col “change cipher spec” ci si accorda su come proteggere  i dati da quel momento  in 

poi;   col messaggio  di  finished  sia  in  una  direzione  sia  nell’altra  viene mandato  in modo protetto un digest di tutti i dati che ci si è scambiati.  

quindi se qualcuno in mezzo (l’attaccante) aveva cambiato, per esempio, le dichiarazioni degli algoritmi del client viene fregato, dal momento che il server che riceve questi dati in modo  sicuro  (perché è  stata già attivata  la protezione), è  in grado di confrontare  il digest  calcolato  su  tutti  i  dati  che  ha  ricevuto  con  quello  inserito  all’interno  del “finished”.  

Quindi dentro  il finished c’è un digest che non è un digest del singolo messaggio ma di tutta la sequenza di handshake.  

 

Client hello  Il client con questo messaggio dichiara le seguenti cose :  

La massima versione di SSL che lui è in grado di supportare, quindi si assume che il client sia in gradi di usare anche le versioni precedenti. Questa sarà la versione preferita dal client 

28 byte generati in modo pseudo‐casuale per la generazione delle chiavi con il server  un identificatore di sessione (session‐id) 

0 per iniziare una nuova sessione o se non lo vuole usare  diverso da 0 per chiedere di riesumare una sessione precedente 

elenco delle  “cipher  suite”  (insieme degli algoritmi di  cifratura, algoritmo di  scambio  chiavi e algoritmo per autenticazione e per integrità dei dati) supportate dal client 

elenco dei metodi di compressione supportati dal client  Quindi con questo messaggio il client sta dichiarando le proprie capabilities.  Server hello  Il  server  risponde  anche  lui  con  un  messaggio  di  “server  hello”,  ma  senza  dichiarare  nulla  bensì effettuando direttamente le scelte. Quindi quelle che seguono, sono le scelte fatte dal server: 

versione di SSL scelta dal server  :  il server dovrebbe scegliere sempre gli algoritmi più forti tra quelli in comune tra lui e il client 

28 byte generati in modo pseudo‐casuale  un identificatore di sessione (session‐id) 

nuovo session‐id se session‐id=0 nel client‐hello oppure gli manda un nuovo session‐id se rifiuta il session‐id proposto dal client 

rimanda  indietro  il  session‐id  proposto  dal  client  se  il  server  accetta  di  riesumare  la sessione 

“cipher suite” scelta dal server  dovrebbe essere la più forte in comune col client 

metodo di compressione scelto dal server  Cipher suite  Come già detto, la cipher suite altro non è che un nome per identificare la triade costituita da :  

algoritmo di scambio chiavi  algoritmo di cifratura simmetrico  algoritmo di hash (per il MAC) 

 

Le cipher suite sono definite negli standard e tipicamente hanno dei nomi come quelli riportati sopra:  

SSL_NULL_WITH_NULL_NULL: cioè non viene protetto lo scambio delle  scambio chiavi, la cifratura simmetrica con 0 bit, e l’hash non viene fatto  

SSL_RSA_WITH_NULL_SHA:   scambio chiavi con RSA, ma cifratura 0 e algoritmo di hash SHA.   A  cosa  serve  l’algoritmo  di  scambio  delle  chiavi  se  la  cifratura  è  nulla?  Anche  se  la cifratura è nulla la chiave simmetrica serve anche al digest quindi è necessario avere un algoritmo di scambio chiavi.  

SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5: questo è un esempio di algoritmi che  si usavano quando c’erano dei limiti di esportazione 

RSA versione export  (RSA versione export: si hanno delle chiavi  limitate a 512 bit se si usano  per  cifrare  dei  dati;  in  questo  caso  RSA  è  per  scambio  chiavi  e  quindi  si  deve cifrare la chiave; quindi al massimo la chiave sarà da 512 bit) 

RC2 tagliato a 40 bit (perché più di questo non si poteva esportare).   SSL_RSA_WITH_3DES_EDE_CBC_SHA:  

scambio  chiavi  con RSA  (pieno, non versione export),  cifratura  con   3DES  in modalità EDE CBC,   algoritmo di hash SHA che è SHA‐1 (in quanto SSL non ha ancora recepito  le versioni successive di SSL).  

 

Certificate (server) 

Il messaggio certificate del  server manda  il certificato per  la  server authentication. Come già detto  in precedenza, bisogna prestare attenzione al fatto che  il campo subject o  il campo subjectAltName deve coincidere con l’identità del server. Se abbiamo usato come URL l’indirizzo IP allora nel certificato deve esserci l’indirizzo IP. Inoltre il certificato può essere solo di firma o anche per la cifratura:  

il  certificato  ha  un  campo  particolare  che  si  chiama  keyUsage  che  dice  per  quali  scopi  il certificato può essere utilizzato 

se  in questo  campo  c’è  scritto  che è usato  solo per  la  firma allora poi è necessaria  la  fase di server‐key Exchange, perché se è solo di  firma allora vuol dire che questo certificato non può essere usato dal client al fine di inviare al server il pre‐master secret 

 Certificate request  E’ quello con cui  il server  richiede  l’autenticazione del client e nel  richiedere  l’autenticazione  il server manda al client anche la lista delle CA che il server ritiene fidate : questo è importante in quanto il client può anche avere dei certificati, ma il server dichiara quali sono le CA che lui ritiene fidate quindi il client dovrà mandare il certificato solo se emesso da una delle CA che compare in quella lista. Qualora non ne abbia uno allora potrà fare a meno di inviarglielo. 

Server key exchange 

Come già detto questa fase è fondamentale se il certificato del server non è valido per fare la cifratura, quindi se il server ha un certificato RSA valido solo per fare la digital signature. Inoltre, è richiesto questo messaggio anche nei seguenti casi:  

server ha certificato RSA solo per firma  si usa DH anonimo o effimero per stabilire il master‐secret  ci sono problemi di export e si devono usare chiavi RSA/DH temporanee  Fortezza 

 Questo è l’unico messaggio con firma esplicita da parte del server , ovvero il server manda o i parametri 

Diffie  Hellman  o  la  chiave  che  ha  generato  al  volo  e  la  manda  firmata  con  la  chiave  presentata precedentemente. Questo è l’unico messaggio che richiede la firma da parte del server. Inoltre notiamo che  in termini di prestazioni usare meccanismi effimeri richiede maggio tempo nella fase di handshake perché  richiede una  firma  esplicita da parte del  server  :  ricordiamo  infatti  che  le  verifiche RSA  sono veloci, mentre le firme RSA sono lente.  Certificate (client) 

Come già detto, questo messaggio trasporta il certificato per la client authentication, e deve essere stato emesso da una delle CA fidate elencate dal server nel messaggio Certificate Request.  Client key exchange  Questo messaggio assume varie forme a seconda di quello che abbiamo scelto di fare. Può essere:  

pre‐master secret cifrato con la chiave pubblica RSA del server (temporanea o dal certificato)  parte pubblica di DH  Fortezza 

 Per quanto riguarda lo scambio di chiavi può capitare che:  

il client mandi un pre‐master secret cifrato con la chiave pubblica RSA del server (se si tratta di una  chiave  RSA  temporanea  oppure  se  il  certificato  permette  crittografia  con  la  chiave crittografica) 

oppure se il server accetta una scambio Diffie Hellman allora il client gli manda la parte pubblica di Diffie Hellaman o i parametri di fortezza che sono analoghi ai parametri pubblici di DH.  

 

Certificate verify  Nella fase di certificate verify si fa la prova esplicita di firma; in particolare il client firma con la propria chiave privata l’hash calcolato su tutti i messaggi che precedono questo. Quindi questa è la parte di sfida nei confronti del client.  Inoltre questa parte viene  fatta solo se  il client alla richiesta del certificato ha risposto con un certificato valido rispetto alla lista delle CA fidate che gli è stata comunicata dal server.  Change cipher spec  Questo messaggio provoca  l’aggiornamento degli algoritmi da usare per  la protezione, e permette di passare  dai  messaggi  precedenti  in  chiaro  all’uso  nei  messaggi  successivi  degli  algoritmi  appena negoziati. A rigore come visto prima fa parte di un protocollo specifico e non dell’handshake. Secondo varie analisi potrebbe anche essere eliminato, ma al momento questo resta.  Finished  Il finished è  il primo messaggio protetto con gli algoritmi negoziati, ed è fondamentale per autenticare tutto lo scambio. Ricordiamo infatti che i messaggi scambiati prima sono in chiaro, e qualcuno potrebbe essersi messo in mezzo e quando si negoziavano gli algoritmi potrebbe aver forzato il client all’utilizzo di algoritmi poco efficaci.  Il messaggio di  finished evita che si vengano a creare queste situazioni perché contiene  il MAC  calcolato  su  tutti  i messaggi di handshake precedenti  (tranne  il  change  cipher  spec) tramite  l’uso  del master  secret.  Permette  di  evitare  attacchi man‐in‐the‐middle  di  tipo  rollback  (  i rollback  sono  quelli  che  fanno  scendere  il  livello  di  protezione  che  si  è  scelto).  Sono  necessari  due messaggi di finished. Il messaggio di finished è ovviamente diverso per  il client e per  il server visto che conterrà il MAC calcolato sui messaggi che il client ha mandato al server, e che il server ha mandato al 

client, e poiché questi sono diversi anche i finished saranno diversi.  TLS  Quando  si decise di  standardizzare SSL e quindi quando SSL è  stato aperto all’IETF, ne  fu  cambiato  il nome in TLS (Transport Layer Security): il cambio del nome è stato politico, poiché Microsoft non voleva accettare di  implementare una cosa con un nome creato da un concorrente.Esistono due versioni TLS 1.0 del gennaio 99 e il nuovissimo TLS 1.1 (dell’aprile 2006).   Al 99% TLS‐1.0 coincide con SSL‐3. Una cosa  su cui  si è messo particolare accento è  stata  la  scelta di algoritmi non proprietari, quindi algoritmi su cui non fosse necessario pagare le royalty. La cipher suite che è stata scelta è stata la seguente:  

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA : quindi scambio chiami con DH effimero, firma DSS e cifratura 3‐DES EDE CBC con SHA per integrità. 

 L’unica  differenza  sostanziosa  è  che  il  key  digest  non  è  più  un  keyed  digest  generico,  inventato  da Netscape, ma un digest HMAC.   TLS‐1.1  In realtà il TLS 1.1 coincide dal 99% con la versione 1, ma corregge soltanto un paio di piccoli bachi che permettevano degli attacchi contro le varie versioni di TLS. In particolare c’erano alcuni attacchi contro il CBC. Quindi l’IV implicito è stato rimpiazzato da IV esplicito il che ha comportato che la dimensione dei pacchetti sia un pochettino cresciuta. Inoltre in caso di errori di padding ora usano il messaggio di alert  bad_record_mac  (invece  di  decryption_failed):  può  sembrare  un  dettaglio,  ma  questo  forniva  dei dettagli all’attaccante attraverso cui quest’ultimo poteva risalire alla chiave. Infine:  

1. In più  sono  stati definiti dei  registri  che  tiene  l’organizzazione  IANA per definire quali  sono  i numeri di protocollo 

2. Se  si  chiude  il  canale  prima  che  la  sessione  sia  conclusa,  il  session‐id  non  viene  cancellato; questo viene fatto per  migliorare le performance 

3. Poi  ci  sono  tutta una  serie di note  che  spiegano  l’interpretazione di  TLS nei  confronti di  vari attacchi possibili 

 Evoluzione di TLS  TLS continua ad evolversi e ci sono delle RFC che documentano delle aggiunte  

Kerberos si può usare per la parte di autenticazione  Si possono usare anche AES o algoritmi a curva ellittica   qualcuno ha anche inventato algoritmi tipo Camelia (che è un altro algoritmo simmetrico)  oppure è possibile avere una chiave cifrata a mano e precondivisa. 

 Queste  diversità  sono  dovute  al  fatto  che  si  possono  avere  ambienti  con  capacità  computazionali differenti  e  quindi  si  deve  avere  il  massimo  della  flessibilità.  Si    hanno  anche  diversi  metodi  di compressione,  infatti  in SSL‐3 era stata definita  la possibilità di negoziare gli algoritmi di compressione ma non era stata fatta menzione di quali algoritmi di compressione specificare. E’ stato quindi  inserito LSZ  che  è  l’algoritmo  di  compressione  alla  base  dello  ZIP,  e  inoltre  sono  state  aggiunte  anche  delle estensioni application‐specific.  DTLS (Datagram Transport Layer Security)  TLS ha avuto un così positivo impatto nell’ambito della sicurezza che si è deciso di sviluppare anche una 

versione per datagrammi. Notiamo  che  come  già  detto per  SSL/TLS  è necessario  che  il protocollo di trasporto sia affidabile, quindi si può applicare solo a TCP, però ci sono tantissimi protocollo applicativi che vengono veicolati su UDP. Ovviamente non si può trasporre direttamente SSL/TLS su UDP, perché vengono a cadere tutta una serie di fattori, e allora è stato sviluppato appositamente  il DTLS ovvero  il Transport  Layer  Security  orientato  ai  datagrammi,  riconoscendo  che  alcuni  servizi  di  sicurezza  non possono  essere  offerti.  Il  DTLS  è  una  versione  che  cerca  di  applicare  gli  stessi  concetti  del  TLS  alla sicurezza dei datagrammi, quindi per esempio UDP, ma non offre tutti i servizi di sicurezza di TLS. Il DTLS è attualmente in competizione con altre due soluzioni : se noi abbiamo un’applicazione basata su UDP abbiamo due scelte:  

IPsec : uso IPsec, quindi faccio sicurezza al livello sottostante rispetto a UDP  TLS : fare sicurezza applicativa (dei messaggi o dei dati securizzando il payload)  DTLS : securizzare UDP stesso 

 Se ad esempio trattiamo SIP, abbiamo 4 scelte possibili :   

1. con IPsec 2. con TLS (solo per SIP_over_TCP) 3. con DTLS (solo per SIP_over_UDP) 4. con secure SIP 

 notiamo che se scelgo IPsec o secure SIP sono indipendente dal livello di trasporto che è stato scelto per SIP.  Detto  questo,  andremo  ad  analizzare  alcuni  problemi  applicativi  per  securizzare  le  applicazioni  e  in particolare visto che oggi  la maggior parte delle applicazioni  sono veicolate  sopra http, cominceremo proprio da questo protocollo.  All’interno di HTTP‐1.0 sono già definiti dei meccanismi di sicurezza, e sono i seguenti:  

“address‐based” = il server controlla l’accesso in base all’indirizzo IP del client  “password‐based” (o Basic Authentication Scheme) = accesso limitato da username e password, che vengono  trasmessi codificati con Base64, quindi NON SONO CIFRATI,  infatti Base64 è una funzione perfettamente invertibile 

 Ovviamente  entrambi  gli  schemi  sono  altamente  insicuri  , ma  è  da  notare  che  nell’RFC  dell’HTTP  si dichiara di usare HTTP solo su canali sicuri. HTTP/1.1 migliora un po’ la situazione in quanto introduce la  “digest  authentication”  con  cui  si  continua  ad  usare  la  password  ma  la  si  utilizza  per  una  sfida simmetrica,  quindi  la  fase  di  autenticazione  è  diventata  un  po’  più  robusta.  Nell’RFC‐2617  “HTTP authentication: basic and digest access authentication”, vengono riassunti entrambi i meccanismi.  HTTP ‐ basic authentication scheme  

  Consideriamo adesso  il meccanismo di Basic Authentication. Abbiamo aperto un canale HTTP e stiamo facendo una domanda al server, quindi  la GET di una pagina. Questa pagina che stiamo richiedendo è protetta, ma di fatto non c’è alcun modo per saperlo,  infatti non esiste un meccanismo per dichiarare 

nella URL che una pagina sia protetta. Quello che ci capita, è beccarci una errore 401, che è l’unico caso in cui anche nella versione HTTP 1.0  il server non ci chiude  la connessione,  in quanto  lui sa benissimo che  l’utente  fosse  ignaro  che  la  pagina  richiedesse  autenticazione. Quindi,  gli  da  il  suggerimento,  se veramente  l’utente  vuole  accedere  a  quella  pagina,  di  autenticarsi,  e  lo  richiede  facendo  seguire all’errore HTTP anche l’header:  WWW‐Authenticate: Basic realm="RealmName"    dove  richiede  di  autenticarsi  in  questo  caso  con  il meccanismo  Basic  Authentication  per  il  dominio “RealmName”. Non bisogna  fare  tra questo  reame e  il  reame di Kerberos,  infatti mentre  il  reame di Kerberos è costituito da tutte le macchine che si sottomettono al sistema di autenticazione di Kerberos, questo qui invece è solo un nome di fantasia, ed è quello che viene usato dal Pop‐Up per dire all’utente che deve  immettere Username e Password per  il reame specificato  (altrimenti  l’utente non capirebbe quail credenziali usare se solo non sapesse il reame nei confronti del quale è richiesta l’autenticazione). Il popup non  è  applicativo,  e quindi non  è bloccante,  ed  è una  reazione  automatic del browser non disabilitabile.  Inviando  le  credenziali,  riceviamo  un  altro  header  che  dice  che  sta  provando  ad autenticarsi con quell meccanismo (Basic) seguito da username e password codificati  in Base64: quindi chi  fa  sniffing  sulla  rete  li può  leggere  e ottenerli,  inoltre poichè  il  server dovrà  autenticare  l’utente dovrà conoscere username e password in chiaro, e se il calcolo fatto dal server va a buon fine, visto che il  canale  è  ancora  aperto  ci  manderà  header  e  body  della  pagina  HTTP.  Ovviamente  fare  queste operazioni su un canale non cifrato mette a serio rischio di intercettazione di username e password, ed ecco quindi l’interesse ad usare HTTP sopra un canale SSL o TLS dirsi voglia.   HTTP e SSL/TLS  Abbiamo due alternative in questo caso:  

“TLS then HTTP” (RFC‐2818 – HTTP over TLS) – url https  :  implica che  io prima apro un canale sicuro e poi sopra questo veicolo il protocollo HTTP 

“HTTP then TLS” (RFC‐2817 – upgrading to TLS within HTTP/1.1) : apro il canale HTTP non sicuro, ed esiste un commando dentro il protocollo HTTP per richiedere di securizzare il canale 

 Notiamo che “SSL then HTTP” è largamente usato, ma in realtà coincide con la prima solo che si usa SSL e non TLS, ma non è documentato. Inoltre, la prima soluzione è ad oggi quella largamente usata, ma si assiste a continue pressioni da parte di  IETF e W3C al  fine di usare  la seconda soluzione  : PER QUALE MOTIVO?  A  loro  non  piace  il  fatto  che  esistano  due  URL  diverse,  ovvero  l’http  e  l’https. Qualcuno obbietta al fatto che http non sia sicuro,  infatti se stiamo usando http su  IPsec allora è sicuro, mentre altri obbiettano al fatto che https sia sicuro infatti data l’esistenza delle ciphersuite con algoritmi NUL in quel caso di sicurezza ce n’è ben poca. Quindi la tendenza è quella di avere http e poi se si vuole rendere sicuro il canale allora lo si rende sicuro. Come  è  chiaro,  le due  forme non  sono  assolutamente  equivalenti  ed hanno un  grosso  impatto  sulle applicazioni  finale, sul  firewall ed  in generale sull’IDS.  Infatti se  io ho  fatto TLS  then HTTP, quando un firewall  si  vede  arrivare  un  traffico  cifrato  non  può  più  decidere  in  base  al  protocollo  applicativo  se lasciarlo passare o meno, infatti può anche darsi che sulla porta TCP 443 sia stato installato un servizio diverso e  il firewall  lo  lasci passare. Stessa cosa con  l’IDS. Viceversa se  io ho HTTP e poi TLS,  il firewall può vedere se quello è un canale HTTP , può vedere quando viene richiesto di rendere sicuro il canale. Anche sull’applicazione c’è un notevole  impatto,  infatti se  io  faccio TLS  then HTTP allora  il mio server può  ignorare  il  fatto che ci sia SSL, mentre se  faccio http  then TLS allora  il server dovrà riconoscere  il comando per richiedere di securizzare il canale e poi implementare le dovute misure di sicurezza.  E’ da notare che più  in generale si può estendere  il discorso anche ad altri protocolli applicativi,non solo ad http,  quindi  sebbene  l’RFC  faccia  riferimento  ad  http  di  fatto  il  discorso  che  stiamo  facendo  risulta estendibile anche ad altri protocolli applicativi.   

 Sicurezza del WWW  Conviene usare il canale SSL, per i seguenti motivi:  

protegge le transazioni  protegge le password applicative  

 Notiamo che  la password per Basic/Digest Authentication non è ancora  la password che  io uso dentro un  form, perchè questa autenticazione è  fatta prima ancora che sul browser mi arrive  la pagina web. Quindi come discuteremo meglio dopo con il web io ho almeno tre livelli di autenticazione:  

1. Posso mettere le password applicative (dentro i form) 2. Posso avere la password al livello di Basic Authentication 3. Posso avere autenticazione al livello SSL con la Client Authentication 

 Se abbiamo scelto di usare password per la Basic o la Digest Authentication abbiamo due scelte:  

Creare delle password apposite del servizio http, ovvero delle password per accedere al servizio http 

il server starà su un certo S.O. e l’utente dovrà pure essersi loggato sul sistema operativo, quindi si può anche richiedere la password del S.O. che ospita il server (es. NT o UNIX). Questo è molto comodo soprattutto quando abbiamo un dominio perché ho un dominio e uso  la password di dominio anche per questi scopi, ma non è una bella cosa, perché se per caso viene intercettata sul  canale  la  coppia username e password, quella non  servirà  solo per  loggarsi  col  server ma conterrà delle credenziali valide per il dominio.  

 Quindi anche se è più comoda  la seconda strada, si consiglia sempre di seguire  la prima creando delle password  apposite per  il  servizio http.  Esisteranno  inoltre delle ACL  che determineranno  in  funzione dell’autenticazione  che  diritti  si  hanno  sulle  varie  risorse  ,  quindi  sono  utili  per  regolare  l’accesso  ai documenti.  Client authentication SSL a livello applicativo  Abbiamo  detto  che  usando  SSL  è  anche  possibile  chiedere  la  Client  Authentication,  quindi  esiste  la possibilità che  il server chieda al client di mostrargli un certificato valido per autenticarsi nei confronti del  server. Questo  viene  fatto al  livello  SSL, quindi prima ancora  che  venga  creato  il  canale HTTP.  In realtà  qualcuno  dice  anche  che  questa  cosa  non  ha  molto  senso,  in  quanto  comunque  al  livello applicativo si dovranno comunque richiedere username e password per poter capire quale utente è, ma in realtà non è così : infatti SSL esporta al livello applicativo alcuni paramteri caratteristici tra cui anche i dati  con  cui  l’utente  si  è  autenticato. Quindi  con  questa  soluzione  c’é  la  possibilità  di  fare mapping automatici o semi‐automatici tra la credenziale estratta dal certificato e quella fornita ai livelli superiori. Il fatto che l’autenticazione sia stata fatta ad un livello più basso non preclude che questa rimanga nota al  livello  applicativo,  inoltre  è  completamente  trasparente  per  l’utente ma  non  gli  permette  di  fare “giochetti strani”.   Autenticazione nelle applicazioni web  Quindi riassumendo abbiamo 3 scelte :  

1. autenticazione al livello di canale SSL  2. autenticazione al livello di canale http (Basic/Digest Authetication) 3. autenticazione applicativa 

 

Queste  tre  soluzioni non  sono equivalenti.  In  figura  sono  stati  forniti dettagli  su quale  sia  il  software responsabile dell’autenticazione:  

canale SSL : ci sarà un’apposita libreria che permette di fare SSL  canale http : è compito del software server web (Apache o IIS)  applicazione : sarà l’application server o le pagine che abbiamo scritto 

 tipicamente queste tre cose sono organizzate a piramide, infatti SSL è una quantità di sotware piccola in quanto deve occuparsi solo di fare SSL, mentre il demone http deve fare tutto http. Infine l’applicazione sarà qualcosa di ancora più grosso.  Il  concetto è quindi prima  si  fa  l’autenticazione e meno  software stiamo esponendo agli attacchi, quindi  “più  in basso  si  fa  il  controllo e meno parti  si espongono agli attacchi”  . Questo  si  correla  con  un  concetto  che  fa  parte  di  quei  tentativi  di misurare  quando  un sistema sia sicuro o insicuro, che si chiama ATTACK SURFACE : dato un attaccante, qual è la superficie di attacco che lui ha a disposizione? Infatti più ristretta sarà la superficie, più bassa sarà la probabilità che l’attaccante trovi un attacco efficace.   

  Quindi se possiamo, facciamo la Client Authentication, ma anche se non possiamo farla è sempre meglio fare  la Basic/Digest Authentication piuttosto che ritardare  il controllo fino al  livello applicativo facendo quindi l’autenticazione applicativa, perché c’è molta più probabilità di aver commesso errori nella parte applicativa piuttosto che nel demone del server web. Notiamo che le frecce in blu indicano il mapping, ovvero l’autenticazione fatta ad un certo livello può essere trasferita come minimo con delle variabili di ambiente,ma molto spesso esiste la possibilità di fare dei mapping automatici.   Come introdurre username e password  Vediamo di toccare con mano  la situazione che si viene a creare. Supponiamo di trovarci su un sito di Internet Banking, e di dover introdurre le credenziali di accesso, ovvero username e password. A questo punto guardiamo  il form di  login, e vediamo che  in fondo alla pagina stessa c’è un  lucchetto aperto. A questo  punto  l’utente  si  incuriosisce  :  ma  il  lucchetto  non  dovrebbe  essere  chiuso  per  fornirmi sicurezza? La risposta che gli viene fornita è che in realtà metterlo chiuso prima o dopo è la stessa cosa. In realtà i conti non tornano, perché scegliendo questa strada username e password verranno trasmessi in modo INSICURO! Ma questa cosa è vera? No, in quanto tutto dipende da cosa viene fatto dopo che si clicca sul bottone “GO”, che corrisponderà ad una certa action e sarà  la ACTION a dire se andiamo su http o https. Ma così è un casino : perché l’unico modo per sapere come veramente verranno trattate le mie credenziali di accesso al servizio è andare a guardare la URI, e se nella URI c’è https per trasmettere i dati. Quindi la sicurezza effettiva dipende dalla URI del metodo usato per inviare username e password al server :   

tecnicamente, non importa la sicurezza della pagina in cui si introducono i dati  ma psicologicamente è  importante  la sicurezza della pagina  in cui si  introducono  i dati perché pochi utenti hanno  le conoscenze tecniche necessarie a verificare  la URI del metodo usato per l’invio 

 

Quindi,  seguendo  la  strada dell’esempio  che  abbiamo posto, noi  stiamo disabituando  gli utenti, e  gli stiamo dando un cattivo esempio perchè così facendo apriamo la strada per degli shadow server. Quindi 

l’utente dovrebbe essere abituato a vedersi richiedere le credenziali per autenticarsi solo su una pagina con un bel lucchetto. 

S‐HTTP 

Non è https, bensì una modifica del protocollo HTTP 1.0 sviluppata da EIT‐Terisa. Ogni commando ed ogni risposta (quindi request e response) vengono incapsulate in una busta sicura, che può essere di vari tipi : PEM, PGP o PKCS‐7.  E’ obsoleta, e non dobbiamo lasciarci ingannare dal fatto che ci siano delle RFC che  documentano  questo  protocollo  in  quanto  sono  delle  RFC  experimental  che  sono  stati  scritti  a futura memoria per documentare una cosa che per un certo periodo di tempo è esistita. S‐HTTP è stata la  contromossa  di  IBM,  infatti Netscape  ha  avuto  l’idea  di  SSL, Microsoft  ha  inventato  PCT,  IBM  ha inventato S‐HTTP ma anche questo è naufragato. 

Coesistenza di SSL con altri protocolli  SSL estende ad un livello inferiore gli altri protocolli di sicurezza, e può coesistere con altri protocolli di sicurezza  che  possono  essere  collocati  a  livelli  diversi  anche.  Con  la  stratificazione  è  possibile  avere misure  di  sicurezza  addizionali  una  sopra  l’altra,  nel  senso  che  sopra  TCP‐IP  è  possibile  decidere  di implementare SSL, il quale può essere usato o non usato da un protocollo che di per sé sarebbe insicuro:  

Per esempio si può usare telnet sicuro con SSL o telnet normale,   oppure SMTP con SSL o normale  (perché  la posta è già  sicura  se  si è ad esempio adottato  lo standard di posta  S/MIME).  

 Quindi attenzione a come SSL si combina con la sicurezza applicativa:   

la sicurezza applicativa sta a livello 7 e magari anche 7 e mezzo,   l’SSL è più a livello 4‐5 e quindi si può combinare con la sicurezza applicativa. 

 

SSH (Secure SHell) 

Per un certo periodo di  tempo una delle alternative a SSL è stato SSH. SSH è stato sviluppato da uno studente  finlandese  che  nell’ambito  di  un  corso  di  sicurezza  ha  sviluppato  come  tesina  la  riscrittura completa dei comandi R (rsh, rlogin, rcp) per renderlo sicuro. Lui ha sviluppato una soluzione che poi fu fondamentalmente utile anche in ambiti diversi da quello per cui fu sviluppato. Che cosa ci fornisce SSH? Vediamo:   

crittografia del canale  

utilizza DES, triplo DES, RC4, IDEA oppure ISS (algoritmo specifico finlandese)  la chiave di cifratura è una chiave di sessione scambiata in fase di connessione  

vari tipi di autenticazione:  

indirizzi IP (= rlogin + crypto) : questo vuol dire avere lo stesso tipo di autenticazione di rlogin con in più la parte di protezione dei dati trasmessi 

chiave RSA di host  : sfida asimmetrica con chiave assegnata a ciascun host della  rete, quindi ciò che viene identificato è l’host, ma non l’utente 

chiave RSA di utente  : è possibile assegnare chiavi RSA anche ai singoli utenti e quindi fare anche una sorta di client authentication 

 

Per quanto riguarda le implementazioni, è public‐domain per UNIX, mentre è commerciale per Windows anche  se  è  in  corso  di  sviluppo  anche  un’implementazione  public  domain  per  Windows.  Infine,  il protocollo in corso di pubblicazione come RFC.  

SSH – certificazione  Abbiamo detto che SSH usa ampiamente le chiavi RSA, il maggior problema è che SSH usa nella sessione base chiavi RSA ma non usa certificati di alcun  tipo! Usare  le chiavi pubbliche  senza certificati  induce problemi per  la  sostituzione delle  chiavi pubbliche  : ovvero  se qualcuno  riesce a  sostituirmi  la  chiave pubblica io non ho alcun modo di accorgermi di questa sostituzione in quanto la chiave pubblica non è certificata  in  alcun modo.  La  certificazione  o  la  garanzia  delle  chiavi  è  affidata  interamente  al  File System, quindi si assume che il file system sia adeguatamente protetto da intrusioni. In particolare : 

la  chiave  pubblica,  non  essendo  associata  ad  un  certificato  di  una  CA,  deve  essere  nota  alla controparte per poter essere verificata:  

i client tengono la chiave pubblica dei server in:  ~/.ssh/known_hosts 

  i server tengono le chiavi pubbliche dei client in: 

~/.ssh/authorized_keys  Il server manda la propria chiave pubblica, e a quell punto se era un server sconosciuto SSH avverte che è  stata  ricevuta una nuova  chiave, nel qual  caso  ci  chiede  se  la vogliamo memorizzare. Però già  solo averla ricevuta così pone molti dubbi. Viceversa  i server  tengono  le chiavi pubbliche dei client nel  file authorized_keys, quindi la sicurezza di queste chiavi pubbliche è affidata interamente alla sicurezza del File System e al fatto che nessuno possa manipolare queste cartelle e questi file.  

SSH ‐ protezione delle chiavi private  La chiave privata del server è conservata in chiaro in un file, e come sappiamo la cosa è estremamente pericolosa. Anche  in questo caso ci si affida pienamente alla protezione del  file System  lato server. Si suggerisce anche di tenere nascosto questo file (quindi un po’ di security through obscurity), e bisogna anche ricordarsi di cancellare il file di configurazione che dice qual è il file in questione. La chiave privata del client è conservata crittografata con un passphrase P. La passphrase viene richiesta all’utente  quando  occorre,  ed  esiste  un  programmino    (infatti  SSH  è  costituito  da  una  miriade  di programmini)  che  si  chiama  ssh‐agent  e  che  è  una  sorta  di  proxy,  al  quale  noi  comunichiamo  la password che rimuove  la protezione della chiave privata, e ci penserà  lui a dialogare con  tutti gli altri programmi della suite SSH trasmettendola quando necessario.  

SSH ‐ autenticazione dei client  Per  l’autenticazione  dei  client  abbiamo  detto  che  uno  dei meccanismi  è  quello  dell’autenticazione basata sull’indirizzo  IP, quindi  il server va a controllare quali sono gli  IP autorizzati. Nello standard dei comandi  “r”, questi definiscono degli host  che  sono  equivalenti, ovvero  se  si  fa  il  login  su una  certa macchina allora è possibile  collegarsi  a  tutte  le altre  senza dover più  fare  login. Questo è definito al livello  di  sistema  globale  se  questi  host  vengono  elencati  nel  file  /etc/hosts.equiv,  oppure  al  livello individuale  (di  singolo  utente)  se  nella  nostra  home  abbiamo messo  questi  altri  calcolatori  nel  file denominato ~/.rhosts. Come già ditto è anche possible fare autenticazione standard + RSA challenge: 

  il  client deve  rispondere  ad una  sfida  crittografica di  tipo  asimmetrico  (verificabile dal  server perché conosce le chiavi pubbliche dei client) 

il server verifica comunque ~/.rhosts e /etc/hosts.equiv  SSH ‐ autenticazione dei client  Per autenticare i client ho diverse possibilità:  

uso di login+password Unix all’interno di un canale crittografato  challenge RSA puro, ossia senza controllo dell’indirizzo IP 

 SSH ‐ autenticazione dei server  Viene fatta solo ed esclusivamente mediante challenge RSA.  

K‐commands  In  quei  sistemi  in  cui  è  implementato  Kerberos  può  essere  interessante  utilizzare  i  cosiddetti  k‐commands,    ossia  tutte  quelle  applicazioni  che  sono  state modificate  per  utilizzare  Kerberos. Questi comandi sono: 

K‐telnet, K‐ftp, Klogin, Kcp, Ksh, K‐POP  

Notiamo che Kerberos serve in due sensi: 

1. serve  innanzitutto  nella  fase  di  autenticazione  in  cui  Kerberos  è  in  grado  di  fornire mutua autenticazione del client e del server 

2. visto che tra client e server Kerberos stabilisce un segreto condiviso, questo segreto condiviso può  essere  usato  per  la  cifratura  simmetrica  e  il  keyed‐digest,  e  quindi  per  proteggere successivamente l’applicazione 

La parte di crittografia del canale con DES è opzionale. Non dobbiamo farci fuorviare nei k‐commands dal fatto che si usi Kerberos e che questo sia usato solo per autenticazione,  in quanto come visto può anche essere utilizzato per scambio chiavi. Di solito non si mette  in piedi Kerberos per utilizzare questi comandi, al più si va nel viceversa, ovvero se ho già Kerberos allora posso prendere  in considerazione l’idea di usare questi comandi.  

SSL‐telnet, SSL‐ftp, SSL‐rsh  Allo stesso modo, se abbiamo usato servizi come  telnet,  ftp ed  rsh con SSL   allora possiamo ripiegare sull’uso di SSL‐telnet, SSL‐ftp, SSL‐rsh. Si tratta di applicazioni standard modificate con trasporto SSL, e si appoggia  sulla  libreria  OpenSSL.  Ovviamente  usa  certificati  X.509.  E  permette  anche  la modalità  di funzionamento fall‐back, ovvero se l’autenticazione SSL fallisce si può: 

rifiutare la connessione  ricadere all’indietro (fall back) , e collegarsi col protocollo standard 

SSL‐x: autenticazione 

In tutti questi programmi tipicamente l’autenticazione consiste nel: 

il server è sempre autenticato:  

chiave privata in chiaro in un file  chiave privata conservata in un file cifrato con l’uso di una passphrase, che sarà richiesta all’avvio per aprire il file che contiene la chiave privata  

per default, il client è autenticato tramite login+password Unix ma su un canale crittografato  

opzionalmente  si può usare  la  client  authentication di  SSL;  in  questo  caso  la passphrase  che protegge la chiave privata è richiesta all’utente 

 

Uno  dei  più  comuni modi  di  usare  SSH  (di  tunnellizzare  un’applicazione),  è  per  la  protezione  di  X‐Windows, quindi adesso spendiamo due paroline su X‐Windows. 

Il sistema X‐windows (X11) 

 

X‐Windows è  il sistema grafico del mondo Unix e possiamo vederlo come una applicazione, con  i suoi requisiti  di  sicurezza  (e  sono  dei  forti  requisiti  di  sicurezza).  Notiamo  innanzitutto  l’inversione  di terminologia, infatti:  

client  :  sono  i  nodi  di  rete  che  svolgono  l’elaborazione,  perché  il  sistema  X‐Windows  è  un sistema Client/Server che serve a  fornire  il servizio di  Input e Output grafico a dei programmi che stanno svolgendo elaborazione. Quindi  i client  sono dei programmi che  stanno svolgendo elaborazione e che hanno bisogno di dialogare con degli utenti in rete  

Quindi  la nostra macchina  è un X‐server, perché offre  i  servizi di  video,  tastiera  e mouse  ad un’applicazione che gira da qualche parte in rete 

 Si  tratta  di  sistemi  eterogenei,  come messo  in  luce  dal  fatto  che  sull’X‐Server  abbiamo  due  finestre corrispondenti a due sistemi diversi tra loro. La sicurezza intrinseca di X‐Windows è molto bassa. Al livello di autenticazione tipicamente si basa sugli indirizzi IP. Vediamo tutti i meccanismi possibili di autenticazione:  

indirizzi IP ( xhost +host )  cookie : a partire da X11R4 è possibile usare i cookie, che sono un segreto condiviso con i quali è possibile poter fare una sfida di tipo simmetrico 

Kerberos V5 : a partire da X11R6  Notiamo  che  queste  sono  opzioni,  ovvero,  come  già  detto  il  default  è  l’indirizzo  IP,  ma  avere autenticazione debole significa che con le primitive di X11 (es. xwindump) posso catturare tutto l’I/O del 

terminale grafico (sia parte grafica che parte testuale) senza bisogno di fare sniffing! Per questo motivo ad oggi si tende a non usare più X‐windows senza i dovuti meccanismi di protezione al livello inferiore, ma lo si appoggia a IPsec o come minimo su SSH (la cui caratteristica è quella di creare un tunnel su cui veicolare protocolli di livello superiore).  Protezione della chiave private 

Il problema della protezione della chiave private l’abbiamo già citato prima, ma adesso lo riesaminiamo in questo contesto.  Tipicamente il problema della protezione della chiave private è grosso quando deve essere usata automaticamente da un qualche processo come ad esempio capita nel caso dei server.  Il modo più  facile è quello di  lasciarla  in chiaro dentro un  file  : è molto  facile ma richiede  la protezione complete  del  server.  La  seconda  possibilità  è  lasciare  questa  chiave  in  un  file  criptato  con  una poassword, vuol dire che nel momento  in cui si f ail boot del server deve essere presente una persona per  l’immissione  da  console  una  passphrase  che  permetta  di  decifrare  questo  file  e  di mettere  la versione decifrata non su disco, bensì in RAM. La cosa è un pochettino meglio, ma se qualcuno riesce ad avere  i privilegi di sistema può esaminare  tutta  la memoria RAM  (non solo quella del suo processo) e quindi andarsi a  leggere  la chiave.    In particolare ci sono dei piccolo programmi che analizzano tutto  il contenuto della RAM  e  beccano  a  colpo  sicuro dove  sono  le  chiavi.  La  cosa può  sembrare  strana  in quanto  in  RAM  non  c’è  un’indicazione  esplicita  di  dove  si  trovino  le  chiavi.  In  realtà  le  chavi  sono random,  mentre  tutto  il  resto  che  si  trova  in  RAM  ha  una  sua  regolarità,  quindi  semplicemente analizzando la distribuzione casual e facendo un raffronto si può andare a reperire in RAM la chiave. La soluzione migliore è che le chiavi non vengano date ma vengano memorizzate su un dspositivo sicuro e poi sarà  lui ad occuparsi di fare  le dovute operazioni crittografiche (ovvero  il concetto di SMART‐CARD che abbiamo già visto). 

Sicurezza degli accessi remoti a DBMS 

Dipende fortemente da come noi andiamo a sviluppare la nostra applicazione. Quindi:  

Se  usiamo  ancora  il  vecchio  stile,  ovvero  collegarci  in  emulazione  di  terminale,  cosa  che  chi sviluppa un sistema modern non usa più ma che in realtà è ancora presente in tantissimi sistemi per eredità dei vecchi sistemi, allora faremo emulazione di terminale su canale protetto (quindi SSL‐telnet, SSH, e così via) 

Se accediamo al DB tramite interfaccia WWW, anche qui la soluzione è abbastanza semplice in quanto  dovremo  applicare  la  protezione  del Web  (SSL),  più  sarà  un  nostro  pensiero  vedere come il server web si college al database 

Il vero problema degli accessi a database è  in modalità client‐server. Ossia quando al client è permesso fare direttamente via rete delle query al server, come ad esempio si fa sfuttando JDBC o ODBC. Qui la soluzione non è banale infatti JDBC o ODBC sono API, non sono un protocollo di rete, perchè non esiste l’SQL via rete. Non esistendo un protocollo via rete, non esiste nemmeno un metodo  standard  per  renderlo  sicuro.  Ecco  quindi  che  in  questa  situazione  ci  sono  due approcci: 

Approccio Microsoft  :  facciamo  sicurezza  ad  un  livello  inferiore,  quindi  si  usa IPsec su qualunque canale verso un database.  In questo modo qualunque cosa ci passi sopra sarà sicuro 

Chi  controlla  l’applicazione,  dirà  di  usare  le  estensioni  che  rendano  sicuro  il dialogo  client‐server  indipendentemente  dalla  rete  su  cui  il  dialogo  sta avvenendo 

Entrambe le cose hanno una loro validità. Nell’approccio di Microsoft si vede l’ottica di chi ha il controllo forte e sistemistico dell’intera struttura, che quindi vuole potersene fregare di quello che fanno le applicazioni in quanto Microsoft ha l’Active Directory con cui lui stabilisce le policy, e tutti  i nodi della rete andranno su  IPsec  .  Invece nell’approccio dello sviluppatore applicativo che  è  responsabile  solo  dell’applicazione,  ma  non  sella  configurazione  sistemistica,  risente tantissimo  di  quell’ottica,  e  quindi  tende  ad  una  sicurezza  auto‐consistente  all’interno dell’applicazione.  Entrambe  le  strade hanno dei pro  e dei  contro.  Sulla parte  IPsec  in questo momento non ci soffermiamo, consideriamo  invece  ina delle soluzioni proposte da Oracle per rendere sicuri i propri dialoghi. Questa è ovviamente una soluzione custom. 

Oracle SNS 

Oracle offre un servizio che si chiama SNS, che è un add‐on per la sua parte di rete. E’ da notare infatti che ogni fornitore di database ha anche un suo sistema per veicolare  l’SQL di rete, quindi Oracle ha  il suo sistema SQL*NET e sopra questo ci può anche metter sopra SNS. Permette di autenticare client e server e protegge  i dati (query, update, risposte) da  intercettazione (data encryption), modifiche (data integrity) , cancellazione (data filtering). L’SNS come soluzione di sicurezza risulta applicabile a: 

DB Oracle centralizzato/distribuito  DB federato con parti non Oracle : ricordiamo che un DB federato è un DB distribuito tra nodi di diversi produttori 

 Alcuni vantaggi insiti nell’uso di SNS sono: 

  non richiede modifiche alle applicazioni esistenti  non richiede dispositivi hardware 

 Quindi è un po’ il concetto di SSL applicato al mondo dei database. 

SNS ‐ schema funzionale 

 

Noi abbiamo la nostra applicazione che già usa SQL*NET, e quello che facciamo è introdurre tra lo strato SQL*NET e la rete lo strato SNS. Notiamo che questa parte SNS ha due interfacce: 

da un lato verso SQL*NET, quindi la libreria applicativa  dall’altra parte verso Oracle NPA, network protocol adapter,  l’altro  strato di  libreria di Oracle per permettere di fare query su qualunque tipo di rete 

Nel passaggio da sopra a sotto i dati diventano da non protetti a protetti. Ovviamente in ricezione ci sarà il  duale.  Se  vogliamo  applicarlo  anche  elementi  non Oracle  il  vincolo  è  che  bisogna  avere  SQL*NET: quindi io posso anche avere un PC Windows con Foxpro o Access, ma devo avere la libreria SQL*NET e 

anche SNS. Analogamente potrei anche avere un mainframe IBM con sistema operativo MVS e un certo database,  in  questo  caso  dovrò  avere  un modulo  aggiuntivo  chiamato  “Oracle  Open  Gateway”  per permettere al database con formato diverso da quello standard Oracle di parlare con SNS, quindi anche qui sono richiesti SNS e SQL*NET, quindi questo è quello che serve per le parti federate. 

SNS ‐ supporto cross‐protocollo  

 SNS non è  specifico per un protocollo di  rete. Visto  che  SNS  si  appoggia  su NPA,  analogamente può essere  usato  su  qualunque  tipo  di  rete. NPA  supporta  quasi  50  tipi  di  rete  diversi. Grazie  a  questa proprietà, SNS funziona anche cross‐protocollo. Notiamo i due tipi di rete che sono diversi. Nel qual caso SNS  creerà un  canale  logico  sicuro, ma di  fatto poiché  in  termini di pacchetti di  rete  ci  saranno due formati  diversi,  ci  dovrà  pur  essere  in mezzo  tra  queste  due  reti  un modulo  che  faccia  le  dovute conversioni tra  i due formati di rete diversi. Questo modulo  lo si  indica  in figura con  il nome di Oracle Multiprotocol Interchange.  SNS è integrato in Oracle MultiProtocol Interchange, che fa da gateway. SNS lavora  quindi  al  livello  di  payload  applicativo  ed  è  per  questo  che  è  indipendente  dal  livello  rete sottostante.  Oracle  MultiProtocol  Interchange  permette  di  avere  un  cambio  di  protocollo  senza rimettere i dati in chiaro, il che si traduce in velocità e soprattutto inattaccabilità. 

Crittografia in SNS  Per la parte di crittografia, viene negoziato l’algoritmo all’apertura della connessione tra client e server: 

ce n’è uno di default  nel caso in cui il default sia diverso tra client e server, allora si ricorre alla negoziazione  possibile  rifiuto della connessione,nel caso  in cui  il  livello di sicurezza non sia  ritenuto sufficiente  

Si può richiedere l’attivazione automatica della sicurezza ma bisogna fare attenzione in quanto il campo dei database è il campo in cui si presta attenzione alle prestazioni fino al centesimo di secondo, quindi avere  tutta  la parte di  sicurezza produce un  calo di prestazioni. Ecco perché  l’attivazione automatica della sicurezza: 

  per default può essere disattivata  attivazione automatica e trasparente quando ci si collega ad un server che la richiede 

 Vantaggi di SNS  Già a partire da Oracle 7 non venivano mica trasmessi  in chiaro username e password ma si usava un sistema  a  sfida,  però  c’è  un  problema.  Infatti  molti  server  lasciano  in  chiaro  i  cambiamenti  di password,perché il server deve conoscere la password in chiaro, e in ogni caso viene lasciato in chiaro la trasmissione dei dati quindi abbiamo bisogno di un qualche meccanismo per proteggere le trasmissioni. SNS crittografa tutta la sessione e quindi elimina questi problemi     

SNS ‐ identificazione ed autenticazione degli utenti  Per quanto riguarda l’ identificazione e l’autenticazione degli utenti, SNS è neutrale e supporta tantissimi sistemi di autenticazione tramite accordi esclusivi , questa è una delle potenze quando uno è veramente leader di mercato, perché  io accetto  il  tuo  sistema ma  tu non puoi darlo a nessun altro venditore di database. Ecco le soluzioni:  

Banyan ‐ Universal StreetTalk  login singolo di rete 

Bull ‐ Integrated System Management  SESAME  identificazione basata su token 

CyberSAFE – Challenger  Kerberos V5 (V4, DCE)  applicativi kerberizzati  GSS‐API 

ICL – AccessManager  login singolo di rete  A: RACF, ACF2, TopSecret, DCE, Kerberos  I: SDI SecurID, PCSL StopLockV, RACF Passticket 

Identix – TouchSafeII  verifica delle impronte digitali  interfaccia ISA 

Security Dynamics Technologies – SecurID  autenticatore hardware  PIN + numero casuale (cambia ogni minuto) 

 

SNS ‐ integrità dei dati 

Per garantire  integrità  (e quindi anche autenticazione) dei dati, SNS usa MD5 come checksum  (basata anche  sulla  chiave),  checksum  che  normalmente  non  è  inserita  ed  è  inseribile  a  richiesta.  SNS opzionalmente:  

numera i pacchetti  controlla che non ne manchino e non ci siano duplicati  arresta il sistema in caso di attacco  

Per la protezione del canale invece si utilizzano algoritmi standard. 

Sistemi di pagamento elettronico 

Si  intende quindi  il modo  in  cui noi possiamo  sviluppare delle applicazioni  che permettano di pagare merce che noi abbiamo acquistato su Internet. Inizialmente era stato proposto un tentativo di creazione della moneta elettronica,  tentativo  fatto da DigiCash e  che  si è  tradotto  in un  fallimento  forzato per problemi tecnici e normativi , perché c’erano molte paure sul fatto che con la moneta elettronica fosse più semplice  fare  riciclaggio di denaro sporco. Quindi nonostante  il sistema dal punto di vista  tecnico fosse valido, è stato distrutto.   Attualmente  il metodo più usato è trasmissione del numero di carta di credito  su  canale  SSL,  che  però  non  garantisce  contro  le  frodi:  VISA  Europa  dichiara  che  il  50%  dei tentativi di  frode nascono da  transazioni  Internet,  che però  sono  solo  il 2% del  suo  volume d’affari! Questo non perché Internet è il posto in cui si rubano le carte di credito, ma perché Internet è il posto dove più facilmente posso utilizzare le carte di credito che ho rubato, perché se vado in un negozio devo 

avere  con me  la  carta di  credito,ma  se  io ho  sbirciato  i numeri  allora posso usarli più  facilmente  su Internet.  

Sicurezza delle transazioni basate su carta di credito 

Inizialmente c’erano due standard in competizione tra loro: 

STT (Secure Transaction Technology)  VISA + Microsoft 

SEPP (Secure Electronic Payment Protocol)  Mastercard, IBM, Netscape, GTE, CyberCash 

SET = STT + SEPP (Secure Electronic Transaction)  Poi era stato creato uno standard comune chiamato SET. Lo standard SET è un bellissimo caso di studio per far vedere come non si realizza una soluzione di sicurezza. E’ un protocollo che è morto e sepolto. La sua sperimentazione  fu  fatta per  la prima volta alle Olimpiadi di Atlanta e da allora non ha più avuto alcuna applicazione pratica. Non si tratta di problem tecnici, quanto più di problem organizzativi.  SET (Secure Electronic Transaction) 

SET non è un sistema di pagamento ma un insieme di protocolli per usare in rete aperta in modo sicuro un’infrastruttura  esistente  basata  su  carte  di  credito.  SET  usava  certificati  X.509v3  dedicati esclusivamente  alle  transazioni  SET,  quindi  avevano  dei  key  usage  per  indicare  che  quel  certificato poteva essere usato specificatamente con SET. Era stato pensato bene dal punto di vista tecnico, perché assicurava  la privacy degli utenti perché mostra a ciascuna parte  solo  i dati che  le  competono,  senza permettere a chi intercettava i dati di leggere né i dati del certificato né i dati della carta di credito.  Caratteristiche di SET 

versione 1.0 (maggio 1997)  digest: SHA‐1  crittografia simmetrica: DES  scambio chiavi: RSA  firma digitale: RSA con SHA‐1  www.setco.org : fino all’anno scorso esisteva questo sito, adesso non esiste più  

Architettura di SET  

 

Dal punto di vista architetturale, SET era fatto nel seguente modo. Innanzitutto, quando noi ci rechiamo in un negozio e vogliamo pagare con carta di credito ,esiste già la rete che verrà usata per effettuare il pagamento e mettersi quindi in contatto con chi ha emesso la carta. I vari fornitori (Visa, Mastercard..) si chiamano Issuer. Però tipicamente non si chiede direttamente all’issuer, bensì all’acquirer (es. la banca), ovvero colui che procaccia clienti per conto dell’Issuer, e l’acquirer sarà il mediatore tra il negoziante e 

gli issuer, perché il negoziante ospita o direttamente nelle linee telefoniche o nell’architettura di SET IL payment  gateway,  ovvero  il  punto  di  scalo  tra  la  rete  non  protetta  e  la  rete  protetta  per  pagare.  Il merchant deve essere dotato del software SET, e dall’altra parte c’è invece un card holder ovvero colui che possiede una carta di credito e vuole effettuare il pagamento. 

Attori in SET 

cardholder  legittimo possessore di una carta di credito aderente a SET, e deve quindi possedere  il SET wallet (borsellino SET). Questo è un software particolare che deve essere installato sulla macchina da cui il card holder sta effettuando il pagamento 

merchant  venditore di un prodotto via  Internet  (Web o email), sul suo sito web ci deve essere  il software SET  

issuer  istituto finanziario che ha emesso la carta di credito dell’utente 

acquirer  organizzazione  finanziaria che  stabilisce un  rapporto col mercante e  lo  interfaccia con uno o più circuiti di pagamento. Devono generare certificati X.509 per il merchant,per il card  holder,  e  per  il  payment  gateway,  quindi  deve  esistere  tutta  l’insfrastruttura  di certificazione che distribuisce i certificati a questi attori 

payment gateway  sistema  che  traduce  transazioni  SET  nel  formato  richiesto  dal  circuito  di  pagamento dell’acquirer 

certification authority  emette certificati X.509v3 e CRL X.509v2 per tutti gli altri attori di SET 

 Doppia firma SET 

Il punto  che  protegge  la  privacy  è  la  cosiddetta doppia  firma.  In questo modo, quando  io  faccio un acquisto al merchant non vengono fatti sapere gli estremi del pagamento, quindi il negoziante non verrà mai a  sapere qual è  il mio numero di  carta di  credito  (quindi  la  situazione è  completamente diversa rispetto ai pagamenti fatti con SSL). Alla banca non viene mai fatto sapere quale merce si è acquistata.  Ecco quindi come si implementa questo concetto di doppia firma :  

al merchant non vengono fatti sapere gli estremi del pagamento  alla banca non viene fatto sapere quale merce si è acquistata  solo l’utente può dimostrare l’associazione tra merce e pagamento in caso di contestazione 

 Ma  come  si  realizza  l’ultimo  punto?  Come  può  l’utente  dimostrare  l’associazione  tra  merce  e pagamento?  

Doppia firma SET: dettagli 

Indichiamo  con  PI  (Purchase  Information)  i  dati  di  pagamento,  e  con  OI  (Order  Information)  le informazioni relative alla merce che sto acquistando. La firma digitale SET è fatta nel seguente modo: 

io calcolo l’hash dei dati di pagamento, e l’hash dei dati relativi alla merce che sto acquistando  

queste due cose le concateno e ne calcolo ancora l’hash, e di questo hash ne faccio la cifratura con la mia chiave privata 

o DS = E ( H( H(PI),H(OI) ), Ukpri)  

A

 

Al  merchan(DS+H(PI)), oH(H(PI),H(OI

t  comunico ovvero PI (il m)) verificand

la  firma  dmerchant noo che corrisp

igitale  appeon ha i dati dponda al valo

ena  calcolatdi pagamentoore estratto 

a  e  l’hash o PI, ma condalla firma) 

dei  dati  di osce l’OI e p

pagamentouò calcolare

o  e 

A

f

Allo stesso m(DS+H(OI)), ma conosce firma) 

modo, all’acqovvero OI  (l’PI e può cal

quirer comu’acquirer nocolare H(H(P

nico la firmaon conosce  i PI),H(OI)) ver

a digitale e l’dati riguardrificando che

’hash delle ido  la merce e corrisponda

nformazioni che sto acqa al valore e

sulla merceuistando OI,stratto dalla

e , a 

Soltantodati  vendimostra

Problem

A questoInnanzitimmotivelettronfrenato mAltro protutti quaPoi  l’altrcompatibackup dEcco  qul’utente ambito aCon  la sfacendo messi  suproblem2.0 non   

o chi ha fattongono manteare l’associaz

mi di SET 

o punto vediutto  il  softvatamente  mico, si chiedemolto la partoblema è chanti i loro cliero  incubo erbilità sia al del SET walleindi  la  granddeve installaaziendale poeconda versa meno delu  un  wallet ma… chi contrha mai visto 

 

o questa firmenuti  all’intezione tra me

ma, può far verno del  SETerce e pagam

vedere che  iT wallet, quimento, come 

i dati PI e Ondi  sul nostgià detto. 

I collimano etro PC: noi  s

e vanno  insisaremo  gli u

eme. Questiunici  a poter

i r 

amo di capirre perché SETT è fallito.  tware  necemolto  caro: evano cifre atenza di que

essario  erasiccome  ne

assurde per esto sistema.

molto  carel  1996‐97 iniziare a lav 

ro,  ma  la c’era  la  fidvorare con i

cosa  più  pducia  nel  bl commercio

particolare usiness  del o elettronico

è  che  eracommercio : questo ha

a o a 

he  le bancheenti, e le ban

e dovevano  fnche non ave

fungere da Cevano nessun

CA, perché dna intenzion

dovevano me di fare que

ra nel  SET wlivello di S.Oet per evitarede  lezione  care un softwsso ancora ssione (2.0) h SET wallet eserver,  e  l’rolla il walletla luce ed è 

wallet, un  soO. che degli e di perderlache  stiamo  iware specificosperare nell’oanno cercate rimpiazzan’utente  si  cot server? Risstato definit

oftware da  inapplicativi  tra traccia di tuimparando: o diventa unomogeneità o di risolverndolo con unollegava  colposta: nessutivamente so

nstallare  a  cra  loro.  Inoltutti gli acquisqualunque  sn incubo se ndi configurae questi pron browser. O  browser  : uno voleva aoppiantato.

casa del  clietre chi  insegsti fatti.  soluzione  dinon è in ambzione delle poblemi e renOssia  i walletma  a  questssumersi qu

ettersi  loro esto lavoro.  

a certificaree 

nte: è un  ingnava all’ute

ncubo per  laente a  fare  il

a l 

  sicurezza  cbito aziendalpostazioni di 

che  dica  chee! Perché inlavoro. 

e n 

dere SET piùt venivano vto  punto  c’eesto onere, 

ù appetibile,irtualizzati eera  un  altroe quindi SET

, e o T 

Architettura di pagamento via Web 

Abbiamo  detto  che  l’alternativa  è  il  pagamento  via web.  Vediamo  ora  uno  schema  di  cosa  avviene all’interno di un’architettura di pagamento via web: 

 

Il  cliente  ha  selezionato  la merce,  e  l’ha messa  in  uno  shopping  chart  (carrello  virtuale)  e  a questo punto  fa  il  check‐out.  Facendo  il  check‐out  il merchant  ci  invia un’offerta  (1)  che  è  il riassunto della merce che vogliamo acquistare, alla quale il cliente (cardholder) risponde con un ordine (2) 

In teoria se il merchant è un tipo che fa le cose per bene, non dovrebbe chiedermi lui i dati della carta di credito, ma dovrebbe reindirizzarmi verso un payment gateway con cui  lui ha fatto un accordo. Il payment gateway attiverà un canale SSL verso di me per chiedermi i dati della carta di credito (4 e 5), garantendoci rispetto ad eventuali buchi di sicurezza del mercante 

Il payment gateway attiverà su di sé un software noto come POS virtuale che a partire dai dati della carta di credito mi ricrea tutti quei dati che effettivamente verrebbero prodotti se solo si strisciasse  la carta di credito  in un vero e proprio POS.  Inoltre  il POS virtuale dialogherà con  la rete di pagamento usando i protocolli propri del mondo finanziario, non è detto che sia TCP/IP, ottenendo un OK (6 e 7) 

Solo se tutto va a buon fine  invierà un feedback al merchant per  indicare  la buona riuscita del pagamento (8) e il mercante può spedire l’oggetto. 

 Notiamo  che  questa  soluzione  si  presta  ad  una  serie  di  problemi:  innanzitutto  non mi  garantisce  la privacy, perché il payment gateway tipicamente fa un brutto lavoro di tenere traccia di quali sono le mie preferenze di acquisto (e rivende questi dati a terzi). La seconda cosa è che nel momento  in cui faccio l’acquisto ci sono dei merchant che chiedono  loro  la carta di credito,  la memorizzano  localmente e poi provvedono a trasmetterla via FAX o altro. Quindi c’è un grosso problema  di come viene gestito il dato della carta di credito. Quindi di per sé l’architettura va bene, il vero problema è come sono gestiti i dati della carta di credito.  

Pagamento con carta di credito via Web 

Quindi in caso di pagamento con carta di credito via web, le ipotesi base sono: 

l’acquirente possiede una carta di credito  l’acquirente ha un browser con SSL 

 in base a quanto abbiamo detto oggi, la sicurezza effettiva dipende dalla configurazione sia del server sia del client perché in SSL c’è una negoziazione, quindi il lucchetto scatta anche quando abbiamo negoziato la cifratura a zero bit quindi c’è un problema di educazione degli utenti. Non deve bastare la sola visione del lucchetto, ma bisogna vedere innanzitutto chi ha autenticato il server, e poi qual è il livello effettivo di cifratura in termini di bit. Inoltre, l’utente non gode di privacy. 

Requisiti di sicurezza per SI di e‐commerce 

Questo problema del fatto che sempre più spesso oggi viene attaccato non il canale SSL, ma il payment gateway, nel caso che questo conservi in modo insicuro i dati delle carte di credito, ha fatto sì che Visa per prima e poi  tutti  gli altri grossi produttori di  carte di  credito abbiano attivato   dei programmi di certificazione per tutti coloro che vogliono attivare dei payment gateway. Quindi Visa non permette di attivare  un  payment  gateway  se  non  dopo  il  conseguimento  di  una  certificazione. Ogni  issuer  però faceva la sua certificazione, quindi stava per diventare un casino:   

Visa:  (2000)  Account  Information  Security  (AIS)  program  for  EU  and  the  Cardholder Information Security Program (CISP) for USA 

(2001) programs mandatory for all members, merchants and service providers   other security programs: 

MasterCard requires Site Data Protection (SDP)  American Express requires DSOP  Discover requires DISC  … 

 

ecco perché alla fine si sono accordati ed esiste uno standard molto  importante che si chiama PCI‐DSS (Payment Card Industry – Data Security Standard). Oggi è richiesto da tutte le carte di credito per tutte le  transazioni  in  Internet,  quindi  chiunque  voglia mettere  in  piedi  un  payment  gateway  deve  avere questa certificazione altrimenti non potrà collegarsi alla rete finanziaria. 

PCI DSS 

Rispetto  ad  altri  standard  che  esistono  in  giro  e  che  dicono  come  implementare  la  sicurezza  nel  SI, questo standard è molto più prescrittivo, ovvero indica proprio quali sono le soluzioni da adottare.  

Requisiti PCI DSS 

Al fine di far capire cosa si intenda per “standard prescrittivo”, vediamo quali sono le regole 

costruire e mantenere una rete protetta: o R1 =  installare e mantenere una  configurazione  con  firewall per proteggere  i dati dei 

titolari delle carte (non ci limita sul produttore, ma ci dice che ci deve essere!) o R2 = non usare password di sistema predefinite o altri parametri di sicurezza  impostati 

dai  fornitori  (in passato con Oracle erano state mantenute all’atto dell’installazione  le password di default…alla fine tutti si facevano le copie dei database) 

proteggere i dati dei titolari delle carte: o R3 = proteggere  i dati dei titolari delle carte memorizzati (quindi se  li manteniamo noi, 

dobbiamo garantire che  il File System  sia  sicuro o che  i  sistemi che mantengono quei dati non siano manipolabili) 

o R4  =  cifrare  i  dati  dei  titolari  delle  carte  quando  trasmessi  attraverso  reti  pubbliche aperte (incluse qualunque rete wireless, qualunque cosa vada su onde radio!) 

rispettare un programma per la gestione delle vulnerabilità o R5 = usare e aggiornare con regolarità l’antivirus o R6 = sviluppare e mantenere applicazioni e sistemi protetti 

implementare misure forti per il controllo accessi 

o R7 = limitare l’accesso ai dati dei titolari delle carte solo se effettivamente indispensabili per  lo svolgimento dell’attività commerciale (principio del need to know: un operatore dovrebbe avere accesso alla minima quantità di dati necessaria per lo svolgimento delle sue mansioni. Purtroppo per semplicità sempre più spesso a seguito dell’autenticazione si da accesso al database direttamente.) 

o R8 = dare un  ID univoco ad ogni utente del SI  (quindi NO AGLI ACCOUNT DI GRUPPO, ognuno deve essere responsabile delle proprie azioni) 

o R9 = limitare la possibilità di accesso fisico ai dati dei titolari delle carte  monitorare e testare le reti con regolarità 

o R10 = monitorare e tenere traccia di tutti gli accessi effettuati alle risorse della rete e ai dati dei titolari delle carte (vogliono un elenco di chi sta facendo cosa sulla rete) 

o R11 = eseguire test periodici dei processi e dei sistemi di protezione  adottare una Politica di Sicurezza 

o R12 = adottare una Politica di Sicurezza (documentata, perché questa è anche una cosa che vedranno all’atto della verifica per ottenere la certificazione) 

Questi punti vanno rispettati tutti e 12, non in parte!