UNIVERSITATEA POLITEHNICA DIN BUCUREŞTI

FACULTATEA DE ŞTIINŢE APLICATE

Programul de studii: TCSI

Aprobat Decan,

Prof. Univ. Dr. Petrescu Emil

LUCRARE DE DISERTAŢIE
Concepte în vederea securizării bazelor de date

COORDONATOR ŞTIINŢIFIC,

Prof. Dr. Andrei Oprina

MASTERAND,

Florescu Ionuț-Adrian

Bucureşti
2019
CUPRINS
INTRODUCERE

CAPITOLUL I
ASPECTE PRIVIND SECURITATEA UNEI BAZE DE DATE
1.1 Privilegii
1.2 Vulnerabilități
1.3 Auditul și expunerea datelor
1.4 Aspecte privind serverul unei baze de date

CAPITOLUL II
ALGORITMUL BLOWFISH ȘI METODA SALT
2.1 Introducere
2.2 Algoritmul de criptare BLOWFISH
2. Metoda de criptare Salt

CAPITOLUL III
APLICAȚIA DE GESTIUNE ANALIZE

CONCLUZII

BIBLIOGRAFIE

2
INTRODUCERE
În lucrarea de față, se urmărește dezvoltarea unei platforme ce conține o bază de date
securizată pentru schimbul de date.

Întotdeauna, informația a jucat un rol esențial în societate, ea fiind comparată ca valoare cu

petrolul sau aurul.
În momentul de față, majoritatea informației este ținută în anumite baze de date (SQL Server,
Oracle, MySQL). Informația este scrisă în aceste baze de date prin intermediul diferitelor
aplicații. Un depozit de date (DataWarhouse) conține datele existențiale din suita de aplicații a
unei firme multinaționale, de exemplu. Procesul prin care datele se aduc în depozit se numește
ETL (Extract, Transform, Load). Anumite companii și instituții dețin și depozite de BigData,
unde sunt prezente date din diferite ecosisteme. De exemplu, compania Facebook tranzitează
zilnic către BigData în jur de 500 de TB. Aceste date le permit să efectueze analize complexe
despre comportamentul utilizatorului și să previzioneze anumite trenduri și evenimente.
Așadar, consider faptul că este obligatoriu ca aceste date să fie securizate încă din momentul
intrării în aplicația primară (de exemplu, un soft ERP, de Marketing sau HR).

Website
Pentru dezvoltarea software-ului, este necesar ca acesta să se adreseze si să aibă ca țintă un
număr cat mai mare de oameni. Astfel, pentru a face acest lucru posibil, trebuie să existe cel
puțin un program disponibil pentru toate cele trei sisteme de operare importante: Windows,
Linux și Mac OS.
De asemenea, software-ul ar trebui sa fie destinat si sistemelor de operare Android, iOS și
Windows Phone, pentru a oferi utilizatorului posibilitatea de accesare a software-ului de pe
telefonul mobil. Acest fapt presupune dezvoltarea si mentenanța a șase aplicații. Prin selectarea
unui limbaj de programare adecvat, precum Java sau C ++, efortul dezvoltării mai multor
programe poate fi minimizat (avantajul acestor limbaje de programare este că pot fi ușor portate,
sau necesita doar compilare).
Dezavantajul este acela ca funcționează numai pentru sistemele de operare desktop, nu si
pentru sistemele de operare mobile. Spre exemplu, software-ul Android este programat în Java,
iar iOS, în Swift (C). Schimbul de cod între aceste două platforme este mai dificil decât pentru
sistemele desktop.

3
CAPITOLUL I
ASPECTE PRIVIND SECURITATEA UNEI BAZE DE DATE

1.1 Privilegii

Privilegii excesive
Atunci când utilizatorilor (sau aplicațiilor) li se acordă privilegii la baza de date care
depășesc cerințele funcției lor, aceste privilegii pot fi folosite pentru a avea acces la
informații confidențiale. De exemplu, un administrator de la o universitate a cărui loc de
muncă necesită acces numai în citire pentru înregistrările studenților, poate beneficia de
privilegii de actualizare pentru a schimba notele. Soluția acestei probleme (pe lângă politicile
de angajare bune), este controlul accesului la nivel de interogare. Acesta din urma
restricționează privilegiile la operațiile și datele minime necesare. Cele mai multe platforme
de securitatea a bazelor de date oferă unele dintre aceste specificații (declanșatoare, RLS
etc.), dar proiectarea manuală a acestor instrumente le face impracticabile în toate
implementările, cu excepția acelora mai limitate.

Abuz de privilegii

Utilizatorii pot abuza de privilegiile legale de acces la date, în scopuri neautorizate. De

exemplu, un utilizator cu privilegii in vizualizarea înregistrărilor individuale ale pacientului,
printr-un client particularizat al aplicației de asistență medicala, poate abuza de acest
privilegiu pentru a prelua toate înregistrările pacienților. Soluția este o politică de control al
accesului care se aplică nu numai la datele accesibile, ci și la modul în care sunt accesate
datele. Prin impunerea politicilor pentru ora din zi, locația, clientul, și volumul de date, este
posibil să se identifice utilizatorii care abuzează de privilegiile de acces.

Creșterea privilegiilor neautorizate

Se poate profita de vulnerabilitățile din software-ul de gestionare a bazelor de date pentru a

transforma privilegiile de acces la nivel inferior, la privilegii de acces la nivel înalt. De
exemplu, se poate profita de vulnerabilitatea unui buffer overflow pentru a obține privilegii
administrative. Exploatarea numărului mare de privilegii poate fi învinsa cu o combinație
dintre controlul accesului la nivel de interogare și sistemele tradiționale de prevenire a

4
intruziunilor (IPS). Controlul accesului la nivel de interogare poate detecta un utilizator care
utilizează brusc o operație SQL neobișnuită, în timp ce un IPS poate identifica o amenințare
documentată specifică în cadrul operației.

1.2 Vulnerabilități

Vulnerabilitățile platformei

Vulnerabilitățile din sistemele de operare de bază pot duce la accesul neautorizat la date și
corupție. De exemplu, viermele Blaster a profitat de vulnerabilitatea Windows 2000 pentru a
prelua serverele țintă. Instrumentele IPS reprezintă o modalitate bună de a identifica și / sau
de a bloca atacurile concepute pentru a exploata vulnerabilitățile cunoscute ale platformei
bazei de date.

SQL injection

SQL injection implică existenta unui utilizator care profită de vulnerabilitățile aplicațiilor
web front-end și procedurile stocate pentru a trimite interogări neautorizate de baze de date,
adesea cu privilegii ridicate. Folosind SQL injection, atacatorii ar putea chiar să obțină acces
nelimitat la o întreagă bază de date. Controlul accesului la nivel de interogare detectează
interogările neautorizate in aplicații web și / sau proceduri stocate.

