Sunteți pe pagina 1din 22

ACADEMIA DE STUDII ECONOMICE DIN MOLODVA FACULTATEA CIBERNETIC, STATISTIC I INFORMATIC ECONOMIC CATEDRA CIBERNETIC I INFORMATIC ECONOMIC

CARACTERISTICA PROTOCOALELOR DE SECURIZARE A TRANZACIILOR DE I-COMER


REFERAT
la disciplina Afaceri electronice Specialitatea 444.2 Management Informaional

Profesor prof. univ. Ion BOLUN

Autori: gr. MI - 121, nvmnt cu frecven la zi Andrei POGURSCHI, Mihai RACU

Chiinu 2012

CUPRINS
CUPRINS........................................................................................................................................3 LISTA ABREVIERILOR.............................................................................................................4 INTRODUCERE...........................................................................................................................5 I.PROTOCOLUL SET..................................................................................................................7 II.PROTOCOLUL SSL I S-HTTP...........................................................................................10 III.PROTOCOLUL 3D-SECURE..............................................................................................13 IV.LIMBAJUL SAML................................................................................................................16 BIBLIOGRAFIE..........................................................................................................................22

LISTA ABREVIERILOR
AAV ACS AES CAVV DES DSA IDEA MPI SAML SET SHTTP SSL UCAF SI Accountholder Authentication Value Access Control Server Advanced Encryption Standard Cardholder Authentication Verification Value Data Encryption Standard Digital Signature Algorithm International Data Encryption Algorithm Merchant plug-in Security Assertion Markup Language Secure Electronic Transaction Secure Hypertext Transfer Protocol Secure Sockets Layer Universal Cardholder Authentication Field Sistem informatic

INTRODUCERE
Comerul electronic se dezvolt tot mai rapid, n ultimii ani a crescut numrul companiilor care implementeaz sisteme informatice ce permit acest lucru. n astfel de SI securitatea este un factor foarte important care trebuie s fie luat n considerare pentru a mbunti SI: disponibilitatea serviciului - se pune problema ct de afectai vor fi utilizatorii de noul sistem de securitate, dac se incarca prea mult sistemul, perioadele critice pentru procesare i acces la resurse; integritatea datelor - se pune problema evalurii afacerilor, ca urmare a deteriorarii integritaii datelor, precum si determinarea punctelor vulnerabile din sistem; confidenialitatea datelor - se prevede ce efect ar avea ajungerea datelor la ali parteneri de afaceri, competitori, asupra grupului, organizaiei; contabilitatea - se stabilesc indatoririle securitii: cine se ocupa cu monitorizarea cderilor, atentatelor de ptrundere neautorizat in sistem, cine rspunde pentru afacerile pierdute i recuperarea pierderilor. Pentru implementarea serviciilor de securitate se identific urmtoarele mecanisme de securitate: cifrarea - furnizeaz confidenialitatea asupra datelor i asupra transmisiei datelor; algoritmii de cifrare trebuie s fie reversibili i pot fi simetrici sau asimetrici; semntura digital - consta din doua etape: semnarea datelor - implic datele i producerea unei valori rezumat (digest), ca urmare a aciunii unei funcii de dispersie (hash); informaii folosind cheia secret a semnatarului; verificarea semnturii - se realizeaz cu cheia public a emitorului i determin dac semntura este autentic i a fost aplicat datelor originale; controlul accesului - folosete identitatea entitii pentru a stabili drepturile de acces. semnarea acestei

integritatea datelor - se refer la: integritatea traficului (a irului de date) - se folosesc numere de secven, inlnuire criptografic sau marcarea timpului. integritatea unei singure uniti de date - la emisie se adaug o sum de control criptografic BCC (Block Check Code), iar la recepie se genereaz valoarea corespunztoare mesajului recepionat i se compar cu cea primit.

autentificarea schimbului - mecanismul const din utilizarea unor informaii de autentificare, parole, furnizate de emitor i verificate la recepie, a unor protocoale criptografice sau entiti hardware.

protecia traficului - are ca scop analiza traficului; informaia de protecie a traficului este protejat printr-un serviciu de confidenialitate.

