Cât de sigură este procedura mea de pseudonimizare?

Lucrez pentru o instituție în care sunt colectate datele pacienților și ar trebui să le criptez. Momentan fac următorii pași (cu R):

• Atribuirea aleatorie a unui ID fiecărui pacient. Procedura evită duplicatele (folosind probă(), printre alții)
• Creați o sare pentru fiecare pacient (folosind sare <- bcrypt::gensalt(log_rounds= 5))
• Creați un ID hashed pentru fiecare pacient folosind ID-ul și sarea (folosind id_hashed <- bcrypt::hashpw(id, sare = sare))

Salvez datele în trei fișiere diferite

• primul fișier conține perechi de date despre pacient (nume și data nașterii) și ID criptat/hash
• al doilea fișier conține perechi de ID-uri și săruri necriptate/hashed
• al treilea fișier este baza de date reală cu ID-uri și un număr de variabile de interes (de ex.fumător, greutate,...)

În practică, acesta va fi utilizat după cum urmează:

• În timp ce lucrăm în baza de date (al treilea fișier) știm ID-urile, dar nu și numele pacienților. Uneori trebuie să aflăm ce persoană este un act de identitate. Am scris o aplicație (shinyApp) unde putem introduce ID-ul și aplicația returnează numele și data nașterii. Pentru aceasta, aplicația intră în al doilea fișier, ia ID-ul și sarea corespunzătoare și generează ID-ul hashed. Acest ID hashed este comparat cu cele din fișierul unu. Aplicația returnează numele și data de naștere ale pacientului cu același ID cu hash ca tocmai creat.
• Dacă un pacient vine la noi și dorim să colectăm date noi, îi știm numele și data nașterii, dar nu îi cunoaștem ID-ul. În acest caz, putem introduce numele și data nașterii în aplicație și găsim ID-ul corespunzător. Pentru aceasta, aplicația merge la al doilea fișier și folosește ID-urile și sărurile pentru a crea ID-uri hashed. În timp ce face acest lucru, aplicația compară dacă ID-ul hashed corespunde cu unul dintre cele din fișierul unu. Dacă da, am găsit ce identitate are pacientul. Acest proces durează ceva timp, deoarece aplicația trebuie să parcurgă fiecare ID și pereche de sare până când este găsit ID-ul corect cu hashing.
• Dacă avem un pacient nou, îi putem introduce numele și data nașterii în aplicație. Acest lucru generează automat o intrare în fișierul unu (nume + data nașterii și codul hashed) și în fișierul doi (ID și sare).

Întrebare: Există vreo capcană evidentă în această procedură? Dacă ai putea numi o slăbiciune și cum să rezolvi asta, ar fi grozav. Îmi place să fiu blând pentru că sunt nou în acest domeniu.

Note:

• Știu că nu este nevoie teoretică de ID-uri generate aleatoriu, deoarece am putea folosi datele pacientului (nume și data nașterii) și o sare pentru a genera un ID hashed. Nu ne-am dorit această abordare, deoarece colegilor mei nu le place să aibă ID-uri foarte lungi în baza de date efectivă (fișierul trei).
• Descrierea lui bcrypt::hashpw() spune „Bcrypt este folosit pentru hashing securizat al parolei. Principala diferență cu algoritmii obișnuiți de digest cum ar fi MD5 sau SHA256 este că algoritmul bcrypt este proiectat special pentru a consuma intens CPU în pentru a proteja împotriva atacurilor de forță brută. Complexitatea exactă a algoritmului este configurabilă prin parametrul log_rounds. Interfața este pe deplin compatibilă cu cea Python.” (vezi Aici ).

Cel mai rău punct slab este că accesul de citire la primul fișier dezvăluie numele și data de naștere a pacienților.

Și apoi, accesul de citire la celelalte fișiere de către un adversar care cunoaște sistemul (cum se presupune în criptografie) permite obținerea datelor medicale pentru fiecare pacient identificat prin nume și data nașterii, la un cost de calcul suportabil.

Aceasta este o problemă de securitate IT fără o soluție criptografică completă. Soluția standard este de a restricționa accesul la citire la fișiere. Cel mai bun lucru pe care îl văd practic posibil fără o astfel de restricție este că cunoașterea/ghicirea exactă a numelui și a datei de naștere a unui pacient este necesară pentru a-i de-anonimiza datele și există un cost de calcul pentru a verifica o presupunere. Ideea generală este să fie fie

• nu stocați deloc numele și data nașterii; acest lucru pare posibil fără a modifica funcționalitatea așa cum este menționată în „în practică”, dar nu mai putem dezanonimiza și nici nu mai putem detecta că un nume/data de naștere greșit a creat intrări duplicate pentru același pacient.
• numele magazinului și data nașterii criptate sub o cheie publică, cu cheia privată păstrată cu precauții suplimentare și folosită (pentru a descifra) doar în cazul excepțional în care datele pacientului trebuie să fie de-anonimizate.

Ca o deosebire relativ minoră, „Atribuirea aleatorie a unui ID fiecărui pacient” necesită ceva nedeclarat pentru a evita codurile duplicate, iar o slăbiciune s-ar putea strecura acolo.