Refuzul serviciului

Refuzul serviciului (DoS) poate fi invocat prin mai multe tehnici. Tehnicile comune DoS
includ coruperea datelor, network leakage și consum de resurse. Acestea din urma sunt
adesea trecute cu vederea.

Protecția DoS ar trebui să aibă loc in mai multe straturi, inclusiv rețeaua, aplicațiile și
bazele de date.

Recomandările legate de baza de date, includ implementarea unui control IPS și a ratei
conexiunii. Prin deschiderea rapidă a unui număr mare de conexiuni, controalul ratei
conexiunii poate împiedica utilizatorii individuali să consume resurse de server de baze de
date.

5
Autentificare slabă

Schemele de autentificare slabe permit atacatorilor să-și asume identitatea utilizatorilor

legitimi ai bazelor de date.

Implementarea parolelor sau autentificarea cu doi factori este o necesitate. Pentru

scalabilitate și ușurință în utilizare, mecanismele de autentificare ar trebui să fie integrate cu
infrastructura de gestionare a directorului / utilizatorului.

1.3 Auditul si expunerea datelor

Auditul slab

Politica și tehnologia de audit slabă reprezintă riscuri în ceea ce privește respectarea,

descurajarea, detectarea, criminalistica și recuperarea.

Din păcate, capacitățile de audit ale sistemului de gestionare a bazelor de date (DBMS) au
ca rezultat degradarea performanțelor și sunt vulnerabile la atacurile legate de privilegii -
adică dezvoltatorii sau administratorii bazelor de date (DBA) pot opri auditarea.

Cele mai multe soluții de audit DBMS nu dispun de granularitatea necesară. De exemplu,
produsele DBMS înregistrează rar ce aplicație a fost utilizată pentru a accesa baza de date,
adresele IP sursă și interogările nereușite.

Aparatele de audit bazate pe rețea reprezintă o soluție bună. Aceste dispozitive nu ar trebui
să aibă niciun impact asupra performanței bazei de date, să funcționeze independent de toți
utilizatorii și să ofere o colecție granulară de date.

Expunerea datelor de rezervă

Unele atacuri recente au implicat furtul copiilor de rezervă de pe baza de date și al

discurilor hard disk. Toate backup-urile ar trebui să fie criptate. De fapt, unii furnizori au
sugerat că viitoarele produse DBMS ar putea să nu sprijine crearea de copii de rezervă
necriptate. Criptarea informațiilor bazei de date online de producție este un substitut slab
pentru controlul granular privilegiat.

În continuare, au fost definite două metode de atac ce trebuie evitate:

6
1. DDoS: Scopul atacatorilor este de a încetini viteza serverului prin trimiterea de multe
cereri non-sens. Dacă sunt suficiente aceste cereri, ei consumă o mulțime de lățime de bandă
și utilizeaza CPU.

2. SQL Injection: Este o metodă de a obține informații sensibile din punct de vedere al
securității datelor din serverul bazei de date cu acces neautorizat. Folosirea acestei metode
implica apariția unei erori de software pe site. Însă, chiar dacă există o astfel de eroare,
serverul web trebuie sa filtreze astfel de solicitări, sa aibă o performanța și scalabilitate mari.
Serverul IIS trebuie instalat astfel încât sa permită extinderea ușoară a serverului pentru ca
site-ul sa fie upgradat la orice cerința. Un dezavantaj al serverului este că rulează numai pe
sistemul de operare Windows. Costurile de licențiere trebuie, de asemenea, luate în
considerare, însă serverul IIS este, așa cum a fost menționat anterior, parte a fiecărui system
de operare Windows, deci există doar costurile normale de licențiere Windows, fără taxe
suplimentare pentru a rula serverul.

1.4 Aspecte privind serverul unei baze de date

Alegerea serverului de baze de date este aproape la fel de importantă ca alegerea serverului
web. Acest server este responsabil pentru stocarea tuturor informațiilor legate de utilizatori.
O parte din aceste informații sunt date sensibile din punct de vedere al securității, precum
adresa de e-mail și alte informații de conectare. Prin urmare, este foarte importanta alegerea
unui server securizat. Mai mult decât atât, serverul SQL trebuie să fie compatibil cu serverul
web. Un alt aspect important este accesibilitatea prin intermediul serverului baza de date la
limbajul de programare selectată. Este necesara existenta unui suport al limbajului de
programare pentru serverul SQL, ce permite accesarea si stocarea bazelor de date in
interiorul acestuia. În plus, ar trebui să fie posibila accesarea funcțiilor predefinite în serverul
SQL, cum ar fi procedurile stocate.

Caracteristica aplicației Pool a serverului web poate fi folosită in tandem cu serverul SQL
pentru a specifica nivelul de securitate. Avantajul este că permite o singura gestionare mai
ușoară a configurațiilor de securitate, în locul utilizării uneia separate pentru website și
serverul baza de date. Cu această configurație este posibilă particularizarea setărilor de
securitate în detaliu, cum ar fi dacă site-ul web ar fi trebuit aibă acces in citire sau scriere la o
bază de date specificată. Un alt aspect important pentru securitate este mecanismul de
actualizare. Actualizările pentru acest produs sunt lansate împreună cu Windows Update,
deci nu este nevoie ca acestea sa fie facute manual.

Pentru a oferi cea mai bună performanță unui server, a fost considerat următorul aspect: ori
de câte ori este posibil, este folosită o comandă de lot în locul comenzilor de tip rand-pe-rand

7
(row-by-row). Acest lucru are avantajul că serverul trebuie să efectueze Comanda SQL o
singură dată și nu pentru fiecare linie. De exemplu, dacă n puncte de date ar trebui să fie
introduse într-un tabel de pe serverul bazei de date, comanda lot rulează o singură dată pe
server, in timp ce comanda rând-pe-rând rulează de n de ori. Un exemplu legat de declarația
introducerii de 1 până la 2000 puncte de date pot fi văzute în Figura 3.1. Această cifră arată
timpul necesar introducerii numărului de puncte de date în serverul SQL. Un număr mic de
inserții este rulat mai rapid daca se utilizează o comanda rând-cu-rând, însă daca numărul
punctelor creste, este indicata inserarea cu o comandă de lot. Prin introducerea a 2000 de
puncte de date, timpul pentru o comandă rând-pe-rând dureaza 1198,4 ms și pentru comanda
lotului 75,2 ms.

Fig. 1.1. Comparatia a doua comenzi SQL

Deci, pentru inserare, este necesar:

75.2
𝑝= ∗ 100 = 6.275%
1198.4
În funcție de scalabilitatea serverului: acest server poate fi instalat pe mai multe platforme.
De exemplu, poate exista un singur server disponibil pentru fiecare continent, iar utilizatorul
se conectează la cel mai apropiat server care corespunde poziționării sale geografice.

