. Prezentare Generala Privind Semnaturile Digitale

Informatica

. Prezentare Generala Privind Semnaturile Digitale

Byadmin ianuarie 1, 2024

Index de figuri

Figura 1: Elementele componente ale unei semnături electronice XML avansate 52

Figura 2: Structura XML a unei semnături XAdES-BES 53

Figura 3: Structura XML a unei semnături XAdES-EPES 54

Figura 4: Elementele componente ale unei semnături electronice XML avansate complete 55

Figura 5: Elementele componente ale tipurilor de semnătură extinsă 56

Figura 6: Relația dintre formatul XAdES-X-L și forma de arhivare 57

Figura 7: Sintaxa unei semnături electronice cu validare și arhivare 58

Figura 8: Descrierea generală a pachetului de clase „Dsig” 60

Figura 9: Descrierea generală a pachetului de clase „Data” 62

Figura 10: Descrierea generală a pachetului de clase „XML” 66

Figura 11: Descrierea generală a pachetului de clase „Utils” 78

Figura 12: Descrierea generală a pachetului de clase „Crypto” 80

Figura 13: Descrierea generală a pachetului de clase „Transform” 81

Figura 14: Descrierea generală a pachetului de clase „Certificate” 84

Figura 15: Descrierea generală a pachetului de clase „Factory” 86

Figura 16: Descrierea generală a pachetului de clase „Exceptions” 87

Figura 17: Fluxul datelor și obiectelor pentru generarea unei semnături 87

Figura 18: Fluxul de date și obiecte pentru verificarea unei semnături 90

Figura 19: Frame-ul de configurare pentru aplicația de semnare 93

Figura 20: Fereastra de alegere a unui document XML 94

Figura 21: Ecranul de configurare după alegerea documentului 95

Figura 22: Frame-ul de alegere a datelor care vor fi semnate 96

Figura 23: Frame care prezintă structura unui document XML 97

Figura 24: Frame de introducere a informațiilor despre cheie 98

Introducere

Problematica semnării digitale

Înainte de a putea discuta despre semnătura digitală trebuie să explicăm noțiunea de semnătură și rolul pe care aceasta îl are în cadrul relațiilor inter-umane. De obicei, semnătura este o versiune stilizată a numelui unei persoane, scrisă pe documente și acționând ca o dovadă a identității persoanei respective, un fel de sigiliu personal, obținut prin scrierea de mână. O semnătură are rolul de a fi o probă privind proveniența unui anumit document și privind intențiile persoanei care a semnat realativ la respectivul document.

Însă o semnătură nu este suficientă, dacă cel care semneză nu poate să facă asocierea între caligrafia semnăturii și identitatea persoanei care a semnat. Această asociere poate fi făcută direct (dacă cele doi se cunosc și își pot recunoaște scrisul unul altuia) sau indirect, prin utilizarea unei a treia persoane, de încredere (de obiecei un notar public), care prin semnătura sa confirmă legătura dintre o persoană și semnătura acelei persoane.

Odată cu dezvoltarea industriei calculatoarelor a început să se pună probleme găsirii unei metode de a putea asocia și un document creat cu ajutorul unui editor de texte cu autorul său, fără a mai folosi suportul de hârtie.

Mai mult, după apariția Internetului și a posibilității de a stabili relații de afaceri la mare distanță, de cele mai multe ori fără a-l întâlni fizic pe cel cu care se realizează repectiva afacere, a condus și mai mult la dorința de eliminare a suportului de hârtie la încheierea contractelor. A rămas însă aceeași necesitate de a putea stabili o relație între identitatea unei persoane și intenția sa privind un anume document în format electronic. Deci, problema a rămas aceeași, doar contextul în care ea se manifestă s-a schimbat.

Cu alte cuvinte, semnătura digitală reprezintă mutarea unei vechi probleme, cea a ‚aplicării sigiliului’ în noua lume a calculatoarelor, a documentelor electronice și a Internet-ului. Modalitatea de rezolvare este și ea tot o traducere în format electronic a soluțiilor aplicate cu succes de-a lungul timpului.

Problematica descrierii unitare a datelor

Una din marile probleme ale transmiterii datelor între două sisteme informatice constă în modalitatea de prezentare a datelor respective. Deoarece lumea calculatoarelor este una eterogenă, trebuie ales formatul de prezentare care să conducă la aceeași interpretare a datelor indiferent de sistemul care face acea interpretare.

Mai mult chiar, un anumit șir de biți, deci o informație, poate avea o semnificație diferită chiar pe același calculator; să nu uităm că un număr întreg poate fi scris pe 1, 2, 4 sau 8 octecți.

Aproape singurul mod de reprezentare a informației care este interpretat în același fel de toate sistemele informatice este modul text. Un caracter este văzut la fel de toate calculatoarele, indiferent de arhitectura pe care se bazează sau de sistemul de operare care există pe acel calculator.

Însă în lumea calculatorelor un șir de caractere nu are o înțeles decât dacă se știe semnificația care trebuie acordată acelui text. Cu alte cuvinte, atunci când se dorește mai mult decât simpla afișare a unui text, datelor reprezentate de un șir de caractere trebuie să li se dea o anumită semnificație, calculatorului trebuie să i se explice cum anume trebuie să transforme șirul de caractere în informații pe care să le poată prelucra.

Următorul pas logic este acela de a sugera existența unui șir de caractere care să explice semnificația, ajungându-se în final la date care se auto-descriu. Astfel după citirea unui document text, un calculator și-ar putea extrage informațiile pe care trebuie să le proceseze și ar ști și ce modalități de procesare pot fi aplicate.

Deci, șirul de caractere nu are decât rolul de purtător al informațiilor, calculatoarele lucrând cu tipuri interne de date. Este treaba calculatorului sursă să genereze șirul de caractere astfel încât sarcina decodării informației să nu fie prea complicată sau să poată conduce la interpretări diferite.

Prezentare generală XML

EXtensible Markup Language, abreviat XML, este un limbaj de tip markup, folosit pentru descrierea datelor. El descrie o clasă de obiecte, numite documente XML, și modul în care un calculator ar trebui să proceseze informațiile din aceste documente XML.

XML poate fi descris ca un subset al SGML – Standard Generalized Markup Language. Spre deosebire de SGML, XML este mai simplu de implementat (un procesor de XML este mult mai simplu de construit si implementat decât un procesor de SGML) și din acest motiv poate fi folosit pentru transmiterea datelor în mediul web (implementarea unui procesor de SGML într-un browser web ar fi făcut procesarea informaților greoaie datorită complexității acestuia).

XML este tot un limbaj de tip markup ca și HTML. Însă spre deosebire de acesta din urmă, nu își propune să ofere o modalitate de prezentare a datelor ci își propune să ofere chiar datele. Tag-urile HTML sunt folosite numai pentru a oferi instrucțiuni despre cum trebuie prezentate informațiile dintr-o pagină web. Tag-urile din XML pot descrie datele. Dacă în HTML există un număr fix de tag-uri care pot fi folosite, in XML autorul documentului își crează propriile tag-uri, după cum consideră necesar pentru a face descrierea datelor pe care le conține documentul XML.

Cerințele de proiectare

XML a fost dezvoltat de un grup de lucru aflat sub auspiciile World Wide Web Consortium (W3C) în 1996. Vom prezenta în continuare principalele cerințe de proiectare ale acestui limbaj și modalitatea prin care fiecare din aceste cerințe este îndeplinită de versiunea actuală de XML.

posibilitatea de utilizare directă în Internet (fiind bazat tot pe tag-uri, ca și HTML, a fost ușor pentru dezvoltatorii de browsere să scrie procedurile care să parseze acest nou limbaj),

oferirea de suport pentru o gamă largă de aplicații (XML este un limbaj bazat pe text și cu reguli de sintaxă simple, iar astăzi o mulșime de aplicații folosesc documente XML pentru operațiile de schimb de date),

ușurința de a scrie programe care să proceseze documentele XML (datorită regulilor de sintaxă simple a fost foarte ușor să se scrie aplicații care să parseze documente XML)

ușurința de fi citite de oameni si claritatea documentelor XML (este un limbaj text și cu o structură arborescentă, singurul impediment în calea înțelegerii de către oameni poate fi doar inabilitatea autorilor de a alege tag-uri semnificative)

ușurința de a crea documente XML (documentele XML pot fi realizate cu orice editor de texte, dar există și multe aplicații dedicate)

Pe lângă aceste scopuri prevăzute înainte de proiectarea limbajului, autorii au mai ținut cont de încă două principii: primul dintre ele a fost principiul utilizării internaționale (și XML oferă suport pentru o gamă largă de caractere din alfabetele lumii, nu numai cel latin); al doilea scop suplimentar a fost acela de a permite modificarea la nivel global, într-un document complex, a anumitor informații prin folosirea unui limbaj de script – cum ar fi Perl.

Sintaxa unui document XML

Regulile de sintaxă ale XML-ului sunt foarte simple și foarte stricte. Regulile sunt foarte ușor de învățat și foarte ușor de utiliazat. Din acest motiv este foarte ușoară crearea unui software care să citească și să manipuleze documente XML, de altfel aceasta find unul din scopurile de proiectare ale limbajului.

Documentele XML au o sintaxă simplă, care se auto-descrie. Vom ilustra acest lucru printr-un exemplu foarte simplu:

<?xml version="1.0" encoding="ISO-8859-1"?>

<destinatar>Popescu</destinatar>

<expeditor>Ionescu</expeditor>

<titlu>Reamintire</titlu>

<cuprins>Ne vedem în weekend</Cuprins>

</telegrama>

Prima linie din acest document conține declarația XML (conține versiunea de XML folosită și modul de codare a caracterelor din acest document). În acest exemplu, avem de a face cu un document XML care respectă specificațile XML versiunea 1.0 și folosește setul de caractere ISO-8859-1 (alfabetul latin, folosit in Europa de vest).

Reguli de sintaxă

Elementul rădăcină – telegramă – conține patru elemente fiu – destinatar, expeditor, titlu și cuprins. După cum se poate oberva toate elementele XML trebuie să aibă tagul de încheiere. Spre deosebire de HTML, unde unele tag-uri de final puteau fi omise. Acest lucru nu se aplică liniilor de declarație, pentru că, practic, ele nu aparțin documentului. Există o singură abatere de la această regulă, și anume cazul unui element vid (fără fii, atribute sau valoare). În acest caz este permis să se scrie, de exemplu, <titlu/>, în loc de <titlu></titlu>.

Tot spre deosebire de HTML, în XML tag-urile sunt case-sensitive, adică o literă mare este diferită de o literă mică, deci un tag <Telegrama> este diferit de un tag <telegrama>.

Toate elementele XML trebuie închise în ordinea exact inversă a deschiderii lor. Adică tag-ul de final al unui element nu poate apărea decât după apariția tag-urilor de final ale tuturor fiilor acelui element.

Toate documentele XML conțin unul și numai un element rădăcină. Toate celelalte elementele trebuie să fie conținute în cadrul acestui document rădăcină sau în cadrul fiilor acestui element.

Elementele pot avea asociate atribute. Fiecare atribut are o anumită valoare. Toate valorile atributelor trebuie trecute între ghilimel,. indiferent dacă valoarea acelui atribut reprezintă un șir de caractere, un număr sau o dată calendaristică.

În XML spațiile sunt păstrate. Spre deosebire de HTML, unde mai multe caractere de spațiu erau reduse la unul singur, acest lucru nu se întâmplă în XML. De asemenea, perechea CR / LF este redusă la LF.

Ca orice alt limbaj, XML oferă posibilitatea prezenței comentariilor. Acestea încep cu <!– și se termină cu –>.

Structuri

Structuri fizice

Din punct de vedere fizic, un document XML este compus din una sau mai multe unități de stocare, numite ‚entități’. Fiecare entitate are un ‚conținut’ și sunt identificate printr-un ‚nume’.

Fiecare document XML are o entitate numită ‚entitatea document’, care este punctul de plecare pentru un procesor XML și care poate conține întreg documentul.

Fiecare entitate poate fi fie o entitate finală (care nu mai trebuie parsată de către procesorul XML), fie o entitate care, pentru a căpăta sens trebuie să fie parsată de către trebuie să fie parsată de către procesorul XML. Prin procesor XML se înțelege un program care interpretează documentele XML.

O entitate poate să conțină referințe către alte entități incluse în document. Bineînțeles că, pentru a evita blocarea procesorului XML într-o buclă infinită, o entitate nu poate conține o referință către ea însăși nici direct, nici indirect (adică, lanțul de entități referite nu poate conține cicluri).

Una din particularitățile XML, care îl transformă într-o modalitate convenabilă de transmitere a datelor este faptul ca entitățile au o structură și un comportament asemănător obiectelor din limbajele de programare orientate pe obiecte. Ele pot fi descrise în echivalentul unei clase, cu ajutorul definițiilor DTD sau XMLSchema, pot fi verificate, se pot referi unele pe altele.

Structura ierarhică a unui document XML poate fi extinsă fără probleme. Unei entități i se poate adăuga un fiu fără nici o problemă, atât timp cât se respectă regulile de sintaxă ale limbajului.

Entitățile pot fi folosite pentru a defini porțiuni de text care sunt folosite mai des în cadrul documentului, pentru a defini un literal pentru diverse caractere UNICODE.

Structuri logice

Din punct de vedere logic, un document XML conține unul sau mai multe elemente delimitate de tag-urile de început și sfârșit. Fiecare element are un tip identificat prin nume, și poate avea specificat un set de atribute.

O excepție de la regula delimitării o constituie faptul că, în cazul elementelor goale, următoarele două construcții sunt echivalente: <empty></empty> se poate scrie <empty/>

Numele conținut în tag-urile de început și final dă tipul unui element. Numele trebuie să respecte câteva reguli: un nume trebuie să înceapă cu o literă si poate conține litere, cifre sau alte caractere. Numele nu pot conține spații și nu pot începe cu literele xml (indiferent dacă sunt cu majuscule sau nu). Numele care încep cu ‚xml’ sunt rezervate pentru tipuri specifice limbajului.

Elementele XML pot avea asociate atribute. Valoarea atributelor trebuie să fie conținută între ghilimele. De exemplu: putem avea un astfel de element:

<persoana sex=”feminin”>Ioana Popescu</persoana>

Deși atributele pot fi folositoare, în special pentru cei obisnuiți cu HTML, folosirea lor nu este recomandată din moment ce aceeași informație poate fi conținută ca un fiu al elementului respectiv. Această modalitate prezintă avantajul că poate fi ușor modificat ulterior (atât valoare cât și structură).

Prin utilizarea unei modalități de definire a conținutului unui document (XMLSchema sau DTD) se pot construi structuri de tipul listelor sau enumerărilor. De asemenea, în cazul atributelor se pot specifica tipul valorii, o valoare implicită și eventuala obligativitate a prezenței atributului respectiv.

Validarea documentelor XML

Pentru ca un document XML să poată fi folosit el trebuie să fie conform și, dacă e cazul, valid. Un document este conform, sau bine formatat atunci când respectă regulile de sintaxă ale XML-ului. Această proprietate trebuie să fie respectată de toate documentele XML.

Atunci când un document respectă și regulile trasate într-un document de definire a datelor, un DTD sau o XMLSchema, se spune despre acel document că este și valid.

Procesorul XML, atunci când verifică validitatea unui document, ia în considerare definițiile trasate în documentul specificat. Pentru aceasta există două entități care precizează dacă un document XML trebuie să urmărească regulile unui DTD sau ale unei XMLSchema. Acestea sunt:

<!DOCTYPE tipul_elementului_radacina SYSTEM „fisierul_cu_definiții.dtd”>

respectiv

xsi:schemaLocation=”adresa_schemei_folosite schema_folosita.xsd”

De remarcat că definirea definiției DTD este o entitate separată de elementul rădăcină, în timp ce definirea unei scheme este doar un atribut al elementului radăcină.

Cu alte cuvinte, orice document trebuie să respecte regulile generale ale limbajului XML, iar pentru acele documente pentru care s-au precizat reguli suplimentare, și acestea trebuie respectate.

XML Schema și DTD

Există două modalități de a descrie structura pe care trebuie să o respecte un anumit document XML. Prima dintre ele – DTD = Document Type Definition – este mai veche, a fost construită pe baza definiților SGML și constă dintr-o înșiruire de entități. Fiecare din aceste entități corespunde unui tip de elemente din documentul XML si stabilește regurile pentru acel tip. Poate fi indicată lista atributelor, cu valoarea lor implicită, si lista (eventual chiar și ordinea) fiilor pentru elementul respectiv.

Totuși, un DTD este destul de greoi de construit și de urmărit datorită faptului că este atât de diferit de XML. Din acest motiv apartiția XMLSchema a fost întâmpinată cu atât de mult succes de către autorii de documente XML.

Iata mai jos, spre exemplificare, aceleași definiții, scrise în DTD și în XMLSchema pentru un document XML, numit telegrama.xml

Documentul telegrama.xml:

<?xml version="1.0"?>

<dest>Popescu</dest>

<exped>Ionescu</exped>

<titlul>Informare</titlu>

<cuprins>Ne vedem la sfârșitul săptămânii!</cuprins>

</telegrama>

Descrierea DTD:

<!ELEMENT telegrama (dest, exped, titlu, cuprins)>

