[e-privacy] Cifroserver 2 - la vendetta

[ale]

"Marco A. Calamari" <marcoc1 at dada.it> ha scritto:
> On Tue, 2005-08-23 at 13:49 +0200, ale wrote:
> > In effetti la maggior parte delle soluzioni di cui si e' discusso
> > in questa lista non e' particolarmente adeguata al nostro problema
> > per un semplice motivo - al di la' dell'impatto in termini di
> > prestazioni su di un server gia' sotto carico intenso - e cioe' che non credo
> > (come anche riconosceva Leandro in una mail passata) sia molto saggio
> > mettersi nella posizione di possiedere la chiave (singola!) di migliaia
> > e migliaia di caselle di posta.
> 
> Ciao,
> 
> dove e' scritto che si deve sapere chi possiede la chiave
>  singola (penso tu ti riferisca ai dischi) ?
> 
> Poi esistono le chiavi in sharing, parziali od a password multiple.

Non mi riferisco ad una generica situazione ideale ma penso piu' che
altro al contesto legale - c'e' una Associazione che gestisce la
macchina, e sostenere che tale associazione non possegga i mezzi per
accedere ai propri dati mi pare un po' una forzatura... poi non e' tanto
importante identificare quale singola persona possiede la chiave, una
volta che e' possibile identificare un responsabile giuridico.


> 
> Ed infine, avete fatto prove per dire che una cifratura aes inciderebbe
>  significativamente sulle prestazioni della macchina ? I buffer
>  del filesystem di linux non vengono mica cifrati.
> 
> E, ad esempio, uno swap criptato non incide in maniera significativa.
> 
> Ma, ripeto, condividere questo tipo di informazioni servirebbe a tutti.
> 
> Io ho cifrato una pbox tipo III, processore Geode 266 mhz, equivalente
>  ad un pentium I (una lumachina), e non ce se ne accorge nemmeno.
> 
> Le cache lavorano bene, ed i buffer di s.o. pure....

