1. Introducere in securitatea informatiei

Putem privi securitatea – securitatea datelor, securitatea comunicațiilor, în general securitatea informației de orice fel – ca un lanț. Securitatea întregului sistem este o combinație puternică de legături slabe. Totul trebuie securizat: algoritmii criptografici, protocoalele, programele de administrare etc. Dacă, de exemplu, algoritmii sunt puternici, însa sunt probleme cu generatorul de numere aleatoare, orice criptanalist va ataca sistemul pe aceasta cale. Dacă nu sunt securizate locațiile de memorie care conțin cheia, criptanalistul va sparge sistemul utilizând această slăbiciune. În timp ce proiectantul securității unui sistem trebuie să identifice toate căile posibile de atac și să le asigure, un criptanalist are nevoie doar de o singură slabiciune pentru a pătrunde în sistem.

Criptografia este doar o parte a securității. Ea acoperă problematica realizării securității unui sistem, ceea ce este diferit de ceea ce înseamnă realizarea unui sistem securizat. Tradiționala imagine a criptografiei ca “spion” în tehnologie este destul de departe de realitate. Peste 99% din aplicațiile criptografice utilizate în lume nu protejează secrete militare. Ele sunt întâlnite în bănci, plați on-line, taxe de drum, acces la terminale, contoare de electricitate etc. Rolul criptografiei în aceste aplicații este de a împiedica efectuarea de furturi și înșelăciuni. În cele mai multe dintre aceste aplicații s-a utilizat prost criptografia, atacurile reușite neavând însă nimic în comun cu criptanaliza. Chiar și NSA a admis că marea parte a erorilor apărute în activitățile sale provin din erorile de implementare și nu din algoritmi sau protocoale. În aceste condiții, nu contează cât de bună a fost criptografia, atacurile reușite anulând acest lucru și speculând erorile de implementare.

Orice algoritm de criptare poate fi implementat software. Dezavantajele constau în viteză, cost și ușurința în manipulare și modificare. Avantajul este oferit de flexibilitate și portabilitate, usurință în folosire și în efectuarea de upgrade-uri.

Programele criptografice pot fi copiate foarte ușor și instalate pe orice mașină și se pot încorpora în aplicații complexe, cum ar fi cele de comunicații și procesoarele de texte.

Programele de criptare software sunt foarte populare și sunt valabile pentru majoritatea sistemelor. Ele sunt destinate să protejeze fișiere individuale. Utilizatorul, în general, criptează și decriptează fișiere. Este important ca schema de administrare a cheilor să fie sigură. Cheile nu trebuie pastrate oriunde pe disc. Textele clare ce se cripteaza trebuie, de asemenea, sterse dupa efectuarea operatiei.

Până recent, toți producătorii de criptare își ofereau produsele sub forma unor cutii ce se atașau unei linii de comunicații și criptau toate datele de-a lungul liniei. Deși criptarea software devine tot mai dominantă, cea hardware este încă cea mai cerută în aplicațiile militare sau comerciale de mare importanță. NSA, de exemplu, autorizează doar criptări hardware. Motivele pentru care se întâmplă acest lucru sunt următoarele:

  • Viteza – Criptarea constă dintr-o mulțime de operații complicate ce se efectuează asupra unui șir de biți clar, operații care trebuie simulate într-un calculator. Cei doi algoritmi comuni de criptare, DES și RSA, lucrează ineficient pe procesoare normale. Dacă o serie de criptografi și-au făcut propriii algoritmi adaptați implementărilor software, hardware-ul specializat câștigă prin viteză. Criptarea, fiind un proces complex, prin introducerea unui chip sau a unui procesor dedicat, va rezulta un sistem mult mai rapid.

  • Securitatea – Un algoritm de criptare ce lucrează pe un calculator obișnuit nu are protecție fizică. Dispozitivele de criptare hardware sunt încapsulate, iar protecția se poate face destul de ușor. Chip-urile VLSI dedicate pot fi tratate chimic, astfel încât orice încercare de pătrundere poate distruge chip-ul. Radiația electromagnetică poate uneori arăta ce este în interiorul unei piese a unui echipament electronic. Dispozitivele de criptare pot fi ecranate, astfel încât să nu ofere informații la o astfel de încercare. Calculatoarele obișnuite pot fi ecranate la fel de bine, însă este o problemă mult mai complexă (programul este cunoscut sub numele de TEMPEST).

  • Ușurința în instalare – Se poate dori ca secretizarea să fie făcută pentru conversațiile telefonice, transmisiile de fax sau pentru legături de date. Chiar dacă datele criptate vin de la un calculator, este mai ușor de instalat un dispozitiv specializat, decât să se modifice sistemul software al calculatorului. Criptarea trebuie să fie invizibilă. Ea nu trebuie să fie accesibilă utilizatorului. Singura cale de a face acest lucru software este de a scrie criptarea în sistemul de operare, ceea ce nu este ușor. Pe de alta parte, chiar și unui calculator slab i se poate atașa un dispozitiv de criptare, între el și modem-ul de comunicație.

