Teză elaborată în vederea obținerii titlului științific de “DOCTOR” în domeniul fundamental “ȘTIINȚE INGINEREȘTI”, domeniul “INGINERIE ELECTRONICĂ ȘI… [310399]

[anonimizat]: “XXXXXXXXXXXXXXXXXXX”

Teză elaborată în vederea obținerii titlului științific de

“DOCTOR” în domeniul fundamental “ȘTIINȚE INGINEREȘTI”,

domeniul “INGINERIE ELECTRONICĂ ȘI TELECOMUNICAȚII”

Conducător de doctorat:

Col. (r) prof. univ. dr. ing. Ciprian RĂCUCIU

BUCUREȘTI

2018

[anonimizat], a evoluat și importanța atribuită informației. [anonimizat] s-a [anonimizat] a o face disponibilă numai unui grup restrâns de indivizi. În Egiptul antic s-au descoperit texte cifrate datând chiar și de acum 4000 [anonimizat]-se astfel importanța pe care o dădeau oamenii antici informației și nevoii de proteja această informație.

Scrierea cifrată a apărut foarte des în lumea antică. Există date privind utilizarea acesteia în Grecia antică din secolul V î.Hr.. [anonimizat], o fâșie îngustă ([anonimizat]) [anonimizat], paralel cu axa bastonului. [anonimizat], făcând astfel mesajul indescifrabil. Pentru a decoda un astfel de mesaj era nevoie de un baston identic pe care se rula respectiva panglică și astfel informația cuprinsă putea fi citită. În Roma antică cifrul lui Cezar era folosit foarte des pentru a transmite în secret informații importante (militare, politice, etc.).

[anonimizat], este de o remarcabilă importanță. [anonimizat] „The Codebreakers”, susține faptul că „…criptologia s-a născut în lumea arabă…”. Între anii 700 și 1000 d.Hr., care au reprezentat și primele trei secole ale culturii și civilizației islamice în care aceștia au avut o mare extindere militară și politică, s-au făcut mari eforturi pentru a traduce în limba arabă marile opere ale antichității (romane, grecești, indiene, ebraice, siriene, armene, etc.). [anonimizat], [anonimizat], aceasta deoarece textele respective pot fi considerate texte cifrate. Civilizația arabă a preluat multe din cunoștințele matematice al civilizațiilor grecești și indiene, a [anonimizat] „arabe” și termenii „zero”, „algoritm” și „algebră”. Din aceste motive originile criptologiei precum si dezvoltările în domeniul criptanalizei se pot atribui lumii arabe.

Termenul de „cifru” [anonimizat] „sifr”. Acesta fiind o traducere din sanscrită în arabă a cifrei zero. La introducerea lui în Europa conceptului de „zero” a fost foarte ambiguu. Aceasta deoarece sistemul folosit de numerotare era cel roman. [anonimizat]. [anonimizat], este numită cifru. Astfel se poate observa că lumea arabă a avut o [anonimizat]ică. Se poate deci trage concluzia că din lumea antică, de-a lungul istoriei și până în prezent interesul pentru protejarea informației, a fost, este și cel mai probabil va fi în continuare unul deosebit.

Terminologie generală folosită în criptografie

În domeniul științei calculatoarelor și mai ales în domeniul securității informației se folosește un limbaj (jargon) specific. Deoarece un organism care să standardizeze/reglementeze limbajul specific diferitelor domenii și modul de folosire a termenilor specifici nu există, foarte des în lucrările de specialitate se folosesc termeni, de foarte multe ori, contradictorii. Din această cauză în următoarele rânduri vor fi prezentați câțiva termeni des întâlniți și definirea lor.

Conform „Webster’s Encyclopedic Unabridged Dictionary of the English Language” [ HYPERLINK \l "Web" 1 ] termenul informație poate fi definit ca o serie de „…cunoștințe comunicate sau recepționate cu privire la un fapt particular sau circumstanță…”, la modul general și „…date care pot fi codificate pentru prelucrarea de către un calculator sau un dispozitiv similar…”, la modul particular al științei calculatoarelor. Desigur o definiție completă și formală a termenului informație este data de C.E. Shanon în cărțile sale „A Mathematical Theory of Communications” 2] și „Communication Theory of Secrecy Systems” [ HYPERLINK \l "CES49" 3 ].

În concordanță cu definiția informației dată mai sus, termenul IT (i.e. „information technology”) sau Tehnologia Informației, face referire la toate tehnologiile ce au legătură cu informația. Mai specific, atunci când vorbesc de IT, autorii se referă la gestionarea informației codificate din punctul de vedere al transmiterii, procesării și stocării datelor acesteia. În mod asemănător atunci când facem referire la termenul de securitate IT, ne referim la lucruri ce au legătură cu securitatea informației și mai exact cu securitatea sistemelor de procesare și stocare a informației și a legăturilor de comunicații dintre acestea.

Astfel scopul securității comunicațiilor este de a proteja datele vehiculate într-o rețea de comunicații sau într-un sistem distribuit iar scopul securității calculatoarelor este de a preveni accesul neautorizat la sistemele de calcul și de a proteja informațiile stocate de distrugeri intenționate, modificare sau deconspirare.

Termenul rețea de calculatoare se referă la mai multe sisteme autonome conectate între ele. Două sau mai multe sisteme se pot considera conectate dacă au posibilitatea să schimbe date între ele folosind o anumită metodă (radio, cablu de rețea, conexiune serială/paralelă, etc.). Prin sisteme autonome se înțelege faptul că între două sau mai multe sisteme nu se poate stabili o relație clară de tipul master/slave. Astfel, un sistem cu o unitate master de control și mai multe unități slave nu formează o rețea.

Se face foarte des confuzie în literatura de specialitate în legătură în ceea ce privește diferența dintre un sistem distribuit și o rețea de calculatoare. Conform lui Leslie Lamport un sistem distribuit este „…o colecție de procese separate spațial și care comunică între ele prin schimb de mesaje”. Acesta a precizat de asemenea în lucrarea sa „Time, Clocks and the Ordering of Events in a Distributed System” 4], că pentru un sistem distribuit „întârzierea introdusă de comunicația cu mesaje nu este neglijabilă în raport cu evenimentele din cadrul unui proces”.

ISO – „International Organization for Standardization” (i.e. Organizația Internațională pentru Standardizare) pentru a defini un „document convenit care conține specificații tehnice sau alte criterii precise utilizate consistent ca reguli sau definiții de caracteristici pentru a asigura că materialele, produsele, procesele și serviciile sunt potrivite pentru scopul propus” folosește termenul standard. Astfel a apărut noțiunea de standard de sistem deschis („open sistem standard”). Acesta permite fabricanților de echipamente IT să construiască produse conforme și interoperabile.

Joint Technical Committee 1 (JTC1) („Comitetul Tehnic Întrunit 1”) aflat sub ISO și IEC („International Electrotechnical Committee”), atunci când se referă la o persoană sau entitate înregistrată care se poate autentifica la o rețea de calculatoare sau la un sistem distribuit, folosește termenul de partener. Astfel procesele, host-urile și utilizatorii sunt considerați parteneri.În acest context un utilizator este o persoană responsabilă pentru acțiunile sale în rețea, un host reprezintă o entitate adresabilă în cadrul unei rețele sau unui sistem distribuit (unde adresarea se face prin nume sau adresă) iar un proces reprezintă o instanțiere a unui program ce rulează pe un anume host.

În mod uzual, o vulnerabilitate (a unui sistem/rețele de calculatoare, etc.) reprezintă o slăbiciune ce poate fi exploatată de un atacator pentru a accesa un sistem și/sau informațiile vehiculate în cadrul acestuia. O amenințare se referă la o circumstanță, condiție sau eveniment care are potențialul de a încălca securitatea unui sistem de a cauza defecțiuni acestuia. Rețelele de calculatoare sunt sisteme distribuite foarte susceptibile la o multitudine de amenințări. Aceste amenințări pot fi reprezentate fie de intruși, fie de utilizatorii legitimi. Cei din urmă fiind considerați chiar mai periculoși decât intrușii deoarece aceștia au acces facil la mult mai multe informații care în mod normal nu sunt accesibile intrușilor.

Există mai multe tipuri de compromitere a bunei funcționării a rețelelor de calculatoarelor. Dinte acestea cele mai comune sunt compromiterea host-ului (unul sau mai multe), în urma unui eveniment de subminare a acestuia și compromiterea comunicației, în urma unui eveniment ce duce la subminarea legăturilor de comunicații ale respectivei rețele.

Compromiterea unui host poate avea ca rezultat o simplă modificare a stării proceselor și poate ajunge până la pierderea controlului asupra acestuia de către utilizatorii legitimi.

Protejarea legăturilor de comunicații este foarte importantă deoarece acestea reprezintă un punct foarte sensibil în cadrul unei rețele sau sistem. Se pot distinge două tipuri de atacuri ce pot avea ca rezultat compromiterea comunicației între elementele rețelei, atacul activ și atacul pasiv.

Atacul pasiv amenință confidențialitatea datelor transmise. Datele de la transmițător sunt observate de un intrus. Fezabilitatea unui astfel de atac depinde de tipul de mediu prin care are loc comunicarea. Astfel, liniile de comunicație mobile sunt relativ ușor de ascultat, pe când liniile fizice necesită acces fizic. Fibrele optice sunt și ele susceptibile la ascultare, dar cu un efort tehnologic substanțial.

Este interesant de remarcat că atacul pasiv nu se realizează exclusiv la nivelul căilor de comunicație hardware. Pe piață se găsesc pachete software pentru monitorizarea traficului în rețea în special în scop de management. Aceleași pachete se pot folosi, de exemplu, pentru capturarea parolelor necriptate din rețea.

Atacul activ amenință integritatea și / sau disponibilitatea datelor. În acest caz, intrusul poate observa și controla fluxul de informații, putându-l modifica, extinde, șterge și retrimite informații. În plus, intrusul poate inunda receptorul cu informații false pentru a cauza o întrerupere a comunicației, situație denumită uzual Denial of Service (interzicerea accesului la servicii).

Adesea, atacul poate să fie atât activ cât și pasiv. Spre exemplu, prin atac pasiv se obțin parolele de acces la un anumit serviciu, apoi prin atac activ se face autentificarea. Este deci clar că autentificarea prin parole nu este suficientă.

Alți termeni folosiți pentru clasificarea atacurilor sunt:

Întreruperea: O componentă a sistemului este distrusă, devine indisponibilă sau inutilizabilă total sau pentru o anumită perioadă de timp. Acest tip de atac este un atac asupra disponibilității. Exemple de astfel de atacuri ar fi: distrugerea unor echipamente hardware, tăierea liniilor de comunicație, distrugerea sistemului de fișiere sau tehnici de supraîncărcare a sistemului, care duc la blocarea comunicațiilor sau a întregului sistem, numite atacuri prin refuzul serviciilor (denial of service);

Interceptarea: Inamicul obține acces la o componentă a sistemului. Acesta este un atac asupra confidențialității. Inamicul poate fi o persoană, un program sau un calculator. Exemple de astfel de atacuri ar fi copierea ilegală a unor fișiere și programe sau interceptarea liniilor de comunicație;

Modificarea: Inamicul obține nu numai acces la o componentă din sistem, dar și falsifică informația obținută. Acesta este un atac asupra integrității. Exemplele includ modificarea unor valori din fișiere de date, modificarea unor programe sau transmiterea unor mesaje false prin rețea;

Construirea: Inamicul pătrunde în sistem și imită unele componente din acesta. Un atac de acest tip este un atac asupra autenticității. Un exemplu de acest gen ar putea fi introducerea unor mesaje false în rețea care sunt interpretate ca mesaje reale și inventarea unor fișiere care pot induce în eroare utilizatorii reali.

De asemenea asupra sistemelor informatice mai pot exista o serie de amenințări active:

Mascarada – este un tip de atac în care o entitate pretinde a fi o altă entitate. De exemplu, un utilizator încearcă să se substituie altuia sau un serviciu pretinde a fi un alt serviciu, în intenția de a obține date secrete (numărul cărții de credit, parola sau cheia algoritmului de criptare). O mascarada este însoțită, de regulă, de o altă amenințare activă, cum ar fi înlocuirea sau modificarea mesajelor;

Reluarea – se produce atunci când un mesaj sau o parte a acestuia este reluată (repetată), în intenția de a produce un efect neautorizat. De exemplu, este posibilă reutilizarea informației de autentificare a unui mesaj anterior;

Modificarea mesajelor – face ca datele mesajului să fie alterate prin modificare, inserare sau ștergere. Poate fi folosită pentru a schimba beneficiarul unui credit în transferul electronic de fonduri sau pentru a modifica valoarea acelui credit. O altă utilizare (foarte frecventă) poate fi modificarea câmpului destinatar/expeditor al poștei electronice;

Refuzul serviciului – se produce când o entitate nu reușește să îndeplinească propria funcție sau când execută acțiuni ce împiedică o altă entitate de a-și îndeplini propria funcție;

Repudierea serviciului – se produce când o entitate refuză să recunoască un serviciu executat. Este evident că în aplicațiile de transfer electronic de fonduri este important să se evite repudierea serviciului atât de către emițător, cât și de către destinatar.

Având în vedere multitudinea vulnerabilităților și a posibilităților de atac asupra sistemelor de transmitere și stocare a datelor sunt necesare metode pentru a proteja aceste date de răuvoitori. Astfel una dintre aceste metode este criptografia.

Comunicații bazate pe protocoale IP

Un protocol de comunicații este un set de reguli ce facilitează schimbul de informații/date într-o rețea. Într-o stivă de protocoale, cum este și stiva ISO/OSI sau stiva TCP/IP, fiecare protocol se bazează pe serviciile furnizate de protocolul de sub el. Un astfel de exemplu este un protocol de tip transfer de fișiere, FTP (nivel 7 ISO/OSI), care rulează peste TCP (nivel 4 ISO/OSI), care la rândul lui rulează peste IP (nivel 3 ISO/OSI), ce rulează peste Ethernet (nivel 2 ISO/OSI) și poate folosi ca mediu de transmisie un cablu torsadat UTP la viteza de 100Mb/s sau o pereche de fibre optice , etc. (nivelul 1 ISO/OSI).

Stiva de protocoale ISO/OSI

Stiva/modelul de protocoale ISO/OSI („International Organization for Standardization/Open Systems Interconnection”) (numit și modelul de referință ISO/OSI) este un model conceptual care caracterizează și standardizează funcțiile de comunicații ale unui sistem de transmisiuni sau ale unui sistem de calculatoare, fără să fie influențat de tehnologia pe baza căreia s-au dezvoltat echipamentele sau de structura internă a acestora. Scopul acestei stive este interoperabilitatea diverselor sisteme folosind protocoale standardizate. Modelul partiționează un sistem de comunicații în „niveluri de abstractizare”. Stiva de referință ISO/OSI este definită pe 7 niveluri.

Fiecare nivel oferă servicii nivelului superior și primește servicii de la nivelul inferior.

Stiva de referință ISO/OSI

Nivelurile stivei ISO/OSI sunt:

Nivelul fizic

Nivelul legătură de date

Nivelul rețea

Nivelul transport

Nivelul sesiune

Nivelul prezentare

Nivelul aplicație

Fiecare nivel inițiază pe orizontală instanțe ale protocoalelor specifice nivelului respectiv conform figura 1: Stiva de protocoale ISO/OSI.

La fiecare nivel X entitățile ce comunică schimbă între ele așa numitele PDU („Protocol Data Unit”) prin intermediul protocolului/alelor aferent/e acelui nivel. Fiecare PDU conține o parte numită „payload” sau SDU („Service Data Unit”) și o parte de „headere” (antet) și/sau „footere” (subsol) specifice protocolului respectiv.

Stiva de protocoale ISO/OSI nu a fost niciodată implementată în practică deoarece aceasta este un model de referință în urma căruia s-au creat alte suite de protocoale mult mai practice, e.g. TCP/IP, IPX/SPX, etc..

Stiva de rotocoale TCP/IP

Numită și „Suita de protocoale Internet” este un model conceptual și un set de protocoale de comunicații folosit cel mai adesea în Internet și în rețelele de calculatoare similare Internet-ului. Este cunoscută cel mai adesea ca TCP/IP („Transmission Control Protocol/Internet Protocol”), dar în trecut era cunoscută și ca modelul DoD („Department of Defence”), deoarece a fost inițial dezvoltată și fundamentată de Departamentul Apărării al Statelor Unite prin DARPA („Defence Advanced Research Projects Agency”).

Stiva TCP/IP asigură comunicații de date cap-la-cap („end-to-end”) specificând cum trebuie împachetate, etichetate, transmise, routate (direcționate) și recepționate datele. Spre deosebire de stiva ISO/OSI stiva TCP/IP este împărțită în patru niveluri de abstractizare care clasifică protocoalele aferente conform scopului pe care acestea îl au în rețea.

Nivelurile stivei TCP/IP sunt:

Nivelul legătură de date numit și „Link”

Nivelul rețea numit și Internet

Nivelul transport

Nivelul aplicație

Nivelul legătură de date asigură metodele de comunicație pentru același segment de rețea („link”). Nivelul rețea asigură comunicare inter-link-uri („internetwork”) între segmentele diferite de rețea. Nivelul transport se ocupă cu comunicarea entitate-la-entitate („host-to-host”) iar nivelul aplicație asigură schimbul de date între procesele aceleiași aplicații („process-to-process”).

Stiva TCP/IP funcționează asemănător stivei ISO/OSI, singura diferență de principiu fiind numărul de nivele. Stiva TCP/IP a „concatenat” unele din nivelurile stive ISO/OSI (figura 3).

Fiecare echipament care lucrează într-o rețea funcționează până la un anumit nivel din stiva TCP/IP. De exemplu un router, prin definiție, lucrează până la nivel 2 TCP/IP (echivalent nivel 3 ISO/OSI). De asemenea un switch funcționează, prin definiție, până la nivel 1 TCP/IP (nivel 2 ISO/OSI). În schimb un calculator (PC) lucrează cu toate nivelurile stivei. În figura 4 se poate vedea cum este folosită stiva TCP/IP pentru scenariul când entitatea A (poate fi un PC) dorește să comunice cu entitatea B (poate fi un alt PC sau un server), folosind o rută care tranzitează doua routere.

Comparație intre stiva ISO/OSI și stiva TCP/IP

Modul în care este folosită stiva TCP/IP (exemplu cu două routere)

Necesitatea securizării comunicațiilor digitale

Informația a însemnat întotdeauna putere, prin urmare dorința de a o proteja, de a o face accesibilă doar unor elite, unor inițiați, s-a pus din cele mai vechi timpuri. Primele texte cifrate descoperite până în prezent datează de circa 4000 de ani și provin din Egiptul Antic.

Există date privind utilizarea scrierii cifrate în Grecia Antică încă din secolul al V-lea î.e.n. Pentru cifrare se folosea un baston în jurul căruia se înfășura, spirală lângă spirală, o panglică îngustă de piele, papirus sau pergament, pe care, paralel cu axa, se scriau literele mesajului. După scriere, panglica era derulată, mesajul devenind indescifrabil. El putea fi reconstituit numai de către persoana care avea un baston identic cu cel utilizat la cifrare. În Roma Antică, secretizarea informațiilor politice și militare se făcea utilizând diverse tipuri de scrieri secrete, dintre care amintim cifrul lui Cezar, utilizat încă din timpul războiului galic.

Contribuția arabă la dezvoltarea criptologiei, mai puțin cunoscută și mediatizată, este de o remarcabilă importanță. David Kahn, unul dintre cei mai de seamă istoriografi ai domeniului, subliniază în cartea sa The Codebreakers că, criptologia s-a născut în lumea arabă. Primele trei secole ale civilizației islamice (700-1000 e.n.) au constituit, pe lângă o mare extindere politică și militară și o epocă de intense traduceri în limba arabă ale principalelor opere ale antichității grecești, romane, indiene, armene, ebraice și siriene. Unele cărți sursă erau scrise în limbi deja moarte, deci reprezentau în fapt texte cifrate, astfel încât traducerea lor constituie primii pași în criptanaliză, deci originile criptologiei pot fi atribuite arabilor. Dezvoltările criptanalizei au fost mult sprijinite de studiile lingvistice ale limbii arabe. Arabii au preluat cunoștințele matematice ale civilizațiilor grecești și indiene. Arabii sunt cei care au introdus sistemul zecimal de numerotație și cifrele „arabe”. Termenii „zero“, „algoritm”, „algebră” li se datorează tot lor.

Însuși termenul de „cifru” provine din limba arabă. El își are originea din cuvântul arab „sifr” care reprezintă traducerea în arabă a cifrei zero din sanscrită. Conceptul de „zero” a fost deosebit de ambiguu la începuturile introducerii lui în Europa, în care sistemul de numerotație folosit era cel roman. De aceea se obișnuia să se spună despre cineva care vorbea neclar că vorbește ambiguu, ca un cifru. Acest înțeles de ambiguitate a unui mesaj poartă și azi denumirea de cifru.

Prin urmare, putem concluziona că, încă din antichitate s-a încercat securizarea informației și a datelor transmise. Astăzi necesitatea securizării comunicațiilor are o importanță deosebită, mai ales în contextul în care tehnologia comunicațiilor IP este predominantă la nivel întregii planete. De asemenea această tehnologie permite utilizarea în comun a resurselor rețelelor IP ceea ce impune o importanță deosebită domeniului securității informațiilor.

Informații generale

Criptografia (cuvânt derivat din limba greacă a cuvintelor kryptós (ascuns) și gráfein (a scrie) reprezentând scriere ascunsă) este știința care se ocupă cu studiul codurilor și cifrurilor. Un cifru este de fapt un algoritm criptografic care poate fi folosit pentru a transforma un mesaj clar (text clar) într-un mesaj indescifrabil (text cifrat). Acest proces de transformare se numește criptare iar procesul invers se numește decriptare.

Știința care se ocupă cu decriptarea (spargerea) cifrurilor se numește criptanaliză. Criptanaliza se ocupă cu studiul transformării unui text neinteligibil înapoi în cel inteligibil fără a cunoaște cheia de criptare.

Sistemul format dintr-un algoritm de criptare și o cheie de criptare se numește criptosistem.

Inițial, securitatea unui cifru depindea de faptul că inamicul nu cunoștea algoritmul de criptare folosit, dar pe măsură ce criptografia a evoluat, securitatea cifrului s-a bazat pe utilizarea unei chei secrete care nu se poate extrage din textul cifrat. Până la jumătatea secolului XX, nu a fost demonstrat faptul că un anumit cifru nu poate fi spart, ba chiar întreaga istorie a criptografiei este plină de relatări în care anumit cifru era spart iar ulterior erau creați alți algoritmi care la rândul lor erau sparți.

Arhitectura OSI a securității

Arhitectura OSI a securității este o descriere generală a serviciilor de securitate și a mecanismelor înrudite și discută relațiile dintre acestea și cum corespund unei arhitecturi de rețea.

Servicii de securitate

Arhitectura OSI distinge cinci clase de servicii de securitate: autentificarea, controlul accesului, confidențialitatea datelor, integritatea datelor și non-repudierea.

Serviciile de autentificare permit autentificarea entităților participante la comunicație sau a originii datelor:

Serviciul de autentificare a entităților similare verifică faptul că o entitate dintr-o asociație aparține acesteia și nu încarcă să-și falsifice identitatea sau să retransmită copii neautorizate ale identităților din trecut. Acest fel de autentificare se face în faza de stabilire a conexiunilor, și ocazional în timpul fazei de transfer de date;

Serviciul de autentificare a originii datelor verifică sursele de date, dar nu poate oferi protecție împotriva duplicării sau modificării datelor, în acest caz folosindu-se serviciul de la punctul anterior. Serviciul de autentificare a originii datelor se folosește în timpul fazei de transfer de date.

Serviciul de control al accesului protejează împotriva folosirii neautorizate a resurselor sistemelor. Acest tip de serviciu conlucrează strâns cu serviciile de autentificare, deoarece pentru a media accesul la o resursă, utilizatorul trebuie să își confirme identitatea.

Serviciul de confidențialitate a datelor protejează sistemul de divulgare neautorizată a datelor.

Serviciul de confidențialitate a conexiunii furnizează confidențialitatea tuturor informațiilor transmise într-o conexiune;

Serviciul de confidențialitate fără conexiune furnizează confidențialitatea unităților de informație;

Serviciul de confidențialitate cu câmp selectiv furnizează confidențialitatea câmpurilor specifice dintr-un flux pe durata unei conexiuni sau a unei unități de informație;

Serviciul de confidențialitate a fluxului de trafic furnizează protecție împotriva analizei traficului.

Serviciile de integritate a datelor protejează datele de modificări neautorizate.

Serviciul de integritate a serviciului cu recuperare furnizează integritatea datelor într-o conexiune. Pierderea integrității este recuperată dacă acest lucru este posibil;

Serviciul de integritate a serviciului fără recuperare, ca și în cazul precedent furnizează integritatea datelor într-o conexiune. Pierderea integrității nu se poate recupera;

Serviciul de integritate a unui câmp desemnat furnizează integritatea unor câmpuri specifice în cadrul conexiunii;

Serviciul de integritate fără conexiune furnizează integritatea unor unități de date separate;

Serviciul de integritate a unui câmp desemnat fără conexiune furnizează integritatea unor câmpuri specifice din unități de date separate.

Serviciul de non-repudiere (non-negare) furnizează protecție împotriva negării ulterioare a trimiterii sau recepționării unui mesaj. Putem distinge două feluri de servicii:

Serviciul non-repudiere cu dovada originii, oferă receptorului o dovadă a originii mesajului;

Serviciul non-repudiere cu dovada livrării, oferă transmițătorului o dovadă a recepționării mesajului.

Mecanisme de securitate

Arhitectura OSI de securitate face distingere între mecanisme specifice și mecanisme generale de securitate.

Mecanisme specifice de securitate:

Codificarea se folosește pentru a proteja confidențialitatea unităților de informație și deseori se folosește complementar cu alte mecanisme. Tehnicile de criptografie sunt prezentate în secțiunile următoare;

Semnăturile digitale se folosesc în analogie electronică la semnăturile de mână, pentru documente electronice. Similar cu corespondentul real, semnăturile electronice nu trebuie să se poată falsifica, destinatarul să o poată verifica și emitentul să nu o poată nega mai târziu;

Controlul accesului forțează aplicarea drepturilor de acces prin utilizarea identității autentificate a părților. Dacă una dintre părți încearcă să folosească o resursă neautorizată, serviciul blochează această tentativă și opțional poate genera o alarmă care să apară în auditul de securitate;

Integritatea datelor este un mecanism care protejează unitățile de informație sau câmpuri din acestea. În general, acest tip de mecanism nu protejează împotriva atacurilor de tip replay;

Schimbul de autentificare verifică identitatea părților. În conformitate cu ITU X.509, un mecanism de autentificare se numește puternic dacă se bazează pe tehnici criptografice pentru a codifica schimbul de mesaje;

Completarea traficului protejează împotriva analizei datelor. Acest mecanism maschează datele reale intercalând date fără valoare, fiind efectiv în conjuncție cu un mecanism de confidențialitate;

Controlul rutărilor se folosește pentru alegerea dinamică sau într-un mod predeterminat a rutelor pentru transmiterea informației. Sistemele de comunicație pot comanda modificarea rutei la descoperirea unui atac pasiv sau activ. În mod asemănător, anumite informații cu etichete de securitate speciale pot fi rutate pe căi speciale;

Notarizarea se referă la asigurarea transmiterii unor proprietăți ale informației, cum ar fi integritatea, originea, timpul și destinația. Asigurarea se face de către un terț într-o manieră verificabilă.

Mecanisme generale de securitate:

Mecanismele generale de securitate nu sunt specifice nici unui serviciu, iar unele se confundă cu managementul securității. Importanța mecanismelor generale de securitate este în strânsă legătură cu nivelul de securitate cerut. OSI specifica cinci mecanisme generale de securitate:

Conceptul general de funcționalitate credibilă se poate folosi fie pentru a extinde fie pentru a defini eficiența altor mecanisme de securitate. Orice funcționalitate care oferă în mod direct sau mijlocește accesul la mecanismele de securitate trebuie să fie de încredere;

Resursele sistemului pot avea etichete de securitate asociate cu acestea. Deseori este necesar ca etichetele să fie transmise împreună cu datele în tranzit, sub forma unor informații adiționale asociate datelor de transferat sau sub formă implicită dată de context, cum ar fi rută sau sursă;

Detectarea evenimentelor se poate folosi pentru a detecta violarea de securitate;

Auditul de securitate se referă la o examinare independentă a jurnalelor sistemului pentru a testa acuratețea controalelor de sistem, pentru a se asigura alinierea la politica și practicile de securitate, pentru a detecta breșele de securitate și pentru a recomanda schimbări în control, politică și proceduri;

Recuperarea de siguranță se ocupă cu manipularea cererilor mecanismelor de securitate și aplică un set de reguli stabilit apriori.

