Articoli e news    Prezzi

CryptDB usa dati crittografati senza togliere la protezione

10:43 - 29 dicembre 2011 di Valerio Porcu

Le ricerche di alcuni specialisti del MIT hanno portato alla creazione di un potente strumento capace d'interrogare un database crittografato senza rimuovere la protezione, e senza impiegare anni per farlo. Uno dei più rilevanti contributi recenti in ambito di sicurezza informatica.

Un gruppo di ricercatori del MIT (Massachusetts Institute of Technology) ha messo a punto CryptDB, uno strumento per lavorare su database crittografati senza rimuovere la protezione. Lo studio, cofinanziato da Google e Citigroup, rappresenta una pietra miliare nell'evoluzione del software, e pone le basi per una nuova epoca del calcolo digitale sicuro.

L'uso di database crittografati oggi infatti presenta un problema rilevante: per lavorare con i dati bisogna prima rimuovere la protezione, di fatto esponendoli a occhi indiscreti, compresi quelli di operatori troppo curiosi. Gli strumenti ipotizzati fino a oggi per evitare il problema non sono utilizzabili, perché impiegano mesi, se non anni, anche per le attività più semplici, e si arriva a migliaia di anni per quelle più complesse

Proteggere i dati non è facile, se bisogna anche usarli

CryptDB non è quindi il primo software del suo genere, ma potrebbe essere il primo ad avere una qualche utilità pratica. Il principio su cui si basa questo software, e quelli simili, è quello della crittografia omomorfa: i dati di ricerca "entrano" nella crittografia, e solo i risultati saranno poi decodificati.

"È come una di quelle scatole di vetro con guanti di gomma usate per manipolare sostanze chimiche tossiche. Tutta la manipolazione avviene dentro la scatola, e i prodotti non vengono mai in contatto con il mondo esterno", aveva spiegato Craig Gentry di IBM, nel 2009 - quando presentò una sua proposta, che però impiegava troppo tempo per produrre risultati.

I ricercatori del MIT sono invece riusciti a ridurre i tempi e a creare uno strumento utilizzabile. "L'idea interessante è che le query SQL nei database si compongono di relativamente pochi tipi di operazioni: uguale a, meno di, somma, ordina", spiega Nickolai Zeldovich "per ogni operazione siamo riusciti a trovare uno schema crittografico piuttosto efficiente nel calcolo su dati crittografati".

CryptDB è inoltre capace di cambiare sistema di crittografia "al volo" in base all'operazione e ai dati, e questo lo rende veloce anche con informazioni protette da diversi "strati" di crittografia, un sistema noto come "cipolla" nell'ambiente specifico.

Chiaramente CryptDB non offre tutta la potenza e la flessibilità che si avrebbe lavorando su dati non protetti, ma si arriva comunque oltre il 99% della funzionalità "in chiaro". Tra i difetti c'è anche il fatto che una minima parte dei dati comunque "esce" dal sistema di protezione. I limiti potrebbero essere più che accettabili per chi dà importanza alla protezione dei dati.

La sicurezza è importante in ogni ambito

Ci sono tanti contesti dove un sistema simile potrebbe rivelarsi utile, a partire da tutti i database del mondo gestiti con sistemi cloud, a cui hanno accesso più persone - ognuna con le proprie mansioni. Dati bancari, server con dati finanziari, registri di medici e ospedali, server di posta elettronica, collezioni di dati militari sono tutti dei validi contesti, e non sorprende quindi che siano aziende come Google e Citigroup a finanziare il progetto.

Anche la DARPA (Defense Advanced Research Projects Agency), l'agenzia degli Stati Uniti che sviluppa progetti avanzati per la difesa militare, è interessata alla crittografia omomorfa, racconta Andy Greenberg su Forbes. L'agenzia è infatti disposta a spendere 20 milioni di dollari per uno strumento che lavori su database crittografati mettendoci "solo" 100.000 volte il tempo richiesto per lavorare con dati in chiaro. CryptDB si ferma a un x80.000, quindi sembra il candidato ideale per ricevere il finanziamento.

Condividi:   

Commenti

Aggiungi un tuo commento
1/2 avanti    
Tux89 29/12/2011 11:35
 
J limiti potrebbero essere più che accettabili per chi dà importanza alla protezione dei dati.



Mi sa che c'è un errore poco sopra la seconda immagine!
Moderatore: Valerio Porcu 29/12/2011 11:39

 Originariamente inviata da Tux89

J limiti potrebbero essere più che accettabili per chi dà importanza alla protezione dei dati.



Mi sa che c'è un errore poco sopra la seconda immagine!



Corretto, grazie.
supertigrotto 29/12/2011 12:16
 
Per il futuro del cloud è una cosa molto utile,i dati sensibili sono importanti....
joeSeggiola 29/12/2011 12:30
 
+1 
Scusatemi, ma non ho capito molto il problema da dove sorge. Magari qualcuno può spiegarmi meglio.

Ho un database in un file (o qualsiasi altra cosa, comunque in un filesystem o una memoria) crittato. Per lavorarci devo decrittarlo tutto e lanciare le mie query, e questo espone tutto il DB decrittato all'utilizzatore. E fin qui ci sono.

