Securitatea
în noul JDK 1.1

Java furnizează clase și interfețe pentru implementarea efectivă a securității.

S-au scris multe articole despre securitatea Java și despre scrierea de programe sigure în Java. Majoritatea subiectelor s-au concentrat pe 3 metode de a asigura securitatea:
1. Mecanismul de „sandbox”, asigurat de limbajul Java compilat pe JDK 1.0
2. Mediul de compilare și de rulare Java.
3. Clasa Java Security Manager.

Începând cu JDK 1.1, Java furnizează un număr de clase și de interfețe pentru implementarea unei politici de securitate efective. Aceste tehnici cuprind interfețe criptografice pentru producerea și verificarea semnăturii, sumele de verificare criptografice (cryptografic checksum), de asemenea interfețe pentru controlul accesului.

Din cauza dorinței utilizatorilor de a avea un mediu sigur de dezvoltare a afacerilor, infrastructura trebuie să asigure un cadru minim de securitate. Elementele care trebuie asigurate sunt:
1. Identificarea si autentificarea: sunt procesele de asigurare a identității pentru fiecare parte a comunicării.
2. Controlul autorizării si accesului: este procesul de acordare si interzicere a drepturilor către o parte, pentru executarea unor acțiuni specifice.
3. Protecția privată: constă în asigurarea că detaliile tranzacției nu pot fi dezvăluite către a treia parte.
4. Protecția de integritate: constă în asigurarea că receptorul va respinge o tranzacție care este coruptă în mod accidental sau intenționat.
5. Non-repudierea: constă în asigurarea că o entitate nu poate fi împiedicată să devină o parte a unei tranzacții, după ce s-a angajat în mod voluntar în acea tranzacție.
6. Auditul: constă în păstrarea secretă a înregistrărilor detaliate ale evenimentelor pentru examinări viitoare.

Java devine rapid limbajul ales pentru dezvoltarea aplicațiilor care rulează pe Internet. Longevitatea limbajului depinde de mai mulți factori, cum ar fi disponibilitatea de a integra instrumente pentru implementarea politicilor de securitate ce reflectă dorințele particulare ale diferitelor organizații.

Modelul de încredere
înainte de JDK 1.1

De la începuturile sale limbajul Java a implementat un model eficient și simplu de securitate. Acest model, cunoscut de programatorii Java sub denumirea de „cutia de nisip” (sandbox), constă în următorul principiu integrat în mediul de rulare Java: tot ceea ce este local, este de încredere și tot ceea ce este descărcat de pe Internet este suspect. Cu alte cuvinte, sistemul de rulare Java are deplină încredere în aplicațiile Java și impune restricții apleturilor descărcate din rețea. Principala restricție impusă programelor suspecte este interzicerea accesului la fișierele locale. Această restricție se manifestă în mai multe moduri, incluzând restricția de a încărca fișiere locale cu extensia .class, de a lega librării locale și de a citi sau scrie fișiere locale.

Dilema cutiei cu nisip: a folosi sau a nu folosi.

Experiența arată că din punctul de vedere al politicii de securitate impunerea modelului cutiei de nisip este foarte importantă. Acest model protejează împotriva atacurilor răuvoitoare și a aplicațiilor defectuoase care pot șterge fișiere locale, întrebuința greșit informațiile private sau care pot consuma resursele sistemului. Mai mult, majoritatea aplicațiilor vor să interacționeze cu utilizatorul într-un mod personalizat. Acest lucru implică accesul aplicației la resurse locale.

Soluții la dilema cutiei cu nisip:

JavaSoft abordează dilema cutiei cu nisip în două versiuni ale JDK- ului. JDK 1.1 permite inițiatorului unui applet să semneze digital aplicația. Semnătura digitală furnizează appletului o amprentă digitală persistentă. Clientul care descarcă appletul poate alege să aibă încredere în applet și să-i permită accesul la resursele locale (fișiere, conexiuni pe rețea, ș.a.). De asemenea, clientul poate trata fiecare applet în mod diferențiat în funcție de semnătura digitală. Oricum, modelul de încredere pentru un applet dat rămâne binar. JavaSoft abordează această problemă în JDK 1.2 printr-o concepție mai fină a noțiunii de control. JDK 1.2 introduce conceptul de „domenii de protecție ”, care permite unui client să specifice exact care resurse devin transparente pentru un applet anume și ce se va întâmpla cu aceste resurse (scriere, citire, conectare, etc.).

Instrumente JDK 1.1
pentru semnarea appleturilor