Arhitectura OSI a securității nu urmărește să rezolve o anume problemă a rețelei, ci stabilește un cadru și o terminologie care poate fi folosită pentru a descrie și discuta problemele și soluțiile lor.

Integrarea criptografiei în arhitectura OSI

Datele codificate într-un fel anume pot trece prin mai multe noduri ale rețelei până să ajungă la destinație. Putem identifica mai multe posibilități de integrare ale punctelor de cifrare în arhitectura unei rețele.

Cifrarea la nivel de legătură de date presupune codificarea și decodificarea mesajului la fiecare nod de comunicație. Fiecare nod are propria cheie și posibil propriul algoritm de criptare. În acest caz, datele sunt protejate doar pe mediul fizic de transmitere

Cifrarea la nivel de rețea este similară cu cea la nivel de legătură, restrângându-se circulația în clar într-un „modul de securitate”. Fiecare legătură utilizează o cheie unică, iar trecerea de la o cheie la alta se face în modulul de securitate;

Cifrarea la nivel superior este o soluție ce pare mai naturală într-un sistem orientat prin „sesiuni”, unde schimburile sunt relativ lungi. Toate informațiile care tranzitează prin rețea sunt cifrate în general cu aceeași cheie pe durata între sesiuni între entitățile sursă și destinație ale schimbului. Cifrarea poate fi implementată prin protocoale la nivel de sesiune sau prezentare. Această soluție are avantaje și dezavantaje. La cifrarea pe legătura de date, utilizatorii au nevoie doar de o singură cheie când comunică cu sistemul local, restul cheilor fiind gestionate automat de sistem. În acest caz însă, utilizatorul trebuie să comunice cu alți utilizatori folosind chei separate. În plus, se pune problema distribuției cheilor prin protocoale speciale în vederea stabilirii unor conexiuni sigure.

Cifrarea la nivel superior oferă o securitate sporită, deoarece datele circulă codificat pe tot parcursul, dar adresa destinației trebuie păstrată în clar, ceea ce ar putea fi o posibilă verigă slabă. La cifrarea la nivel de legătură, datele pot fi observate în clar la fiecare nod. Adresa destinației este secretă pe parcursul transmisiei, ceea ce face mai dificilă prognoza rutei.

În cazul unor aplicații care necesită un nivel mai ridicat de securitate, pe lângă păstrarea confidențialității datelor este necesar a se păstra și confidențialitatea destinației. Fiecare pachet are asociat un câmp de adresă cifrat cu cheia nodului anterior. Această schemă se numește sistem de cifrare la nivel superior în combinație cu cifrarea pe legătură a adresei destinație.

Criptografia

Toate criptosistemele pot fi împărțite în două tipuri: criptosisteme simetrice numite și clasice sau convenționale și criptosisteme asimetrice numite și moderne. Criptosistemele simetrice, sau cu cheie secretă, sunt acele criptosisteme în care numai emițătorul și receptorul cunosc cheia secretă pe care o aplică la fiecare criptare sau decriptare. Criptosistemele asimetrice, sau cu cheie publică, se bazează pe perechi de chei. Una din chei (cheia publică) este folosită la criptare, iar cealaltă (cheia privată) este folosită la decriptare.

Criptografia clasică

În criptografia clasică mesajul clar, numit și text clar, este convertit într-o secvență aparent aleatoare și fără sens, numită text cifrat. Procesul de criptare presupune un algoritm de criptare și o cheie de criptare. Această cheie este o valoare independentă de textul care se dorește a fi criptat. Odată produs, textul criptat trebuie transmis destinatarului. La recepție acest text criptat trebuie transformat în textul original folosind un algoritm de decriptare bazat pe aceeași cheie folosită la criptare.

Securitatea criptografiei clasice

Securitatea criptării convenționale depinde de două aspecte esențiale: algoritmul de criptare și cheia de criptare. Algoritmul de criptare, care trebuie să fie destul de puternic pentru a face imposibilă o decriptare numai pe baza textului criptat. Cheia de criptare trebuie să fie destul de lungă pentru a asigura o criptare puternică și mai ales trebuie să fie secretă. Deci nu este nevoie de păstrarea în secret a algoritmului folosit, ci numai a cheii de criptare. Acest lucru oferă un avantaj foarte mare criptării convenționale și a ajutat la răspândirea ei pe scară largă.

Există două cerințe esențiale care trebuie să le îndeplinească un algoritm de criptare:

Costul spargerii codului să depășească valoarea informației criptate;

Timpul necesar spargerii codului să depășească timpul de viață al informației, adică timpul până când informația nu mai are valoare.

Un algoritm de criptare care satisface aceste două cerințe este numit algoritm cu securitate computațională.

În tabelul 1 sunt prezentați timpii necesari pentru decriptarea unui text cifrat, folosind metoda forței brute, pentru diferite lungimii ale cheii de criptare.

Timpii necesari pentru decriptare folosind forța brută.

Un algoritm de criptare este de securitate necondiționată dacă textul criptat generat de acesta nu conține destulă informație pentru a determina textul original, indiferent de volumul de text decriptat care este în posesia atacatorului. De asemenea, nu contează puterea de calcul și timpul de care dispune inamicul, mesajul nu poate fi decriptat deoarece informația necesară nu este acolo.

Cu excepția unui algoritm numit “one-time pad”, propus de Gilbert Vernam în 1920, nu există algoritm de criptare care să fie de o securitate necondiționată. Securitatea acestui algoritm a fost demonstrată în 1949 de către Claude Shannon, condițiile fiind ca, cheia de criptare să fie de aceeași lungime cu textul clar, să fie secretă și să nu fie folosită decât o singură dată. Algoritmul „one-time pad” a fost implementat pentru transmiterea de informații sensibile, dar, marea problemă rămâne distribuirea cheilor de criptare care trebuiesc schimbate la fiecare utilizare și sunt foarte mari.

Modelul criptării clasice

Un model de criptosistem simetric (clasic) este prezentat în figura 1:

Un criptosistem clasic de comunicații

O sursă “emițător” produce un mesaj de tip text simplu (un șir de caractere), X = [X1,X2,…,XM]. Cele M elemente din X sunt niște litere ale unui alfabet finit. Pentru criptare trebuie generată o cheie de forma K = [K1,K2,…,KJ]. Dacă cheia este generată de sursa mesajului aceasta trebuie transmisă destinatarului printr-un canal de comunicație sigur. O alternativă este ca o a treia parte să genereze cheia care să fie transmisă celor două părți folosind o metodă cu grad înalt de securitate.

Cu mesajul X și cheia de criptare K ca și intrare, algoritmul de criptare formează textul criptat Y = [Y1,Y2,…,YN]. Astfel putem scrie:

Y=EK(X)

Această notație indică faptul că Y este produs folosind algoritmul E pe baza textului X cu o funcție specifică determinată de valoarea cheii K.

Destinatarul, aflat în posesia cheii, poate inversa procesul de transformare:

X=DK(Y)

Unde D este algoritmul de decriptare.

Un inamic, observând Y și presupunând că cunoaște algoritmul de criptare E și decriptare D, va încerca să reconstituie X sau K sau ambele.

Procesul prin care se încearcă descoperirea lui X sau K, adică a textului necriptat, respectiv a cheii de criptare, se numește criptanaliză.

Criptografia modernă

Ideea funcțiilor cu sens unic a dus la inventarea criptografiei cu chei publice de către Diffie și Hellman în 1976. Din punct de vedere practic, criptografia cu chei publice presupune existența unei perechi de chei legate matematic. Una dintre ele se numește cheie publică și trebuie publicată – fără a afecta securitatea sistemului – iar cealaltă este cheia privată care nu trebuie să fie deconspirată în nici un fel. Derivarea cheilor una dintr-alta este nefezabilă din punct de vedere computațional. Cel mai folosit sistem cu chei publice este RSA, inventat în 1978 de Rivest, Shamir și Adelman la Massachusetts Institute of Technology (MIT).

Algoritmul RSA este folosit în prezent pentru securizarea comunicațiilor din internet, a tranzacțiilor bancare sau a comerțului electronic. Securitatea lui se bazează pe complexitatea matematică pe care o impune factorizarea numerelor prime.

Aplicarea criptografiei cu chei publice necesită un cadru de autentificare care leagă cheia publică a utilizatorului de identitatea sa. Certificatul cu cheie publică este o dovadă certificată de o autoritate de certificare (CA – certificate authority). Folosirea CA evită verificarea de către utilizatorii individuali a cheilor publice ale altor utilizatori.

Criptografia cu chei publice este mai convenabilă teoretic decât criptografia cu chei secrete deoarece părțile nu mai trebuie să fie în posesia aceleiași chei. Astfel, fiind necesară o schemă de distribuție a cheilor mult mai simplă.

Totuși, criptografia cu chei publice necesită în general operații matematice dificile pentru procesoare mici. Spre exemplu, performanța cardurilor inteligente nu este suficient de mare pentru a permite utilizarea criptografiei cu chei publice, dar este interesant de văzut cum calculatorul gazdă poate prelua o parte din sarcini până la atingerea unui nivel de performanță satisfăcător. O alternativă este folosirea criptografiei cu chei publice ca mecanism de distribuție a cheilor pentru un criptosistem cu chei secrete.

Deci, criptosistemele cu chei publice suplinesc dezavantajul major al celor cu cheie secretă datorită faptului că nu mai este necesar schimbul de chei. Totuși, criptosistemele asimetrice cum este și RSA au marele inconvenient că securitatea lor se bazează pe complexitatea matematică a calculelor.

La nivelul actual al sistemelor de calcul un astfel de criptosistem poate fi spart în durate chiar de ordinul sutelor de ani, funcție de lungimea cheii, dar având în vedere faptul că, încă din 1985, David Deutsch a descris principiile de funcționare ale unui calculator cuantic, un supercalculator cu o putere de calcul extraordinar de mare care funcționează pe principiile fizicii cuantice, putem presupune că în viitor criptosistemele cu chei publice ar putea deveni nesigure.

În concluzie, singurul criptosistem absolut sigur rămâne one-time pad (cu condițiile prezentate mai sus cu privire la lungimea cheii și secretul ei). Există totuși metode care se adresează problemei distribuirii în secret a cheilor. Unele dintre aceste metode sunt legate de folosirea principiilor mecanicii cuantice. Mai exact există o serie de sisteme implementate ce se adresează distribuției cheilor – sistemele de distribuire cuantică a cheilor (Quantum Key Distribution – QKD). Despre acestea voi discuta ulterior în această lucrare.

Algoritmi de criptare

Algoritmi simetrici de tip bloc

În criptografie, un cifru pe blocuri sau un cifru bloc este un cifru care operează pe grupuri de biți de lungime fixă, denumite blocuri. Atât algoritmii de criptare cu chei simetrice, cât și cei cu chei asimetrice pot fi cifruri pe blocuri. Atenția în această parte va fi îndreptată către algoritmii simetrici de tip bloc.

Aparent, lungimea fixă a mesajului clar este o importantă limitare a gradului de utilizare a cifrurilor pe blocuri. Pentru a cripta un mesaj de o lungime diferită de cea a blocului, mesajul este partiționat în componente de lungime egală cu cea a blocului, care sunt criptate și concatenate pentru obținerea mesajului criptat. Dacă ultima componentă rămâne mai mică decât blocul, se folosește ceea ce se numește padding: completarea textului clar cu un șir de biți a cărui structură este predefinită, până când el are lungimea egală cu cea a blocului.

Din punct de vedere matematic, un cifru pe blocuri este o funcție care are proprietatea că pentru orice , este o funcție bijectivă definită pe Vn cu valori în Vn. Aici, Vn este mulțimea vectorilor de n biți, iar K este o mulțime a cheilor.

Numărul n din definiție este lungimea blocului, iar funcția inversabilă de criptare este în esență o permutare pe mulțimea vectorilor de n biți. Dacă cheile definesc fiecare o funcție bijectivă diferită, și toate cheile sunt valide (adică ), atunci numărul total de chei este log|K| . Dacă toate cheile au aceeași probabilitate de utilizare, atunci și entropia spațiului cheilor este tot log | K | .

În practică, algoritmii de tip bloc criptează, în general, mesajul în blocuri de 64 sau 128 de biți. Pentru acesta se aplică o funcție matematică între un bloc de biți ai mesajului în clar și cheie (care poate varia ca mărime), rezultând același număr de biți pentru mesajul criptat. Funcția de criptare este realizată astfel încât să îndeplinească următoarele cerințe:

știind un bloc de biți ai textului în clar și cheia de criptare, sistemul să poată genera rapid un bloc al textului criptat;

știind un bloc de biți ai textului criptat și cheia de criptare/decriptare, sistemul să poată genera rapid un bloc al textului în clar;

știind blocurile textului în clar și ale textului criptat, sistemului să-i fie dificil să genereze cheia.

Acest tip de algoritmi este foarte folosit în criptografia modernă. În continuare sunt prezentați câțiva algoritmi care au fost implementați la scara largă de-a lungul timpului.

Algoritmul Lucifer

Acest algoritm este un proiect al companiei IBM inițiat în anul 1970 pentru crearea unui cifru bloc rezistent. Rezultatele cercetărilor au contribuit la crearea a două metode de construire a cifrurilor bloc rezistente – rețelele Feistel și rețelele SP (Substitution- Permutation Network). Acest algoritm a pus bazele criptografiei simetrice moderne. În proiect au participat Horst Feistel și Don Coppersmith, care mai târziu au devenit criptografi vestiți.

Lucifer este o rețea de permutări și substituții, bazate pe așa numitele „cutii-S” care au intrări și ieșiri de 4 biți. Intrarea este o permutare a biților ieșirii din faza anterioară, iar intrarea din prima fază este chiar textul în clar. Un bit cheie este folosit pentru a alege între „cutia-S” actuală din două posibile (Lucifer implementează aceasta printr-o „cutie-T” cu 9 biți la intrare și 8 la ieșire). Lucifer are 16 faze, blocuri de 128 de biți și o manipulare a cheii suficient de complicată. În figura 2 este prezentată schema unei „cutii-S” iar în figura 3 – a rețelei Feistel.

Schema unei „cutii-S”

În rețeaua Feistel informația este divizată în blocuri de lungime fixă: 64, 128 biți. Fiecare bloc este divizat în 2 sub-blocuri L0 și R0. Asupra blocului L0 se aplică funcția f(L0,K0) iar rezultatul se adună modulo 2 cu R0 și se atribuie blocului nou de stânga L1, care este jumătatea datelor de intrare a rundei următoare. Iar blocul de stânga L0 se atribuie fără modificări blocului nou de dreapta R1, care este a doua jumătate. Operația se repetă în funcție de numărul rundelor în algoritm iar la fiecare etapă se modifică, conform unei reguli matematice, cheile de rundă K0 cu K1.

Schema rețelei Frestel

Folosind criptografia diferențială împotriva primei forme de Lucifer, criptologii Biham și Shamir au arătat că Lucifer cu 8 faze și 32 de biți poate fi spart cu 40 de texte în clar alese și 229 pași; același atac poate sparge Lucifer cu 8 faze și 128 biți cu 60 de texte în clar alese și 253 pași. Analize ulterioare au arătat că peste jumătate din chei nu sunt sigure, ceea ce conduce la posibilitatea de a sparge Lucifer cu 128 de biți, cu orice număr de faze, cu 233 texte în clar alese, sau cu 265 texte în clar cunoscute cu chei alese. În concluzie, a doua formă de Lucifer este mai slabă.

Cu toate neajunsurile care la avea, algoritmul Lucifer a contribuit la dezvoltarea ulterioară a cifrurilor bloc și chiar a unora foarte importante cum ar fi DES.

Algoritmul DES (Data Encryption Standard)

A fost elaborat pentru guvernul Statelor Unite și pentru folosință publică. El a fost dezvoltat plecând de la algoritmul “Lucifer”. În mai 1973, revista Federal Register a sintetizat principiile care trebuie să stea la baza proiectării unui algoritm criptografic standard: algoritmul trebuie să asigure un înalt nivel de securitate; să fie complet specificat și simplu de înțeles; securitatea algoritmului trebuie să fie asigurată de cheie și nu trebuie să depindă de păstrarea secretă a algoritmului; algoritmul trebuie să fie disponibil tuturor utilizatorilor; să fie adaptabil pentru diverse aplicații; să fie implementabil pe dispozitivele electronice; să fie eficient în utilizare; să poată fi validat; algoritmul trebuie să fie exportabil.

DES a fost oficial adoptat ca standard federal în 23 noiembrie 1976, iar în 1977 specificațiile sale au fost făcute publice.

Algoritmul DES este o combinație complexă folosind două blocuri fundamentale în criptografie: substituția și permutarea (transpoziția). Acest cifru bloc acceptă un bloc de 64 de biți la intrare și generează un bloc cifrat de 64 de biți. DES este un algoritm simetric. Același algoritm și aceeași cheie sunt folosiți atât pentru criptare cât și pentru decriptare.

Algoritmul este constituit din 16 cicluri repetate ale blocurilor fundamentale. Textul inițial este descompus în blocuri de 64 de biți. Cheia este de 64 biți din care doar 56 sunt efectivi, ceilalți fiind biți de paritate. Folosirea substituției provoacă confuzie prin substituirea sistematică a unor biți cu alții. Transpozițiile provoacă difuzie prin reordonarea biților. DES folosește numai operații clasice aritmetice și logice cu număr de până la 64 de biți, ceea ce face relativ ușor de implementat atât software cât mai ales hardware: unul din scopurile declarate ale algoritmului fiind ușoara lui implementare hardware într-un cip specializat.

Cu algoritmul DES se poate face atât cifrarea cât și decifrarea unui mesaj.

Deși DES a fost cel mai celebru algoritm al secolului XX este considerat la această oră nesigur pentru multe aplicații. Pare paradoxal, dar aceasta este consecința măririi considerabile a puterii de calcul de la confirmarea DES-ului ca un standard criptografic și până in anul 2000. Slăbiciunea pleacă de la lungimea prea mică a cheii de 56 de biți. Varianta algoritmului cunoscută ca triplu-DES este cea care este considerată sigură și la această oră.

Structura generală

Structura generală a algoritmului este reprezentată în figura 4 (dreapta): sunt 16 pași identici de procesare, numiți runde. Există și câte o permutare inițială și finală, numite PI și PF, care sunt funcții inverse (PI „anulează” acțiunea lui PF și vice-versa). PI și PF nu au aproape nici o importanță criptografică, dar au fost incluse pentru a facilita încărcarea și descărcarea blocurilor folosind hardware-ul din anii 1970. Înaintea rundelor principale, blocul este împărțit în două jumătăți, de câte 32 de biți, și procesate alternativ; această alternare este cunoscută drept Schema Feistel. Structura Feistel asigură că, criptarea și decriptarea sunt procese foarte asemănătoare — singura diferență este ordinea aplicării sub-cheilor – invers la decriptare. Restul algoritmului este identic. Acest lucru simplifică implementarea, în special cea hardware, deoarece nu e nevoie de algoritmi separați. Funcția F amestecă jumătate din bloc cu o sub-cheie. Rezultatului funcției F este combinat cu cealaltă jumătate de bloc, iar jumătățile sunt interschimbate înaintea următoarei runde. După ultima rundă, jumătățile nu sunt schimbate; aceasta este o trăsătură a structurii Frestel care face din criptare și decriptare procese similare.

Dreapta: Structura Frestel generală a DES; Stânga: Funcția Frestel (F) din DES

Funcția Freistel (F)

Funcția F, care apare în figura 4 (stânga), operează pe o jumătate de bloc (32 biți) la un moment dat și este formată din patru pași:

Expansiune – jumătatea de bloc de 32 de biți este extinsă la 48 de biți folosind funcția de expansiune, notată E în diagramă, prin duplicarea unor biți;

Amestecare – rezultatul este combinat cu o sub-cheie folosind operația XOR. Șaisprezece sub-chei de 48 de biți – una pentru fiecare rundă – sunt derivate din cheia principală folosind diversificarea cheilor (descrisă mai jos);

Substituție – după amestecarea cu sub-cheia, blocul este divizat în opt bucăți de 6 biți fiecare înainte de procesarea folosind cutiilor S, sau cutii de substituție. Fiecare din cele opt cutii S înlocuiește cei șase biți de intrare cu patru biți conform unei transformări neliniare, oferită sub forma unui tabel de căutare. Cutiile S reprezintă securitatea lui DES – fără ele, cifrul ar fi liniar și ușor de spart;

Permutare – în final, cele 32 de ieșiri din matricele S sunt rearanjate conform permutării fixe P.

Alternarea substituțiilor din matricele S și permutarea biților folosind matricea P și expansiunea E oferă ceea ce se numește „confuzie și difuziune”, un concept identificat de către Claude Shannon în anii 1940 ca fiind necesar unui cifru sigur și practic în același timp.

Diversificarea cheilor

Pentru diversificarea cheilor pentru criptare algoritmul care generează sub-cheile selectează inițial 56 de biți (din cei 64) din cheia principală printr-o permutare, ceilalți 8 biți sunt ignorați sau folosiți ca biți de paritate. Cei 56 de biți sunt apoi împărțiți în două blocuri de 28 de biți; fiecare jumătate fiind tratată ulterior separat. În runde succesive, ambele jumătăți sunt rotite la stânga cu unul sau doi biți (specificați pentru fiecare rundă), și apoi sunt selectați cei 48 de biți ai sub-cheii printr-o altă permutare, 24 de biți din jumătatea stângă, și 24 din cea dreaptă. Prin rotație se înțelege că un set de biți diferit este folosit în fiecare sub-cheie; fiecare bit este folosit în circa 14 din cele 16 chei

Diversificarea cheilor pentru decriptare este similară, trebuie doar să se genereze sub-cheile în ordine inversă. Așadar, rotațiile sunt la dreapta, și nu la stânga.

Securitate și criptanaliză

Deși despre criptanaliza lui DES s-a publicat mai multă informație decât despre cea a oricărui alt cifru bloc, atacul cel mai practic rămâne cel prin forță brută. Diferite proprietăți criptanalitice minore sunt cunoscute, iar trei atacuri teoretice sunt posibile. Acestea au complexitatea mai mică decât cea a atacului prin forță brută, dar numărul de texte necesare este nerealist și de aceea nu sunt fezabile.

În ciuda tuturor criticilor și slăbiciunilor lui DES, nu există exemple de persoane care să fi suferit pierderi bănești din cauza limitărilor de securitate ale lui DES.

Proprietăți criptanalitice minore

DES prezintă proprietatea complementarității, adică:

unde este complementatul pe biți al lui , EK denotă criptarea cu cheia K, P și C reprezintă textul clar respectiv criptat. Proprietatea complementarității înseamnă că munca unui atac prin forță brută se înjumătățește (un bit) sub prezumția unui text ales.

DES are, de asemenea, patru chei slabe. Criptarea (E) și decriptarea (D) cu o cheie slabă au același efect:

sau echivalent EK = DK

Există de asemenea și șase perechi de chei semi-slabe. Criptarea cu o pereche de chei semi-slabe, K1, operează identic cu decriptarea cu o alta, K2:

sau echivalent

Este ușor de evitat cheile slabe și semi-slabe într-o implementare, fie prin testare explicită, fie prin alegerea aleatorie a cheilor; șansele de alegere a unei chei slabe sau semi-slabe sunt neglijabile. Aceste chei nu sunt în realitate mai slabe decât alte chei în nici un fel, pentru că nu avantajează nici un atac.

S-a dovedit că DES nu este un grup, sau mai precis, mulțimea (EK) (a tuturor cheilor posibile K) față de compunerea funcțiilor nu este grup, și nici măcar „aproape” de a fi grup (Campbell și Wiener, 1992). Aceasta a fost o întrebare pentru un timp, și dacă așa era cazul, ar fi fost posibil să se spargă DES, iar modalitățile de criptare multiple, precum Triplu DES nu ar fi mărit securitatea.

Este cunoscut faptul că securitatea criptografică maximă a lui DES este limitată la 64 de biți, chiar și când se aleg independent sub-cheile în locul derivării lor din cheia principală, care ar permite altfel o securitate de 768 de biți.

Algoritmul AES (Advanced Encryption Standard)

În ianuarie 1997, NIST a organizat un concurs de criptografie deschis cercetătorilor din întreaga lume, având ca subiect crearea unui nou standard de criptare. Regulile concursului dispuneau ca: algoritmul să fie un cifru bloc simetric, trebuia să fie public, trebuia să prevadă chei de 128, 192 și 256 biți, să se poată implementa atât hardware cât și software și să fie un standard public sau oferit cu licență nediscriminatorie.

În august 1998 NIST a selectat cinci finaliști pe criterii de securitate, eficiență, flexibilitate și cerințe de memorie iar în octombrie 2000 NIST a stabilit câștigătorul. Acesta este algoritmul Rijndael, dezvoltat de doi tineri cercetători belgieni, Joan Daemen și Vincent Rijmen și care devine standard guvernamental al SUA. Se speră ca Rjindael să devină standardul criptografic dominant în lume pentru următorii 10 ani.

Rijndael permite lungimi de chei și mărimi de blocuri de la 128 de biți la 256 de biți, în pași de câte 32 de biți. Lungimea cheii și lungimea blocului pot fi alese în mod independent, dar în practică se vor folosi două variante: bloc de 128 biți cu cheie de 128 biți și bloc de 128 biți cu cheie de 256 biți. O cheie de 128 biți permite un spațiu al cheilor de 2128 chei. La 26 mai 2002 AES a fost anunțat standard de criptare în SUA. La moment este cel mai răspândit algoritm de criptare simetrică.

Rijndael se bazează pe teoria câmpurilor Galois, în sensul că anumite operațiuni sunt definite la nivel de octet iar octeții reprezintă elemente în câmpul finit GF(28). Cum toate reprezentările câmpului finit GF(28) sunt izomorfe, se poate alege reprezentarea clasică polinomială, cu impact pozitiv asupra complexității implementării. Octetul b, format din biții b7, b6, b5, b4, b3, b2, b1 și b0, este considerat ca fiind un polinom de gradul 7 cu coeficienți 0 sau 1:

b7x7+b6x6+b5x5+b4x4+b3x3+b2x2+b1x+b0

Operațiunea de adunare este definită ca suma a două polinoame în care coeficienții se adună modulo 2 și care corespunde operării XOR a celor doi octeți corespondenți. Sunt îndeplinite axiomele grupului abelian: operația este internă, asociativă, comutativă, există element neutru și element invers.

Operațiunea de înmulțire corespunde produsului a două polinoame modulo, un polinom ireductibil de grad 8 și care pentru AES este:

m(x)=x8+x4+x3+x+1

Înmulțirea este internă (rezultatul este un polinom de grad strict mai mic ca 8), asociativă și există element neutru. Elementul invers se determină cu algoritmul lui Euclid, iar distributivitatea celor doua operații se verifică.

Concluzia este că mulțimea celor 256 de valori posibile ale unui octet, împreună cu cele două operațiuni definite mai sus formează un corp algebric finit, respectiv GF(28).

În proiectarea AES s-a ținut cont de 3 criterii: rezistența împotriva tuturor atacurilor cunoscute; viteza și compactitatea codului pe un mare număr de platforme și simplicitatea proiectării.

Ca și DES, AES folosește substituție și permutări, ca și runde multiple. Numărul de runde depinde de mărimea cheii și de mărimea blocului, fiind 10 în cazul 128/128 și mărindu-se până la 14 pentru cazul 256/128. Spre deosebire de DES, toate operațiile sunt la nivel de octet, pentru a permite implementări eficiente hardware și software.

La momentul implementării AES nu se cunoșteau metode de atac asupra lui. Însă căutarea permanentă a dat roade pentru criptanaliști. Atacul cel mai realizabil împotriva AES este îndreptat împotriva variantelor Rijndael cu număr redus de iterații. AES are 10 iterații la o cheie de 128 de biți, 12 la cheie de 192 de biți și 14 la cheie de 256 de biți. La nivelul anului 2008, cele mai cunoscute atacuri erau accesibile la 7, 8 respectiv 9 iterații pentru cele trei lungimi ale cheii. Au fost găsite metode eficiente pentru a ataca AES cu mai puține runde (10) și o cheie de 256 biți aplicând metoda cheilor înrudite. De aceea pentru siguranță e recomandată trecerea de la 10 la 16 runde pentru AES-128, de la 12 la 20 pentru AES 192 și de la 14 la 28 pentru AES-256.

Algoritmul

În propunerea avansată NIST, cei doi autori ai algoritmului Rijndael au definit un algoritm de criptare pe blocuri în care lungimea blocului și a cheii puteau fi independente, de 128 de biți, 192 de biți, sau 256 de biți. Specificația AES standardizează toate cele trei dimensiuni posibile pentru lungimea cheii, dar restricționează lungimea blocului la 128 de biți. Astfel, intrarea și ieșirea algoritmilor de criptare și decriptare este un bloc de 128 de biți. În publicația FIPS numărul 197, operațiile AES sunt definite sub formă de operații pe matrice, unde atât cheia, cât și blocul sunt scrise sub formă de matrice. La începutul rulării cifrului, blocul este copiat într-un tablou denumit stare (în engleză state), primii patru octeți pe prima coloană, apoi următorii patru pe a doua coloană, și tot așa până la completarea tabloului. Algoritmul modifică la fiecare pas acest tablou de numere denumit state, și îl furnizează apoi ca ieșire.