I.

Protocolul SET

Secure Electronic Transaction (SET) este un protocol pentru securizarea tranzaciilor cu carduri n cadrul reelelor nesigure, n special, pe Internet dezvoltat de ctre SETco formata din companii precum VISA, MasterCard, RSA, IBM i Microsoft. SET folose te infrastructura existent a plilor prin card prin intermediul unei reele securizate. SET a fost destinat s devin metoda de facto de plat pe internet ntre comercian i, cumprtori, i companiile de carduri de credit. n ciuda publicitii grele pentru a castiga cota de piata el a euat, motivele pentru aceasta sunt: Efectul de reea - nevoie pentru a instala software-ul client (ex. e-wallet). Costul i complexitatea pentru comerciani de a oferi sprijin, n contrast cu costuri relativ reduse i simplitatea alternativ bazat pe protocolul SSL existent. Figura 1.1 indic participanii la sistemul SET, care includ urmtoarele: Cardholder: Deintorul autorizat a unui card. Comerciant: Persoan sau o organizaie care are bunuri sau servicii de a ale vinde la titularul cardului. De obicei, aceste bunuri i servicii sunt oferite prin intermediul unui site web sau prin email. Un comerciant care accept carduri de plat trebuie s aib o relaie cu un dobnditor. Emitent: Aceasta este o instituie financiar, cum ar fi o banc, care ofer cardul de plat . Dobnditorul: Aceasta este o instituie financiar care stabilete un cont cu un comerciant i proceseaz autorizrile de plat prin card i nsi tranzacia. Comercianii vor accepta, de obicei, mai mult de un brand de card de. Dobnditorul prevede autorizaia ctre comerciant c contul de card este activ i c achiziia propus nu depete limita de pe card. Gateway-ul de plat: Aceasta este o funcie operat de ctre dobnditor sau de o parte ter care proceseaz desemnat mesaje comerciale de plat.. Autoritatea de Certificare (CA): Aceasta este o entitate care emite certificate X.509v3 cu cheie public certificate pentru cardholderi, comercianti, si gateway-uri de plat.
7

Figura 1.1. SET Metoda de funcionare: 1. Clientul deschide un cont. Clientul obine un cont de card de credit, cum ar fi MasterCard sau Visa, cu o banca care accept pli electronice i SET. 2. Clientul primete un certificat. Dup verificarea corespunztoare a identitii, clientul primeste un certificat X.509v3 digital, care este semnat de ctre banc (vezi Figura0 1.2). 3. Comercianii au certificate proprii. Un comerciant care accept un anumit brand de card trebuie s fie n posesia a dou certificate pentru dou chei publice deinute de comerciant: unul pentru semnarea mesajelor i unul pentru schimbul de chei. Comerciant are nevoie, de asemenea, de o cpie a cheii publice a gatewayului de plat. 4. Clientul plaseaz o comand. Acesta este un proces care poate implica navigare primul client prin intermediul site-ul Web pentru a accesa formularul de comand. 5. Comerciantul este verificat. n plus fa de formularul de comanda, comerciantul trimite o copie a certificatului su, astfel nct clientul s poat verifica faptul c el sau ea este de-a face cu un magazin valid.

6. Comanda si plata sunt trimise. Clientul trimite att ordinul i informaiile de plat la comerciant, mpreun cu certificatul clientului. Pentru confirm achiziionarea articolelor din formularul de comanda. Plata conine detaliile cardului de credit. Informaiile de plat sunt criptate n aa fel nct s nu poat fi citit de comerciant. Certificatul clientului permite comerciantului s verifice clientului. 7. Comerciant cere autorizarea de plat. Comerciant trimite informaiile de plat la gateway de plat, solicit autorizarea pentru a stabili dac sunt dispnibile destule mijloace bneti pe card. 8. Comerciantul confirma comanda. Comerciantul trimite confirmarea comenzii la client. 9. Comerciantul furnizeaz bunuri sau servicii. Livrarea bunului sau serviciului achiziionat. 10. Comerciantul trimite cererea de plat. Aceast cerere este trimis la gateway-ul de plat, care se ocup de procesarea plilor.