<!ELEMENT dest (#PCDATA)>

<!ELEMENT exped (#PCDATA)>

<!ELEMENT titlu (#PCDATA)>

<!ELEMENT cuprins (#PCDATA)>

Descrierea XMLSchema:

<?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.w3schools.com"

xmlns="http://www.w3schools.com"

elementFormDefault="qualified">

<xs:element name="telegrama">

<xs:complexType>

<xs:sequence>

<xs:element name="dest" type="xs:string"/>

<xs:element name="exped" type="xs:string"/>

<xs:element name="titlu" type="xs:string"/>

<xs:element name="cuprins" type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

XMLSchema folosește aceeași structură ierarhică și aceleași reguli de formatare ca și un document XML obișnuit. Astfel, autorul de documente XML nu este nevoit să învețe practic un nou limbaj doar pentru a descrie regulile pe care trebuie să le respecte anumite documente.

Date și structuri

Atunci când se stabilesc reguli pentru documente prin XMLSchema apare necesitatea de a preciza tipul unui atribut. Pentru aceasta sunt puse la dispoziție tipurile simple predefinite. Acestea sunt prefațate de ‚xs:’ și cuprind atât tipurile elementare (integer, decimal, byte, long, character, boolean) cât și tipurile complexe (string, date, time).

Pe baza acestor tipuri elementare pot fi construite noi tipuri, prin introducerea de restrictii. De exemplu, se poate construi un tip ‚initială’ care să conțină o singură literă mare urmată de un punct, astfel

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:pattern value="[A-Z]."/>

</xs:restriction>

</xs:simpleType>

În mod similar poate fi construit un tip ‚enumerare’ care să oblige un atribut să ia numai anumite valori prestabilite.

Trebuie reținut faptul că XML este un limbaj text. Tipurile numerice de care am pomenit mai sus sunt construițe tot pe baza unor restricții asupra tipului string. Interpretarea datelor într-un mod numeric se poate face doar după ce a fost realizată o conversie din text în valoarea reprezentată de acel text.

Prin XMLSchema se pot stabili anumite reguli care trebuiesc urmate de fii elementelor. Se poate stabili obligativitatea prezenței unui anumit fiu, numărul minim și numărul maxim de apartiții, ordinea apariției fiilor, și așa mai departe. Există șapte indicatori:

Indicatori de ordine:

All – toți fii trebuie să apară o dată și numai o dată, indiferent în ce ordine

Choice – doar unul din fii indicati poate apărea o dată

Sequence – toți fii indicați trebuie să apară în ordinea specificată

Indicatori de apariție

minOccurs – numărul minim de apariții pentru un element

maxOccurs – numărul maxim de apariții pentru un anumit element

Indicatori de grup

group name – grupează mai mulți fii sub un singur nume

attributeGroup name – grupează mai multe atribute sub un singur nume

DOM

Pentru a putea folosi datele dintr-un document XML în alte aplicatii sau pentru a putea modifica usor anumite date, se poate folosi DOM – Document Object Model. Acest standard precizează modul în care se poate accesa și manipula un document XML.

Pe baza DOM se poate contrui o structură de tip arbore care să conțină informațiile dintr-un document XML. De asemenea se poate construi un document XML pe baza unei structuri arborescente.

Legislația privind semnăturile electronice

Semnăturile electronice sunt legiferate atât pe plan european cât și în țara noastră. La nivel european este aplicabilă Directiva 1999/93/EC a Parlamentului și Consiliului European privind cadrul legat comunitar pentru semnături electronice, directivă emisă în 13 decembrie 1999. În țara noastră, a fost adoptată Legea nr. 455 din 18 iulie 2001 privind semnătura electronică, publicată în Monitorul Oficial nr. 429 din 31 iulie 2001 și a fost emisă Hotărârea de Guvern nr. 1259 din 13 decembrie 2001 care conține normele tehnice și metodologice pentru aplicarea Legii nr. 455.

Legislația europeană

Directiva 1999/93/EC stabilește în doar 15 articole și 4 anexe cadrul legal privind semnăturile electronice valabil în toate statele membre ale Uniunii.

Directiva Consiliului Europei

Primul articol al Directivei stabilește scopul acestui act normativ. Conform Articolului 1 scopul Directivei este

de a facilita folosirea semnăturii electronice și de a contribui la recunoașterea legală a lor și

de a stabili un cadru legal pentru semnătura electronică și pentru serviciile de certificare sigure pentru a asigura funcționarea potrivită a pieței interne. Directiva are cu alte cuvinte două obiective.

Atâta timp cât primul obiectiv este îngrijorător, articolul este formulat prudent. Directiva nu conține un total de reguli pentru semnăturile electronice ci doar cât să permită facilitarea folosirii lor. De altfel nici nu intenționează să acopere toate chestiunile recunoașterii legale a acestora. Directiva caută doar să „contribuie”.

Al doilea obiectiv este de a crea un cadru legal comun pentru Europa pentru a evita divergențele dintre legile naționale din acest domeniu. Cadrul nu acoperă toate tipurile de servicii de certificare, ci numai „asigură” aceste servicii.

Cel de-al doilea articol cuprinde definițiile termenilor folosiți în cadrul Directivei. Dintre aceste definiții, cele mai importante sunt cele de “semnătură electronică” și de “semnătură electronică avansată ”. În textul final termenul „semnătură electronică” are un sens foarte larg: „date în forme electronice cărora le este atașată sau cărora le este asociată logic alte date electronice și care servesc ca o metodă de autentificare”. Trebuie ținut minte că noțiunea de „semnătură” așa cum a fost folosită în cazul Directivei, se referă la aspectele legale și nu la cele tehnice. Obiectivul definiției este să acopere nu numai toate tehnologiile curente și viitoare care pot fi folosite pentru semnături electronice, ci de asemenea să includă toate înțelesurile posibile ale termenului „semnătură” în legile Statelor Membre. Este bine cunoscut faptul că termenul „semnătură” nu are același înțeles legal în toate Statele Membre ale uniunii. De exemplu, un nume tipărit și chiar o ștampilă a unei companii, va fi considerat o semnătură legală în Marea Britanie în timp ce noțiunea de „semnătură” în Franța, Belgia sau Germania –cel puțin până recent – includea numai semnăturile de mână. S-ar putea spune că definiția semnăturii electronice adoptată în Directivă este cel mai mare numitor comun al conceptelor de semnătură” care sunt folosite în legile Statelor Membre.

O „Semnătură Electronică Avansată” este o semnătură electronică care întrunește următoarele 4 cerințe:

să fie legată în mod unic de semnatar

să fie capabilă să identifice semnatarul

să fie creată utilizând mijloace pe care semnatarul le poate păstra sub unicul său control

să fie legată de datele pe care le referă într-o asemenea manieră încât orice modificare ulterioară a datelor să poată fi detectată.

Oricine poate observa că aceste cerințe sunt formulate într-un mod foarte general și neutru din punct de vedere tehnologic. În practică totuși definiția se referă în principal la semnăturile electronice bazate pe tehnologia semnăturilor digitale sau, cu alte cuvinte, care utilizează criptografia cu chei publice.

Conform unei alte definiții semnatarul este „o persoană care deține un dispozitiv de creare a semnăturii și care acționează fie în numele său fie în numele persoanei sau entității legale sau naturale pe care o reprezintă”. Contrar primei versiuni a directivei semnatarul nu mai este „persoana care creează o semnătură electronică” ci este persoana care deține dispozitivul de creare a semnăturii. Un asemenea dispozitiv este definit în Articolul 2.5 ca: „hardware sau software configurat folosit pentru a implementa datele de creare a semnăturii”. Un exemplu comun de dispozitiv de creare a semnăturii este un smart-card da există multe alte dispozitive posibile cum ar fi un smart-pen, un telefon mobil, un PDA sau hard-disk-ul unui computer. Semnatarul este persoana care deține dispozitivul și care acționează pentru a genera o semnătură. Semnatarul poate acționa fie în numele propriu, fie în numele persoanei sau entității naturale sau legal pe care o reprezintă.

Articolul 2 mai cuprinde definiții pentru datele de creare a semnăturii, dispozitivul și datele de verificare a semnăturii, certificat și certificat calificat, furnizor de servicii de certificare și acreditare voluntară.

Articolele 3 și 4 definesc principiile pieței și accesului pe piață a serviciilor de certificare și semnare. Ele prevăd că fiecare Stat Membru va aplica prevederile naționale, pe care le va adopta respectând Directiva, pentru furnizorii de servicii de certificare stabiliți pe teritoriul statului respectiv și pentru serviciile pe care le oferă. Statele Membre nu pot restricționa prevederile pentru serviciile de certificare care sunt originare în alt Stat Membru în câmpurile acoperite de către această Directivă. Furnizorii de servicii de certificare sunt subiectul regulilor țării în care sunt stabiliți (țara lor de origine). Ei nu trebuie să ia în considerare regulile tuturor țărilor europene în care oferă servicii. Din moment ce respectă regulile țării în care sunt stabiliți, serviciile lor trebuie să fie considerate în acord cu regulile tuturor Statelor Membre în care operează.

În aceste două articole se acordă o mare atenție reglementărilor privind accesul liber pe piață pentru furnizorii de servicii de certificare. Astfel, oricărui furnizor de servicii de certificare va trebui să i se permită să ofere serviciile sale fără autorizare inițială, înțelegând prin aceasta „nu numai orice tip de permisiune prin care furnizorul de servicii de certificare în cauză trebuie să obțină o decizie a autorităților naționale înainte de a i se permite să ofere serviciile de certificare, ci și orice altă măsură care are același efect.”

Articolul 5 se ocupă de efectele legale ale semnăturilor electronice. Articolul 5 este fără îndoială cea mai controversată prevedere a Directivei. Afirmă în primul paragraf că Statele Membre vor asigura faptul că semnăturile electronice avansate care sunt bazate pe un certificat calificat și care sunt create utilizând un dispozitiv securizat de creare a semnăturilor: a) satisfac cerințele legale ale unei semnături în relația cu datele în forma electronică în aceeași măsura în care o semnătură de mână satisface acele cerințe în relația cu datele scrise pe hârtie; și b) sunt admisibile ca probă în procedurile legale.

Conform Articolului 5.2 Statele Membre vor asigura faptul ca semnăturile lor electronice nu le este negată admisibilitatea și eficiența legală ca probe în procedurile legale numai pe baza faptului că este:

în formă electronică sau

nu se bazează pe un certificat calificat sau

nu se bazează pe un certificat calificat emis de un furnizor de servicii de certificare acreditat sau

nu este creată de un dispozitiv securizat de creare a semnăturilor

În Articolul 6 directiva conține prevederi privind răspunderea legală a emițătorilor de certificate calificate. Conform Articolului 6.1 și 6.2 un furnizor de servicii de certificare care emite un certificat ca și certificat calificat către public sau care garantează un asemenea certificat către public este răspunzător pentru

acuratețea și integritate conținutului certificatului calificat și a listei de revocări,

asigurarea privind proprietatea unei chei private de către semnatarul certificat la momentul emiterii și

corespondența dintre cheile privată si publică în cazul în care furnizorul de servicii de certificare generează ambele chei.

Articolul 6 prevede o responsabilitate minimă pentru furnizorii de servicii de certificare. Acest lucru înseamnă că Statele Membre pot merge dincolo de cerințele Articolului 6 în implementarea directivei dar nu li se permite să introducă o responsabilitate mai redusă pentru furnizorii de servicii de certificare.

Articolul 7 se ocupă de aspectele internaționale ale semnăturilor electronice. Aliniatele directivei subliniază faptul că dezvoltarea comerțului electronic internațional necesită aranjamente transfrontaliere care implică țări terțe. Pentru a asigura interoperabilitatea la nivel global înțelegeri și reguli multilaterale cu țări terțe privind recunoașterea serviciilor de certificare ar putea fi benefice

Articolul 8 se ocupă de protecția datelor personale colectate de entitățile implicate în serviciile de certificare și semnare. Astfel, Statele Membre trebuie să se asigure că furninzorii de servici de certificare și entitățile naționale responsabile pentru acreditare și supervizare, respectă cerințele prezentate în Directiva 95/46/EC a Parlamentului European și a Consiliului din 24 Octombrie 1995 privind protejarea indivizilor în legătură cu procesarea datelor personale și libera circulație a acestor date.

Ultimele articole se ocupă de chestiuni administrative, și cuprind reglementări privind înființarea și funcționarea unui comitet ‚al semnăturii electronice’ cu rol de supervizare a dezvoltărilor tehnologice, reglementări privind procedurile de implemetare și de modificare a Directivei, precum și reguli de colaborare și informare între Statele Membre.

Poate mai importante decât articolele Directivei sunt anexele acesteia, deoarece ele conțin cerințele care trebuiesc îndeplinite de un certificat calificat, de furnizorii de servicii de certificare care emit acest tip de certificate și de dispozitivele securizate de creare a semnăturii electronice.

Pentru certificatele calificate sunt specificate în prima anexă nu mai puțin de 10 cerințe:

indicare a faptului că certificatul este emis ca un certificat calificat;

identificarea furnizorului de servicii de certificare și a statului în care își are sediul

numele semnatarului sau un pseudonim care va fi autentificat ca atare;

furnizarea unui atribut specific al semnatarului care va fi inclus dacă este relevant depinzând de scopul pentru care este intenționată emiterea certificatului

datele de verificare a semnăturii care corespund datelor de creare a semnăturii sub controlul semnatarului

un indicator al începutului și al sfârșitului perioadei de validitate al certificatului

codul de identitate al certificatului

semnătura electronică avansată a furnizorului de servicii de certificare care au emis certificatul

limitări ale scopului de utilizare al certificatului, dacă este cazul

limitări ale valorilor tranzacțiilor pentru care certificatul poate fi utilizat dacă este cazul.

Pentru furnizorii de servicii de certificare, cerințele, care se găsesc în anexa 2, sunt în număr de 12. Dintre acetea amintim:

să demonstreze fiabilitatea necesară pentru oferirea serviciilor de certificare;

să asigure operațiunea unui director prompt și securizat și un serviciu de revocare securizat și imediat;

să asigure că data și timpul emiterii sau revocării uni certificat pot fi determinate precis;

să verifice, prin mijloace potrivite în concordanță cu legile naționale, identitatea și dacă este cazul orice atribut specific al persoanei pentru care este emis un certificat calificat;

să mențină resurse financiare suficiente pentru a opera în conformitate cu cerințele prezentate în directivă în special pentru a suporta riscul plăților pentru daune , de exemplu, prin obținerea unei polițe de asigurări potrivite;

să folosească sisteme de încredere și produse care sunt procedate împotriva modificărilor și să asigure securitatea tehnică și criptografică a proceselor suportate de acesta;

să ia măsuri împotriva falsificării certificatelor și în cazul în care furnizorul serviciilor de certificare generează date de creare a semnăturii, sa garanteze confidențialitatea în timpul procesului de generare a acestor date;

să nu păstreze sau să copieze datele de creare a semnăturii ale persoanei căreia furnizorul de servicii de certificare îi oferă servicii de administrare a cheilor;

să folosească sisteme de încredere pentru a stoca certificatele într-o formă verificabilă astfel încât:

numai persoanele autorizate să poată să facă introduceri și modificări,

informațiile să poată fi verificate pentru autenticitate,

certificatele să fie disponibile public pentru extragere numai în acele cazuri pentru care a fost obținut consimțământul deținătorului certificatului

orice modificare tehnică care compromite cerințele de securitate să fie evidentă pentru operator

Pentru dispozitivele securizate de creare a semnăturilor, anexa 3 prevede următoarele cerințe:

datele de creare a semnăturii folosite pentru generarea semnăturii pot practic să apară o singură dată, și securitatea lor este asigurată în mod rezonabil

datele de creare a semnături nu pot fi derivate și semnătura este protejată împotriva falsificării folosind tehnologia actuală

datele de creare a semnăturii pot fi protejate de către semnatar împotriva folosirii lor de către alte persoane

dispozitivele nu trebuie să altereze datele care sunt semnate sau să nu permită semnatarului vizualizarea acestor date înainte de semnare.

Legislația românească

În România, semnăturile electronice sunt reglementate de legea privind semnătura electronică și de normele tehnice și metodologice de aplicare a acesteia.

Legea a fost concepută astfel încât să respecte legislația europeană, având în vedere intenția țării noastre de a adera la Uniunea Europeană în viitorul apropiat.

Legea semnăturii electronice

Legea semnăturii electronice este legea 455 din 18 iulie 2001, publicată în Monitorul Oficial, Partea I numărul 429 din 31 iulie 2001.

Legea este organizată în 9 capitole, fiecare cu mai multe secțiuni.

Încă din primul capitol se indică faptul că această lege stabilește regimul juridic al semnăturilor electronice și al înscrisurilor în formă electronică, precizându-se că acestă lege se completează cu prevederile legale privind încheierea, validitatea și efectul actelor juridice.

O secțiune a primului capitol este rezervată definițiilor folosite în cadrul legii. Se observă ușor că aceste definiții sunt astfel formulate încât să fie în acord cu definițiile date în Directiva 1999/93/EC. Astfel, semnătura lectronică este definită ca fiind ‚date în formă electronică, care sunt atașate sau logic asociate cu alte date în formă electronică și care servesc ca metodă de identificare’, iar condișiile pentru ca o semnătură electronică să fie considerată ca fiind ‚extinsă’ sunt tot în număr de patru: să fie legată în mod unic de semnatar, să asigure identificarea semnatarului,să fie creată prin mijloace controlate exclusiv de semnatar și să fie legată de datele electronice la care se raportează în așa fel încât orice modificare ulterioară să fie identificabilă. Tot în secțiunea de definiții sunt trecute și condițiile care trebuie îndeplinite de un dispozitiv securizat de creare a semnăturii electronice

Al doilea capitol al legi se ocupă de regimul juridic al semnăturilor electonice. Articolul 5 stabilește că pentru ca un înscris în formă electronică căruia i s-a atașat sau asociat logic o semnătură extinsă să fie asimilat cu înscrisul sub semnătură privată, trebuie ca semnătura electronică să fie bazată pe un certificat calificat, nesuspendat și nerevocat la momentul semnării, iar semnătura trebuie să fie generată cu un dispozitiv securizat de creare a semnăturii electronice.

Tot în această secțiune se stabilește că o astfel de semnătură electronică (creată cu un dispozitiv securizat pe baza unui certificat calificat nerevocat și nesuspendat) poate fi folosită atunci când este cerută forma scrisă ca o condiție de probă sau de validitate a unui act juridic.

Mai este specificat că responsabilitatea probării calității unui certificat de a fi certificat calificat sau a calității unui dispozitiv de creare a semnăturii de a fi dispozitiv securizat cade în sarcina celui care invocă în fața instanței certificatul sau dispozitivul. Se precizează, totuși că un certificat emis de un furnizor de servicii de certificare acreditat este prezumat a fi calificat și că un dispozitiv de creare a semnăturii omologat este prezumat a fi securizat.

Capitolul 3 se ocupă de reglementările privind furnizarea serviciilor de certificare. Se precizează că această activitate nu este supusă nici unei autorizări prealabile (conform cerințelor Directivei), dar fiecare furnizor care intenționează să ofere astfel de servicii trebuie să anunțe, cu cel puțin 30 de zile înainte de începerea activității, intenția de furniza astfel de servicii autorității de reglementare și supraveghere specializată și data începerii furnizării serviciilor.

Câteva articole din această secțiune regelementează și modul în care furnizorii de servicii de certificare colectează date cu caracter personal precum și modul în care aceste date pot fi utilizate.

O întreagă secțiune a acestui capitol este dedicată suspendării și încetării valabilității certificatelor. Orice furnizor de servicii de certificare este obligat să suspende un certificat în următoarele situații:

la cererea semnatarului, după verificarea prealabilă a identității acestuia

dacă o hotărâre judecătorească dispune suspendarea

atunci când informațiile din certificat nu mai corespund realității, dar nu se impune revocarea certificatului

Revocarea unui certificat este tot obligatia furnizorului de servicii de certificare și se realizează în următoarele situații:

la cererea semnatarului, după verificarea identității acestuia

la decesul sau punerea sub interdicție a semnatarului

în cazul în care o hotărâre judecătorească irevocabilă decide revocarea

dacă se dovedește în mod neîndoielnic că certificatul a fost emis pe baza unor informații eronate sau false

dacă informațiile esențiale din certificat nu mai corespund realității

atunci când confidențialitatea datelor de creare a semnăturii a fost încălcată

în cazul în care certificatul a fost folosit în mod fraudulos

Tot în această secțiune sunt reglementate și procedurile care trebuiesc urmate în cazul falimentului furnizorului de servicii de certificare sau a încetării activității acestuia, dintr-un motiv sau altul.

Următorul capitol al legii se ocupă de operațiunile de monitorizare și control, stabilindu-se atribuțiunile autorității de reglementare și supraveghere, modul în care se desfășoară supravegherea activității furnizorilor de servicii de certificare, modul în care un furnizor poate să obțină o acreditare voluntară sau modul în care un dispozitiv de creare a semnăturii este omologat.

Conform acestui capitol, acreditarea unui furnizor de servicii de certificare este o operațiune voluntară, în scopul asigurării unui grad sporit de securitate a operațiunilor și al protejării corespunzătoare a drepturilor și intereselor legitime ale beneficiarilor de servicii. Un furnizor care este acreditat are dreptul de a menționa acest lucru în toate activitățile pe care le desfășoară.

Omologarea dispozitivelor de creare a semnăturii se realizează cu scopul de a verifica conformitatea respectivelor dispozitive cu prevedreile acestei legi, fiind realizată de agenții de omologare agreate de autoritatea de reglementare.

Capitolul 5 stabilește recunoașterea certificatelor eliberate de furnizorii de servicii de certificare străini dacă furnizorul respectiv este acreditat (de agenția de regelementare română), dacă un furnizor acreditat din România garantează certificatul furnizorului străin sau dacă există un acord bilateral pe această temă între țara de origine a furnizorului și România.

Capitolele 6 și 7 stabilesc răspunderea și obligațiile furnizorilor de servicii de certificare și ale titularilor. Se prevede că titularii sunt obligați să ceară revocarea certificatului atunci când au pierdut datele de creare a semnăturii electronice (cheia privată), când au motive să creadă că datele de creare a semnăturii electronice au ajuns la cunoștiința unui terț neautorizat sau atunci când informațiile esențiale cuprinse în certificat nu mai corespund realității.

Următorul capitol stabilește contravențiile și sancțiunile. Contravențiile se constată de către personalul specializat, cu atribuțiuni de control, din cadrul autorității de reglementare și supraveghere. Același personal se ocupă și de aplicarea sancțiunilor. Sancțiunile stabilite în acest capitol se referă în principal la fapte ale furnizorilor de servicii de certificare.

Normele tehnice și metodologice (HG1259 din 13 decembrie 2001)

Normele tehnice și metodologice aprobate prin Hotărârea de guvern numărul 1259 din 13 decembrie 2001, vin cu anumite completări și clarificări privind modul de aplicare a legii nr 455.

În ceea ce privește autoritatea de reglementare, aceste norme stabilesc formatul și informațiile din cadrul registrului furnizorilor de servicii de certificare. Din acest registru sunt făcute publice tipul furnizorului (persoană fizică sau juridică), numele sau denumirea acestuia, data la care și-a înceeput activitatea, cheia publică, informații privind acreditarea (dacă este acreditat și perioada pentru care este acreditat), adresa, telefonul, situația și un istoric al activității furnizorului, și o serie de alte date de interes public.

Pentru furnizorii de servicii de certificare care doresc să emită certificate calificate se prevăd resursele financiare pe care trebuie să le dețină pentru a acoperi eventualele prejudicii cauzate beneficiarilor precum și valoarea scrisorii de garanție din partea unei societăți de asigurare. Mai sunt stabilite standardele internaționale care trebuiesc aplicate pentru nivelul de securitate a sistemelor, comunicațiilor, tranzacțiilor și datelor. Mai este stabilit și faptul că un furnizor nu-și poate începe activitatea dacă autoritatea de reglementare nu a verificat toate actele și nu a emis decizia care să-i confere acest drept.

Prin aceste norme metodologice se stabilește că un furnizor poate să obțină acreditarea dacă îndeplinește toate condițiile necesare emiterii de certificate calificate și dacă utilizează doar dispozitive securizate de creare a semnăturii omologate în acest sens de o agenție agreată. După verificările documentelor și a concordanței celor afirmate cu realitatea, autoritatea de reglementare decide acreditarea furnizorului. Durata acreditării este de 3 ani, putând fi reînnoită după o procedură similară celei de acordare a acreditării. În cazul în care constată că furnizorul nu mai îndeplinește una sau mai multe din condițiile de acordare a acreditării sau în cazul declanșării procedurii falimentului, autoritatea de reglementare poate decide suspendarea acreditării, iar dacă furnizorul nu remediază deficiențele în termenul stabilit, acreditarea poate fi retrasă.

Actul normativ stabilește faptul că autoritatea de reglementare trebuie să verifice un furnizor cel puțin o dată la 2 ani sau când acesta din urmă modifică procedurile de lucru.

Capitolul 4 din normle metodologice stabilește procedurile de utilizare a semnăturii electronice, mai precis ce trebuie să facă o persoană care dorește să i se elibereze un certificat și cum procedează furnizorul la primirea unei cereri de eliberare a unui certificat. Un certificat este valabil maxim un an de la data comunicării către client. Prin acceptarea unui certificat, clientul își asumă responsabilitatea controlului cheii private, certifică veridicitatea datelor din certificat și se angajează să îl folosească exclusiv în scopuri autorizate. Cheile publice ale clienților sunt gestionate direct de către furnizorul de servicii de certificare, lucru care presupune implicit acordarea tuturor serviciilor de certificare prevăzute în contractul încheiat cu clienții.

Certificatele calificate pot fi reînnoite, caz în care se emite un nou certificat, cu aceleași date de identificare și verificare a semnăturii, dar cu alte date de valabilitate.

În capitolul dedicat detaliilor tehnice, actul normativ stabilește lungimea minimă a cheii private utilizate de un semnatar pentru crearea unei semnături electronice extinse la 1024 de biți pentru algoritmii RSA și DSA și la 160 de biți pentru algoritmul DSA bazat pe curbe eliptice. Se stabilește că autoritatea de reglementare va folosi algoritmul RSA și că generarea datelor de semnătură a autorității se va face utilizând un sistem izolat, fiabil, special proiectat în acest scop și protejat împotriva utilizării neutorizate.

În cazul algoritmilor de generare a hash-ului, normele metodologice stabilesc că autoritatea de regelementare va folosi SHA-1, și că pentru o semnătură electronică extinsă se vor folosi SHA-1 sau RIPEMD-160. Se precizează, totuși, că pot fi folosiți și alte preceduri de generare a semnăturii dacă oferă același nivel de securitate, fapt certificat de un organism autorizat recunoscut.

Prezentare generală a semnăturilor digitale în XML

Semnătură digitală

Pricipalul obiectiv al operațiunii de semnare digitală este acela de a autentifica autorul (semnatarul) unui document, de a-l asigura pe receptorul unui document semnat că respectivul document provine într-adevăr de la cel care se pretinde a fi expeditorul.

Trebuie subliniat faptul că securitatea datelor (privită aici în sensul de a impiedica alte persoane decât expeditorul și receptorul să aibă acces la aceste date ) nu intră în scopurile semnării digitale. Pentru a îndeplini și obiectivul de securizare a datelor, se poate utiliza semnătura digitală în combinație cu diverse scheme de criptare a conținutului digital care este semnat.

Elemente de criptare asimetrică

Principala proprietate a criptografiei asimetrice, și cea care face din această ramură a criptografiei unul din elementele structurale de bază pentru semnăturile digitale este posibilitatea de a cripta un conținut digital cu o anumită cheie – numită cheie privată – și de a decripta respectivul mesaj utilizând o altă cheie, pereche, numită cheie publică.

De aici rezultă și o altă particularitate a acestui tip de criptare: după cum îi spune și numele, una din cele două chei pereche este publică, poate fi distribuită fără nici o restricție. Însă cealaltă cheie se presupune că este la dispoziția semnatarului și numai la dispoziția lui.

În general perechile de chei sunt generate de o entitate specializată în acest domeniu, care, pe lângă operațiunea de generare, poate să ofere și serviciul de identificare a posesorului unei anumite chei publice.

Tăria algoritmilor asimetrici constă în dificultatea de a determina cheia privată, chiar dacă este cunoscută cheia publică – adică din dificultatea de a factoriza numere foarte mari. Aplicarea lor este însă mare consumatoare de resurse, acesta fiind și motivul pentru care se semnează doar un digest al unui conținut digital și nu întreg conținutul digital.

Cerințe pentru semnături

Multă vreme semnăturile olografe (“de mână”) au fost folosite pentru a proba că o anumită persoană este de acord cu un anumit document.

Potrivit Asociației Baroului American (American Bar Association –ABA), semnătura nu reprezintă o parte esențială a unei tranzacții, ci mai degrabă a modului de reprezentare sau a formei tranzacției respective. Semnarea unui document se face pentru a atinge 4 scopuri, pe care le vom prezenta în continuare.

Probă

O semnătură autentifică un document scris prin identificarea celui care a semnat documentul. Când persoana respectivă a ‚marcat’ documentul într-o manieră proprie, distinctivă, documentul poate fi atribuit acelei persoane.

Caracter oficial

Actul de semnare a unui document are implicații în domeniul juridic și, de aceea, cel care semnează trebuie să fie în cunoștiință de cauză, să cunoască documentul semnat și să-și asume responsabilitățile juridice implicate de acel document, putând astfel să evite ‚angajamentele nechibzuite’.

Acord

În anumite contexte specificate de lege, semnătura are rolul de a consemna în mod expres autorizarea sau acordul dat de persoana care semnează pentru prevederile acelui document sau intenția semnatarului ca documentul să aibă efect legal.

Eficiență

O semnătură pe un document scris dă o anumită claritate și chiar o finalitate unei tranzacții. În mod optim, o semnătură și procesele de creare și verificare ale ei trebuie să furnizeze siguranță maximă atât în autentificarea celui care semnează cât și a documentului, cu un consum de resurse cât mai mic.

Proprietăți ale semnăturilor digitale

Semnătura digitală îndeplinește 5 proprietăți ale semnăturilor care îi permit să respecte cerințele generale prezentate mai sus. Vom prezenta în continuare aceste proprietăți și modul în care sunt îndeplinite de semnătura digitală.

Autentică

Prin calitatea unei semnături de a fi autentică se înțelege faptul că în urma semnării se poate realiza autentificarea autorului, adică se poate stabili o legatură între semnătură și cel care a realizat-o.

În cazul semnăturii digitale autentificare semnatarului se face cu ajutorul perechii de chei – publică și privată. Odată creată o semnătură (prin criptarea cu cheia privată), ea nu mai poate fi decriptată decât cu cheia publică a semnatarului. Astfel, dacă decriptarea cu o cheie publică verifică o semnătură se știe că acea semnătură nu a putut fi creată decât de posesorul cheii private corespunzătoare, care poate fi identificat ușor cu ajutorul autorității de certificare.

Nefalsificabilă

Prin calitatea unei semnături de a fi nefalsificabile se înțelege faptul că respectiva semnătură dovedește că semnătura documentului a fost produsă de pretinsul semnatar.

În cazul semnăturii digitale, deoarece numai proprietarul cheii private are acces la aceasta, și deci el e singurul care o poate folosi pentru a semna documente. Odată ce o cheie privată a fost compromisă (prin pierdere, furt, deteriorare) și a fost declarată ca fiind compromisă, proprietarul ei este exonerat de răspunderea juridică.

Nereutilizabilă

Prin calitatea unei semnături de a fi nereutilizabile se înțelege faptul că o semnătură nu poate fi mutată pe un alt document decât cel semnat.

Cum semnătura digitală este realizată prin criptarea unui rezumat al documentului, ea nu este valabilă decât pentru documentul care are același rezumat, pentru orice alt document semnătura nu se mai verifică.

Nealterabilă

Prin calitatea unei semnături de a fi nealterabilă se înțelege faptul că unui document semnat nu i se mai pot aduce modificări. Orice modificare ulterioară invalidează semnătura.

În cazul semnăturii digitale, orice modificare adusă documentului implică o modificare a valorii rezumatului. Apare astfel o diferență între valoarea rezumatului care a fost criptat cu cheia publică și valoarea rezumatului calculată de receptor, ceea ce înseamnă neverificarea semnăturii. Astfel, un document nu mai poate fi modificat după ce a fost semnat.

Nerepudiabilă

Prin nerepudiere se înțelege calitatea unei semnături de a nu permite semnatarului să nu mai recunoască că a semnat documentul respectiv.

Nerepudierea semnăturii digitale este obținută din faptul că este verificată de o singură cheie publică care corespunde unei singure chei private și din imposibilitatea semnatarului de a nega că ar fi proprietarul cheii private cu care s-a realizat semnătura. Autoritate de certificare care a emis perechea de chei poate stabili legătura între cheia publică și entitatea pentru care s-a emis respectiva cheie.

Infrastructura PKI

Infrastructura cu chei publice – Public Key Infrastructure sau PKI – reprezintă mulțimea de servicii asigurate pentru buna funcționare pe scară largă a tehnologiilor de criptare cu chei asimetrice. Elementele acestei infrastructuri sunt:

Certificatele digitale

Autoritățile de certificare

Utilitățile de management al certificatelor

Certificatele digitale sunt folosite pentru transmiterea pe scară largă a cheilor publice. Un certificat digital este emis de o autoritate de certificare. El trebuie să respecte un anumit format, cel mai folosit fiind cel definit în standardul ITU X.509. În cadrul acestui format sunt specificate câmpurile unui certificat. Printre acestea se găsește și un câmp care conține semnătura digitală aplicată de autoritatea de certificare.

Certificatele digitale pot fi transmise fără a necesita protejarea lor, deoarece cheia publica nu este secretă. De asemenea, un certificat este autoprotejat împotriva modificărilor prin semnătura digitală a autorității care l-a emis.

O autoritate de certificare este o entitate care emite certificate pentru anumiți subiecți. Dacă o entitate are încredere într-o autoritate de certificare, această încredere este transmisă către toate entitățile care au un certificat emis de aceea autoritate de certificare.

La rândul ei, o autoritate de certificare poate deține un certificat emis de o altă autoritate. Se asigură astfel posibilitatea de identificare între entitățile care dețin certificate emise de autorități de certificare diferite.

Se ajunge la o ierarhie a autorităților de certificare. Acestă ierarhie conține în rădăcina arborelui o autoritate care se auto-autentifică și care este presupusă de încredere de către toți participanții la infrastructura cu chei publice.

Protocoalele de management al certificatelor cuprind modalitățile de obținere a unui certificat, de verificare a unui certificat și de revocare a unui certificat. De asemenea trebuie să ofere posibilitatea obținerii informațiilor despre certificate.

În momentul verificării unei semnături trebuie în primul rând să existe posibilitatea verificării lanțului de certificare. Această verificare pornește de la certificatul entității pentru care se dorește identificarea, se trece prin certificatul autorității de certificare care a emis acel certificat, si se merge, recursiv, până se ajunge la o autoritate de certificare de încredere (care poate fi autoritatea din vârful ierarhiei de certificare sau poate fi o autoritate de pe un nivel inferior, în care cel care face verificarea are încredere).

După cum se observă elementul de bază în infrastructura cu chei publice este „încrederea”. Acest lucru implică necesitatea unor cerințe de securitate mai stricte pentru autoritățile de certificare, iar aceste cerințe cresc pe măsură ce se avansează în arborele de certificare spre nivelurile superioare.

Un alt protocol important din utilitătile de management al certificatelor este protocolul de revocare a unui certificat. Atunci când dintr-un motiv sau altul, perechea de chei a unei entități a fost compromisă este necesar ca acest lucru să poată fi cunoscut de toți cei interesați. Din acest motiv, fiecare autoritate de certificare deține o listă de certificate suspendate și revocate. Această listă trebuie să conțină informații cât mai actuale despre starea certificatelor. Dacă atunci când se face verificarea unei semnături certificatul corespunzător se găsește în lista de certificate revocare, asupra documentului respectiv planează suspiciunea.

Caracteristici XMLDSIG

Semnăturile digitale XML (XML-DSIG) reprezintă o inițiativă comună a Internet Engineering Task Force (IETF) și a World Wide Web Consortium (W3C). Folosirea XML-DSIG face posibilă combinarea avantajelor XML-ului cu cele ale semnăturilor digitale.

Un document XML-DSIG încapsulează rezultatele unei operațiuni de semnătură digitală. Operațiile de hash-are și cele cu chei publice sau private sunt realizate în afara contextului XML. După ce sunt realizate aceste operații, rezultatele sunt scrise în documentul de semnătură digitală XML. Cu alte cuvinte, standardul XML-DSIG nu oferă o modalitate de criptare a datelor. Toate informațile privind semnătura digitală sunt grupate în elementul signature. Acest element conține elementele care descriu informația semnată, valoarea semnăturii, informații despre algoritmul și cheia folosită și alte date care pot avea legătură cu semnătura digitală.

Formatul de semnătură digitală în XML oferă anumite avantaje: compatibiltatea, ușurința de citire de către oameni și faptul că este bazată pe obiecte.

Standardul XML-DSIG oferă o posibiltate simplă de a creea semnături digitale independente de aplicație și de platformă asupră oricărui tip de conținut. Poate fi folosit pentru a verifica integritatea și autentificarea emitentului unei informații.

Structură de obiect

Prin acest lucru se înțelege faptul că semnăturile digitale XML sunt folosite pentru a semna obiecte specifice și nu neapărat documente complete. Obiectul semnat poate fi orice format de conținut digital, pornind de la un simplu element XML și ajungând până la un film întreg în format digital sau chiar arhive de dimensiuni mai mari.

Ușor de citit

Documentele XML sunt ușor de citit de către oameni pentru că sunt construite în elemente. Semnătura digitală XML este construită ca un element într-un document XML separat sau poate fi o parte a unui document XML care conține elementele semnate.

Semnături multiple într-un singur document

Prin aceasta se înțelege posibilitatea oferită de XML-DSIG ca în același document XML să se găsească elemente de tip signature care să aparțină mai multor semnatari.

De asemenea este posibilă modificarea documentelor XML fără a compromite semnăturile digitale a elementelor specifice. Atât timp cât elementele semnate nu sunt modificate nu sunt nici un fel de complicații. De exemplu, un element de semnătură digitală poate fi preluat dintr-un document XML-DSIG (care conține mai multe astfel de elemente) și să fie distribuit separat că și când ar fi fost proaspăt creat.

Compatibilitatea

XML-DSIG nu este un algoritm separat; acest standard poate fi folosit pentru a semna obiecte cu mai multe tipuri de algoritmi standard de semnare digitală. Elementul XML signature conține toate informațiile privind semnătura digitală XML, incluzâd metodele și cheile folosite pentru generarea valorii semnăturii. Prin urmare, orice aplicație, care rulează pe orice platformă poate lucra cu datele semnate în XML-DSIG atât timp cât aplicația are utilități XML, care sunt ușor de construit într-o aplicație.

Sintaxa și procesare XMLDSIG

Generalități

Un document XML-DSIG are avantajul că poate conține o semnătură doar asupra unei părți din document. Prin urmare mai mulți utilizatori pot semna bucăți diferite din document. Acest lucru poate fi foarte benefic în cazul contractelor dintre semnatari diferiți din organizații diferite. Faptul că o semnătură digitală XML nu acoperă neapărat un document întreg face posibilă adăugarea sau modificarea (de către o a treia parte) a unor părți nesemnate în document, lăsând intactă integritatea semnăturii.

Un alt avantaj major al semnăturii digitale XML este acela că oferă posibilitatea de a semna cu o singură operație criptografică mai multe conținuturi digitale prin adunarea lor într-un element SignedInfo și semnarea doar a acestuia, permițând astfel semnatarului să indice faptul că un anumit conținut digital nu poate fi considerat semnat decăt dacă se găsește într-un grup bine determinat de alte conținuturi digitale.

XML-DSIG poate fi folosită în trei moduri diferite:

prin referință cu un URI în cadrul semnăturii XML (detașată)

semnătura e părintele unui obiect care este semnat (cu anvelopare)

semnătura este fiu al obiectului care este semnat (anvelopată)

Fiecare tip de semnare este folosit în scopuri diferite. Sintaxa XML-DSIG este capabilă să trateze toate aceste trei tipuri de semnătură.

Primul tip (detașată) este folosit adesea atunci când documentul semnat este disponibil prin Internet (HTTP).

Al doilea tip (cu anvelopare) este o tehnică care permite autorului sau semnatarului unui document să încapsuleze informații semnate în cadrul semnăturii digitale.

Al treilea tip de semnătură (anvelopată) este analoagă celei de a doua. Mesajul semnat conține semnătura digitală care autentifică semnatarul și dovedește integritatea datelor.

Structura unei semnături digitale XML constă în câteva tipuri de elemente. Nu toate aceste tipuri sunt necesare, depinzând de modul în care este realizată semnătura digitală. În următoarea parte a acestui document vor fi descrise fiecare din aceste tipuri. Va fi indicat și modul în care fiecare din aceste componente ar trebui să fie utilizate.

Principalul document, și specificație tehnică de facto, care prezintă modul în care este constituită o semnătură digitală, și modul în care ea este procesată este Recomandatea W3C bazată pe RFC 3275.

Recomandarea W3C privind sintaxa și procesarea semnăturilor digitale în XML

Stabilirea cadrului de lucru

Regulile de sintaxa și de procesare a semnăturilor digitale XML simple sunt descrise în Recomandarea W3C din 12 februarie 2002, ai căror pricipali autori sunt Mark Bartel, John Boyer, Barb Fox, Brian LaMacchia și Ed Simon.

Practic, acest document definește un tip de element XML ‚Signature’ (și alte tipuri utile care identifică metodele de identificare a colecțiilor de resurse, și a informațiilor de management al informațiilor despre chei și algoritmi) și o aplicație de semnătură XML, definite atât cu ajutorul schemelor XML cât și prin proză.

Conform acestei recomandări, semnăturile XML pot fi aplicate asupra oricărui conținut digital, inclusiv XML. O semnătură XML poate fi aplicată asupra conținutului uneia sau mai multor resurse. Semnăturile anvelopate și cu anvelopare sunt aplicate asupra datelor din același document ca și semnătura, iar semnăturile detașate sunt aplicate asupra datelor externe documentului care conține semnătura.

Semnătura XML este o metodă de a asocia o cheie cu datele referite. Scopul acestei reomandări W3C nu este acela de a reglementa modul în care cheile sunt asociate cu persoane sau instituții și nici acela de a reglementa conținutul datelor care sunt referite și semnate. Cu alte cuvinte, deși este o componentă importantă a aplicațiilor de securitate XML, recomandarea nu este suficientă pentru a trata toate problemele de securitate și de încredere, în principal în legătură cu folosirea documentelor XML semnate ca o bază a comunicațiilor și a înțelegerilor interumane. O aplicație de securitate trebuie să specifice cerințe suplimentare pentru chei, algoritmi, regulile de procesare și de redare.

Prima secțiune se ocupă de regulile de procesare, cea de-a doua prezintă sintaxa formală pentru semnătura de bază, în timp ce a treia secțiune prezintă sintaxa semnăturii extinse.

Conceptul de semnătură simplă (core signature)

Semnăturile digitale XML sunt aplicate asupra oricărui conținut digital, printr-o indirectare sau o referință. Conținutului digital (obiectului de date) îi este aplicat o funcție hash, rezultatul acestei funcții – digest-ul – este plasat într-un element DigestValue dintr-un element Reference, care este plasat într-un element SignedInfo (alături de alte informații). Acestui element SignedInfo i se calculează la rândul lui digest-ul, acest din urmă digest fiind semnat criptografic. Semnăturile digitale XML sunt reprezentate în elementul <Signature> care are următoarea structură (în exemplu de mai jos, am folosit ‘?’ pentru a reprezenta zero sau o apariție, ‚+’ pentru a reprezenta una sau mai multe apariții, iar ‚*’ pentru a reprezenta zero sau mai multe apariții):

(<Reference URI? >

(<Transforms>)?

</Reference>)+

</SignedInfo>

(<KeyInfo>)?

(<Object ID?>)*

</Signature>

Semnăturile sunt relaționate cu obiectele de date semnate printr-un URI. În interiorul unui document XML relațiile se realizează prin identificatorii de fragment. Astfel de date locale pot fi incluse într-o semnătură cu anvelopare sau pot cuprinde o semnătură anvelopată. Semnăturile detașate sunt aplicate asupra resurselor externe sau asupra obiectelor de date locale care se găsesc în cadrul documentului XML pe același nivel cu elementul Signature; în acest caz semnătura nu este nici cu anvelopare (semnătura e părinte) nici anvelopată (semnătura e fiu). Din moment ce elementul Signature (și valoarea/numele atributului ID) pot să coexiste cu alte elemente (și ID-urile lor) într-un singur document XML, trebuie avut grijă la alegerea acestor nume astfel încât să nu apară coliziuni care să violeze constrângerea de unicitate a atributelor ID.

Conceptul de semnătură extinsă (extended signature)

Elementele incluse în cadrul semnăturii de bază în recomandarea W3C nu pot să acopere toate necesitățile unei aplicații în ceea ce privește informațiile pe care le consideră necesare a fi transmise odată cu semnătura, ci acoperă doar acele informații esențiale, absolut necesare oricărei semnături. Recomandarea oferă totuși modalități de a alătura semnăturii și alte informații. Se ajunge astfel la conceptul de semnătură extinsă.

Este definit un tip de elemente ‚SignatureProperty’ care poate fi folosit pentru includerea de afirmații despre semnătură (de exemplu semantica semnăturii, timpul la care a fost realizată sau numărul serial al dispozitivului hardware folosit în procesul criptografic). Astfel de afirmații pot fi semnate prin includerea unei referințe către elementul SignatureProperty în cadrul lui SignedInfo. În timp ce aplicația care semnează trebuie să fie foarte atentă la ce anume semnează (și trebuie să înțeleagă ce se găsește în SignatureProperty) aplicația care primește semnătura nu este obligată să înțeleagă semnatica elementului SignatureProperty. Orice fel de conținut despre generarea semnăturii poate fi inclus în elementul SignatureProperty. Acest element conține un câmp obligatoriu, Target, care indică elementul Signature pentru care se aplică proprietățile descrise.

Se poate ajunge la o situație interesantă; dacă se consideră o semnătură care în SignedInfo conține o referință către un element Object, local, care cuprinde un element SignatureProperty, o astfel de semnătură nu ar fi numai detașată ci și cu anvelopare.

…

…

<Reference URI="#AMadeUpTimeStamp"

Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">

<DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue>

</Reference>

</SignedInfo>

…

</timestamp>

</SignatureProperty>

</SignatureProperties>

</Object>

</Signature>

După ce proprietatea semnăturii XML de a semna cu o singură operație criptografică mai multe conținuturi digitale (prin adunarea lor într-un element SignedInfo și semnarea doar a acestuia), Recomandarea prezintă o modalitate prin care se mai poate sări un pas obligatoriu al verificării unei semnături. Este vorba de validarea referințelor, care poate fi mare consumatoare de timp și resurse deoarece presupune calcularea, de către aplicația care a primit documentul semnat, a valorii digest-ului pentru fiecare continut digital indicat printr-o referință de fiecare dată când trebuie validată o semnătură. Pentru început, este introdus un nou tip de element, Manifest. SignedInfo va conține o referință către acest element, care la rândul lui va conține referințele către conținuturile digitale care sunt semnate. În acest mod, obligativitatea calculării digest-ului se aplică doar pentru referința către elementul Manifest (obiect local, de mici dimensiuni, deci un calcul ușor de realizat), iar decizia de a calcula sau nu valoarea digest-ului pentru conținuturile digitale indicate de referințele cuprinse în elementul Manifest aparține aplicației care verifică semnătura.

Aceeași soluție poate fi aplicată și în cazul în care se semnează un număr mare de documente cu un număr mare de chei. Soluția ineficientă ar consta în a avea câte o semnătură aplicată asupra aceluiași SignedInfo (care cuprinde multe referințe) – lucru care este reduntant. Mai eficient este să se includă acele multe referințe într-un Manifest, și apoi să se aplice semnarea cu fiecare cheie în parte asupra unui element SignedInfo care conține o singură referință către elementul Manifest.

…

<Reference URI="#MyFirstManifest"

Type="http://www.w3.org/2000/09/xmldsig#Manifest">

<DigestValue>345x3rvEPO0vKtMup4NbeVu8nk=</DigestValue>

</Reference>

…

…

</Reference>

…

</Reference>

</Manifest>

</Object>

Reguli de procesare

După ce prezintă noțiunile introductive, Recomandarea W3C descrie regulile de procesare pentru semnăturile digitale în XML. Aceste reguli se axeaxă în principal pe partea de semnături simple (core signatures), deoarece această parte este obligatorie (în sensul acestei Recomandări) pentru toate documentele semnate. Partea de semnătură extinsă, nefiind obligatorie, nu are definite niște reguli de procesare clare, ci sunt prezentate doar câteva posibilități de comportament, Recomandarea lăsând la latitudinea aplicațiilor stabilirea unor reguli clare precum și modalitatea de transmitere a lor între cele două aplicații (de semnare și de verificare). Nici partea de sintaxă pentru semnătura extinsă nu este prea detaliată, fiind definite doar două elemente.

Generarea semnăturii simple

Recomandarea W3C stabilește doi pași ca fiind obligatorii în generarea unei semnături simple, și anume generarea elementelor Reference și generarea semnăturii în sine.

Generarea referințelor

Pentru generarea referințelor, pentru fiecare obiect de date care este semnat sunt definiți următorii pași:

aplicarea transformărilor, așa cum au fost stabilite de către aplicația de semnare asupra obiectului de date.

Calcularea valorii digest-ului asupra obiectului de date rezultat în urma pasului 1)

Crearea elementului Reference, care va trebui să includă ca elemente opționale identificatorul obiectului de date, eventualele transformări aplicate, iar ca elemente obligatorii, identificatorul algoritmului de hash-are folosit și elementul DigestValue

Generarea semnăturii

Pentru generarea semnăturii sunt stabiliți următorii pași:

Crearea elementului SignedInfo care trebuie să cuprindă elementele SignatureMethod (valoarea acestui element este identificatorul algoritmului de semnare folosit), CanonicalizationMethod (valoarea acestui element este indetificatorul algoritmului de canonicalizare aplicat asupra elementeleor Reference înainte de calcularea digest-ului pentru elementul SignedInfo) și toate elementele Reference generate.

Aplicarea algoritmului de canonicalizare și apoi calcularea elementului SignatureValue obținut din aplicarea algoritmului criptografic specificat în SignatureMethod asupra digest-ului elementului SignedInfo

Construirea elementului Signature care să includă ca elemente obligatorii SignedInfo și SignatureValue și ca elemente opționale KeyInfo și eventualele Object(s)

Validarea semnăturii simple

Pentru validarea unei semnături simple, Recomandarea prevede doi pași obligatorii, și anume validarea referințelor, inclusiv verificarea digest-ului conținut în fiecare element Reference din SignedInfo, și validarea semnăturii criptografice calculate asupra elementului SignedInfo.

Se precizează într-o notă că pot exista semnături valide pe care anumite aplicații să nu le poată valida. Această eroare poate apărea fie din cauză că în implementarea aplicației de verificare nu au fost luate în considerare părțile opționale ale specificațiilor cuprinse în Recomandare, fie din cauză că aplicația nu poate (nu vrea) să execute anumiți algoritmi sau nu poate (nu vrea) să rezolve URI-urile specificate (anumite scheme URI pot cauza efecte nedorite).

O altă notă se referă la compararea valorilor pentru digest-uri sau pentru valoarea semnăturii. Aceste comparații se pot executa asupra volorii numerice (un anume tip integer) sau asupra secvenței de octeți obținuți din decodarea valorii respective. Se precizează că diverse implementări pot produce codări diferite pentru valorile digest-urilor și a semnăturii chiar și atunci când procesează aceleași resurse, datorită diferențelor de codare (cum ar fi apariția accidentală a unui spațiu). Acestă problemă poate fi eliminată prin folosirea aceluiași tip de comparare (numerică sau octet cu octet) atât asupra valorii trmise de aplicația care a semnat cât și asupra valorilor calculate de aplicația care verifică.

Validarea referințelor

Recomandarea indică următorii pași ca fiind obligatorii pentru a valida referințele în cazul unei semnături simple:

canonicalizarea elementului SignedInfo, realizată cu algoritmul specificat în CanonicalizationMethod din SignedInfo.

Obținerea, pentru fiecare element Reference din SignedInfo, a datelor cae au fost semnate. De exemplu, aplicația care face verificarea semnăturii poate să rezolve URI-ul specificat și să aplice transformările indicate în elementul Transform sau poată să folosescă alte mijloace pentru obținerea conținutului, cum ar fi un cache local.

Calcularea digest-ului penrtu fiecare obiect de date obținut la pasul 2), folosind algoritmul indicat în DigestMethohd pentru fiecare element Reference.