Pasul Sub-Bytes

Pasul Sub-Bytes (figura 5) este un cifru cu substituție, fără punct fix, denumit Rijndael S-box, care rulează independent pe fiecare octet din state. Această transformare este neliniară și face astfel întreg cifrul să fie neliniar, ceea ce îi conferă un nivel sporit de securitate.

Fiecare octet este calculat astfel:

unde bi este bitul corespunzător poziției i din cadrul octetului, iar ci este bitul corespunzător poziției i din octetul ce reprezintă valoarea hexazecimală 63, sau, pe biți, 01100011. Maparea octeților se poate reține într-un tabel, explicitat în FIPS PUB 197, în care este specificat rezultatul operației de mai sus efectuată pe fiecare din cele 256 de valori posibile reprezentabile pe un octet.

Pasul Sub-Bytes

Pasul Shift Rows

Pasul Shift-Rows, figura 6, operează la nivel de rând al matricii de stare state. Pasul constă în simpla deplasare ciclică a octeților de pe rânduri, astfel: primul rând nu se deplasează; al doilea rând se deplasează la stânga cu o poziție; al treilea rând se deplasează la stânga cu două poziții; al patrulea se deplasează la stânga cu trei poziții. Rezultatul acestui pas este că fiecare coloană din tabloul state rezultat este compusă din octeți de pe fiecare coloană a stării inițiale. Acesta este un aspect important, din cauză că tabloul state este populat inițial pe coloane, iar pașii ulteriori, inclusiv AddRoundKey în care este folosită cheia de criptare, operațiile se efectuează pe coloane.

Pasul Shift-Rows

Pasul Mix-Columns

În acest pas, fiecare coloană a tabloului de stare este considerată un polinom de gradul 4 peste corpul Galois GF(28) (figura 7). Fiecare coloană, tratată ca polinom, este înmulțită, modulo x4 + 1 cu polinomul a(x) = 3×3 + x2 + x + 2. Operația se poate scrie ca înmulțire de matrice astfel:

unde si’ sunt elementele de pe un vector coloană rezultate în urma înmulțirii, iar si sunt elementele de pe același vector înaintea aplicării pasului.

Pasul Mix-Columns

Rezultatul are proprietatea că fiecare element al său depinde de toate elementele de pe coloana stării dinaintea efectuării pasului. Combinat cu pasul Shift-Rows, acest pas asigură că după câteva iterații, fiecare octet din stare depinde de fiecare octet din starea inițială (tabloul populat cu octeții mesajului în clar). Acești doi pași, împreună, sunt principala sursă de difuzie în algoritmul Rijndael. Coeficienții polinomului a(x) sunt toți 1, 2 și 3, din motive de performanță, criptarea fiind mai eficientă atunci când coeficienții sunt mici. La decriptare, coeficienții pasului corespunzător acestuia sunt mai mari și deci decriptarea este mai lentă decât criptarea. S-a luat această decizie pentru că unele din aplicațiile în care urma să fie folosit algoritmul implică numai criptări, și nu și decriptări, deci criptarea este folosită mai des.

Pasul AddRoundKey și planificarea cheilor

Pasul AddRoundKey (figura 8) este pasul în care este implicată cheia. El constă într-o simplă operație de „sau” exclusiv pe biți între stare și cheia de rundă (o cheie care este unică pentru fiecare iterație, cheie calculată pe baza cheii secrete). Operația de combinare cu cheia secretă este una extrem de simplă și rapidă, dar algoritmul rămâne complex, din cauza complexității calculului cheilor de rundă (Key Schedule), precum și a celorlalți pași ai algoritmului.

Pasul AddRoundKey

Algoritmul Blowfish

Din categoria de algoritmi simetrici de tip bloc se mai poate menționa algoritmul Blowfish care este proiectat pentru a fi implementat pe procesoare puternice, și este optimizat pentru aplicații în care cheia nu trebuie să se schimbe des, cum ar fi legături de comunicație sau un criptor automat pentru fișiere. Este semnificativ mai rapid decât DES când este implementat pe procesoare de 32 de biți dotate cu memorie cache mare, cum ar fi noile procesoare INTEL. Blowfish nu este potrivit pentru comutarea de pachete, cu schimbări dese de cheie, ca funcție hash one-way sau în aplicații smart card, unde memoria este insuficientă.

Acest algoritm a fost conceput de Bruce Schneier. Este un algoritm de criptare bazat pe o structură Feistel. A fost aleasă o funcție f mai simplă decât în cazul algoritmului DES obținându-se de aceea și securitate, dar și o eficiență și o viteză de calcul sporite. Cea mai importantă particularitate a algoritmului Blowfish este metoda de generare a cheilor. Cheile iterațiilor precum și întregul conținut al cutiilor de tip S sunt create prin iterații multiple ale sistemului de criptare de bloc. În acest mod crește securitatea sistemului de criptare împotriva atacurilor bazate pe metode exhaustive de căutare a cheilor, chiar și pentru chei scurte.

Descriere

Spre deosebire de DES, Blowfish aplică funcția f jumătății din stânga a blocului de text clar rezultatul fiind însumat modulo 2 cu jumătatea din dreapta a blocului. Se fac 16 iterații. La începutul fiecărei iterații se calculează suma modulo 2 dintre blocul din stânga și sub-cheia corespunzătoare acelei iterații. Apoi se aplică funcția f blocului din stânga și rezultatul se adună modulo 2 cu blocul din dreapta. La sfârșitul ultimei iterații se substituie una celeilalte cele două jumătăți de bloc obținute. În fiecare iterație se folosește o singură sub-cheie, funcția f nu folosește nici o sub-cheie, dar folosește cutii S care depind de sub-cheie. După ultima iterație se calculează suma modulo 2 a jumătății din dreapta a blocului de biți cu sub-cheia 17 și se calculează suma modulo 2 a jumătății din stânga a blocului de biți cu sub-cheia 18.

Funcția F

Blowfish folosește 4 cutii de tip S. Fiecare are 256 de intrări la care se aduc blocuri de câte 32 de biți. Calculul funcției f se bazează pe următoarea succesiune de operații: Se folosește primul octet al blocului de 32 de biți de intrare pentru a găsi o intrare în prima cutie de tip S, cel de-al doilea octet pentru a găsi o intrare în cea de-a doua cutie de tip S, ș.a.m.d. Valoarea funcției f este ((S1(B1) +S2(B2))+S3(B3))+S4(B4) unde se folosește adunarea modulo 232, notată cu +.

Decriptarea

Decriptarea se realizează la fel ca și criptarea, folosind cele 18 sub-chei de iterație în ordine inversă. Într-adevăr există două operații de adunare modulo 2 după ultima utilizare a funcției f și numai una singură înaintea primei utilizări a funcției f.

Generarea sub-cheilor

Acest proces convertește o cheie inițială de cel mult 448 de biți în câteva zone de sub-chei care ocupă un spațiu de 4168 de octeți. Blowfish folosește un număr mare de sub-chei. Acestea trebuiesc generate înaintea oricărei operații de criptare sau de decriptare. În continuare voi prezenta zonele de sub-chei.

Zona 1. Este numită și zona P și constă din 18 sub-chei de 32 de biți: P1, P2,…, P18.

Zona 2. Este zona cutiilor de tip S. Există 4 cutii de tip S de 32 de biți, fiecare cu 256 de intrări:

S1,0 S1,1… … S1,255;

S2,0 S2,1… … S2,255;

S3,0 S3,1… … S3,255;

S4,0 S4,1… … S4,255.

Generarea sub-cheilor se face folosind algoritmul Blowfish. Etapele de generare a cheilor sunt:

Inițializarea zonelor 1 și apoi 2, în ordine, cu un șir fixat. Acest șir constă din partea fracționară a numărului pi exprimată în formă hexazecimală. De exemplu:

P1 = 0x243f6a88

P2 = 0x85a308d3

P3 = 0x13198a2e

P4 = 0x03707344

Se calculează suma modulo 2 între P1 și primii 32 de biți ai cheii inițiale, se calculează suma modulo 2 între P2 și următorii 32 de biți ai cheii inițiale, ș.a.m.d. (e posibil să se depășească P18). Acest ciclu se repetă până când întreaga zonă 1 a fost însumată modulo 2 cu biți ai cheii inițiale a algoritmului Blowfish. Pentru orice cheie inițială scurtă există cel puțin o cheie echivalentă mai lungă; de exemplu dacă A este o cheie de 64 de biți atunci AA, AAA, etc. sunt chei echivalente.

Se criptează texte în clar formate numai din biți nuli cu algoritmul Blowfish folosind sub-cheile descrise în pașii (1) și (2).

Se înlocuiesc cheile P1 și P2 cu rezultatul obținut la pasul (3).

Se criptează rezultatul obținut la pasul (3) folosind algoritmul Blowfish cu cheile obținute la pasul (4).

Se înlocuiesc cheile P3 și P4 cu rezultatul obținut la pasul (5).

Se continuă procesul, înlocuind toate elementele zonelor 1 și 2 cu rezultatele aplicării algoritmului Blowfish.

Pentru generarea tuturor sub-cheilor de care este nevoie sunt necesare 521 de rulări ale algoritmului Blowfish.

O particularitate a algoritmului Blowfish este utilizarea cutiilor de tip S dependente de chei. Această construcție are câteva avantaje:

Se realizează o bună protecție împotriva atacurilor prin criptanaliză liniară sau diferențială;

Implementarea cutiilor variabile este mai simplă decât cea a unor cutii fixe;

Reducerea necesității stocării unor structuri de date mari.

Există câteva modalități de simplificare a algoritmului Blowfish care pot conduce la reducerea volumului de memorie ocupat precum și la creșterea vitezei:

Utilizarea unui număr mai mic de cutii de tip S și de dimensiuni mai mici;

Reducerea numărului de iterații (de exemplu de la 16 la 8). Numărul de iterații necesar pentru asigurarea unui anumit nivel de securitate depinde de lungimea sub-cheilor folosite;

Utilizarea unei metode neiterative de calcul al sub-cheilor. În acest mod s-ar putea obține chei independente una de cealaltă.

Criptografia cuantică

Criptarea cuantică este o abordare bazată pe fizica cuantică pentru a realiza comunicații securizate. Spre deosebire metodele de criptografie tradiționale, care folosesc diverse metode matematice pentru a împiedica interceptarea și decodificarea mesajului, criptarea cuantică se bazează pe legile fizicii în ceea ce privește transmiterea informației. Interceptarea poate fi văzută ca o măsurare a unui obiect fizic – în acest caz purtătorul de informație. Folosind fenomene cuantice cum ar fi suprapunerea cuantică sau legătura cuantică, se poate proiecta și implementa un sistem de comunicație care să evite întotdeauna interceptarea. Aceasta este din cauză că măsurările efectuate asupra unui purtător cuantic îi modifică proprietățile și astfel rămân „urme” ale interceptării.

Dispozitivele care folosesc criptarea cuantică utilizează fotoni individuali, și se bazează fie pe principiul lui Heisenberg sau pe principiul legăturii cuantice.

Actul de a măsura este o parte integrantă a mecanicii cuantice, nu doar un proces extern și pasiv, ca în cazul fizicii clasice. Este deci posibil să se codeze informația în anumite proprietăți ale fotonului, astfel încât orice efort de a le monitoriza le modifică într-un mod ușor de detectat. Acest efect apare din cauză că în teoria cuantică, anumite perechi de proprietăți fizice sunt complementare, în sensul că măsurarea uneia dintre aceste proprietăți o modifică pe cealaltă. Acest fenomen este cunoscut ca principiul incertitudinii al lui Heisenberg. Cele două proprietăți complementare care sunt des folosite în criptarea cuantică sunt cele două tipuri de polarizare a fotonului, de exemplu liniară (vertical/orizontal) sau diagonală (la 45 si 135 de grade).

Legătura este o stare a două sau mai multe particule cuantice (de exemplu fotoni) în care multe din proprietățile lor fizice sunt puternic corelate. Particulele legate nu pot fi descrise specificând stările individuale ale acestora, deoarece acestea pot să conțină informație într-un mod care nu poate fi accesat prin experimente făcute asupra vreuneia dintre ele în particular. Acest fenomen se produce indiferent de distanța dintre particule.

Pe baza acestor două proprietăți neintuitive ale mecanicii cuantice (incertitudinea și legătura), au fost inventate două tipuri de protocoale de criptare cuantică. Primul folosește polarizarea fotonilor pentru a codifica biții de informație și se bazează pe natura aleatoare a fizicii cuantice pentru a evita interceptarea mesajului. Al doilea folosește fotoni legați pentru a codifica biți, și se bazează pe faptul că informația apare doar după măsurători făcute de părțile ce comunică.

Protocoalele de criptare cuantică au proprietăți la care nu se poate ajunge prin metodele tradiționale de criptare. Cei doi agenți care comunică pot genera și interschimba chei aleatorii care sunt foarte similare – în condiții ideale ar trebui sa fie identice, dar în realitate va exista o anumită rată a erorii. De asemenea aceste protocoale permit estimarea nivelului de interceptare a comunicației, și se poate deduce cât din cheile lor aleatorii este cunoscut de o terța parte. Aceste rezultate sunt interesante, dar nu suficiente pentru a rezolva problema interschimbării cheilor. Interceptarea chiar a unei mici părți din chei poate avea efecte semnificative: o terță parte poate sa citească o bucată (poate critică) a mesajului secret. Din cauza faptului că erorile și zgomotul de fond nu pot fi evitate în totalitate, nu se poate garanta ca nici o cheie nu a fost interceptată – erorile de comunicație și încercările de interceptare nu pot fi deosebite, așa că se poate presupune că în cazul cel mai defavorabil, toate erorile se datorează interceptării mesajului.

Criptarea cuantică a fost propusă pentru prima oară de Stephen Wiesener, pe atunci la Universitatea „Columbia” din New York, când, la începutul anilor 70, a introdus un concept de codare cu conjugată cuantică. Lucrarea sa intitulată „Conjugate Coding” a fost respinsă de Comisia de Teoria Informației a IEEE, dar a fost in cele din urmă publicată în 1983 în SIGACT News. El arată cum se poate reține sau transmite două mesaje codate în două „observabile conjugate”, cum ar fi polarizarea liniară sau circulară a luminii, astfel încât oricare dintre ele, dar nu amândouă, pot fi recepționate și decodificate. El și-a ilustrat ideea cu un proiect de bancnote care nu pot fi falsificate. Un deceniu mai târziu, pe baza acestei lucrări, Charles H. Bennett, de la Centrul de Cercetare „Thomas J. Watson” al IBM, și Gilles Brassard, de la Universitatea din Montréal, au propus o metodă de comunicație securizată bazată pe observabilele conjugate ale lui Wiesener. În 1990, în mod independent și fără să fie la curent cu lucrările precedente, Artur Ekert, pe atunci doctorand la Universitatea din Oxford, a folosit o abordare diferită bazată pe proprietatea de „Entanglement cuantic”.

Stările legate sunt rareori destul de stabile pentru a putea fi folosite în aplicații comerciale, care sunt astfel limitate (cel puțin deocamdată) la aproximativ 100 de kilometri. Se studiază totuși folosirea sateliților pentru transmiterea stărilor legate, pentru că în afara atmosferei perturbațiile ar fi mult reduse.

Dispozitive comerciale bazate pe criptarea cuantică au apărut, și pot înlocui cu succes protocoale cum ar fi schimbul de chei Diffie-Hellman în aplicațiile care au nevoie de maximum de securitate posibil. Dezavantaje ale acestei tehnologii, care fac ca ea să nu fie larg răspândită, sunt costul echipamentelor și al liniei de fibră optică dedicată, ca și necesitatea de a avea încredere în firma producătoare, ceea ce nu este cazul dacă se folosesc tehnologiile curente, bazate pe software liber și calculatoare standard, ca și lipsa vreunei vulnerabilități majore a acestor tehnologii. Existența unor mijloace de stocare a datelor de mare capacitate și relativ ieftine face ca transmiterea unor cantități mari de date sensibile să poată fi făcută prin curier; aceste date pot să reprezinte chei folosite în cadrul unui algoritm cum ar fi AES.

Bruce Schneier, expert în domeniul criptologiei, este de părerea că implementarea rețelelor înzestrate cu tehnologia criptării cuantice este „practic lipsită de sens” fiind aplicată în practică. În octombrie 2008 în Austria a fost pusă în funcție prima rețea cuantică, despre care Schneier a scris în revista Wireed că implementarea acestor tipuri de rețea nu va schimba nimic din punct de vedere al securității informaționale. „Ideea de bază, în teorie, este la fel de tare pe cât de lipsită de sens în viața reală”. „Chiar și cifrarea cuantică nu va rezolva toate problemele criptografice. Cheia se transmite cu fotoni, însă în baza procesului de cifrare rămâne același algoritm matematic”. Schneier a remarcat că veriga cea mai slabă a oricărei rețele sunt punctele finale ale rețelei și nu momentul de transmitere a datelor. Criptarea cuantică nu propune soluții pentru izvorul tuturor problemelor. „Asta e același lucru ca și cum te-ai apăra de atacatori cu un stâlp bătut în pământ. E inutil de discutat despre înălțimea lui necesară – 15 sau 30 de metri, deoarece atacatorul pur și simplu îl vor ocoli”.

Principiul incertitudinii al lui Heisenberg

Principiul incertitudinii al lui Heisenberg spune că pentru oricare două observabile cuantice A și B avem:

unde iar și .

Astfel și sunt deviațiile standard ce măsoară incertitudinea observabilelor A și B. Pentru observabilele A și B cu reducerea incertitudinii a observabilei A obligă creșterea incertitudinii a observabilei B și vice-versa.

Folosind fenomene cuantice, se poate proiecta și implementa un sistem de comunicație care să evite întotdeauna interceptarea.

Având în vedere cele menționate, rezultă că, folosind principiile fizicii cuantice, putem realiza un sistem prin care se poate face un schimb de chei în deplină siguranță.

Distribuirea cuantică a cheilor

Criptosistem cuantic de comunicații

Distribuirea cheilor cuantice folosește avantajul unor fenomene ce au loc la nivel subatomic, astfel încât, orice încercare de interceptare a biților, nu numai că eșuează dar și alertează receptorul că s-a produs o interceptare. În esență, fiecare bit din cheia transmisă, corespunde unei stări particulare a particulei purtătoare, cum ar fi fotonii polarizați. Emițătorul cheii trebuie să stabilească o secvență de polarizare a fotonilor, care vor fi transmiși printr-o fibră optică. Pentru a obține cheia, care este formată dintr-o secvență de fotoni polarizați – qbits, Receptorul trebuie să facă o serie de măsurători cu ajutorul unor filtre cu care se poate determina polarizarea fotonilor.

Un foton poate fi polarizat liniar (0o, 90o), diagonal (45o, 135o) sau circular (stânga – spinL, dreapta – spinR) (tabelul 2). Polarizarea liniară-diagonală, liniară-circulară sau diagonală-circulară sunt cunoscute ca fiind variabile legate iar legile fizicii cuantice spun că este imposibil de măsurat simultan valorile oricărei perechi de variabile legate; deci, dacă inamicul încearcă să „măsoare” un foton polarizat orizontal, folosind o metoda de „măsurare” a fotonilor polarizați diagonal, acel foton își schimbă polarizarea din orizontală în diagonală.

Polarizarea fotonilor – qbits

Atacul și interceptarea

În criptarea cuantică, atacul tradițional cu „intermediar” este imposibil din cauza principiului incertitudinii. Orice interceptare a fotonilor duce inevitabil la modificarea proprietăților lor, dacă se folosește un detector incorect. De asemenea nu se pot re-emite particulele, deoarece acest fapt ar duce la erori inacceptabile.

În cazul folosirii metodei de criptare cu particule legate, acestea sunt aproape imposibil de interceptat, deoarece crearea a trei particule legate ar slăbi „legătura” atât de mult încât acest lucru s-ar detecta imediat. Atacul cu „intermediar” nu poate fi folosit pentru ca ar fi nevoie de măsurarea unei particule legate, ceea ce ar modifica-o și pe cealaltă, urmată de re-emiterea ambelor particule (fotoni), lucru imposibil după legile mecanicii cuantice. Din cauza faptului că o linie de fibră optică e necesară între cei doi agenți care folosesc criptarea cuantică, întreruperea comunicației poate fi făcută foarte ușor tăind linia sau, mai discret, încercând interceptarea informației transmise. Dacă se poate interveni în echipamentul folosit, s-ar putea modifica astfel încât cheile generate să nu mai fie sigure, ajungându-se astfel la un atac cu generator de numere aleatoare. Atacul cu „intermediar” (în engleză man-in-the-middle attack) poate fi totuși folosit în cazul criptării cuantice, dacă intermediarul se „prezintă” fiecărei părți autorizate ca fiind cealaltă; după aceea, tot ce trebuie să facă este să respecte protocolul de transmisie a datelor, făcând schimb de chei cu cei doi agenți autorizați. Acest fel de atac poate fi evitat prin folosirea unei metode de autentificare prin care cele doua parți se pot recunoaște.

Quantum Key Distribution (QKD) – protocolul BB84

Protocolul BB84, este primul protocol cuantic, numit astfel după cei care l-au descoperit în 1984, Charles Bennett și Gilles Brassard, prin care două entități, emițătorul și receptorul stabilesc în secret o cheie unică, comună, folosind fotoni polarizați (qbits).

Pașii protocolului BB84:

Emițătorul generează o secvență aleatorie, „s”, de biți;

Emițătorul alege baza, „b”, de polarizare ce o va aplica fiecărui foton care va reprezenta biții din secvența „s” (liniar „L” sau diagonal „D”);

Folosind un echipament special (un laser atenuat și un set de dispozitive de polarizare) emițătorul creează o secvență „p” de fotoni polarizați (qbits) a căror direcție de polarizare reprezintă biții din „s”;

Emițătorul transmite qbiții din „p” către receptor prin fibra optică;

Receptorul, pentru fiecare qbit recepționat alege în mod aleatoriu o bază de polarizare (liniar „L” sau diagonal „D”). Secvența aleasă va fi notată cu „b’”;

Receptorul măsoară fiecare qbit recepționat respectând baza de polarizare, „b’” aleasă de acesta, rezultând astfel o secvență de biți „s’”;

Printr-un canal public emițătorul îi transmite receptorului baza de polarizare aleasă pentru fiecare bit. De asemenea receptorul transmite emițătorului unde a făcut aceeași alegere a bazei de polarizare. Biții pentru care emițătorul și receptorul nu au avut aceeași baza de polarizare aleasă vor fi eliminați din secvența „s” respectiv „s’”.

Detectarea inamicului:

Pentru bitul cu numărul n, bitului s[n], din secvența s, îi va corespunde o bază de polarizare b[n], iar bitului s’[n] îi va corespunde o bază b’[n]. Dacă b’[n]=b[n] atunci s’[n]=s[n].

În cazul în care un inamic încearcă să citească fotonul purtător al lui s[n], atunci chiar dacă cele două baze alese de emițător și receptor sunt identice (b[n]=b’[n]) vom avea s’[n] diferit de s[n] (s[n]≠s’[n]). Acest fapt va permite receptorului si emițătorului detecția unei tentative de citire a informației vehiculate și astfel să poată acționa în consecință.

Secret key reconciliation

Algoritmul BB84 este incomplet deoarece, chiar dacă inamicul există sau nu, vor exista erori în secvența de biți a receptorului. Ultimul pas al algoritmului BB84 constă într-o comparație a celor două secvențe de biți, deținute de emițător și receptor după codificare și decodificare. Această comparație cuprinde două etape : secret key reconciliation și privacy amplification.

În această etapă se corectează următoarele tipuri de erori:

erorile datorate alegerii diferite a bazelor;

erorile datorate intervenției inamicului;

erorile datorate zgomotului.

În etapa secret key reconciliation se execută o căutare binară, interactivă a erorilor. Emițătorul și receptorul împart secvența de biți rămasă în blocuri de biți și vor compara paritatea fiecărui bloc. În cazul în care paritatea unui bloc de biți diferă, ei vor împărți blocul respectiv în blocuri mai mici și vor compara paritatea lor. Acest proces va fi repetat până când bitul care diferă va fi descoperit și eliminat. Canalul folosit pentru această etapă va fi un canal public nesecurizat.

Privacy amplification

Datorită faptului că în etapa anterioară, comunicația s-a realizat pe un canal public nesecurizat, nu se exclude posibilitatea ca inamicul să dețină informații despre cheia secretă. Pentru a stabili o cheie perfect sigură, este necesară executarea unei alte etape de către emițător și receptor: privacy amplification.

Această etapă se realizează printr-o permutare a biților din cheia secretă și eliminarea unui subset de biți. Aceasta va fi realizată de ambele părți ale comunicației, emițător și receptor. După definitivarea acestei etape avem certitudinea că emițătorul și receptorul, sunt în posesia unei chei secrete ce nu este cunoscută de către inamic.

– Trecere în revistă a tipurilor de rețele informaționale, niveluri de performanțe

Noțiuni introductive IPSec

IPSec – „Internet Protocol Security” reprezintă o suită de protocoale de securitate care autentifică și criptează pachetele de date trimise pe suportul unei rețele bazate pe stiva de protocoale TCP/IP. IPSec include protocoale ce asigură autentificarea reciprocă a entităților ce doresc să comunice și protocoale pentru negocierea cheilor criptografice în vederea criptării traficului de date. IPSec poate fi folosit pentru a asigura protecția traficului între entități („host-to-host”), între două rețele („gateway-to-gateway”) sau între o entitate și o rețea („host-to-gateway”). Suita de protocoale IPSec asigură următoarele servicii de securitate: autentificarea entităților de nivel rețea (nivel 2 TCP/IP sau nivel 3 ISO/OSI), autentificarea originii datelor, integritatea datelor, confidențialitatea datelor prin criptare și protecție la atacuri de tip „replay”.

Spre deosebire de alte sisteme de securitate, cum ar fi TLS – „Transport Layer Security” sau SSH – „Secure Shell” care operează la nivelurile transport respectiv aplicație ale stivei TCP/IP, IPSec operează la nivel rețea (i.e. Internet) al acestei stive (vezi figura 4).

Arhitectura de securitate a IPSec

IPSec este o suită de protocoale „open standard” care folosește următoarele protocoale pentru implementarea funcționalităților diferite:

Autentificarea antetelor (numită în continuare „Authentication Headers” sau AH) – asigură integritatea fără conexiune directă a datelor („connectionless data integrity”), autentificarea originii datelor pentru datagramele (pachetele) IP și asigură protecție anti atacuri de tip „replay”.

„Encapsulating Security Payload” (numită în continuare ESP) – asigură confidențialitate, autentificarea originii datelor, integritatea datelor în lipsa conexiunii („connectionless integrity”), asigură un serviciu anti-replay și asigură un serviciu limitat de confidențialitate a fluxului traficului de date.

Asocierile de securitate (numit în continuare „Security Associations” sau SA) – asigură pachetul de algoritmi și datele necesare care asigură parametri necesari operațiilor făcute de AH și/sau ESP.

„Internet Security Association and Key Management Protocol” (numit în continuare ISAKMP) – asigură cadrul necesar autentificării și schimbului de chei. Cheile pot fi configurate manual ca „pre-shared keys” sau obținute folosondu-se certificate digitale emise de o autoritate de certificare („Internet Key Exchange” – IKE sau IKEv2, „Kerberized Internet Negotiation of Keys” – KINK sau IPSECKEY).

Authentication Header

Authentication Header este unul din protocoalele suitei IPSec și este definit în documentul RFC4302 ce are ca emitent pe IETF („Internet Engineering Task Force”). Acesta garantează integritatea fără conexiune și autentificarea originii datelor pentru pachetele IP. În plus, opțional, acesta poate să asigure protecție împotriva atacurilor de tip „replay” prin utilizarea unei tehnici numite „fereastră glisantă” („sliding window”) și aruncarea pachetelor vechi.

În IPv4 (IP versiunea 4) AH previne atacurile de tip „option-insertion” (inserare de opțiuni în câmpurile headerului). În IPv6, AH previne în plus și atacurile de tip inserare de header. De asemenea în IPv4, AH protejează tot „payload-ul” și câmpurile headerului IP cu excepția câmpurilor susceptibile modificărilor legitime pe parcursul tranzitului pachetului de la sursă către destinație (acestea sunt „DSCP/ToS, ECN, Fragment Offset, TTL, Flag și Header Checksum”).

Headerul AH este reprezentat în tabelul următor:

Headerul AH conform RFC 4302

„Next Header”