Cele trei lucruri de bază ale criptării hardware oferite pe piață sunt: module de criptare (care realizează operații de genul verificarea parolei sau administrare de chei pentru bănci), dispozitive dedicate de criptare pentru legături de comunicație și plăci atașate în calculatorul personal.

Există diferențe majore între dispozitive proiectate pentru criptare sincronă sau asincronă. Un dispozitiv nu va accepta niciodata o viteză a datelor mai mare decât cea pentru care a fost proiectat. În această familie de dispozitive există o serie de incompatibilități. Problema principală este dacă există compatibilitate între necesitățile particulare ale propriei aplicații și caracteristicile principale ale dispozitivului de criptare oferit.

Tot mai multe companii iși secretizează datele prin hardware specializat. Administrarea internă a cheilor pentru aceste dispozitive este în general sigură, deși sunt tot atâtea scheme câți producători sunt.

Astăzi, tehnicile de criptare a informației sunt suficient de puternice. Orice metodă de criptare poate fi întărită prin mărirea dimensiunii cheii de criptare.

Cele mai importante în zilele noastre par a fi criptarea eliptică, cea vocală, criptografia cuantică și criptografia ADN, etc. Puține microprocesoare au fost proiectate pentru a rula intern un algoritm de criptare. Toate PC-urile pot îndeplini cerințele hardware și software ale programelor moderne de criptare, în schimb majoritatea dispozitivelor portabile nu pot. Pentru acestea a fost dezvoltată o nouă clasă de algoritmi, cunoscută drept criptare eliptică, ce folosește o cheie de dimensiuni mai reduse și aritmetică facilă pentru microprocesorul de mai mică putere.

O dată cu creșterea traficului audio și de telefonie prin Internet a început să se dezvolte o nouă tehnologie: cea a criptării vocale. Cu un software adecvat, oricine poate să poarte convorbiri complet criptate cu un alt utilizat al rețelei de Internet.

Criptografia cuantică nu este un algoritm de criptare ci, mai degrabă, un mijloc de creare și distribuire a unor chei private. Bazată pe principiul incertitudinii a lui Heisenberg, ideea care stă la baza calcului și criptografiei cuantice este cea a utilizării mecanicii cuantice pentru schimbarea și securizarea de mesaje secrete. Principiul susține că fotonii de comunicație care se îndreaptă către un receptor nu pot fi deviați prin interceptare fără a crea o schimbare ireversibilă a stărilor cuantice ale sistemului. Bazele criptografiei cuantice datează din anii 1970, iar în domeniu au fost efectuate cercetări în laboratoare celebre cum ar fi cele de la Los Alamos, Universitatea din Geneva și Universitatea John Hopkins din Baltimore.

Domeniul care se ocupã de spargerea (decodificarea) cifrurilor se numeste criptanalizã (cryptanalysis) iar conceperea cifrurilor (criptografia) si spargerea lor (criptanaliza) sunt cunoscute global sub numele de criptologie (cryptology).

Atât criptarea cât și decriptarea sunt controlate de către una sau mai multe chei criptografice. Există două tipuri de sisteme criptografice:

  • simetrice (cu cheie secreta) care folosesc aceeași cheie, atât la criptarea cât și la decifrarea mesajelor

  • asimetrice (cu chei publice) care folosesc chei distincte de criptare și decriptare (dar legate una de alta). Una din chei este ținută secretă și este cunoscută doar de proprietarul ei. A doua cheie (perechea ei) este făcută publică, de unde și numele de criptografie cu cheie publică.

O unealtă importantă care ajută implementarea serviciilor de autentificare este semnătura digitală. O semnătură digitală este asemănătoare cu o semnătură obișnuită, doar că funcționează mult mai bine: când este folosită corect este dificil de falsificat și se comportă ca și cum ar fi iscălită pe întregul document, așa încât alterarea documentului ar duce la alterarea semnăturii. În contrast, o semnăturile obișnuite sunt extrem de ușor de falsificat și ocupă o mică parte din document.

Fig. 1 Modelul de criptare/decriptare

Un criptosistem care nu poate fi spart implică o criptanaliză cu succes imposibilă. Un astfel de sistem este cel care utilizează un cifru de tipul “one-time-pad”.

Poate părea surprinzător faptul că exista metode de criptare “perfecte”, însemnând că există dovezi matematici care atestă faptul că este imposibilă o criptanaliză. Termenul de “perfect” în criptografie înseamnă, de asemenea, că după ce un oponent primește textul cifrat nu are mai multă informație decât avea înainte să-l primească.