Figura 1.2. Criptarea i decriptarea cu ajutorul cheilor publice i private

II.

Protocolul SSL i S-HTTP

SSL (Secure Sockets Layer) este un acronim care reprezint un protocol web dezvoltat de compania Netscape pentru a transmite fr risc documente private prin Internet. Pentru a cripta datele, SSL utilizeaz un sistem criptografic cu dou chei: una public, cunoscut de oricine, i una privat, secret, cunoscut numai de destinatarul mesajului. Majoritatea browserelor web suport SSL, i multe situri web utilizeaz protocolul de utilizator pentru a transmite informaii confideniale, cum ar fi numerele de carduri de credit. Prin convenie, URL-ul care are nevoie de o conexiune SSL ncepe cu https: (n loc de http:). Un alt protocol de transmitere a datelor n siguran pe World Wide Web este Secure HTTP (S-HTTP, vezi Figura 2.1). n timp ce SSL creeaz o conexiune securizat ntre un client i un server prin care poate fi trimis n siguran orice cantitate de date, S-HTTP este proiectat pentru a transmite mesaje individuale n siguran. SSL i S-HTTP pot fi a adar percepute mai degrab ca tehnologii complementare dect concurente. Ambele protocoale au fost aprobate ca standard de ctre Internet Engineering Task Force (IETF).

Figura 2.1. Comunicarea prin protocolul SHTTP

10

SSL implic mai multe faze intermediare: Verificarea mutual de suportare a protocolului Schimbarea cheilor prin intermediul criptrii prin metoda cu chei publice i autenficare pe baz de certificate

Trasmiterea de trafic criptat prin sistemul cheilor simetrice n timpul primei faze a protocolului serverul i clientul negociaz asupra algoritmului de

criptare ce va fi folosit. Implementrile curente permit urmtoarele posibiliti:


criptografia bazat pe chei publice: RSA, Diffie-Hellman, DSA sau Fortezza; pentru codri simetrice: RC2, RC4, IDEA, DES, Triple DES sau AES; pentru funcii de hash unidirecional: MD5 sau SHA. Protocolul SSL permite schimbul de nregistrri; fiecare nregistrare poate fi, n mod

opional, compresat, criptat i mpachetat cu un cod de autentificare al mesajului (englez: message authentication code - MAC). Fiecare nregistrare are un cmp numit content_type care specific care protocol superior este folosit. Cnd conexiunea demareaz, nivelul nregistrare ncapsuleaz un alt protocol, de tip handshake protocol, pentru care cmpul content_type are valoarea 22. Comunicarea client-server (vezi Figura 2.2): Trimite un mesaj ClientHello n care specific lista de metode de criptare care sunt suportate, metodele de compresie i cea mai actual versiune a protocolului cunoscut. De asemenea transmite o secven aleatoare de bii care va fi folosit ulterior.

11

Primete mai apoi un ServerHello, n care serverul alege parametrii conexiunii din mulimea de opiuni oferit de client mai devreme.

Cnd parametrii conexiunii sunt cunoscui, clientul i serverul schimb certificatele (n funcie de algoritmul de codare pentru chei publice ales). Aceste certificate sunt n prezent de tip X.509, dar exista de asemenea un document care specific utilizarea certificatelor bazate pe OpenPGP.

Serverul poate solicita un cerificat clientului, astfel nct conexiunea s fie mutual autentificat.

Clientul i serverul negociaz un secret comun numit "master secret", existnd aici opiunea folosirii rezultatului schimbului Diffie-Hellman, sau mai simplu prin criptarea secretului cu cheia privat i decriptarea acesteia cu cheia privata a partenerului. Toate datele legate de chei sunt derivate din acest "master secret" (i de valori generate aleator de ctre client sau de ctre server), care sunt schimbate atent prin funcia atent proiectat de "Funcii pseudoaleatore".

12

Figura 2.2. Comunicarea Client-Server

III.

Protocolul 3D-Secure