Acest câmp indică care este tipul următorului protocol (protocol de nivel superior în stiva) ce a fost protejat. Acesta reprezintă un număr pe 8 biți standardizat în lista oficială a numerelor de protocol (standardizarea fiind făcută de către IANA „Internet Assigned Numbers Authority”). De exemplu valoarea 4 reprezintă IPv4, valoarea 41 reprezintă IPv6 iar valoarea 6 reprezintă TCP.

„Payload len”

Acest câmp de 8 biți specifică lungimea AH considerată în „cuvinte” de 32 de biți (unități de câte 4 biți), minus „2”. De exemplu, dacă un algoritm de integritate are o valoare de 96 de biți, valoarea câmpului „length” va fi de „4” (și anume 3 cuvinte de câte 32 biți ale câmpurilor fixe, plus 3 cuvinte de câte 32 biți ale câmpului ICV, minus 2). Pentru IPv6, lungimea totală a headerului trebuie să fie multiplu de unități de 8 (octet).

„Reserved” – câmp rezervat

Acest câmp de 16 biți este rezervat pentru o folosire viitoare. În mod normal are setată valoarea „zero” de către sursă și trebuie să fie ignorat de către destinație. Cu toate acestea el este luat în calcul atunci când se calculează valoarea câmpului ICV.

„Security Parameters Index” – SPI

SPI este o valoare arbitrară de 32 biți, care este folosită de entitatea de destinație să identifice (posibil împreună cu valoarea „protocol type” a IPSec) cărei SA – „Security Association” aparține respectivul pachet. Pentru sesiunile „unicast” valoarea SPI este asignată la destinație, iar dacă „protocol type” este folosit sau nu este la latitudinea destinației. În cazul unui scenariu cu sesiuni „multicast”, identificarea este mai complicată, acestea necesitând un algoritm suplimentar pentru identificarea corectă a SA-urilor asociate. Acest algoritm se regăsește în multe scenarii cu arhitecturi „multicast” cum ar fi cel definit în RFC3740.

„Sequence Number” – SN

Această valoare pe 32 de biți este incrementată cu „1” la fiecare pachet trimis. Este folosită pentru evitarea atacurilor de tip „replay”. Când detecția atacurilor „replay” este activată, aceste „sequence numbers” nu sunt refolosite, deoarece atunci când valoarea SN depășește o anumită limită prestabilită, o altă SA va fi negociată și se va alege un alt SN diferit.

„Integrity Check Value” – ICV

Acest câmp are lungime variabilă și poate conține informație de „balast” („padding”) pentru a face ca AH să aibă o lungime multiplu de 32 biți pentru IPv4 sau 64 biți pentru IPv6.

„Encapsulating Security Payload” – ESP

ESP este, ca și AH, unul din membrii suitei de protocoale ale IPSec și este definit in documentul RFC4303 ai IETF. Acesta asigură autentificarea originii, integritate și confidențialitate pachetelor protejate cu IPSec. ESP poate fi configurat să asigure numai confidențialitate sau numai autentificarea originii datelor, dar aceste moduri de lucru nu sunt încurajate deoarece reprezintă riscuri de securitate. În modul de lucru „transport” ESP nu asigură serviciile integritate și autentificare pentru întreg pachetul IP. În schimb în modul „tunnel” întreg pachetul IP original este încapsulat și i se adaugă un nou header IP, astfel tot pachetul original este protejat. ESP lucrează la nivel rețea (TCP/IP) și este definit de IANA ca protocolul cu numărul 50.

În tabelul următor se regăsește structura pachetului ESP conform RFC4303.

Pachetul ESP conform RFC4303

„Security Parameters Index” – SPI

Acest câmp are același scop ca și câmpul SPI al AH, este o valoare arbitrară de 32 biți, care este folosită de entitatea de destinație să identifice (posibil împreună cu valoarea „protocol type” a IPSec) cărei SA – „Security Association” aparține respectivul pachet. Pentru sesiunile „unicast” valoarea SPI este asignată la destinație, iar dacă „protocol type” este folosit sau nu este la latitudinea destinației. În cazul unui scenariu cu sesiuni „multicast”, identificarea este mai complicată, acestea necesitând un algoritm suplimentar pentru identificarea corectă a SA-urilor asociate. Acest algoritm se regăsește în multe scenarii cu arhitecturi „multicast” cum ar fi cel definit în RFC3740.

„Sequence Number” – SN

Are același scop ca și în cazul AH, și anume este un câmp de lungime 32 de biți care este incrementat cu „1” la fiecare pachet trimis. Este folosită pentru evitarea atacurilor de tip „replay”. Pentru fiecare SA – „Security Association” este ținută o altă numărătoare.

„Payload data”

Acest câmp de lungime variabilă conține datele utile, provenite de la un nivel superior (TCP/IP), și care trebuie protejate. De asemenea acest câmp poate conține și informații folosite pentru protecția conținutului (e.g. vectori de inițializare pentru un algoritm criptografic). Tipul de conținut care este protejat în acest câmp este indicat în câmpul „Next Header”, care va fi detaliat în cele ce urmează.

„Padding” – încărcătură de balast

Acest câmp poate varia de la 0 până la 255 de octeți. Este folosit pentru a aduce dimensiunea datelor utile (conținute în câmpul „payload”), la o dimensiune necesitată de algoritmul de criptare utilizat a.î. să aceasta să fie multiplu de dimensiunea blocurilor („block size”) algoritmului (e.g. multiplu de 128 de biți în cazul AES). De asemenea acest câmp este necesar alinierii câmpului următor.

„Pad Length” – lungimea „padding-ului”

Acest câmp indică lungimea câmpului „padding”. Este exprimat în octeți.

„Next Header”

Ca și în cazul AH acest câmp indică care este tipul următorului protocol (protocol de nivel superior în stiva) ce a fost protejat în cadrul pachetului ESP. Acesta reprezintă un număr pe 8 biți standardizat în lista oficială a numerelor de protocol (standardizarea fiind făcută de către IANA „Internet Assigned Numbers Authority”). De exemplu valoarea 4 reprezintă IPv4, valoarea 41 reprezintă IPv6 iar valoarea 6 reprezintă TCP.

„Integrity Check Value” – ICV

În mod identic cu AH, acest câmp are lungime variabilă și poate conține informație de „balast” („padding”) pentru a face ca pachetul ESP să aibă o lungime multiplu de 32 biți pentru IPv4 sau de 64 biți pentru IPv6.

„Security Association” – SA

Arhitectura de securitate IP – IPSec – definește conceptul de „Security Association”, numite în continuare SA, ca bază pentru implementarea funcțiilor de securitate în IP. Un SA este un pachet de algoritmi și parametri (e.g. chei) care sunt folosiți pentru a cripta și autentifica un flux de date într-o anumită direcție. Astfel pentru a securiza un comunicarea în ambele sensuri, ambele fluxuri vor fi securizate de câte un SA, în alte cuvinte o pereche de SA va securiza „conversația” între doua entități.

SA sunt stabilite folosind ISAKMP – „Internet Security Association Key Management Protocol”. Acesta din urmă este implementat manual de către administratorul echipamentului prin chei „pre-share” sau automat prin protocoalele IKE sau IKEv2, KINK sau IPSECKEY.

Pentru a decide ce protecție va fi aplicată unui pachet ce urmează a fi trimis, IPSec folosește valoarea câmpului SPI, și eventual valoarea „protocol type” și adresa IP de destinație, pentru a identifica în mod unic cărui SA aparține respectivul pachet. În mod similar un pachet recepționat este analizat și atribuit SA-ului corespunzător pentru a fi procesat.

În cazul unei arhitecturi multicast, un SA este construit pentru respectivul grup și replicat către toți participanții legitimi la acel grup. De asemenea pot exista mai multe SA pentru un singur grup, folosind SPI-uri diferite astfel permițând existența mai multor niveluri de securitate în cadrul aceluiași grup. Standardul nu descrie cum sunt alese și replicate SA-urile diferite pentru același grup, ci este presupus că o terță parte, recunoscută, va lua această decizie.

Moduri de operare

IPSec implementează două opțiuni în ceea ce privește modul de operare, modul transport destinat în general lucrului direct între entități („host-to-host”) și modul tunel, folosit în general între rețele.

Modul Transport

În acest mod de operare, numai încărcătura („payload-ul”) pachetului este criptat și autentificat. Câmpurile IP sursă și IP destinație ale pachetului original sunt menținute intact din moment ce headerul (antetul) IP original nu este modificat sau criptat. De menționat este faptul că în cazul folosirii AH, pe traseul urmat de pachet nu trebuie să existe elemente de translatare a adreselor IP (NAT – „Network Address Translation”), deoarece acestea modifică unul sau ambele câmpuri de adresare IP, modificând astfel valoarea „hash” calculată inițial de AH, ducând la invalidarea pachetului la destinație.

Modul Tunel

În modul tunel, întregul pachet IP original este criptat și autentificat. În urma acestui mod de operare se creează un nou pachet cu un nou header (antet) IP. Modul tunel este folosit deseori pentru a crea așa numitele „Virtual Private Networks” – VPN, și este implementat în general pentru comunicația între rețele („network-to-network”), comunicația între o entitate și o rețea („host-to-network”), dar și pentru comunicația între entități („host-to-host”) ca în cazul modului transport.

În cazul modului tunel elementele de translatare a adreselor pot funcționa în rețea, între nodurile care au stabilit sesiunea IPSec.

Algoritmii de criptare definiți

ESP și AH sunt mecanismele de aplicare a protecției criptografice datelor ce sunt transmise pe suportul unui IPSec SA.

Pentru a asigura interoperabilitatea între soluții și echipamente produse de vendori diferiți, este necesară definirea prin standard (RFC7321) a unor algoritmi ca strict necesari pentru a fi implementați. Acest lucru va asigura că va exista cel puțin un algoritm comun, pe care toți vendorii îl vor implementa.

Standardul definește algoritmii care sunt strict necesar a fi implementați în acest moment, cei care sunt recomandați a fi implementați, deoarece în viitor e posibil să devină strict necesari, dar și algoritmii depășiți, care nu este recomandat a fi implementați.

Dată fiind natura criptografiei și faptul că noi algoritmi continuă să apară iar cei existenți sunt în permanență atacați, RFC7321 va fi în mod continuu modificat și actualizat. Un algoritm care astăzi este considerat sigur, mâne poate fi depășit. Astfel lista algoritmilor impuși a fi implementați trebuie să fie conservativă și să țină cont de posibilitatea ca aceștia să fie compromiși dar și de eficiență și performanță deoarece mulți utilizatori ai IPSec vor implementa securitatea în medii în care performanța este un criteriu avut în vedere.

Lista algoritmilor criptografici se regăsește în tabelul următor:

Lista algoritmilor criptografici pentru IPSec și nivelul de impunere a implementării lor conform RFC7321

Posibila implicare a Agenției Naționale de Securitate a SUA („National Security Agency” – NSA) în compromiterea IPSec

Conform „WIKIPEDIA”, în 2013, ca urmare a dezvăluirilor făcute de Edward Snowden, a reieșit că structura de securitate a Statelor Unite – NSA – ar fi lucrat în vederea introducerii de vulnerabilități în sistemele de criptare comerciale, sistemele IT, rețele și echipamentele terminale de comunicații ale anumitor ținte, ca parte a unui program cu nume de cod „Bullrun”. Au fost aduse acuzații că printre arhitecturile de securitate țintite de NSA s-ar regăsi și IPSec.

Suita IPSec „OpenBSD” a fost prima implementare disponibilă sub o licență permisivă de tip „open-source” și a fost astfel folosită la nivel global. Într-un email primit la data de 11 decembrie 2010 de către șeful echipei de dezvoltare a „OpenBSD”, Theo De Raadt, de la Gregory Perry, este afirmat că Jason Wright și alții, lucrând pentru FBI („Federa Bureau of Investigations”), au inserat o serie de vulnerabilități („backdoor” și „side-channel” pentru transmiterea în clar a cheii) în modul criptat al „OpenBSD”. În emailul de răspuns din 2010, Theo De Raadt nu și-a exprimat nici o poziție oficială cu privire la validitatea celor afirmate, în afară de aprobarea implicită prin prisma trimiterii emailului de răspuns. Răspunsul lui Jason Wright la aceste acuzații a fost (în traducere din limba engleză): „Fiecare legendă urbană este cu atât mai reală atunci când se includ nume reale, date și ore. Emailul lui Gregory Perry eșuează la acest capitol. …Voi menționa încă odată faptul că nu am adăugat vulnerabilități „backdoor” în sistemul de operare OpenBSD sau în structura criptografică a OpenBSD”. Câteva zile mai târziu, Theo de Raadt a comentat spunând (în traducere din limba engleză): „Consider că NETSEC a fost probabil contractat în vederea dezvoltării de vulnerabilități „backdoor” așa cum a fost stipulat. …Dacă acelea [vulnerabilitățile] au fost dezvoltate, nu cred că și-au găsit calea în arhitectura noastră”. Aceste declarații au fost publicate înainte de dezvăluirile lui Snowden.

O explicație alternativă înaintată de autorii atacului „Logjam” sugerează că NSA ar fi compromis IPSec prin subminarea algoritmului „Diffie-Hellman” folosit în fază de schimb de chei. În lucrare, aceștia susțin că NSA a construit sistem computațional care să precalculeze subgrupuri multiplicative pentru funcții specifice și generatoare, cum ar fi cel de-al doilea grup „Oakley” definit în RFC 2409. Începând cu mai 2015, 90% din VPN-urile IPSec implementau al doilea grup Oakley ca parte a IKE („Internet Key Exchange”). Dacă o organizație ar fi reușit să precalculeze acest grup, ar fi putut determina cheile aflate în proces de schimb între părți și ar fi reușit decriptarea traficului fără a necesita software de tip „backdoor”.

O altă explicație alternativă ce a fost înaintată, a fost aceea că grupul de atacatori numit „Equation Group” a folosit vulnerabilități de tip „zoro-day” împotriva echipamentelor VPN ale unor vendori. Aceste atacuri ce au fost validate de „Kaspersky Lab” ca având legături cu grupul „Equation Group” și certificate de respectivii vendori ca fiind vulnerabilități reale, unele fiind chiar vulnerabilități de tip „zero-day” la momentul dezvăluirii lor. De asemenea este presupus că echipamentele firewall „PIX” și „ASA” produse de CISCO au vulnerabilități care au fost folosite de NSA pentru a înregistra traficul de date tranzitat.

De asemenea a fost afirmat că VPN-urile IPSec care folosesc modul „agresiv” de stabilire a SA, trimit hash-ul cheii „pre-share” în clar. Acest lucru făcând foarte ușoară aflarea cheii prin utilizarea metodelor de „spargere” a hash-urile (metode dicționar, rainbow tables, etc).

Analiză practică a nivelului de performanță a IPSec – teste laborator

Scenariul de testare

Pentru implementarea scenariului de testare s-au folosit următoarele materiale (figurile 1 și 2):

două routere CISCO seria 2900 model CISCO2911/K9 cu versiune de IOS (Internetwork Operating System) C2900-UNIVERSALK9-M, Versiune 15.3(3)M3;

un laptop cu sistem de operare Windows XP și cu software de captură de pachete Wireshark;

un PC (Personal Computer) cu sistem de operare Windows XP și cu software de captură de pachete Wireshark. De asemenea pe acest PC rulau un server TFTP (Trivial File Transfer Protocol) și un server FTP (File Transfer Protocol);

un telefon analogic;

o conexiune analogică la sistemul RTP/RMNC (Rețeaua de Transmisiuni Permanente/Rețeaua Militară Națională de Comunicații);

cablurile pentru interconectări (UTP, Seriale SmartSerial la DB25, cabluri analogice la 2 fire – 2F);

cablu consola CISCO pentru configurarea inițială a routerelor.

Interconectările s-au realizat conform figurii 1 iar setup-ul de ansamblu al laboratorului este prezentat în figura următoare.

schema conexiunilor

Cele două routere CISCO din figura precedentă, denumite în continuare 2911-L (Local) și 2911-R (Remote), au fost echipate, suplimentar față de dotarea standard, cu câte un modul CISCO HWIC-4T (High-speed WAN Interface Card cu 4 interfețe smarT serial) și cu câte un modul analogic pentru conectarea telefonului respectiv a liniei centralei. Modulele analogice au fost, un modul CISCO VIC2-2FXO (Voice Interface Card cu 2 porturi Foreign eXchange Office) pe routerul 2911-L și un modul CISCO VIC3-4FXS (Voice Interface Card cu 4 porturi Foreign eXchange Station) pe routerul 2911-R.

Pentru a executa testele, laptopul și PC-ul au fost conectate fiecare la cate un router, laptopul la routerul 2911-R și PC-ul la 2911-L, pe interfața GigabitEthernet0/1 a fiecărui router.

Routerele au fost conectate între ele folosind prima interfață serială, de tip smart-serial, din fiecare modul HWIC-4T (interfața Serial0/3/0 a fiecărui router). Această conexiune între routere reprezintă simularea conexiunii WAN (Wide Area Network). S-a ales acest tip de legătură deoarece legăturile seriale permit configurarea manuală a vitezei (lățimii de bandă a interfeței). În acest fel a fost posibilă testarea IPSec în condiții de lățime de bandă redusă. Astfel de condiții se regăsesc frecvent în aplicațiile militare.

Pentru a aplica suita IPSec s-a configurat o tunelare GRE (Generic Routing Encapsulation) între cele două routere. Peste această tunelare s-a aplicat un profil IPSec configurat pe fiecare router. Planul de adresare și conexiunile au fost definite conform figurii 1 și tabelului următor.

Planul de adresare/numerotare

Pentru a avea garanția că tot traficul va fi routat pe interfața Tunnel2911 a fiecărui router (interfață căreia i-a fost aplicat profilul IPSec), s-a configurat un protocol de rutare astfel încât să poată fi direcționat tot traficul prin aceste interfețe. Protocolul folosit este EIGRP – Enhanced Interior Gateway Routing Protocol, căruia i-a fost activată instanța 1 pe interfețele Tunnel2911. Celelalte interfețe fiind configurate în modul pasiv pe ambele routere.

Laptopul și PC-ul au funcționat ca platforme pentru transmisia/recepția de date și capturarea pachetelor în vederea analizei. Pentru a captura pachetele s-a folosit un software dedicat numit Wireshark. Acesta capturează pachetele care pleacă sau vin din/în placa de rețea a calculatorului și interpretează datele obținute afișându-le grupat pe niveluri din stiva TCP/IP. Această facilitate permite analiza ulterioară a pachetelor și compararea celor transmise cu cele recepționate, putându-se astfel trage concluzii despre calitatea transmisiei.

Figura 6 prezintă o imagine cu organizarea laboratorului și cu panourile frontale ale routerelor CISCO 2911.

Teste executate

În vederea testării această lucrare a urmărit compararea timpilor de întârziere, „end-to-end”, introduși de aplicarea criptării pe legătura dintre cele două routere cu timpii de întârziere în varianta fără criptare.

Testarea s-a făcut urmărind mai multe scenarii. S-a testat IPSec configurat cu mai mulți algoritmi de criptare (DES, 3DES, AES128, AES192 și AES256). De asemenea s-a testat funcționarea IPSec în mai multe variante ale vitezei legăturii WAN (legătura serială dintre cele două routere) pentru fiecare dintre cei cinci algoritmi de criptare.

La final s-au comparat datele rezultate în urma aplicării criptării și a diferitelor viteze de transfer cu datele constatate fără aplicarea criptării pentru fiecare viteză în parte.

Organizarea laboratorului

Testul PING

S-a folosit comanda PING pentru a compara timpii de întârziere între Laptop și PC. Această comandă folosește ICMP – Internet Control Message Protocol pentru a verifica legătura dintre două echipamente configurate cu adrese IP și afișează timpul scurs între momentul trimiterii pachetului de cerere și momentul primirii răspunsului de la corespondent. Toate pachetele ICMP transmise și recepționate au fost capturate cu Wireshark și salvate local pe laptop și respectiv PC.

S-au executat câte 4 seturi de teste pentru fiecare algoritm de criptare în parte cât și pentru varianta fără criptare (în clar). Primele două seturi au presupus setarea extremelor de viteză pe legătura WAN, acestea fiind 504000 bps, pentru setul 1 și 1200 bps, pentru setul 2. 504000 bps fiind viteza maximă acceptată de router pe o interfață serială, iar 1200 bps fiind viteza minimă. Limitarea vitezei maxime la 504000 bps fiind dată de cablul serial disponibil la momentul testării și nu de capacitatea interfeței seriale din modului HWIC-4T (acesta poate suporta viteze de până la 8 Mbps pe o astfel de interfață).

Seturile 3 și 4 au presupus setarea unor viteza intermediare pe legătura WAN. Aceste viteze au fost 9600 bps, pentru setul 3 și 56000 bps pentru setul 4.

Pentru fiecare set în parte s-au setat câte 3 mărimi ale pachetelor ICMP, 32B, 65500B și 1360B. Selectarea acestor mărimi a avut ca scop testarea variației întârzierii în funcție de cantitatea de date transmisă și testarea funcționării în condițiile apariției fragmentării pachetelor IP. 32B reprezintă o valoare foarte mică (aproape minimă) a lungimii payload-ului ICMP, pe când 65500 reprezintă valoarea maximă. Valoarea de 1360B a fost aleasă deoarece reprezintă valoarea maximă a payload-ului ICMP pentru care routerul nu a fost forțat să fragmenteze pachetul.

Testul voce

Pentru configurarea apelurilor vocale, testele s-au executat folosindu-se două codec-uri vocale, G.711 și G.729r8. S-au ales aceste 2 codec-uri deoarece acestea se situează la extreme opuse din punct de vedere al necesarului de bandă. G.711 necesită 87,2 Kbps, iar G.729r8 necesită numai 31,2 Kbps, dar folosește o cantitate mai mare de resurse de procesare de semnal.

Testul a presupus executarea a câte unui apel telefonic de pe telefonul analogic (figura 5) către un abonat din RTP/RMNC (1009/123), pentru fiecare din seturile executate în cadrul testului PING și pentru ambele codec-uri vocale testate.

Testarea a urmărit două aspecte, primul fiind verificarea stabilirii legăturii cu rezultat de tipul realizat/nerealizat și al doilea constând în stabilirea subiectivă a calității audiției.

Testul TFTP

În cadrul acestui test s-a determinat timpul de transmisie a două cantități de date cu lungimile de 1048576 biți (1Mb) și, respectiv, 6696960 biți (~6,3 Mb). Determinarea s-a făcut pentru fiecare din cei 5 algoritmi de criptare menționați anterior cât și pentru varianta fără criptare. Toate testele TFTP s-au realizat la o viteză a serialei WAN de 504000 bps.

Concluziile s-au tras comparând rezultatele obținute având criptarea aplicată pe interfața tunel cu rezultatele obținute fără criptare.

Testul FTP

Testul FTP s-a executat deoarece clientul TFTP nu a oferit rezultate foarte precise cu privire la timpii de transfer. Astfel pentru acest test s-a copiat de pe serverul FTP un fișier cu lungimea de 1048576 biți (1Mb), depunându-l pe cardul de memorie flash al routerului, folosind clientul FTP de pe routerul 2911-R (figura 5). Ca și în cazul testului TFTP, și de această dată s-au testat fiecare din cei 5 algoritmi de criptare menționați anterior cât și varianta fără criptare. Testele s-au realizat la viteza de 504000 bps a serialei WAN.

De asemenea concluziile s-au tras comparând rezultatele obținute având criptarea aplicată pe interfața tunel cu rezultatele obținute fără criptare.

Rezultate obținute și concluziile trase

Analiza și interpretarea rezultatelor obținute s-a făcut prin compararea timpilor de întârziere obținuți în varianta aplicării criptării cu cei obținuți fără criptare.

Astfel se poate observa că toți algoritmii introduc o întârziere suplimentară medie de 2 milisecunde (de la 3 la 5 ms) pentru un ping cu lungimea implicită de 32 biți și cu setarea vitezei pe legătura WAN de 504000 bps (~500kbps – viteza maximă permisă de hardware-ul avut la dispoziție la momentul testării). Chiar pentru AES 128 se poate observa că valoarea maximă a întârzierii atinge 6 ms, ceea ce adaugă o întârziere suplimentară de 3 ms. Dar întârzierea suplimentară medie a acestuia se menține tot la 2 ms. Astfel pentru acest tip de ping cu această viteză WAN, singura diferență o reprezintă aplicarea algoritmului, fără a fi evidențiate diferențe între tipul de algoritmi.

Diferențele între algoritmi apar odată cu modificarea vitezei pe interfața serială WAN. Pentru o viteză de 1200 bps și lungimea unui pachet tot de 32B, am constatat că timpul de întârziere variază de la 1498 ms pentru varianta fără criptare, la 2686,8 ms pentru AES 256. Întârzierea medie a celorlalți algoritmi situându-se pentru acest test la valorile de 2336 ms pentru DES, 1958 ms pentru 3DES, nerealizat pentru AES 128 și 2303 ms pentru AES 192. De remarcat este faptul că algoritmul DES a înregistrat o valoare a întârzierii medii mai mare ca a celorlalți algoritmi cu excepția AES 256, care după cum era de așteptat a înregistrat cea mai mare întârziere. De asemenea de remarcat este și faptul că introducerea criptării cu AES 128 și configurarea pe seriala WAN a vitezei de 1200 bps a făcut ca legătura să nu se poată stabiliza.

Pentru punerea în evidență a diferențelor dintre algoritmii de criptare reieșite în urma testului PING rezultatele au fost sintetizate în tablele următoare.

Întârzierea medie pentru ping cu lungimea de 32 B

Întârzierea medie pentru ping cu lungimea de 65500 B

Întârzierea medie pentru ping cu lungimea de 1360 B

În urma testului PING s-a putut constata că algoritmul DES, deși este cel care asigură cea mai mică protecție, produce în multe situații cea mai mare întârziere sau o întârziere comparabilă cu AES cu cheie de 256 biți.

Pentru ping- urile cu lungime de 65500 B, în tabelul 17, se poate observa că viteza configurată pe seriala WAN are o importanță deosebită în trimiterea cu succes a datelor. În același tabel se observă că vitezele de 1200 și 9600 bps nu asigură lățimea de bandă necesară transferului de pachete cu lungimi foarte mari care presupun fragmentare multiplă. De precizat este faptul că pentru această lungime a pachetului, nici viteza de 56000 bps nu este suficientă pentru transmitere. Se poate observa în tabelul 17 că pentru fiecare din algoritmi, inclusiv pentru varianta fără criptare, viteza nu este suficientă pentru a transmite suficiente pachete cât să se poată extrage date elocvente. Numărul de răspunsuri („reply”) fiind de unul, maxim două.

Din punctul de vedere al stabilirii sesiunilor IPSec, din testul PING, a reieșit că acestea se pot stabili indiferent de viteza configurată, cu excepția AES 128 care pentru 1200 bps nu a stabilit sesiuni stabile. În acest caz protocolul de routare EIGRP nu a avut posibilitatea să stabilească adiacențe permanente.

Având în vedere că testul PING nu a oferit date suficiente pentru a stabili foarte clar diferențele de întârziere introduse de algoritmii de criptare analizați, a fost necesară continuare testelor și pentru un transfer continuu de date. Pentru aceasta s-a folosit un server TFTP instalat pe PC și un client TFTP de pe laptop. Transferul s-a realizat între PC și laptop, jurnalizându-se timpii de transfer.

Inițial s-a folosit pentru transfer un fișier cu lungimea de 1048576 biți (1 Mb). Astfel datele colectate au fost afișate în tabelul 13.

După cum se poate observa în tabelul 13, în urma acestui test nu s-a constatat nici o diferență între timpii de transfer realizați având aplicați algoritmi de criptare. Singura diferență fiind între varianta fără criptare și varianta cu aplicare a criptării. Această diferență fiind considerabilă, aproximativ patru secunde.

Având în vedere că nu s-a constatat nici o diferență între timpii de transfer aferenți diverșilor algoritmi, s-a presupus că, clientul TFTP folosit nu are precizia necesară pentru a evidenția aceste diferențe în condițiile transferului unui fișier atât de mic. Astfel s-a reluat testul folosindu-se un fișier cu o dimensiune mai mare (6696960 biți / ~6,38 Mb). Rezultatele acestui nou test au fost consemnate în tabelul 14.

Se poate observa că presupunerea făcută în urma primului test TFTP a fost corectă. În urmă măririi dimensiunii fișierului de transferat, diferențele între algoritmi au început să fie vizibile. În tabelul 14 se poate observa clar diferența între varianta în clar și aplicarea criptării, dar se pot observa micile diferențe între algoritmii DES, 3DES și AES. Astfel s-a constatat o diferență de o secundă între DES și 3DES și de 3 secunde între 3DES și AES (indiferent de lungimea cheii AES).

Ultimul test TFTP a oferit o diferențiere mai precisă între algoritmii analizați dar tot nu s-au putut observa diferențe între cei trei algoritmi AES studiați. Pentru aceștia timpul de transfer fiind identic, și anume 166 secunde.