Totuși, pentru aceste metode practice există întotdeauna posibilitatea ca un cercetător inteligent sau chiar un hacker inteligent să spargă acel cod. De asemenea, criptanaliza poate sparge aceste metode folosind căutări exhaustive de tip “forță brută”. Singura problemă este timpul necesar spargerii acestora. Folosind algoritmi criptografici puternici, șansele sunt foarte mari să nu existe metode ușoare de spargere a sistemelor, iar criptanaliza de astăzi are nevoie de decenii sau chiar milenii sa spargă algorimii prin cautări exhaustive. Pentru a concluziona, cu metodele practice nu există garanții absolute ale securității dar experții se așteaptă sa rămână nesparte. Pe de altă parte, sistemele “one-time-pad” sunt considerate imposibil de spart.

2. Clasificarea criptosistemelor

După tipul cheilor folosite pentru criptare, respectiv decriptare, putem clasifica criptosistemele în două categorii: sisteme cu chei simetrice și sisteme cu chei publice.

2.1. Criptosisteme cu chei simetrice

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.

Fig. 2 Criptosistem cu cheie simetrică

Din acest motiv, acesti algoritmi mai sunt cunoscuti sub numele de algoritmi simetrici; pentru aplicarea lor este necesar ca înaintea codificãrii / decodificãrii, atât emitãtorul cât si receptorul sã posede deja cheia respectivã. În mod evident, cheia care caracterizeazã acesti algoritmi trebuie sã fie secretã.

Securitatea criptării simetrice depinde de protecția cheii. Managementul acestora este  un factor vital în securitatea datelor și cuprinde urmatoarele aspecte:

  • generarea cheilor – pot fi folosite, cu o tabelă de conversie, proceduri manuale (datul cu banul, aruncarea zarurilor), dar numai pentru generarea cheilor master (folosite pentru cifrarea cheilor). Pentru cheile de sesiune sau de terminal sunt necesare proceduri automate, de generare (pseudo) aleatoare, care se pot baza pe amplificatoare de zgomot, funcții matematice și diverși parametri (numărul curent al apelurilor sistem, data, ora etc).

  • distributia cheilor – cu privire la transportul cheii secrete, problema este în general rezolvată prin folosirea unei alte chei, numită cheie terminal, pentru a o cripta. Cheile de sesiune, generate numai pentru o comunicație, sunt transportate criptat cu cheile terminal care, de asemenea, pot fi protejate (când sunt memorate) cu altă cheie, numită cheie master.

  • memorarea cheilor – utilizarea algoritmilor simetrici, în cazul a N entități care doresc să comunice, implica n(n-1)/2 chei de memorat într-un mod sigur. În realitate, nu toate legăturile bidirecționale se stabilesc la același timp. Acesta este motivul pentru care se utilizează cheile de sesiune. Cheile terminal, care criptează numai date foarte scurte (chei de sesiune), sunt foarte dificil de atacat. Când sunt folosite chei publice, X500 pare cea mai buna soluție pentru managementul cheilor. Cheile publice sunt păstrate în directoare X500, ca certificate semnate cu o semnătură digitală a Autorității de certificare (Certificate Authority).

După tipul algoritmului folosit, criptosistemele cu chei simetrice pot fi clasificate în două categorii:

  1. Cu cifruri secvențiale

Textul în clar este considerat o succesiune de simboluri ale unui alfabet. Criptarea operează asupra textului în clar simbol cu simbol. La ieșire se va obține un șir de simboluri ale criptogramei. Cheia folosită într-un astfel de algoritm este generată cu un registru de deplasare cu reacție(RDR) care are starea inițială controlată de o cheie compactă.

  1. Cu cifruri bloc

Un cifru bloc este cifrul care operează pe grupuri de biți de dimensiune fixă(blocuri). Transformările de bază folosite pentru criptare şi decriptare sunt substituţiile şi transpoziţiile, repetate iterativ. Pentru a cripta un mesaj de o lungime diferită de cea a blocului, mesajul este partiţionat în componente de lungime egală cu cea a blocului, care sunt criptate şi concatenate pentru obţinerea mesajului criptat. Cele mai multe mesaje nu se împart exact în blocuri de o lungime fixă k (uzual între 32 și 128 biți) astfel încât ultimul bloc va avea o dimensiune mai mică. Pentru a rezolva acest neajuns se va folosi metoda numită “padding”. Această metodă constă în completarea textului în clar cu un șir de biți a căror structură este predefinită, astfel încât textul rezultat va avea o dimensiune egală cu un multiplu al dimensiunii blocului.

Întâlnim următoarele tipuri de sisteme de criptare cu algoritmi cu cheie secretă:

  • cifrul DES (DES simplu, DES cu sub-chei independente, DESX, DES generalizat GDES, DES cu cutii S alternative, DES cu cutii S dependente de cheie);

  • cifrul IDEA;

  • cifrul FEAL;

  • cifrul LOKI;

  • cifrul RC2.

2.2. Criptosisteme cu chei publice (asimetrice)

Un moment important în evoluția criptografiei moderne l-a constituit crearea, în anul 1976, de către Whitfield Diffie și Martin Hellman, cercetatori la Univeritatea Stanford din California, a unui principiu diferit de acela al cifrării simetrice. Ei au pus bazele criptografiei asimetrice cu chei publice. În locul unei singure chei secrete, criptografia asimetrică folosește două chei diferite, una pentru criptare, alta pentru decriptare.