Compararea valorii digest-ului obținut cu valoarea elementului DigestValue, aflată în fiecare Reference din SignedInfo. Dacă apare vreo inegalitate între oricare două valori, validarea se încheie cu eșec.

Validarea semnăturii

Pentru validarea semnăturii trebuie îndepliniți următorii pași obligatorii:

obținerea informațiilor despre cheie, folosind elementul KeyInfo (dacă există un astfel de element) sau o sursă externe (semnatarul poate transmite printr-o altă metodă informațiile despre cheia de verificare a semnăturii).

Obținerea formei canonice a elementului SignedInfo utilizând CanonicalizationMethod și calcularea digest-ului pentru acest element.

Folosirea algoritmului indicat de SignatureMethod și a informațiilor despre cheie (obținute la pasul 1 ) pentru a decripta conținutul elementului SignatureValue

Compararea valorilor obținute la cei doi pași anteriori. Dacă cele două valori nu sunt egale, validarea se încheie cu eșec.

Recomandarea indică că principala sursă de apariție a neconcordanțelor între ceea ce se semnează și ceea ce se verifică este operația de canonicalizare, care poate să modifice valoarea URI-urilor din document (aducându-le la forma absolută) sau pot să altereze într-un mod nedorit conținutul altor elemente. Se precizează, totuși, că algoritmul de canonicalizare recomandat, XML-C14N nu aduce URI la forma lor absolută.

