Securitatea Aplicatiilor Economice Bazate pe Sisteme de Gestiune a Bazelor de Date
Cuprins
1 Introducere – Ce își propune lucrarea de față 2
2 Criptarea informatică 3
2.1 Noțiuni introductive 3
2.2 Algoritmi criptografici cu cheie secretă (simetrici) 4
2.3 Algoritmi criptografici cu cheie publică (asimetrici) – algoritmul RSA (Rivest Shamir Adleman) 5
2.4 Securitatea la nivel IPSec 8
2.5 Certificate digitale cu chei publice 14
2.6 Soluții de criptare a datelor în SGBD (Tehnologii Oracle-Transparent Data Encryption) 19
2.7 Dezvoltarea aplicațiilor SGBD utilizând Data Encryption API (fostul Oracle Obfustication Kit) și JCE (Java Cryptography Extension) 22
3 Aplicații economice ale securității informatice 26
3.1 Aplicații economice ale securității informatice 26
3.2 ERP-Enterprise Resource Planner 36
3.3 CRM –Customer relationship management 38
4 Aplicație de tip Customer Relationship Management 44
4.1 Descrierea aplicației 44
4.2 Instalarea aplicației 54
4.3 Rularea aplicației 60
5 Bibliografie 64
Introducere – Ce își propune lucrarea de față
Lucrarea de față își propune să prezinte câteva metode și tehnologii existente de securitate a tranzacțiilor informatice în mod special existente pe internet și securizare a informațiilor bazei de date folosite în aplicațiile economice. Contribuția autorului constă în modelarea unei baze de date destinate unei aplicații economice de tip CRM securizată cu un algoritm de criptare propriu (necomercial).
Criptarea informatică
Noțiuni introductive
Criptografia informatică oferă cele mai puternice soluții pentru mediul în societatea noastră se pregătește să trăiască în viitorul apropiat: Cyberspace-ul. Folosită inițial numai pentru asigurarea confidențialității transmisiunilor din domeniul diplomatic și mai ales militar criptografia a cunoscut în ultimele decade progrese remarcabile datorită cerințelor în special impuse de comerțul electronic și securitatea bancară.
Criptografia este știința care folosește principii matematice pentru a cripta și decripta informații; cu alte cuvinte, pentru a securiza informațiile stocate ori transmise. Reversul medaliei este criptanaliza – știința analizării și determinării codurilor prin care se codifică datele. Cele două, criptografia și criptanaliza sunt denumite generic criptologie. Scopul criptografiei este de a asigura următoarele atribute ale unei comunicații:
Confidențialitate –protejează conținutul tranzacțiilor împotriva citirii lor neautorizate.
Integritatea datelor – furnizează receptorului unui mesaj siguranța că mesajul primit nu a fost modificat; deci este identic cu cel plecat de la origine (dovada împotriva manipulării frauduloase a informației);
Autentificarea originii mesajului – verifică identitatea celui care transmite mesajul (determinarea identității unui individ sau a unei aplicații);
Nerepudiere sau nonrepudiere – siguranța că cel ce generează mesajul nu poate să nege că l-a trimis (asigurarea paternității mesajului);
Criptografia informatică realizează aceste servicii prin criptare. În criptografie mesajul este criptat folosind o cheie (șir de caractere sau biți –parametrii ai funcției de criptare sau decriptare), la expeditor, iar apoi este transmis prin rețea. La destinație, mesajul criptat este decriptat cu aceeași cheie sau cu o altă cheie in funcție de algoritm, obținându-se mesajul original.
Un cifru reprezintă transformarea unui mesaj clar sau text clar in mesaj clar sau criptogramă. Atât cifrarea cât și decifrarea sunt controlate de una sau mai multe chei criptografice. Exista două tipuri primare de criptare folosite astăzi: criptografie cu cheie secretă (criptografia simetrică) și cea cu cheie publică (criptografia asimetrică).
Algoritmi criptografici cu cheie secretă (simetrici)
Principiile de criptare din algoritmii cu cheie secretă au evoluat odată cu apariția calculatoarelor; ele continuă însă să se bazeze pe metodele tradiționale, cum ar fi transpoziția și substituția. Algoritmii cu cheie secretă sunt caracterizați de faptul că folosesc aceeași cheie atât în procesul de criptare, cât și în cel de decriptare avantajul major fiind viteza de criptare/decriptare.
Cei mai cunoscuți algoritmi criptografici cu cheie secretă sunt: AES (Advanced Encryption Standard), DES (Data Encryption Standard), 3DES, IDEA (International Data Encryption Algorithm). În figura de mai jos este prezentat modul de funcționare al criptării simetrice.
După cum se poate observa, cheia de criptare este folosită și la decriptare. În cazul funcției de criptare a mesajului la emisie () pentru recepție se folosește inversa acesteia ().
Standardul de Criptare a Datelor (în engleză Data Encryption Standard, DES și varianta sa mai sigură Triplu DES) este un cifru (algoritm) selectat ca standard de procesare a informațiilor în Statele Unite în 1976 și care s-a bucurat ulterior de o largă utilizare pe plan internațional. Algoritmul, destul de controversat la început, suspect de avea elemente secrete, lungimea cheii scurtă și fiind bănuit că ascunde de fapt o portiță pentru NSA (cheie de criptare de 56 de biți – considerată prea scurtă pentru provocările actuale și deci cifrul failibil). IDEA (International Data Encryption Algorithm) folosește o cheie de criptare de 128 de biți. AES (Advanced Encryption Standard), înlocuitorul lui DES, permite utilizarea unei chei de cifrare pe 128, 192 sau 256 de biți.
Algoritmi criptografici cu cheie publică (asimetrici) – algoritmul RSA (Rivest Shamir Adleman)
În criptografie, RSA este un algoritm criptografic cu chei publice, primul algoritm ce poate fi utilizat atât pentru criptare, cât și pentru semnătura electronică. Algoritmul a fost dezvoltat în 1977 și publicat în 1978 de Ron Rivest, Adi Shamir și Leonard Adleman la MIT inițialele reprezentând numele celor trei autori.
Spre deosebire de criptografia simetrică, în criptografia asimetrică se folosesc două chei diferite, una pentru criptare, alta pentru decriptare provocarea constând în dificultatea problemei factorizării numerelor întregi problema pentru care toți algoritmii de rezolvare cunoscuți au complexitate exponențială.
Deducerea unei chei din cealaltă este, în consecința imposibila, una din chei este făcută publică, și poate fi folosită de oricine dorește să transmită un mesaj criptat. Doar destinatarul, care deține cea de-a doua cheie (cheia privată), poate descifra mesajul. Existența cheii publice face ca algoritmul să se preteze la mediul web, iar perechile de chei publice/private pot fi folosite și pentru autentificarea mesajelor prin semnătură digitală, fapt care face algoritmul cu chei publice și private și mai popular.
În cripto-sistemele cu chei publice, de exemplu Costin deține o cheie publică notată ECostin , stocată într-un fișier public și o cheie secretă notată DCostin ce nu poate fi obținută din E. Cheia de descifrare (transformare secretă) este derivată din cheia publică printr-o transformare greu inversabilă.
Să presupunem că Costin dorește să-i transmită lui Dan un mesaj M sub formă criptată C. Atunci, cu ajutorul cheii publice a lui Dan criptează astfel:
C=EDan(M) – unde C=criptograma iar M=mesaj clar.
La recepție, Dan va descifra criptograma cu ajutorul cheii sale secrete DDan:
DDan(C)= DDan (EDan(M))=M
Prin mecanismul de mai sus se asigură confidențialitate, dar nu și autentificare, Dan neavând certitudinea că mesajul provine realmente de la Costin.
Pentru autentificare este necesara identificarea adevăratului emitor. Pentru asta Costin folosește cheia sa privată obținând criptograma C:
C=DCostin(M)
La recepție Dan aplica cheia publică (transformarea publică) a lui Costin:
ECostin(C)= ECostin (DCostin(M)) =M
Implementarea lui în limbajele orientate obiect este pusa la dispoziție prin clase moștenite de tip API. Spre exemplu, implementarea în Java (generarea cheilor pe client) este relativ simplă:
RSA client –implementare Java
private static SecureRandom random;
private static int keyLengthRSA = 1024;
private static Key locRSAPrivKey;
private static RSAPublicKey locRSAPubKey;
private static void makeLocRSAKeys() throws Exception {
random = new SecureRandom();
KeyPairGenerator generator = KeyPairGenerator.getInstance( "RSA" );
generator.initialize( keyLengthRSA, random );
KeyPair pair = generator.generateKeyPair();
locRSAPrivKey = pair.getPrivate();
locRSAPubKey = ( RSAPublicKey )pair.getPublic();
}
Algoritmul criptografic cu cheie publică se bucură de o foarte mare apreciere, atât în mediul guvernamental cât și în cel comercial și este susținut prin lucrări și studii de comunitatea academică și azi reprezintă standardul "de facto" în domeniul confidențialității cu chei publice și al semnăturilor digitale. În diverse moduri de implementare, prin programe software sau dispozitive hardware , algoritmul RSA fiind azi cel mai sigur algoritm de criptare comercial.
RSA este bazat pe cvasi-imposibilitatea actuală de factorizare a întregilor mari, în timp ce a găsi numere prime mari este ușor; funcțiile de criptare/decriptare sunt exponențiale, unde exponentul este cheia și calculele se fac în inelul claselor de resturi modulo n.
Deoarece criptarea și decriptarea sunt funcții mutual inverse, metoda RSA poate fi utilizată atât la secretizare, cât și la autentificare acest lucru fiind explicat în paragrafele ce urmează.
Securitatea la nivel IPSec
Multe dintre aplicațiile din prezent furnizează servicii de securitate la nivelul de transport (spre exemplu aplicațiile ce folosesc SSL –secure sockets layer sau https). Acestea funcționează pe un nivel de transport IP nesecurizat ce funcționează în mod obișnuit în clar. Nivelul de transport IP nu a fost conceput pentru a furniza un grad înalt de securitate, ci mai degrabă pentru a asigura transportul pachetelor IP. Cerințele noi de securitate au făcut necesară apariția implementării unui nivel de securitate sigure ( de pildă protocoalelor sigure ssl și https) deasupra protocolului de transport.
Una din abordările recente o reprezintă protocolul de transport IPSec dezvoltată de Data Network System descrisă în RFC 1108 – un protocol sigur de transport deasupra căruia se pot implementa protocoalele care nu au fost neapărat concepute pentru a fi sigure și totuși securitatea întregului transport să fie sigură; cu alte cuvinte se furnizează în mod generic un mecanism de securitate chiar și pentru protocoalele ce nu sunt conștiente de existenta acestora:
Standardul pentru Arhitectura de Securitate RFC2401 prezintă mecanismele de securitate atât pentru versiunea IPv4 cât și pentru IPv6. Exista 2 tipuri de antete ce pot fi atașate la un pachet IP pentru a deveni IPSec:
Antetul de autentificare AA (Authentication Header) ce furnizează servicii de integritate și autentificare.
Învelișul de securitate IS (Encapsulating Security Header) ce asigură confidențialitate în funcție de algoritmii folosiți. În unele cazuri poate furniza și integritate și autentificare.
Ambele mecanisme pot furniza servicii de securitate între:
doua calculatoare
un calculator și gateway-ul lui
doua gateway-uri conectate între ele.
Asigurarea unui suport pentru modele de gestiune a cheilor pentru nivelul de transport IP nu a constituit un obiectiv pentru proiectarea acestui mecanism. În schimb AH și ESH sunt proiectate astfel încât să folosească metode de gestiune a cheilor, transportul cheilor și stocarea acestora.
Antetul de autentificare (AH) este proiectat pentru a asigura serviciile de integritatea datelor și autentificarea originii datelor pentru ambele datagrame IPv4 și IPv6, iar în funcție de algoritmii criptografici folosiți, poate furniza și algoritmul de nerepudiere.
2.4.1. Mecanismul Antetului de Autentificare
Antetul de autentificare a fost proiectat să furnizeze doar serviciile de autentificare a originii datelor, integritatea lor și ocazional nerepudiere. Nu există un mecanism propriu zis pentru realizarea confidențialității deoarece legislația americană nu permitea exportul produselor software criptografice cu chei mai mari de 56 biți pentru serviciul de confidențialitate. (criptare propriu-zisa). Pentru serviciul de autentificare se folosesc algoritmi de tip hash (rezumat) precum MD5 si SHA1, dar pot fi suportați și alți algoritmi. Pentru prevenirea atacurilor prin repetiție (replay attacks), în ultima versiune exista un câmp de 32 biți ce conține un contor monoton incrementat pentru verificarea faptului că fiecare datagrama între cele doua entități comunicante este diferită.
O datagramă cu Antet de Autentificare conține următoarele câmpuri:
Antetul următor – câmp de 8 biți cu tipul de informație după AA
Lungimea încărcăturii (Payload) -8 biți pentru lungimea AA
Octeți rezervați- rezervat pentru utilizări ulterioare
Indexul parametrilor de securitate -32 biți ce identifică Asociere de Securitate
Număr de secvență- 32 biți; valoare contor
Datele de autentificare – valoare de verificare pentru pachetul curent
2.4.2 Mecanismul învelișului de Securitate pentru Internet Protocol (IP)
Învelișul de securitate a fost descris în RFC 1827 și este destinat să asigure următoarele servicii pentru datagramele IP:
Confidențialitatea datelor;
Confidențialitatea limitata a traficului
Serviciu anti-replică
Autentificarea originii datelor
Confidențialitatea la nivel IPSec este furnizată numai dacă învelișul de securitate este prezent și este independentă de celelalte servicii.
Iată cum arată formatul pachetelor învelișului de securitate:
Indexul parametrilor de securitate (Security Parameters Index) -32 biți ce identifică o Asociere de Securitate pentru acest pachet IP (datagarama).
Număr de secvență 32 biți contor incrementat pentru fiecare datagramă –opțional în funcție de serviciul anti replică.
Vector de inițializare- are lungime variabilă în funcție de algoritmul de criptare.
Datele (Protected data)- Câmp ce conține datele în sine.
Datele de umplere, Lungime umplere-Pad, Pad Lengh – completează câmpul date
Antetul următor – câmp pe 8 biți ce identifică tipul de date conținute în câmpul de date.
Date de autentificare (authentication data)- câmp de lungime variabilă ce conține valoarea MAC (Message authentication code- funcție hash -rezumat- precum MD5 sau SHA-1)
Una dintre utilizările ale IS (invelisului de securitate) este aceea de furnizare a serviciilor de securitate pentru protocoalele TCP si UDP. În modul transport header-ul (antetul IP) nu este protejat. O alta utilizare este modul tunel sau modul VPN în care IS încapsulează datagrama cu totul; (atât antelele datagramei (IP si TCP) cât și secțiunea de date. Acest mod este implementat peste rețele nesecurizate, protocolul IPSec fiind implementat de către gateway-uri.
2.4.3 Protocoale de securitate la nivel transport (SSL si TLS)
Standardul SSL (și precursorul lui TLS) a fost dezvoltat inițial de Netscape pentru a transmite fără risc documente private prin Internet, iar în momentul de față se află la versiunea 3.0. Deși a fost proiectat ca un protocol de securizare a comunicației pe world wide web, el s-a dezvoltat sub forma unei întregi suite de protocoale ce operează peste TCP. Realizarea securității web a întâmpinat întotdeauna dificultăți, precum diversitatea platformelor și sistemelor de operare ale calculatoarelor interconectate sau a aplicațiilor ce rulau pe web. În final soluția a fost adoptarea unui protocol independent de aplicații și sisteme de operare. Cea mai utilizată aplicație a protocolului SSL este https (http protejat) .
Scopul principal al protocolului este realizarea a trei atribute ale conexiunii:
conexiune secretă – trebuie asigurată confidențialitatea datelor transmise.
Autentificarea (identificarea fără echivoc) a entității pereche – sunt folosiți algoritmii de criptarea asimetrica precum RSA sau DSA
Conexiunea trebuie să fie stabilă (sau fiabilă). Pentru aceasta se folosesc funcții hash SHA-1, MD5 folosite pentru calculul digest-ului (codul de autentificare MAC)
Versiunea actuală este SSL 3.0. Printre facilitățile aduse de această ultimă versiune amintim:
-suport pentru algoritmii criptografici Diffie – Hellman și Fortezza.
-căile de certificare
-serverul poate alege algoritmi de compresie și de criptare care vor fi folosiți pe durata sesiunii (handshake)
-o mai bună compresie a datelor, ceea ce îl face mai rapid decât versiunile anterioare.
Protocolul SSL posedă 2 de niveluri de protocol:
Protocolul SSL de înregistrare (SSL Record Protocol)
Furnizează servicii pentru:
Fragmentarea și compresia datelor
Generează MAC (Message Authentication Code –o valoare pentru verificarea integrității datelor)
Criptează datele
Se asigură că receptorul poate determina lungimea corectă a datelor primite. (datele de intrare pot necesita o lungime de umplere după cum e descris în subcapitolul anterior).
Protocolul SSL de negociere (SSL Hanshake Protocol)
Când un client și un server încearcă să comunice pentru prima dată folosind protocolul SSL, aceasta se realizează în următoarele faze:
Punerea de acord asupra versiunii protocolului.
Alegerea algoritmilor criptografici
(opțional) o etapă de autentificare mutuala a clientului și serverului
În continuare părțile vor folosi algoritmi cu chei publice pentru a genera o cheie secretă ce o vor partaja pe durata sesiunii.
În cele din urmă cele 2 de niveluri de protocol se disting în Figura (de completat nr figura de mai sus.)
Certificate digitale cu chei publice
În funcționarea sistemelor cu chei publice este necesar un sistem de generare și circulație a cheilor publice. (Nu a celor private!). Să ne imaginăm următorul scenariu: Costin, un utilizator malefic, dorește sa se dea drept Danuț, un utilizator onest și să semneze în fals documente electronice in locul lui Danuț. Tot ce ar avea de făcut este să înlocuiască fișierul ce conține cheia publica a lui Danuț cu propria cheie publică. Astfel tot ce semnează Costin pare venind de la Danuț și orice persoană se va înșela cu privire la autenticitatea documentelor ce vin de la Danuț.
Problema fundamentală se rezumă deci la încrederea absolută în cheile publice cu care se face verificarea semnăturii digitale. În acest context, soluția a fost crearea unei infrastructuri internaționale (Autorități de Certificare – Certification Authority); aceasta trebuie sa fie disponibilă în rețea astfel încât orice client să poate obține cheia publica a unui emitent de document semnat digital.
Cel mai recunoscut și mai utilizat standard pentru certificatele digitale este X.509, care a cunoscut de-a lungul timpului mai multe versiuni.
Sistemul bazat pe certificate cu chei publice implică existenta unei Autorități de Certificare, care emite certificate. Certificatul conține cheia publica și numele subiectului în clar. Există o relație biunivocă între cheia publică și subiectul certificatului, care poate fi o persoană, o aplicație, un dispozitiv hardware etc. Aceasta reprezintă o legătura imposibil de falsificat între subiect și cheia sa publică. Certificatul este semnat digital de o Autoritate de Certificare confirmând astfel identitatea subiectului. Această autoritate de certificare este certificată la rândul ei printr-un alt certificat digital semnat de o altă Autoritate de Certificare de nivel superior, generându-se astfel o ierarhie precum în figura de mai jos.
Distribuția certificatelor este una facilă având în vedere că nu există informații secrete conținute în certificat, ci doar acele informații care pot fi făcute publice. Ca urmare, certificatele pot fi distribuite prin rețele nesigure.
Este imposibil de găsit o Autoritate de Certificare care să emită certificate pentru toți deținătorii de perechi de chei publice/private din lume. De asemenea, nu este nici practic ca toți utilizatorii din lume sa aibă încredere într-o singură organizație sau companie, atunci când e vorba de comunicațiile lor secrete.
2.5.1 Suita de standarde PKCS
Standardul predominat în sistemele oferite de piața de software pentru semnătura digitală îl reprezintă algoritmul RSA. După cum am văzut în capitolele anterioare, RSA își bazează tăria pe imposibilitatea factorizării unor întregi mari (sute, poate chiar mii de cifre zecimale). Folosirea algoritmului în industria software se face sub denumirea PKCS (Public Key Criptography Standards), realizate de RSA Data Security Inc.
Abordarea legală a semnăturii electronice
Structura internetului este una eterogenă, nu există un control global, părțile se pot situa sub jurisdicții diferite astfel încât pentru orice disputa, legislația ar trebui să fie armonizată. Spre exemplu, ar putea fi imposibil ca anumite tipuri de afaceri să se desfășoare fără riscuri, penale sau civile, pentru procesările de date sau procesările financiare, deoarece ceea ce este legal în țara în care sunt preluate datele, ar putea fi ilegal în țara în care sunt citite. Deoarece internetul este o rețea globala, riscurile devin și ele globale.
Camera Internațională de Comerț (ICC) încearcă de mulți ani să încorporeze reglementari referitoare la comerțul pe internet. Aceasta a recomandat folosirea unui notar electronic (CyberNotarySM) și a unor terțe părți de încredere în gestiunea sigură a unor documente electronice.
Comisia Națiunilor Unite asupra Legii Comerțului International (UNCITRAL) lucrează la elaborarea unui set de reguli aplicabile în comerțul electronic internațional (document numit – uniform rules), ce ar urma sa fie valabile oriunde în lume, iar scopul lor ar fi să faciliteze folosirea semnăturilor electronice și digitale în tranzacțiile economice internaționale.
Scopul acestui document este să stabilească condițiile de bază pe care semnăturile digitale ar trebui sa le îndeplinească pentru a fi sigure:
AC-ul (Autoritatea de Certificare) trebuie să identifice în mod corect posesorul cheii publice
Ac-ul trebuie să autentifice în mod corect pe posesorul cheii publice.
Cheia secretă nu trebuie compromisă.
Procesul de creare a semnăturii trebuie să fie de încredere – algoritmul și lungimea cheii publice trebuie să fie corespunzătoare.
Definește Autoritatea de Certificare ca fiind:
orice entitate care acționează pentru a pune în practica regulile adoptate de comisie.
Orice persoană sau entitate care pune în circulație certificate în legătură cu cheile criptografice folosite pentru semnăturile digitale.
Comisia nu-și propune să definească criterii pe care un stat ar trebui sa le adopte. Aceasta deoarece o infrastructură cu chei publice are o componentă publică, deci implementarea ei depinde și de cadrul legislativ al fiecărui stat.
Comisia definește noțiunea de certificat ca fiind un mesaj prin care:
Se identifică autoritatea de certificare, care l-a emis.
Denumește sau identifică pe cel care îl deține sau un dispozitiv sau un agent electronic, sub controlul autorității de certificare.
Conține o cheie publică care corespunde unei chei secrete a celui care îl deține.
Și pe plan european există aceeași preocupare pentru reglementarea uniformă a problematicii comerțului electronic și a semnăturilor electronice și implicit a celor digitale.
Un document important pe plan european pentru reglementarea statutului juridic a semnăturilor digitale și electronice îl constituie Directiva asupra semnăturilor electronice elaborata de Comisia Comunității Europene și de către Consiliul Europei. Scopul fundamental al documentului îl constituie crearea cadrului internațional privind recunoașterea legală a semănaturilor electronice în special a celor digitale ce folosesc metode criptografice cu chei publice.
Soluții de criptare a datelor în SGBD (Tehnologii Oracle-Transparent Data Encryption)
2.1.1 Criptare de tip coloană ( TDE Column Encryption)
Criptarea TDE la nivel de coloană este folosită pentru a proteja datele confidențiale, cum ar fi numere de card de credit sau CNP și stocate în coloane. Criptarea de tip coloană folosește o arhitectură pe două nivele, pe bază de cheie pentru a cripta și decripta simetric și transparent coloane. Cheia de criptare de tip master este stocată într-un modul extern de securitate, care poate fi un modul de portofel software sau hardware ca de exemplu Hardware Security Module (HSM). Această cheie de criptare de tip master este folosită pentru a cripta cheia master, care, la rândul ei este folosită pentru a cripta și decripta datele în coloana tabele.
Așa cum se arată în figura de mai sus, cheia de criptare master este stocată într-un modul de securitate extern, care este în afara bazei de date și accesibile numai administratoru-lui de securitate (diferit de administratorul de baze de date). Pentru acest modul de securitate externă, Oracle se folosește un portofel software sau o cheie hardware după cum este descris în prezentul capitol. Stocarea cheii de criptare master în acest portofel software (wallet) previne utilizarea neautorizată.
Folosirea unui modul de securitate externă (portofel / HSM) separă funcțiile operațiunii de criptare, oferind posibilitatea de a împărți atribuțiile între administratorii de baze de date între și cei de securitate. Acest lucru se realizează prin faptul că parola portofel este necunoscută de administratorul bazei de date fiind cunoscută numai administratorului de securitate.
Atunci când un tabel conține coloane criptate, o singură cheie tabel poate fi utilizată indiferent numărului de coloane criptate. Toate cheile de criptare pentru tabele sunt criptate la rândul lor cu cheia de criptare master al serverului de baze de date și stocate într-un tabel din dicționarul bazei de date. Nici o cheie nu este stocată în clar.
2.1.2 Criptare la nivel tablespace (TDE Tablespace Encryption)
Serverul de baze de date cunoaște o structura logică numită tablespace (spațiu tabel) la nivelul căruia sunt stocate în baza de date atât tabela cât și indecși, șiruri, constrângeri, directoare, etc. O baza de date conține una sau mai multe subdiviziuni de tip tablespace; acesta aparține unei singure baze de date. Un anumit fișier de date aparține unui singur tablespace. În cele ce urmează termeni precum tablespace și spațiu tabela vor fi folosiți ca sinonime.
Criptarea la nivel tablespace permite criptarea unui tablespace întreg aceasta însemnând că toate obiectele create în tablespace criptate automat (tablele, indecși, sinonime, directoare,constrângeri, view-uri materializate –numite obiecte ale bazei de date). Criptarea la nivel tablespace este utilă dacă se dorește criptarea tuturor datelor senzitive din tablele nemaifiind nevoie pentru a se efectua o analiză granulară a fiecărei coloane din tabel pentru a determina coloanele care au nevoie de criptare.
Criptarea la nivel tablespace este o bună alternativă la criptarea de tip coloană dacă datele confidențiale există în mai multe coloane, sau dacă se dorește criptarea tuturor obiectelor bazei de date din tablespace-ul respectiv.
În cazul criptării la nivel tablespace sunt stocate criptat atât din tablespace-ul criptat cât și datele corespunzătoare din tabelspace-ul de tip redo. Aceasta include obiecte de interne mari (LOB-urile): cum ar fi cele de tip BLOB si CLOB.
Toate datele dintr-un tablespace criptat sunt stocate în format criptat pe disc. Datele sunt decriptate în mod transparent (în timpul citirii sau scrierii) pentru un utilizator autorizat care are privilegiile necesare pentru a vizualiza sau modifica datele. Un utilizator de bază de date sau aplicație nu are în mod normal nevoie să știe dacă datele într-un anumit table sunt criptate pe disc. In cazul în care fișierele de pe disk sau un backup este furat, cheia de criptare nu este compromisă.
Criptarea de tip tabelă folosește arhitectura de securitate pe două nivele, pe bază de cheie pentru criptarea și decriptarea tabelelor. Cheia de master TDE este stocată într-un modul de securitate extern (HSM sau Oracle Wallet). Această cheie de master TDE este folosită pentru a cripta cheia de criptare TDE tabelă, care la rândul lui este folosit pentru a cripta și decripta datele în tablespace.
2.1.3 Oracle Wallet Manager (portofel electronic)
Oracle Wallet Manager este o aplicație destinată managementului cridențialelor (parole, chei publice private, certificate SSL). În mod tipic acesta este folosit pentru stocarea cheilor folosite la criptarea de tip TDE la nivel de coloană sau tablespace prezentate mai sus. Oracle Wallet Manager poate fi folosit pentru următoarele tipuri de servicii:
Creare de portofele electronice
Generare de certificate digitale
Accesarea serviciilor PKI
Exportul portofelului electronic către alte aplicații și dispozitive
RSA Laboratories, o divizie a RSA Security, Inc., a dezvoltat în cooperare cu mediul academic și organizațiile guvernamentale SUA un standard pentru criptografia cu chei publice sau PKCS (Public-Key Cryptography Standards). Acest standard este menit să asigure interoperabilitatea între sisteme ce folosesc criptare cu chei publice și private atât în Internet cât și în Intranet.
Oracle Wallet Manager stochează certificate X.509 și chei private în format PKCS #12 format și generează cereri de certificate în concordanță cu specificația PKCS #10. Aceste capabilități fac structura Oracle Wallet interoperabilă cu o gama variata de aplicații și dispozitive hardware pe diverse sisteme de operare.
Dezvoltarea aplicațiilor SGBD utilizând Data Encryption API (fostul Oracle Obfustication Kit) și JCE (Java Cryptography Extension)
Serverul RDBMS Oracle, de asemenea un API (Attached Package Interface), poate cripta toate datele din tabele sau datele din coloane, chiar și mod în mod selectiv. Pachetul DBMS_CRYPTO este instalat implicit de către serverul RDBMS Oracle. Teoretic se poate utiliza JCE pentru criptare și DBMS_CRYPTO pentru decriptare sau viceversa.
DBMS_CRYPTO este un pachet interfața (API) pentru limbajul PL/SQL folosit ca suport pentru câțiva algoritmi criptografici standard precum (DES, AES si 3DES) si pentru funcții hash (MD5, MD4, SHA-1 si MAC).
Următorul bloc arată utilizarea procedurii DBMS_CRYPTO cu un algoritm AES pe 256-biți cu Cipher Block Chaining (CBC) și PKCS#5. (după cum e prezentat la www.oracle.com , sectiunea Database PL/SQL Packages and Types Reference)
DBMS_CRYPTO
DECLARE
input_string VARCHAR2 (200) := 'Mesaj Secret';
output_string VARCHAR2 (200);
encrypted_raw RAW (2000); – stores encrypted binary text
decrypted_raw RAW (2000); – stores decrypted binary text
num_key_bytes NUMBER := 256/8; – key length 256 bits (32 bytes)
key_bytes_raw RAW (32); – stores 256-bit encryption key
encryption_type PLS_INTEGER := – total encryption type
DBMS_CRYPTO.ENCRYPT_AES256
+ DBMS_CRYPTO.CHAIN_CBC
+ DBMS_CRYPTO.PAD_PKCS5;
BEGIN
DBMS_OUTPUT.PUT_LINE ( 'String original: ' || input_string);
key_bytes_raw := DBMS_CRYPTO.RANDOMBYTES (num_key_bytes);
encrypted_raw := DBMS_CRYPTO.ENCRYPT
(
src => UTL_I18N.STRING_TO_RAW (input_string, 'AL32UTF8'),
typ => encryption_type,
key => key_bytes_raw
);
decrypted_raw := DBMS_CRYPTO.DECRYPT
(
src => encrypted_raw,
typ => encryption_type,
key => key_bytes_raw
);
output_string := UTL_I18N.RAW_TO_CHAR (decrypted_raw, 'AL32UTF8');
DBMS_OUTPUT.PUT_LINE ('Decrypted string: ' || output_string);
END;
Procedura de mai sus folosește subprocedurile DBMS_CRYPTO.ENCRYPT și DBMS_CRYPTO.DECRYPT pentru a cripta respectiv decripta datele de tip caracter (sir) de la standard input (tastatura). Acestea sunt preluate și returnate în variabilele input_string și respectiv output_string și stocate în variabilele encrypted_raw și respectiv decrypted_raw Tipul criptării este specificat de variabila encryption type, în cazul de mai sus AES256 cu CBC și padding PKCS5;
Acest pachet include două tipuri diferite de funcții hash one-way: funcție hash și funcția de MAC. Funcțiile hash operează pe un mesaj de intrare de o lungime arbitrară și întorc o valoare hash de lungime fixă. Este ușor a se calcula o valoare hash de la un mesaj de intrare, dar este extrem de dificilă generarea unui mesaj de intrare pentru un rezumat de o anumită valoare. Valorile rezumatului hash trebuie să fie de cel puțin 128 de biți pentru a fi considerate sigure.
Pachetul DBMS_CRYPTO poate genera aleatoriu chei de criptare, dar nu oferă un mecanism pentru păstrarea acestor. Dezvoltatorii de aplicații trebuie să se asigure că cheile de criptare utilizate cu acest pachet sunt generate și stocate în siguranță. De asemenea este de reținut că operațiunile de criptare și decriptare efectuate de DBMS_CRYPTO apar pe server, nu pe client. Prin urmare, în cazul în care cheia este trimisa prin conexiunea între client și server, conexiunea trebuie să fie protejata cu ajutorul protocoalelor de criptare de rețea descrise in capitolul anterior. Altfel, cheia devine este vulnerabilă în timp ce este transmisă.
Următorul exemplu folosește API-ul javax.crypto din Java Cryptography Extension pentru a genera o pereche de chei publice/private și a cripta și decripta un text introdus de la tastatură.
Exemplu de criptare folosind Java Cryptography Extension(javax. crypto)
import java.security.*;
import javax.crypto.*;
public class CryptoExample{
public static void main (String[] args) throws Exception {
if (args.length !=1) {
System.err.println("Usage: java CryptoExample text");
System.exit(1);
}
byte[] plainText = args[0].getBytes("UTF8");
// genereaza cheile RSA
System.out.println( "\nStart generating RSA key" );
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
keyGen.initialize(1024);
KeyPair key = keyGen.generateKeyPair();
System.out.println( "Finish generating RSA key" );
// Afiseaza cheile
System.out.println("Public key=" + key.getPublic());
System.out.println("Private key=" + key.getPrivate());
Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
System.out.println( "\n" + cipher.getProvider().getInfo() );
// cripteaza textul folosind cheia publica
System.out.println( "\nIncepe criptarea" );
cipher.init(Cipher.ENCRYPT_MODE, key.getPublic());
byte[] cipherText = cipher.doFinal(plainText);
System.out.println( "Termina criptarea: " );
System.out.println( new String(cipherText, "UTF8") );
// decripteaza textul folosind cheia privata
System.out.println( "\nIncepe decriptarea" );
cipher.init(Cipher.DECRYPT_MODE, key.getPrivate());
byte[] newPlainText = cipher.doFinal(cipherText);
System.out.println( "Termina decriptarea: " );
Aplicații economice ale securității informatice
Aplicații economice ale securității informatice
Comerțul electronic tradițional se referă la utilizarea în rețelele cu valoare adăugata a unor aplicații de tipul transferului electronic de documente (EDI), a comunicațiilor și codurilor de bare, transferului de fișiere și a poștei electronice. Extraordinara dezvoltare a interconectivității calculatoarelor în Internet, în toate segmentele societății, a condus la o tendință tot mai clara a întreprinderilor de a folosi aceste rețele pentru a desfășura un nou tip de comerț: comerțul electronic în Internet, care sa apeleze, pe lângă vechile servicii amintite și la altele noi. De pilda, putem vorbi de posibilitatea de a cumpăra online, consultând cataloage electronice Web și plătind cu ajutorul cărților de credit sau a unor portofele electronice. Pentru alții, Comerțul pe Internet reprezintă relațiile de afaceri care se derulează prin rețea între furnizori și clienți, ca o alternativa la variantele de comunicații "tradiționale" prin linii de comunicații dedicate sau EDI pe rețele cu valoare adăugata.
Acest nou tip de comerț a stimulat însă cererea pentru noi metode adecvate de piață. În cadrul noului concept de "sat global" (global village), dezvoltarea unor activități comerciale între participanți situați la mari distanțe geografice unii de alții nu poate fi concepută fără folosirea unor sisteme electronice de plăți.
Aceste noi modalitati de plată permit transferuri sigure si rapide a banilor între partenerii de afaceri. De asemenea, înlocuirea monedelor și bancnotelor, actualele forme tradiționale de lichiditatea, prin ceea ce se pot numi bani electronici, conduce, pe lângă reducerea costurilor de menținere în circulația numerarului, și la sporirea flexibilității și securității sistemelor de plăți.
Domeniul (interdisciplinar) al sistemelor electronice de plăți este foarte vast. El se întinde de la problemele arhitecturale și de software ale cartelelor inteligente, pana la fundamentele matematice ale criptografei utilizate în vederea securizării plăților, prin cunoștințele economice specifice gestiunii plăților în sistemele bancare clasice.
Viteza cu care evoluează tehnologia Internetului este impresionantă. Dacă acum se apreciază că există câteva milioane de oameni care folosesc serviciile de Internet, numărul lor va creste exponențial în anii următori.
Card-urile bancare clasice
Deoarece o buna parte din plățile ce se fac pe Internet folosesc deja "clasicele" card-uri vom începe cu o prezentare a acestui foarte răspândit sistem de plată. Bank Americard (în prezent VISA International), emis de Bank of America, reprezintă primul card lansat în 1960 pentru revoluționarea modului de achiziționare de bunuri și servicii. În zece ani s-a ajuns la peste 20 milioane de deținători de astfel de card-uri, în 1980, 73 milioane, iar în 1991 peste 100 milioane.
În anul 1966, 17 bănci finanțează Asociația Interbancara de Card-uri, care se ocupă cu procedurile de autorizare, clearing și decontare. În 1979 ele devin Mastercard, care cunoaște, la fel ca VISA, o dezvoltare rapidă: peste 90 de milioane de utilizatori în 1990.
De ce a cunoscut acest nou instrument de plată o așa de mare dezvoltare și care sunt avantajele sale?
• Pentru deținătorii de card-uri: ușurința în utilizare, renunțarea la purtarea numerarului, renunțarea la inconvenientele folosirii cecurilor, obținerea de credite instantanee, amânarea plaților cu circa o lună, urmărirea cu ușurința la sfârșit de lună a sumelor cheltuite etc.
• Pentru comercianți: ușurința încasărilor, autorizarea simpla a vânzărilor, creșterea volumului vânzărilor, acordarea de vânzări pe credit la scară foarte mare.
• Pentru bănci: card-ul reprezintă o modalitate simplă de a acorda credite și încuraja clienții sa se împrumute, veniturile băncii sporesc prin dobânzile încasate și prin comisioanele percepute comercianților
Tipuri de card-uri
Card-urile reprezintă instrumente de decontare care asigură posesorului achiziționarea de bunuri și servicii, fără prezența efectivă a numerarului. Indiferent de tip și funcții, card-urile au anumite trăsături comune:
• suport fizic de plastic, cu dimensiuni standard;
• numele emitentului, numărul card-ului, perioada de valabilitate, numele posesorului – inscripționate pe fața card-lui prin tipărire, gofrare sau gravare cu laser
• sigla emitentului, holograma de securitate, logo-ul organizației,
• banda magnetică (sau de curând, cip) pentru criptarea elementelor de securitate și un spațiu pentru semnătura posesorului, pe verso
Card-urile se pot c1asifica pe mai multe criterii:
A. În raport cu modul de stocare a caracteristicilor de securitate:
• card-uri cu banda magnetică – care memorează pe trei piste informații criptate despre utilizator, emitent, algoritmul de codare etc;
• card-uri cu microprocesor (smart-card-uri) – având stocate în cip datele de securitate și permițând funcționarea ca portofel electronic.
B. în raport cu sursa de acoperire a cheltuielilor:
• debit-card-uri – care asigură utilizatorului achiziționarea de bunuri ;i servicii sau retrageri de numerar cu condiția prezervării a unor fonduri în contul de card și efectuarea de cheltuieli în limita soldului disponibil.
• credit-card-uri – care asigură utilizatorului achiziționarea de bunuri și servicii sau retrageri de numerar pe baza unei linii de credit acordate posesorului.
C. în raport cu calitatea emitentului:
• card-uri emise de bănci
• card-uri emise de societăți non bancare: lanțuri de magazine , cluburi, societăți de asigurare.
Operațiuni cu card-uri
Etapele fundamentale care caracterizează operațiunile cu card-uri sunt: emiterea și acceptarea
Emiterea card-urilor
O bancă comercială poate lansa pe piață două tipuri fundamentale de card-uri: de debit și de credit. Orice program de emitere card-uri presupune patru etape:
Proiectarea și lansarea produselor card
Analiza și aprobarea cererilor de emitere
Producerea și predarea card-urilor (tipărire, ambosare, codare, generare PIN)
Autorizarea și decontarea tranzacțiilor (presupune existența unui sistem informatic care sa obțină în timp real informații legate de disponibilitățile cumpărătorului)
Transferul de fonduri prin card-uri
Sistemul electronic de transfer de fonduri (EFT-Electronic Found Transfer) reprezintă ansamblul dispozitivelor și procedeelor speciale care asigură deplasarea fluxurilor monetare de la plătitor la beneficiar, într-un mediu exclusiv electronic. Ele se efectuează în timp real și fără prezența înscrisului doveditor pe hârtie. Avantajele EFT sunt:
• viteza de transfer;
• securizarea transferului prin metode criptografice;
• aplicații autosecurizate.
Un exemplu de EFT este telebankingul, ce permite plați și încasări bancare prin soft, de la PC-uri conectate în afara perimetrului bancar. Se permite inițierea unor plăți de la distanță, transferul de fonduri de la plătitor (prin banca sa) către beneficiar prin inițierea electronică a ordinului de plată. În domeniul plăților prin card, transferul electronic de fonduri poate fi realizat cu ajutorul a două echipamente:
• Puncte electronice de vânzare la comercianți (EFTPOS-Point of Sale) reprezintă medii electronice de efectuare a tranzacțiilor comerciale sub forma unor automate ce prelucrează în timp real autorizarea operațiunilor și stocarea informațiilor financiare și chiar decontarea tranzacțiilor. Autorizarea în timp real se asigură printr-o tastatură specială atașată la POS (numită PINPAD), unde destinatarul card-ului introduce numărul personal de identificare (PIN). La sfârșitul unei zile, memoria POS (în realitate un PC) se "descărcă" la bancă și astfel fondurile tranzacționate sunt înregistrate în contul comerciantului. Unele sisteme POS permit azi alimentarea instantanee a contului comerciantului, pe măsura efectuării vânzărilor. Operarea POS implică două card-uri: al clientului și al vânzătorului (pentru identificarea acestuia).
• Ghișeul automat de bancă (ATM, cash dispenser) este un dispozitiv care înlocuiește operatorul uman în operații, implicând card-ul ca instrument de plată sau metoda de autentificare a clienților. Operarea ATM-ului implică un card pe care utilizatorul îl introduce pentru identificare, după care acesta poate beneficia de anumite servicii, ca: eliberarea de numerar din contul c1ientului, obținerea extrasului de cont, eliberarea de numerar din portofelul electronic, alimentarea contului etc.
Card-uri inteligente (Smart Card-uri)
Derivând din simplele card-uri cu cartele magnetice, card-urile inteligente (smart card) au înregistrat în ultimii ani o imensă creștere a cererii pe piață, depășind cu mult așteptările. Spre deosebire de card-urile magnetice obișnuite, card-urile inteligente sunt capabile să execute programe complexe, cum ar fi algoritmii criptografici, oferind posibilitatea folosirii acestora cu grad de risc mult diminuat, în aplicații ce necesita o complexitate și securitate ridicate.
Ce este un card intelligent
Termenul de card inteligent este folosit în general pentru a desemna un card de plastic de dimensiuni date, care include o serie de componente semiconductoare ce-i permit să memoreze și, uneori, să prelucreze informații. Caracteristicile unui card, denumit și ICC Card (Integrated Circuit Chip), sunt determinate de standarde internaționale (ISO 7810), care stabilesc dimensiunea fizică a plasticului (PVC sau ABS), toleranța la temperatură, flexibilitatea, poziția contactelor electrice exterioare și funcțiunea lor, modul în care cipurile comunică cu exteriorul.
Card-urile inteligente oferă câteva avantaje în raport cu "clasicele" card-uri magnetice:
• sunt mai fiabile;
• pot memora de 100 de ori mai multă informație;
•furnizează mecanisme sofisticate de securitate, folosind protocoale și mecanisme criptografice;
• sunt reutilizabile;
• au o arie largă de aplicabilitate;
• sunt compatibile cu alte dispozitive portabile (PC, telefoane etc.);
• sunt economice în raport cu facilitățile oferite;
• au o evoluție rapidă ca performanțe, existând deja card-uri inteligente cu performanțe deosebite (procesor 32 biți, Java card-uri etc.).
Trebuie sa facem distincție între doua tipuri de bază de card-uri inteligente:
• Card-urile cu memorie (Memory Cards) sunt incapabile să prelucreze informațiile; ele reprezintă doar dispozitive de stocare, similare cu deja vechile card-uri magnetice (foarte răspândite în momentul de față). Card-urile cu memorie, deși au o capacitate de stocare sporită, prezintă aceleași vulnerabilități privind securitatea ca cele magnetice. Odată conectate, acestea sunt controlate și accesate total din afară. Securitatea lor se bazează pe setarea unui comutator intern pe on/off, după cum datele (PIN-ul) furnizate la intrare coincid cu cele memorate într-o zona ascunsă a card-ului. Odată ce acest test e trecut, datele din memoria cipului sunt accesibile la citire și scriere.
• Card-urile cu microprocesor (Microprocesor Smart Cards) au pe lângă o mare capacitate de memorare și un microprocesor, care le permite nu numai sa stocheze informație, ci și să o prelucreze local, conform unor algoritmi complecși memorați în card sub forma unor programe. Ele posedă un sistem de operare propriu diferit.
Card-urile cu microprocesor pot fi considerate deci ca niște mici calculatoare portabile, plasate pe un suport plat de plastic și capabile sa suporte aplicații aferente unor servicii avansate, asigurând garanții înalte de securitate .
Din punct de vedere al accesului la card, exista doua tipuri:
Card-uri cu contact (Contact Card), care necesită introducerea într-un cititor de card-uri inteligente (smart card reader). Când card-ul este inserat în cititor, el face contact electric cu conectorii de pe card, prin care se transferă datele la/de la cip. Cartelele inteligente cu contact au un cip de aur de diametru aproximativ 1/2 inch încorporat pe fata cartelei, în locul benzii magnetice de pe spate de la tradiționalele cărți de credit. Când cipul este introdus în cititorul de card-uri inteligente, acesta face contact cu conectorii electrici care pot citi informația din cip și pot scrie informațae în acesta;
Card-uri fără contact (Contactless Card), care comunică printr-o antenă, la distantă, cu un cititor/transmițător. Card-urile inteligente fără contact arată ca o carte de credit normala, prezentând însa în interior un cip și o antenă, ce permite comunicarea cu o antenă externa. Aceste card-uri inteligente sunt folosite în aplicații în care este necesară procesare rapidă sau în care folosirea mâinilor trebuie evitată (din motive de invaliditate sau a efectuării unor acțiuni ce ocupă total mâinile). Aceste card-uri inteligente fără contact se bazează pe transmisii radio sau tehnologii de înaltă frecvență, care permite transferul datelor, al energiei de alimentare cu care acestea funcționează.
Menționam și existența card-urilor inteligente combinate (CombiCard), care funcționează în ambele moduri.
ISO 7816 este cel mai standard-ul principal în ceea ce privește construcția fizică a card-urilor inteligente, stabilind dimensiunile card-ului, temperaturile limită de funcționare, numărul și poziția și rolul contactelor externe, etc.
EMV se referă la card-urile de debit/credit; principalele instituții financiare Europay, Mastercard și Visa – au lansat în anul 1993 un proiect de folosire a card-urilor inteligente în bănci, soluție bazată pe standardul EMV, finalizat în 1996. Standardul EMV specifică protocolul, datele, instrucțiunile și tranzacțiile pe care trebuie să le desfășoare un card inteligent bancar. În plus, sunt specificate mecanismele interne de protecție a datelor care asigură inviolabilitatea secretelor memorate în card.
SET (Secure Electronic Transaction) este un standard în domeniul comerțului electronic promovat de importante instituții financiare – Visa, Mastercard, American Express. SET este
destinat prezentării tranzacțiilor cu card-uri de credit pe Internet, fiind destinat să lucreze fie într-un mediu de tip Web, fie în cazul e-mail. SET permite consumatorilor, comercianților și băncilor să opereze cu propriile lor componente software, care însă să coopereze perfect, fără a fi produse de aceeași firmă. SET se bazează pe existenta unei ierarhii de autorități de certificare, care furnizează cheile publice corecte utilizatorilor. Ca urmare, cumpărătorii și vânzătorii trebuie sa schimbe certificatele de securitate înainte de a ști cu ce cheie publica să cripteze mesajul adresat unui anumit corespondent.
C-SET (Chip Secure Electronic Transaction) a fost elaborat în Franța, pentru folosirea card-ului francez de bancă cu microprocesor. Sistemul, definitivat de Cartes Bancaires, folosește un mic cititor de card, conectat la un PC. C-SET este interoperabil cu SET.
PC/SC reprezintă specificațiile de integrare a card-urilor inteligente în contextul PC-urilor. A fost elaborat de principalele firme interesate în dezvoltarea card-urilor inteligente – Bull, Gemplus, Hewlett Packard, IBM, Schlumberger, Siemens, Toshiba și VeriFone – care au creat un grup de lucru pentru integrarea tehnologiilor lor într-un set de standarde comune.
În conformitate cu standardul ISO 7816, micromodulul (cipul) conține un tablou cu opt contacte, din care doar șase sunt de fapt conectate la cip, lucru care de obicei nu este vizibil. Contactele sunt alocate astfel: sursa de a1imentare (VCC și VPP), nul, ceas, reset și o legătură de comunicație serială de date, numită I/O. ISO (International Standards Organization) are în vedere la ora actuală câteva modificări ale acestui standard și actualizarea specificațiilor în ceea ce privește contactele; suprimarea celor două contacte nefolosite și crearea unui al doilea port I/O.
La momentul actual cartelele inteligente folosesc ca unitate de procesare un microcontroler pe 32 biți, cel mai des întâlnit fiind 68HC05 de la Motorola și 80C51 de la Intel. Capacitatea memoriei RAM (de obicei în jur de 512 octeți) este extrem de limitată de constrângerile fizice ale cartelei.
Pentru stocarea datelor de identificare ale posesorului cartelei, inițial card-uri le inteligente foloseau memorii de tip EPROM (Electrically Programmable Memory). Acestea necesitau o sursă de putere "high-voltage" suplimentară, având valori între 15V și 25 V. Cartelele din generațiile mai recente conțin, în locul acestora, memorii EEPROM (Electrically Erasable Programmable Memory), care necesită o singură sursă de energie de 5 V și pot fi scrise și șterse de mii de ori.
Standardul ISO 7816 impune și constrângeri relative la dimensiunea cipului. Multe din limitările actuale – în special cele privind capabilitățile criptografice și cele de memorare sunt o consecință directă a acestei limitări.
Cipurile integrate în cartelele inteligente sunt foarte fiabile. Mulți producători garantează proprietățile electrice ale cipurilor lor pentru 10 ani sau mai mult. Standardele ISO specifică modul în care o cartela trebuie protejată împotriva deteriorărilor mecanice, chimice sau electrice. Pentru majoritatea aplicațiilor cărora le sunt dedicate, cartelele prezintă o astfel de rezistentă încât ele expiră înainte de a se degrada.
Nu toate cipurile au integrate facilitați criptografice. Toate au însă detectori de securitate de genul:
Detectori de ceas;
Senzori de expunere la lumină și pasivizare;
Detectori de voltaj anormal;
Celula care detectează dacă memoria EEPROM a fost ștearsa într-un mod neobișnuit
Acești detectori permit microcontrolerului (procesorului) să împiedice încercările de
monitorizare prin resetarea memoriei Ram/EPROM. Detectorii de ceas reacționează la frecvențe ale ceasului excesiv de ridicate sau de scăzute. Senzorii de lumină și de pasivizare semnalizează dacă micromodulul a fost deschis. Detectorul de voltaj anormal este util, deoarece un astfel de voltaj poate influenta generatorul de numere aleatoare ce se găsește în orice cip cu facilitați criptografice sau poate influenta programele cablate în EEPROM.
Aplicații generale ale card-urilor inteligente
Card-uri bancare (debit/credit)
În majoritatea țărilor, card-urile bancare sunt de tip magnetic. Însa tendința actuală este de migrare către folosirea card-urilor inteligente.
Card-uri de transport
În domeniul transporturilor se folosesc deja aceste card-uri cu sau fără contact.
Card-uri de sănătate
Card-urile inteligente oferă noi perspective și în domeniul sănătății. Ele pot fi folosite pentru a memora informații, simplificând numeroase proceduri și asigurând securitatea și confidențialitatea datelor. Ele permit gestiunea autentificată și compartimentală a numeroase informații:
medicul poate accede la informațiile despre situația pacienților;
farmacistul accede la informațiile privind prescripțiile;
oricine poate citi informațiile de bază: identificatorul proprietarului, persoanele de contact în caz de accident etc.
Exista doua tipuri de card-uri pentru sănătate:
• card-uri de asigurări medicale, care reduc gestiunea birocratică, posibilitățile de fraudă, accelerează procesul de plată;
• card-uri de acces la înregistrările medicale, care permit accesul la istoricul medical al unui pacient, controlează accesul doctorilor și al farmaciștilor la informații, verifică automat incompatibilitățile anumitor medicamente.
De exemplu, în statul Oklahoma (SUA) există din 1994 un card de sănătate, MediCard, care permite un acces selectiv la datele medicale ale pacientului, ca și la unele informații în caz de urgență; cititoarele de card-uri sunt instalate în spitale, farmacii, servicii de ambulanță, pompieri etc.
Un alt exemplu îl constituie proiectul DiabCard al Comunității Europene care a realizat împreuna cu IBM un card pentru bolnavii diabetici, permițând o asistență medicală de calitate superioară și mobilitate acestui grup de pacienți.
Card-urile de tip portofel electronic
Card-urile de tip portofel electronic (numite Intersector Electronic Purse-IEP) permit efectuarea unor plăți mici (de obicei sub 20 USD). Pot fi utilizate la plați fără semnătură, cod, pentru diferite tipuri de mărfuri: băuturi, înghețată, cinema, parcări, telefoane, benzinării, jocuri etc.
Card-uri pentru comerț electronic
Comerțul electronic este desfășurat cu mijloace electronice și informatice, între vânzători și cumpărători situați la distanță unul de altul. Se folosesc rețele de calculatoare (în special Internetul) pentru cumpărarea unor bunuri și servicii, o serie fiind livrate chiar on-line. Comerțul electronic introduce trei mari avantaje:
universalitate , adică acceptabilitate oriunde în lume, pe baza unor standarde;
ușurința implementării;
aspectul prietenos față de utilizatori, folosind metode ergonomice, multimedia, etc
Comerțul electronic necesită calitate, securitate, fiabilitate și, mai presus de toate, posibilitatea punerii în practică a tuturor conceptelor criptografice valabile în securizarea tranzacțiilor în rețele. Marea problema a comerțului electronic în general și a celui pe Internet, în particular o reprezintă securitatea și, strâns legat de aceasta, sistemele de plați.
În toate aceste aplicații, card-urile inteligente joacă și vor juca un rol esențial.
Aplicație de tip Customer Relationship Management
Descrierea aplicației
Aplicația de tip CRM concepută pentru această lucrare are următoarele caracteristici:
Folosește o instanță de baze de date Oracle Real Application Clusters (A11204) versiunea 11.2.0.4
Sistem de operare Oracle Solaris x86_64 versiunea 10.
Este dezvoltată folosind proceduri stocate Java folosind JDK 1.8.0_46 și clasele de conectare la baza de date de tip JDBC (ojdbc6)
Clasele java au fost dezvoltate utilizând editorul Notepad++, iar modelul bazei a fost dezvoltat utilizând SQLDeveloper.
Funcția de criptare folosită este una simplă (demonstrativă) de tip Electronic Codebook (ECB) ce aplică o inversare de biți pe fiecare octet citit. La criptare pozițiile biților 2 și 3 (generate cu masca 0x0c) sunt schimbate cu pozițiile biților 6 și 7 (generate cu masca 0xc0). Funcția de decriptare efectuează operația inversă. Astfel, reiese un algoritm de criptare simetric cu o cheie de criptare 0x33, adică (non (0x0c) AND non (0xc0)). Operația de decriptare va repune biții în poziția inițială de dinainte de criptare.
Clasa CodeIf – metoda de criptare și decriptare cu scriere în fișier
import java.io.*;
public class CodeIf {
public static void main(String[] args) throws IOException {
BufferedReader in = null;
BufferedWriter out =null;
try {
in = new BufferedReader(new FileReader("input.txt"));
out = new BufferedWriter(new FileWriter("output.txt"));
int i=1;
int c,t1,t2;
int m1=0x0c;
int m2=0xc0;
int m3=0x33; // (~m1)&(~m2);
while ((c = in.read()) != -1) {
t1=c&m1;
t2=c&m2;
t1=t1<<4; t2>>=4;
c=c&m3;
c|=t1;
c|=t2;
out.write(c);
}
} finally {
if (in != null) {
in.close();
}
if (out != null) {
out.close();
}
}
}
}
În consecință, dacă în fișierul input.txt se va introduce textul “Acesta este un text criptat”, atunci output.txt va conține: “'e7t% e7te uæ te´t '6¥4t%t”. Inversând fișierele de output și input și rulând din nou programul se va obține textul original. La nivelul bazei de date aceasta metodă este similară cu cea de scriere/citire din fișier, doar că în cadrul aplicației ea este chemată de alte metode responsabile cu insertul/update-ul/selectarea din baza de date, astfel citirea și scrierea din bază făcându-se criptat.
Modelul relațional este unul simplu format din 4 tabele: Clienți, Articole, Comenzi și un tabel de legătură Comenzi_Articole (descriind articolele comandate (preț, cantitate) de către client pe fiecare comandă – Facturi)
Securizarea aplicației constă în următoarele două aspecte:
Scrierea și citirea din și în baza de date se face criptat astfel încât datele nu sunt stocate în clar, neavând nici o semnificație pentru utilizatorul care le vizualizează direct din baza de date
Accesul aplicației la baza de date se face numai prin intermediul procedurilor stocate care sunt responsabile pentru inserarea, ștergerea, updatarea altor operațiuni prin intermediul procedurilor stocate java. Acestea sunt constituite în librării și puse la dispoziția dezvoltatorului aplicației, putând fi aplicate web, desktop etc. În figura de mai jos este descris flowchart-ul unui apel cu o interogare dintr-o procedură stocată java la o bază de date Oracle.
În continuare vom folosi noțiunile metodă (funcție sau rutină în limbajul Java) cu proceduri (proceduri stocate în limbajul PL/SQL) în mod interșanjabil deoarece procedurile Java vor deveni proceduri stocate ale bazei de date ca orice altă procedură stocată PL/SQL.
Clasa CodeIf – metoda de criptare și decriptare cu scriere în fișier
public static String codificare (String s) throws IOException {
StringReader in = new StringReader(s);
StringWriter out= new StringWriter();
try {
int c,t1,t2;
int m1=0x0c;
int m2=0xc0;
int m3=0x33; // (~m1)&(~m2);
while ((c = in.read())!= -1) {
t1=(c&m1)<<4;
t2=(c&m2)>>4;
c=c&m3;
c|=t1;
c|=t2;
out.append((char)c);
}
} finally {
if (in != null) {
in.close();
}
if (out != null) {
out.close();
}
return out.toString();
}
}
}
Metoda de criptare și decriptare cu scriere în baza de date
public static String codificare (String s) throws IOException {
StringReader in = new StringReader(s);
StringWriter out= new StringWriter(); try {
int c,t1,t2;
int m1=0x0c;
int m2=0xc0;
int m3=0x33; // (~m1)&(~m2);
while ((c = in.read())!= -1) {
t1=(c&m1)<<4;
t2=(c&m2)>>4;
c=c&m3;
c|=t1;
c|=t2;
out.append((char)c);
}
} finally {
if (in != null) {
in.close();
}
if (out != null) {
out.close();
}
return out.toString();
}
}
În continuare vom prezenta câteva metode ce vor constitui librării ce vor fi puse la dispoziția dezvoltatorilor aplicației. Spre exemplu procedurile de inserare clienți și respectiv inserare articole. Se poate observa chemarea metodei codificare.
Metoda de inserare clienți
public static void adaugaClient (int codClient, String numeClient, String strada, String oras, String tara, String codPostal, String telefon) throws SQLException,IOException
{
String sql = "INSERT INTO Clienti VALUES (?,?,?,?,?,?,?)";
try
{
Connection conn = DriverManager.getConnection("jdbc:oracle:thin:ap/ap@//cgheban-sol1.ro.oracle.com:1521/A11204.ro.oracle.com");
PreparedStatement pst = conn.prepareStatement(sql);
pst.setInt(1, codClient);
pst.setString(2, codificare(numeClient));
pst.setString(3, codificare(strada));
pst.setString(4, codificare(oras));
pst.setString(5, codificare(tara));
pst.setString(6, codificare(codPostal));
pst.setString(7, codificare(telefon));
pst.executeUpdate();
pst.close();
}
catch (SQLException ex)
{System.err.println(ex.getMessage());}
}
Metoda de inserare articol
public static void adaugaArticol (int codArticol, String descriere, float pret) throws SQLException,IOException
{
String sql = "INSERT INTO Articole VALUES (?,?,?)";
try
{
Connection conn = DriverManager.getConnection("jdbc:oracle:thin:ap/ap@//cgheban-sol1.ro.oracle.com:1521/A11204.ro.oracle.com");
PreparedStatement pst = conn.prepareStatement(sql);
pst.setInt(1, codArticol);
pst.setString(2, codificare(descriere));
pst.setFloat(3, pret);
pst.executeUpdate();
pst.close();
}
catch (SQLException ex)
{
System.err.println(ex.getMessage());
}
}
Sau spre exemplu o metodă de verificare a existentei unui articol în stoc – adică o interogare a bazei. Această metodă apelează la rândul său metoda afiseazăRezultate () utilizată la formatarea interogării, care la rândul ei cheamă metoda codificare() responsabilă pentru scrierea/citirea criptată din și în baza de date.
Metoda de vizualizare stocuri
public static void verificaArticolStoc (int codArticol) throws SQLException, IOException {
String sql = "SELECT C.NrComanda, C.CodClient, L.CodArticol,L.NrInreg, L.Cantitate, L.Discount FROM Comenzi C, Comanda_Articol L WHERE C.NrComanda = L.NrComanda AND L.CodArticol = ?";
try
{
Connection conn = DriverManager.getConnection("jdbc:oracle:thin:ap/ap@//cgheban-sol1.ro.oracle.com:1521/A11204.ro.oracle.com");
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, codArticol);
ResultSet rset = pstmt.executeQuery();
afiseazaRezultate(rset);
rset.close();
pstmt.close();
}
catch (SQLException ex)
{
System.err.println(ex.getMessage());
}
În cele din urmă, mai există și o procedură mai complexă, care are ca scop afișarea unui raport privitor la numărul total de comenzi, grupat pe clienți. Din nou metoda afiseazăRezultate () este responsabilă pentru afișarea rezultatelor prin decriptarea lor. Aceasta este folosita pentru o interogare mai complexa folosind o funcție de grup in interogarea SQL (GROUP BY) :
Metoda totalComenzi
public static void totalComenzi () throws SQLException, IOException
{
String sql = "SELECT C.NrComanda, ROUND(SUM(A.Pret * L.Cantitate)) AS TOTAL " +
"FROM Comenzi C, Comanda_Articol L, Articole A " +
"WHERE C.NrComanda = L.NrComanda AND L.CodArticol = A.CodArticol " +
"GROUP BY C.NrComanda";
/*SELECT C.NrComanda, ROUND(SUM(A.Pret * L.Cantitate)) AS TOTAL FROM Comenzi C, Comanda_Articol L, Articole A
WHERE C.NrComanda = L.NrComanda AND L.CodArticol = A.CodArticol
GROUP BY C.NrComanda;*/
try
{
Connection conn = DriverManager.getConnection("jdbc:oracle:thin:ap/ap@//cgheban-sol1.ro.oracle.com:1521/A11204.ro.oracle.com");
PreparedStatement pstmt = conn.prepareStatement(sql);
ResultSet rset = pstmt.executeQuery();
afiseazaRezultate(rset);
rset.close();
pstmt.close();
}
catch (SQLException ex)
{ System.err.println(ex.getMessage());
}
}
Metoda afiseazaRezultate() este responsabila pentru afișarea si decriptarea rezultatului. După cum se poate observa, ea apelează metoda de criptare/decriptare codificare(rset.getString(i)) :
Metoda afiseazaRezultate
static void afiseazaRezultate (ResultSet rset) throws SQLException, IOException
{
String buffer = "";
try
{
ResultSetMetaData rsmd = rset.getMetaData();
int nr_coloane = rsmd.getColumnCount(), rows = 0;
for (int i = 1; i <= nr_coloane; i++)
{
int size = rsmd.getPrecision(i);//Get the designated column's specified column size.
String nume_Coloana = rsmd.getColumnLabel(i); //returneaza nume coloana
if (nume_Coloana.length() > size)
size = nume_Coloana.length();//returneaza nr de coloane al result set-ului
while (nume_Coloana.length() < size)
nume_Coloana += " ";
buffer = buffer + nume_Coloana + " ";
}
buffer = buffer + "\n";
while (rset.next())
{
rows++;
for (int i = 1; i <= nr_coloane; i++)
{
int size = rsmd.getPrecision(i);
String nume_Coloana = rsmd.getColumnLabel(i);
String columnType=rsmd.getColumnTypeName(i);
String val = "";
if (columnType!="NUMBER")
val = codificare(rset.getString(i)); //daca tipul de date nu este number se codifica
else
val = rset.getString(i);
if (nume_Coloana.length() > size)
size = nume_Coloana.length();
while (val.length() < size)
val += " ";
buffer = buffer + val + " ";
}
buffer = buffer + "\n";
}
if (rows == 0)
buffer = "Nu s-au gasit date!\n";
System.out.println(buffer);
}
catch (SQLException ex)
{ System.err.println(ex.getMessage());}
}
Cantitatea comandata de client poate fi modificata cu metoda modificaCantitate()
Metoda modificaCantitate
public static void modificaCantitate (int cantitateNoua, int nrComanda, int codArticol) throws SQLException
{
String sql = "UPDATE Comanda_Articol SET Cantitate = ? " +
"WHERE NrComanda = ? AND CodArticol = ?";
try
{
Connection conn = DriverManager.getConnection("jdbc:oracle:thin:ap/ap@//cgheban-sol1.ro.oracle.com:1521/A11204.ro.oracle.com");
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, cantitateNoua);
pstmt.setInt(2, nrComanda);
pstmt.setInt(3, codArticol);
pstmt.executeUpdate();
pstmt.close();
}
catch (SQLException ex)
{ System.err.println(ex.getMessage());}
}
Modelul relațional este unul simplu format din 4 tabele: Clienți, Articole, Comenzi și un tabel de legătură Comenzi_Articole și arătat mai jos împreună cu legăturile dintre tabele, constrângerile (constraints) și cheile primare/străine (PK/FK). Spre exemplu, tabela articole conține descrierea articolelor, codul lor și prețul, tabla Clienți date despre clienți, coloanele codarticol și codclient fiind chei primare în cele două tabele. Comenzile sunt înregistrate în tabela Comenzi cu număr_comandă ca cheie primară, aceasta constituind cheie străină pentru tabela Comanda_Articol.
Instalarea aplicației
Instalarea aplicației se face prin rularea ca sysdba (administrator al bazei de date) a scripturilor de creare a tabelelor, respectiv popularea tabelelor. Instalarea aplicației presupune:
Crearea structurii tabelelor prin rularea procedurii creazaTabele.sql arătată mai jos. A se remarca faptul că user-ul AP creat de către procedura sql nu acordă decât drepturi de conectare utilizatorului aplicației (AP) prin proceduri java. Nici un altfel de drepturi nu sunt acordate utilizatorului aplicației pentru securizarea aplicației: dbms_java.grant_permission ('AP', 'SYS:java.net.SocketPermission', '10.171.68.146:1521', 'connect,resolve' );
Popularea tabelelor cu date demonstrative prin rularea procedurii populareTabele.sql
Compilarea clasei Java ce conține procedurile stocate Proceduri.java prin comanda: loadjava -v -u ap/ap Proceduri.java pe serverul de baze de date în directorul în care se află fișierul sursa Proceduri.java. Acesta compilează și încarcă procedurile stocate.
Crearea efectivă a procedurilor stocate PL/SQL, compilarea și publicarea lor.
Procedura pentru crearea tabelelor (creazaTabele.sql)
set echo on
drop user ap cascade;
GRANT create session TO ap IDENTIFIED BY "ap";
–grant dba to ap;
exec dbms_java.grant_permission ('AP', 'SYS:java.net.SocketPermission', '10.171.68.146:1521', 'connect,resolve' );
conn ap/ap
DROP TABLE ARTICOLE CASCADE CONSTRAINTS;
DROP TABLE CLIENTI CASCADE CONSTRAINTS;
DROP TABLE COMANDA_ARTICOL CASCADE CONSTRAINTS;
DROP TABLE COMENZI CASCADE CONSTRAINTS;
CREATE TABLE Clienti (
CodClient NUMBER(3) NOT NULL,
NumeClient VARCHAR2(50) NOT NULL,
Strada VARCHAR2(50) NOT NULL,
Oras VARCHAR2(20) NOT NULL,
Tara VARCHAR2(20) NOT NULL,
CodPostal VARCHAR2(10) NOT NULL,
Telefon VARCHAR2(12),
PRIMARY KEY (CodClient)
);
CREATE TABLE Comenzi (
NrComanda NUMBER(5),
CodClient NUMBER(3) REFERENCES Clienti,
DataComanda DATE,
DataLivrare DATE,
Strada VARCHAR2(50),
Oras VARCHAR2(20),
Tara VARCHAR2(20),
CodPostal VARCHAR2(10),
PRIMARY KEY (NrComanda)
);
CREATE TABLE Articole (
CodArticol NUMBER(4) PRIMARY KEY,
Descriere VARCHAR2(50),
Pret NUMBER(6,2)
);
CREATE TABLE Comanda_Articol (
NrInreg NUMBER(3),
NrComanda NUMBER(5) REFERENCES Comenzi,
CodArticol NUMBER(4) REFERENCES Articole,
Cantitate NUMBER(2),
Discount NUMBER(4,2),
PRIMARY KEY (NrInreg, NrComanda)
);
Procedura de populare tabele (populareTabele.sql)
SET SERVEROUTPUT ON
CALL dbms_java.set_output(2000);
BEGIN
–Articlole
AP.adaugaArticol(1010, 'Bielete fata', 245.00);
AP.adaugaArticol(1011, 'Piston fi108', 122.50);
AP.adaugaArticol(1012, 'Bucsa fi10', 388.25);
AP.adaugaArticol(1013, 'Garnitura C59', 201.75);
AP.adaugaArticol(1014, 'Manson Prindere', 73.50);
AP.adaugaArticol(1015, 'Bielete spate', 43.85);
AP.adaugaArticol(1016, 'O ring', 155.00);
AP.adaugaArticol(1017, 'Garnituri etansare', 17.95);
AP.adaugaArticol(1018, 'Segmenti', 36.75);
AP.adaugaArticol(1019, 'Lifter', 96.25);
AP.adaugaArticol(1020, 'Pompa ulei', 207.95);
AP.adaugaArticol(1021, 'Arbore cotit', 137.75);
AP.adaugaArticol(1022, 'Colier e10', 21.35);
AP.adaugaArticol(1023, 'Colier e50', 110.00);
AP.adaugaArticol(1024, 'Inele de prindere', 18.50);
AP.adaugaArticol(1025, 'Supape g50', 68.50);
AP.adaugaArticol(1026, 'Resort supape', 13.25);
AP.adaugaArticol(1027, 'Pompa benzina', 144.50);
COMMIT;
–Clienti
AP.adaugaClient(101, 'AAA Automobile Second Hand', 'Buleverdul Libertatii','Bucuresti', 'RO', '95923', '0212071212');
AP.adaugaClient(102, 'AutoQuest', 'Buleverdul Corneliu Coposu','Sebes', 'RO', '9285', '0215251211');
AP.adaugaClient(103, 'Tali Auto', 'Strada Heliade Radulescu','Medias', 'RO', '75874', '2558745');
AP.adaugaClient(104, 'Rally Auto', 'Strada Ion Ionescu','Cluj', 'RO', '34345', '0458733652');
COMMIT;
–Comenzi si Comanda_Articol
AP.adaugaComanda(30501, 103, '14-SEP-2001', '21-SEP-2001','Calea Mosilor 10','Bucuresti','RO','71080');
AP.adaugaComanda_Articol(01,30501,1011,5,0.02);
AP.adaugaComanda_Articol(02,30501,1018,25,0.10);
AP.adaugaComanda_Articol(03,30501,1026,10,0.05);
AP.adaugaComanda(30502, 102,'15-SEP-2001', '22-SEP-2001','Doamna Ghica nr.2','Bucuresti', 'RO', '94335');
AP.adaugaComanda_Articol(01, 30502, 1013, 1, 0.00);
AP.adaugaComanda_Articol(02, 30502, 1014, 1, 0.00);
AP.adaugaComanda(30503, 104, '15-SEP-2001', '23-SEP-2001','Sos Bucuresti','Craiova', 'RO', '75234');
AP.adaugaComanda_Articol(01, 30503, 1020, 5, 0.02);
AP.adaugaComanda_Articol(02, 30503, 1027, 5, 0.02);
AP.adaugaComanda_Articol(03, 30503, 1021, 15, 0.05);
AP.adaugaComanda_Articol(04, 30503, 1022, 15, 0.05);
AP.adaugaComanda(30504, 101, '16-MAR-2001', '23-MAR-2001','Calea Rahovei 10', 'Sebes', 'RO', '95309');
AP.adaugaComanda_Articol(01, 30504, 1025, 20, 0.10);
AP.adaugaComanda_Articol(02, 30504, 1026, 20, 0.10);
COMMIT;
END;
/
Procedura de publicare a procedurilor (publicare_clase_java.sql)
CREATE OR REPLACE PACKAGE AP AS
PROCEDURE codificare (s VARCHAR2);
PROCEDURE adaugaClient (CodClient NUMBER, NumeClient VARCHAR2, Strada VARCHAR2, Oras VARCHAR2, Tara VARCHAR2, CodPostal VARCHAR2,Telefon VARCHAR2);
PROCEDURE adaugaArticol (CodArticol NUMBER, Descriere VARCHAR2, Pret NUMBER) ;
PROCEDURE adaugaComanda (NrComanda NUMBER, CodClient NUMBER,DataComanda VARCHAR2, DataLivrare VARCHAR2, Strada VARCHAR2, Oras VARCHAR2, Tara VARCHAR2, CodPostal VARCHAR2);
PROCEDURE adaugaComanda_Articol (NrInreg NUMBER, NrComanda NUMBER, CodArticol NUMBER, Cantitate NUMBER, Discount NUMBER);
PROCEDURE totalComenzi;
PROCEDURE verificaArticolStoc (CodArticol NUMBER);
PROCEDURE modificaCantitate (cantitateNoua NUMBER, nrComanda NUMBER, CodArticol NUMBER);
PROCEDURE stergeComanda (NrComanda NUMBER);
END AP;
Procedura de publicare a pachetelor (package_body.sql)
CREATE OR REPLACE PACKAGE BODY AP AS
PROCEDURE adaugaClient (CodClient NUMBER, NumeClient VARCHAR2, Strada VARCHAR2, Oras VARCHAR2, Tara VARCHAR2, CodPostal VARCHAR2,Telefon VARCHAR2) AS LANGUAGE JAVA
NAME 'Proceduri.adaugaClient(int, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String)';
PROCEDURE adaugaArticol (CodArticol NUMBER, Descriere VARCHAR2, Pret NUMBER) AS LANGUAGE JAVA
NAME 'Proceduri.adaugaArticol(int, java.lang.String, float)';
PROCEDURE adaugaComanda (NrComanda NUMBER, CodClient NUMBER,DataComanda VARCHAR2, DataLivrare VARCHAR2, Strada VARCHAR2, Oras VARCHAR2, Tara VARCHAR2, CodPostal VARCHAR2)
AS LANGUAGE JAVA
NAME 'Proceduri.adaugaComanda(int, int, java.lang.String, java.lang.String, java.lang.String, java.lang.String,java.lang.String, java.lang.String)';
PROCEDURE adaugaComanda_Articol (NrInreg NUMBER, NrComanda NUMBER, CodArticol NUMBER, Cantitate NUMBER, Discount NUMBER)
AS LANGUAGE JAVA
NAME 'Proceduri.adaugaComanda_Articol(int, int, int, int, float)';
PROCEDURE totalComenzi
AS LANGUAGE JAVA
NAME 'Proceduri.totalComenzi()';
PROCEDURE verificaArticolStoc (CodArticol NUMBER) AS LANGUAGE JAVA
NAME 'Proceduri.verificaArticolStoc(int)';
PROCEDURE modificaCantitate (cantitateNoua NUMBER, nrComanda NUMBER, CodArticol NUMBER) AS LANGUAGE JAVA
NAME 'Proceduri.modificaCantitate(int, int, int)';
PROCEDURE stergeComanda (NrComanda NUMBER) AS LANGUAGE JAVA
NAME 'Proceduri.stergeComanda(int)';
END AP;
Rularea aplicației
După instalarea aplicației și popularea tabelelor se poate observa că la nivelul bazei de date informațiile sunt stocate criptat după cum urmează: (o interogare in tabela comanda_articol):
Tabela articole:
Tabela clienți:
Tabela comenzi:
Tabela comanda_articol:
Verificarea unui articol din stoc se realizează cu procedura: exec AP.verificaArticolStoc(codArticol). Spre exemplu: execuția procedurii AP.verificaArticolStoc(1025) returnează:
Sau, o interogare din tabela CLIENT returnează evident in mod criptat:
În schimb, iată ce este returnat prin metoda vizualizareClienti() sau vizualizareClient(cod_client)- textul in clar:
Mai jos iată un raport mai complex cum ar fi: apelarea procedurii totalComenzi(), care decriptează și returnează datele grupate per identificatorul comenzii ; coloana 2 total per comandă:
Exemplele de inserare a datelor în tablele CLIENT, ARTICOL, COMENZI sunt abundente în paragraful precedent, secțiunea popularea tabelelor.
Pentru modificarea, spre exemplu, a cantității comandate se poate utiliza metoda –modificarea cantității comandate, AP.modificaCantitate (int cantitateNoua, int nrComanda, int codArticol). De exemplu, apelarea metodei AP.modificaCantitate(25,3054,1025); se va modifica cantitatea comandată de la 20 la 25 de unități.
Concluzii
Folosind conceptele criptografiei, bazelor de date si cu ajutorul programării orientate obiect (limbajul Java), aplicația prezentata in aceasta lucrare si-a propus sa folosească un algoritm de criptare simetric si propriu. Acesta criptează datele existente in baza de date (modelate pentru o aplicație de tip CRM), facandul-le de neînțeles pentru persoanele neautorizate ce ar putea vizualiza informații confidențiale, si chiar si pentru operatorii acesteia. Doar utilizatorii care folosesc metodele furnizate stocat chiar in baza de date pot cripta, decripta, deci citi, scrie si modifica datele. Acest tip de tehnici sunt folosite pentru a spori securitatea aplicațiilor financiare care accesează bazele de date din bănci si instituții financiare, dar si nefinanciare, cum ar fi sistemele de telecomunicații si serviciile de informații.
Bibliografie
David Coffin – Expert Oracle and Java Security- Programming Secure Oracle Database Applications with Java- Apress
Securitatea comerțului electronic – Victor Valeriu Patriciu, Ion Bica si al. Editura All.
Documentația Oracle 11g R2 disponibila la www.oracle.com.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Securitatea Aplicatiilor Economice Bazate pe Sisteme de Gestiune a Bazelor de Date (ID: 123811)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.