Fig. 3 Criptosistem cu chei publice

Această caracteristică a dat algoritmilor cu cheie publică și numele de algoritmi asimetrici. În acest caz, una dintre chei poate fi publică (general cunoscută – poate fi distribuită oricui) iar cealaltă va trebui să fie privată/secretă (cunoscută doar de cel care o folosește). Fiecare dintre aceste chei poate cripta mesajul, dar un mesaj criptat cu o anumită cheie nu poate fi decriptat decât cu cheia sa pereche.

Astfel, în cazul utilizării unui algoritm asimetric în comunicarea dintre un emițător și un receptor, fiecare dintre aceștia va deține câte o pereche de chei – publică și privată. Emițătorul poate cripta mesajul cu cheia publică a receptorului, astfel încât doar acesta să poată decripta mesajul cu cheia sa privată. În cazul unui răspuns, receptorul va utiliza cheia publică a emițătorului astfel încât decriptarea să se poată face exclusiv de către emițător (cu cheia sa pereche, privată).

Cheile algoritmilor asimetrici sunt obținute pe baza unei formule matematice din algebra numerelor mari, pentru numere prime între ele, iar din valoarea unei chei nu poate fi dedusă valoarea cheii asociate. Remarcăm faptul că aplicarea în informatică a calculelor modulo numere prime s-a dovedit extrem de benefică pentru mulți algoritmi moderni.

Deoarece este imposibilă deducerea unei chei din cealaltă, una din chei este făcută publică, fiind pusă la îndemâna oricui dorește să transmită  un mesaj cifrat. Doar destinatarul, care deține cea de-a doua cheie, poate decripta și utiliza mesajul. Tehnica cheilor publice poate fi folosită și pentru autentificarea meajelor prin semnatură digitală, fapt care i-a sporit popularitatea. Întalnim urmatoarele tipuri de sisteme de criptare cu algoritmi cu cheie publica:

  • sisteme de cifrare exponențială RSA (Rivert-Shamir-Adleman);

  • cifrul EL GAMAL (EG);

  • standardul DSS de semnatură digitală.

  1. Arhitectura criptografică Java

Mediul Java a fost utilizat in vederea testarii mecanismului de criptare folosind sisteme de calcul cu procesoare Intel/AMD si sisteme de operare Windows/Linux.

API-ul de securitate al limbajului de programare Java este construit în jurul package-ului java.security. Acest API este construit astfel încât să permită dezvoltarea și încorporarea în programe a funcționalităților de securitate low-level și high-level.

Prima varianta a acestui API de securitate în JDK 1.1 a introdus JCA (Java Cryptography Architecture), un framework ce permite accesarea și dezvoltarea funcțiilor criptografice pentru platforma Java. În JDK 1.1, JCA includea API-uri pentru semnaturi digitale și message digest. În variantele următoare, Java 2 SDK a extins semnificativ JCA. De asemenea a îmbunătățit infrastructura de management a certificatelor pentru a suporta certificate X.509 v3. Noi optiuni au fost integrate in versiunile noi Java incepand cu Java 6-8.

Extensia criptografică Java(JCE) extinde JCA, incluzând API-uri pentru criptare, schimb de chei și MAC (Message Authentication Code). JCE împreună cu aspectele criptografice ale SDK constituie un API criptografic complet, independent de platformă.

Înainte de apariția versiunii 1.4 a J2SE, JCE era un pachet opțional. Actualmente instalarea este specifica variantelor de Java utilizate existand posibilitatea de a fi downlodat pentru versiunile curente de lucru Java 6-8 SE/EE, etc. si de asemenea pentru noua varianta Java SE9 (actualmente beta), estimat din toamna 2017.

Varianta actuala Java Cripthography Architecture este prezentata in detaliu la: https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html

3.1. Arhitectura

Arhitectura criptografică Java a introdus noțiunea de Provider de Servicii Criptografice. Termenul de provider (uzual) se referă la un package sau un set de package-uri care furnizează o implementare concretă a unui subset al aspectelor criptografiei din API-ul Security.

Spre exemplu, în JDK 1.1 un provider putea să conțină o implementare a unuia sau mai multor algoritmi care folosesc semnaturi digitale, message digest și generări de chei. Java 2 SDK adaugă 5 tipuri de servicii: key factories, crearea și managementul de keystore, managementul parametrilor, generarea parametrilor și certificate factories. De asemenea permite unui provider să furnizeze un algoritm de tip RNG (Random Number Generation).

Un program poate solicita un anumit tip de obiect (de exemplu, un obiect Signature) pentru un serviciu particular (cum ar fi algoritmul DSA) și să obțină implementarea de la unul din providerele instalate. Alternativ, programul poate solicita obiectele de la un anumit provider(fiecare provider are un nume care îl referă).