Date relaționale

Datele relaționale descriu utilizatorii înregistrați pe site, seturile de date stocate pentru
analiza în baza de date și fișierele asociate pentru acest set de date.

8
 În acest scenariu sunt utilizate următoarele relații: fiecare fișier de date aparține unui set de
date și fiecare set de date aparține unui singur utilizator înregistrat. Acest comportament este
ilustrat în figura 1.2.

Este important faptul ca că unui utilizator i se permite sa aibă mai multe seturi de date și un
set de date poate fi stocat in mai multe fișiere. Acest fapt se definește ca: relația "One-to-
many", caracteristică implementată prin limbajul de programare al serverului.

Partea importantă pentru aceste relații este identificatorul unic global (GUID). Aceste
coloane sunt denumiri unice care identifică exact un utilizator, set de date sau un fișier.
Numele din baza de date pentru aceste coloane este "Cheie primară" (PK). Pentru a conecta
un set de date cu un utilizator, tabela de seturi de date din baza de date are nevoie de o
coloană UserId, pentru a stoca ID-ul utilizatorului care a creat setul de date. Numele
coloanei UserId din tabelul cu seturi de date se numește "Cheie străină" (FK). Această
valoare este aceeași cu ID-ul utilizatorului. Prin intermediul acestei proceduri, setul de date
este conectat la un singur utilizator. În cazul relației dintre seturile de date și fișiere, tabela de
fișiere are o coloană DataSetId, aceasta fiind Id-ul setului de date din care face parte fișierul.

Conturi de utilizator

Sistemul de gestionare a utilizatorilor din site se poate baza pe identitatea ASP.NET.

Aceasta din urma, ușurează personalizarea profilurilor, adăuga funcția de conectare și
deconectare la aplicația respectiva.

Este necesara implementarea mai multor setări pentru a oferi cea mai bună securitate
utilizatorul site-ului web. Un aspect important este politica de securitate a parolelor pentru a
face imposibila existenta parolelor precum "1234" sau "parola". De aceea politicile de
securitate a parolelor din Tabelul 1 sunt implementate în site-ul web, deci doar parolele
sigure sunt permise. Mai mult decât atât, o caracteristică de blocare este implementată. Daca
utilizatorul ce dorește logarea, introduce de cinci ori o parolă incorectă, contul va fi blocat
pentru o perioadă de cinci minute. În acest timp, contul nu poate fi utilizat. Această
procedură minimizează drastic șansa de a obține acces neautorizat la cont.

În aplicațiile web moderne nu este suficienta introducerea doar a unei parole pentru
conectare. Este necesara existenta unor setări de securitate suplimentare. Unul dintre ele este
autentificarea cu doi factori. După ce utilizatorul s-a logat cu adresa de e-mail și parola, el
trebuie să furnizeze un cod de securitate din șase cifre pentru a avea acces la site. Acest cod
este generat de site-ul însuși și va fi trimis către adresa de e-mail a utilizatorului.

9
 Tabel 1.2 Cerinte minime pentru parole

O altă posibilitate este utilizarea unei aplicații mobile care va genera acest cod, de
exemplu, Google Authenticator. În acest caz, utilizatorul scanează un cod de bare pe de site,
cu aplicația respectiva. Cererea generează codurile de securitate. Utilizatorul care dorește să
se autentifice trebuie să aibă acces la contul de e-mail care a fost specificat în timpul
înregistrării sau la telefon mobil, unde este instalată aplicația. Această procedură oferă
securitate suplimentară și este mai sigura decât o parolă.

Pentru a activa autentificarea cu doi factori, utilizatorul trebuie să-și confirme e-mailul,
înainte ca site-ul web să poată trimite codul la această adresă. Acest fapt asigură că
utilizatorul are acces la adresa specificată. Aceasta procedura implica un anumit avantaj, si
anume, posibilitatea implementării caracteristici „parola uitată”. Dacă un utilizator nu își
poate aminti parola, el poate introduce adresa sa de e-mail pe site-ul web. El va primi un e-
mail cu un link unic pentru resetarea parolei. Cu această caracteristică este imposibil ca un
utilizator sa poată bloca singur sau sa piardă accesul la datele sale. Pentru a asigura cea mai
bună securitate pentru setările de date, trebuie ca toate acțiunile asupra datelor să fie
autorizate de server. De exemplu, doar utilizatorul setului de date are permisiunea de a șterge
contul, in timp ce utilizatorii neautorizați vor primi o excepție de securitate. La fiecare
acțiune de pe site-ul Web, această autorizare este verificată și, prin urmare, este acordat
acceptul sau refuzat.

10
CAPITOLUL 2

ALGORITMUL BLOWFISH SI METODA SALT

2.1. Introducere

11
Algoritmul AES

Numele algoritmului AES vine de la Advanced Encryption Standard, iar traducerea în română
este Standard Avansat de Criptare).

Acesta mai poartă și numele de Rijndael, fiind un algoritm standardizat, folosit pentru criptarea
simetrică, pe blocuri, întâlniti pe scară largă în aplicații și adoptat ca și standard de organizația NIST.

Deoarece algoritmul DES devenise foarte vulnerabil din cauza lungimii prea mici a cheii sale, NIST a
recomandat utilizarea 3DES, un algoritm care constă în aplicarea de trei ori a DES. Deși 3DES s-a
dovedit a fi un algoritm puternic, el fiind însă lent, motiv pentru care NIST a lansat o cerere de
propuneri pentru un algoritm care să îl înlocuiască pe acesta .
S-a pornit de la 21 de propuneri acceptate inițial, ca apoi numărul lor a fost redus la 15, și apoi la 5,
în final a fost ales algoritmul propus de doi criptografi belgieni, Joan Daemen și Vincent Rijmen. La
votarea finală, algoritmul, denumit de autorii săi Rijndael, a învins patru alte propuneri, de exemplu
cunoscutul algoritml RC6.
Criteriile pe baza cărora au fost evaluate propunerile pentru AES au fost:
- securitatea, tradusă ca rezistența la atacuri criptanalitice;
- costurile, traduse prin eficiența computațională;
-licențierea liberă și gratuită);
- particularitățile algoritmului, traduse prin flexibilitate și simplitate;
În propunerea avansată NIST, autorii au definit un algoritm de criptare pe blocuri în care lungimea
blocului și a cheii puteau să fie independente, de 128 de biți, 192 de biți, sau 256 de biți. Specificația
AES standardizează astfel toate cele trei dimensiuni folosite pentru lungimea cheii, dar și
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.
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, primii patru octeți pe prima coloană, apoi următorii patru pe a doua coloană, și
continuând astfelcpână la completarea tabloului respectiv.
Algoritmul modifică astfel în fiecare pas acest tablou de numere, denumit ca state, și îl furnizează
apoi ca și ieșire. Funcționarea sa este descrisă de următorul pseudocod:

12
În pseudocodul de mai sus, Nb este numărul de coloane al stării iar în varianta standardizată acesta
fiind întotdeauna 4. Putem observa din descrierea algoritmului că o anumită secvență este realizată
iterativ, de un număr de Nr ori. Deci variabila de stare Nr depinde de lungimea cheii și este 10, 12
sau 14, pentru chei pe 128, 192, respectiv 256 biți.

Pasul SubBytes

Pasul SubBytes poate fi definit drept un cifru cu substituție, dar fără să aibă punct fix, denumit
și Rijndael S-box. El însă rulează independent pe fiecare octet din state. Transformarea respectivă
este neliniară și face astfel întreg cifrul să fie neliniar, obținând astfel un nivel sporit de securitate.
Fiecare octet este calculat astfel:

unde:
-bi este bitul corespunzător poziției i din octet; - ci este bitul corespunzător poziției i din octetul ce
este egal cu valoarea hexazecimală 63, sau, transformat în biți, 01100011.
Maparea octeților poate fi stocată într-un tabel, unde e specificat rezultatul operației, efectuată pe
fiecare din cele 256 de valori posibile reprezentabile pentru octet.

Pasul ShiftRows
Pasul ShiftRows este acel pas care 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ă spre stânga cu o poziție;
-al treilea rând se deplasează spre stânga cu două poziții;

13
-al patrulea se deplasează spre stânga cu trei poziții.
Rezultatul acestui pas constă în faptul 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 foarte important, din pricina
faptului că tabloul state este populat inițial pe coloane, la pașii viitori, inclusiv AddRoundKey în care
este folosită cheia de criptare, operațiile se efectuează pe coloane.

14
Pasul MixColumns
În pasul MixColumns, fiecare coloană a tabloului de stare poate fi
considerată drept un polinom de grad 4.
În pasul acesta, fiecare coloană a tabloului de stare poate fi considerată
un polinom de gradul 4 peste corpul Galois {\displaystyle F_{2^{8}}}
{\displaystyle F_{2^{8}}}.
Fiecare coloană, tratată ca și un polinom, este înmulțită,
Operația de față se poate scrie ca și înmulțire de matrice:

sunt elementele de pe un vector coloană ce rezultă în urma înmulțirii, iar

sunt elementele de pe același vector înainte de aplicarea pasului.

Rezultatul are proprietatea că fiecare element al său depinde de toate

elementele de pe coloana stării dinaintea efectuării pasului.
În combinație cu pasul ShiftRows, pasul în cauză asigură că după
câteva iterații, fiecare octet din stare depinde de fiecare octet din starea
inițială.
Acești doi pași, parcurși împreună, sunt principala sursă de difuzie în
algoritmul lui Rijndael.
Coeficienții polinomului a(x) sunt de forma 1, 2 și 3, din motive de
performanță, însă criptarea fiind mai eficientă atunci când coeficienții
sunt mai mici.
La decriptare, coeficienții pasului corespunzător acestuia sunt mai mari
iar decriptarea este mai lentă decât criptarea.

Pasul AddRoundKey și planificarea cheilor

Modificare

Pentru AddRoundKey, se face o operație de sau exclusiv, pe biți, între

octeții stării și cei ai cheii de rundă.

15
AddRoundKey este acel pas unde este implicată cheia. El se efectuează
printr-o simplă operație de „sau” exclusiv pe biți între stare și cheia de
rundă. Operația prin care se combină cu cheia secretă este una extrem
de simplă și rapidă, însă complexitatea algoritmului rămâne ridicată , din
cauza complexității calculului cheilor de rundă (Key Schedule), dar și a
pașilor algoritmului.[14]

Cheia de rundă este calculată după algoritmul următor:[15]

KeyExpansion(byte key[4*Nk], word w[Nb*(Nr+1)], Nk)

begin
word temp
i=0
while (i < Nk)
w[i] = word(key[4*i], key[4*i+1], key[4*i+2], key[4*i+3])
i = i+1
end while
i = Nk
while (i < Nb * (Nr+1)]
temp = w[i-1]
if (i mod Nk = 0)
temp = SubWord(RotWord(temp)) xor Rcon[i/Nk]
else if (Nk > 6 and i mod Nk = 4)
temp = SubWord(temp)
end if
w[i] = w[i-Nk] xor temp
i=i+1
end while
end

16
Acest algoritm lucrează pe cheia algoritmului, de lungime Nk cuvinte de
4 octeți (4, 6 sau 8, conform standardului), populând un tabel de
{\displaystyle Nb\times (Nr+1)} {\displaystyle Nb\times (Nr+1)} cuvinte,
Nb fiind numărul de cuvinte al blocului (în versiunea standardizată, 4),
iar Nr numărul de runde (iterații), dependent de lungimea cheii.
Algoritmul de planificare a cheilor folosește transformarea SubWord,
care este o substituție a octeților identică cu cea din pasul SubBytes.[16]
RotWord este o rotație ciclică la stânga cu un octet a octeților dintr-un
cuvânt.[16] Cu Rcon[i] se notează în algoritm un cuvânt format din octeții
{\displaystyle \left[2^{i-1},\{00\},\{00\},\{00\}\right]} {\displaystyle \left[2^{i-
1},\{00\},\{00\},\{00\}\right]}. Operația de ridicare la putere este aici cea
valabilă în corpul Galois {\displaystyle F_{2^{8}}} {\displaystyle
F_{2^{8}}}.[16] Tabloul w conține la finalul prelucrării cuvintele de pe
coloanele cheilor de rundă, în ordinea în care urmează să fie aplicate.

Securitatea
Modificare
Rijndael, ca și toți ceilalți algoritmi ajunși în etapa finală de selecție
pentru standardul AES, a fost revizuit de NSA și, ca și ceilalți finaliști,
este considerat suficient de sigur pentru a fi folosit la criptarea
informațiilor guvernamentale americane neclasificate. În iunie 2003,
guvernul SUA a decis ca AES să poată fi folosit pentru informații
clasificate. Până la nivelul SECRET, se pot folosi toate cele trei lungimi
de cheie standardizate, 128, 192 și 256 biți. Informațiile TOP SECRET
(cel mai înalt nivel de clasificare) pot fi criptate doar cu chei pe 256
biți.[17]

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.[18]

Note

17
2.2. Algoritmul de criptare BLOWFISH
18
 Cuvântul criptografie provine din grecescul “kryptos” care înseamnă “ascuns”, şi“graphein”
care înseamnă “a scrie”). Criptografia este definite ca stiinţa care studiază codarea mesajelor
şi descrie arta de a descifra mesajele criptate, facând mesajul lizibil. Deasemenea ea contine si
o latură matematică; aceasta combină criptografia şi criptoanaliza, de unde rezulta criptologia.