Sintaxa semnăturii simple

După precizarea principalelor reguli de procesare a semnăturilor simple digitale în XML, Recomandarea detaliază fiecare element care apare în cadrul semnăturii simple (core signature).

Fiecare element este explicat prin furnizarea sintaxei elementului respectiv, și prin detalierea rolului pe care îl are în cadrul semnăturii. Sintaxa este indicată prin furnizarea schemei XML pe care este bazat.

Elementul Signature

Elementul Signature este rădăcina unei semnături digitale în XML. El este contruit pe baza următoarei scheme:

</sequence>

</complexType>

Acest element este elementul de nivel înalt al fiecărei semnături digitale XML-DSIG. Folosește un singur spațiu de nume care este xmlns:ds="http://www.w3.org/2000/09/xmldsig#". Toate celelalte elemente ale semnăturii digitale XML pot fi găsite în cadrul acestui element Signature. Elementul Signature poate conține următoarele elemente: SignedInfo, SignatureValue, KeyInfo și Object.

Elementul SignatureValue

Acest element conține însăși valoarea semnăturii digitale, codată întotdeauna utilizând modalitatea Base64. Deși Recomandarea specifică doi algoritmi (pentru unul implementarea este obligatorie – DSA – și pentru altul ea este opțională – RSA) utilizatorul poate alege să implementeze și alți algoritmi.

Schema XML după care trebuie implementat elementul SignatureValue este:

</extension>

</simpleContent>

</complexType>

Elementul SignedInfo

Elementul SignedInfo este un fiu direct al elementului Signature și este un element obligatoriu. Conține informații despre obiectul care este semnat și despre metodele care sunt folosite pentru a forma semnătura. Aceste informații pot fi găsite în elementele CanonicalizationMethod, SignatureMethod și Reference.

Elementul SignedInfo poate conține un atribut opțional ID care va permite să fie referit de alte semnături și obiecte.

Elementul nu include proprietăți explicite ale semnăturii sau ale digest-ului (cum ar fi data la care a fost calculată, numărul serial al dispozitivului cu care s-a realizat semnarea, etc.). Dacă o aplicație trebuie să asocieze proprietăți cu o anume semnătură sau digest poată să includă aceste informații într-un lement SignatureProperty din cadrul unui element Object.

Schema XML după care este implementat acest element este:

</sequence>

</complexType>

Acest element obligatoriu este informația care se semnează. Mai trebuie observat că algoritmii folosiți în calcularea elementului SignatureValue sunt de asemenea incluși în informația semnată atunci când elementul SignatureValue se găsește în afara lui SignedInfo.

Elementul CanonicalizationMethod

Elementul CanonicalizationMethod este un element obligatoriu care specifică algoritmul de canonicalizare aplicat elementului SignedInfo inainte de a efectua calculele pentru smenare. Recomandarea specifică algoritmul XML-C14N ca algoritm care trebuie implementat obligatoriu și că aplicațiile trebuie să fie foarte atente la acceptarea și folosirea unor algoritmi de canonicalizare arbitrari.

Acest element specifică modul în care este reconstruit exact stream-ul de octeți. În acest mod, stream-uri diferite de date care conțin exact aceeași informație XML (de exemplu, un stream de date conține un spațiu în plus) vor returna același stream de date după canonizare, astfel încât valoarea hash-ului să fie identică.

Elementul este un fiu direct al elementului SignedInfo și conține un atribut numit algorithm care specifică ce algortim a fost folosit pentru canonizare.

Schema după care este definit este următoarea:

<!– (0,unbounded) elements from (1,1) namespace –>

</sequence>

</complexType>

Elementul SignatureMethod

Elementul SignatureMethod este un element obligatoriu care specifică algoritmul utilizat pentru generarea și verificarea semnăturii. Acest algoritm identifică toate funcțiile criptografice implicate în operațiile de semnare.

Elementul SignatureMethod specifică ce tip de metodă a fost folosită pentru a face rezumatul elementului SignedInfo și care algoritm este folosit pentru obținerea valorii semnăturii, de exemplu RSA sau DSA.

Ele este definit prin următoarea schemă XML:

<!– (0,unbounded) elements from (1,1) external namespace –>

</sequence>

</complexType>

Elementul Reference

Poate cel mai important element al sintaxei semnăturii digitale în XML este elementul Reference. El poate să apară o dată sau de mai multe ori. Specifică algoritmul folosit pentru calcularea digest-ului si valoarea acestuia, și opțional un identificator al obiectului de date care este semnat, tipul acestui obiect și o listă de transformări care sunt aplicate înainte de calcularea digest-ului.

Identificatorul (URI) și lista transformărilor descrie modul în care a fost creată intrarea pentru algoritmul de hash. Atributul Type facilitează procesarea datelor referite. De exemplu, deși această specificație nu conține cerințe privind datele externe, o aplicație poate dori să semnalizeze că datele referite sunt de fapt un element Manifest.

Schema XML după care este construit acest element este:

</sequence>

</complexType>

Acest element este definit prin atributul său URI. Acel URI pointează către un obiect care este semnat digital. Aplicațiile de semnare XML trebuie să poată parsa toate sintaxele URI, și este recomandat să poată să le rezolve, adică să poată extrage obiectul de date identificat de un anume URI.

Elementul Reference conține cel puțin elementele DigestMethod și DigestValue. Elementele Transforms, Manifest și SignatureProperty sunt elemente opționale care pot fi incluse în elementul Reference.

elementul Transforms este opțional. Este o listă ordonată de pași de procesare. Fiecare pas este aplicat asupra conținutului resursei înainte de calcularea rezumatului. Elementul Transforms poate cuprinde mai multe operații care au legătură cu codare și canonizarea informației. Este definit pe baza schemei:

</sequence>

</complexType>

<!– (1,1) elements from (0,unbounded) namespaces –>

</choice>

</complexType>

Elementul DigestMethod specifică algoritmul care este folosit pentru calcularea valorii rezumatului. Schema după care este definit este:

</sequence>

</complexType>

Elementul DigestValue conține valoarea care a fost generată după aplicarea metodei de calculare a rezumatului specificată în elementul DigestMethod. Valoarea este un șir de caractere fără înțeles logic pentru oameni. Elementul este definit astfel:

</simpleType>

Elementul Manifest este un element adițional semnăturii digitale XML și un fiu direct al elementului Reference. Oferă o listă de referințe. Elementul este folosit atunci când se dorește compararea rezumatului cu obiectul referit și ce trebuie făcut atunci când obiectul este inaccesibil sau compararea rezumatelor a eșuat.

Elementul SignatureProperty este de asemenea un element adițional XML-DSIG și un fiu direct al elementului Reference. Informații adiționale privind semnătura pot fi plasate intr-un element de acest tip.

Elementul KeyInfo

Elementul keyInfo indică cheile care trebuie folosite pentru a valida semnătura. Formele posibile de identificare includ certificate, nume de chei, sau algoritmi și informații de alegere a cheii. Prin urmare elementul keyInfo poate conține diverse implementări ale structurilor de chei, cum ar fi X.509 sau chei RSA.

Acest element este unul opțional și permite aplicației care primește documentul cu semnătura XML să obțină cheia necesară pentru validarea semnăturii. Recomandarea W3C prezintă structura acestui element pentru câțiva algoritmi, dar precizează că dezvoltatorii pot să extindă structura elementelor definite sau pot să definească alte elemente în funcție de necesitățile aplicației sau de algoritmii folosiți.

Dacă acest element lipsește, se așteaptă ca aplicația de verificare să poată identifica cheia pe baza contextului aplicației. Aplicațiile își pot defini și pot folosi orice mecanisme de distribuție a cheilor.

Elementul este definit după următoare schemă XML:

<!–(1,1) elements from (0,unbounded) namespaces –>

</choice>

</complexType>

Elementul KeyName conține o șir de caractere care poate fi folosit de către semnatar pentru a comunica destinatarului un identificator al cheii. Aceasta poate include un simplu nume pentru cheie, un index, un nume distinctiv, sau o adresă de email.

Elementul KeyValue conține o singură cheie publică care poate fi utilă în validarea semnăturii. Recomandarea precizează structura acestui element pentru algoritmul DSA (implementarea acestui algoritm este obligatorie) și pentru RSA (implementarea acestui algoritm este recomandată). Astfel, pentru DSA, elementul KeyValue trebuie să cuprindă valorile pentru P – modulul prim, pentru Q – un întreg mare (reprezentat pe 160 de biți) care este prim cu numărul P-1, G și Y, unde Y = G**X mod P (unde X este parte a chei private și nu este făcut public). Pentru algoritmul RSA este disponibil modulul și exponentul. Toate numerele mari sunt reprezentate ca șiruri de caractere obținute prin codarea în format Base64.

Elementul Object

Acest element poate păstra informații despre datele din cadrul semnăturii. Nu este un element obligatoriu. În cadrul acestui element se pot păstra informații privind momentul la care a fost aplicată semnătura digitală, în cazul în care un timestamp este necesar. Acest element poate conține orice tip de informație.

Elementul Object poate să apară de zero sau mai multe ori. Dacă se dorește identificarea metodei prin care este codat obiectul (de exemplu pentru identificarea uneui fișier binar), se poate folosi atributul Encoding.

Atributul MimeType este opțional și poate fi folosit pentru a descrie datele din cadrul elementului Object (independent de codarea acestor date). De exemplu, dacă elementul conține un fișier PNG codat Base64, se egalează atributul Encoding cu valoarea ‚base64’, și atributul MimeType se egalează cu ‚image/png’.

ID-ul unui element Object este folosit adesea de o referință din cadrul unui SignedInfo sau a unui Manifest. Ecest element este de obicei folosit pentru a anvelopa semnături atunci când obiectul care este semnat trebuie inclus în elementul Signature. Digest-ul este calculat asupra întregului element Object, inclusiv asupra tag-urilor de început și final.

Acest element este construit pe baza următoarei scheme XML:

</sequence>

</complexType>

Sintaxa semnăturii extinse

Această secțiune descrie elementele opționale Manifest și SignatureProperties, precizând că sintaxa și comportamentul prezentate sunt minimale.

Partea de semnătură extinsă, nefiind obligatorie, nu are definite niște reguli de procesare clare, ci sunt prezentate doar câteva posibilități de comportament, Recomandarea lăsând la latitudinea aplicațiilor stabilirea unor reguli clare precum și modalitatea de transmitere a lor între cele două aplicații (de semnare și de verificare). Nici partea de sintaxă pentru semnătura extinsă nu este prea detaliată, fiind definite doar două elemente.

Elementul Manifest

Elementul Manifest oferă o listă de elemente Reference. Diferența față de lista din elementul SignedInfo constă în faptul că aplicația definește care dintre digest-uri (dacă există măcar unul) sunt verificate prin comparare cu digest-ul obiectelor referite precum și care este comportamentul atunci când obiectul de date nu este disponibil sau când compararea digest-urilor eșuează. Atunci când SignedInfo conține o referință către Manifest, la validarea referințelor se va face compararea cu digest-ul aplicat asupra elementului Manifest. Digest-urile din cadrul elementului Manifest sunt verificate doar dacă așa dorește aplicația.

Aceeași soluție poate fi aplicată și în cazul în care se semnează un număr mare de documente cu un număr mare de chei. Soluția ineficientă ar consta în a avea câte o semnătură aplicată asupra aceluiași SignedInfo (care cuprinde multe referințe) – lucru care este reduntant. Mai eficient este să se includă acele multe referințe într-un Manifest, și apoi să se aplice semnarea cu fiecare cheie în parte asupra unui element SignedInfo care conține o singură referință către elementul Manifest.

Elementul este construit pe baza următoarei scheme XML:

</sequence>

</complexType>

Elementul SignatureProperties

Acest element poate conține informații adiționale privind generarea semnăturii. Ce informații să fie transmise și modul în care trebuie interpretate și procesate aceste informații este lăsat în grija celor două aplicații (de semnare și de validare a semnăturii). Dintre informațiile care pot fi adăugate putem aminti o ștampilă temporală privind timpul la care a fost realizată semnătura, numărul serial al dispozitivului care a fost folosit la generarea semnăturii, contextul și politica de securitate care se aplică acestei semnături.

Astfel de afirmații pot fi semnate prin includerea unei referințe către elementul SignatureProperties în cadrul lui SignedInfo. În timp ce aplicația care semnează trebuie să fie foarte atentă la ce anume semnează (și trebuie să înțeleagă ce se găsește în SignatureProperties) aplicația care primește semnătura nu este obligată să înțeleagă semnatica elementului SignatureProperties. Orice fel de conținut despre generarea semnăturii poate fi inclus în elementul SignatureProperties. Acest element conține un câmp obligatoriu, Target, care indică elementul Signature pentru care se aplică proprietățile descrise.

Elementul este construit conform schemei:

</sequence>

</complexType>

<!– (1,1) elements from (1,unbounded) namespaces –>

</choice>

</complexType>

Exemplu

Iată și un exemplu de semnătură digitală. Se pot observa cu ușurință structurile și elementele discutate în paragrafele anterioare.

</Transforms>

<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>MC0CFFrVLtRlk=…</SignatureValue>

</DSAKeyValue>

</KeyValue>

</KeyInfo>

</Signature>

Standardul pentru semnături digitale XML avansate (ETSI TS 101 903 – XML Advanced Electronic Signatures XAdES)

Un alt document important, care reglementează semnăturile electronice, este Specificația Tehnică (TS – Tehnical Specification) 101 903 produsă de Comitetul Tehnic de Securitate (SEC – Tehnical Commitee Security) al Institutului European de Standarde în Telecomunicații (ETSI – European Telecomunications Standards Institute), ajuns în prezent la versiunea 1.2.2 (emisă în luna aprilie 2004).

Acest document se deosebește de Recomandarea W3C în sensul că își propune să standardizeze semnăturile electronice XML așa cum sunt ele văzute în Uniunea Europeană. Această specificație tehnică vine în întâmpinarea Directivei Europene 1999/93/EC, și prezintă sintaxa tipurilor de semnătură propuse în actul normativ, și anume semnătura electronică calificată, oferind și suport pentru semnături care trebuie arhivate pe o perioadă mai mare de timp.

A se observa și diferența de termeni. Dacă Recomandarea W3C făcea referire la ‚semnătură digitală’, specificația tehnică a ETSI se referă la ‚semnătură electronică’.