Versiunea JRE (Java Runtime Environment) a lui Oracle/Sun include un provider implicit, numit SUN/Oracle. Acest package include:

  • O implementare a algoritmului DSA (Digital Signature Algorithm)

  • O implementare a algoritmilor de tip message digest MD5 și SHA-1

  • Un generator de perechi de chei DSA pentru a genera o pereche formată dintr-o cheie publică și una privată, potrivite pentru algoritmul DSA

  • Un generator de parametri pentru algoritmul DSA

  • Un manager de parametri pentru algoritmul DSA

  • O key factory (fabrică de chei) care oferă conversii bidirecționale între cheile publice si private DSA și materialul care stă la baza cheii.

  • O implementare a SHA1PRNG – algoritm de generare de numere pseudo-aleatoare

  • Un path builder și validator pentru certificate X.509

  • O fabrică pentru certificate etc.

Fiecare instalare SDK are unul sau mai multe providere instalate. Noile providere pot fi adaugate static sau dinamic. JCA oferă un set de API-uri care permit utilizatorilor să vadă care providere sunt instalate și ce servicii oferă acestea.

Clienții pot configura JRE-ul cu diferite providere și să specifice o ordine a preferințelor pentru fiecare din acestea. Ordinea de preferință este ordinea în care providerele sunt căutate și le sunt solicitate servicii atunci cand nu este specificat un anumit provider.

O bază de date numită “keystore” poate fi folosită pentru managementul unui depozit de chei și certificate. Un keystore este disponibil aplicațiilor care au nevoie de el pentru autentificare și semnare.

Aplicațiile pot accesa un keystore printr-o implementare a clasei KeyStore, clasă care face parte din package-ul java.security. O implementare KeyStore default este oferită de către Sun Microsystems. Ea implementează acest keystore sub forma unui fișier, folosind un format specific numit “JKS”.

Aplicațiile pot alege diferite tipuri de implementări ale keystore de la diferite providere, folosind metoda getInstance, metodă existentă in clasa KeyStore.

3.2. Concepte

Metodele din clasele care implementează servicii criptografice sunt divizate în două grupe. Prima grupă de metode este API (Application Programming Interface). Ea constă în metode publice care pot fi foloste cu instanțe ale claselor. A doua grupă este SPI (Service Provider Interface), un set de metode care trebuie implementate de clasele derivate. Prin convenție, metodele SPI au nume care încep cu “engine”.

O clasă engine definește un serviciu criptografic într-o manieră abstractă (fără o implementare concretă).

Un serviciu criptografic este întotdeauna asociat cu un anume algoritm sau tip, fie oferind operații criptografice, generând sau furnizând material criptografic (chei, parametri) necesar operațiilor criptografice, fie generând obiecte (certificate, keystore) care încapsulează chei criptografice într-o manieră sigură. Spre exemplu, două dintre clasele engine sunt clasele Signature și KeyFactory. Clasa Signature oferă acces către funcționalitatea unui algoritm de semnătură digitală. KeyFactory DSA furnizează o cheie DSA publică sau privată într-un format folosit de metodele initSign sau initVerify, respectiv de un obiect DSA Signature.

JCA conține clasele package-ului de securitate Java SDK, inclusiv clasele engine. Utilizatorii API-ului solicită și folosesc instanțe ale claselor engine pentru a efectura operații corespunzătoare. Următoarele clase engine sunt definite în Java SDK:

  • MessageDigest: folosită să calculeze funcția hash a datelor specificate

  • Signature: folosită să semneze date și să verifice semnături digitale

  • KeyPairGenerator: folosită pentru a genera o pereche de chei publică și privată potrivită pentru un anume algoritm

  • KeyFactory: convertește chei criptografice opace de tip Key în specificații de chei(reprezentări transparente a substratului cheilor) și vice-versa.

  • CertificateFactory: folostește la crearea certificatelor de chei publice și a CRL-urilor (Certificate Revocation Lists).

  • KeyStore: creează și coordonează un keystore.

  • AlgorithmParameters: folosită sa coordoneze parametrii unui anumit algoritm, inclusiv codificarea/decodificarea parametrilor.

  • AlgorithmParameterGenerator: generează un set de parametri potrivit unui algoritm specificat.

  • SecureRandom: generează numere aleatoare sau pseudo-aleatoare.

O clasă engine conferă interfața către funcționalitatea unui anumit tip de serviciu criptografic. Ea definește metodele API care permit aplicațiilor să acceseze tipurile specifice de servicii criptografice. Actualele implementări (de la unul sau mai multe providere) sunt cele pentru anumiți algoritmi. De exemplu, clasa engine Signature oferă acces la funcționalitatea unui algoritm de semnătură digitală. Actuala implementare propusă de subclasa SignatureSpi se referă la un anumit algoritm, cum ar fi SHA-1 cu DSA, SHA-1 cu RSA sau MD5 cu RSA.

API-urile livrate de clasele engine sunt implementate în termenii unui SPI. Aceasta înseamnă că fiecărei clase engine îi corespunde o clasă abstractă SPI care definește metodele SPI pe care un provider trebuie să le implementeze.