Un mesaj nesecurizat poate fi interpretat ca şi un text, pe când unul ce este securizat este
interpretat ca fiind un text criptat/codat. Procesul de convertire a textelor nesecurizate în texte
securizate, se numeste criptare. Procesul invers poarta numele de decriptare. Datorită noilor
tehnologii, astăzi criptografia a evoluat într-un mod semnificativ, devenind un proces foarte
sigur şi foarte folosit, de aceea prezintă un interes pentru oamenii de afaceri, precum şi pentru
programatori, care încearca zi de zi sa gasească noi algoritmi optimi şi eficienti de criptare şi
decriptare. În momentul în care comunitatea criptografica avea nevoie sa furnizeze lumii noi
standarde de criptare, este propus Blowfish, un nou bloc de cifru de 64 biţi cu cheie de lungime
variabilă.

Deşi există diferite metode de criptare disponibile pentru a păstra un transfer de date sigur,
mulţi dintre aceşti algoritmi nu sunt disponibili pentru public. Unii sunt protejaţi de autorizaţii
(Khufu [11,12], REDOC II [2,23,30], şi IDEA [7,8,9]), unii sunt păstrati secreti de guverne
(Skipjack şi Capstone protejate de guvernul american) ) sauunii sunt disponibili doar pe
părţi(RC2,RC4 şi GOST). Totodată, algoritmul de criptareDES [16] din ultimii 15 ani se
apropie de sfarsitul lui în utilizare. Cheia lui de de 56 biţilungime este vulnerabilă la un atac
de forţă brută[22] şi noile avansări în criptanalizadiferenţială[1] şi criptanaliza liniară[10] arată
că DES este vulnerabil şi pentru alteatacuri.De aceea în multe situaţii algoritmul Blowfish este
soluţia ideală. El are licienţăgratuită, este disponibil pentru toate cazurile de utilizare şi deşi a
fost spart pe bucăţi,întreaga versiune este inpenetrabilă.ISTORICBlowfish a fost creat în 1993
de Bruce Schneier că o alternativă la algoritmii decriptare deja existenți. Presedinte al
companiei Counterpane Systems, firmă deconsultare specializata în criptograpfie şi
securizarea calculatoarelor, a contribuit lascrierea multor documente criptografice, incluzând
cartea “Applied Cryptography (JohnWiley & Sons,1994&1996)” considerată o lucrare
influiențabilă în domeniulcriptografiei. Cea mai mare realizare a sa ramâne totuși algoritmul
de criptare Blowfish, prezentat pentru prima dată în 1994 la Cambridge, Anglia într-un
workshop despre procedee de securizare.

19
DOMENII DE APLICAȚIE

Un algoritm standard de criptare trebuie să fie compatibil cu diferite aplicații. El trebuie să fie
eficient pentru:

- criptarea fișierelor de date sau al unui șir de date continuu

- producerea de biţi aleatori- criptarea pachetelor de date dimensionate (un pachet ATM are
campul de date de 48octeți)

- convertirea sa într-o funcție de dispersie cu o singură orientare- aplicațiile unde pachete

successive pot fi criptate şi decriptate cu chei diferite.

DESCRIEREA ALGORTMULUI

Blowfish este un bloc de cifru de 64 biţi cu cheie de lungime variabilă. Algoritmul constă în 2
parti: o parte de expansiune a cheii şi o parte de criptare a datelor. Procesul de expansiune al
cheii convertește o cheie care are maxim 448 biţi în mai multe tablouri de subchei totalizând
4168 octeți. Criptarea datelor are loc prin o rețea Feistel de 16 reprize. Toate operațiile sunt de
forma XOR şi adunări pe cuvinte de 32 biți. Singurele operații de adunare sunt 4 tablouri de
căutare a datelor împarțite pe fiecare repriză.

Subchei :

Blowfish folosește un număr mare de subchei:

1. Tabloul P este format din 18 subchei de 32 biți: P1,P2,…,P18

2. Există 4 cutii-S de 32 biţi cu câte 256 intrări fiecare.

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

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

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

S4,0, S4,1,…, S4,255;

20
Criptarea:

Blowfish este de fapt o rețea Feistel care constă în 16 reprize. Intrarea este un x, un element
de 64 biți, în timp ce șirul P este notat cu Pi (unde i este iterația). Împarte x în două jumătăți
de 32 biți: xL, xR. Pentru i = 1 la 16 avem:

xL = xL XOR Pi

xR =F(xL) XOR Xr

Schimbăm XL si XL

xR=xR XOR P17

xL=xL XOR P18

Recombinăm xL si xR

Împarte xL în 4 sferturi de 8 biţi: a, b, c, d.

F(xL)=((S1,a+ S2,b mod 232) XOR S3,c) + S4,d mod 232

Decriptarea este identică cu criptarea cu excepția că P1,P2,…,P18 sunt folosite în ordine

inversă. Implementarea Blowfish-ului care cere viteză maximă necesită să se asigure că toate
subcheile sunt păstrate și sunt bine ascunse. Subcheile sunt calculate cu ajutorul algoritmului
Blowfish. Metoda exactă este prezentată mai jos:

1. Initializăm prima dată tabloul P şi cele 4 cutii-S, în ordine, cu un șir fixat. Șirul constă
în cifre hexazecimale ale numărului pi (dar excluzând primele 3).

Exemplu:

P1 = 0x243f6a88 P2 = 0x85a308d3

P3 = 0x13198a2e P4 = 0x03707344

2. XOR P1 cu primii 32 de biţi ai cheii, XOR P2 cu următorii 32 de biţi ai cheii şi

continuând pentru toți biții cheii (posibil până la P14). Repetăm ciclul prin biții cheii
până atunci când pentru tot tabloul s-a efectuat XOR cu biții aparținând cheii.(la orice
cheie scurtă există cel puțin o cheie echivalentă dar mai lungă, de exemplu dacă A este
cheie de 64 biţi atunci AA,AAA,etc vor fi chei echivalente)
3. Se criptează tot șirul zero cu algoritmul Blowfish folosind subcheile descrise în pașii
(1) şi (2)
21
 4. Se înlocuiește P1 şi P2 cu ieșirea pasului (3)
5. Se criptează ieșirea pasului (3) folosind algoritmul blowfish pentru subcheile anterior
modificate
6. Se înlocuiește P3 şi P4 cu ieșirea pasului (5)
7. Se continua procesul înlocuind toate intrările tabloului P, după toate 4 cutiile S în ordine
cu iesirea algoritmului Blowfish continuu și modificabil.