JDK 1.1 furnizează două instrumente pentru semnarea appleturilor: javakey și jar. Javakey se folosește pentru a crea identități și pentru a le încărca în propria bază de date a identităților. Odată creată o identitate, utilizatorul o poate defini ca o identitate de încredere. Appleturile care sunt semnate de identități sigure sunt appleturi sigure. JDK 1.1 tratează appleturile de încredere ca și aplicații locale: aceste appleturi au acces la toate resursele transparente și pentru aplicațiile dezvoltate și rulate local. Folosind javakey, utilizatorul poate crea și o identitate de „semnător”(signer). Un signer este o identitate care posedă o cheie privată. Programatorul poate crea un signer pe server, înainte să semneze efectiv appletul.

Deși jar nu este un instrument de securitate este foarte folositor pentru împachetarea fișierelor, incluzând clasele Java, într-o singură entitate descărcabilă. Comanda jar furnizează aceleași funcțiuni ca și comanda tar din UNIX.

Pași în crearea appleturilor semnate

1. Crearea unei semnături de identitate și generarea perechii de chei.
Se folosește javakey pentru crearea unei semnături de încredere. În listingul 1, cu comanda 1 se creează o identitate numită OpenHorizon. După acest pas, trebuie generată o pereche de chei publice /private pentru acea identitate. Algoritmul ales pentru semnarea și verificarea semnăturii și lungimii cheii sunt parametrii importanți, contribuind la securitatea mediului utilizatorului. În listingul 1 cu comanda 2 se alege Algoritmul de Semnătură Digitală (Digital Signature Algorithm) cu o lungime a cheii de 1024 de biți. Cheile publice și private sunt memorate în fișiere numite oh.pub și oh.priv. Este foarte important ca fișierul de chei private să fie protejat.

2. Generarea unui certificat pentru cel care semnează.
Fiecare programator care semnează trebuie să aibă propria cheie publică certificată. Într-un mediu real PKI (Public Key Infrastructure), o autoritate certificatoare (Certification Authority) publică un certificat care leagă identitatea unui semnatar cu cheia publică a semnatarului. Însuși CA-ul poate deține o certificare publicată de o autoritate CA mai înaltă. Acest principiu se numește „lanț de încredere” și nu este suportat de JDK 1.1. În listingul 1, comanda 4 creează o auto-certificare și anume o certificare furnizată de identitatea lui OpenHorizon pentru el însuși. De remarcat că certificatele sunt publicate în conformitate cu un fișier specific. Directiva de certificare este prezentată în listingul 1, comanda [3]. Ea specifică, printre alte informații, o perioadă de validitate de 1 an, un număr serial (1100) și numele fișierului unde va fi stocat certificatul (oh.cert).

3. Crearea și semnarea arhivei.
Pentru pregătirea sistemului în vederea semnării apleturilor, trebuie urmați pașii 1 și 2. De fiecare dată când trebuie să creezi un applet semnat se vor urma pașii 3 și 4. În listingul 1, cu instrucțiunea 5 se creează un fișier jar pentru toate clasele comprimate a unui exemplu de software numit Ambrosia. Acest fișier țintă se va numi AmbrosiaSam ples.jar. Folosind instrucțiunea [7], se semnează fișierul jar cu cheie privată a unei identități a cărei nume apare în fișierul de semnătură (listat cu comanda [6]). Numele fișierului de semnătură ce apare la sfârșitul fișierului de semnătură este folosit pentru semnătura ca un fișier individual (OHSig.DSA). Fișierul de semnătură este inclus în fișierul jar.

4. Distribuirea arhivei semnate pe serverul Web.
Javakey creează un fișier cu același nume (AmbrosiaSamples.jar) și exetnsia .sig. Se va redenumi Ambrosia.jar.sig cu Ambrosia.jar, care este mai mult un nume potrivit pentru stocarea claselor semnate pe serverul Web. În listingul 1, cu instrucțiunea [8] vom redenumi fișierul jar. Listingul 2 arată fișierul HTML pentru appletul (ohpub.class) inclus în fișierul jar semnat.

Configurarea clientului.

Clientul trebuie configurat pentru a recunoaște și a valida semnatarul appletului. Listingul 3 afișează instrucțiunile javakey folosite pentru configurarea clientului. Se poate folosi un set diferit de instrucțiuni depinzând de browserul utilizat. Clientul poate obține fișierul de certificare (oh.cert în acest exemplu), înainte de a-l încărca în baza de date a identităților. (listingul 3 instrucțiunea [9] )

Arhitectura criptografică Java