O instanță a unei clase engine, un obiect API încapsulează o instanță a clasei corespondente SPI, obiectul SPI. Toate metodele API ale unui obiect API sunt declarate finale și implementarea lor invocă metodele SPI corespondente ale obiectului SPI încapsulat. O instanță a unei clase engine este creată prin apelul metodei getInstance a clasei engine.

Numele fiecărei clase SPI este același cu al clasei engine corespondente, urmată de Spi. Spre exemplu, clasa SPI corespunzătoare clasei Signature este clasa SignatureSpi.

Fiecare clasă SPI este abstractă. Pentru a implementa un anumit tip de serviciu, pentru un algoritm anume, un provider trebuie să mostenească acea clasă SPI corespunzătoare și să implementeze toate metodele abstracte.

3.2. Clase principale și folosirea lor

Clasa Security

Această clasă gestionează providerele instalate. Ea conține doar metode statice și nu este niciodată instanțiată. Metodele folosite pentru adaugarea sau ștergerea de providere și pentru setarea proprietăților de securitate pot fi executate doar de un program de încredere – “trusted program”. Acest program este fie o aplicație locală care nu rulează sub un manager de securitate, fie un applet sau o aplicație care are permisiunea de a executa respectivele metode.

Pentru ca un cod să fie considerat de încredere este nevoie ca appletului să i se acorde permisiunea pentru a efectua acea acțiune.

Metoda static Provider[] getProviders() returnează un tablou care conține toate providerele instalate, în ordinerea de preferință specificată în fișierul java.security. Un exemplu de configurare a acestui fișier folosit la varianta java de la Sun este următorul:

security.provider.1=sun.security.provider.Sun

security.provider.2=sun.security.rsa.SunRsaSign

security.provider.3=com.sun.net.ssl.internal.ssl.Provider

security.provider.4=com.sun.crypto.provider.SunJCE

security.provider.5=sun.security.jgss.SunProvider

security.provider.6=com.sun.security.sasl.Provider

security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI

security.provider.8=sun.security.smartcardio.SunPCSC

security.provider.9=sun.security.mscapi.SunMSCAPI

security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider

security.provider.11=oreilly.jonathan.crypto.Provider

Pentru a adăuga un nou provider se poate edita fișierul, adaugând în continuare următoarea linie:

security.provider.12=cryptix.jce.provider.Cryptix.

Similar, se poate edita fișierul pentru a elimina anumite Providere sau pentru a modifica ordinea.

O altă metodă de a adauga un nou provider de securitate implică folosirea uneia din următoarele metode:

static int addProvider(Provider provider) – adaugă un Provider la sfârșitul listei de Providere instalate. Metoda returnează poziția la care Providerul a fost instalat sau -1 daca nu a fost adăugat pentru că era deja instalat.

static int insertProviderAt(Provider provider, int position) – adaugă un nou Provider pe poziția specificată. Dacă providerul este instalat pe poziția solicitată, providerul care ocupa inițial acea poziție, împreună cu toate providerele care îl urmează vor fi shiftate cu o poziție spre sfârșitul listei. Metoda returnează poziția preferată pe care Providerul a fost adăugat sau -1 daca nu a fost adăugat pentru că era deja instalat.

Pentru a șterge un provider din listă se poate apela metoda:

static void removeProvider(String name) – elimină Providerul cu numele specificat și toate providerele aflate pe poziții mai mari decât poziția pe care se afla Providerul eliminat vor fi shiftate cu o poziție mai jos, către începutul listei.

Clasa Signature

Clasa Signature este o clasă engine care conferă funcționalitate unui algoritm de semnătură digitală precum DSA sau RSA cu MD5. Un asemenea algoritm primește date de intrare de dimensiuni variabile și o cheie privată, generând un scurt cuvânt(sub formă de octeți) numit semnătură, având următoarele proprietăți:

  • Dându-se cheia publică ce corespunde cheii private folosite să genereze semnătura, ar trebui să fie posibilă verificarea autenticității și integrității datelor de intrare.

  • Semnătura și cheia publică nu oferă informații cu privire la cheia privată.

Un obiect Signature poate fi folosit pentru a semna date. De asemenea, poate fi folosit pentru a verifica daca o anumită semnătură este semnătura autentică asociată datelor respective.

Aceste obiecte, fiind modale, au întotdeauna o stare dată care implică un singur tip de operație. Stările sunt reprezentate ca și constante finale întregi definite in clasele lor respective. Cele trei stări pe care le poate avea un obiect Signature sunt: UNINITIALIZED, SIGN, VERIFY.

Când este creat pentru prima dată, un obiect Signature se află în starea UNINITIALIZED. Pentru a crea un obiect Signature se apelează metoda static Signature getInstance(String algorithm), metodă ce se găsește în clasa Signature. Opțional, se poate specifica și numele unui provider sau clasa Provider, garantând faptul că implementarea algoritmului solicitat se află în respectivul provider:

static Signature getInstance(String algorithm, String provider)