Per total, o să fie necesare 521 de iterații pentru a genera toate subcheile de care avem nevoie.
Aplicațiile pot stoca subcheile mai rapid decât să execute procesul respectiv de derivare de mai
multe ori.

DECIZII CARE AU STAT LA BAZA CREARII ALGORITMULUI BLOWFISH

La baza filosofiei din spatele algoritmului Blowfish-ului a stat simplicitatea beneficiilor de

design care e ușor de înțeles dar şi foarte usor de implementat. Un bloc ce are mărimea de 64
biţi poate realiza un cuvânt de mărimea a 32 biţi şi menține poate compatibilitatea mărimii
blocului cu algoritmii deja existenți. Criptanaliza variantelor de mini-Blowfish va putea fi în
mod semnificant mult mai simplă decât criptanaliza întregii sale versiuni. Operațiile
fundamentale care au fost luate în considerare luându-se în calcul viteza, XOR,ADD şi MOV
sunt eficiente atât pe apropape toate arhitecturile.

Rețeaua Feistel care formează corpul Blowfish este modelată astfel încât să fie simplă în timp
ce reține proprietățile criptografice dorite ale structurii.

S-a considerat o funcție reversibilă mult mai complicată, una cu înmulțiri modulare şi rotații.
Operațiile respective vor mări mult timpul de execuție al agoritmului. Ținând cont de faptul că
functia Feistel, prima sursă a securității algoritmului, s-a decis să se pastreze și acele
complicații de consumare a timpului pentru funcție în cauză.

Funcția ireversibilă F îi oferă algoritmului Blowfish-ului cel mai benefic efect de avalanșă
pentru o rețea asemenea Feistel: fiecare bit text din jumătatea stângă a reprizei afectează fiecare
bit text din jumătatea dreaptă iar în plus, dacă se ține cont că fiecare bit al subcheii este afectat
de aproape fiecare bit al cheii, funcția are un efect de avalanșă perfect între cheie şi jumătatea
dreaptă ce aparține textului după fiecare repriză.

Functia ireversibilă este create mai ales pentru putere, viteză dar şi simplicitate. În mod ideal,
s-a vrut ca o singură cutie-S să conțină 232 cuvinte de 32 biţi, dar aceasta nu a fost o decizie

22
bună. Decizia de a avea 256 cutii-S de intrare a fost un compromis între cele scopurile de
design (3 la număr).

Numărul mic de biţi dar şi numărul mare de biţi a fost o mare slăbiciune pentru criptanaliza
liniara însă slabiciunea respectivă poate fi ascunsă prin combinarea ieșirii celor 4 cutii-S şi
prin crearea lor, independent față de cheie.

S-au folosit 4 cutii-S diferite în locul uneia singure pentru a evita simetriile când diferiti biţi
de intrare sunt egali sau când intrarea de 32 biţi a funcției F este o permutare a altor 32 de biţi
de intrare. S-ar fi putut folosi o singură cutie-S şi sa se creeze pentru fiecareiesire diferita o
permutare netriviala a unei singure iesiri dar modelarea celor 4 cutii Seste mai rapida, mai
usor de programat şi pare mai sigura.

Functia care combina cele 4 iesiri al cutiilor-S este pe cât se poate de rapida. O funcție mai
simpla ar fi fost sa se execute un XOR a celor 4 valori dar amestecarea adunarii mod232 şi a
XOR imbina 2 grupuri algebrice diferite fara instructii suplimentare. Alternareaadunarii cu
XOR se termina cu o operatie de adunare pentru că XOR combina rezultatulfinal cu xR.

Daca se iau valori alese din aceeasi cutie-S o mai complicata funcție de combinare
estenecesara pentru eliminarea simetriilor.S-a luat în considerarea acestei functii complexe
înBlowfish (folosind inmultiri modulare, rotiri, etc) dar sa ales sa nu fie folosită pentru
căaceasta complicare parea nenecesara.

Cutiile-S dependente de cheie protejeaza impotriva criptanalizei liniara şi

diferențiala.Tinand cond că structura cutiilor-S este complet ascunsa de criptanalist acestor
atacuri leeste mai greu sa exploateze structura. în timp ce ar fi posibil sa se inlocuiasca
acestecutii-S variabile cu 4 cutii cutii S fixe care au fost crearea să fie rezistente la
acesteatacuri, cutiile-S cu de cheie dependente sunt mai usor de implementat şi mai
puținsensibile la argumente de proprietati ascunse, în plus, aceste cutii-S pot fi create la
cererereducand necesitatea unei structuri de date mare păstrata cu algoritmul.

Fiecare bit a xL este folosit doar că intrarea unei cutii-S. în DES mulţi biţi sunt folositi
căintrări pentru 2 cutii-S care slabeste în mod considerabil algoritmul impotriva
atacurilor diferențiale. Aceasta complicatie adaugata nu este necesara cu cutiile-S dependente
decheie. în plus, cutii-S mai mari ar lua mult mai mult spațiu de memorie.

Functia F nu depinde de iteratie. S-a adugat independenta dar nu s-a considerat că arevreun
merit criptografic. Substituirea tablouluiP poate fi considerate că facand parte dinaceasta
funcție, şi aceasta este deja dependenta de iterații.

Numărul de reprize s-a fixat la 16 la inceput din dorinta de a fi conservator. Oricum,

acestnumăr afecteaza mărimea tabloului P şi de aici procesul de generarea a subcheilor.

23
16iterații permit chei de lungime până la 448 biți. S-a asteptat sa poata fi posibila
reducereaacestui număr şi grabirea mare a algoritmului în proces în momentul în care
seacumuleaza mai multa dată de criptanaliza.

In modelarea acestui algoritm sunt 2 metode de baza care asigura faptul că cheia este destul
de lunga pentru a asigura un nivel de sercuritate particular. Unul este de a modela cu atentie
algoritmul astfel incat intreaga entropie a cheii este păstrata astfel incat sa nu fie nici oalta
metoda mai buna de criptanaliza decat forță brută. Cealalta este de a modela algoritmul cu atat
de mulţi biţi ai chei astfel incat atacurile care reduc lungimea efectiva achei cu mai mulţi biţi
să fie irelevante. Din moment ce Blowfish este creat pentru microprocesoare mari cu un total
de memorie mare s-a ales mai tarziu.