În vederea evidențierii diferențelor dintre cei trei algoritmi AES s-a continuat având la baza presupunerea făcută după primul test TFTP. Astfel una din soluții ar fi fost folosirea unui fișier de dimensiune mult mai mare sau folosirea unui alt client care să ofere informații mult mai detaliate despre timpul de transfer. În acest scop a fost aleasă soluția a doua cu folosirea unui server și client FTP.

Pentru următorul test s-a folosit un server FTP instalat pe PC și clientul FTP instalat pe routerul „remote”. Acest client oferă informații mult mai precise cu privire la timpul de transfer. Având în vedere folosirea clientului instalat pe un router CISCO, a fost necesară folosirea pentru stocare a cardului de memorie „flash” al routerului. Din cauza spațiului limitat de stocare de pe acest card a fost necesară folosirea unui fișier cu dimensiune mică, astfel folosindu-se fișierul de 1 Mb. Rezultatele acestui test au fost consemnate în tabelul 15.

După cum se poate observa în tabelul 15, acest al treilea test de transfer date a furnizat cele mai precise informații și a reușit diferențierea tuturor celor cinci algoritmi din punctul de vedere al timpului de transfer. Se poate observa că pe măsură ce complexitatea algoritmului crește este influențat timpul de transfer al datelor. Cu cât algoritmul de criptare este mai complex, cu atât timpul de transfer este mai mare. Deși routerele model 2911 sunt echipate cu modul hardware de criptare, complexitatea algoritmului de criptare ales, are o influență sesizabilă asupra timpului de transfer al datelor, dar aceasta nu atinge valori care să influențeze negativ performanțele per ansamblu ale echipamentului.

În cadrul acestei lucrări s-a executat și un test de voce, rezultatele acestui fiind consemnate în tabelele 11 și 12. Prin întârziere, în contextul testului de voce executat în cadrul acestei lucrări, se înțelege diferența percepută de aparatul auditiv uman, între momentul transmiterii unei comunicări în microreceptorul aparatului telefonic transmițător și momentul recepționării acestuia în aparatul telefonic receptor. Aprecierea acestei întârzieri fiind una subiectivă și nu una cantitativă precisă.

După cum se poate observa, pentru voce, introducerea criptării nu influențează în mod categoric pachetele de voce. Factorul cel mai important în stabilirea legăturii voce este lățimea de bandă. Cele două codec-uri vocale testate au cerințe de lățime de bandă diferite. Pentru codec-ul G.711 necesarul de bandă, conform producătorului, este de aproximativ 87,2 kbps iar pentru G.729r8 necesarul fiind de 31,2 kbps. Astfel s-a putut constata că pentru G.711 numai testele cu lățimea de bandă configurată la 504000 bps s-a putut stabili legătura de voce. Pentru G.729r8 legătura s-a stabilit și pentru viteza de 56000 bps, dar a prezentat o întârziere sesizabilă, dar care nu a deranjat. De asemenea, în cazul algoritmilor AES 128 și AES 256 s-au constatat și scurte întreruperi, dar și acestea nu au făcut imposibilă comunicarea.

Se observă, de asemenea, că în cazul încercării stabilirii unei legături voce în același timp cu transferul unei cantități însemnate de date (în cazul de față transmiterea unui ping cu lungime de 65500 biți), legătura de voce s-a stabilit numai pentru viteza de 504000 bps configurată pe seriala WAN, indiferent de codec-ul vocal configurat. În acest caz s-a putut constata o întârziere sesizabilă de aparatul auditiv uman, dar care nu a împiedicat comunicarea. Valoarea acestei întârzieri nu a fost influențată de codec-ul ales, întârzierea fiind sesizată identic pentru ambele codec-uri.

– Cloud computing – Securitatea în cloud

Noțiuni introductive despre serviciile „cloud”

Modul normal de operare al oricărei organizații produce constant o mare cantitate de informații. Aceste informații pot avea diverse forme, scrise pe hârtie sau în format electronic. În cele ce urmează se vor discuta probleme legate de datele în format electronic și unele din metodele folosite pentru stocarea lor.

În funcție de tipul activității desfășurare de organizații, cantitatea de date generate poate varia de la mică și foarte mică până la mare și foarte mare. Pentru organizațiile mici stocarea datelor poate să nu reprezinte o problemă. De obicei aceste organizații își stochează datele local fără a avea prea multe probleme legate de acest aspect. Însă pentru organizațiile mari, care pot avea mai multe sucursale distribuite pe o suprafață geografică extinsă, poate fi nevoie de un sistem centralizat de stocare a informațiilor. Pentru a implementa un astfel de sistem centralizat de stocare este nevoie de investiții majore în echipament specializat și personal tehnic pentru mentenanță. Dar nu toate organizațiile sunt dispuse să consume o cantitate așa de mare de resurse pentru a-și implementa propriul sistem de stocare centralizat. Iar pentru aceste organizații există o soluție mult mai avantajoasă de stocare, și anume stocarea „în nor” sau „cloud storage”.

Cu soluțiile de stocare „în nor” a datelor clienții, practic, își externalizează serviciul de stocare a datelor. Aceștia apelează la o terță parte care le poate oferi serviciul de stocare de date. Cu alte cuvinte clienții apelează la un furnizor de servicii de stocare „în nor” sau „Cloud Storage Service Provider” (CSSP). În continuare se vor aborda problemele legate de securitatea stocării datelor „în nor” și se vor analiza unele soluții menite să rezolve o parte din aceste probleme.

Stocarea „în nor” (Cloud Storage)

„Cloud storage” este în general un serviciu furnizat de o terță parte care oferă clienților posibilitatea de a-și stoca datele în spații virtualizate de stocare. Astfel clienții nu sunt nevoiți să investească o cantitate mare de resurse pentru stocarea datelor. Tot ceea ce un client are de făcut este să cumpere sau să închirieze capacitatea de stocare, pe care acesta o necesită, de la un CSSP. În general un CSSP are multe centre mari de date care sunt folosite pentru a furniza clienților spațiul de stocare pe care aceștia îl necesită. Acest spațiu este folosit ulterior de client pentru a-și stoca informațiile. Astfel oferind clientului posibilitatea de a-și accesa datele de oriunde dorește, atâta timp cât acesta deține cel puțin o legătură de date cu rețeaua furnizorului.

Odată ce datele sunt stocate în rețeaua furnizorului clientul o poate accesa folosind mai multe metode posibile. Astfel de metode pot fi „cloud storage gateways”, „application programming interfaces (API)”, interfețele „web” de utilizator, etc..

Din punct de vedere istoric stocarea „în nor” nu este o idee nouă. Conform site-ului „Wikipedia” aceasta a fost inventată de Joseph Carl Robnett Licklider în anii 1960. Dar nu a fost pusă în practică decât la sfârșitul anilor ’90 deoarece până atunci serviciile internet nu erau de nădejde și nu asigurau lățimea de bandă necesară încărcării și descărcării cantităților mari de date. Din această cauză stocarea „în nor” este considerată o tehnologie relativ nouă disponibilă maselor.

Nu există încă o definiție oficială a serviciilor de stocare „în nor”, dar anumiți autori au formulat definiții pentru „cloud storage”. De exemplu în [1] „cloud storage” este definit ca „un model de serviciu în care datele sunt menținute, manageriate și salvate de la distanță și sunt puse la dispoziția clienților prin intermediul unei rețele (de obicei internetul)”. Există desigur și alte definiții cum ar fi „Cloud storage este un sistem de stocare accesat prin intermediul unei rețele (internă sau externă) cu ajutorul serviciilor web de tip API”, așa cum este descris în [2]. Stocarea „în nor” este de asemenea definită ca un sistem de resurse distribuite, ce se comportă unitar. Din această cauză este posibil ca datele clienților să nu fie stocate într-un singur loc, ci distribuite în rețeaua CSSP.

Sistemul de stocare „în nor” prezintă anumite avantaje față de metodele convenționale de stocare. Principalul avantaj constă în faptul că un client plătește doar pentru ceea ce folosește și are nevoie, dar există și alte avantaje ale sistemelor de stocare „în nor”. Datorită faptului că un astfel de sistem este distribuit prezintă avantajul unei toleranțe mari la erori, proprietate comună tuturor sistemelor cu resurse distribuite. Faptul că acest serviciu este oferit de o terță parte prezintă avantajul ca un client nu trebuie să își facă griji în privința asigurări mentenanței, a redundanței sau a îmbunătățirii sistemului de stocare. Toate aceste probleme vor fi rezolvate de către CSSP. Astfel clientul se poate concentra asupra activității proprii, cum de altfel și CSSP se va preocupa asupra activității proprii și anume asigurarea un serviciu de stocare de calitate clienților. De asemenea faptul că principalul domeniu de activitate al unui CSSP este stocarea, poate asigura clienții că acesta va oferi un serviciu de o calitate mult mai bună în comparație cu situația în care clientul și-ar fi asigurat singur un astfel de serviciu.

Din păcate, ca orice sistem și stocarea „în nor” prezintă anumite dezavantaje. Deși externalizarea activității de stocare a informațiilor prezintă anumite avantaje, prezentate anterior, faptul că un client este nevoit să-și încredințeze informația unei terțe părți reprezintă în sine un mare dezavantaj, și anume neîncrederea în acea terță parte. Clientul nu poate ști cu siguranță ce face furnizorul serviciului de stocare cu datele încărcate de acesta în „nor”. Astfel se pune problema securității informațiilor încărcate „în nor”.

Problemele legate de stocarea datelor „în nor”

Riscurile adoptării soluțiilor de stocare a datelor „în nor” nu sunt neglijabile. Pe lângă problemele tehnice de securitate, ce vor fi discutate ulterior, mai există și alte tipuri de probleme ce privesc astfel de sisteme de stocare. În majoritatea cazurilor serviciul de stocare este asigurat de către un CSSP clientului în baza unui contract. Dar, este bine cunoscut faptul că un contract nu poate garanta clientului ca serviciul va fi asigurat 100%. De exemplu, dacă furnizorul serviciului intră în faliment, este cumpărat de altcineva sau în cazul unui eșec catastrofal, clientul poate pierde parțial sau total informațiile stocate. În astfel de situații datele clientului pot fi ușor subiectul atacurilor, datorită instabilității temporare a furnizorului.

De asemenea implementarea unei astfel de soluții de stocare cu resurse distribuite sporește riscul accesului neautorizat la date prin acces fizic direct asupra echipamentelor de stocare. De asemenea, informația fiind mutată și copiată frecvent crește riscul recuperări neautorizate prin refolosirea echipamentelor de stocare sau în momentul când aceste echipamente sunt casate. De asemenea prin externalizarea acestui serviciu clientul nu are control asupra persoanelor care manipulează echipamentele de stocare. Acest lucru reprezintă o problemă destul de serioasă când un CSSP are sute sau mii de clienți, deoarece acest fapt presupune, indirect, angajarea uni echipe mari de tehnicieni pentru a asigura funcționarea echipamentelor, sporind astfel numărul persoanelor cu acces fizic asupra echipamentelor și în mod implicit riscul coruperii, accesului neautorizat sau ștergerii datelor.

Un alt aspect, legat de securitate, ce trebuie luat în calcul, este acela că, pentru a ajunge în rețeaua furnizorului, datele clientului trebuie să tranziteze o serie de legături de date de tip WAN (Wide Area Network), care în general sunt legături în internet. Aceste legături prezintă serioase probleme legate de securitate. Din această cauză trebuie luate măsuri speciale de securitate în această privință.

De asemenea folosirea în comun cu alți clienți a spațiului de stocare sporește riscul accesului neautorizat la date de către un alt client. Acest inconvenient poate surveni ca urmare a defectării unor echipamente, a erorilor sau chiar ca urmare a unei persoane răuvoitoare.

Accesarea neautorizată a datelor poate fi, de obicei, evitată prin folosirea metodelor de criptare a datelor. Criptarea datelor poate fi făcută de client înainte de a încărca datele în rețeaua furnizorului sau poate fi chiar un serviciu oferit de către furnizor. Dar, chiar și folosind metode de criptare datele pot suferi modificări sau chiar ștergeri. Într-un astfel de scenariu clientul poate să nu realizeze la timp că datele sale au fost manipulate sau șterse. Astfel, pentru a face față unui astfel de scenariu, clientul are nevoie de o metodă prin care să poată verifica integritatea datelor sale. De asemenea clientul are nevoie de o metodă prin care să-și poată confirma că CSSP a stocat corect și integral informația sa, dar și că acesta o are stocată corect după mai mult timp. Acestei probleme i se adresează metodele de verificare a integrității datelor („proof of data integrity/storage”).

Soluții pentru problemele legate de stocarea „în nor”: verificarea integrității datelor

Integritatea datelor stocate „în nor” este foarte importantă deoarece poate afecta grav activitatea unei organizații. Anumite studii, cum ar fi cel din [3], au arătat că în cazul unui atac reușit asupra unui server, un „Cal Troian” care poate afecta securitatea software-ului critic, poate fi plasat de către atacator, compromițând astfel integritatea datelor stocate. Consecințele unui astfel de atac pot varia de la simpla distrugere a aspectului unui site web până la înlocuirea datelor cu informații false sau chiar la fraudă informatică.

Problema majoră în cazul unui astfel de atac este reprezentată de faptul că detecția lui poate surveni la mult timp după înfăptuirea atacului în sine. De aceea este deosebit de important ca datele critice să fie verificate în mod constant. O posibilă soluție la această problemă ar fi repornirea periodică a serverelor și rularea lor în modul sigur de operare („safe mode”). După aceasta se va proceda la compararea unor sume criptografice, ale anumitor fișiere critice, cu altele calculate și salvate anterior, asupra acelorași fișiere. Această metodă trebuie făcută local de către administrator, deoarece anumiți viruși ar putea „păcăli” un sistem automat de calcul al sumelor de control și ar putea trimite entității de verificare sume calculate și stocate anterior modificării fișierelor. Această metodă, deși funcțională, nu este totuși practică, deoarece necesită un timp îndelungat și trebuie făcută de către un administrator bine pregătit. De asemenea mentenanța serverelor se face în mod uzual de la distanță deoarece serverele sunt dispuse de obicei în locații diferite sau chiar în regiuni geografice diferite. De altfel nici o aplicație de verificare a integrității, cu funcționare locală, nu este o soluție viabilă deoarece un atacator poate să o modifice astfel încât aceasta să transmită informații false.

Toate aceste riscuri fac necesară dezvoltarea unor mecanisme sigure de verificare a integrității datelor stocate. Câteva dintre aceste mecanisme sunt analizate în cele ce urmează.

Protocoale de verificare a integrității – „Integrity checking protocols”

Protocolul „Challenge-Response” – „Challenge Response Protocol” – CRP

Acesta este un protocol generic simplu care implică o solicitare periodică din partea administratorului, denumită și verificator, către serverul verificat. Cu această cerere, verificatorul cere serverului să calculeze o sumă de control a unui fișier specificat și să returneze rezultatul. Atunci când verificatorul primește suma de control, acesta o compară cu un sumă de control de referință care a fost salvată anterior pe mașina administratorului.

Astfel răspunsul va avea următoarea formă:

(XX)

unde H este o funcție hash „one-way”.

Dar această implementare simplă nu ar funcționa dacă serverul a fost manipulat în așa fel încât să pre-calculeze toate sumele de control înainte de a schimba fișierele. Atunci când verificatorul cere calculul unei sume de control, serverul manipulat ar răspunde cu o sumă de control stocată în loc să o calculeze pe loc. În acest fel, atacatorul poate modifica orice fișier pe care îl dorește fără ca verificatorul să fie alertat. Pentru a depăși această situație, protocolul trebuie modificat astfel încât o sumă de control pre-calculată să nu fie egală cu o sumă de control calculată la cerere.

O modalitate de a avea un astfel de rezultat este de a introduce o așa-numită "provocare – challenge" (denumită C) în cererea pe care verificatorul o trimite serverului distant. În acest fel, suma de control a răspunsului va depinde în mod direct de provocarea trimisă de verificator. Iar atunci când provocarea este cunoscută doar de verificator, serverul nu va putea calcula corect răspunsul corect. Cu alte cuvinte, în loc să se calculeze o sumă de control ca urmare a unei funcții hash „one-way” a fișierului, cu această modificare a protocolului, serverul trebuie să calculeze o sumă de control ca urmare a aceleiași funcții de hash „one-way” pentru fișier și pentru „provocarea” C. Acest rezultat va fi o sumă de control complet diferită.

(XX)

O altă problemă apare cu această modificare a protocolului. Verificatorul nu poate compara răspunsul rezultat din server cu un sumă de control de referință salvată. De asemenea, el nu poate salva un sumă de control de referință pentru a calcula răspunsul cu „provocare”, deoarece serverul nu trebuie să știe provocarea în avans.

O soluție la această problemă ar fi stocarea fișierelor utilizate de acest protocol pe mașina verificatorului pentru a verifica integritatea. Dar, de asemenea, acest lucru nu este foarte practic, deoarece, de obicei, mașina verificatorului este utilizată pentru a menține și verifica mai multe servere și dispozitive, astfel spațiul de stocare necesar mașinii verificatorului ar deveni o problemă serioasă.

O altă soluție la această problemă ar fi aceea de a avea două funcții și , unde este o funcție de tip hash și ar satisface:

(XX)

Aceasta ar fi o soluție funcțională numai dacă cel puțin una dintre funcțiile sau ar fi păstrată în secret. Acest lucru se datorează faptului că atacatorul ar putea avea, dacă ar ști ambele funcții, o sumă de control pre-calculată iar atunci când verificatorul ar trimite cererea de verificare cu provocare, acesta ar răspunde cu rezultatul funcției .

Dar, din păcate, această soluție nu ar funcționa pentru că astfel de perechi de funcții și nu au fost găsite.

O altă soluție a fost propusă de Yves Deswarte, Jean-Jacques Quisquater și Ayda Saïdane în [5]. Acolo se propune ca un număr finit de provocări aleatorii să fie generat off-line pentru fiecare fișier care trebuie verificat. Răspunsurile la aceste provocări sunt, de asemenea, calculate off-line și rezultatele sunt salvate pe mașina verificatorului. De fiecare dată când verificatorul testează integritatea datelor pe server, acesta trimite unul dintre răspunsurile la server și compară rezultatul cu cel corespunzător care a fost salvat anterior.

Această soluție este bazată (și dependentă) pe faptul că serverele sunt repornite frecvent (de exemplu o dată pe zi). În practică, serverele sunt repornite frecvent cu scopul reinițializării software-ului. După repornire, toate programele și fișierele sunt restaurate dintr-o copie securizată, pentru a elimina toate amenințările de securitate pe care un atacator le-ar fi putut instala. Repornirea elimină, de asemenea, posibilitatea ca un atacator să stocheze sumele de control pre-calculate pentru orice provocare , făcând astfel această soluție viabilă. Dar numărul al provocărilor trebuie să respecte următoarea regulă în concordanță cu perioada de repornire:

, (XX)

unde este frecvența cu care protocolul „provocare-răspuns” este apelat pentru un fișier și este frecvența repornirii serverului.

O posibilitate pentru un atacator de a evita această soluție este păstrarea copiilor fișierelor originale pe server, înainte de modificări. Din fericire acest tip de comportament este ușor de detectat de un administrator competent.

Această soluție are totuși un dezavantaj major. Tabelul sumelor de control cu ​​răspunsurile pre-calculate va avea un număr de intrări conținând provocarea și răspunsul. Dar, atunci când există mai multe servere pentru a fi verificate cu mai multe fișiere de verificat pe fiecare, dimensiunea tabelului cu răspunsuri și provocări ar putea reprezenta o problemă. Pentru aceasta există modalități de a reduce dimensiunea unui astfel de tabel. Unul dintre aceste moduri este prezentat în [6] și afirmă că, în loc să se genereze un număr aleatoriu specific pentru fiecare provocare, pentru fiecare fișier va fi generat un singur număr aleator, . Provocările rămase se calculează ca funcții de tip hash „one-way” pornind de la numărul (i.e. ) pentru fiecare index decrementând de la la 1. În acest mod tabelul va conține numai un număr de răspunsuri, ultimul număr aleatoriu și valoarea lui . Verificatorul, atunci când apelează protocolul, va trimite provocările în ordine, de la la . Provocarea actuală este calculată de către verificator într-un mod dinamic.

, (XX)

unde și .

Un exemplu practic al protocolului „răspuns-provocare” („Challenge-responce protocol”) implementat într-un server web distribuit, tolerant la intruziune este dat în [7] și constă într-o serie de verificatori care gestionează și monitorizează o serie de servere web.

Verificatorul apelează periodic protocolul „răspuns-provocare” pentru a verifica serverele sau ceilalți verificatori.

Pe lângă verificarea integrității fișierelor, a directoarelor și a tabelelor de pe serverele de la distanță, CRP (protocolul „răspuns-provocare”) este folosit pentru a verifica statusul de operativitate al serverelor și al altor verificatori și, de asemenea, ca un mecanism de tip "heart-beat" („în viață sau nu”), datorită periodicității protocolului. Un mecanism tip "heart-beat" înseamnă că un verificator ar putea ridica alarma dacă nu primește o provocare din partea altui verificator într-o perioadă de timp mai mare decât perioada de provocare. Statusul de operativitate este verificat dacă un server sau un alt verificator răspunde la cererea de provocare, dacă nu, verificatorul poate da alarma.

Arhitectura unui sistem de servere web rezistente la intruziune

Destinația CRP este de a verifica integritatea unor fișiere de sistem importante care nu sunt modificate în funcționarea normală a serverului, cum ar fi fișiere de sistem (e.g. fișiere de boot) sau fișiere critice de securitate.

Atunci când serverul este reînnoit periodic, există o relație între frecvența solicitărilor de provocare, durata unui schimb CRP, numărul de fișiere care trebuie verificate și numărul de servere.

, (XX)

unde este numărul de fișiere de verificat, frecvența apelării CRP, numărul de provocări per fișier, numărul de servere și timpul între reporniri. De asemenea , unde este durata unui schimb CRP.

Există o valoare minimă corespunzătoare duratei maxime de execuție a CRP (relaționată de dimensiunea celui mai mare fișier de verificat). Durata de execuție depinde în mare măsură de configurația sistemului și de complexitatea funcției hash.

Astfel, dacă durata de execuție, pentru cel mai mare fișier, este 0,5 secunde, atunci .

O soluție bazată pe protocolul Diffie-Hellman

Protocolul prezentat în cele ce urmează este o soluție generică bazată pe protocolul de schimb de chei Diffie-Hellman discutat de asemenea și în [5].

Se va nota:

, aparținând mulțimii numerelor întregi, reprezentând valoarea fișierului care urmează a fi verificat de la distanță;

, un modul RSA („Rivest–Shamir–Adleman”) cu doi sau mai mulți factori primi și lungimea de aproximativ 1024 biți. Această valoare este publică și considerată cunoscută de toata lumea, inclusiv de un posibil atacator care are la dispoziție foarte multă putere de calcul;

este secretul cunoscut numai de verificator. Aceasta este funcția Euler (dacă atunci );

, un element aleatoriu cuprins între 2 și , considerat public.

Protocolul funcționează astfel:

verificatorul pre-calculează și stochează valoarea:

, (XX7)

acest calcul este simplu deoarece este cunoscută valoarea lui (teorema lui Euler permite înlocuirea exponentului cu valoarea scurtă (, care are lungimea de aproximativ 1024 biți), independent de lungimea fișierelor protejate) și de asemenea, dacă este necesar, se poate folosi teorema chinezească a resturilor prin folosirea factorilor primi;

verificatorul alege în mod aleatoriu o valoare din același domeniu cu . Astfel valoarea:

, (XX)

este trimisă serverului ca și cuvânt de „provocare”;

la primirea „provocării” serverul calculează:

, (XX)

și răspunde verificatorului cu valoarea nou calculată ;

între timp verificatorul calculează :

, (XX10)

și compară valoarea primită cu valoarea calculată . Dacă fișierul ce a fost verificat nu a fost modificat între timp atunci conform:

, (XX)

valoarea lui ar trebui să fie egală cu . Ecuația precedentă este corectă deoarece (XX7) și (XX10) sunt adevărate.

Securitatea acestui protocol derivă din securitatea protocolului Diffie-Hellman și nepredictibilitatea „provocării” este garantată de alegerea aleatorie a valorii . Fiind o formă generică, acest protocol poate fi îmbunătățit din multe puncte de vedere.

O nouă schemă de verificare a integrității datelor în nor („cloud”)

Această soluție a fost propusă de Yan Xiangtao și Li Yifa în lucrarea lor „A new data integrity checking scheme for cloud storage” [8].

Arhitectura acestei scheme este prezentată în figura 2. Aceasta are la bază trei elemente: un DO (Data Owner) – posesorul de drept al unui calup de date, un DA (Data Auditor) – verificatorul (sau auditorul) și furnizorul de servicii de stocare „în nor” (CSSP – „Cloud Storage Service Provider”).

DO este partea care creează datele și le trimite pentru a fi stocate în rețeaua CSSP. DA reprezintă verificatorul, partea care verifică integritatea datelor.

Pentru a începe verificarea integrității datelor, DO descarcă o aplicație care constă dintr-un procesor de date și un verificator de date. Când DO lansează pentru prima dată aplicația, aceasta generează o cheie care este utilizată pentru verificarea integrității datelor. DA este o terță parte autorizată de autoritatea de control pentru a verifica integritatea datelor sale. DA efectuează verificările integrității datelor fără a copia datele din CSSP. Când DO dorește să încarce date în „cloud” (nor), procesorul de date calculează valorile de verificare a integrității pentru aceste date. Aceste valori de verificare a integrității vor fi utilizate pentru a verifica integritatea datelor după ce sunt trimise către „nor”. Atunci când se solicită verificarea integrității datelor, verificatorul de date este invocat și procesul de verificare este inițiat prin interacțiunea cu CSSP.

Arhitectura schemei bazate pe protocol Diffie-Hellman

Autorii au stabilit următoarele obiective de proiectare pentru această schemă de verificare a integrității: verificarea integrității, analiza securității, conservarea confidențialității, verificabilitatea publică, suportul dinamic în operarea datelor și eficiența.

Amenințarea luată în considerare pentru acest sistem apare din două surse, atacatorul și CSSP. Atacatorul are intenția de a corupe fișierele din „cloud” și / sau de a împiedica DO să acceseze datele sale. De asemenea, CSSP este considerată o amenințare la adresa datelor furnizate de DO, deoarece ar putea avea și alte interese decât DO sau acesta poate să nu fie de încredere. De asemenea, CSSP poate ascunde evenimentele de corupere a datelor sau orice alte eșecuri pe care le-ar putea avea, pentru a-și menține reputația. Acest model presupune o securizare prealabilă a canalelor de comunicații dintre DA, DO și CSSP, iar cheia folosită pentru verificarea integrității este stocată local pe DA sau DO și este secretă.

În această schemă, verificatorul stochează numai cheia criptografică, o sumă de control pre-calculată, care nu depinde de dimensiunea fișierului care trebuie verificat și de o cantitate mică de date dinamice de stare.

Definițiile folosite în această schemă

– Această funcție este apelată de DO înainte ca acesta să încarce datele în „cloud”. Rolul acesteia este de a diviza fișierul în blocuri de mărime egală . Ultimul bloc este completat („padded”) cu valoarea 0 până atinge mărimea .

– Algoritmul probabilistic invocat de DO pentru a genera cheia. Intrarea pentru acest algoritm este reprezentată de un parametru de securitate ( biți) și ieșirea este cheia publică plus cheia secretă (privată) . Pentru parametrul dat algoritmul selectează în mod aleatoriu două numere prime mari și , astfel încât . este un subgrup ciclic al de ordinul . Generatorul lui este considerat a fi . Algoritmul alege apoi două numere întregi și , astfel încât . este cheia publică, cunoscută de toată lumea și este cheia secretă cunoscută numai de către verificator(i).

– Funcție invocată de DO pentru a genera o sumă de control pentru fișierul , care va fi utilizată pentru a verifica răspunsul la cererea de verificare a integrității primite de la CSSP. Pentru fiecare fișier de date compus din blocurile de date funcția calculează următoarele valori:

, (XX12)

– Procedura probabilistă condusă de verificatori (poate să fie DO sau DA) pentru a crea o „provocare” ce va fi trimisă către CSSP. Această funcție are ca intrare cheia privată și generează provocarea . După invocarea acestei funcții cu intrarea , se selectează două numere aleatorii, și , iar valoarea se calculează astfel:

, (XX13)

– Funcția utilizată de serverul CSSP pentru a calcula răspunsul la primirea provocării de la un verificator. Odată ce cererea a fost primită, serverul CSSP calculează:

, (XX14)

unde este fișierul de verificat.

– Aceasta este o funcție booleană folosită de verificatori pe DA sau DO pentru a verifica răspunsul de la server. Dacă răspunsul este egal cu atunci ieșirea este adevărată, altfel dacă , ieșirea este falsă, adică fișierul a suferit modificări.