static Signature getInstance(String algorithm, Provider provider)

Pentru a putea fi folosit, un obiect trebuie să fie inițializat. Clasa Signature definește două metode pentru inițializare, initSign și initVerify metode care schimbă starea în SIGN, respectiv în VERIFY. Dacă obiectul urmează să fie folosit pentru semnare, el trebuie să fie mai întâi inițializat cu cheia privată a entității a cărei semnături se dorește generată. Inițializarea se face prin apelul metodei:

final void initSign(PrivateKey privateKey)

Metoda va pune obiectul într-o stare SIGN.

În cazul în care obiectul Signature urmează a fi folosit pentru verificare, el trebuie să fie inițializat cu cheia publică a entității a cărei semnături trebuie verificată. Această inițializare se va face prin apelul uneia dintre următoarele metode, punând obiectul în starea VERIFY:

final void initVerify(PublicKey publicKey)

final void initVerify(Certificate certificate)

După ce obiectul a fost inițializat pentru semnare(se află în starea SIGN), datele care se doresc semnate pot fi livrate obiectului prin apeluri ale metodelor update:

final void update(byte b)

final void update(byte[] data)

final void update(byte[] data, int off, int len)

Apelurile trebuie realizate până când întregul volum de date care urmează a fi semnate au fost trimise către obiectul Signature.

Pentru generarea semnăturii se va apela una din metodele sign:

final byte[] sign()

final int sign(byte[] outbuf, int offset, int len)

Prima metodă va returna semnătura într-un array de tip byte. Cea de-a doua va stoca rezultatul într-un buffer outbuf, începând de la un offset specificat, len fiind numărul de octeți din buffer alocați semnăturii. Metoda va returna numărul de octeți stocați.

Apelul unei metode sign va reseta obiectul Signature la starea la care a fost inițializat. O dată resetat, obiectul este disponibil să genereze o nouă semnătură cu aceeași cheie privată, prin noi apeluri ale metodelor update și sign. Opțional, se poate face un nou apel initSig specificând o nouă cheie privată sau un apel initVerify pentru a inițializa obiectul în scopul verificării unei semnături.

Clasa KeyGenerator

Clasa KeyGenerator oferă funcționalitatea unui generator de chei simetrice. Generatoarele de chei sunt construite folosind una din metodele getInstance ale acestei clase.

Obiectele KeyGenerator sunt reutilizabile. După ce o cheie a fost generată, același obiect poate fi folosit pentru a genera alte chei.

Există două metode de a genera o cheie: într-un mod independent de algoritm sau într-un mod specific unui algoritm. Singura diferență dintre cele două moduri este inițializarea obiectului.

Toate generatoarele de chei împart conceptele de keysize și source of randomness. În această clasă există trei metode init care folosesc la inițializarea obiectelor KeyGenerator într-un mod independent de algoritm:

void init(int keysize)

Această metodă, primind ca parametru doar dimensiunea cheii, folosește implementarea SecureRandom a providerului instalat cu cel mai mare grad de prioritate ca sursă de aleatorizare(sau o sursă de aleatorizare oferită de sistem dacă niciunul dintre providerele instalate nu conțin o implementare SecureRandom).

Celelalte două metode init sunt următoarele:

void init(int keysize, SecureRandom random)

void init(SecureRandom random)

Pentru situațiile în care există un set de parametri specifici unui algoritm, există două metode init care primesc ca argument AlgorithmParameterSpec:

void init(AlgorithmParameterSpec params)
void
init(AlgorithmParameterSpec params, SecureRandom random)

Dacă utilizatorul nu inițializează în mod explicit un obiect KeyGenerator, fiecare provider trebuie să furnizeze și să documenteze o inițializare implicită.

Clasa SecureRandom

Clasa SecureRandom este o clasă engine care oferă funcționalitatea unui generator de numere aleatoare. Precum în cazul tuturor claselor engine, metoda de a obține un obiect SecureRandom este apelarea metodei statice getInstance din clasa SecureRando:

static SecureRandom getInstance(String algorithm)

Opțional, se poate specifica numele unui provider sau clasa Provider, fapt care va garanta că implementarea algoritmul de generare de numere aleatoare este din providerul numit:

static final SecureRandom getInstance(String algorithm,String provider)

static final SecureRandom getInstance(String algorithm,Provider provider)

Implementarea SecureRandom încearcă să aleatorizeze în mod complet starea internă a generatorului dacă utilizatorul nu folosește opțiunea de seed prin apelul metodei setSeed:

synchronized public void setSeed(byte[] seed)

public void setSeed(long seed)

După folosirea acestei opțiuni, obiectul SecureRandom va produce biți aleator, precum “sămânța” originală. În orice moment, un obiect SecureRandom poate fi “reînsămânțat” (re-seed) folosind una din metodele setSeed.

Pentru a obține octeți în mod aleator, programatorul furnizează un array de orice dimensiune care, mai apoi este umplut cu octeți aleatori:

synchronized public void nextBytes(byte[] bytes)