Introducere și scop

Documentul își propune să acopere problematica semnăturilor electronice pentru diverse tipuri de tranzacții. Termenul de semnătură electronică este văzut în sensul dat de Directiva Europeană, anume acela de ‚ date în format electronic care sunt atașate sau asociate logic cu alte date electronice și care servesc ca metodă de autentificare’.

O semnătură electronică produsă în concordanță cu această specificație oferă o dovadă care poate fi procesată pentru a oferi încredere că un anumit angajament a fost luat în mod explicit, conform unei politici de semnare, la un anumit timp, de un semnatar (identificat printr-un identificator, care poate fi un nume, un pseudonim sau uneori un rol asumat). Politica de semnare conține cerințele tehnice și de procedură privind crearea și validarea semnăturii pentru a acoperi anumite cerințe specifice ale tranzacției.

Aceatsă specificație tehnică recunoaște Recomandarea W3C, și rolul său de a oferi funcționalitate de bază pentru semnarea digitală a mai multor obiecte de date în același timp și de a oferi mijloace de bază pentru încorporarea informațiilor necesare pentru a transforma o semnătură într-o semnătură electronică calificată.

Specificația definește formate XML pentru semnături electronice care rămân valide o lungă perioadă de timp, respectă cerințele Directivei Europene și încorporează alte date adiționale utile cazurilor des folosite, prin:

propunerea unor scheme XML și a unor definiții de tipuri XML care pot să conțină informațiile necesare pentru a îndepli cerința de valabilitate pe termen lung și alte cerințe impuse de Directivă sau de practica comună. Aceste semnături vor fi realizate pe baza standardului W3C – XMLDSIG – prin adăugarea acestor informații în cadrul elementului Object definit în Recomandarea W3C.

Specificare unor mecanisme folosite pentru a produce adăugările menționate pentru generarea informațiilor calificate.

Specificația definește două tipuri principale de proprietăți: proprietăți semnate și proprietăți nesemnate. Primele sunt acele informații adiționale care sunt de asemenea securizate de semnătura produsă, ceea ce presupune că semnatarul deține aceste informații, le calculează hash-ul și generează elementul Reference corespunzător. Proprietățile nesemnate sunt adăugate de semnatar, de cel care verifică, sau de alte părți după producerea semnăturii. Ele nu sunt securizate de semnătura produsă de semnatar, însă pot fi semnate de alte părți (ștampile temporale, contra-semnături, certificate sau CRL-uri).

Acest document folosește o politică de semnare, definită implicit sau explicit de semnatar, ca bază pentru a stabili validitatea semnăturii electronice.

Sunt folosite ștampile temporale (time-stamps) pentru a oferi semnăturii validitate pe termen mai lung decât timpul de viață normal și oferă suport pentru non-repudiere. Este specificată de asemenea posibilitatea de a folosi ștampile temporale adiționale pentru a oferi valabilitate pe termen foarte lung și pentru a oferi protecție împotriva compromiterii unei chei sau împotriva scăderii puterii algoritmilor folosiți.

Acest document specifică modul în care pot fi folosite entitățile furnizoare de servicii de încredere (de exemplu autoritîți de ștampilare temporală) și datele care trebuiesc să fie arhivate. O semnătură electronică care respectă această sepcificație poate fi folosită pentru arbitrare în caz de dispută între semnatar și cel care verifică, dispută care poate apărea la un anumit timp, poate chiar la câțiva ani de la data producerii semnăturii.

În sensul dat de această specificație, un furnizor de servicii de încredere este o enitate care ajută la construirea relațiilor de încredere între semnatar și cel care verifică. Aceste entități oferă suport pentru semnatar și cel care verfică prin oferirea de servicii care includ certificarea utilizatorului, cross-certificare, elemente de ștampilare temporală, CRL-uri, ARL-uri, sau răspunsuri OCSP. Dintre entitățile furnizoare de servicii de încredere amintim:

autoritățile de certificare

autoritățile de înregistrare

autoritățile de depozitare (oferă un director de certificate)

autoritățile de ștampilare temporală

emitenții de politici de semnare

Semnătură electronică și date de validare

Pentru a putea verifica o semnătură electronică, în sensul dat de această specificație este nevoie de o semnătură electronică avansată (construită pe formatul definit de Recomandarea W3C cu încorporarea informațiilor adiționale de calificare, anume acele proprietăți semnate furnizate de semnatar) și de datele de validare (date necesare pentru validarea semnăturii electronice), care inlcud certificate, informații privind starea revocării acelor certificate și elemente de ștampilare temporală oferite o o autoritate de ștampilare temporală.

Datele de validare pot fi colectate de semnatar și/sau de verificator și trebuie să respecte cerințele impuse de politica de semnare. Este necesar ca cel puțin una din cele două părți (semnatarul și verificatorul) să obțină o ștampilare temporală asupra semnăturii semnatarului sau să păstreze o înregistrare care să nu poată fi modificată (fără a fi detectat acest lucru) privind semnătura electronică și timpul la care ea a fost validată prima dată.

Structuri de date ale semnăturii electronice XML avansate (XAdES)

Specificația definește diferite forme de semnătură electronică, fiecare din ele satisfăcând ceerințe care vor fi descrise în fiecare secțiune.

În această primă parte sunt descrise primele trei forme: semnătura electronică de bază (XAdES-BES – Basic Electronic Signature), semnătura electronică bazată pe o politică explicită (XAdES-EPES – Explicit Policy based Electronic Signature) și semnătura electronică cu date de validare complete (XAdES-C – Electronic Signature with Complete Validation Data).

Conținutul XAdES-BES

O semnătură electronică de bază construită conform acestei specificații va fi construită pornind de la cerințele Recomandării W3C prin încorporarea proprietăților calificate definite aici. Toate proprietățile calificate vor fi conținute în elementul Object. Anumite proprietăți definite pentru construirea acestui formular vor fi acoperite de semnătura autorului (informațiile calificate semnate grupate într-un element nou, SignedProperties), în timp ce alte proprietăți nu vor fi acoperite de semnătură.

În figura următoare se pot observa elementele componente ale unei semnături electronice, conform acestui document.

Figura 1: Elementele componente ale unei semnături electronice XML avansate

În cadrul unei semnături XAdES-BES valoare semnăturii va fi calculată luând în considerare obiectele de date care trebuiesc semnate și întreg setul de proprietăți semnate, atunci când există.

Pentur acest titp de semnătură este obligatoriu ca semnătura să protejeze certificatul cu care semnează, fie prin încorporarea elementului SigningCertificate în cadrul proprietăților semnate, fie prin încorporarea lui în cadrul elementului KeyInfo (într-un element X509Data), cu condiția ca acest element să fie semnat (cu alte cuvinte trebuie ca în SignedInfo să existe o referință către elementul KeyInfo). În acest mod, semnătura XAdES-BES previne simpla substituție a certificatului semnatarului.

O semnătură XAdES-BES poate să conțină următoarele proprietăți semnate:

SigningTime

DataObjectFormat

CommitmentTypeIndication

SignerRole

SignatureProductionPlace

Unul sau mai multe elemente IndividualDataObjectTimeStamp sau AllDataTimeStamp

De asemenea poate să conțină o dată sau de mai multe ori și proprietatea nesemnată CounterSignature.

În această structură mai pot fi adăugate și alte elemente Object cu diverse componente, pentru a putea satisface alte cerințe decât cele deja prezentate în această specificație.

Trebuie precizat că XAdES-BES este formatul minim pentru o semnătură electronică generată de un semnatar. Prin ea însăși, ea nu oferă suficiente informații pentru a fi validă pe termen lung. De exemplu, informații privind revocarea certificatelor, emise de un furnizor de informații despre starea certificatelor trebuie să fie disponibilă pentru validarea pe termen lung.

XAdES-BES satisface cerințele legale pentru o semnătură electronică, așa cum sunt ele definite în Directiva Europeană 1999/93/EC, oferind autentificare de bază și protecția integrității. Semantica datelor semnate într-o XAdES-BES sau contextul acesteia îi pot indica celui care verifică implicit politica de semnare utilizată.

