ownCloud sembra un'alternativa dropbox promessa localmente ospitata. Tuttavia, è stato segnalato che la crittografia non è esattamente strong ... (Il team di ownCloud fa almeno fornisce un elenco di problemi ) Ma presumendo che stia utilizzando un server ownCloud in una LAN fidata, i dati memorizzati sono al sicuro abbastanza da resistere al furto fisico del server non alimentato? Con "abbastanza sicuro" intendo rispetto ad es. un volume TrueCrypt non montato.
Il blog di Pascal mostra alcuni punti deboli, alcuni dei quali vengono richiamati in advisor di ownCloud , ma non ricordavano il peggio.
L'archiviazione delle chiavi di crittografia come file in /tmp è già piuttosto brutta, specialmente dal fatto che /tmp è una vera directory basata su disco in molti sistemi operativi Linux e * BSD (di solito configuro il mio /tmp come un file system basato sulla memoria, ma questo non è l'impostazione predefinita). Pertanto, alcune chiavi di crittografia faranno parte della memoria fisica. Ed è risaputo che l'eliminazione di un file fa sì che non cancelli i dati; segna semplicemente i blocchi corrispondenti come riutilizzabili. I dati non vengono scritti fino a quando non vengono creati nuovi file. Pertanto, si può presumere che alcune chiavi si perderanno se il server non alimentato viene rubato.
La peggiore debolezza riguarda la generazione di chiavi. Pascal lo afferma come:
The computation of the overall entropy, and thus the effort to guess a key, is left to the reader… Not to mention the maximal achievable amount of 4*log2(99999-10000+1) = 65.8 bits of entropy, which are far from the recommended minimal value of 80 bits.
Il bit di "65,8 bit" è fuorviante: significa che il modo in cui ownCloud genera le chiavi implica un'entità massima di tale quantità ... supponendo che il PRNG coinvolto sia perfetto. Ma non lo sono. Il 65.8 deriva dalla produzione della chiave come quattro numeri interi nell'intervallo 10000..99999. Ma provengono da un Mersenne twister PRNG, anch'esso seminato con un altro PRNG, a sua volta seminato dall'attuale ora e dall'identificatore del filo. Il tempo è passato al microsecondo; supponiamo che l'attaccante conosca quel tempo con un'accuratezza di un secondo. Supponiamo anche un identificatore di thread a 16 bit. Questo è, nel migliore dei casi, 36 bit di entropia. Un semplice PC passerà attraverso questo nel giro di pochissime ore (la crittografia usa Blowfish, che ha un programma di chiavi piuttosto costoso, ma non che costoso).
Naturalmente, dal momento che è coinvolta una password, l'attacco alla password è probabilmente ancora più semplice, ma questa generazione di chiavi a bassa entropia impedisce il rafforzamento da una password grande e casuale. Questo è piuttosto senza speranza. Se il twister Mersenne è stato sostituito con un PRNG decente e crittograficamente strong con un'appropriata semina (ad esempio, semplicemente leggendo da /dev/urandom ), allora le altre debolezze sarebbero fonti di seria preoccupazione, ma il debole trionfo semina tutto .
La mia soluzione sarebbe utilizzare la crittografia del filesystem di Linux (LUKS). Puoi cifrare tutto su quel server tranne per / boot, se lo desideri, che includerà naturalmente anche tutto ciò che ownCloud memorizza. Con qualcosa come AES-256 e una buona passphrase, il compromesso fisico manterrà i tuoi dati riservati. Questo è qualcosa che sto facendo sempre più su tutte le mie scatole. Data la potenza dei moderni microprocessori, anche se non si dispone di un acceleratore crittografico, non c'è molto rallentamento.
Il link sottostante dal sito CentOS mostra come farlo. Queste istruzioni si applicano fondamentalmente a qualsiasi altra distribuzione GNU / Linux (ho usato Slackware per il mio primo).
Se stai utilizzando i BSD, supportano anche la crittografia del filesystem. Non l'ho ancora provato, ma questo da OpenBSD dovrebbe iniziare. OpenBSD utilizza la sua utility softraid non solo per il software RAID, ma anche per la crittografia dell'intera partizione.
Spero che questo aiuti,
- SYG
Leggi altre domande sui tag encryption server