Procesul de generare a subcheilor este creat pentru a conserva intreaga entropie a cheii
şi pentru a impartii entropia uniform prin subchei. Este deasemeanea creat pentru a
distribuisetul de subchei premise aleator prim domeniul subcheilor posibile. S-a ales numerele
lui pi că şi tabelul subcheii initiale din 2 motive: pentru că este o secventa aleatoare neasociata
cu algoritmul şi pentru că poate sau să fie păstrat sau că parte a algoritmului sau derivat daca
este necesar. Nu este nimic solemn la pi, orice șir de biţi – numerealeatori ai lui e, tabele
RAND, iesirea unui generator de numere aleatoare sunt suficiente.Oricum daca sirul initial nu
este aleator în orice fel(de exemplu un text ASCII cu bitulinalt al fiecarui octet egal cu 0),
problema că este nealeator se va raspandi în intregalgoritmul.In procesul de generare al cheilor
subcheile se Schimbă puțin cu fiecare pereche desubchei generata. Aceasta este în primul rand
pentru a proteja impotriva oricarui atacasupra procesului de generare a subcheii care
exploateaza subcheile fixate şi cunoscute. De asemenea reduce cerințele de depozitare. Limita
de 448 a marimii cheii asigura că orice bit a oricarei subchei depinde de orice bit a cheii. (De
notat că fiecare bit a lui P15, P16,P17 şi P18 nu afecteaza fiecare bit a ciphertextului şi că
oricare intrare a unei cutii-S areo probabilitate de .06 sa afecteze orice bloc ciphertext).

Pentru biții cheilor se efectueaza în mod repetat XoR cu numerele lui pi în tabloulP
initial pentru a preveni urmatorul potential atac: sa presupunem că biții cheilor nu se repeta
dar în schimb se umplu cu zeroruri pentru a se extinde catre lungimea tabloului P. Un
atacator ar putea sa gaseasca doua chei care difera doar în valoarea de 64 de biţi la care li s-
auaplicat un XOR cu P1 şi P2 şi care, folosind subcheile cunoscute initial produce
aceasivaloare criptata. Acesta este un atac tentant pentru un generator de chei malitios.

Pentru a preveni acelasi tip de atac, s-a fixat valoarea plaintextului initial în procesul
degenerarea a subcheilor. Nu este absolut nimic special la sirul cu zerouri dar este importantcă
aceasta valoare să fie fixata.

Algoritmul de generare a subcheilor nu presupune că biţi cheii sunt aleatori. până şi biții
cheii puternic corelati, că şi un string alfanumeric ASCII cu bitul fiecarui octet setat la 0 va

24
produce suBchei aleatoare. Oricum pentru a produce subchei cu aceeasi entopie o
cheiealfanumerica mai lunga este ceruta.Timpul consumat în procesul de generare a subcheilor
adauga o complexitateconsiderabila pentru un atac de forță brută. Subcheile sunt prea lungi
pentru a fi stocate pe o banda masiva deci ar trebui să fie generate de o masina de spargere în
forță brută precum se cere. Un total de 522 de iterații al algoritmului de criptare este necesar
pentru atesta o singură cheie , adaugand efectiv 29 de pasi la orice atac de forță brută.

2.1 Exemplul unei encriptari blowfish

25
Expunerea algoritmului Blowfish, conceput de Paul Kocher in 1997:

26
27
28
2.3. Metoda de criptare Salt

Metoda de criptare Salt este o metoda ce presupune adaugarea unor valori arbitrare (salt) –
pentru a opri atacuri de tip dictionar parola aplicatiei va fi concatenata cu k biti aleatori,
denumiti biti salt dar in cazul respectiv dimensiunea dictionarului se va mari cu aproximativ
2k ori iar valoarea de salt se va păstrea alături de parolă.

Salting-ul poate fi definit ca un proces care întărește criptarea fișierelor și hash-urile sale,
făcându-le mult mai greu de spart.

Metoda salting adaugă un șir aleator la începutul sau la sfârșitul textului de intrare înainte
de a face hashing sau de a cripta valoarea respectivă.

Figura 2.2 Tehnica SALT

29
 Când cineva va încearca să spargă o listă de parole, de exemplu, hackerii, trebuie să
contabilizeze informațiile referitoare la acest proces salt, precum și eventualele parole, înainte
de a putea intra efectiv în aplicație. Dacă fiecărei valori ce este parcursă în acest proces salt îi
este atribuită o valoare diferită de cea de salt, abilitatea sa de a crea o tabelă cu valori potențiale
de parolă pentru un program de spargere a parolei o să devină mult mai dificilă.

În criptografie, modelul salt este deficit precum o informație aleatorie care este utilizată ca
și o intrare suplimentară la o funcție unidirecțională care "hashuește" date, o parolă sau o
expresie de acces. Metodele salt sunt folosite ca să protejeze parolele de stocare. Din punct de
vedere istoric, o parolă a fost stocată în plaintext pe un sistem, însă, în timp, au fost create alte
măsuri suplimentare pentru a proteja parola unui utilizator împotriva citirii din sistem. Metoda
Salt este una din metode.
Într-o setare tipică, metoda salt și parola (sau versiunea sa după întinderea cu cheie) sunt
concatenate și procesate cu o funcție hash criptografică, iar rezultatul obținut (dar diferit parola
originală) este stocat împreună cu salt-ul într-o bază de date. Hashing-ul permite și
autentificarea ulterioară.

Procesul SALT apără împotriva atacurilor dicționarului și împotriva echivalentului lor de

hash-uire, de exemplu un atac de masă ‘’curcubeu pre-calculat’’.

Deoarece datele de SALT nu trebuie să fie memorate de oameni, ele pot face ca mărimea de
date necesară pentru un atac de succes să fie prohibitiv de mare, fără a pune însă o povară
asupra utilizatorilor.
Deoarece procesele de salt sunt diferite în fiecare caz în parte, se protejează de asemenea
parolele utilizate frecvent dar și acei utilizatori care folosesc aceeași parolă pe mai multe site-
uri, făcând toate instanțele hash-uite pentru aceeași parolă diferite unul față de celălalt.
Sarcinile criptografice sunt utilizate în general în mai multe sisteme informatice moderne, de
la acreditările sistemului Unix până la securitatea Internetului. Procesul de salt e strâns legat
de conceptul de nonce criptografic.

30
CAPITOLUL III
APLICATIA DE GESTIUNE ANALIZE
3.1 Introducere
În lucrarea de față, se va prezenta o aplicație cu utilitate în gestionarea unei clinici medicale,
denumită contextual Florescu Adrian Clinical Center.

Utilizatorul aplicației va beneficia de drepturi mărite de Securitate, în prinpical în partea de

logare. Parolele împreună cu datele importante vor fi criptate: informațiile de user și
rezultatele de analize.

O anumitș parte a bazei de date se va replica într-o bază de audit, cu ajutorul unui trigger pe
tabela user, de unde deținătorul aplicației va putea să observe modificările pe care le-a facut
userul respectiv unui set de analize.

Pasul de logare:

Aplicația admite ca user doar userul: Florescu Adrian-Ionut.

Tabela în care se regăsesc date despre useri poartă următoarea denumire: famc_user_anal și
are structura:

31
CREATE TABLE `famc_user_anal`

`id` int(10) UNSIGNED NOT NULL,