Vom prezenta în continuare structura XAdES-BES cu încorporarea directă a noilor elementelor XML corespunzătoare (în această descriere vom folosi ‚?’ pentru a indica zero sau o singură apariție, ‚+’ pentru a indica una sau mai multe apariții și ‚*’ pentru a indica zero sau mai multe apariții.

Figura 2: Structura XML a unei semnături XAdES-BES

Conținutul XAdES-EPES

O semnătură electronică bazată pe o politică de semnare explicită (XAdES-EPES) extinde definiția dată semnăturii electronice, pentru a se conforma unei politici de semnare identificate. O semnătură XAdES-EPES se construiește pe baza unei semnături conforme cu Recomandarea W3C sau cu XAdES-BES prin încorporarea unui element semnat – SignaturePoliczIdentifier, indicând astfel că este obligatorie o politică de semnare pentru a valida semnătura si specificând care politică anume să fie utilizată. Acest element este protejat prin semnătura autorului. Nu intră în scopurile prezentei specificații să detalieze conținutul unei politici de semnare, acestea fiind descrise în ETSI TS 102 038.

Vom prezenta în continuare structura unei XAdES-EPES realizată prin încorporarea directă într-o XAdES-BES.

Figura 3: Structura XML a unei semnături XAdES-EPES

Conținutul XAdES-C

Specificația descrie și două formate de semnătură electronică care cuprind și datele de validare. Validarea unui document este văzută de acest document ca necesitând date adiționale semnăturii, constând în:

certificate de chei publice (PKC – public key certificates)

informații privind starea revocării pentru fiecare din aceste certificate

ștampile temporale de încredere aplicate semnăturii sau o altă metodă de a marca timpul care va fi disponibilă în jurnalul de audit

atunci când e cazul, detaliile politicii de semnare care trebuie folosită pentru verificarea semnăturii electronice

Aceste date de validare pot fi colectate de semnatar și/sau de cel care verifică semnătura. Atunci când există un identificator al politicii de semnare, datele de validare trebuie să întrunească cerințele respectivei politici. Datele de validare includ atât certificate eliberate de o autoritate de certificare (CA) cât și informații privind starea revocării lor în forma unei liste de certificate revocate (CRL – certificate revocation list) sau de informații on-line oferite de un serviciu de informare privind starea certificatelor (OCSP – online certificare status protocol).

Cele două tipuri de semnături simple care includ și date de validare definite de specificația ETSI sunt XAdES-T și XAdES-C. Imaginea de mai jos prezintă relația care există între tipurile de semnătură definite de acest document.

Figura 4: Elementele componente ale unei semnături electronice XML avansate complete

Semnătura electronică XML avansată cu timp (XAdES-T) este o semnătură pentru care există asociat un timp de încredere. Acest timp de încredere poate fi obținut în două moduri:

adăugarea elementului SignatureTimeStamp ca proprietate nesemnată

marcare a timpului semnăturii furnizată de un furnizor de încredere

Marcarea timpului semnăturii va avea un efect similar cu cel al proprietății SignatureTimeStamp, dar în acest caz nu este adăugată nici o proprietate semnăturii electronice și este responsabilitatea furnizorului de servicii de stampilare temporală să aducă dovezi privind marcarea temporală, ori de câte ori îi este cerut acest lucru.

Trebuie remarcat că ștampilarea temporală este primul pas în asigurarea valabilității pe termen lung.

Semnătura electronică XML cu date de validare complete (XAdES-C) adăugă unei XAdES-T elementele CompleteCertificateRefs și CompleteRevocationRefs, care sunt proprietăți nesemnate. Dacă în cadrul semnăturii apare și un certificat de atribute, atunci XAdES-C va cuprinde și elementele AttributeCertificateRefs și AttributeRevocationRefs.

Elementul CompleteCertificateRefs contine o secvență de referințe către întreg setul de certificate ale CA care au fost folosite pentru a valida semnătura mergând până la (dar nu inclusiv) certificatul cu care s-a semnat.

Elementul CompleteRevocationRefs conține un set complet de referințe către datele de revocare care au fost folosite la validarea semnatarului și a certificatelor autorităților de certificare.

Elementele AttributeCertificateRefs și AttributeRevocationRefs conțin referințe către setul complet de certificate ale autorităților de atribuire și referințe către setul complet de date de revocare care au fost folosite la validarea certificatelor de atribute prezente în semnătură.

Depozitarea referințelor permite ca valorile listei de certificate, a CRL-urilor și/sau a răspunsurilor OCSP, a certificatelor autoritășilor de atribute si a listei de revocare a certificatelor de atribute și/sau a răspunsurilor OCSP să fie stocate altundeva, reducând dimensiunea formatului stocat al semnăturii electronice.

Date de validare a formularelor extinse

Formatul semnăturii electronice XML avansate complete descris mai sus poate fi extins la unul din formatele XAdES-X sau XAdES-X-L. Imaginea de mai jos prezintă relația dintre aceste tipuri de semnături.

Figura 5: Elementele componente ale tipurilor de semnătură extinsă

Conținutul XAdES-X

Formatul XAdES-X este folosit atunci când există riscul ca oricare cheie folosită în lanțul de certificate sau în lanțul de informații de revocare să fie compromisă. Cazul spargerii unui algoritm va fi tratat mai jos, atunci când se va discuta despre formatul de semnătură electronică arhivată.

În plus, este necesar să se ștampileze temporal toate referințele căilor de certificate și toate referințele informațiilor de revocare conținute în XAdES-C. În mod alternativ, ștampilarea temporală poate fi aplicată asupra semnăturii digitale, (elementul Signature), asupra ștampilelor temporale prezente în XAdES-T și asupra referințelor menționate mai sus.

Datele de validare ale XAdES-X sunt create prin adăugarea unui element XML care să încapsuleze ștampilele temporale descrise mai sus și plasarea acestui element ca un fiu al elementului UnsignedProperties.

Conținutul XAdES-X-L

Formatul XAdES-X-L este folosit atunci când datele lanțului de certificare și datele privind starea de revocare nu sunt stocate pe termen lung într-un anume loc, și deci este necesară adăugarea lor în cadrul semnăturii.

Acest format va fi produs prin încorporarea lanțului de certificare și a informațiilor despre starea de revocare (CRL-uri și/sau răspunsuri OCSP), încapsulate convenabil în elemente XML. Aceste elemente XML vor fi adăugate ca fii ai elementului UnsignedProperties.

Date de validare arhivelor

Specificația ETSI ia în considerare și posibilitatea ca puterea algoritmilor criptografici sau a cheilor folosite să scadă în viitor (datorită îmbunătățirii analizei criptoanaliștilor sau a puterii de calcul), punând astfel în pericol posibilitatea folosirii semnăturii pe termen lung (unul din dezideratele acestei specificații). Din acest motiv, în cadrul documentului este descris un tip de semnătură, care conține datele de validare și arhivare.

Conținutul XAdES-A

Dezvoltarea industriei calculatoarelor crește probabilitatea ca algoritmul folosit sau cheile de semnătură să fie compromise. Apare, în consecință necesitatea protejării semnăturii electronice împotriva acestei posibilități. O tehnică simplă constă în formatul de semnătură cu date de validare și arhivare, XAdES-A.

Figura 6: Relația dintre formatul XAdES-X-L și forma de arhivare

Datele de validare și arhivare constau în datele de validare complete, datele complete despre certificate și despre starea de revocare, toate ștampilate temporal împreună cu semnătura electronică.

În continuare vom prezenta formatul complet al unei semnături electronice cu date de validare și arhivare.

Figura 7: Sintaxa unei semnături electronice cu validare și arhivare

Prezentare generală stucturi și clase

Pentru partea practică a acestui proiect s-a încercat dezvoltarea unui set de clase care să poată fi folosit pentru construirea de aplicații de semnare electronică a datelor și de verificare a semnăturilor electronice.

A fost aleasă soluția realizării unui set de clase și nu a unei aplicații finale datorită flexibilității acestei soluții. Având în vedere că o semnătură electronică trebuie să respecte o anumită politică de semnare și că aceste politici de semanre pot varia de la caz la caz, aplicațiile de generare și de verificare a unei semnături electronice trebuie create și pe baza unei politici stabilite.

Setul de clase realizat își propune să faciliteze crearea unor aplicații de generare și de verificare a unor semnături electronice, furnizând clase și metode care pot fi folosite pentru scrierea unei astfel de aplicații.

În cadrul acestui capitol vor fi prezentate pachetele și clasele distribuite. Pachetul distribuit va cuprinde toate pachetele care vor fi prezentate în cele ce urmează, fiind incluse sursele pentru toate clase, fișierele rezultate în urma compilării precum și documentația aferentă fiecărei clase.

Motivarea alegerii limbajului Java™

A fost ales limbajul de programare Java™ în primul rând datorită faptului că este un limbaj orientat pe obiecte, acest stil de programare fiind necesar pentru realizarea acestui set de funcții. Limbajele orientate pe obiect permit dezvoltarea ulterioară a programelor într-un mod ușor, atât datorită modularizării codului cât și datorită posibilității de a extinde clasele pentru care deja este scris codul, și adăugând noi funcționalități.

Un alt motiv pentru care a fost ales limbajul Java™ este documentația pusă la dispoziție. Toate clasele existente se găsesc într-o structură arborescentă, fiind derivate unele din altele. Pentru fiecare clasă este generată o pagină HTML în care sunt prezentate toate metodele, toți membrii și toate excepțiile aferente acelei clase. Navigarea este intuitivă, permitând vizualizarea claselor către care există o legătură. În plus, în cadrul forumului de discuții pot fi găsite explicații mai puțin formale, explicații furnizate de alți programatori care s-au confruntat cu o anumită problemă.

Pe lângă documentația pusă la dispoziție, limbajul Java™ permite și generarea automată a documentației pentru un anumit proiect. Programatorul trebuie să aibă grijă ca în cadrul codului sursă să introducă comentarii care să explice rolul unei clase sau funcționalitatea unei anumite metode și aceste comentarii sunt preluate de programul de generare a documentației și aranjate într-un fișier HTML similar celor care conțin documentația oficială. Există anumite formate speciale pentru a introduce o explicație pentru parametrul unei metode, pentru a explica ce returneză metoda respectivă sau ce excepții pot apărea atunci când este apelată.

Un alt motiv pentru care am ales limbajul de programare Java™ este faptul că acest limbaj își propune să fie independent de platformă, deci să nu restrângă dreptul utilizatorului de a folosi ce sistem dorește. Astfel, utilizatorul poate folosi orice sistem pentru care există o mașină virtuală Java (Java Virtual Machine) care să interpreteze codul de octeți rezultat în urma compilării. De aici rezultă și unul din marile dezavantaje ale acestui limbaj, și anume faptul că programele rezultate par a rula mai greoi decât programe similare scrise în alte limbaje.

În plus, limbajul de programare Java™ nu necesită licență, putând fi descărcat de pe internet și instalat fără costuri suplimentare.

Nu în ultimul rând, un motiv personal pentru alegerea acestui limbaj îl constituie familiaritatea lui, Java™ fiind limbajul de programare pe care l-am folosit cel mai mult în ultimii ani.

Pachetele distribuite și clasele mai importante

Clasele implementate au fost împărțite în pachete pentru a fi mai simplu de întreținut pe viitor. Astfel clasele care au roluri asemănătoare fac parte din același pachet. Dacă în viitor se va mai adăuga o clasă aceasta va fi alăturată pachetului care conține clase cu care noua clasă va semăna cel mai mult.

La momentul distribuirii, proiectul constă din 9 pachete, fiecare având un număr de clase cuprins între 2 și 16.

În continuare vom prezenta fiecare pachet, iar din cadrul acelui pachet vom prezenta mai detaliat clasele mai importante.

DSIG

Primul pachet prezentat este pachetul Dsig, numele prescurtat de la Digital SIGnature. Figura următoare prezintă un extras din pagina de documentație aferentă acestui pachet.

Figura 8: Descrierea generală a pachetului de clase „Dsig”

Acest pachet cuprinde clasele de nivel înalt ale proiectului, adică acele clase care folosesc obiecte ale căror clase au fost defintite în celelalte pachete ale proiectului. Cuprinde două clase, ConfigManager și XMLDSIG. A se observa că a fost preferată denumirea folosită în cadrul Recomandării W3C privind sintaxa și procesarea semnăturilor digitale și nu sintagma de ‚semnătură electronică’ folosită în standardele europene ETSI TS. Aceasta deoarece proiectul implemetează în primul rând funcționalitățile descrise pentru semnătura digitală, și mai puțin pe cele descrise pentru semnătura electronică.

ConfigManager

Clasa ConfigManager este folosită pentru stabilirea și pentru obținerea unor setări valabile în cadrul tuturor funcționalităților. Toate proprietățile și setările pentru aplicația de semnare digitală pot fi stabilite în cadrul unui fișier text de configurare, care este citit prin apelarea metodei init a acestei clase. Odată inițializată, clasa ConfigManager poate fi folosită pentru a obține valoarea unei anumite proprietăți ori de câte ori este necesar acest lucru.

Fișierul de configurare poate fi să existe atât local, fie în același director cu cel din care este rulată aplicația, fie în cadrul unei arhive Java, cât și pe internet, la o locație accesibilă, stabilită înainte de rularea aplicației. Mai jos este prezentat codul metodei init a acestei clase.

public static void init(String cfgFileName) {

try {

m_props = new Properties();

InputStream isCfg = null;

URL url = null;

if(cfgFileName.startsWith("http")) {

url = new URL(cfgFileName);

isCfg = url.openStream();

} else if(cfgFileName.startsWith("jar://")) {

ClassLoader cl=instance().getClass().getClassLoader();

isCfg =cl.getResourceAsStream(cfgFileName.substring(6));

} else {

isCfg = new FileInputStream(cfgFileName);

}

m_props.load(isCfg);

isCfg.close();

url = null;

} catch (Exception ex) {

System.err.println("Cannot read config file: " +

cfgFileName + " Reason: " + ex.toString());

}

XMLDSIG

Clasa XMLDSIG conține implementările metodelor de semnare și verificare a semnăturii. Aplicația va instanția această clasă și va apela una din metodele deja implementate, fie cea de semnare, fie cea de verificare a semnăturii.

Această clasă poate fi modificată ori de câte ori se dorește implementarea unei noi metode de semnare (un tip de semnare care să respecte o politică de semnare care nu a fost implementat până în prezent) sau pentru a modifica o metodă de semnare deja existentă.

Totuși nu este obligatoriu ca o anumită aplicație să instanțieze această clasă și să apeleze metode din cadrul ei. Aplicația își poate defini propria clasă care să cuprindă metodele de semnare și/sau verificare.

Data

Pachetul Data conține clase folosite pentru manevrarea datelor care urmează să fie semnate, respectiv a celor pentru care se face verificarea semnăturii. Imaginea de mai jos prezintă un extras din pagina de documentație aferantă acestui pachet, fiind ilustrate clase componente cu o scurtă descriere a lor.

Figura 9: Descrierea generală a pachetului de clase „Data”

Clasele din cadrul acestui pachet se ocupă de datele electronice pentru care, atunci când s-a decis semnarea, nu s-a furnizat și rezultatul unei funcții hash, fiind deci necesară calcularea de către aplicație a digest-ului. În aceeași situație se găsesc și datele pentru care se face verificarea semnăturii, în cadrul operației de validarea a referințelor, mai precis atunci când se face verificarea egalității dintre digest-ul furnizat de semnatar și digest-ul obținut de cel care face verificarea.

După cum am mai precizat, setul de clase distribuit permite ca digest-ul datelor care urmează să fie semnate să fie furnizat direct și nu calculat. În această situație se presupune că semnatarul a calculat acest digest cu o aplicație externă mai rapidă, o astfel de strategie fiind de preferat atunci când se dorește semnarea unor fișiere de mari dimensiuni (sute de Mega-octeți sau chiar mai mari). O altă situație când este preferabilă o astfel de strategie este aceea în care semnatarul trebuie să semneze același document de mai multe ori (poate în combinții diferite cu diverse alte documente) și când este de preferat să calculeze o singură dată valoare digest-ului și să o salveze pentru a o utiliza repetat. Desigur, în toate aceste situații, semnatarul își asumă un risc, anume acela al apariției unei oarecare discordanțe între varianta documentului pentru care s-a calculat digest-ul și varianta pentru care se face verificarea. Să nu uităm că modificarea unui singur octet din fișierul sursă duce la un rezultat cu totul diferit al funcției hash, și implicit la invalidarea semnăturii.

Data

Clasa Data este folosită pentru reprezentarea internă a fișierelor (sau a bucăților de fișiere) care urmează a fi folosite fie la semnare fie la verificare. Datele electronice sunt stocate în format binar, putând astfel să fie transmise direct ca parametru de intrare unei funcții hash.

Pentru fiecare unitate de date electronice (un fișier, sau o parte clar identificabilă a unui fișier – de exemplu un element unic dintr-un document XML) există un obiect de tip Data.

Fiecare unitate de date electronice este identificat prin URI (Uniform Resource Identifier) corespunzător blocului respectiv de date. Clasa Data conține pe lângă acest identificator URI și un obiect de date binare. Un obiect de tip Data poate fi construit doar pe baza unui URI, datele corespunzătoare putând fi încărcat folosind metoda load care instanțiază obiectul de date binare cu rezultatul dereferențierii URI-ului obiectului Data.

Una din metodele acestei clase generează un obiect de tip Reference corespunzător datelor reprezentate. Această metodă primește ca parametru o referință către obiectul de tip SignedInfo care va conține obiectul Reference generat, calculează digest-ului datelor respective și generează un obiect Reference folosind și restul informațiilor cunoscute: URI-ul corespunzător datelor, identificatorul algoritmului folosit pentru calcularea digest-ului și, dacă este cazul, lista de identificatori pentru algoritmii de transformare aplicați asupra datelor de intrare.

DataList

Atunci când se dorește semnarea mai multor documente în cadrul aceleași semnături digitale poate fi necesară instanțierea mai multor obiecte de tip Data. Pentru tratarea lor într-un mod unitar a fost creată clasa DataList, care nu este altceva decât un array de obiecte de tip Data.

Acestă clasă conține ca membrii un integer care reprezintă numărul de elemente din listă și un array de elemente de tip Data.

Clasa DataList pune la dispoziția utilizatorului metode necesare managementului unei liste de obiecte de tip Data, cum ar fi adăugarea sau eliminarea unui element, obținerea numărului total de elemente sau a unui anumit element din listă și o metodă care generează unitar toate elementele de tip Reference corespunzătoare obiectelor de date din respectiva listă. Acestă metodă poate fi folosită ca o metodă de a inițializa un obiect de tip SignedInfo. Metoda primește ca parametru o referință către obiectul de tip Signature care va conține noul obiect generat. După instanțierea obiectului SignedInfo este apelată metoda de generare a obiectelor de tip Reference din cadrul clasei Data, pentru fiecare element din listă.

Cache

Clasa Cache este folosită pentru implemetarea unei structuri de acces rapid la anumite obiecte mai des folosite. Fiecare instanță a acestei clase este caracterizată de o anumită capacitate, reprezentând numărul maxim de obiecte pe care obiectul respectiv le poate stoca.

Când o anumită instanță a clasei este plină și se încearcă adăugarea unui nou obiect, cel mai puțin recent folosit element este eliminat.

Acestă clasă este folosită în principal de metodele clasei URIDereferencer, pentru a stoca temporar documentele accesate. Acest lucru se poate dovedi folositor atunci când în lista de URI corespunzătoare datelor care trebuie încărcate se găsesc mai multe elemente din cadrul aceluiași document XML. În această situașie este de preferat ca documentul respectiv să fie încărcat din rețea o singură dată și stocat într-o astfel de structură, urmând ca elementele dorite să fie încărcate din obiectul Cache, decât să se încerce descărcarea de pe internet de fiecare dată când trebuie obținute alte date din același document.

URIDereferencer

Clasa URIDereferencer este folosită pentru a citi documente care corespund unor tipuri de URI diverse. Această clasă poate citi fișiere din CLASSPATH-ul aplicației, sau poate citi URI de tip resursă, sesiune, aplicație web, fișier, http sau https. Fiecare tip de URI este tratat în modul corespunzător, fiind urmate protocoalele specifice pentru descărcarea fișierelor de pe Internet, atunci când este cazul.

Metoda resolve a acestei clase împarte URI-ul în părțile componente (schemă, adresă și fragment) și încearcă rezolvarea respectivului URI în funcție de schema identificată. Trebuie menționat că aplicația nu oferă suport decât pentru un număr redus de scheme și nu pentru întreg setul de scheme.

Atunci când este determinat numele fișierului din care face parte resursa identificată prin acel URI prima dată se verifică dacă nu cumva acel fișier se găsește în structura de tip Cache inițializată. Dacă este găsit, citirea se face din Cache, dacă nu, după descărcare, fișierul respectiv este adăugat structurii Cache.

Vom ilustra în continuare modalitatea de a rezolva un URI prin prezentarea codului sursă pentru metoda readFromFile.

private InputStream readFromFile(String uri) throws FileNotFoundException {

String path = uri.substring("file://".length());

File file = new File(path);

InputStream fromCache =(InputStream) fileCache.getIfUpToDate(path, file.lastModified());

if (fromCache != null)

return fromCache;

try {

InputStream newRes =new FileInputStream(file);

fileCache.put(path, newRes);

return newRes;

} catch (FileNotFoundException ex) {

String msg = "Could not find file for URI " + uri;

throw ex;

}

XML

Acest pachet include clasele create pentru a reprezenta elementele XML întâlnite în cadrul unei semnături digitale.

Fiecare clasă are un nume identic cu tag-ul XML folosit în cadrul documentelor de semnătură digitală XML, conform standardului XML-Signature Syntax and Processing, descris în RFC 3275. Excepție de la această regulă fac clasa XmlNode care este o clasă generică construită pentru reprezentarea generală a unui element XML (nu neapărat cele descrise în standardul de semnătură digitală) și clasele folosite pentru reprezentarea specifică a elementului KeyInfo.

Imaginea următoare prezintă un extras din pagina de documentație corespunzătoare pachetului, putând fi observate scurte explicații pentru toate clasele componente.

Figura 10: Descrierea generală a pachetului de clase „XML”

Pentru elementul KeyInfo implementarea este specifică pentru fiecare algoritm implementat, deoarece elementele constituiente ale cheii publice diferă de la un algoritm la altul. Din acest motiv, clasa KeyInfo oferă o implementare minimală, care generează un element XML KeyInfo fără nici o informație, și pentru fiecare algoritm implementat este această clasă este extinsă astfel încât să genereze elementul KeyInfo în conformitate cu specificațiile algoritmului.

După cum se poate observa, sunt implementate în special clasele descrise în cadrul Recomandării W3C privind sintaxa și procesarea semnăturilor digitale și doar câteva clase din cele descrise în standardul european ETSI TS 101 903, privind structura semnăturii electronice extinse.

În general, clasele din acest pachet conțin o metodă numită xmlHeader care returnează obiectul de tip String reprezentând tag-ul de început al elementului XML corespunzător clasei respective, xmlTrailer, care returnează obiectul de tip Strin cu tag-ul de încheiere a elementului XML și metoda toXML care returnează un String cu reprezentarea întregului element XML, așa cum urmează a fi scris în fișier.

SignedDoc

Nivelul cel mai înalt al elementelor XML reprezentate este cel al documentului semnat, implementată în cadrul aplicației prin clasa SignedDoc. O instanță SignedDoc poate conține una sau mai multe instanțe ale clasei DataFile și zero sau mai multe instanțe ale clasei Signature. În plus, este necesară identificarea formatului documentului semnat și versiunea.

Această clasă conține o metodă, care permite scrierea documentului semnat într-un fișier. De remarcat faptul că până la apelarea acestei metode semnătura electronică există numai sub formă de obiecte în memorie, și deci este foarte important ca utilizatorul să nu uite să apeleze această metodă. Vom prezenta în continuare codul sursă pentru funcția de scriere în fișier.

public void writeToStream(OutputStream os)

throws XMLDSIGException

{

try {

os.write(xmlHeader().getBytes());

for(int i = 0; i < countDataFiles(); i++) {

DataFile df = getDataFile(i);

df.writeToFile(os);

os.write("\n".getBytes());

}

for(int i = 0; i < countSignatures(); i++) {

Signature sig = getSignature(i);

os.write(sig.toXML());

os.write("\n".getBytes());

}

os.write(xmlTrailer().getBytes());

} catch(XMLDSIGException ex) {

throw ex; // allready handled

} catch(Exception ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_WRITE_FILE);

}

La fel ca toate celelalte clase din cadrul acestui pachet, și SignedDoc conține o metodă numită toXML, care generează un obiect de tip String, care este reprezentarea fidelă a elementului XML respectiv. Practic, metoda de scriere în fișier a documentului nu face altceva decât să scrie rezultatul apelului acestei funcții. Vom prezenta și codul sursă pentru această funcție:

public String toXML()

throws XMLDSIGException

{

StringBuffer sb = new StringBuffer(xmlHeader());

for(int i = 0; i < countDataFiles(); i++) {

DataFile df = getDataFile(i);

sb.append(df.toString());

sb.append("\n");

}

for(int i = 0; i < countSignatures(); i++) {

Signature sig = getSignature(i);

sb.append(sig.toString());

sb.append("\n");

}

sb.append(xmlTrailer());

return sb.toString();

}

Această clasă mai conține o întreagă serie de funcții importante în economia generală a aplicației, cum ar fi metoda readCertificate de citire a unui certificat X509 sau metoda digest de calculare a rezultatului funcției hash SHA-1 asupra datelor primite ca parametru. Pe lângă funcția de citire a certificatului mai există câteva funcții de management a informațiilor din respectivul certificat, cum ar fi meteodele getSubjectFirstName, getSubjectLastName, getSubjectPersonalCode.

Bineînțeles că nu lipsesc metodele de setare și de obținere a conținutului elementelor componente ale acestei clase: getSignature, getFormat,getLastDataFile, pentru a numi dar câteva dintre ele.

Signature

Clasa Signature este reprezentarea obiectuală a elementului XML Signature, element de bază pentru o semnătură digitală. În limbaj Java™, un obiect de tip Signature poate conține o referință către obiectul SignedDoc de care aparține, un identificator (presupus unic) al semnăturii, un obiect de tip SignedInfo, unul de tip SignatureValue, și, atunci când este cazul, un obiect de tip KeyInfo, sau obiecte reprezentând proprietățile semnate sau nesemnate.

Cele mai multe metode ale acestei clase se ocupă de setarea componentelor și de obținerea informațiilor conținute în obiectele încapsulate în cadrul clasei Signature. Aceasta deoarece odată stabilite valorile pentru toate componentele, se poate folosi metoda toXML pentru a genera obiectul String care reprezintă elementul XML corespunzător, iar în cadrul acestei metode trebuie obținute informații despre obiectele conținute.

Vom ilustra în cele ce urmează codul sursă pentru metoda toXML corespunzătoare clasei Signature:

public byte[] toXML()

throws XMLDSIGException

{

ByteArrayOutputStream bos =

new ByteArrayOutputStream();

try {

bos.write(ConvertUtils.str2data("<Signature Id=\""));

bos.write(ConvertUtils.str2data(m_id));

bos.write(ConvertUtils.str2data("\" xmlns=\"http://www.w3.org/2000/09/xmldsig#\">\n"));

bos.write(m_signedInfo.toXML());

bos.write(ConvertUtils.str2data("\n"));

bos.write(m_signatureValue.toXML());

bos.write(ConvertUtils.str2data("\n"));

bos.write(m_keyInfo.toXML());

bos.write(ConvertUtils.str2data("\n<Object><QualifyingProperties>"));

if(m_sigProp != null)

bos.write(m_sigProp.toXML());

if(m_unsigProp != null)

bos.write(m_unsigProp.toXML());

bos.write(ConvertUtils.str2data("</QualifyingProperties></Object>\n"));

bos.write(ConvertUtils.str2data("</Signature>"));

} catch(IOException ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_XML_CONVERT);

}

return bos.toByteArray();

}

SignedInfo

Clasa SignedInfo reprezintă în limbajul Java™ elementul XML cu același nume. Un astfel de obiect trebuie să conțină o trimitere către obiectul de tip Signature care este tatăl acestui obiect, un indicator al metodei folosite pentru semnare (atât algoritmul de calculare a digest-ului, cât și algoritmul criptografic folosit), un indicator al metodei de canonicalizare precum și o listă de obiecte de tip Reference.

Pentru a trata cazul oarecum special al semnăturilor cu anvelopare (caz în care semnătura este fiu al elementului SignedInfo), clasa aceasta mai conține un membru, denumit origContent, care reține conținutul elementului SignedInfo, așa cum a fost ele citit din documentul XML.

Pe lângă obișnuitele metode de stabilire a valorilor membrilor componenți ai clasei și cele de obținere a obiectelor reprezentate de acei membrii, clasa conține o metodă de calculare a digest-ului prin utilizarea algoritmului SHA-1. Atunci când este apelată această funcție, este calculat fie digest-ul membrului origContent, fie digest-ul rezultatului metodei toXML(). Iată codul sursă al acestei metode:

public byte[] calculateDigest()

throws XMLDSIGException

{

CanonicalizationFactory canFac = ConfigManager. instance().getCanonicalizationFactory();

byte[] tmp = null;

if(m_origContent == null)

tmp = canFac.canonicalize(toXML(), SignedDoc.CANONICALIZATION_METHOD_20010315);

else

tmp = canFac.canonicalize(m_origContent, SignedDoc.CANONICALIZATION_METHOD_20010315);

return SignedDoc.digest(tmp);

}

Vom mai prezenta pentru această clasă și codul sursă al funcției toXML.

public byte[] toXML() throws XMLDSIGException

{

if(m_origContent == null) {

ByteArrayOutputStream bos =

new ByteArrayOutputStream();

try {

bos.write("<SignedInfo xmlns= \"http://www.w3.org/2000/09/xmldsig#\">\n".getBytes());

bos.write("<CanonicalizationMethod Algorithm=\"".getBytes());

bos.write(m_canonicalizationMethod.getBytes());

bos.write("\">\n</CanonicalizationMethod>\n".getBytes());

bos.write("<SignatureMethod Algorithm=\"".getBytes());

bos.write(m_signatureMethod.getBytes());

bos.write("\">\n</SignatureMethod>\n".getBytes());

for(int i = 0; (m_references != null) && (i < m_references.size()); i++) {

Reference ref = (Reference)m_references.get(i);

bos.write(ref.toXML());

bos.write("\n".getBytes());

}

bos.write("</SignedInfo>".getBytes());

} catch(IOException ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_XML_CONVERT);

}

return bos.toByteArray();

} else

return m_origContent;

}

Reference

Această clasă reprezntă un bloc Reference al unei semnături digitale, care se referă la o anumită resursă care urmează a fi semnată și conține digest-ul aferent respectivelor date electronice.

O instanță a acestei clase trebuie să conțină o referință către obiectul de tip SignedInfo de care aparține, un identificator al algoritmului folosit pentru calcularea digest-ului, un șir de octeți reprezentând valoarea digest-ului calculată pentru datele referite și un identificator al algoritmului de transformare a datelor aplicat asupra intrării înainte de aplicarea funcției hash.

Clasa conține funcțiile obișnuite pentru stabilirea valorilor membrilor componenți și pentru obținerea valorilor conținute în respectivii membrii. În plus există o metodă folosită pentru validarea digest-ului, prin verificarea lungimii șirului de octeți (în acest moment proiectul nu oferă suport decât pentru funcția de hash SHA-1 și pentru algoritmul criptografic RSA).

Ca de obicei, pentru clasele din acest pachet, vom prezenta funcția toXML:

public byte[] toXML()

throws XMLDSIGException

{

ByteArrayOutputStream bos =

new ByteArrayOutputStream();

try {

bos.write(ConvertUtils.str2data("<Reference URI=\""));

bos.write(ConvertUtils.str2data(m_uri));

if(m_sigInfo.getSignature().getSignedDoc().

getVersion().equals(SignedDoc.VERSION_1_2)) {

bos.write(ConvertUtils.str2data("\" Type= \"http://uri.etsi.org/01903/v1.1.1#SignedProperties"));

}

bos.write(ConvertUtils.str2data("\">\n"));

if(m_transformAlgorithm != null) {

bos.write(ConvertUtils.str2data("<Transforms><Transform Algorithm=\""));

bos.write(ConvertUtils.str2data(m_transformAlgorithm));

bos.write(ConvertUtils.str2data("\"></Transform></Transforms>\n"));

}

bos.write(ConvertUtils.str2data("<DigestMethod Algorithm=\""));

bos.write(ConvertUtils.str2data(m_digestAlgorithm));

bos.write(ConvertUtils.str2data("\">\n</DigestMethod>\n"));

bos.write(ConvertUtils.str2data("<DigestValue>"));

bos.write(ConvertUtils.str2data(Base64.encode(m_digestValue, 0)));

bos.write(ConvertUtils.str2data("</DigestValue>\n"));

bos.write(ConvertUtils.str2data("</Reference>"));

} catch(IOException ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_XML_CONVERT);

}

return bos.toByteArray();

}

SignedProperties

Una din clasele care implementează elemente descrise în standardul european ETSI TS 101 903 este clasa SignedProperties. Instanțierile acestei clase conțin în secțiunea de membrii toate posibilele proprietăți care trebuiesc semnate. Bineînțeles că primul membrul al acestei clase este o referință către elementul Signature de care aparține.

Dintre ceilalți membrii ai clasei mai enumerăm: un identificator (ID) pentru elementul SignedProperties, un indicator al target-ului pentru care este creat elementul, timpul la care a fost efectuată semnătura (măsurat de semnatar), numărul serial, algoritmul de digest, valoarea acelui digest și identificatorul certificatului semnatarului, locul unde a fost produsă semnătura, și rolul sau rolurile pe care semnatarul și le asumă.

Ca și restul claselor din acest pachet, și această clasă conține metode de stabilire și obținere a valorii pentru fiecare componentă, iar pentru unele dintre aceste componente sunt implementate chiar și funcții de validare (cum ar fi funcția de validare pentru algoritmul de digest folosit pentru semnarea certificatului semnatarului). La fel ca și pentru celelalte clase vom prezenta funcția toXML:

public byte[] toXML()

