Ti rispondo nei vari punti all'interno della tua mail

Il 29 aprile 2010 04.00, Elettrico <[email protected]> ha scritto:
> grazie a tutti quelli che hanno risposto.
> chiarisco meglio cosa intendevo nella mia precedente mail:
>
> - vi sono N medici
> - ogni medico ha una serie di dati che vengono memorizzati su di un server
> - alcuni di questi dati devono essere criptati in maniera che siano
> decriptabili solo dal medico
>
> fin qui non ci vedo grossi problemi, anche se ancora non sono arrivato a
> decidere l'implementazione la (de)criptazione in questo caso è semplice
> poichè parliamo di un attore una chiave.
> il complicato - almeno per me - arriva ora:

Generi una chiave simmetrica per ogni sottoinsieme di dati che devono
essere acceduti da diversi medici: Sk.

Questa chiave simmetrica sarà cifrata N volte, tanti quanti sono i
medici/supervisori/etc. che vi devono accedere. Tale cifratura verrà
fatta con la chiave pubblica dell'utente che vi dovrà accedere.

> - ogni N medici vi è un supervisore
> - tale supervisore deve poter vedere tutti i dati dei medici sotto di
> lui, eventualmente anche decriptare la parte criptata

Come detto sopra. Ammettiamo che Sk sia la chiave simmetrica, avrai
Epk1, Epk2,..., Epkn chiavi pubbliche dei medici, poi EEpk1 per il
supervisore e EWorldpk per l'organismo centrale.

La cifratura del dato dovrà essere fatta con Sk ed Sk dovrà essere
cifrato con il set di chiavi pubbliche sopra esposto.

Quindi se M è il dato da cifrare il tuo pacchetto di dati cifrato M1 sarà:

M1 = Sk(M)+Epk1(Sk)+Epk2(Sk)+...+Epkn(Sk)+EEpk1(Sk)+ EWorldpk(Sk)
(dove "+" è la concatenazione)

Per la decifratura: Supponiamo di avere un header del messaggio che ti
dica dove finisce il dato cifrato e dove iniziano le cifrature della
chiave simmetrica, ti conviene anche aggiungere un prefisso alla
chiave simmetrica Sk noto tipo "hello", in questo modo quando dovrai
decifrare il dato per capire se la chiave privata (corrispondente alla
chiave pubblica con cui è stato in precedenza cifrata Sk) che stai
utilizzando è valida o meno, dovrai solo vedere "se esiste una
cifratura di Sk tale che il prefisso è "hello". Se esiste estrai Sk e
decifri M. Oppure puoi aggiungere il Fingerprint della chiave privata
e fare un match (ti conviene perché è meno costosa di una decifratura
asimmetrica)...oppure valuta tu quello meno costoso e più sicuro :-)

L'idea è questa. Però ti conviene vedere lo schema che usa PGP o GPG
per la cifratura multipla con chiavi asimmetriche. Questo che ti ho
appena scritto è in linea generale l'approccio.

> - vi è un organismo centrale che deve poter vedere tutti i dati,
> eventualmente anche decriptare la parte criptata
>
> ne consegue che ogni dato criptato lo deve essere usando non solo la
> chiave del medico ma anche quella del supervisore e dell'organismo centrale.
>
> qui mi perdo, poichè l'idea di usare una chiave random si perde nel
> momento in cui i dati sono divisi in sottoinsiemi, e soprattutto questi
> sottoinsiemi variano, ovvero il supervisore 1 potrebbe accedere ai dati
> dei medici 1, 2 e 3 oggi, ma domani potrebbero assegnargli anche il
> medico 4.

Nei casi in cui i sottoinsieme varino ti basta unicamente aggiungere
al dato cifrato un nuovo Epkm(Sk). Per tutti i dati ovviamente. Non è
una ricifratura. Devi solo estrarre Sk e appendere un nuovo pacchetto.

>
> la costruzione del tutto probabilmente si appoggerà a vari componenti,
> ma la maggior parte sarà scritta in php/mysql, e non mi pare di trovare
> grandi soluzioni rispetto ai miei bisogni.

Non mi sembra che MySQL abbia API native per la cifratura. Se MySQL è
un MUST allora sei nei guai :-) oppure ti divertirai molto.
Implementare queste cose è molto gustoso....poi quando dovrai fare i
test e andrai in produzione un po' meno perché se qualche cosa non
funziona son dolori.

Mi raccomando dotati di qualche strumento di Unit
Testing....fondamentali in questi casi per gestire i cambiamenti.

ciao e spero che queste mie considerazioni ti siano utili.
________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List

Rispondere a