`user_id` int(10) UNSIGNED NOT NULL,

`anal_no` varchar(255) CHARACTER SET utf8 NOT NULL,

`date` datetime NOT NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

---

Dumping data pentru tabela `famc_user_anal`

---

INSERT INTO `famc_user_anal` (`id`, `user_id`, `anal_no`, `date`)

VALUES

(1, 1, 'ANALIZ#00000001', '2019-06-15 05:07:18');

Trigger pe tabela: `famc_user_anal`

---

DELIMITER $$

CREATE TRIGGER `analiz_delete` AFTER DELETE ON `famc_user_anal` FOR EACH

ROW BEGIN

INSERT INTO `famc_db_audit`.`famc_istoric_actiuni`(`user_id`, `analiza`, `data`)

VALUES (famc_user_anal.user_id, famc_user_anal.anal_no, now());

32
De regulă, în toate limbajele SQL, trigger-ul se comportă precum o procedură stocată la nivel
de tabelă. Trigger-ul în cauză a fost folosit pentru a stoca modificările pe care user-ul le face
asupra setului de analize, în situația noastră doar statement de delete.

Acest trigger va scrie într-o noua bază, o bază care este pe același server dar este indicat ca
ea să aparțina de un server distinct, pe care o vom defini ca bază de audit.

Astfel, putem avea o privire de ansamblu asupra acțiunilor pe care userii respectivi le vor
efectua asupra datelor.

De regulă, partea de frontend a aplicației accesează datele apelând ca statement-uri view-uri

si nu select-uri deoarece acestea oferă o securitate extensă aplicației, ele limitează accesul
anumitor categorii de useri la anumite date.

Pentru o aplicație ce conține mai multi utilizatori care aparțin mai multor grupuri, este indicat
să se folosească o tabelă de securitate, cu drepturi de acces pe anumite ecrane.

Atunci când se va construi view-ul respectiv, va trebui ca acest statement să fie legat (prin
inner join direct prin user_id, de exemplu), între tabele de date și tabela de securitate.

O altă chestiune de luat în calcul este formatul datelor în bază:

1) Collation-ul bazei de date;

2) Upper-case setat pentru baza de date. Atunci când este setat modul de upper-case,

33
user-ul de SQL va primi date doar pentru statementul corect. De exemplu, vom putea numi
tabela teoretica USER ca UseR, deci selectul corect va fi select top 1 * from UserR iar acest
lucru va spori securitatea datelor, baza de date va fi spartă într-un timp mai ridicat.

Parola si datele confidențiale ale useri-lor au fost criptate, folosind algoritmul de criptare
AES, cu o cheie privată generată anterior:

Mai jos, este prezentat clasa PHP care criptează și decriptează datele, folosind cheia privată
specificată mai sus,

unde:

$key reprezintă cheia de criptare

$iv reprezintă vectorul de inițializare, care este un număr arbitrar pentru encriptare și este
folosit în prevenția repetării datelor în encriptare, făcând să fie mult mai greu de găsit
pattern-ul de encriptare

34
35
Acestea sunt rezultatele după ce s-a folosit algoritmul de encriptare:

36
La fel s-a efectuat criptarea datelor și pentru setul de analize și anume rezultatele:

După ce se efectuează logarea în aplicație folosind CNP-ul si parola (parola a fost encriptată

37
folosind algoritmul de criptare Blowfish:

Dup ace userl a fost logat cu success, folosind masuri de preventive de Securitate a datelor,
precum Sql Injection (facandu-se escape la datele introduse de utilizator in campurile CNP,
parola, folosind metoda de bind params a clasei de conectare la baza de date), va fi redirectionat

38
catre dashboard-ul principal, unde va putea vizualiza toate buletinele active de analiza:

User-ul are dreptul să vizualizeze datele buletinului, accesând butonul următor: .

Pentru a șterge un anumit buletin, user-ul va accesa butonul:

În momentul în care este accesat butonul de vizualizare, respectiv , va fi redirectionat catre

pagina de rezultate a buletinului de analiza selectionat, moment in care rezultatele de analiza a
buletinului vor fi preluate din baza de date encriptate si apoi vor fi decriptate cu acceasi cheie

39
pentru a putea fi intelese de utilizator:

Metoda folosita in decriptarea fiecarui rezultat din analize:

40
La accesarea butonului de delete, in baza de audit se va efectua urmatoarea actiune, care va scrie

41
ceea ce a sterg userul din buletinul de analize in baza noastra de audit.

42
BIBLIOGRAFIE

[1] Jelena Mirkovic and Peter Reiher. “A taxonomy of DDoS attack and DDoS defense
mechanisms.” In: ACM SIGCOMM Computer Communication Review 34.2 (2004), pp. 39–53.
[2] Stephen W Boyd and Angelos D Keromytis. “SQLrand: Preventing SQL injection attacks.”
In: Applied Cryptography and Network Security. Springer. 2004, pp. 292–302.
[3] Russell Sears, Catharine Van Ingen, and Jim Gray. To BLOB or Not To BLOB: Large Object
Storage in a Database or a Filesystem. Tech. rep. MSR-TR-2006-45. Microsoft Research, 2006,
p. 7. url: http://research.microsoft.com/apps/pubs/default.aspx?id=64525
[4] Andrew Kennedy and Don Syme. “Design and implementation of generics for the. net
common language runtime.” In: ACM SigPlan Notices. Vol. 36. 5. ACM. 2001, pp. 1–12.
[5] Mark Otto, Jacob Thornton, and Bootstrap contributors. Bootstrap The world’s most popular
mobile-first and responsive front-end framework. url: http://getbootstrap.com
[6] Oresti Banos, Rafael Garcia, Juan A Holgado-Terriza, Miguel Damas, Hector Pomares,
Ignacio Rojas, Alejandro Saez, and Claudia Villalonga. “mHealthDroid: A novel framework for
agile development of mobile health applications.” In: Ambient Assisted Living and Daily Activities.
Springer, 2014, pp. 91–98.
[7] Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C,
Second Edition. New York, NY: John Wiley & Sons, 1995
[8] Dennis V Lindley. “Fiducial distributions and Bayes’ theorem.” In: Journal of the Royal
Statistical Society. Series B (Methodological) (1958), pp. 102–107.
[9] Leo H Chiang, Evan L Russell, and Richard D Braatz. “Fault diagnosis in chemical processes
using Fisher discriminant analysis, discriminant partial least squares, and principal component
analysis.” In: Chemometrics and intelligent laboratory systems 50.2 (2000), pp. 243–252.
[10] Oresti Banos, Miguel Damas, Hector Pomares, Alberto Prieto, and Ignacio Rojas. “Daily
living activity recognition based on statistical feature quality group selection.” In: Expert Systems
with Applications 39.9 (2012), pp. 8013–8021.

43