Cum să stocați în siguranță datele cu o parte nede încredere?

Alice vrea să păstreze valoare cheie se face perechi cu Bob. Scopul exercițiului este ca Alice să poată folosi Bob ca un serviciu de stocare a datelor de încredere, chiar dacă Bob nu era de încredere. Un MAC/AEAD/Semnătură (implementat corect) înseamnă că Bob nu poate modifica înregistrările. Dar autentificarea de bază nu este suficientă pentru a se asigura că Bob returnează înregistrarea corectă, deoarece nu îl împiedică pe Bob să reia înregistrările vechi.

Iată un exemplu. Să presupunem că undeva printre cheie și valoare este un autentificator securizat implementat corect pe care Alice îl poate folosi pentru a valida înregistrările primite:

• Alice se fixează cheie1:valoare1 cu Bob
  • Bob îl păstrează corect
• Alice suprascrie mai târziu cheia1 si seturi cheie1:valoare2 cu Bob unde valoare2 != valoare1
  • Când Alice întreabă cheia1 de la Bob, ea se așteaptă să primească valoarea2
  • Dar Bob putea salva și relua valoare1
    • Verificarea etichetei HMAC va trece deoarece ambele înregistrări au fost create de Alice

Prin urmare, simpla autentificare a datelor nu este suficientă. În mod natural, cineva ajunge la un fel de nonce. Cu toate acestea, pentru că este posibil ca Alice să piardă (sau să nu aibă) starea și să se bazeze pe recuperarea acelei stări de la Bob (tot scopul exercițiului), trebuie să abordăm cazul în care Alice nu are nicio stare și, în consecință, nu mai are cea mai recentă stare. nonce. Aceasta pare să fie partea grea.

Cum se poate asigura Alice că primește cel mai recent record de la Bob?

Alte obiective/probleme de securitate

Un Bob rău intenționat poate refuza în continuare stocarea înregistrărilor sau ștergerea înregistrărilor. Având în vedere că acestea sunt evenimente naturale care ar putea avea loc în timpul funcționării benigne (de exemplu, Bob rămâne fără spațiu), nu este clar că prevenirea acestor capacități este strict necesară sau benefică.

S-ar putea să existe și alte obiective în ceea ce privește stocarea/backup-ul securizat de care nu știu. O explicație sau o lucrare care să acopere noțiunile standard de securitate formalizate ale acestui subdomeniu ar fi grozavă.

Din „Titanium: un sistem de partajare a fișierelor care ascunde metadatele cu securitate rău intenționată”:

Mai mult, integritatea, care nu este asigurată în [34], este critică. Utilizatorii rău intenționați nu ar trebui să poată scrie altor utilizatori... fișiere. Serverele rău intenționate nu ar trebui să poată servi incorect sau fișiere învechite fără a fi prinse. Obținerea integrității în prezența unui adversar rău intenționat este o provocare și uneori imposibil. De exemplu, în orice construcție cu un singur server, acesta este imposibil să ai integritate [36–41] împotriva celor rău intenționați server deoarece serverul poate prezenta întotdeauna versiuni diferite a fişierelor către diferiţi utilizatori, despre care discutăm în §II-B.

Există un rezultat imposibil [36–41] care spune că stocarea pe un singur server sistemele nu pot oferi garanții de integritate împotriva malware server, deoarece serverul poate prezenta întotdeauna o versiune veche a stocare pentru anumiți utilizatori. Un sistem separat, fie un alt server [39] sau blockchain [40, 41], trebuie să fie utilizate pentru a recupera astfel garanții de integritate.

Referințele citate:

36. D. Mazieres și D. Shasha, âConstruirea sistemelor de fișiere securizate ` din depozitul bizantin,â în PODC â02.
37. J. Li, M. Krohn, D. Mazieres și D. Shasha, âSecure ` depozit de date nesigure (SUNDR),â în OSDI â04.
38. A. J. Feldman, W. P. Zeller, M. J. Freedman și E. W. Felten, âSPORC: Colaborarea de grup folosind neîncredere resurse cloud,â în OSDI â10.
39. N. Karapanos, A. Filios, R. A. Popa și S. Capkun, âVerena: protecție integrală a integrității pentru aplicațiile web,â în S&P â16.
40. A. Tomescu și S. Devadas, âCatena: Efficient nonequivocation via Bitcoin,â in S&P â17.
41. Y. Hu, S. Kumar și R. A. Popa, âGhostor: Toward a sistem securizat de partajare a datelor de la încredere descentralizată,â în NSDI â20