Schema de bază pentru verificarea integrității (câte un singur fișier)

DO dorește să încarce fișierul în „cloud” și să verifice integritatea acestuia mai târziu. indică parametrul de securitate. Schema de bază pentru verificarea integrității poate fi construită în două etape, și .

În etapa DO generează prima dată perechea de chei invocând . DO trimite apoi către CSSP și păstrează secret. Pentru a încărca fișierul , DO apelează funcția pentru a produce blocuri de mărimi egale ale fișierului , . Fiecare bloc are lungimea . Apoi, funcția este apelată pentru a genera valorile , care sunt de asemenea păstrate în secret.

Pentru a efectua verificarea integrității, verificatorii, DA sau DO, invocă pentru a obține valoarea a provocării și a o trimite către serverul CSSP. La recepția serverul CSSP invocă pentru a genera . Apoi, serverul trimite ca răspuns la provocarea verificatorilor. Verificatorul la primirea , apelează pentru a verifica integritatea lui . Dacă ieșirea este adevărată atunci fișierul nu a fost modificat, altfel verificatorul este alertat.

Schema extinsă pentru verificarea integrității (mai multe fișiere)

DO dorește să verifice integritatea mai multor fișiere încărcate (număr finit). Setul de fișiere este notat cu , unde fiecare fișier de la la este împărțit într-un număr de blocuri egale. Ca și mai devreme, dacă ultimul bloc este mai scurt, se folosește completarea („padding”) cu 0. Cu alte cuvinte, pentru fiecare fișierul , unde . Valoarea de verificare pentru fișierul este . Valoarea de verificare este calculată înainte ca fișierul să fie încărcat în „cloud”. Numărul total de blocuri pentru toate fișierele este .

La executarea extinsă a schemei, valoarea provocării este calculată la fel ca în cazul schemei de bază. Atunci când CSSP primește o „cerere de provocare” cu ca valoare a „provocării”, se calculează valoarea răspunsului astfel:

, (XX15)

Când ester primit de către verificatori, aceștia calculează valoarea . Dacă aceasta este egală cu răspunsul atunci verificatorii consideră că fișierele sunt intacte.

Update-urile dinamice

În practică clientul efectuează operațiuni foarte frecvente la nivel de bloc pe datele sale. Cele mai obișnuite operații sunt modificările și adăugările.

Un utilizator ar putea dori să modifice un anumit bloc din fișierul . Blocul modificat va fi notat și valoarea corespunzătoare de verificare . Pentru a calcula valorile de verificare vor fi utilizate următoarele expresii:

, (XX16)

Pentru o operație de adăugare, calculele sunt aceleași. Dacă utilizatorul dorește să adauge blocul la fișierul , valorile de verificare actualizate vor fi:

, (XX17)

Verificarea publică și păstrarea confidențialității

Verificatorul generează o pereche de chei , care este utilizată pentru a calcula valoarea de verificare pentru fișiere. De asemenea, valoarea „provocării” este aleasă aleatoriu și (sau ) nu dezvăluie informații datorită complexității algoritmului. Luând în considerare cele prezentate anterior, acest model de sistem este considerat a suporta verificarea publică și asigurarea păstrării confidențialității.

Analiza securității și eficienței

Se consideră că pentru fișierul , dacă problemele logaritmului discret și a factorizării întregilor mari sunt dificile atunci schema prezentată mai sus este garantată să verifice corect integritatea cu probabilitatea de eroare de , unde este cheia publică. Răspunsul CSSP ar trebui să fie egal cu valoarea de verificare deoarece:

, (XX18)

Dacă notăm cu un posibil răspuns greșit. Probabilitatea pentru este egală cu , deoarece pentru și aleși la întâmplare nimeni, cu excepția verificatorilor, nu poate extrage valoarea de verificare din valoarea a provocării.

Dovada stocării în „cloud” – „Proof of storage”

Din perspectiva securității datelor din „cloud” au existat două concepte majore „Dovada de posesie a datelor” (PDP – „Proof of Data Possession”) și „Dovada de recuperare” (POR – „Proof of Retrievability”). Noțiunea PDP a fost introdusă pentru prima dată de Ateniese și colegii săi în [9]. Această noțiune permite clienților să verifice integritatea datelor lor, la fel ca protocoalele prezentate mai sus. Și face acest lucru într-un mod eficient, mult mai eficient decât descărcarea tuturor datelor de la furnizorul de servicii pentru a le verifica integritatea. A doua noțiune, POR, a fost introdusă de Juels și Kaliski în lucrarea lor „Pors: proofs of retrievability for large files” [10]. Pe lângă ceea ce oferă PDP, această noțiune a permis, de asemenea, clienților să se asigure că datele lor sunt de fapt recuperabile din „cloud”.

Din perspectiva eficienței, a fost propusă o altă noțiune, aceea a „Dovezii proprietății” – „Proof of Ownership" sau POW. Această noțiune a fost introdusă de Halevi et al. în [13]. Pentru a împiedica serverul să stocheze aceleași date de mai multe ori, utilizând astfel resursele din „cloud” și de rețea ineficient. Pentru aceasta se aplică tehnici speciale pentru a șterge datele duplicate. POW oferă serverului un mecanism pentru a determina că un client deține cu adevărat datele pe care le pretinde.

Până de curând, noțiunile de securitate și eficiență au fost studiate separat, pentru că arătau ca două noțiuni distincte sau opuse. Protocolul analizat în paginile următoare a fost propus de Qingji Zheng și Shouhuai Xu, de la Universitatea din Texas, la San Antonio, în lucrarea „Secure and Efficient Proof of Storage with Deduplication” [11]. Acest document propune un sistem în care cele două aspecte ale securității și eficienței pot coexista în același cadru. Schema exploatează faptul că verificabilitatea publică a schemelor PDP și POR poate fi utilizată pentru a obține dovada proprietății POW. Noțiunea propusă a fost numită „Dovada stocării cu deduplicare” („Proof of Storage with Deduplication”) POSD și este o schemă care este demonstrabil sigură în modelul „Random Oracle” pe ipoteza computațională Diffie-Helman.

Schema POSD – „Proof Of Storage with Deduplication”

Deduplicarea este o tehnică obișnuită folosită de mulți CSSP pentru a asigura eficiența stocării în „cloud-ul” furnizat clienților. Deduplicarea e folosită deoarece o mare parte din datele stocate în cloud sunt duplicate. Conform unui sondaj din 2010 [12], până la 75% din datele stocate în „cloud” sunt duplicate. Astfel, folosind tehnici de deduplicare, CSSP poate salva spațiu de stocare și resurse de rețea eliminând datele duplicate din „cloud-ul” său. De asemenea, este foarte probabil ca mulți clienți să aibă aceleași date stocate în „cloud” și păstrând doar o singură copie a acestor date, CSSP poate salva cantități substanțiale de spațiu.

Noțiunea de deduplicare a fost propusă de Harnik et al. în [14], dar prezintă o problemă dacă este aplicată direct, orice utilizator ar putea să pretindă posesia acelor date. Deci, a fost nevoie de o soluție pentru a dovedi proprietatea asupra datelor. Soluția a fost schema POW propusă în [13], în care a fost prezentată și o soluție concretă.

Protocolul analizat propune o schemă care se adresează atât securității, cât și eficienței, permițând deduplicarea securizată a datelor.

Notații:

un parametru de securitate. O funcție ester considerate neglijabilă dacă este mai mică decât pentru oricare și oricare suficient de mare;

un număr prim pe biți și un alt număr prim astfel încât ;

un fișier de date constând din blocuri. Fiecare bloc este compus din simboluri în spațiul , i.e. unde este blocul din fișierul cu numărul ;

identitatea care identifică în mod unic fișierul ;

informație auxiliară asociată fiecărui fișier (i.e. etichete criptografice). Sunt două tipuri de , și . este informația criptografică asociată procesului de verificare a integrității, iar este informația criptografică folosită în procesul de deduplicare;

un identificator pentru argumente opționale ale funcțiilor și algoritmilor (e.g. , semnifică faptul că are două argumente obligatorii, și și un argument opțional ).

Configurația din punct de vedere criptografic și presupuneri

Se consideră și a fi două grupuri ciclice de ordin prim iar este generatorul lui . Fie o hartă biliniară cu următoarele proprietăți:

poate fi calculat ușor;

, și , ;

.

Problema computțională Diffie-Hellman standard (CDH) este următoarea: Date fiind , unde , și sunt alese uniform și aleatoriu din , a se calcula . Presupunerea CDH stipulează că nici un algoritm probabilistic de timp polinomial („probabilistic polynomial-time” – PPT) nu poate rezolva problema CDH cu o probabilitate ne-neglijabilă (in ).

Problema logaritmului discret („Discrete Logarithm” – DLOG) este următoarea: Date fiind oricare, grup ciclic de ordin prim și două elemente aleatorii și , a se găsi astfel încât . De asemenea presupunerea DLOG stipulează că nici un algoritm probabilistic de timp polinomial („probabilistic polynomial-time” – PPT) nu poate rezolva problema DLOG cu o probabilitate ne-neglijabilă (in ). Presupunerea DLOG este mai „slabă” comparativ cu presupunerea CDH.

Fie și două funcții hash aleatoriu alese din familiile fiecăreia. Ambele și sunt modelate ca oracole aleatorii.

De asemenea, fie o familie de funcții pseudoaleatorii sigure.

Cerințe (obiective) definite pentru POSD

Cerințele soluției, așa cum au fost formulate de autori:

soluția trebuie implementată folosind funcții standard/comune (e.g. funcții hash) pentru a permite interoperabilitatea între clienți;

pentru a păstra resursele de rețea (i.e. lățimea de bandă) și de procesare, soluția ar trebui să fie mai eficientă decât soluția de bază a copierii datelor și efectuarea verificarea integrității în mod off-line;

soluția nu ar trebui să forțeze serverul de „cloud” să recupereze o parte semnificativă a fișierelor de date atunci când stabilește că trebuie efectuată deduplicarea. Acest lucru se datorează faptului că un server, atunci când încarcă fișiere mari din memoria de stocare, consumă o cantitate mare de resurse;

soluția ar trebui, de asemenea, să solicite clientului să efectueze doar o singură trecere asupra fișierului de date, folosind o cantitate de memorie care este substanțial mai mică decât dimensiunea fișierului respectiv.

Această schemă ia în considerare trei modele de participanți, un server de stocare în „cloud” (S), clienții de stocare în „cloud” (C) și o terță parte, cunoscută și ca Auditor. Auditorul poate fi o terță parte care are acceptul clientului pentru a verifica integritatea datelor sale sau poate fi un alt client care are aceleași date stocate în „cloud”. Un alt fapt despre această schemă este că datele sunt stocate doar în text clar pentru a efectua deduplicarea (același lucru se poate spune despre POW [13]). Acest fapt se poate dovedi a fi un dezavantaj al schemei în general.

Definire funcțională

Pentru a defini POSD trebuie luate în considerare definițiile PDP / POR și POW [9], [10], [13]. Ca o definiție funcțională, o schemă POSD, notată , este o schemă care constă din următorii algoritmi de timp polinomi [11].

este algoritmul de generare a cheilor. Are nevoie la intrare un parametru de securitate și generează două perechi de chei publice / private și . și sunt cheile publice în timp ce și sunt cheile private/secrete corespunzătoare. Prima pereche este utilizată pentru verificarea integrității, iar a doua pereche este utilizată pentru scopuri deduplicate securizate.

este un protocol de încărcare a datelor care rulează pe un canal privat între clientul și serverul . Protocolul funcționează după cum urmează: să presupunem că dorește să încarce fișierul pe „cloud” unde poate detecta dacă a fost deja încărcat de alt client (e.g. prin compararea funcției hash furnizate lui de către față de o listă a valorilor hash stocate pe ). Înainte de a începe încărcarea pe clientul , ia ca intrare fișierul cu un identificator unic și cu cheia secretă și generează informația auxiliară , care poate fi utilizată ulterior pentru a verifica integritatea fișierului stocat pe . După încărcarea, serverul stochează , și primite de la , precum și unele informații de deduplicare care pot fi produse de utilizând cheia privată . poate de asemenea să păstreze valorile hash ale fișierelor ca pentru a facilita detectarea duplicării datelor.

este protocolul de verificare a integrității datelor. Acesta se executată între și auditor. Serverul încearcă să convingă auditorul că integritatea anumitor fișiere stocate pe este asigurată. Pe partea auditorului, protocolul ia ca intrare identificatorul fișierului de date și cheia publică corespunzătoare a proprietarului datelor. Pe partea serverului, protocolul ia ca intrare fișierul de date care corespunde cu și informația auxiliară asociată cu . În esență, protocolul este de tipul „Provocare-Răspuns” (CRP), ca cel prezentat anterior în această lucrare. Auditorul trimite provocarea la serverul , iar acesta din urmă calculează răspunsul care, la rândul său, este trimis auditorului. Dacă este valabil, atunci auditorul ajunge la concluzia că integritatea luieste asigurată și ieșirea ca valoare booleană adevărată („true”), în caz contrar rezultă (i.e. fals/„false”).

este protocolul de verificare a deduplicării. Acest protocol este executat între serverulși clientul , care pretinde posesie asupra fișierului de date . Pentru a detecta dacă este nevoie de deduplicare, clientul trimite valoarea hash a fișierului și serverul poate evalua dacă fișierul este deja stocat. Acest protocol se bazează, de asemenea, pe o metodă de tipul „Provocare-Răspuns” (CRP). De data aceasta, serverultrimite o provocare clientului care răspunde cu răspunsul care este calculat folosind fișierul și eventual alte informații. compară cu valoarea proprie calculată folosind și . Ieșirea este dacă răspunsul se verifică sau dacă nu.

Definirea validității POSD

O schemă POSD este considerată validă/corectă dacă, pentru un client și un server integru/cinstit, execuția funcțiilor și a generat de fiecare dată un răspuns adevărat (i.e. – „true”).

Definirea securității

În [11] securitatea POSD este definită folosind așa numitele „jocuri” („games”), care specifică atât comportamentul adversarului (i.e. ceea ce îi este permis adversarului să facă), cât și condiția câștigătoare (i.e. în ce circumstanțe se consideră că atacul a reușit). La un nivel mai înalt, o schemă POSD trebuie să fie , care este similară cu securitatea definită de „jocul posesia datelor” descris în [9] și care este similar cu definiția de securitate din [13].

În [11] o schemă POSD este dacă nici un server al atacatorului nu poate executa cu succes protocolul cu un auditor onest, la o probabilitate de ne-neglijabilă. De asemenea, o schemă POSD este dacă probabilitatea de a câștiga (jocul) pentru orice algoritm PPT este neglijabil (în ) mai mult decât .

Construcția soluției

Construcția POSD a plecat de la premisa că POSD=PDP+POW. Aceasta deoarece obiectivul POSD este de a oferi atât funcționalitățile auditului integrității cât și ale deduplicării.

este algoritmul care generează perechile de chei criptografice. Și face acest lucru după cum urmează:

se alege și în mod uniform aleatoriu din mulțimea astfel încât ordinul lui și al lui să fie (dacă este generat din , atunci DLOG din în bază ar trebui șters ulterior);

se alege și în mod uniform aleatoriu din mulțimea pentru . Se calculează pentru ;

fie generatorul lui . Se alege în mod uniform aleatoriu din . Se alege în mod uniform aleatoriu din mulțimea și se calculează ;

se stabilește și cheia private/secretă a clientului . Este de remarcat faptul că utilizarea unei funcții pseudoaleatorii corespunzătoare (PRF) este posibil să se reducă în continuare necesarul de spațiu de stocare la capătul clientului (i.e. folosind o singură cheie în PRF pentru generarea );

se stabilește și , unde este de asemenea făcută publică.

este protocolul stabilit între un client, ce dorește să stocheze un fișier de date în „cloud”, și server. Acest lucru se desfășoară după cum urmează:

Pentru fiecare bloc al fișierului , cu , clientul selectează și uniform aleatoriu din și calculează:

, (XX19)

Clientul trimite serverului, unde .

La primirea , serverul setează .

AUDITINT este protocolul stabilit între auditor, care poate fi clientul în sine și serverul de „cloud”. Scopul său este de a verifica integritatea fișierului de date al clientului stocat în „cloud”. În cazul în care auditorul nu este clientul, ci o terță parte, clientul nu trebuie să dea auditorului nici o informație, decât cheia publică și identificatorul de fișier .

Auditorul alege un set de elemente , unde este selectat uniform aleatoriu din , și un set de coeficienți , unde este selectat uniform aleatoriu de la . După această selecție, valoarea provocării , poate fi construită și trimisă serverului.

După aceasta serverul calculează:

, (XX20)

pentru și

, (XX21)

(în ) , (XX22)

După efectuarea calculelor, serverul poate trimite răspunsul auditorului, , unde pentru a fost generat de client la faza .

Când auditorul primește , acesta calculează:

, (XX23)

și în cele din urmă acesta verifică:

, (XX24)

, (în ) (XX25)

Dacă ambele comparații sunt adevărate, atunci returnează 1, altfel returnează 0.

este protocolul invocat când un client afirmă că posedă fișierul cu identificatorul , fișier care a fost de asemenea încărcat de alt client. Acest protocol se stabilește între acel client și server. Protocolul este o versiune mai simplă a protocolului . Diferența este că aici partea auditorului este jucată de server. Există unele modificări minore, deoarece nu toate informațiile utilizate pentru calculul răspunsului sunt cunoscute clientului.

Serverul alege un set de elemente , unde este selectat uniform aleatoriu din , și un set de coeficienți , unde este selectat uniform aleatoriu de la . După această selecție, valoarea provocării , poate fi construită și trimisă clientului.

Serverul calculează valoarea , care este aceeași cu (20), pentru și trimite ca răspuns la server.

De la valoarea , serverul calculează valorile , , , , folosind ecuațiile (21), (23) și (22) prezentate mai sus pentru protocolul . Apoi execută verificările (24) și (25). Dacă ambele sunt adevărate returnează , altfel va returna .

Analiza validității/corectitudinii POSD

Corectitudinea schemei POSD se poate verifica (cu concordanță cu definiția corectitudinii, prezentată anterior):

===

=====X.

și

e(T,g)====

==.

Analiza securității

Teorema 1: Dacă și sunt funcții hash modelate ca oracole aleatoare și problema CDH este una dificilă, atunci schema POSD este .

Dovada acestei teoreme a fost formulată de autorii lucrării [11] ca o serie de „jocuri”, între un „provocator” („challenger”), care joacă rolul unui client cinstit, și un adversar notat cu , care acționează ca un server malware. Ideea generală a strategiei de demonstrație este că atunci când se dă corespunzând lui , care este stocat pe server, și un „provocator” ales aleator (selectat de client), dacă poate trece verificarea folosind o pereche care nu este egală cu , atunci există un algoritm care poate rezolva problema CDH.

Jocul0: În acest scenariu, adversarul păstrează numai cheile private și publice relevante și lista identificatorului fișierului de date () pe care la folosit. Lista este marcată cu .

Jocul1: Este același lucru cu Jocul0, cu excepția faptului că adversarul păstrează lista implicată în executarea protocolului . Acest scenariu este folosit pentru a dovedi că dacă (adversarul) poate produce un fals care va trece protocolul cu privire la provocarea trimisă de către „provocator”, atunci există un algoritm care poate rezolva problema CDH.

Pentru a pune la încercare aceste scenarii de joc, ar trebui să fie modelat un simulator pentru această construcție. Un astfel de simulator a fost modelat în [11] și este explicat și detaliat mai jos.

Pentru a genera cheile, următorul proces se desfășoară:

se alege și în mod uniform aleatoriu din mulțimea astfel încât ordinul lui și al lui să fie (dacă este generat din , atunci DLOG din în bază ar trebui șters ulterior);

se alege și în mod uniform aleatoriu din mulțimea pentru . Se calculează pentru ;

fie un generator pentru . Se alege în mod uniform aleatoriu din . Se calculează , unde și sunt selectate uniform aleatoriu din ;

se alege uniform aleatoriu din grupul , ceea ce înseamnă că simulatorul nu cunoaște corespondentul pentru care ;

se generează și . Simulatorul va cunoaște numai cheile secrete fără a cunoaște și valoarea .

Simulatorului modelează ca un oracol aleator și funcționează astfel: dată fiind intrarea , verifică dacă această intrare a mai fost văzut înainte, dacă da, funcția generează . În caz contrar, selectează uniform aleatoriu din și produce la ieșire. Simulatorul păstrează lista .

Pentru a calcula pentru fișierul , simulatorul execută următoarele: pentru fiecare cu , acesta selectează și uniform aleatoriu din și calculează:

(XX26)

Se selectează uniform aleatoriu din și calculează .

Astfel vom avea .

Se stabilește eticheta criptografică pentru blocul . Simulatorul alcătuiește și păstrează lista . Valoarea este necunoscută atacatorului .

Atunci când atacatorul interoghează separat , simulatorul operează după cum urmează: Dacă a fost deja folosit pentru interogare, returnează . În caz contrar selectează uniform aleatoriu din și returnează . este necunoscut atacatorului .

Simulatorul interacționează cu până când acesta generează falsul (unde sunt alese în mod aleatoriu de simulator) la etapa de falsificare a răspunsului și acesta câștigă jocul.

Presupunem că atacatorul produce pentru a câștiga jocul1. Asta înseamnă că , dar:

(XX27)

unde , și și din care , sunt calculate. Corectitudinea/validitatea acestei scheme implică:

(XX28)

Și pentru că atacatorul câștigă acest joc,

(XX29)

Sunt trei posibilități luate în considerație pentru ecuația (27):

cazul 1: ;

cazul 2: , dar pentru anumiți ;

cazul 3: , pentru orice , dar

Pentru aceste trei cazuri, ecuațiile (28) și (29) vor fi folosite pentru a demonstra că simulatorul va rezolva problema CDH. Acest lucru înseamnă că atacatorul nu va putea câștiga jocul cu o probabilitate ne-neglijabilă, finalizând astfel demonstrația.

Cazul 1: .

Vom avea . Prin înlocuirea lui cu , ecuația va deveni .

Se poate observa că dacă rearanjăm termenii, vom obține . Astfel, deoarece , se poate afirma că . Și datorită faptului că , vom obține , ceea ce semnifică, pentru , că problema CDH poate fi rezolvată prin calcularea valorii , având în vedere că pentru o valoare necunoscută a lui .

Cazul 2: , dar pentru anumiți .

Din cauză că , . După rearanjarea termenilor vom obține .

Deoarece probabilitatea ca este neglijabilă și , vom avea , ceea ce semnifică faptul că simulatorul poate rezolva DLOG de în bază , invalidând imediat presupunerea CDH.

Cazul 3: , pentru orice , dar

Având în vedere că:

(XX30)

și

(XX31)

Cum pentru

(XX32)

Înlocuind în (32) cu , vom obține:

(XX33)

Astfel, cum , atunci simulatorul poate calcula DLOG de (aleatoriu) în bază , ceea ce invalidează imediat presupunerea CDH.

Teorema 2: Să presupunem că și sunt funcții hash modelate ca oracole aleatorii și problema CDH este dificilă. Schema POSD este în ceea ce privește „provocarea” blocurilor în protocolul DEDUP, unde este entropia minimă a fișierul în cauză, este cantitatea de entropie scursă sau furată de adversar și este neglijabilă în parametrul de securitate .

Conform teoremei 1, dat fiind că și sunt funcții hash modelate ca oracole aleatoare și problema CDH este dificilă, schema POSD este . Aceasta este, dată fiind „provocarea” cu identificatorul de fișier , răspunsul trebuie construit în mod cinstit din , astfel încât să se respecte ecuațiile (31) și (34).

(XX34)

Deci, fie „provocarea”, cu identificatorul de fișier corespunzător , în execuția DEDUP. Fie răspunsul clientului rău intenționat și , , , sunt calculați din de către serverul de „cloud”. Așa cum ne amintim, , atunci vom avea , , și . Prin urmare, pentru a satisface (30) și (35) avem pentru , altfel vom putea rezolva problema DLOG în bază din (aleatoriu) (cazul 3 pentru dovada teoremei 1). Acest lucru înseamnă că un client răuvoitor trebuie să calculeze în mod cinstit din . Deci, acest client poate câștiga jocul numai dacă poate descoperi entropia necunoscută a biților în blocul de date specificat prin .

(XX35)

În continuare, notăm ca fiind evenimentul în care există blocuri de date cu entropie necunoscută a biților, iar adversarul încearcă să ghicească entropia necunoscută a biților pentru a trișa serverul. Pentru a simplifica modelul, să presupunem că entropia necunoscută a biților este distribuită uniform peste blocurile de date . De asemenea, deoarece blocurile de date „provocate” sunt alese aleatoriu uniform, putem presupune că entropia necunoscută a biților se distribuie peste F uniform. Și așa, probabilitatea lui este:

(XX36)

unde . Acest lucru demonstrează teorema 2 și finalizează analiza securității schemei POSD.

După cum s-a putut observa, schema POSD oferă o modalitate de obținere a auditului datelor și a dovezii de proprietate în cadrul unor scenarii de deduplicare a datelor. De asemenea, s-a dovedit că POSD satisface cerințele stabilite de creatorii acesteia.

Compararea eficienței între scheme PDP, POR, POW și POSD [11], unde este numărul de blocuri ale unui fișier de date, este numărul de simboluri ale unui bloc, este numărul de blocuri care vor fi „provocate”, ERR probabilitatea de corupție a blocurilor, operațiunea de exponențiere modulară, operația de multiplicare modulară și N/A înseamnă neaplicabil.

Din tabelul precedent, putem observa că schema POSD necesită exponențieri atunci când clientul procesează fișierul înainte de a-l încărca. Această complexitate este mult mai mică decât cerințele de procesare ale PDP și POR. Dar, din același tabel, putem vedea că în procesul de audit, consumul de resurse de rețea al POSD este mai mare decât cel aferent POR și PDP. Dar diferența nu este semnificativă, mai ales atunci când vorbim de fișiere mari. De exemplu, dacă avem un fișier de date de blocuri de câte simboluri fiecare (adică 2,5 GB dacă ). Dacă probabilitatea ca blocul să fie corupt este ERR = 0.01 atunci avem aproximativ blocuri de date corupte. Dacă vrem să obținem o probabilitate de detecție a corupției de 99,5%, atunci consumul de resurse de rețea suplimentar pentru POSD este de biți (adică 8 KB). Diferența nu este semnificativă dacă luăm în considerare posibilitățile rețelelor de comunicații din prezent.