Ora, si cerca un modo di lanciare query direttamente su un database crittato.

Ora mi chiedo, il problema sta nel fatto che il database intero, struttura compresa, è crittato (cioè dati e struttura sono crittati insieme, e quindi senza decrittarlo non ho nemmeno la struttura di esso)? Oppure sono crittati solo i dati mentre l'intera struttura è comunque tutta in chiaro (e cioè, si arriva al dato crittato solo all'interno del record)?

Se la prima ipotesa è giusta, perché crittare anche la struttura? Se è giusta la seconda, dov'è il problema?
degac 29/12/2011 13:09
 
+1 
Da quanto ho capito io:
- la struttura 'dovrebbe' essere esposta, mentre i dati sono criptati
- il SQLE riesce ad operare a livello di 'dati criptati' SENZA conoscere la chiave e quindi riuscendo a vedere solo il risultato ricercato (quindi una classica SELECT * dovrebbe venir bloocata altrimenti il tutto va a farsi friggere)

E' questo il motivo della lentezza di ogni singola query: in pratica c'è un algoritmo che deve decriptare al volo /creare ogni volta una chiave di protezione dei dati.

A me comuqnue sorge il dubbio di base: se ho un database pieno di dati, OGNI record dovrebbe essere 'bloccato' (esemio: DNA, associato a nome+cognome+chiave unica).
Se il sistema è in grado di drecriptare al volo tutto dov'è la sicurezza?
Roby10 29/12/2011 13:19
 
Nemmeno io ho colto nel pieno come funziona, ma ho idea delle possibili applicazioni.

Ricordo un episodio in cui chiamai per conto di un cliente che aveva comprato un antivirus, si era registrato con password e poi aveva formattato e il pc non gli permetteva di reinstallarlo.

Chiamato il centro assistenza e dati tutti i dati, l'operatrice ad un certo punto mi chiede la password. Già mi è sembrato strano, ma ho pensato che la inserisse nel terminale che poi avrebbe dato esito positivo o negativo. Spiegando la storia e tutto e soprattutto che questa password non ce l'avevamo, finì che l'operatrice cominciò a darci degli indizi per indovinare la password tipo "sono 6 caratteri... sono numeri... sembra una data... si quasi, un po' più estate... ecco giusto!!!
E ci ha sbloccato l'account....

Ecco secondo me qui potrebbe servire.
Moderatore: Iron 29/12/2011 13:47

 Originariamente inviata da joeSeggiola

Scusatemi, ma non ho capito molto il problema da dove sorge. Magari qualcuno può spiegarmi meglio.

Ho un database in un file (o qualsiasi altra cosa, comunque in un filesystem o una memoria) crittato. Per lavorarci devo decrittarlo tutto e lanciare le mie query, e questo espone tutto il DB decrittato all'utilizzatore. E fin qui ci sono.

Ora, si cerca un modo di lanciare query direttamente su un database crittato.

Ora mi chiedo, il problema sta nel fatto che il database intero, struttura compresa, è crittato (cioè dati e struttura sono crittati insieme, e quindi senza decrittarlo non ho nemmeno la struttura di esso)? Oppure sono crittati solo i dati mentre l'intera struttura è comunque tutta in chiaro (e cioè, si arriva al dato crittato solo all'interno del record)?

Se la prima ipotesa è giusta, perché crittare anche la struttura? Se è giusta la seconda, dov'è il problema?


Crittare? Si dice cifrare o crittografare...
erty 29/12/2011 14:28
 

 Originariamente inviata da Iron

Crittare? Si dice cifrare o crittografare...


va bene lo stesso http://www.treccani.it/vocabolario/crittare/
Moderatore: Iron 29/12/2011 14:35

 Originariamente inviata da erty

va bene lo stesso http://www.treccani.it/vocabolario/crittare/


Ma non di può sentire... Se poi vogliono approvare tutti i neologismi buon per loro (ma non per noi...).

Fine OT.
twisted87 29/12/2011 15:59
 

 Originariamente inviata da degac

Da quanto ho capito io:
- la struttura 'dovrebbe' essere esposta, mentre i dati sono criptati
- il SQLE riesce ad operare a livello di 'dati criptati' SENZA conoscere la chiave e quindi riuscendo a vedere solo il risultato ricercato (quindi una classica SELECT * dovrebbe venir bloocata altrimenti il tutto va a farsi friggere)

E' questo il motivo della lentezza di ogni singola query: in pratica c'è un algoritmo che deve decriptare al volo /creare ogni volta una chiave di protezione dei dati.

A me comuqnue sorge il dubbio di base: se ho un database pieno di dati, OGNI record dovrebbe essere 'bloccato' (esemio: DNA, associato a nome+cognome+chiave unica).
Se il sistema è in grado di drecriptare al volo tutto dov'è la sicurezza?



sarebbe molto interessante saperne di piu
1/2 avanti    
Accedi o  registrati.
Nome utente:
Password:
Segnala TomsHW

Correlazioni

  Categorie: Sicurezza, Nuove Tecnologie
  Tag: Ricerca, Crittografia