throws XMLDSIGException {

if(m_origContent == null) {

ByteArrayOutputStream bos =

new ByteArrayOutputStream();

try {

bos.write(ConvertUtils.str2data("<SignedProperties xmlns=\"http://www.w3.org/2000/09/xmldsig#\" Id=\""));

bos.write(ConvertUtils.str2data(m_id));

bos.write(ConvertUtils.str2data("\" Target=\""));

bos.write(ConvertUtils.str2data(m_target));

bos.write(ConvertUtils.str2data("\">\n"));

bos.write(ConvertUtils.str2data("<SignedSignatureProperties>\n<SigningTime>"));

bos.write(ConvertUtils.str2data(ConvertUtils.date2string(m_signingTime)));

bos.write(ConvertUtils.str2data("</SigningTime>\n<SigningCertificate>\n"));

bos.write(ConvertUtils.str2data("<Cert Id=\""));

bos.write(ConvertUtils.str2data(m_certId));

bos.write(ConvertUtils.str2data("\">\n<CertDigest>\n<DigestMethod Algorithm=\""));

bos.write(ConvertUtils.str2data(m_certDigestAlgorithm));

bos.write(ConvertUtils.str2data("\">\n</DigestMethod>\n<DigestValue>"));

bos.write(ConvertUtils.str2data(Base64.encode(m_certDigestValue, 0)));

bos.write(ConvertUtils.str2data("</DigestValue>\n</CertDigest>\n<IssuerSerial>"));

bos.write(ConvertUtils.str2data(m_certSerial.toString()));

bos.write(ConvertUtils.str2data("</IssuerSerial></Cert></SigningCertificate>\n"));

bos.write(ConvertUtils.str2data("<SignaturePolicyIdentifier>\n<SignaturePolicyImplied>\n</SignaturePolicyImplied>\n</ SignaturePolicyIdentifier>"));

if(m_address != null) {

bos.write(ConvertUtils.str2data("\n"));

bos.write(m_address.toXML());

}

if(countClaimedRoles() > 0) {

bos.write(ConvertUtils.str2data("\n<SignerRole>\n<ClaimedRoles>\n"));

for(int i = 0; i < countClaimedRoles(); i++) {

bos.write(ConvertUtils.str2data("<ClaimedRole>"));

bos.write(ConvertUtils.str2data(getClaimedRole(i)));

bos.write(ConvertUtils.str2data("</ClaimedRole>\n"));

}

bos.write(ConvertUtils.str2data("</ClaimedRoles>\n</SignerRole>\n"));

}

bos.write(ConvertUtils.str2data("</SignedSignatureProperties>\n"));

bos.write(ConvertUtils.str2data("<SignedDataObjectProperties>\n</SignedDataObjectProperties>\n"));

bos.write(ConvertUtils.str2data("</SignedProperties>"));

} catch(IOException ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_XML_CONVERT);

}

return bos.toByteArray();

} else

return m_origContent;

}

UnsignedProperties

O altă clasă care implementează un tip de element descris în standardul european privind semnăturile electronice extinse este clasa UnsignedProperties. La fel ca și pentru clasa SignedProperties, o instanțiere a acestei clase trebuie să cuprindă o referință către elementul de tip Signature de care aparține.

Clasa mai cuprinde elemente utile pentru faza de verificare, dar care nu sunt atât de sensibile la apariția modificărilor încât să fie nevoie să fie semnate. Aceste elemente sunt: lista completă a referințelor certificatelor, lista completă de căi de revocare, lista certificatelor respondenților și un obiect de datele primite de la un server OCSP.

Mai jos este prezentată funcția toXML aferentă acestei clase:

public byte[] toXML()

throws XMLDSIGException {

ByteArrayOutputStream bos =

new ByteArrayOutputStream();

try {

bos.write(ConvertUtils.str2data("<UnsignedProperties Target=\"#"));

bos.write(ConvertUtils.str2data(m_signature.getId()));

bos.write(ConvertUtils.str2data("\">\n<UnsignedSignatureProperties>"));

if(m_certRefs != null)

bos.write(m_certRefs.toXML());

if(m_revRefs != null) {

bos.write(m_revRefs.toXML());

bos.write(ConvertUtils.str2data("\n"));

}

if(m_respondersCert != null) {

bos.write(ConvertUtils.str2data("<CertificateValues>\n<EncapsulatedX509Certificate Id=\""));

bos.write(ConvertUtils.str2data(m_signature.getId()));

bos.write(ConvertUtils.str2data("-RESPONDER_CERT\">\n"));

try {

bos.write(ConvertUtils.str2data(Base64.encode(m_respondersCert.getEncoded(), 64)));

} catch(CertificateEncodingException ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_ENCODING);

}

bos.write(ConvertUtils.str2data("</EncapsulatedX509Certificate>\n</CertificateValues>"));

}

if(m_notary != null) {

bos.write(ConvertUtils.str2data("\n"));

bos.write(m_notary.toXML());

}

bos.write(ConvertUtils.str2data("</UnsignedSignatureProperties>\n</UnsignedProperties>"));

} catch(IOException ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_XML_CONVERT);

}

return bos.toByteArray();

}

SignatureValue

Clasa SignatureValue este reprezentarea în limbaj Java™ a elementului corespunzător din standardul de semnătură digitală XML. Este una din cele mai simple clase, la fel cum elementul pe care îl reprezintă este unul dintre cele mai simple. Menirea elementului SignatureValue este aceea de a reprezenta rezultatul operației criptografice de semnare. Prin urmare, și clasa Java™ corespuzătoare nu are decât doi membri, cel care indică elementul Signature de care aparține și un șir de octeți care stochează rezultatul criptografic.

Metoda toXML este de asemenea simplă:

public byte[] toXML() throws XMLDSIGException {

ByteArrayOutputStream bos =

new ByteArrayOutputStream();

try {

bos.write(ConvertUtils.str2data("<SignatureValue Id=\""));

bos.write(ConvertUtils.str2data(m_id));

bos.write(ConvertUtils.str2data("\">"));

bos.write(ConvertUtils.str2data(Base64.encode(m_value, 64)));

bos.write(ConvertUtils.str2data("</SignatureValue>"));

} catch(IOException ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_XML_CONVERT);

}

return bos.toByteArray();

}

RSAKeyInfo

În cadrul acestui proiect s-a implementat clasa RSAKeyInfo pentru reprezentarea unui element XML KeyInfo. S-a ales această soluție deoarece în această versiune, proiectul nu oferă suport decât pentru algoritmul criptografic RSA. Acest element XML este dependent de implementarea aleasă, deoarece pentru algoritmi diferiți informația necesară pentru construirea cheii publice este de asemenea diferită.

Practic, clasa conține un obiect de tip certificat X509 din care va prelua informațiile despre cheie necesare. Acest lucru poate fi observat și din modul în care este implementată funcția toXML:

public byte[] toXML()

throws XMLDSIGException {

ByteArrayOutputStream bos =

new ByteArrayOutputStream();

try {

bos.write(ConvertUtils.str2data("<KeyInfo>\n"));

bos.write(ConvertUtils.str2data("<KeyValue>\n<RSAKeyValue>\n<Modulus>"));

bos.write(ConvertUtils.str2data(Base64.encode(getSignerKeyModulus().toByteArray(), 64)));

bos.write(ConvertUtils.str2data("</Modulus>\n<Exponent>"));

bos.write(ConvertUtils.str2data(Base64.encode(getSignerKeyExponent().toByteArray(), 64)));

bos.write(ConvertUtils.str2data("</Exponent>\n</RSAKeyValue>\n</KeyValue>\n"));

bos.write(ConvertUtils.str2data("<X509Data><X509Certificate>"));

try {

bos.write(ConvertUtils.str2data(Base64.encode(m_signersCert.getEncoded(), 64)));

} catch(CertificateEncodingException ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_ENCODING);

}

bos.write(ConvertUtils.str2data("</X509Certificate></X509Data>"));

bos.write(ConvertUtils.str2data("</KeyInfo>"));

} catch(IOException ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_XML_CONVERT);

}

return bos.toByteArray();

}

Utils

Pachetul Utils conține câteva clase utilitare, folosite ca și clase de suport pentru restul pachetelor. În imaginea următoare se poate observa un extras din pagina de documentație a acestui pachet, unde sunt trecute scurte descrieri ale claselor componente, precum și o descriere a întregului pachet.

Figura 11: Descrierea generală a pachetului de clase „Utils”

XMLContainer

Clasa XMLContainer este folosită pentru a păstra într-o structură similară celei de cache un rezultat al cerințe de extragere a informațiilor dintr-un document XML. Pentru fiecare element din cadrul listei, clasa păstrează informații despre calculatorul gazdă, despre rangul respectivului element în interiorul listei, și stream-ul de octeți reprezentând documentul XML.

Elementele din cadrul acestei liste pot fi returnate sub forma reprezentării lor DOM, folosind metoda getXML, prezentată în continuare:

public final org.jdom.Element getXML(int index) {

if ((index < 0) || (index >= host.size())) {

return null;

}

return (org.jdom.Element) xml.get(index);

}

Clasa mai oferă posibilitatea managementului listei de rezultate prin adăugarea unui element, prin permutarea tuturor elementelor sau prin eliminarea tuturor elementelor începând cu cel care are indexul ‚n’. În plus, întreaga listă poate fi salvată într-un document XML cu structură specifică, utilizând una din metodele exportAllToByteArray sau exportAllToDocument. Vom prezenta doar una din aceste metode:

public final org.jdom.Document exportAllToDocument() {

org.jdom.Element root = new org.jdom.Element(TAG_RESULTS);

root.addNamespaceDeclaration(org.jdom.Namespace

.getNamespace("xlink", XLINK_URL));

root.addNamespaceDeclaration(org.jdom.Namespace

.getNamespace("xsi", XSI_URL));

org.jdom.Document doc = new org.jdom.Document(root);

for (int i = 0; i < rank.size(); i++) {

org.jdom.Element res = new org.jdom.Element(TAG_RESULT);

res.setAttribute(ATTR_HOST, ((String) host.get(i)).trim());

res.setAttribute(ATTR_ID, ((String) Id.get(i)).trim());

res.setAttribute(ATTR_RANK, rank.get(i).toString());

res.setAttribute(ATTR_PRED,

(((((getStatus(i) >> 1)) % 2) == 1) ? "true" : "false"));

res.setAttribute(ATTR_SUCC, ((((getStatus(i)) % 2) == 1) ? "true"

: "false"));

org.jdom.Element tmp = (Element) ((Element) xml.get(i)).clone();

res.addContent(tmp);

root.addContent(res);

}

return doc;

}

ConvertUtils

Această clasă conține diverse metode de conversie a datelor de intrare într-un alt tip, sau în același tip dar într-un alt format. Clasa cuprinde metode de transformare din tipul integer sau dintr-un șir de octeți în tipul String, sau de modificare a unui String din format obișnuit în format UTF-8.

Tot în cadrul acestei clase a fost imlementată o funcție de salvare a unui document XML din format intern – DOM – într-un fișier pe disc.

De asemenea clasa conține o metodă de formatare a unui String pentru a putea fi salvat într-un document XML prin înlocuirea caracterelor speciale cu codurile lor corespunzătoare.

Crypto

Pachetul Crypto conține clasele care implementează diverși algoritmi criptografici sau de calculare a funcțiilor hash. Pachetul conține trei clase generice și un exemplu de implementare pentru un algoritm criptografic. Următoarele implementări de algoritmi trebuie să extindă clasa generică corespunzătoare lor.

Și pentru acest pachet vom prezenta extrasul din pagina de documentație pentru a arată descrierea pachetului și scurtele descrieri ale claselor pe care le conține.

Figura 12: Descrierea generală a pachetului de clase „Crypto”

Algorithm

Clasa generică Algorithm are rolul de a asigura implementarea tuturor algortimilor critpografici folosiți într-o mannieră unitară. Este de dorit acest lucru pentru a putea scrie funcții care să utlizeze acești algoritmi fără a conta care dintre acesti algoritmi este folosit efectiv. Cu alte cuvinte, funcțiile care au nevoie de rezultatul unui algoritm criptografic nu trebuie neapărat să cunoască detalii tehnice despre acel algoritm, ci doar că pentru un anume tip de intrare algoritmul furnizează un anume tip de ieșire.

Este știut că una din proprietățile programării orientate pe obiecte este aceea că permite ca un obiect dintr-o anumită clasă să fie instanțiat ca aparținând oricărei clase derivate din prima clasă. Folosind această proprietate este de dorit ca funcțiile care trebuie să folosească algoritmi criptografici să fie scrise folosind metodele din clasa generică Algorithm, iar la rulare să fie apelate metodele corespunzătoare din clasa care implementează algoritmul dorit, instanțiat ca atare.

Transform

Pachetul Transform conține clasele care implementează funcțiile și algoritmii de transformare a datelor. Operațiile de transformare a datelor se execută înainte de aplicarea funcțiilor de hash. În acest moment este recomandată cel puțin transformarea C14N, de canonicalizare a unui document XML, de altfel și singura transformare implementată efectiv în cadrul acestui pachet.

Figura 13: Descrierea generală a pachetului de clase „Transform”

Transform

Clasa Transform este o clasă generică pentru a permite ca implementările ulterioare ale claselor de transformare să fie făcute într-un mod unitar.

La fel ca în cazul clasei generice Algorithm, este de dorit ca funcțiile care trebuie să folosească rezultatele unei operații de transformare să poată fi scrise folosind metode din clasa Trasform, pentru ca apoi, la rulare, să fie apelate metodele din clasele pentru care a fost instanțiat obiectul respectiv.

Ca un minim, clasele de transformare trebuie să conțină o metodă care să returneze indentificator algoritmului de transformare implementat, și o metodă care să primească un Stream de intrare (datele înainte de transformare) și să returneze un Stream de ieșire (datele rezultate după transformare).

Base64

Clasa Base64 nu este o clasă care implementează un algoritm de transformare a unui document XML, însă a fost inclusă în acest pachet datorită imortanței pe care o are. Clasa este folosită pentru transformarea unui șir de octeți (care, interpretat ca un șir de caractere poate conține și anumite caractere netipăribile, și deci imposibil de utilizat în cadrul unui fișier text, așa cum sunt documentele XML) într-un șir de caractere care aparțin toate setului tipăribil. Acest lucru se realizează prin stabilirea unei relații între fiecare 6 biți din șirul de octeți și un anume caracter. Rezultă că sunt necesar 64 de caractere pentru a reprezenta orice șir de octeță, de aici provenind și numele transformării.

Clasa pune la dispoziția utilizatorilor funcții de codare și de decodare în și din format Base64. Vom începe prin a prezenta funcție de codare:

public static String encode(byte[] raw, int wrap) {

//calculate length of encoded string

int encLen = ((raw.length + 2) / 3) * 4;

//adjust for newlines

if (wrap > 3) {

wrap -= wrap % 4;

encLen += 2 * (encLen / wrap);

} else { //disable wrapping

wrap = Integer.MAX_VALUE;

}

StringBuffer encoded = new StringBuffer(encLen);

int len3 = (raw.length / 3) * 3;

int outLen = 0; //length of output line

for (int i = 0; i < len3; i += 3, outLen += 4) {

if (outLen + 4 > wrap) {

encoded.append(LINE_SEPARATOR);

outLen = 0;

}

//System.out.println("Encode offset: " + i);

encoded.append(encodeFullBlock(raw, i));

}

if (outLen >= wrap) { //this will produce an extra newline if needed !? Sun had it this way…

encoded.append(LINE_SEPARATOR);

}

if (len3 < raw.length) {

//System.out.println("Encode offset: " + len3);

encoded.append(encodeBlock(raw, len3));

}

return encoded.toString();

}

Funcția prezentată mai sus este apelată din interiorul unei alte funcții care efectuează codare unui întreg bloc de octeți:

protected static char[] encodeBlock(byte[] raw, int offset) {

int block = 0;

int slack = raw.length – offset – 1;

int end = (slack >= 2) ? 2 : slack;

for (int i = 0; i < 3; i++) {

byte b= (offset + i<raw.length) ? raw[offset + i] : 0;

int neuter = (b < 0) ? b + 256 : b;

block <<= 8;

block += neuter;

}

char[] base64 = new char[4];

for (int i = 3; i >= 0; i–) {

int sixBit = block & 0x3f;

base64[i] = getChar(sixBit);

block >>= 6;

}

if (slack < 1)

base64[2] = '=';

if (slack < 2)

base64[3] = '=';

return base64;

}

DOMc14n

Clasa DOMc14n implementează algoritmul de aducere a unui document XML la forma canonică. Canonicalizarea este efectuată utilizând forma DOM a unui document XML și comenzi XPATH.

Această clasă implementează această transformare prin instanțierea clasei de canonicalizare pusă la dispoziție de către firma Apache. Vom prezenta în cele ce urmează codul sursă pentru această funcție:

public byte[] canonicalize(byte[] data, String uri)

throws XMLDSIGException {

byte[] result = null;

try {

Canonicalizer c14n = Canonicalizer. getInstance ("http://www.w3.org/TR/2001/REC-xml-c14n-20010315");

result = c14n.canonicalize(data);

} catch(Exception ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_CAN_ERROR);

}

return result;

}

Certificate

Pachetul Certificate a fost inclus pentru a oferi o locație pentru toate implementările claselor care reprezintă certificate.

Figura 14: Descrierea generală a pachetului de clase „Certificate”

Clasa conținută în acest moment în pachet, IAIKOCSPDataFactory, implementează un certificat X509, dar oferă și unele metode pentru tratarea unui răsopuns de la un server de OCSP.

Vom prezenta metoda de obținere a răspunsului unui server OCSP atunci când este trimisă o cerere în acest sens:

private OCSPResponse sendRequest(OCSPRequest req)

throws XMLDSIGException {

OCSPResponse resp = null;

try {

byte[] breq = req.getEncoded();

String responderUrl = ConfigManager.instance().

getProperty("DIGIDOC_OCSP_RESPONDER_URL");

URL url = new URL(responderUrl);

URLConnection con = url.openConnection();

con.setAllowUserInteraction(false);

con.setUseCaches(false);

con.setDoOutput(true);

con.setDoInput(true);

// send the OCSP request

con.setRequestProperty("Content-Type", "application/ocsp-request");

OutputStream os = con.getOutputStream();

os.write(breq);

os.close();

// read the response

InputStream is = con.getInputStream();

int cl = con.getContentLength();

byte[] bresp = null;

//System.out.println("Content: " + cl + " bytes");

if(cl > 0) {

int avail = 0;

do {

avail = is.available();

byte[] data = new byte[avail];

int rc = is.read(data);

if(bresp == null) {

bresp = new byte[rc];

System.arraycopy(data, 0, bresp, 0, rc);

} else {

byte[] tmp = new byte[bresp.length + rc];

System.arraycopy(bresp, 0, tmp, 0, bresp.length);

System.arraycopy(data, 0, tmp, bresp.length, rc);

bresp = tmp;

}

//System.out.println("Got: " + avail + "/" + rc + " bytes!");

cl -= rc;

} while(cl > 0);

}

is.close();

if(bresp != null) {

resp = new OCSPResponse(bresp);

//System.out.println("Response: " + resp.toString());

}

} catch(Exception ex) {

XMLDSIGException.handleException(ex, XMLDSIGException.ERR_OCSP_REQ_SEND);

}

return resp;

}

Factory

Pachetul Factory conține în principal interfețe pentru diverse clase care sunt implementate în alte pachete, cum ar fi clasa de canonicalizare sau cea de obținere a datelor de la un server de OCSP. Imaginea de mai jos prezintă un extras din pagina de documenție a pachetului, putând fi observate descrierile sumare pentru clasele și interfețele din acest pachet.

Figura 15: Descrierea generală a pachetului de clase „Factory”

Exceptions

Pachetul Exception conține clasele care implementează în mod unitar toate excepțiile care pot apărea în cadrul proiectului.

Excepțiile sunt grupate în trei clase, fiecare din ele grupând excepțiile care pot apărea la lucrul cu URI, la lucrul cu documentele XML sau anumite excepții generale care pot apărea în cadrul proiectului.

Fiind grupate în cadrul acestor clase toate excepțiile, se pot construi în mod unitar mesajele de avertizare a utilizatorului atunci când apare o situație nedorită.

Imaginea de mai jos prezintă descrierea pachetului și a claselor componente.

Figura 16: Descrierea generală a pachetului de clase „Exceptions”

Dataflow general

În cadrul acestui subcapitol vom prezenta pașii care trebuie urmați pentru a semna, respectiv pentru a verfica o semnătură digitală.

Semnare

Figura 17: Fluxul datelor și obiectelor pentru generarea unei semnături

Imaginea de mai sus prezintă într-un mod figurat pașii pe care îi vom detalia în cele ce urmează.

Determinarea referințelor

O referință constă dintr-un URI care identifică o anumită resursă. La nivel de reprezentare, un URI este un șir de caractere, un String. Resursa identificată poate fi:

Un fișier local

Un fișier pe internet

Un document XML (local sau pe internet)

Un element dintr-un document XML (local sau pe internet)

Insuși documentul XML care conține semnătura

Un element din documentul XML care conține semnătura

În general, datele identificate printr-un URI pot fi încărcate în cadrul aplicației. În cadrul pachetului Data există clasa URIDerefencer care permite căutarea și preluarea datelelor reprezentate de acel URI. Aceasta împarte URI-ul în părți componente și în funcție de structura existentă încarcă fișierul local, caută și încearcă să descarce fișierul din rețea sau caută un anume element din cadrul unui fișier (local sau în rețea).

Totuși, nu este absolută nevoie ca datele sa fie reprezentate în interiorul aplicației (să ne gândim la situațiile în care se dorește semnarea unor fișiere de dimensiuni mari și foarte mari, situație în care operația de încărcare poate introduce un consum de timp și de resurse mult prea mare – cu atât mai mare în cazul în care se impune și descărcarea de pe internet).

Calculare digest

Calcularea hash-ului pentru datele reprezentate este singurul motiv pentru care s-ar putea dori încarcarea lor în cadrul aplicației.