Dacă se dorește, este posibilă invocarea metodei generateSeed pentru a genera un număr dat de octeți de seed (spre exemplu, pentru seed-ul altor generatoare de numere aleatoare):

byte[] generateSeed(int numBytes)

Modul de integrare JCA in dezvoltarea aplicatiilor dedicate va fi prezentat in cadrul urmatoarelor rapoarte.

5. Bibliografie

  1. T. Băjenescu, M. Borda. Securitatea în informatică și telecomunicații. Cluj-Napoca : Dacia, 2001.

  2. DotNetSlackers. An inside look at Symmetric Encryption. DotNetSlackers. http://dotnetslackers.com/articles/security/AnInsideLookAtSymmetricEncryption.aspx.

  3. Lucks, Stefan. Attacking Triple Encryption. London : Springer-Verlag, 1998, Lecture Notes In Computer Science, Vol. 1372.

  4. NIST. Specification for the Advanced Encryption Standart. Computer Security Resource Center. 26 November 2001. http://www.csrc.nist.gov/publications/fips/fips197/fips-197.pdf.

  5. Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish). Schneier, Bruce. s.l.: Springer-Verlag, 1994, Fast Software Encryption, Cambridge Security Workshop Proceedings (December 1993).

  6. Savard, John. IDEA (International Data Encryption Algorithm). http://www.quadibloc.com/crypto/co040302.htm.

  7. Genetics Home Reference. [Interactiv] U.S. National Library of Medicine. http://ghr.nlm.nih.gov/handbook/basics/dna.

  8. Tatiana Hodorogea, Mircea-Florin Vaida, BLOOD ANALYSIS AS BIOMETRIC SELECTION OF PUBLIC KEYS, 7 th International Carpathian Control Conference ICCC’2006, Ostrava – Beskydy, Czech Republic, May 29-31, 2006, pp. 675-678,

  9. How to Implement a Provider for the JavaTM Cryptography Extension. Sun Microsystems. http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/HowToImplAJCEProvider.html.

  10. Microsystems, Oracle/Sun. Developer Resources for Java Technology. Certification Form for CSPs. http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/CertForm.txt.

  11. A Brief History of Cryptography. Cypher Research Laboratories Pty. Ltd. http://www.cypher.com.au/crypto_history.htm.

  12. Java Cryptography Architecture. Oracle/Sun Microsystems. http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html.

  13. Andreica, Alina. Internet Teorie. Facultatea de Studii Europene, Universitatea Babes-Bolyai Cluj-Napoca. http://www.euro.ubbcluj.ro/~alina/cursuri/internet-teorie/.

  14. Ashish Gehani, Thomas LaBean, John Reif. DNA-Based Cryptography. s.l.: DIMACS Series in Discrete Mathematics and Theoretical Computer Science, 1999, Vol. 54.

  15. DNA Alphabet. VSNS BioComputing Division. http://www.techfak.uni-bielefeld.de/bcd/Curric/PrwAli/node7.html#SECTION00071000000000000000.

  16. Hook, David. Beginning Cryptography with Java. s.l. : Wrox Press, 2005.

  17. Knudsen, Jonathan B. Java Cryptography. s.l. : O’Reilly, 1998.

  18. Wagner, Neal R. The Laws of Cryptography with Java Code. [PDF] 2003.

  19. Web Architecture. [Interactiv] School of Information, UC Berkeley. http://dret.net/lectures/web-fall08/.

  20. Cloud Garden – Jigloo GUI Builder. Cloud Garden (Java Resources). Cloud Garden. http://www.cloudgarden.com/jigloo/.

  21. Konheim, Alan G. Computer Security and Cryptography. New Jersey: John Wiley & Sons, Inc., 2007.

  22. Hodorogea Tatiana, Vaida Mircea-Florin, COMPLEXITY OF DNA ENCRYPTION SYSTEM AS A SUBSET OF JAVA CRYPTOGRAPHY EXTENSION, IASTED International Conference on Biomedical Engineering (BioMed 2008), 13-15 Feb., Innsbruck, Austria, paper 601-167, pp. 19-24

  23. Mircea-F. Vaida, Alexandra Vanea, Radu Terec, Raport tehnic privind Securitatea alternativa folosind mediul Java, RTH 09005, septembrie 2009, Laborator Helios, Director Mircea-Florin Vaida, Univ. Tehnica din Cluj-Napoca, ISSN: 1453-875X, pp. 82, ISSN 1454-0665

  24. Olga Tornea, Monica Borda, Tatiana Hodorogea, Mircea-Florin Vaida, ENCRYPTION SYSTEM WITH INDEXING DNA CHROMOSOMES CRYPTOGRAPHIC ALGORITHM, IASTED International Conference on Biomedical Engineering (BioMed 2010), 15-18 Feb., Innsbruck, Austria, paper 680-099, pp. 12-15

LASĂ UN RĂSPUNS

Vă rugăm să introduceți comentariul dvs!
Vă rugăm să introduceți numele aici