3-D Secure este un protocol bazat pe XML conceput pentru a fi un strat de securitate suplimentar pentru tranzacii online cu carduri. Acesta a fost dezvoltat de VISA cu intenia de a mbunti securitatea plilor pe Internet i a oferit clienilor ca serviciu Verified by VISA. Servicii bazate pe protocolul de asemenea, au fost adoptate de ctre MasterCard, sub numele de MasterCard SecureCode, precum i de ctre JCB International, ca J / Secure. American Express a adugat SafeKey in Marea Britanie si Singapore, la 8 noiembrie 2010.

13

Conceptul de baz al protocolului este de a lega procesul de autorizare financiar cu o autentificare on-line. Aceast autentificare se bazeaz pe un model de 3 domenii (deci 3-D n numele). Cele trei domenii sunt: Domeniul dobnditorul (comerciant i banca la care este pltit bani). Domeniul emitentul (banca care a emis cardul utilizat). Domeniul interoperabilitate (infrastructur furnizat de sistemul de carduri ce suporta protocolul 3D-Secure). Acest domeniu include reeua global internet, MPI, ACS i ali furnizori de software. ACS n protocolul 3-D Secure, ACS (Access Control Server), este pe partea emitentului (banca). n prezent, majoritatea bncilor exter ACS ctre o ter parte. Frecvent, site-ul web al cumprtorului prezinta numele de domeniu al furnizorului ACS, mai degrab dect numele de domeniu a bncilor, ns acest lucru nu este cerut de protocol. n dependen de ACS, este posibil de specificat un nume de domeniu al bancii pentru a fi utilizat de ctre ACS MPI Un MPI (Merchant plug-in) este un modul software proiectat pentru a facilita verificri 3D-Secure pentru a ajuta la prevenirea fraudelor cu carduri. MPI identifica numrul de cont i interogheaz serverele emitentului de card (Visa, MasterCard, JCB Internationa) servere de ctre a determina dac acesta este nscris ntr-un program 3D-Secure i returneaz adresa site-ul web al serverului ACS n caz c este gsit. Protocolul utilizeaz mesaje XML trimise prin conexiuni SSL pentru autentificarea clientului (aceasta asigur autenticitatea la ambele peer-uri, server i client, folosind certificate digitale). O tranzacie folosind "Verified by Visa" sau SecureCode (vezi Figura 3.1) va ini ia o redirecionare la site-ul web ce a emis cardul bancar pentru a autoriza tranzacia. Fiecare emitent poate folosi orice fel de metod de autentificare (protocolul nu acoper acest lucru), dar de obicei, este folosit o metod bazat pe parol , astfel nct realizarea unei tranzacii pe internet nseamn a folosi o parol legat de card. Protocolul Verified by Visa recomand pagina de

14

verificare a bncii s fie ncrcat ntr-o sesiune de frame inline. n acest fel, sistemele bncii poate fi considerat responsabile pentru cele mai multe probleme de securitate.. Principala diferen dintre implementarile Visa si MasterCard const n metoda pentru a genera UCAF (Universal Cardholder Authentication Field): MasterCard folosete AAV (Accountholder Authentication Value) i Visa folosete CAVV (Cardholder Authentication Verification Value).

Figura 3.1. Protocolul 3D-Secure

15

IV.

Limbajul SAML