În cazul în care se dorește calcularea hash-ului cu unul din algoritmii de hash-are implementați, este necesară încărcarea datelor într-un InputStream. Acesta este trimis ca parametru funcției de hash-are care returnează șirul de octeți rezultați. Pentru a putea fi reprezentați în mod text în cadrul documentului XML, obiectul byte[] trebuie transformat de una din metodele clasei Base64, devenind un String.

În cazul în care nu se dorește încărcarea datelor în cadrul aplicației, sau în cazul în care se preferă folosirea unui algoritm extern de determinare a hash-ului, este necesară introducerea separată a valorii obtinuțe. Pentru a permite acest lucru, clasa Reference conține o metodă de setare a paramentrului digest_value.

Grupare referințe într-un signedInfo

Odată determinate referințele și hash-ul pentru ele, se poate trece la construirea obiectului SignedInfo. Când există o instanță a clasei SignedInfo se setează parametrul sigInfo pentru fiecare obiect de tip Reference. Parametrul respectiv creează o legatură între un obiect de tip Reference și obiectul SignedInfo de care aparține.

De remarcat că același lucru poate fi făcut și cu ajutorul clasei DataList a cărei metodă, generateSignedInfo, creează un element SignedInfo, și apoi, pentru fiecare element Data creează obiectul Reference corespunzător.

Clasa SignedInfo conține metode de gestionare a referințelor (adăugare, numărare, returnare).

Calculare digest pentru SignedInfo

Odată adunate toate referințele precum și restul proprietăților care trebuiesc semnate, se poate calcula digestul pentru acest obiect. Metoda calculateDigest a clasei SignedInfo face calculul pentru rezultatul operației de canonicalizare asupra conținutului obiectului. Rezultatul este de asemenea sub forma unui byte[] și va trebui transformat Base64 pentru a putea fi folosit (trecut in documentul XML).

Semnare digest SignedInfo

Odată obținut șirul de octeți care reprezintă digestul elementului SignedInfo, acesta poate fi semnat. Pentru aceasta se utilizează metoda corespunzătoare din clasa care implemetează algoritmul de semnare. Toți algoritmii de semnare se găsesc în pachetul Crypto și sunt extensii ale clasei Algorithm.

Elementul de tip SignedInfo este adăugat în cadrul unui Signature, care la rândul lui este adăugat în cadrul unui element SignedDoc.

Adăugare informații despre cheie

Pentru a putea permite verificarea semnăturii, trebuie introduse informațiile necessare pentru obținerea cheii de verificare a semnăturii. Structura acestui element diferă de la algoritm la algoritm, prin urmare va exista o metodă în clasa care implementează algoritmul de semnare care se va ocupa de acest lucru.

Adăugare informații suplimentare

În cazul în care semnatarul consideră necesar (sau în funcție de politica de semnare stabilită între cele două entități) în cadrul elementului Signature pot fi adaugate și alte elemente, care trebuiesc grupate în interiorul unui element UnsignedProperties, adăugat la rândul lui elementului Signature.

Verificare

Figura 18: Fluxul de date și obiecte pentru verificarea unei semnături

Pașii prezentați în manieră figurativă în imaginea de mai sus vor fi detaliați în cadrul acestui subcapitol.

Identificarea semnăturii care trebuie verificată

Când se face verificarea unei semnături, primul lucru care trebuie făcut este identificarea semnăturii care urmează a fi verificată. Acest pas este necesar deoarece în cadrul aceluiași document XML pot exista mai multe semnături. Însă fiecare semnătura are un ID unic în cadrul acelui document. Pe baza documentului și a acelui ID se poate construi un URI care să identifice elementul Signature care ne interesează. Acest lucru se poate face și grafic, dupa încărcarea documentului XML și vizualizarea arborelui DOM asociat se poate selecta semnătura dorită.

Extragerea elementului SignedInfo

Clasa Signature are o metodă getSignedInfo care returnează elementul SignedInfo din cadrul acelei semnături.

Calculare digest asupra elementului SignedInfo

Metoda calculateDigest a clasei SignedInfo face calculul pentru rezultatul operației de canonicalizare asupra conținutului obiectului. Rezultatul este sub forma unui byte[].

Calcularea cheii de verificare

Clasa pentru algoritmul de semnare folosit trebuie să conțină o metodă care pe baza unui element KeyInfo să poată genera o cheie de verificare. Acest lucru trebuie făcut de clasa algoritmului de criptare folosit deoarece tot aceasta clasa este cea care generează elementul KeyInfo (structura și modul de generare a cheilor depind de tipul algoritmului folosit).

Verificarea semnăturii

Odată obținută cheia de verificare a semnăturii, se poate aplica metoda de verificare din clasa algoritmului de criptare folosit pentru a inversa operația de semnare. Se obține un byte[] care ar trebui sa reprezinte digest-ul elementului SignedInfo înainte de semnare.

Compararea celor două digest-uri

În cadrul clasei SignedDoc există o metodă compareDigest care este utilizată pentru a verifica dacă cele două digest-uri (cel calculat de cel care verifică semnătura și cel obținut din decriptarea semnăturii) sunt egale.

Aplicație

În cele ce urmează vom prezenta cât de ușor poate fi construită o aplicație folosindu-ne de clasele deja descrise în capitolul anterior.

Scopul aplicației

În cadrul acestui capitol va fi prezentată o aplicație de generare a unei semnături electronice. Scopul acestei implementări este să demonstreze cât este de ușor să se creeze aplicații pentru acest domeniu atunci când partea de manipulare a elementelor XML implicate în cadrul semnăturii electronice în XML este implementată în cadrul unui API.

Aplicația nu își propune să fie o aplicație „la cheie”, care să poată fi folosită în alt domeniu decât cel educațional, deoarece pentru acest tip de aplicații este de preferat să fie cunoscută cel puțin politica de semnare pe care o entitate dorește să o implementeze. Cerințele care se impun unei aplicații de semnare pot varia foarte mult de la un utilizator la altul chiar și în cadrul aceleiași organizații. Mai mult chiar, aceeași persoană poate dori să implenteze mai multe politici de semnare în funcție de destinatarul semnăturii. De exemplu, un manager de proiect are nevoie de o semnătură simplă atunci când trebuie să comunice cu angajații direcți sau cu superiorii imediat ierarhici, însă atunci când trebuie să încheie contracte cu un client (și deci face acest lucru în calitate oficială, de reprezentant al organizației din care face parte) trebuie să folosească un tip de semnătură care să aibă efect juridic.

Așa cum vom arăta în continuare, crearea unei astfel de aplicații implică doar implementarea unor modalități de a obține de la utilizator datele și informațiile care vor deveni parametrii funcțiilor al căror cod a fost scris în cadrul claselor prezentate în cadrul capitolului anterior și implementarea unor modalități de a furniza respectivele date către funcții. Partea a doua ar putea implica eventuale modificări ale tipului de date folosit și poate chiar unele conversii.

După cum se va vedea, una din posibilitățile de a realiza cele două deziderate de mai sus o constituie construirea unei interfețe grafice care să-i prezinte utilizatorului valorile posibile pentru diverși parametrii și indicatori, oferindu-i posibilitatea de a alege valoarea care corespunde nevoilor de securitate de la momentul respectiv. Valorile respective pot fi prezentate folosindu-se obiecte standard din cadrul interfețelor grafice, cum ar fi checkbox-uri, radio-buttons sau liste de tip drop-down.

După alegerea tuturor parametrilor, informațiilor și datelor implicate în operațiunea de generare sau de verificare a semnăturii electronice, este apelată o funcție care nu are altceva de făcut decâ să furnizeze toate datele citite, în formatul corespunzător, către metodele din clasele găsite în pachetele distribuite. Apoi aceeași funcție trebuie să preia datele furnizate și să le prezinte utilizatorului conform cerințelor acestuia.

Prezentare aplicației de semnare

Aplicația de semnare a fost realizată prin construirea unei interfețe grafice de interacționare cu utilizatorul. În spatele acestei interfețe, datele introduse de utilizator sunt interpretate, transformate în obiecte de tipuri corespunzătoare de date și livrat ca parametrii unor funcții din cele implementate în cadrul pachetelor prezentate în capitolul anterior.

Interfața grafică este concepută ca o înșiruire de ‚frame’-uri, iar în cadrul fiecărui frame utilizatorul trebuie să facă anumite alegeri privind parametrii, datele și informațiile necesare construirii semnăturii electronice.

Ecranul de configurare

Primul cadru care îi este prezentat utilizatorului este unul de configurare generală. El este prezentat în figura următoare:

Figura 19: Frame-ul de configurare pentru aplicația de semnare

În cadrul acestui ecran utilizatorul trebuie să aleagă algoritmii folosiți pentru generarea semnăturii și dacă semnătura electronică care urmează a fi generată va fi adăugată unui document XML deja existent, sau aplicația va trebui să creeze un nou document.

Aplicația furnizează niște valori implicite pentru aceste setări, acestea fiind de fapt doar niște sugestii făcute utilizatorului, care poate șă le schimbe.

În ceea ce privește algoritmul folosit pentru calcularea digest-ului, pentru această aplicație au fost oferite ca posibilități de alegere funcțiile de hash MD-5 și SHA-1, valoarea implicită fiind considerată SHA-1. Cele două posibilități sunt prezentate printr-un radio-button, doar una dintre ele putând fi selectată la un moment dat.

Tot printr-un radio-button sunt prezentate și possibilitățile de alegere pentru algoritmul criptografic folosit pentru semnarea rezultatului operației de hash-are aplicată asupra elementului SignedInfo. Cele două posibilități constau în algoritmii de criptare asimetrică RSA și DSA, iar valoarea implicită este DSA.

După ce utilizatorul a ales algoritmul de calculare a digest-ului și de semnare, aplicația poate construi identificatorul metodei de semnare, care va trebui trecut ca valoare a atributului Algorithm al elementului SignatureMethod din cadrul SignedInfo. De asemenea este cunoscută și valoarea care va fi trecută în elementele Reference în dreptul identificatorului pentru algoritmul de digest folosit.

A treia alegere pe care utilizatorul trebuie să o facă în această fereastră este cea legată de utilizarea unui document XML existent sau de creare a unuia nou. Implicit, pentru această alegere este considerată crearea unui document nou.

Numele documentului care va conține semnătura este trecut în cadrul unui textField, deci este o valoare care poate fi modificată (editată) de către utilizator. Și pentru acest câmp este furnizată o valoare implicită.

Atunci când utilizatorul alege să folosească un document XML existent, se activează butonul ‚Browse’, care permite deschiderea unei ferestre de alegere a fișierului în care se dorește adăugarea semnăturii. Alegerea se face dintr-o fereastră precum cea din imaginea de mai jos:

Figura 20: Fereastra de alegere a unui document XML

După ce utilizatorul determină documentul în care se va face adăugarea, numele fișierului respectiv va apărea în cadrul textField-ului la care s-a făcut referire mai sus. Acest lucru este ilustrat și în imaginea următoare:

Figura 21: Ecranul de configurare după alegerea documentului

Primul cadru mai conține două butoane, unul de avansare către următorul cadru (butonul ‚Next’) și unul de renunțare și de închidere a aplicației (butonul ‚Cancel’). La apăsarea acestui din urmă buton, toate datele introduse sau calculate până în acel moment se pierd, deci trebuie avut grijă să nu fie apăsat accidental.

Ecranul de introducere a datelor

După ce utilizatorul decide că toate setările sunt conforme cu scopul pentru care realizează semnătura electronică, el poate decide să avanseze la următorul ecran, cel de alegere a datelor care urmează să fie semnate. După cum s-a mai precizat în cadrul capitolelor anterioare, într-o aplicație de semnare electronică pot fi semnate mai multe obiecte de date într-o singură operație.

Ecranul de introducere a datelor care trebuie semnate permite introducerea mai multor obiecte de date. Introducerea se face folosind o listă al cărei conținut îi este prezentat utilizatorului, listă a cărei elemente sunt URI-urile corespunzătoare alegerilor făcute de utilizator.

Imaginea următoare prezintă ecranul de alegere a datelor care urmează a fi semnate.

Figura 22: Frame-ul de alegere a datelor care vor fi semnate

În partea stângă a ecranului este prezentată lista așa cum este ea la un moment dat, în timp ce în partea dreaptă sunt plasate elemente care să-i permită utilizatorului adăugarea unui nou element respectivei liste.

Există două posibilități de adăugare a unui element. Prima posibilitate este aceea de adăugare a unui întreg fișier, iar a doua este de introducere doar a unui element dintr-un fișier (de obicei este vorba de elemente din documente XML).

Pentru introducerea unui fișier se poate folosi fie fereastra de alegere a unui fișier care apare la apăsarea butonului ‚Browse’ fie simpla introducere a valorii URI-ului care reprezintă resursa respectivă. La apăsarea butonului ‚Add File’, este adăugată o nouă intrare în lista de URI și este reinițializat textField-ul corespunzător.

Dacă fișierul care este ales este unul cu extensia .xml, se activează și butonul de adăugare a unui element din cadrul fișierului. La apăsarea lui se deschide o fereastră în care este prezentată structura arborescentă a fișierului XML, iar utilizatorul poate selecta un anume element pentru a fi adăugat în listă. Acestă fereastră este prezentată și în imaginea următoare.

Figura 23: Frame care prezintă structura unui document XML

La fel ca și Frame-ul anterior, și ecranul de alegere a datelor care urmează a fi semnate conține butoanele de avansare către următorul ecran și pe cel de renunțare.

În momentul avansării la ecranul următor, aplicația are toate datele necesare construirii elementelor de tip Reference, și deci, și a elementului SignedInfo.

Se poate chiar calcula digestul elementului SignedInfo, singurul lucru care lipsește pentru generarea unei semnături fiind informațiile despre chei. Aceste informații sunt obținute în cadrul ecranului următor.

Ecranul de alegere a cheii de semnare

Ultimul ecran de introducere a datelor este folosit pentru obținerea de la utilizator a informațiilor necesare pentru a determina cheia folosită pentru semnare. Utilizatorul poate decide să genereze o nouă pereche de chei, urmănd să folosească cheia privată pentru a realiza operația de semnare, sau poate să folosească o cheie salvată anterior (cel mai probabil obținută de la o autoritate de certificare) care se găsește într-un fișier pe hard-disk sau pe un token criptat.

Imaginea următoare prezintă acest frame:

Figura 24: Frame de introducere a informațiilor despre cheie

Utilizatorului îi sunt oferite două posibilități: de folosire a unei chei existente sau de generare a unei noi perechi de chei criptografice. Implicit, este selectată opțiunea de folosire a unei chei deja salvate într-un fișier.

Numele fișierului care conține cheia privată poate fi completat în textField-ul prezent pe ecran, sau poate fi folosit butonul de ‚Browse’ pentru a găsi fișierul într-o fereastră de selectare a unui fișier. Trebuie menționat că butonul de ‚Browse’ rămâne activat doar atât timp cât opțiunea utilizatorului este aceea de folosire a unei chei existente.

Dacă utilizatorul decide că este preferabil să genereze o nouă pereche de chei, acest lucru este făcut în concordanță cu algoritmul criptografic ales în primul ecran, cel de configurare.

În momentul în care utilizatorul decide să treacă la ecranul următor, aplicația dispune de toate informațiile necesare pentru a putea genera semnătura electronică. Cheia privată selectată este folosită pentru a cripta digest-ul elementului SignedInfo, este completat elementul SignatureValue și toate elementele fii sunt grupate în cadrul elementului Signature. Pe baza informațiilor despre cheie se poate construi și elementul KeyInfo, semnătura electronică putănd fi completată cu elemente din grupul proprietăților semnate sau nesemnate, cum ar fi locul unde a fost creată semnătura și timpul la care a fost generată.

Ecranul de prezentare

Ultimul ecran al aplicației de semnare va prezenta documentul XML rezultat în urma adăugării semnăturii electronice sau documentul creat pentru a cuprinde această semnătură.

Prezentarea va fi făcută într-o fereastră similară celei prezentate în figura 23, putând fi vizualizată întreaga structură arborescentă a documentului. Ecranul va mai conține un buton care să permită salvarea documentului. Încă odată trebuie făcută precizarea că aplicația lucrează cu obiecte aflate în memorie și că numai salvarea într-un fișier poate asigura păstrarea informațiilor obținute.

Salvarea va fi făcută în fișierul stabilit în cadrul primului ecaran, cel de configurare. Se presupune că utilizatorul are drepturi de scriere valabile pentru locația unde se dorește salvarea, și, bineînțeles, se presupune că locația respectivă nu este pe un mediu de stocare de tip read-only.

Concluzii

Personal, consider că realizarea acestui proiect a fost benefică pentru mine din mai multe puncte de vedere.

În primul rând, domeniu este unul foarte interesant, intrigant și de mare actualitate. Faptul că semnătura electronică își are rădăcinile în mai multe domenii (unele foarte diferite față de celelalte, mă refer aici la domeniul juridic), nu i-a împiedicat pe dezvoltatori să încerce să îmbine noțiunile, strategiile și interpretările diferite din respectivele domenii și să prezinte niște standarde clare și ușor de utilizat.

În timpului realizării acestui proiect am avut posibilitatea de a veni în contact cu literatura de specialitate, în special cu standardele apărute în acest domeniu, dar a trebuit să mă familiarizez și cu unele aspecte ale limbajului juridic, lucru pe care probabil nu l-aș fi făcut fără această motivație.

În al doilea rând, în timpul realizării proiectului a trebuit să mă ocup de toate aspectele și de toate etapele creării unui produs software, începând cu proiectarea respectivului produs, trecând prin stabilirea specificațiilor și finalizând cu scrierea codului și testarea rezultatului.

În al treilea rând, proiectul realizat deschide calea realizării aplicațiilor care să se bazeze pe API-ul implementat, bineînțeles, fără a uita din prea multă încredere, că întotdeauna există posibilitatea (și în unele cazuri chiar necesitatea) dezvoltării în continuare și îmbunătățirii funcțiilor implementate.

Bibliografie

Victor Valeriu Patriciu, Monica Ene-Pietroșanu, Ion Bica, Călin Văduva, Nicolae Voicu: “Securitatea comerțului electronic”, Editura All, București, 2001

European Telecommunications Standards Institute Tehnical Specification 101 903 v1.2.2 “XML Advanced Electronic Signatures (XAdES)” aprilie 2004, disponibil la http://uri.etsi.org/01903/v1.2.2/ts_101903v010202p.pdf

World Wide Web Consortium (W3C). “XML – Signature Syntax and Processing (XMLDSig), W3C Recommendation”, 12 februarie 2002. http://www.w3.org/TR/xmldsig-core/

Victor Valeriu Patriciu, Monica Pietroșanu, Ion Bica, Cătălin Cristea: „Securitatea informatică în UNIX și Internet”, Editura Tehnică, București, 1998

The European Parliament and the Council of the European Union. Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures, 13 decembrie, 1999, disponibil la http://europa.eu.int/smartapi/cgi/sga_doc?smartapi!celexapi!prod!CELEXnumdoc&lg=EN&numdoc=31999L0093&model=guichett

Monitorul Oficial al României, numărul 429, partea întâi, “Legea numărul 455 din 18 iulie 2001privind semnătura electronică”, 31 iulie 2001

Monitorul Oficial al României, numărul 847, partea întâi, “Hotărâre de guverg numărul 1259 din 13 decembrie 2001privind aprobarea normelor tehnice și metodologice pentru aplicarea legii nr. 455/2001 privind semnătura electronică”, 28 decembrie 2001, cu modificările și completările aduse de HG 2303 din 14 decembrie 2004, publicată în Monitorul Oficial numărul 1279 din 30 decembrie 2004

Jos Dumortier, Stefan Kelm, Hans Nilsson, Georgia Skouma, Patrick Van Eecke, Interdisciplinary centre for Law and Information Technology, Katholieke Universiteit Leuven, Belgia “Legal and market aspects of the application of Directive 199/93/EC and practical applications of electronic signatures in the Member States, the EEA, the Candidate and the Accession countries”

Internet Engineering Task Force (IETF). “Uniform Resource Identifiers (URI): Generic Syntax, Standards Track RFC 2396”, August 1998. http://www.ietf.org/rfc/rfc2396.txt.

Internet Engineering Task Force (IETF). “URN Syntax, Standards Track RFC 2141”, Mai 1997. Disponibil la http://www.ietf.org/rfc/rfc2141.txt.

Internet Engineering Task Force (IETF). “A URN Namespace of Object Identifiers, Internet informational RFC 3061”, Februarie 2000. Disponibil la http://www.ietf.org/rfc/rfc3061.txt.

World Wide Web Consortium (W3C). “Document Object Model (DOM) Level 2 Core Specification”, W3C Recommendation, Noiembrie 2000. http://www.w3.org/TR/DOM-Level-2-Core.

Internet Engineering Task Force (IETF). “Internet X.509 Public Key Infrastructure: Online Certificate Status Protocol (OCSP), Standards Track RFC 2560”, Iunie 1999. http://www.ietf.org/rfc/rfc2560.txt

World Wide Web Consortium (W3C). “XML-Signature Requirements”, W3C Working Draft, 14 Octombrie 1999. http://www.w3.org/TR/xmldsig-requirements

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: . Prezentare Generala Privind Semnaturile Digitale (ID: 148978)

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.

. Prezentare Generala Privind Semnaturile Digitale

Copyright Notice

Platforma E Learning, Open Source, Moodle

Crearea Unui Magazine Electronic Magazin Virtual

Elaborarea Unei Aplicatii Pentru Telefonia Mobila

Retele Neuronale Si Logica Fuzzy In Automatizari

Sisteme de Ecuatii Liniare.aspecte Teoretice Si Metodice

Mediul Online din Romania

Copyright Notice

Similar Posts