În această secțiune vom vorbi despre Java Cryptographic Architecture (JCA). Figura 1 arată ierarhia de bază a JCA. Sunt trei clase ce formează fundamentul JCA: KeyPairGenerator, MessageDigest și Signature. Se poate observa că JCA nu include nici o clasă pentru criptarea efectivă. Motivul este că incluzând clase de criptare sau interfețe JDK-ul, ar putea deveni ne-exportabil. De aceea, JavaSoft a fost aleasă pentru a furniza un pachet adiacent numit Java Cryptographic Extensions (JCE), care este disponibil doar pentru clienții din Statele Unite și Canada.

JCA este bazată pe noțiunea de Cryptographic Package Providers (CPP). Clasele de bază ale JDK- ului și interfețele pot fi implementate de unul sau mai multe module CPP. JDK 1.1 vine cu o implementare implicită a algoritmilor DSA, MD5 și SHA. Alte module CPP pot furniza implementări pentru acești algoritmi sau pentru alții. Modulele CPP pot fi instalați static în timpul instalării JDK 1.1. Utilizatorul poate folosi metode din java.security.Security pentru o alternativă dinamică a metodelor prezentate mai sus.

Obținerea unei instanțe a clasei Engine

Toate cele trei clase au o metodă ce permite utilizatorului să instanțieze un obiect cu un algoritm și un furnizor specific. De exemplu, în listingul 4 linia 9 obținem o instanță a algoritmului de semnătură DSA furnizată implicit de CPP (în acest caz SUN). La dorință, se poate utiliza altă versiune a metodei getInstance pentru a numi un furnizor specific.

Date semnate și semnături verificate

Clasa Signature poate fi folosită pentru date semnate și pentru a verifica semnătura digitală a datelor. Când se instanțiază un obiect de tip Signature trebuie să-l inițializezi pentru a fi în starea SIGN sau VERIFY. Odată într-o stare dată, se aprovizionează clasa Signature cu câte informații dorește programatorul. După aprovizionarea cu informații se poate invoca, fie semnarea, fie verificarea metodei, pentru a asigura operațiile corespunzătoare. După ce datele au fost semnate sau verificate, obiectul Signature se întoarce la o stare neinițializată.

Informații semnate digital

Listingul 4 arată un segment de cod parțial pentru date semnate digital. Liniile 1 și 2 importă pachete de securitate necesare semnării datelor. Liniile 3 și 4 definesc 2 șiruri de baiți : unul reprezintă datele de intrare pentru a fi semnate, și celălalt, este semnătura digitală. La linia 9 se instanțiază un obiect Signature care implementează un algoritm DSA de furnizorul implicit (i.e. SUN). Linia 10 plasează obiectul în starea SIGN. Linia 11 alimentează obiectul cu date și linia 12 produce semnătura digitală. Se observă că dacă se primesc informațiile în avalanșă, să zicem de la utilizator, se poate apela metoda update de câte ori este necesar până când nu mai sunt informații. De asemenea, se observă că cheia privată ce este folosită pentru date, trebuie să fie încărcată (nu este arătat în cod) mai înainte de a chema metoda initSig. Se va folosi metoda KeyPair sau interfața Key, pentru a seta cheia privată.

Verificarea semnăturii digitale

Listingul 5 arată un segment de cod parțial pentru verificarea semnăturii digitale a unor date arbitrare. Liniile 1 și 2 importă pachetele de securitate necesare pentru verificarea semnăturii digitale ale datelor. Liniile 3 și 4 definesc 2 șiruri de baiți: unul reprezintă date de intrare a căror semnătură digitală trebuie verificată și celălalt șir reprezintă semnătura digitală actuală. Linia 6 definește o variabilă booleană care va fi setată de către metoda de verificare la true sau false depinzând de validitatea semnăturii. La linia 10 se instanțiază un obiect Signature care implementează algoritmul DSA de către furnizorul implicit (i.e. SUN). Linia 11 plasează obiectul în starea VERIFY. Linia 12 alimentează cu date obiectul și linia 13 verifică semnătura digitală. Din nou se observă că dacă se primesc informațiile în avalanșă, se poate apela metoda update de câte ori este necesar până când nu mai sunt informații. De asemenea, se observă că cheia privată ce este folosită pentru date, trebuie să fie încărcată (nu este arătat în cod) mai înainte de a chema metoda initVerify. Se va folosi metoda KeyPair sau interfața Key pentru a seta cheia publică.

Concluzii

JDK 1.1 furnizează un punct de start foarte bun pentru construirea unei infrastructuri de încredere. Securitatea Java este mai mult decât securitatea codului și principiul „cutiei de nisip”. Cu planul furnizat de JavaSoft de a asigura mai multă securitate claselor și interfețelor, Java se întărește pe poziția de limbaj de programare ales pentru dezvoltarea aplicațiilor bazate pe Internet.

Bibliografie:
http://www.javaworld.com/

BYTE România - februarie 1998

(C) Copyright Computer Press Agora