Security Assertion Markup Language (SAML) este bazat pe standartul deschis XML, pentru schimbul de date autentificare i autorizare ntre pri, n special, ntre furnizorii de indentitate i un furnizor de servicii. SAML este un produs de securitate al OASIS Security Services Technical Committee. SAML dateaz din anul 2001, mai recent actualizare este din 2005. Cea mai importanta problema ce SAML rezolva este web browser single sign-on (SSO). SSO sunt abudente la nivelul intranet (folosind cookie-uri de exemplu), dar extinderea acestor solutii dincolo de intranet a fost problematica i a condus la proliferarea non-interoperabile tehnologii proprietare. Alta recenta abordare pentru adresarea problemei browser SSO este protocolul OpenID. Specificarile SAML defines 3 roluri: principal (tip pentru utilizatori), furnizori de identitate (IDP) si furnizorul de servicii (SP). n caz de utilizare abordata de SAML,este un felul urmator, principalul solicit un serviciu de la furnizorul de servicii. Furnizorul de servicii face o cerere s obin o afirmaie de identitate de la furnizorul de identitate. Pe baza acestei afirmaii, furnizorul de servicii poate lua o decizie de control acces - cu alte cuvinte, se poate decide dac s fac anumite servicii pentru principalul conectat. nainte de livrarea afirmaia identitate la SP, PDI poate solicita unele informaii de la principalul obligat - cum ar fi un nume de utilizator i o parol - pentru a autentifica principal. SAML specific afirmaiile ntre cele trei partide: n special, mesajele pe care afirm identitatea, care au trecut de la IDP la SP. n SAML, un furnizor de identitate poate oferi afirmaiile SAML la furnizorii de servicii. n schimb, o SP se pot baza pe ncredere i afirmaii de la PSI multe independente. SAML nu specifica cum este implementat furnizor de servicii de identitate, se poate utiliza un nume de utilizator/parol, se poate utiliza autentificarea multifactoriale, acesta poate avea o punere n aplicare multifactor autentificare. O companie care permite utilizatorilor s te autentifici cu un nume de utilizator i o parol, este un exemplu tipic al unui furnizor de
16

identitate. Oricare dintre serviciile de internet populare sociale comune, de asemenea, servicii de identitate, care n teorie ar putea fi folosite pentru a sprijini schimburile SAML. Versiuni ale SAML

SAML a fost supus uneia revizuirii minore i unul major SAML 1.0 a fost adoptat ca un standard OASIS n noiembrie 2002 SAML 1.1 a fost ratificat ca standard OASIS n septembrie 2003 SAML 2.0 a devenit un standard OASIS martie 2005

Anatomia SAML SAML definete afirmaiile i protocoale, legturi i profile bazate pe XML. Termenul SAML Core se refer la sintaxa si semantica generala de afirmaiile SAML, precum i protocolul utilizat pentru a solicita i de a transmite aceste afirmaii la o entitate sistem la altul. SAML protocol se refer la ceea ce este transmis, nu modul n care (acesta din urm este determinat de alegerea de legare). Deci, SAML Core definete "goale" afirmaiile SAML, mpreun cu cererea SAML i elemente de rspuns. Un profil SAML este o manifestare concret a unui caz de utilizare definite folosind o anumit combinaie de afirmatii, protocoale i legturi. O afirmaie SAML conine un pachet de informaii de securitate:

<saml:Assertion ...> ... </saml:Assertion>.

n linii mari, un partid bazndu-se interpreteaz o afirmaie, dup cum urmeaz: SAML afirmaiile sunt de obicei transferate de la furnizorii de identitate pentru furnizorii de servicii. Afirmaii conin afirmaii care furnizorii de servicii utilizeaz pentru a permite accesul de control al deciziilor. Trei tipuri de declaraii sunt oferite de SAML: Autentificare declaraii Atribut declaraii

17

Decizie de autorizare declaraii SAML protocoale Un protocol SAML descrie modul n care anumite elemente SAML (inclusiv afirmaiile) sunt ambalate n termen de cerere SAML si elemente de rspuns i d regulile de procesare pe care entitile SAML trebuie s urmeze atunci cnd produce sau consuma aceste elemente. Pentru cea mai mare parte, un protocol SAML este un simplu protocol de cerere-rspuns. Cel mai important tip de SAML cererii protocolului se numete o interogare. Un furnizor de servicii face o interogare direct la un furnizor de identitate de peste un canal securizat spate. Corespunztoare celor trei tipuri de situaii, exist trei tipuri de interogri SAML: Autentificarea interogare Caracteristica de interogare Decizia de autorizare interogare

Figura 4.1 SAML protocol response.

Dintre acestea, interogarea atribut este, probabil, cea mai important (i nc obiectul de cercetare de mult). Rezultatul unei interogri atribut este un rspuns SAML conine o afirmaie, care se conine o declaraie atribut. SAML 1.1 protocoale Dincolo de interogri, SAML 1.1 nu sunt alte protocoale.
18