Scusami, intendevo appunto che _non_ inciderebbe drammaticamente sulle
prestazioni della macchina :)  (cosa che alla luce delle considerazioni
successive non e' comunuqe determinante).
i dati su cui mi sono basato sono stati misurati dai nostri compagni
americani di riseup, e sono da tempo pubblicamente disponibili:

http://deb.riseup.net/storage/encryption/benchmarks/

inoltre teniamo presente che ma la situazione operativa di autistici 
assomiglia poco a cio' che in genere si considera "normale": mentre e'
sempre possibile disegnare un hardware che sia sufficiente allo scopo
prefisso, non e' altrettanto facile procurarselo... ;)
Purtroppo a/i non ha risorse illimitate, e questo fa si', nel caso
specifico che sollevi, che non ci possiamo permettere i gigabytes di
memoria che servirebbero per un setup ottimale - dunque ahime' sul
server attuale la memoria dedicata ai buffer e' una quantita' assolutamente
risibile e temo i risultati sarebbero un po' peggiori. Ma, ripeto, la
cosa sarebbe probabilmente fattibile in ogni caso, se valutata
fondamentale.


> 
> > Una cosa piu' intelligente sarebbe implementare un meccanismo per
> > cifrare _singolarmente_, con chiavi individuali, ciascuna mailbox.
> > Anche qui i problemi di prestazioni si sprecano, ma sarebbe tecnicamente
> > pensabile crittare tutti i messaggi in ingresso con una chiave asimmetrica:
> > l'ostacolo principale diventa a questo punto la webmail (che purtroppo e' il
> > sistema piu' usato dai nostri utenti), non abbiamo trovato nessun software con
> > le caratteristiche adeguate... almeno fino ad ora, ma continueremo a
> > cercare...
> 
> Questo si che mi sembra una situazione complessa.... ma mi riservo
>  di capirne di piu' in seguito.
> 
> > La crittografia del contenuto completo dei server dunque non e' un'opzione
> > praticabile per noi, cosa di cui del resto ci eravamo resi conto da un
> > po', convincendoci che non ci fossero molte alternative ad una migliore
> > educazione degli utenti sulla gestione personale della propria privacy.
> 
> Non la vedei in alternativa ad altro, ma semplicemente come prima
>  barriera di difesa anti raid. E' automatica e (se si fanno i backup,
>  che qualcuno dovra' ben custodire, magari insieme alla chiave)
>  non costa (quasi) niente

A questo rispondo piu' sotto, assieme ad un'altra osservazione simile.


> > 
> > Altra cosa e' difendersi dal tipo di intrusione come quella verificatasi
> > a giugno, il cui scopo era (ok, non solo) impadronirsi di alcuni file
> > specifici che permettessero l'intercettazione delle comunicazioni future
> > (e passate, magari): questi si' sono files che vanno protetti
> > crittograficamente, almeno per evitare che, a macchina spenta, sia
> > possibile accedervi - per questo essenzialmente puo' bastare un loop
> > device crittato, da montare (con inserimento di password a mano) all'avvio
> > prima di far partire i servizi interessati.
> 
> Quindi non criptare la root, ma solo alcuni filesystem ? Ed i
>  certificati ? Almeno etc e var dovrebbero essere comunque criptate

Mi riferivo appunto alle chiavi private dei certificati.

> 
> > Piu' in generale, dato che comunque asserragliarsi su delle posizioni
> > "difensive" alla lunga e' una scelta perdente (o meglio, e' una scelta
> > che viste le risorse che abbiamo non possiamo intraprendere), la
> > direzione che mi sembra migliore e' quella del decentramento, della
> > dispersione, della moltiplicazione. Anziche' pretendere di "garantire"
> > una qualche sicurezza (cosa che siamo stati attenti a non fare mai,
> > ma e' probabile che in non pochi abbiano avuto questa errata impressione)
> > dei dati memorizzati sui server, che in definitiva ci e' impossibile,
> > cercare di puntare sulla "resistenza" della struttura di comunicazione
> > medesima in ogni eventualita'.
> 
> Al solito, perche' vedere le soluzioni in alternativa, e non associate
>  nell'ottica di una difesa in profondita' ?

Supponiamo che il problema che si vuole affrontare sia l'accesso arbitrario
e non autorizzato ai dati da parte di soggetti che _comunque_ sono in grado di
esercitare autorita' sufficiente per accedere ai dati che gli interessano
(sempre che esistano) in maniera legittima. Da questo punto di vista
sia la crittazione dei dischi che la delocalizzazione sono meccanismi
per ottenere legittimazione da parte di questi soggetti, e dunque
evitare l'arbitrarieta'.

Considerando poi che a/i dispone anche di risorse _umane_ limitate
abbiamo cercato di limitarci a cio' che ritenevamo assolutamente
essenziale, e nell'ottica di cui sopra solo uno di questi meccanismi e'
imprescindibile. 

Poi attenzione, non dico che il problema del flug o di qualsiasi altro
soggetto sia esattamente analogo: questo e' un problema molto specifico,
che discende direttamente dagli eventi che ci sono capitati.

> 
> [...]
> 
> > Spero soprattutto che questa esposizione abbia soddisfatto qualche
> > curiosita' (o che invece ne abbia create di nuove)!
> 
> Certamente ne ha create piu' di quelle che ha soddisfatto, ma, essendo
>  le discussioni precedenti avvenute non in pubblico e non avendo tu
>  ancora fornito nessun particolare (le cose che si *faranno*, non quelle
>  che non si faranno) non poteva essere altrimenti.

Beh, l'intento non era quello di illustrare nei dettagli cosa stiamo
facendo, ma di cominciare a condividere le riflessioni che abbiamo
fatto.

> 
> Con il massimo rispetto delle vostre posizioni "abbottonate",
>  a risentirci.

Le posizioni "abbottonate" sono semplicemente necessarie per non dire
troppe cazzate prima di averci pensato bene! :))


ciao


--
ale

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.winstonsmith.org/pipermail/e-privacy/attachments/20050823/fe2290c8/attachment.pgp>