Când comparăm eficiența deduplicării dintre POSD și POW, putem vedea că POW este puțin mai eficient. Dar principalul dezavantaj al POW este că nu poate efectua auditul datelor. De asemenea, POSD folosește mai puține resurse de rețea decât POW (deoarece este de obicei mai mic decât . Putem vedea, de asemenea, că POW este sigur în modelul standard, pe baza utilizării funcțiilor Hash rezistente la coliziune (C-RH).

În concluzie, construirea schemei „Proof Storage with Deduplication” (POSD) a fost motivată de necesitatea de a efectua simultan două operații de securitate pe sistemele de stocare în „cloud”, verificarea integrității și deduplicarea. Schema prezentată își moștenește securitatea din modelului „Random Oracle” (Oracol Aleatoriu) bazat pe ipoteza computațională Diffie-Hellman (CDH). Schema s-a dovedit a fi la fel de eficientă ca și alte modele (PDP, POR și POW). Dar, spre deosebire de celelalte scheme, POSD are avantajul de a efectua simultan două operațiuni de securitate.

Această schemă poate fi îmbunătățită prin dezvoltarea unui model care elimină oracolul aleatoriu din protocol fără a afecta performanța. Performanța poate fi îmbunătățită și prin dezvoltarea unei alte metodologii de proiectare.

– Conceptul de semnătură anonimă

Semnături digitale standard

Semnăturile digitale standard sunt scheme matematice folosite pentru demonstrarea autenticității unui mesaj digital sau document. O semnătură digitală validă oferă motive suficiente destinatarului mesajului ca acesta să considere că mesajul a fost primit de un expeditor cunoscut care nu poate nega trimiterea (autenticitatea si non-repudierea oferite de semnăturile digitale). De asemenea destinatarul poate considera în mod justificat că mesajul nu a fost modificat pe parcurs (integritatea). Semnăturile digitale sunt folosite în mod uzual la distribuții de software, tranzacții financiare și în alte cazuri unde este important să se evite falsificarea sau modificarea.

RSA (Rivest-Shamir-Adleman) este unul din primele criptosisteme cu chei publice puse în practică și este folosit la scară largă pentru transmisiile securizate de date. Într-un astfel de criptosistem cheia de criptare este publică și diferă de cheia pentru decriptare care este păstrată secret. În RSA, această asimetrie este bazată pe dificultatea practică de a factoriza produsul a două numere prime mari.

Utilizatorii algoritmului RSA generează și apoi publică o cheie publică bazată pe două numere prime mari, alături de o valoare auxiliară. Cele două numere prime trebuie ținute în secret. Oricine poate folosi cheia publică pentru a cripta mesaje, dar prin metodele actuale, numai cineva care cunoaște cele două numere prime poate decripta acele mesaje, cu condiția ca respectiva cheie publică să aibă o lungime mare.

Algoritmul RSA implică trei pași: generarea cheii, criptarea și decriptarea.

Generarea cheilor în RSA implică generarea unei chei publice și a unei chei private (secrete). Cea publică poate fi cunoscută de oricine și este folosită pentru criptarea mesajelor. Mesajele criptate cu cheia publică pot fi decriptate folosind cheia privată. Pentru generarea cheilor algoritmul urmărește următorii pași:

Se aleg două numere prime distincte și . Din motive de siguranță, numerele și alese vor fi alese în mod aleatoriu și vor avea lungimi binare asemănătoare. Numere prime aparținând mulțimii numerelor întregi pot fi alese în mod eficient folosind teste de determinare a numerelor prime.

Se va calcula:

(1)

Parametrul este folosit ca modul pentru ambele chei (publică și privată). Lungimea acestuia este lungimea cheii și în general este exprimat în biți. În acest moment lungimea minimă recomandată a cheilor unui sistem PKI („Public Key Infrastructure”) este de 2048 biți.

La următorul pas se calculează:

(2)

unde este „Indicatorul lui Euler” („Euler’s totient function”). Această valoare este ținută secretă.

Se va alege un număr întreg astfel încât:

și (3)

i.e. și coprime ( reprezintă cel mai mare divizor comun). Parametrul va reprezenta exponentul cheii publice. Parametrul cu o lungime mică de biți și un număr mic de biți de „1” („Hamming Weight”) duce la o soluție de criptare mai eficientă (uzual 216+1=65537). Totuși valori foarte mici ale lui (e.g. 3) s-au dovedit a fi mai puțin sigure în anumite situații.

Se va determina astfel încât:

(4)

Cheia publică va consta în modulul și exponentul public (de criptare). Cheia privată constă în modulul și exponentul privat (de decriptare) care va trebui menținut secret. , și trebuie, de asemenea, ținute în secret, deoarece pot fi folosite pentru a calcula valoarea lui . Mai clar se poate exprima ca soluția pentru la:

(5)

Acesta este des calculat folosind algoritmul Euclidian extins. Parametrul reprezintă exponentul cheii private. O alternativă, folosită în cazul standardului PKCS#1, este alegerea lui astfel încât:

cu (6)

unde reprezintă cel mai mic multiplu comun. Folosirea lui în loc de permite mai multe variante pentru . Valoarea lui poate fi de asemenea definită folosind funcția Carmichael, .

Algoritmul de criptare funcționează astfel: Alina transmite cheia ei publică lui Ionel și ține secretă cheia privată . Când Ionel dorește să trimită un mesaj Alinei, acesta transformă mesajul într-un număr întreg astfel încât:

și (7)

folosind un algoritm reversibil acceptat în prealabil de ambii participanți (Alina și Ionel) numit și schemă de „padding”. După acest pas, Ionel generează textul criptat astfel încât:

(8)

Acest pas poate fi trecut în mod eficient, chiar și pentru numere cu lungime de 500 biți, folosind exponențierea modulară. După acest pas Ionel transmite textul criptat Alinei. Se poate observa că cel puțin nouă valori ale lui vor genera un text criptat egal cu .

Algoritmul de decriptare presupune că Alina va putea recupera din folosind exponentul cheii ei private prin executarea următorului calcul:

(9)

Dat fiind , Alina poate recupera mesajul original prin inversarea schemei de „padding”. În practică există metode mult mai eficiente de calcul al valorii folosind valori precalculate.

În continuare este prezentat un exemplu de criptare și decriptare RSA. Parametri folosiți în acest exemplu sunt aleși foarte mici din motive de simplitate, dar aceștia pot fi aleși folosind diverse programe (e.g. OpenSSL) pentru a genera și examina o pereche reală de chei.

Alegerea a două numere prime distincte:

=61 și =53 (10)

Se calculează:

= adică =3233 (11)

Se calculează totient-ul produsului astfel:

adică =3120 (12)

Se alege orice număr:

(13)

care să fie coprim cu 3120. Alegând un număr prim pentru nu rămâne decât să se verifice dacă este divizor al lui 3120. De exemplu poate fi 17.

Se calculează , modulul multiplicativ invers al:

, rezultând =2753 (14)

Se poate observa că:

și (15)

Cheia publică este (). Pentru un text în clar cu pad adăugat, funcția de criptare este:

(16)

Cheia privată va fi (). Pentru un text criptat , funcția de decriptare este:

(17)

De exemplu, pentru a cripta =65, se va calcula:

(18)

Pentru a decripta =2790, se va calcula:

(19)

Ambele calcule de mai sus se pot rezolva eficient folosind un algoritm de ridicare la pătrat și multiplicare („square-and-multiply algorithm”) pentru exponențierea în modul. Bine înțeles în realitate numerele prime alese vor fi mult mai mari. Dacă s-ar alege în realitate numere prime așa mici, ca în exemplul de mai sus, ar fi foarte ușor să se obțină (prin factorizare) din și 3233 (disponibile din cheia publică) numerele prime și . Dat fiind , de asemenea disponibil în cheia publică, s-ar putea apoi calcula și astfel obține cheia privată. Implementările practice folosesc Teorema chinezească a resturilor pentru a crește viteza calculelor.

Valorile , și , care sunt parte din cheia privată sunt calculați astfel:

(20)

Pentru decriptare valorile , și se vor folosi în mod eficient astfel:

(21)

Astfel pentru a semna mesajele se presupune că Alina va folosi cheia publică a lui Ionel pentru a-i trimite acestuia un mesaj criptat. Din mesaj Ionel vede că mesajul provine de la Alina, dar nu are cum să dovedească acest lucru, având în vedere că oricine poate folosi cheia publică a lui Ionel. Pentru a verifica originea mesajelor, algoritmul RSA oferă posibilitatea unei metode de semnătură digitală.

Se presupune că Alina dorește să trimită un mesaj semnat lui Ionel. Pentru asta poate folosi propria cheie privată. Ea va produce o valoare „hash” a mesajului, o va ridica la puterea (modulo ), la fel cum face atunci când decriptează un mesaj, și atașează rezultatul ca și semnătură la mesajul inițial. La primirea mesajului semnat, Ionel va folosi același algoritm „hash” împreună cu cheia publică a Alinei. Va ridica semnătura la puterea (modulo n), la fel cum procedează pentru criptare, și compară rezultatul cu valoarea „hash” calculată de el din mesaj. Dacă cele două sunt identice atunci poate considera că cel care a semnat mesajul deține într-adevăr cheia privată a Alinei și că mesajul nu a fost modificat în tranzit.

Semnături digitale anonime

Semnăturile digitale anonime folosesc algoritmii semnăturilor digitale standard, dar în loc să ofere identitatea semnatarului mesajului () în orice moment, semnătura () ascunde identitatea semnatarului până la un moment dat. Semnăturile anonime sunt folosite în multe aplicații unde identitatea semnatarului trebuie protejată, e.g. protocoale de schimb de chei, sisteme de licitații electronice, sisteme electronice de revizuire a lucrărilor științifice sau sisteme electronice de votare, etc..

Există mai cunoscute modele de scheme de semnături anonime, dar cele mai relevante sunt schemele Yang [1], [5] și Saraswat [3]. De asemenea schemele de semnături electronice au fost studiate în continuare și de Fischlin în [2]. Schema Yang pentru semnături anonime garantează anonimitatea semnatarului atunci când adversarul obține numai semnătura dar nu și mesajul, sau când mesajul conține un șir aleatoriu numit parametru de securitate, care este ținut secret până în momentul fazei de verificare, atunci când se verifică identitatea semnatarului. Menținerea în secret a unei părți a mesajului poate să nu fie potrivită pentru toate aplicațiile, dar există anumite aplicații care pot funcționa în felul acesta.

Schema Saraswat pentru scheme de semnături anonime împarte semnătura σ* în două segmente de date, . Prima parte a semnăturii digitale este numită semnătură anonimă sau simpli semnătură, iar a doua parte este numită „token” de verificare sau simplu „token”. În generarea semnăturii și a token-ului se folosește algoritmul de generare a semnăturii, algoritm ce folosește că intrări cheia secretă a semnatarului și mesajul . Faza de verificare se petrece când semnatarul anonim decide că este momentul să demonstreze public că mesajul semnat anonim îi aparține cu adevărat. În acest moment semnatarul trebuie să facă publice , și și la urmă validitatea mesajului poate fi verificată de către oricine folosind cheia publică a semnatarului. Cât timp este ascuns, nimeni nu poate determina cine este semnatarul, astfel identitatea acestuia nu poate fi aflată cunoscând numai mesajul și semnătura .

O schemă cu semnături anonime Σ este definită de tripletul de algoritmi , unde cheia de generare produce o pereche de chei , algoritmul de generare a semnăturii produce o pereche formată din semnătura anonimă și token-ul de verificare folosind cheia privată și mesajul , iar algoritmul deterministic de verificare a semnăturii produce un rezultat de tip boolean, „” sau „”. Atunci când mesajul sau token-ul nu au fost modificate, următoarea relație va fi adevărată:

(22)

pentru și pentru oricare ar fi .

Aplicabilitatea schemelor cu semnături anonime

Domeniul de aplicabilitate al schemelor cu semnături anonime este unul destul de vast. Aplicațiile care pot folosi aceste scheme sunt cele în care din motive justificate semnatarul unui mesaj dorește să-și mențină anonimitatea până când acesta intenționează să-și demonstreze public „proprietatea” asupra mesajului.

Exemple de astfel de aplicații sunt foarte multe, dar cele care ies în evidență de cele mai multe ori sunt aplicațiile de tipul vot electronic [4], loterie electronică [7], protocoale de schimb de chei („key exchange protocols”), sisteme electronice de revizuire a lucrărilor științifice, etc..

De exemplu în sistemele electronice de revizuire a lucrărilor științifice, care folosesc scheme cu semnături anonime, autorii pot publica lucrările în mod anonim, fără a face publice numele, credențialele, afilierile sau orice altă informație folosită pentru identificare. Astfel se poate evita din start orice prejudecată pe care ar putea-o avea evaluatorii acelor lucrări față de persoana sau instituția care publică lucrarea. În final după revizuire și acordarea calificativelor, autorii pot face dovada posesiei respectivelor lucrări.

Ca exemplu protocoalele de schimb de chei ce folosesc scheme cu semnături anonime pot fi folosite de dispozitivele mobile pentru a comunica cu stațiile de bază în mod anonim fără a putea fi urmărite sau identificate de oricine încearcă să „asculte” comunicația, de alte dispozitive mobile sau alte stații de bază. De asemenea aceste tipuri de protocoale pot avea întrebuințări într-un spectru mult mai larg al comunicațiilor între diferitele tipuri de dispozitive (e.g. comunicația între clienți și servere).

În sistemele de vot electronic, schemele cu semnături anonime pot fi folosite cu succes facilitând verificabilitatea criptografică a votului. O metodă de implementare este aceea ca fiecare votant să posede un element de stocare personal care va fi folosit pentru semnarea anonimă a votului și pentru o verificare ulterioară a înregistrării votului. Voturile vor fi publicate în mod public și în timp real dar fără a fi posibilă asocierea între votant și alegerea făcută de acesta. Lista cu participanții la vot ar trebui de asemenea să fie publică pentru a facilita auditarea ulterioară a participării la vot și pentru a descuraja tentativele de fraudare.

În sistemele de loterie electronică schemele cu semnături anonime se pot utiliza pentru a ascunde identitatea jucătorului până în momentul când acesta decide să pretindă premiul. Acest lucru este util pentru a nu da posibilitatea organizatorului loteriei să ofere premiul unui jucător ales prin manipularea extragerii. Astfel, folosirea unei scheme cu semnături anonime în sistemele de loterie electronică poate restabili încrederea jucătorilor în loterie și în acest mod poate crește încasările loteriei prin participarea mai multor jucători.

În continuare va fi prezentat un exemplu de propunere de aplicabilitate într-un sistem de loterie electronică, sau E-lottery, menit să restabilească încrederea populației în sistemul de loterie națională. Această propunere a fost publicată de autorul acestei teze și colegii acestuia în [XY].

Îmbunătățirea sistemului național de loterie prin introducerea semnăturilor anonime

Sistemul existent al loteriei naționale

Sistemul loteriei românești 6/49 a început pe 8 august 1993 așa cum este precizat pe site-ul www.loto49.ro, dar site-ul oficial al loteriei, www.loto.ro, nu afișează numai rezultatele tragerilor începând cu data de 4 ianuarie 1998. Regulile Loteriei Naționale "Loto" sunt aceleași cu ale altor loterii similare. Jucătorii participă la loterie prin cumpărarea de bilete. Pe un bilet, un jucător are posibilitatea de a alege unul sau două dintre variantele următoare: încearcă să ghicească 6 numere de la 1 la 49 și / sau încearcă să ghicească un număr "noroc" format din 7 cifre. Jucătorii au posibilitatea să cumpere bilete oricând, dar nu mai târziu de ziua precedentă remizei. Jucători completează numerele alese pe bilete, care la urmă sunt validate de o mașină electronică ce scanează și imprimă pe acestea un cod folosit pentru a confirma numerele alese. Numerele câștigătoare sunt extrase de o mașină, sub supravegherea unei comisii formate din persoane din cadrul Ministerului de Finanțe și Ministerului de Interne. Extragerea este publică și oricine poate să asiste, prin completarea unei cereri. Mașina de extragere constă dintr-un bol cu ​​bile etichetate de la 1 la 49. Aceasta alege șase bile la întâmplare, fără a le reintroduce în bol. După extragerea celor 6 bile, se face o altă extragere, de data aceasta doar cu 10 bile, numerotate de la 0 la 9. A doua extragere este repetată de 7 ori, cu înlocuirea bilelor. În acest fel se formează un număr compus din 7 cifre, așa numitul număr „noroc”.

Testarea aleatorismului extragerilor de la loterie

Pentru a evalua oportunitatea de a dezvolta și implementa sistemul de loterie cu semnături anonime, s-a considerat că este necesar să se investigheze caracterul aleatoriu al extragerilor din unele țări. În acest scop, a fost investigată aleatorismul a trei loterii (Romania, Canada și Marea Britanie). Metodele de testare și rezultatele comparative sunt prezentate în cele ce urmează.

În mod evident, nu este posibil să se evalueze dacă numerele loteriei sunt extrase aleatoriu printr-un test direct. Există peste 13 milioane de trageri echiprobabile, iar verificarea independenței între extrageri și aleatorismul în cadrul acestora ar necesita un număr nerealist de mare de extrageri. A se observa aici diferența dintre independență și aleatorism: tragerile ar trebui să fie independente între ele, dar în cadrul unei trageri, distribuția de probabilitate a, să spunem, celui de-al doilea număr, nu este independentă de primul număr extras.

Pentru sistemele de loterie de tipul k/N (de exemplu sistemul românesc 6/49), o întrebare ce survine în mod natural este dacă toate numerele care formează combinația câștigătoare apar cu o probabilitate egală. O preocupare similară este și caracterul aleatoriu al selecțiilor generate de algoritmii de randomizare, cum ar fi algoritmul „QuickPick”. Un mecanism de extragere, fie electronic sau mecanic, în lipsa acestui criteriu ar induce în mod clar inechitate și ar trebui revizuit. Pentru o testare amănunțită, o posibilă cale de urmat este și testarea faptului că toate subseturile a câte două (trei, patru, ș.a.m.d.) numere au aceeași probabilitate de apariție.

Literatura publicată și aplicațiile practice ale analizelor statistice pentru evaluarea aleatorismului loteriei au adoptat aproape exclusiv metode de inferență bazate pe frecvența de apariție, sub forma unor teste de tip „goodness-of-fit”, vezi Joe (1993), Haigh (1997) și Universitatea din Salford (2004-2005).

Pentru a determina dacă Loto 6/49 al României este o loterie „cinstită”, rezultatele n = 1504 extrageri (din 1993 până în 2016) au fost extrase de pe site-ul www.loto49.ro. Figura 17 afișează variabilitatea observată în apariția diverselor numere din combinația câștigătoare cu șase bile, pentru cele trei țări alese.

Probabilitatea de apariție a bilelor observată în loteriile din România (1), Canada (2) și Marea Britanie (3)

Pentru România, frecvențele minime și maxime observate au fost de 149 și 217, corespunzătoare bilelor 40 și respectiv 36 (fig.17-1).

Pentru a testa echiprobabilitatea a celor N numere individuale, o modalitate naturala de a continua este de a determina frecventa cu care numerele au avut loc în extrageri ale loteriei și apoi de a încerca compararea acestor frecvențe de apariție observate cu valoarea estimată a frecvențelor de apariție folosind statistica Pearson tradițională.

Folosind frecvența de apariție a bilelor de la 1 până la 49 observate în perioada 1993-2016, prezentate în fig.17-1, rezultatul pentru statisticile de testare și valoarea corespunzătoare sunt afișate în tabelul 1. Aceeași statistică de testare a fost calculată de asemenea, pentru loteria canadiană și cea britanică, în scop comparativ. Frecvența observată a apariției este prezentată în fig. 17-2 și 17-3, iar rezultatele comparative sunt de asemenea cuprinse în tabelul 11.

Rezultate observate ale frecvențelor de apariție (marginea/marja univariată)

Marja bivariată, este frecvența observată a perechii . Marja bivariată arată dacă numerele extrase, văzute ca perechi de două numere, sunt aleatoare.

Loteriile britanică, canadiană și cea română au fost testate pentru o marjă bivariată. Testele statistice au fost executate pentru extrageri (pentru loteriile britanică și canadiană) și pentru extrageri (pentru loteria din România), iar rezultatele sunt prezentate în tabelul 12.

Rezultate observate ale frecvențelor de apariție (marginea/marja bivariată)

Pentru toate sistemele de loterie analizate, ipoteza echidistribuirii nu poate fi respinsă la nivelul 5% (deoarece valoarea ) nici pentru seturile de numere individuale (marjă univariată), nici pentru perechi neordonate (marjă bivariată), sugerând că mecanismele de extragere folosite sunt corecte și implică faptul că numerele extrase, văzute ca perechi de numere individuale sau neordonate, sunt aleatorii.

Sistem de loterie electronică bazat pe scheme cu semnături anonime

Prin loterie corectă, în contextul prezentat în lucrarea [], autorii se referă doar la sistemul de loterie în care organizatorul loteriei nu cunoaște numerele pe care jucătorii le aleg înainte de momentul extragerii.

În cele ce urmează este prezentată proiectarea unui sistem echitabil de e-loterie bazat pe semnătura anonimă, având următoarele caracteristici:

Jucătorul poate participa la tragerea la sorți și păstrează în secret numerele pe care le-a ales;

Orice modificare a biletului electronic de către jucător după plasarea pariului trebuie să fie vizibilă și să alerteze loteria. De asemenea, nimeni nu poate să creeze un bilet câștigător sau să ia identitatea unui câștigător pentru a pretinde un premiu ce nu îi aparține;

Este nefezabil pentru loterie sau pentru o altă parte să determine numărul jucat înainte de faza de revendicare;

Loteria poate valida sau respinge biletele electronice revendicate printr-un mecanism sigur și fiabil [12].

Sistemul propus este compus din mai multe sisteme ce vor fi descrise mai jos în acest capitol. De obicei, sistemele de loterie electronică (i.e. e-lottery) utilizează primitive criptografice sigure pentru generarea de numere aleatoare. Un astfel de exemplu este propus de Konstantinou et al. în lucrarea [5].

Propunerea făcută în continuare încercă să îmbunătățească securitatea loteriilor tradiționale, dar în același timp încearcă să păstreze cât mai mult posibil din sistemul existent (cu scopul reducerii costurilor de implementare și pentru a face apel la jucătorii ce preferă loteriile clasice). Astfel, s-a presupus că generarea numerelor câștigătoare se face cu o mașină tradițională de extragere (folosind bile fizice marcate cu numere). Acest fapt permite folosirea unei combinații între sistemul tradițional de loterie și un sistem electronic. Sistemul propus permite jucătorilor să participe la loterie în mod tradițional (pe cupoane de hârtie), precum și să joace cu biletele electronice în mod anonim, dezvăluind numerele alese doar după extragere. În acest fel, loteria nu poate manipula numerele selectate în așa fel încât să evite acordarea de premii.

Componentele din schemă sunt prezentate mai jos, inclusiv rolul și responsabilitățile acestora.

(1) Jucător. Un jucător este o persoană care dorește să trimită cupoane în format electronic, numite în continuare e-cupoane, pe care își aleg numerele pentru a participa la extragere, înainte de termenul limită prestabilit. Jucătorul la e-loterie va deține o cartelă inteligentă („smartcard”) sigură ce conține credențialele jucătorului în scopul identificării și parametri critici de securitate (e.g. cheia privată). Perechea cheilor publică-privată este generată de jucător și este transmisă unui server „Registrar” împreună cu datele personale de identificare (nume, prenume, etc.).

(2) Autoritatea de Înregistrare. Autoritatea de Înregistrare (RA) este o entitate care stabilește un acord cu Autoritatea de Certificare pentru implementarea proceselor de înregistrare, identificare și autentificare a utilizatorilor pentru centralizarea datelor și verificarea identității și validitatea informațiilor privind certificatele de chei publice. RA înregistrează datele de identificare ale jucătorului și păstrează certificatul cu cheie publică a acestuia.

(3) Autoritatea de certificare. Autoritatea de Certificare (CA) este o entitate autorizată pentru crearea, semnarea, emiterea și gestionarea certificatelor cu chei publice. CA este alcătuită din hardware, software, personal și proceduri necesare pentru implementarea managementului ciclului de viață al certificatului, realizat de Politica de certificare. Certificatul cu chei publice al jucătorului, care include cheia publică, este semnat digital cu cheia privată a CA.

(4) Emitent de e-cupoane. Emitentul e-cuponului este un server de aplicații responsabil pentru gestionarea tranzacțiilor electronice legate de achiziționarea și procesarea de e-cupoane. Jucătorul inițiază o tranzacție obișnuită de plată electronică sigură, iar dacă această tranzacție se finalizează cu succes, serverul semnează e-cuponul și îi adaugă eticheta de timp („time-stamp”). Jucătorul poate verifica pe un Panou Electronic Public („Public Board”) dacă e-cuponul său a fost procesat și astfel va intra în concurs pentru următoarea extragere sau pentru cea la care s-a înscris.

(5) Cupon electronic (e-cupon). Formularul e-cuponului este o colecție electronică de date completată de jucător și transmisă către emitentul e-cuponului. Această colecție are un format predefinit și ar putea conține câmpuri de date diferite, de exemplu data extragerii, cantitatea de numere jucate și alte informații considerate relevante de loterie. Această colecție de date include semnătura anonimă a numerelor selectate, dar nu și numerele alese în orice format.

(6) Loteria – Mașina de extragere (LDM – „Lottery Draw Machine”) este orice mașină electrică sau mecanică existentă utilizată pentru extragerea de numere aleatorii dintr-un set predefinit. LDM publică numerele extrase pe Panoul Electronic Public (PB – „Public Board”), unde jucătorii pot vedea numerele câștigătoare și pot pretinde premiile. LDM poate fi îmbunătățită sau înlocuită cu orice combinație sigură de primitive criptografice pentru generarea de numere aleatorii.

Sistemul de e-loterie propus

(7) Panoul (electronic) Public (PB) este o bază de date publică (director public) unde jucătorii pot verifica starea e-cupoanelor lor. De asemenea, oricine poate verifica validitatea e-cupoanelor aferente extragerii curente, numărul de cupoane electronice vândute și corectitudinea e-cupoanelor câștigătoare. PB este responsabil pentru actualizarea informațiilor despre numerele câștigătoare, diverse informații și pentru sistemul de revendicare a premiilor. Prin utilizarea PB, premiul total este verificabil în mod public, deoarece fiecare e-cupon vândut este disponibil pe PB. Fiecare utilizator poate vizualiza și verifica e-cupoanele sale pe PB, și e-cupoanele semnate pot fi păstrate pentru a clarifica eventuale litigii. Biletele câștigătoare sunt verificabile public iar inserarea, ștergerea sau modificarea biletelor, după terminarea vânzării, nu este posibilă.

(8) E-Jeton (Jeton electronic sau „E-Token”) este o cartelă inteligentă („smart-card”) care stochează certificatul cu chei publice și cheia privată corespunzătoare. Sprijină și implementează infrastructura cu chei publice și execută calculele de criptografice și de securitate necesitate de sistemul de loterie electronică propus.

(9) Revendicare. Revendicarea este o colecție electronică de date înaintată de jucător către PB pentru a dovedi posesia unui e-cupon specific listat pe PB și pentru a confirma că semnătura anonimă furnizată emitentului de e-cupoane în faza de cumpărare corespunde cu numerele pretinse ce sunt cuprinse în revendicare.

Tabel comparative între sistemul deja existent și cel propus

În tabelul precedent sunt prezentate avantajele, dezavantajele și limitările sistemului propus și a celui deja existent.

Analiza securității

Schema de semnătură anonimă propusă în [XX] și prezentată în secțiunea precedentă, utilizează în plus și o schemă de criptare hibridă. Și anume, folosește o schemă Saraswat combinată cu această schemă de criptare hibridă pentru a obține caracteristicile dorite și un nivel de securitate suficient. Având în vedere faptul că numerele nu ar trebui să fie cunoscute înainte de revendicare, utilizarea numai a schemei Saraswat nu este suficientă, deoarece această schemă presupune că mesajul este în întregime public, dar numerele alese trebuie păstrate în secret până la faza de revendicare. Utilizarea schemei de semnături anonime Yang ar putea fi o alegere, însă nu este suficient de sigură deoarece folosirea numerelor selectate ca șir aleatoriu nu oferă suficientă securitate, deoarece este prea scurt [10].

De exemplu, în cazul sistemului de loterie 6 din 49, un număr ales de la 1 la 49 poate fi reprezentat de 6 biți. Rezultă că 6 numere pot fi reprezentate de 36 de biți. Șirul aleator din schema Yang reprezintă parametrul de securitate. Un atacator ar trebui să încerce exhaustiv toate combinațiile posibile de șir aleatoriu pentru a sparge anonimatul schemei. Este ușor de observat că un șir de lungime de 36 de biți nu poate oferi un nivel acceptabil de securitate. Pentru a atinge nivelul de securitate dorit, șirul de lungime de 36 biți trebuie concatenat cu 92 biți generați la întâmplare. În această propunere s-a considerat inadecvată și inutilă generarea și păstrarea în secret a acestor 92 de biți aleatorii și s-a considerat mai potrivită combinarea schemei Saraswat cu o schemă de criptare hibridă. Astfel, cuponul electronic, inclusiv numerele jucate, sunt semnate anonim și apoi sunt criptate. Semnătura rezultată este împărțită în două părți . De asemenea, cheia de criptare pentru algoritmul simetric este împărțită în două părți și . Numai mesajul criptat, semnătura anonimă și sunt publicate pe PB.

Fazele de: înscriere/înregistrare (1) și verificare/revendicare (2) ale sistemului propus

În faza de verificare/revendicare, jucătorul dezvăluie jetonul („token-ul”) de verificare și . Loteria poate valida revendicările și poate continua să acorde premiile. Toată lumea poate verifica, de asemenea, valabilitatea e-cupoanelor câștigătoare publicate pe PB. Un atacator nu poate afla nici identitatea jucătorului, nici numerele alese, deoarece nu are toată semnătura care să se potrivească cu fiecare combinație posibilă de numere și cu fiecare cheie publică posibilă.

Un exemplu numerotat al diagramei de evoluție a sistemului propus este prezentat în figura 319.

Pe diagramele prezentate în figura 19 există numere de la 1 la 11, atât pentru fazele de înscriere, cât și pentru cele de verificare. Acestea sunt intrări / ieșiri pentru diferiții pași din fluxul de procesare al sistemului propus. Faza de înscriere are loc înainte de momentul extragerii, iar faza de verificare are loc după momentul extragerii. Prima fază garantează anonimitatea numerelor jucate, iar a doua fază garantează validitatea cuponului.

Trebuie subliniat faptul că în faza înscrierii valoarea rezultată din pasul 11 (figura 319-1) este distribuită și către loterie, dar valoarea rezultată din pasului 9 trebuie păstrată în secret până în momentul revendicării premiului.

Bineînțeles, atât timp cât există îndoieli în ceea ce privește extracția numerelor, loteria poate complota cu anumiți jucători care vor juca niște numere alese ce urmează a fi extrase. Această situație poate fi evitată numai cu selectarea imparțială și cu adevărat aleatoare a numerelor. Pentru sistemul de loterie utilizat în prezent în România, a juca la loterie în mod anonim, fără a dezvălui numerele înainte de extragere, înseamnă o îmbunătățire substanțială a nivelului de încredere al jucătorilor, dar tot nu există certitudinea că jocul este corect în proporție de 100%.

Chiar dacă testele care au fost executate nu au dezvăluit nici o îndoială cu privire la aleatorismul numerelor extrase, s-a considerat că oferirea unei certitudini că loteria nu cunoaște numerele jucate înainte de extragere, poate îmbunătăți încrederea jucătorilor în aceasta, mai ales în perioadele îndelungate fără câștigător al marelui premiu sau în momentul unor combinații rare de numere extrase (e.g. 4 sau 5 numere consecutive, 2 extrageri identice consecutive etc.). În aceste momente apar zvonuri și acuzații cu privire la posibilitatea ca loteria să controleze cumva extragerea. Aceste zvonuri au efectul negativ de a reduce numărul de jucători și bine înțeles veniturile loteriei.

Pentru a îmbunătăți securitatea sistemului propus de e-loterie, eliberarea semnăturii anonime ar putea fi realizată prin utilizarea unei scheme „de angajament” („commitment scheme”). Astfel, anonimitatea schemei propuse ar fi mult îmbunătățită. De asemenea renunțarea la mașinile electro-mecanice de extragere a numerelor și înlocuirea acestora cu sisteme electronice bazate pe primitive criptografice generatoare de numere aleatorii, poate asigura participanții la loterie că extragerea numerelor s-a făcut în mod pur aleatoriu, lucru ce poate fi demonstrat și matematic.

– Sisteme publice de gestiune a informațiilor cu caracter personal – GDPR

Sistemul electronic național al asigurărilor de sănătate

În urma unui ordin executiv al ministrului sănătății (645/2007), planul de introducere în România a unui sistem electronic de gestiune al asigurărilor și asiguraților în domeniul sănătății a fost aprobat. A durat câțiva ani pentru a ajunge la o soluție funcțională și în 2015 sistemul a devenit operațional și disponibil publicului.

Compunerea sistemului

Sistemul național al asigurărilor de sănătate este un sistem complex compus din mai multe elemente astfel:

Sistemul Informatic Unic Integrat – SIUI;

Prescripția Electronică – PE;

Cardul Electronic de Asigurări de Sănătate – CEAS;

Furnizorii de Servicii de Sănătate – FSS;

Aplicațiile de Raportate – RA.

Cea mai importantă componentă a sistemului național a asigurărilor este Sistemul Informatic Unic Integrat sau prescurtat SIUI. Acesta are rolul de a colecta, consolida și de a procesa în mod eficient informațiile din întregul sistem național al asigurărilor de sănătate. Scopul principal al SIUI este de a ajuta furnizorii naționali de asigurări de sănătate să își îndeplinească sarcinile specifice de management al bugetului alocat asigurărilor de sănătate. Acesta are o structură ierarhică împărțită pe trei niveluri principale:

Nivelul național;

Nivelul județelor (inclusiv sistemul național de apărare);

Nivelul furnizorilor de servicii de sănătate.

Structura SIUI este reprezentată în figura 1.

Funcțiile principale ale SIUI sunt gestionarea bugetului asigurărilor de sănătate, gestionarea persoanelor asigurate, menținerea unei evidențe a furnizorilor de servicii de sănătate (medicale și farmaceutice), menținerea unei evidențe a contribuțiilor la bugetul asigurărilor de sănătate și asigurarea de control al calității pentru sistemul asigurărilor de sănătate. Datele provenite de la furnizorii de servicii de sănătate (FSS) sunt colectate și analizate local de nivelul 2 (figura 1) al structurii ierarhice a SIUI, la nivel de județ si după aceea sunt centralizate și stocate la nivelul central (național).

În dezvoltarea acestui sistem șapte obiective principale au fost urmărite:

Colectarea și managementul informațiilor economice și medicale necesare operării eficiente a sistemului asigurărilor de sănătate;

Transparența în utilizarea și managementul bugetului asigurărilor de sănătate de către sistemul național de asigurări de sănătate;

Menținerea unei evidențe a asiguraților și a furnizorilor de servicii de sănătate prin crearea și administrarea registrelor naționale ale asiguraților de sănătate și ale furnizorilor de servicii de sănătate;

Simplificarea raportării datelor de către FSS;

Standardizarea în aplicarea normelor și legilor în vigoare la nivel național;

Controlul și evidențierea costurilor pentru fiecare persoană asigurată;

Interfațarea cu alte entități din afara sistemului, altele decât FSS, în mod online și offline.

Beneficiile implementării unui astfel de sistem sunt evidente și intuitive.

Structura ierarhică a Sistemului Informatic Unic Integrat

Interfațarea Sistemului Informatic Unic Integrat

SIUI asigură interfețe de comunicații cu exteriorul prin care se poate face transferul informațiilor către alte entități din afara sistemului. Aceste interfețe se împart în două categorii principale:

Interfețele cu Furnizorii de Servicii de Sănătate (medicale sau farmaceutice);

Interfețele cu alte entități.

Scopul principal al interfațării cu FSS este ca aceștia să poată raporta serviciile furnizate astfel încât asiguratorul să poată plăti respectivii FSS pentru serviciile prestate. De asemenea aceste interfețe sunt folosite pentru a transporta informații legate de eliberarea prescripțiilor medicale, concedii medicale sau alte documente care pot fi emise de un furnizor de servicii medicale. Se mai pot schimba și alte tipuri de informații peste aceste interfețe, dar acestea depind de contractele individuale pe care fiecare FSS le-a încheiat cu casa de asigurări de sănătate.

Utilizatorul (indiferent cine este acesta, FSS, instituție, etc.), face raportarea sau primește detalii din SIUI prin intermediul Aplicațiilor Electronice de Raportare (AER). Aceste aplicații se conectează la resursele SIUI folosind protocolul https/SSL (figura 2).

SIUI oferă, de asemenea, posibilitatea de a valida prescripțiile online sau de a verifica în timp real dacă un client este intr-adevăr asigurat. Această opțiune a fost implementată pentru a evita situația când un client, un serviciu sau echipament medical sau farmaceutic nu este acoperit de asigurare. Bine înțeles această facilitate a SIUI folosește interfațarea sistemului cu FSS.

Interfețele SIUI cu alte entități sunt definite în concordanță cu protocoalele/acordurile acelor entități cu sistemul național al asigurărilor de sănătate și sunt folosite pentru a obține și a furniza datele necesare pentru buna funcționare a acelor entități precum și a sistemului național al asigurărilor de sănătate. Câteva exemple de astfel de entități pot fi instituțiile care mențin evidența populației, instituții antifraudă, instituții financiare, ministere, trezoreria, primării, etc. (figura 1).

Conectarea aplicațiilor de raportare al Sistemul Informatic Unic Integrat

Securitatea informațiilor în Sistemul Informatic Unic Integrat

Pentru a asigura securitatea informațiilor tranzitate între aplicațiile de raportare și Sistemul Informatic Unic Integrat, în cadrul acestui proiect a fost implementată o infrastructură cu chei publice (PKI – „Public Key Infrastructure”) concepută să funcționeze cu certificate digitale emise de autorități de certificare bine cunoscute și aprobate.

Infrastructura cu chei publice PKI (figura 3), tehnicile și metodologia care contribuie în mod colectiv la implementarea și operarea ciptosistemelor cu chei publice sunt alcătuite din hardware, software, baze de date, resurse de rețea, proceduri de securitate și obligații legale. Aceste elemente sunt „legate” între ele și colaborează pentru implementarea și asigurarea serviciilor de securitate precum și a altor servicii asociate infrastructurii PKI, cum ar fi timbrele/marcherii de timp („timestamps”).

Certificatele digitale sunt în permanență verificate și validate. Procesul verificării este aplicat periodic de autoritatea de certificare prin metoda verificării statusului revocării unui certificat („certificate revocation”). Autoritatea emite și încarcă periodic sau ori de câte ori este nevoie un fișier CRL – „Certificate Revocation List”, care conține o listă cu seriile certificatelor care din diverse motive obiective au fost revocate. Motivele pentru care un certificat poate fi revocat sunt multiple. Acestea pot fi:

Certificatul a fost compromis;

Deținătorul nu mai este eligibil;

Echipamentele au fost înlocuite;

Deținătorului a solicitat expres asta;

Informațiile conținute în certificat nu mai sunt valabile;

Diverse cauze legale;

Astfel orice entitate din PKI care primește un certificat cu o solicitare de autentificare va verifica prima dată lista conținută în fișierul CRL și numai în cazul când seria certificatului primit nu se regăsește în acea lista va accepta certificatul ca fiind valid.

Verificarea unui certificat digital în SIUI este realizată și folosind protocoale de verificare online a certificatelor. Un astfel de protocol, care este implementat în SIUI, este „Online Certificate Status Protocol” sau OCSP, definit în RFC2560.

Arhitectura de securitate a Sistemului Informatic Unic Integrat

Folosind OCSP aplicațiile nu mai trebuie să descarce periodic fișierul CRL, care poate fi foarte lung, și să verifice fiecare certificat primit contra acestei liste. Folosind OCSP aplicațiile vor înainta online o cerere către un server/serviciu OCSP prin care se solicită verificarea certificatului în cauză (figura 3).

Certificatele digitale vor fi mânuite folosind o bază de date dedicată administrată la nivelul 2 (conform figurii 1) al structurii ierarhice a SIUI. Aplicațiile de raportare vor folosi certificatele digitale pentru a autoriza și autentifica cererile online către SIUI folosind suita de protocoale https/SSL (figurile 2 și 3).

Pentru a accesa resursele SIUI, toți FSS vor necesita certificate digitale emise de autoritățile de certificare menționate anterior. De asemenea acele certificate vor trebui înregistrate în SIUI pentru ca aplicațiile de raportare să fie acceptate și să funcționeze. Tot ca măsură de securitate, se vor defini conturi de utilizatori pentru fiecare operator al fiecărui FSS. Acest lucru va asigura funcția de autorizare a fiecărui operator al aplicațiilor de raportare. Și desigur va asigura, printre altele, și mecanismul de non-repudiere al acțiunilor operatorilor.

Poarta de acces în SIUI este protejată de un firewall hardware care asigură și funcția de accelerator SSL și de echilibrare a încărcării („load balancer”). În același timp acest echipament verifică validitatea și integritatea certificatelor digitale prezentate de aplicațiile de raportare la inițierea unei noi sesiuni SSL.

După verificare integrității și validității certificatelor, acceleratorul SSL înaintează cererea prin http către serverele de autorizare și autentificare (servere reprezentate grafic în figura 3). În headerul http acceleratorul SSL introduce și informații legate de certificatul digital în cauză. Aceste informații vor fi folosite de servere pentru a face încă o evaluare a statusului certificatului prin SCSP. Serverele de autorizare vor verifica în baza de date dacă certificatul digital a fost înaintat de un utilizator autorizat al sistemului. Dacă utilizatorul a fost validat, serverul înaintează o cerere OCSP prin intermediul serviciilor asigurate de STS – „Serviciul de Telecomunicații Speciale” pentru a verifica statusul revocării certificatul digital la autoritățile de certificare publice menționate anterior.

STS folosește ca parte a serviciul o componentă care permite interogarea simultană a tuturor autorităților de certificare publice din România. Prin această metodă consecințele schimbării structurii sau indisponibilizării unei autorități de certificare sunt evitate.

Dacă în urma cererii OCSP rezultă că certificatul este în regulă, serverele de autentificare vor verifica într-o bază de date tampon statusul contractului cu respectivul FSS. Dacă și în urma acestei verificări va rezulta că totul este în regulă, serverul va trimite un token software către aplicația de raportare. Acest token este numit „session-id-hash” și va fi folosit de aplicația de raportare pentru a confirma că sesiunea a fost deja autorizată, în cazul când va emite cereri ulterioare în cadrul aceleiași sesiuni. În acest fel va fi evitată situația repetării lanțului complet al autorizării sesiunii pentru fiecare cerere lansată de aplicația de raportare în cadrul unei singure sesiuni. De asemenea, folosind această metodă se va accelera procesul de operare al aplicațiilor de raportare iar serverele de autentificare/autorizare nu vor fi copleșite cu cereri de verificare, lucru care ar duce la încetinirea întregului sistem.

Semnăturile digitale în Sistemul Informatic Unic Integrat

O semnătură digitală este reprezentată de o cantitate adițională de informații ce se atașează unui document electronic și care are aceeași semnificație ca o semnătură de mână pe un document în format hârtie. Semnatarul este acea persoană sau entitate care are dispozitivele și/sau software-ul necesare pentru a crea o semnătură care poate acționa în nume propriu sau ca reprezentant al unei terțe părți.

La fel ca semnătura de mână pe un document în format hârtie, semnătura digitală dovedește posesia unui document electronic, dar în plus oferă destinatarului posibilitatea de a verifica dacă documentul a suferit alterări sau modificări, fie acestea accidentale sau intenționate.

Pentru a genera o semnătură digitală, semnatarul necesită un certificat digital a cărui emitere corespunde criteriilor menționate anterior. Certificatul „leagă” semnătura digitală de persoana sau entitatea care a generat acea semnătură.

Pentru a se asigura non-repudierea datelor raportate în SIUI, toate fișierele încărcate trebuie să fie semnate folosind semnătura digitală a semnatarului. Semnând electronic aceste fișiere se generează premisele automatizării complete a sistemului de asigurări de sănătate și a simplificării procedurilor prin eliminarea folosirii documentelor fizice din hârtie.

Sistemul menține o evidență a tuturor fișierelor raportate, indiferent dacă semnătura a fost validată sau nu. Raționamentul din spatele acestui comportament este acela de a avea întotdeauna justificarea unei posibile revocări a unei cereri, atunci când este necesară justificarea unei decizii luate de sistem.

– Propunere de îmbunătățire a sistemelor publice de gestiune a informațiilor cu caracter personal

Analiză privind vulnerabilitățile de securitate ale Sistemului Informatic Unic Integrat privind confidențialitatea datelor cu caracter personal

Ca orice sistem informatic (IT), și SIUI ridică anumite semne de întrebare în legătură cu securitatea informațiilor. Prin folosirea în special a protocoalelor de securitate și a mecanismelor criptografice demonstrate și acreditate, SIUI poate fi considerat că are un nivel acceptabil de securitate, mai ales când vine vorba de metodele de atac bine cunoscute, mediatizate și analizate. Principala vulnerabilitate a SIUI derivă din faptul că o bună parte din conexiunile între aplicațiile de raportare și sistem sunt realizate pe suportul Internetului. Deși măsurile de securitate implementate asigură o bună protecție împotriva atacurilor de tipul „packet sniffing”, „man-in-the-middle”, a tentativelor de decriptare a traficului sau de a impersona un utilizator legitim, sistemul este în continuare vulnerabil la atacuri cum ar fi „denial of service” (interzicerea/blocarea accesului la servicii). Motivul principal al acestei aprecieri este că Internetul este „deschis” întregii planete și orice persoană sau entitate rău intenționată poate să inițieze un atac de tip „denial of service” cum ar fi atacurile de „sufocare” a lățimii de bandă („bandwidth attack”). Folosind un astfel de atac, atacatorul nu va penetra sistemul sau modifica/citi traficul, dar acesta va putea bloca cu succes procesul de stabilire a sesiunilor SSL ale aplicațiilor de raportare prin ocuparea întregii benzi disponibile cu traficul atacatorului.

Atacurile de blocare a benzii au de obicei succes împotriva oricărui sistem IT conectat la Internet si sunt destul de puține metode de a contracara aceste tipuri de atac. Cea mai eficientă metodă de luptă împotriva acestor tipuri de atac este de a conecta sistemul la mai mulți furnizori de serviciu Internet. Această metodă nu asigură protecție totală împotriva atacurilor de blocare a benzii, dar va ridica foarte mult costul atacului, deoarece atacatorul va fi nevoit să angajeze substanțial mai multe resurse pentru a efectua atacul.

În urma analizei acestui sistem a fost descoperită o altă posibilă vulnerabilitate de securitate a acestui sistem. Datele stocate de SIUI conțin foarte multe informații despre utilizatorii si asigurați. Aceste tipuri de informații pot fi:

Informații medicale;

Informații generale despre asigurarea de sănătate;

Informații ce pot identifica utilizatorii și asigurații;

Informații despre starea de sănătate a asiguraților;

Alte tipuri de informații ce intră în categoria informațiilor cu caracter personal.

Toate informațiile cu caracter personal sunt protejate prin lege, mai ales în contextul implementării în Uniunea Europeană a pachetului de legi cunoscut sub denumirea „General Data Protection Regulation” sau GDPR prescurtat. GDPR reprezintă o serie de regulamente europene cu privire la protecția datelor confidențiale și la protecția dreptului la viață privată a indivizilor din Uniunea Europeană și din zona economică Europeană (EEA).

Atunci când sunt stocate în sistem aceste informații sunt relativ bine protejate, dar după cum se poate observa în figura 1, SIUI este interconectat cu alte entități prin intermediul interfețelor externe. De exemplu una din instituțiile care necesită informații din SIUI este Institutul Național de Statistică – INS. Acesta folosește informațiile din SIUI pentru a calcula rapoarte statistice detaliate despre multe caracteristici ale sistemului național de sănătate. Aceste rapoarte pot include statistici despre folosirea diferitelor tipuri de medicamentație, despre concediile medicale, despre prevalența anumitor tipuri de boli, etc.. Pentru a genera aceste statistici INS are nevoie de informațiile generate de aplicațiile de raportare, cum ar fi prescripțiile electronice, rapoartele medicale, eliberarea de medicamente, etc.. Dar aceste rapoarte conțin de asemenea și informații ce pot fi folosite pentru a identifica indivizii pentru care au fost emise precum și informații despre istoricul medical al acestora. Și conform legilor mai sus menționate aceste tipuri de informații sunt confidențiale și protejate și astfel accesul la acestea trebuie să fie limitat. Continuând cu exemplul de mai sus, pentru generarea rapoartelor statistice INS nu necesită aceste tipuri de informații de identificare, ci numai conținutul documentelor medicale.

De asemenea conform celor mai bune practici, din punctul de vedere al securității, orice sistem extern sistemului propriu trebuie considerat ca fiind de neîncredere [6] și astfel trebuie luate măsuri de protecție la interfața cu un astfel de sistem.

Având acestea în vedere datele cu caracter personal protejate din SIUI trebuie protejate, mai ales când părăsesc sistemul. Dar trebuie să existe și un mecanism de a extrage în siguranță aceste informații atunci când apare o astfel de cerință.

Pentru a satisface aceste cerințe, în acest raport s-a cercetat posibilitatea introducerii semnăturilor digitale anonime în Sistemul Informatic Unic Integrat.

Introducerea semnăturilor digitale anonime în Sistemul Informatic Unic Integrat

Soluția cercetată în acest raport implică introducerea semnăturilor digitale anonime în procesul de generare a rapoartelor din SIUI.

Pentru a genera un raport sau pentru a căuta un raport in sistem, aplicațiile de raportare folosesc date de identificare. Aceste date sunt numele asiguratului, codul numeric personal al asiguratului (CNP), seria și numărul raportului și, după caz, numărul de ștampilă al medicului. După ce medicul completează un raport, cum ar fi o prescripție medicală, cu tratamentul recomandat și informațiile de identificare menționate anterior, acesta o validează în sistem și o semnează cu semnătura digitală proprie. După aceasta sistemul o stochează. Pentru a accesa datele despre statutul de asigurare al pacientului, medicul folosește Cardul Electronic de Asigurare de Sănătate – CEAS al pacientului care conține perechea de chei a pacientului și certificatul digital al acestuia. Când pacientul ajunge la o farmacie pentru a ridica tratamentul recomandat de medic, farmacistul fie scanează codul de bare de pe prescripția în format hârtie a pacientului (pe care a printat-o medicul după ce a fost validată și stocată în sistem), fie caută prescripția după informațiile de identificare ale pacientului. Și farmacistul va căuta în sistem statusul de asigurare al pacientului folosind datele stocate pe cardul de sănătate CEAS al pacientului.

O posibilă vulnerabilitate identificată este reprezentată de faptul că prescripția electronică este stocată în sistem având informațiile de identificare ale utilizatorului în clar la fel ca informațiile despre diagnostic și tratamentul asociat. Vulnerabilitatea este și mai mare atunci când aceste informații sunt transmise către o altă instituție din afara sistemului național al asigurărilor de sănătate (e.g. Institutul Național de Statistică sau alte instituții similare).

O posibilă soluție la această vulnerabilitate este aplicarea semnăturilor digitale anonime în SIUI. Această soluție este obiectul principal al acestui raport de cercetare.

Ideea este de a avea un dosar electronic pentru fiecare asigurat de sănătate. Acest dosar va conține toate documentele eliberate pe numele respectivului asigurat și toată evidența medicală a acestuia. Fiecare document medical eliberat pe numele respectivului beneficiar va fi adăugat la dosarul electronic propriu. Dosarul nu va conține nici un fel de informații de identificare, ci va fi semnat cu o schemă cu semnături anonime Saraswat generată folosind informațiile stocate pe cardul personal de sănătate CEAS al asiguratului. Această metodă va putea dovedi de asemenea, la nevoie, identitatea posesorului acelui dosar.

În partea de aplicații de raportare (aplicații care generează documentele medicale și farmaceutice care vor fi atașate la dosarul electronic al asiguratului), toate documentele electronice generate (e.g. prescripțiile electronice) vor avea numele și codul numeric personal șterse sau criptate (folosind cheia publică a asiguratului de pe cardul de sănătate) de către software-ul aplicației. Fiecare document eliberat va fi adăugat dosarului electronic al asiguratului după ce va fi validat din punct de vedere al asigurării de sănătate conform procedurilor deja existente și implementate în SIUI. La adăugarea unui document nou la dosarul electronic, sistemul va șterge vechea semnătură și o va regenera incluzând ultimele modificări suferite de dosar (i.e. adăugarea noului document electronic). Cum era de așteptat semnătura vă fi generată folosind informațiile stocate pe cardul electronic de sănătate CEAS.

Eliminarea sau criptarea numai a numelui și a codului numeric personal din câmpurile documentelor electronice generate este esențială deoarece celelalte informații (diagnostic, tratament prescris, etc.) vor fi folosite pentru și în alte scopuri, cum ar fi generarea de rapoarte statistice, sau pentru a fi trimise către alte entități sau instituții din afara sistemului. Din această cauză aceste informații trebuie să fie disponibile în clar iar datele de identificare trebuie să fie protejate.

Aplicarea schemei cu semnături anonime va rezulta în generarea unei semnături și a unui token de verificare, care va putea fi folosit ulterior pentru a verifica semnătura și pentru a demonstra, dacă acest lucru va fi necesar, identitatea posesorului dosarului electronic. Token-ul de verificare va fi stocat pe CEAS și va fi actualizat ori de câte ori se vor procesa modificări la dosarul electronic al asiguratului.

Dosarul fiecărui asigurat va fi stocat pe serverele de baze de date (figura 2). Semnătura va fi generată de un server de aplicație împreună cu aplicația de raportare.

Prin adăugarea de semnăturii anonime, modul de operare al sistemului nu va fi drastic modificat. Modul de operare al sistemului a fost prezentat în capitolele precedente iar adăugarea semnăturii anonime se adaugă acestuia conform diagramei grafice din figura 4.

Diagrama grafică a procesului de adăugare a semnăturii anonime

De exemplu pentru ca un farmacist să elibereze o rețetă, acesta (i.e. aplicația de raportare a farmaciei) va căuta în baza de date acea rețetă folosind seria și numărul acesteia. După ce o va găsi, aplicația farmaciei va verifica validitatea dosarului ce conține acea rețetă, folosind token-ul de verificare stocat pe CEAS al asiguratului respectiv, conform diagramei grafice de verificare a semnăturii prezentată în figura 5. Dacă procesul de verificare este finalizat cu succes, farmacistul va putea elibera medicamentele prescrise din rețetă. După aceasta, aplicația de raportare a farmaciei va trebui să aducă modificări la dosarul asiguratului prin marcarea rețetei ca fiind eliberată, putând în felul acesta să-și deconteze serviciile de la sistemul național de asigurare de sănătate. Procesul de semnare cu semnătură anonimă a dosarului asiguratului vă trebui reluat, iar noul token de verificare va fi stocat pe CEAS al asiguratului, înlocuind pe cel vechi.

Diagrama grafică a procesului de verificare a semnăturii anonime

Vom nota ca fiind dosarul asiguratului. Astfel putem scrie că , unde este numărul al documentului care a fost adăugat dosarului. Vom avea de asemenea perechea de chei generată de algoritmul de generare a cheilor, unde este cheia publică a asiguratului iar este cheia privată/secretă a acestuia. Perechea este stocată pe CEAS personal al asiguratului. Aplicând schema cu semnături anonime va fi generat , unde este partea din semnătură care va fi adăugată dosarului și este token-ul de verificare stocat pe CEAS, care va fi folosit pentru verificarea semnăturii. Astfel vom avea , ceea ce reprezintă dosarul semnat ce va fi stocat în baza de date.

În faza de verificare sistemul va trebui să calculeze i.e.:

(23)

Dacă rezultatul lui (23) este adevărat pentru orice și pentru perechea de chei generate inițial, putem concluziona că dosarul aparține cu adevărat celui care pretinde acest lucru și că nu a fost modificat sau alterat între timp.

Schema pas cu pas al procesului de semnare se regăsește în diagrama din figura 5.

Analiza securității soluției cercetate

Schema de semnături anonime propusă pentru acest raport de cercetare folosește o schemă Saraswat care poate fi combinată cu un algoritm de criptare asimetric. Schema de semnături anonime este folosită pentru a proteja identitatea asiguratului și pentru a semna dosarul electronic stocat în SIUI al acestuia. Asigură de asemenea non-repudierea și integritatea dosarului electronic. Algoritmul de criptare asimetric nu este neapărat necesar, dar acesta poate asigura criptarea (în loc de ștergerea) informațiilor de identificare ale asiguratului (nume și CNP) pentru fiecare document electronic din dosarul electronic al asiguratului, asigurând astfel o plajă mai mare de opțiuni fără a compromite securitatea. De menționat este faptul că în pasul de verificare algoritmul de criptare asimetric nu este necesar (figura 5).

În faza de semnare (figura 4), un procesor de dosare șterge vechea semnătură anonimă și adaugă noile documente la dosar. Noul document este trecut prin procesul de semnare anonimă și o nouă semnătură este generată, care este adăugată dosarului de procesor. Semnătura este apoi împărțită în două părți, , de către procesorul semnăturii. este apoi folosită pentru a semna dosarul și va fi stocat pe CEAS al asiguratului si folosit ulterior în procesul de verificare. La ultimul pas al procesului de semnare, noul dosar semnat este stocat pe serverele de baze de date, fapt care finalizează procesul de semnare.

În faza de verificare (figura 5), procesorul de dosare va separa semnătura și dosarul asiguratului. Dosarul nesemnat va fi trecut din nou prin procesul de semnare iar semnătura va fi păstrată și împreună cu tokenul de pe CEAS vor forma semnătura originală completă . Noul proces de semnare va genera o nouă semnătură anonimă care va fi comparată cu semnătura originală . Dacă vor fi identice (i.e. ), se poate concluziona că dosarul aparține într-adevăr celui care îl pretinde și că acesta nu a fost modificat între timp.

Implementarea schemelor anonime în Sistemul Informatic Unic Integrat va permite de asemenea ca dosarele asiguraților să fie transmise în siguranță către entități externe sistemului, fără a fi compromisă confidențialitatea persoanelor asigurate, respectând astfel normele și regulamentele naționale și europene cum ar fi GDPR. Entitățile destinatare externe sistemului nu vor putea identifica posesorii dosarelor primite, dar vor putea folosi informațiile medicale din acestea în scopul atingerii obiectivelor și misiunilor proprii.

– (Opțional/Ideal) Implementarea sistemului

Subcapitol

Subsubcapitol

Subcapitol

Subsubcapitol

Subsubcapitol

Concluzii

Bibliografie

x

x

Bibliografie

x

x

Glosar termeni și anexe

Glosar termeni:

Anexa nr. 1: Rezultate obținute la testul PING în varianta fără criptare

Anexa nr. 2: Rezultate obținute la testul PING cu criptare DES

Anexa nr. 3: Rezultate obținute la testul PING cu criptare DES

Anexa nr. 3: Rezultate obținute la testul PING cu criptare AES cu cheie pe 128 biți

Anexa nr. 4: Rezultate obținute la testul PING cu criptare AES cu cheie pe 192 biți

Anexa nr. 5: Rezultate obținute la testul PING cu criptare AES cu cheie pe 256 biți

Anexa nr. 6: Rezultate obținute la testul voce cu codec vocal G.729r8

Anexa nr. 7: Rezultate obținute la testul voce cu codec vocal G.711

Anexa nr. 7: Rezultate obținute la testul TFTP eșantion 1 Mb

Anexa nr. 8: Rezultate obținute la testul TFTP eșantion ~6,38 Mb

Anexa nr. 9: Rezultate obținute la testul FTP eșantion 1 Mb