SAML 2.0 protocoale SAML 2.0 extinde noiunea de protocol considerabil. Urmtoarele protocoale sunt descrise n detaliu n SAML Core 2.0:

Assertion Query and Request Protocol Authentication Request Protocol Artifact Resolution Protocol Name Identifier Management Protocol Single Logout Protocol Name Identifier Mapping Protocol

Cele mai multe dintre aceste protocoale sunt complet noi n SAML 2.0. Authentication Request Protocol <samlp:Response> este transmis de la furnizor de identitate la furnizorului de servicii (prin intermediul browser-ului). n SAML 2.0 fluxul ncepe la furnizorul de servicii care emite o cerere de autentificare explicit la furnizorul de identitate. Rezultat Authentication Request Protocol este o caracteristic important nou SAML 2.0. Atunci cnd un principal (sau o entitate care acioneaz n numele principalului) dorete s obin afirmaii care conin declaraiile de autentificare, un element <samlp:AuthnRequest> este transmis furnizor de identitate:
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="aaf23196-1773-2113-474a-fe114412ab72" Version="2.0" IssueInstant="2004-12-05T09:21:59" AssertionConsumerServiceIndex="0" AttributeConsumingServiceIndex="0"> <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer> <samlp:NameIDPolicy AllowCreate="true"

19

Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/> </samlp:AuthnRequest>

Legaturi SAML Un caracter obligatoriu SAML este o cartografiere a unui mesaj SAML protocol de pe formate standard de mesagerie i / sau protocoale de comunicaii. De exemplu, SAML SOAP obligatoriu specific modul n care un mesaj SAML este ncapsulat ntr-un plic SOAP, care n sine este legat la un mesaj de HTTP. SAML 2.0 Profile Web Browser CSO Profilul a fost complet refactored pentru SAML 2.0. Conceptual, SAML 1.1 Browser / artefact i browser / POST sunt cazuri speciale ale SAML Web 2.0 Browser SSO. Acesta din urm este mult mai flexibil dect omologul su SAML 1.1, datorit noului "plug-and-play" de design de legare a V2.0. Spre deosebire de versiunile anterioare, SAML 2.0 fluxurile browser ncepe cu o cerere la furnizorul de servicii. Acest lucru ofer o flexibilitate mai mare, dar SP-iniiat curge natural da natere la aa-numita problem Discovery Identitate Provider, centrul de cercetare de mult astzi. n plus fa de browser Web SSO, SAML 2.0 introduce profiluri numeroase noi:

SSO Profiles

Web Browser SSO Profile Enhanced Client or Proxy (ECP) Profile Identity Provider Discovery Profile Single Logout Profile Name Identifier Management Profile

Artifact Resolution Profile Assertion Query/Request Profile Name Identifier Mapping Profile
20

SAML Attribute Profiles

Un numr dintre aceste profiluri sunt discutate mai detaliat n subiect SAML 2.0. SAML cazuri de utilizare Primar SAML caz de utilizare este numit Web browser Single Sign-On (SSO). Un utilizator inarmat cu un agent de utilizator (de obicei, un browser web) solicit o resursa web protejat de ctre un furnizor de servicii SAML. Furnizorul de servicii, care doresc s cunoasc identitatea utilizatorului solicita o cerere de autentificare probleme de la un furnizor de identitate SAML prin agentul utilizator. Fluxul protocolul rezultat este descris n schema de mai jos.

Figura 4.2 SAML Web Browser SSO

21

BIBLIOGRAFIE

1.

BOLUN I., COSTA I., GAMECHI A., ZACON T., DELIMARSCHI B., Elaborarea tezelor de licen la specialitatea Cibernetic i informatic economic, Chiinu, ASEM, 2009.

2. 3. 4.

http://en.wikipedia.org/wiki/3-D_Secure http://en.wikipedia.org/wiki/Secure_Electronic_Transaction http://en.wikipedia.org/wiki/Transport_Layer_Security

22

S-ar putea să vă placă și