2.

IP Security

Cerinţe de securitate la nivelul IP

Aplicaţii ale IP Security

Caracteristici ale utilizării IP Security

Servicii IP Security

Arhitectura IP Security

Moduri de utilizare a IP Security

Protocolul AH: Authentication Header

Protocolul ESP: Encapsulating Security Payload

Managementul cheilor

ISAKMP: Internet Security Association and Key

Management Protocol

Protocolul IKE: Internet Key Exchange

 Cerinţe de securitate la nivelul IP

O modalitate curentă de a asigura securitatea aplicaţiilor care folosesc

stiva de protocoale TCP/IP o reprezintă dezvoltarea de mecanisme de
securitate specifice pentru diferite domenii de aplicaţie: e-mail (S/MIME,
PGP), client/server (Kerberos), accesul la Web (SSL/TSL). Există însă
anumite probleme de securitate care pot fi implementate în cadrul stivei de
protocoale TCP/IP: interzicerea legăturilor cu site-urile potenţial nesigure,
criptarea pachetelor emise şi autentificarea pachetelor primite. Prin
implementarea politicii de securitate la nivelul protocolului IP, se poate
asigura securitatea comunicaţiei şi pentru aplicaţii care nu au mecanisme
proprii de securitate.
Elementele de securitate introduse de IPSec pentru versiunea IPv4 şi
în versiunea IPv6 ale protocolului IP, sunt importante în perspectiva
securizării infrastructurii Internetului (rutare, DNS) şi pentru protejarea
comunicaţiei la nivel de aplicaţie. IPSec permite o politică de control
centralizat al accesului şi o abordare flexibilă a metodelor de protecţie a
informaţiei prin criptare, fiind compatibil cu algoritmii importanţi existenţi
şi compatibil cu noi algoritmi (de exemplu: AES - Rijndael). IEFT
recomandă aplicarea specificaţiilor IPSec în toate cazurile posibile; NIST
sprijină finalizarea specificaţiilor pentru IPSec şi implementarea IPSec ca
soluţie globală pentru problemele de securitate ale Internetului.
Implementarea soluţiilor de securitate în cadrul nivelului de reţea
implică pe lângă avantajele indicate mai sus, dezavantaje atât pentru
aplicaţiile globale, destinate infrastructurii Internetului cât şi pentru aplicaţii
destinate diferiţilor utilizatori.
Progresele recente în domeniul tehnologiilor de interconectare au
introdus noi servicii şi mecanisme de control – de exemplu: managementul
calităţii serviciului, controlul congestiei la nivelul ruterelor, care impun
accesul nodurilor intermediare ale reţelei la informaţia transportată de
pachetele IP pentru nivelele de protocol superioare; acest acces vine în
contradicţie directă cu mecanismele IPSec. Există în acest sens propuneri
pentru scheme de securizare pe mai multe niveluri pentru IPSec.

2
 In cazul utilizării IPSec pentru realizarea de reţele private virtuale,
autentificarea se face la nivelul porţilor de acces la reţelele locale sau al
gazdelor pe care este implementat IPSec; staţiile de lucru din reţelele locale
nu se pot autentifica, de asemenea aplicaţiile sau utilizatorii. Problemele
legate de autentificarea staţiilor de lucru şi a utilizatorilor impun pentru
multe aplicaţii utilizarea altor standarde de securizare, eventual suprapuse
implementării IPSec.
Implementarea IPSec nefiind obligatorie pentru IPv4, aplicaţiile
securizate prin IPSec nu sunt portabile, până la generalizarea IPv6, decât pe
maşinile pe care este implementat IPSec. Un alt dezavantaj actual pentru
IPSec în securizarea aplicaţiilor îl reprezintă faptul că majoritatea
implementărilor sunt scrise pentru sisteme de operare Windows.

Securitatea la nivelul IP cuprinde trei zone funcţionale:

- autentificarea
- confidenţialitatea
- managementul cheilor criptografice

Mecanismul de autentificare certifică transmiterea efectivă a unui

pachet de către entitatea indicată ca sursă în header-ul pachetului şi, în plus,
faptul ca pachetul nu a fost modificat în timpul tranzitului. Facilităţile de
criptare/decriptare a mesajelor în nodul sursă/destinaţie asigură
confidenţialitatea comunicaţiei, iar facilităţile privind managementul cheilor
criptografice asigură securitatea schimbului de chei.
Raportul ”Securitatea in arhitectura Internetului” (IAB-Internet
Architecture Board - 1994) a stabilit necesitatea implementării unor
mecanisme de securitate pentru Internet şi a indicat ca priorităţi pentru noile
mecanisme de securitate împiedicarea monitorizării şi controlului traficului
în reţele şi securizarea traficului utilizator-utilizator prin implementarea de
mecanisme de autentificare şi criptare. Rapoartele anuale ale CERT
(Computer Emergency Response Team) indică ca principale tipuri de atac
”IP spoofing”, atac în care intrusul creează pachete IP cu adrese IP false şi
exploatează utilizarea de către aplicaţii a adreselor IP pentru autentificare, şi
diferite forme de atacuri (”packet sniffing”) în care intrusul citeşte
informaţiile transmise. IAB a inclus autentificarea şi criptarea ca mecanisme
obligatorii pentru următoarea variantă de protocol IPv6; implementarea
facilităţilor de securitate pentru IP, cunoscută ca IP Security s-a făcut astfel

3
încât să fie compatibilă atât cu varianta actuală IPv4, cât şi cu varianta
viitoare IPv6.

Aplicaţii al IP Security

IPSec asigură posibilitatea unei comunicaţii sigure în reţele locale

(LAN), reţele de arie largă (WAN), private sau publice, şi în Internet;
exemple:
- VPN reţea virtuală privată bazată pe Internet; se evită necesitatea
realizării şi gestionării unei reţele private de arie largă.
- Acces la distanţă prin Internet; un utilizator final pe al cărui sistem
este implementat protocolul IPSec poate apela la un furnizor de
Internet (ISP) şi obţine accesul securizat la o reţea privată.
- Îmbunătăţirea securităţii aplicaţiilor care au mecanisme de securitate
incluse.

Principala caracteristică a IPSec care îi permite să asigure aceste

aplicaţii variate este faptul că întregul trafic, la nivel IP, poate utiliza
mecanismele de criptare şi/sau autentificare. Astfel toate aplicaţiile
distribuite: client/server, e-mail, transfer de fişiere, acces Web, remote
logon pot fi securizate.
Modul tipic de utilizare a IPSec în cazul unei organizaţii cu reţele
locale aflate în diferite locaţii presupune că traficul intern reţelelor locale
nu este securizat în timp ce traficul între reţelele locale utilizează IPSec
pentru asigurarea securităţii. Acest protocol este implementat în
echipamentele de reţea care conectează reţele locale la reţeaua de arie largă,
de exemplu rutere sau firewall-uri. Operaţiile de criptare/decriptare şi
autentificare executate de echipamentele cu IPSec sunt transparente pentru
staţiile de lucru şi serverele din reţelele locale. Utilizatorii individuali,
conectaţi direct la WAN, pot utiliza aceleaşi facilităţi cu condiţia
implementării IPSec pe staţia de lucru.

4
 Caracteristici ale utilizării IP Security

- Dacă IPSec este implementat într-un firewall sau un ruter, se asigură

securizarea pentru toate staţiile de lucru din reţeaua locală, fără
ca traficul local să fie afectat de mecanismele de securitate.
- IPSec implementat într-un firewall este eficient dacă tot traficul
dinspre exterior utilizează IP şi firewall-ul este singurul punct
de intrare dinspre Internet în reţeaua locală
- IPSec este sub nivelul de transport (TCP, UDP) astfel încât este
transparent pentru aplicaţii; software-ul de aplicaţie nu trebuie
modificat, indiferent dacă IPSec este implementat în
ruter/firewall sau în staţia de lucru.
- IPSec este transparent pentru utilizatorii finali; nu este necesară
cunoaşterea de către utilizatori a mecanismelor de securitate.
- IPSec poate asigura securitatea pentru utilizatori individuali care
lucrează în afara sediului unei organizaţii
- IPSec permite implementarea unei subreţele virtuale securizate
dedicată anumitor aplicaţii în cadrul unei organizaţii.

IPSec poate avea un rol vital în elaborarea unei arhitecturi de rutare

necesară interconectării reţelelor. Exemple de utilizare:
- asigurarea că un mesaj de avertizare a prezenţei unui nou ruter în
reţea provine de la un ruter autorizat.
- asigurarea că un mesaj de stabilire sau menţinere a legăturii dintre
două rutere provine de la un ruter autorizat.
- asigurarea că un mesaj redirecţionat provine de la ruterul către care
pachetul iniţial a fost trimis.
- Asigurarea că informaţia de actualizare a unui ruter este autentică.

Fără astfel de măsuri de securitate un adversar poate perturba traficul;

protocoalele de rutare trebuie rulate pe baza asociaţiilor de securitate
definite de IPSec.

Servicii IP Security

5
 Tabelul 2.1 Servicii asigurate de IPSec
AH ESP ESP
(criptare) (criptare şi autentif.)
Controlul accesului X X X
Autentificarea originii datelor X - X
Rejectarea pachetelor duplicate X X X
Confidenţialitate - X X
Confidenţialitate limitată asupra traficului - X X

IPSec permite selectarea protocoalelor de securitate şi a algoritmilor,

precum şi stabilirea cheilor criptografice necesare asigurării serviciilor de
securitate cerute la nivelul IP. Două protocoale sunt folosite pentru
asigurarea securităţii: un protocol de autentificare denumit după header-ul
protocolului, AH –Authentication Header şi un protocol pentru
criptare/autentificare denumit după formatul pachetului pentru acest
protocol ESP - Encapsulating Security Payload.

Arhitectura IP Security

Documentele care definesc arhitectura IP Security sunt complexe,

unele în faza de propuneri. In 1995 IETF a publicat primul set de propuneri
de standard pentru IPSec: RFC1825-RC1829. Implementarea acestor RFC
este obligatorie pentru IPv6 şi opţională pentru IPv4. Documentele
elaborate sau în curs de elaborare pentru IPSec se împart în următoarele
grupuri:
- Arhitectură: concepte generale, cerinţe de securitate, definiţii.
- Encapsulating Security Payload (ESP): formatul pachetului şi
probleme legate de utilizarea ESP pentru criptare şi, opţional,
pentru autentificare.
- Authentication Header (AH): formatul pachetului şi probleme legate
de autentificare.
- Algoritmi de criptare: modul de utilizare a diferiţi algoritmi de
criptare cu ESP.
- Algoritmi de autentificare: modul de utilizare a diferiţi algoritmi de
autentificare cu AH sau cu opţiunea de autentificare ESP.

6
 - Managementul cheilor: protocoalele de autentificare mutuală şi
schimb de chei.
- Domeniul de interpretare: valori care permit corelarea documentelor,
de exemplu: identificatori pentru algoritmii de autentificare şi
criptare care pot fi folosiţi, parametri operaţionali – de
exemplu: durata de viaţă a cheilor.

Asocieri de securitate
Un concept de bază, care apare în mecanismele IP pentru autentificare
şi confidenţialitate, este asocierea de securitate (SA-security association).
SA este o relaţie unidirecţională între o sursă şi o destinaţie care asigură
servicii de securitate traficului efectuat pe baza ei; pentru un schimb
securizat bidirecţional sunt necesare două asocieri de securitate. Serviciile
de securitate pot fi asigurate de o asociere de securitate fie pentru utilizarea
protocolului AH, fie a protocolului ESP, dar nu pentru ambele.
O asociere de securitate este definită în mod unic de trei parametri:
- Indexul parametrilor de securitate (SPI): un şir de biţi asignat
unei SA, cu semnificaţie locală; este inclus în header-ele AH şi
ESP pentru a permite sistemului de destinaţie să selecteze SA
pentru procesarea pachetului recepţionat.
- Adresa de destinaţie IP: nu sunt permise adrese multiple, este
adresa punctului de destinaţie final al SA, care poate fi un
sistem gazdă sau un sistem al reţelei – ruter sau firewall
- Identificatorul protocolului de securitate: indică dacă este o SA
pentru protocolul AH sau pentru protocolul ESP.

Parametrii unei SA
În orice implementare a IPSec trebuie să existe o bază de date a SA,
care defineşte parametrii asociaţi cu fiecare SA. O asociere de securitate
este în mod tipic definită de următorii parametri:
- Sequence Number Counter: un numărător de 32 de biţi pentru
generarea numărului de secvenţă utilizat în header-ul AH sau
ESP .
- Sequence Counter Overflow: un flag care indică dacă a avut loc
depăşirea numărătorului pentru numere de secvenţă şi
împiedică folosirea SA pentru transmiterea de noi pachete.
- Anti-Replay Window: permite detectarea repetării pachetelor.

7
 - AH information: algoritmi de autentificare, chei criptografice, timp
de viaţă pentru chei, parametri legaţi de utilizarea AH.
- ESP Information: Algoritmi de criptare şi autentificare, chei
criptografice, valori de iniţializare, parametri legaţi de
utilizarea ESP.
- Lifetime of this Security Association: indică timpul după care SA
trebuie înlocuită cu o nouă SA (şi un nou SPI) sau desfiinţată şi
care din aceste acţiuni trebuie să aibă loc.
- IPSec Protocol Mode: indică modul tunel sau transport.
- Path MTU-Maximum Transmission UNIT: dimensiunea maximă a
pachetului care poate fi transmis fără fragmentare.

Selectori SA
Politica de securitate prin care traficul IP este corelat cu anumite SA
(sau cu nici o SA în cazul traficului care nu este controlat de IPSec) este
implementată prin Security Policy Database (SPD). Fiecare intrare în SPD
este definită printr-un set de valori definite de câmpuri ale formatului IP şi
ale formatului protocolului de nivel superior protocolului IP, numite
selectori şi conţine o SA pentru tipul respectiv de trafic. Exemple de
selectori: adresele IP pentru sursă şi destinaţie, denumirea protocolului de
transport, a protocolului IPSec (AH/ESP), adresele porturilor sursă sau
destinaţie. Aceşti selectori sunt folosiţi pentru a filtra traficul, astfel încât
fiecare pachet să fie procesat de o SA corespunzător politicii de securitate
implementate.

Moduri de utilizare a IP Security

Protocoalele AH şi ESP permit două moduri de utilizare:

Modul transport asigură protecţie pentru protocoalele de nivel
superior IP, de exemplu pachete TCP, UDP, ICMP, care lucrează imediat
deasupra nivelului IP în stiva de protocoale; este folosit în mod tipic pentru
comunicaţie între două calculatoare gazdă.
Modul tunel asigură protecţie pentru întregul pachet IP; este utilizat
atunci când sursa şi/sau destinaţia pachetului sunt rutere securizate sau
firewall-uri.
Tabelul 2.2 Principalele caracteristici ale modurilor IPSec:

8
 Mod transport
AH Autentifică unitatea de date
IP şi, selectiv, parţi ale
header-ului IP şi extensiile
header-ului IPv6.
Mod tunel
Autentifică întregul pachet
original IP plus, selectiv,
părţi ale noului header şi
extensiile noului header IPv6.

ESP Criptează unitatea de date IP Criptează pachetul IP original

şi toate extensiile header-ului
IPv6 care urmează după
header-ul ESP.
ESP cu Criptează unitatea de date IP Criptează pachetul IP
autentificare şi toate extensiile header-ului original; autentifică pachetul
IPv6 care urmează după IP original.
header-ul ESP; autentifică
unitatea de date IP.

Protocolul Authentication Header

Header-ul AH asigură mecanismul pentru controlul integrităţii şi

autenticităţii pachetului IP. Controlul integrităţii elimină posibilitatea
modificării pachetelor în tranzit, fără ca modificările să fie detectate.
Controlul autenticităţii permite unui calculator gazdă sau unui echipament
de reţea să autentifice utilizatorii şi aplicaţiile şi să filtreze traficul
corespunzător; previne de asemenea atacurile bazate pe adrese (address
spoofing attack) şi atacurile prin repetarea pachetelor (replay attack).
Authentication Header este format din următoarele câmpuri:
- Next Header: identifică tipul header-ului imediat următor AH.
- Payload length: lungimea lui AH, în cuvinte de 32 biţi, minus 2.
- Reserved
- Security Parameters Index: identifică asocierea de securitate.
- Sequence Number: un număr utilizat pentru eliminarea
duplicatelor.

9
 - Authentication Data: conţine ICV – Integrity Check Value sau
MAC – Message Authentication Code pentru pachet.

Fig 2.1 Authentication Header pentru IPSec

Mecanismul anti-replay
La stabilirea unei noi asocieri de securitate SA, sursa iniţializează un
numărător de pachete cu valoarea zero; acesta va fi incrementat cu fiecare
pachet emis şi valoarea lui va fi scrisă în câmpul Sequence Number din
AH. La atingerea valorii 232– 1 sursa trebuie să termine SA curentă şi să
negocieze o nouă SA, cu o nouă cheie.

Fig 2.2 Fereastra de recepţie anti-replay

10
 Deoarece IP asigură un serviciu fără conexiune, IPSec recomandă ca
destinatarul să implementeze o fereastra de recepţie W cu valoarea implicită
W=64. Limita superioară a ferestrei este reprezentată de N numărul de
secvenţă cel mai mare recepţionat pentru un pachet valid, iar limita
inferioară este N – W + 1. Numărul de secvenţă al pachetelor recepţionate
este folosit astfel:
1. Dacă pachetul este nou şi numărul lui de secvenţă este în
cadrul ferestrei, se verifică ICV. Dacă pachetul este
autentificat, poziţia corespunzătoare din fereastră este
marcată.
2. Dacă pachetul este nou şi numărul de secvenţă este mai mare
decât limita superioară a ferestrei, se verifică ICV. Dacă
pachetul este autentificat, se deplasează fereastra la noul
număr de secvenţă şi poziţia corespunzătoare pachetului este
marcată.
3. Dacă pachetul are numărul de secvenţă mai mic decât limita
inferioară a ferestrei sau dacă autentificarea eşuează, pachetul
este eliminat.

ICV- Integrity Check Value

Câmpul Authentication Data din AH conţine o valuare denumită ICV;
este un cod de autentificare a mesajului -MAC- sau o versiune trunchiată a
unui cod produs cu un algoritm MAC. Implementările IPSec trebuie să fie
compatibile cu:
- HMAC-MD5-96
- HMAC-SHA-1-96

Ambele tipuri de MAC folosesc algoritmul HMAC, primul cu codul

hash MD5, al doilea cu codul hash SHA-1. În ambele cazuri valoarea
HMAC rezultată din calcul este trunchiată prin utilizarea primilor 96 biţi,
lungimea câmpului Authentication Data din AH.
MAC este calculat asupra următoarelor câmpuri:
- câmpurile din header-ul IP care nu se modifică în tranzit sau care au
la destinaţie valori cunoscute; câmpurile care se pot schimba în
tranzit şi a căror valoare la destinaţie nu poate fi prevăzută sunt
considerate de valoare zero pentru calcul, atât la sursă cât şi la
destinaţie.

11
 - header-ul AH cu excepţia câmpului Authentication Data care este
considerat de valoare zero, atât la sursă cât şi la destinaţie.
- unitatea de date a protocolului de nivel superior.

Adresele sursei şi destinaţiei sunt protejate, astfel încât se previne un

atac de tipul „address spoofing”.
Pentru protocolul AH în mod transport utilizând standardul IPv4, AH
este inserat după header-ul IP original; autentificarea acoperă întregul
pachet, cu excepţia câmpurilor variabile din header-ul IP care sunt setate
zero pentru calcularea MAC. În contextul IPv6, header-ul AH nu este
examinat sau procesat de rutere intermediare, ca urmare AH este inserat
după header-ul IP original şi extensiile lui; autentificarea acoperă întregul
pachet, cu excepţia câmpurilor variabile care sunt setate zero pentru
calcularea MAC.
Pentru protocolul AH în mod tunel, întregul pachet IP original este
autentificat şi AH este inserat între noul header şi header-ul original.
Header-ul intern va conţine adresa destinaţiei finale, iar header-ul extern
poate conţine adresa unui firewall sau a unui ruter securizat. Autentificarea
acoperă întregul pachet original; noul header, cu extensiile lui în cazul IPv6,
este autentificat pentru câmpurile fixe.

12
 Fig 2.3 Formatele AH în mod transport şi în mod tunel

Protocolul ESP

Encapsulating Security Payload asigură confidenţialitatea conţinutului

mesajelor şi, parţial, confidenţialitatea traficului. Opţional, poate asigura şi
serviciile de autentificare ale protocolului AH. Formatul unui pachet ESP
are următoarele câmpuri:
- Security Parameters Index: identifică asocierea de securitate.
- Sequence Number: număr utilizat pentru eliminarea duplicatelor.
- Payload Data: pachet al nivelului de transport (în mod transport)
sau pachet IP (în mod tunel) care este protejat prin criptare.

13
 - Padding
- Pad Length: indică numărul de octeţi ai câmpului imediat
precedent.
- Next Header: identifică tipul de date conţinute în câmpul Payload
prin indicarea primului header din acest câmp.
- Authentication Data: conţine ICV – Integrity Check Value
calculată asupra pachetului ESP minus câmpul Authentication
Data.

Fig 2.4 Formatul ESP pentru IPSec

Algoritmi de criptare şi autentificare

Câmpurile: Payload Data, Padding, Pad Length şi Next Header sunt
criptate de ESP. Specificaţiile curente pentru IPSec impun compatibilitatea
cu algoritmul DES în modul înlănţuit; documentele elaborate de IP
Security Protocol Working Group al IETF stabilesc identificatori pentru
următori algoritmi:
- Three-key triple DES
- RC5
- IDEA şi three-key triple IDEA
- CAST.

14
 La fel ca protocolul AH, protocolul ESP permite utilizarea unui MAC
cu lungimea de 96 biţi iar specificaţiile curente impun compatibilitatea cu:
- HMAC-MD5-96
- HMAC-SHA-1-96

Fig 2.5 Formatele ESP în mod transport şi în mod tunel

- Pentru protocolul ESP în mod transport utilizând standardul IPv4,

header-ul ESP este inserat după header-ul IP original şi un
trailer-ul ESP (câmpurile: Padding, Pad Length, Next Header)
este plasat după pachetul IP ; dacă se optează pentru
autentificare, câmpul ESP Authentication Data este adăugat
după trailer-ul ESP. Întregul segment al nivelului de transport
şi trailer-ul ESP sunt criptate. Autentificarea acoperă tot textul
cifrat, plus header-ul ESP.

15
 Etapele de operare în mod transport sunt următoarele:
- La sursă, blocul format din segmentul nivelului de transport plus
trailer-ul ESP sunt criptate şi textul clar este înlocuit cu textul
criptat pentru a forma pachetul IP de transmis; se adaugă şi
informaţia de autentificare, dacă s-a selectat această opţiune.
- Pachetul este rutat către destinaţie. Fiecare ruter intermediar
examinează şi procesează header-ul IP şi extensiile sale
necriptate, dar nu examinează textul criptat.
- Nodul de destinaţie examinează şi procesează header-ul IP şi
extensiile sale necriptate. Apoi, pe baza SPI – Indexul
Parametrilor de Securitate din header-ul ESP, nodul de
destinaţie decriptează restul pachetului pentru a reconstitui ca
text clar segmentul nivelului de transport.

Utilizarea modului de transport asigură confidenţialitate pentru orice

aplicaţie care utilizează acest mod, evitând necesitatea ca fiecare aplicaţie să
trateze această problemă în mod individual. Acest mod de operare este
eficient, lungimea pachetului IP mărindu-se nesemnificativ; nu împiedică
analiza traficului.
Pentru protocolul ESP în mod tunel, header-ul ESP este adăugat la
începutul pachetului original, apoi pachetul plus trailer-ul ESP sunt criptate
şi încapsulate într-un nou pachet IP; noul header va permite rutarea, dar va
limita posibilitatea de analiză a traficului.
Modul tunel este util pentru configuraţii care includ firewall-uri sau
alte tipuri de porţi securizate care protejează reţele locale. Problemele de
securitate sunt preluate de firewall, eliminându-se necesitatea implementării
facilităţilor de securitate în fiecare staţie de lucru a reţelei locale.
Etapele de operare în mod tunel, în cazul în care o staţie de lucru
exterioară unei reţele locale protejate cu firewall comunică cu o staţie din
reţea, în staţia exterioară şi în firewall fiind implementat protocolul ESP,
sunt următoarele:
- Staţia de lucru exterioară reţelei locale pregăteşte un pachet IP având
ca adresă finală staţia din reţeaua locală. Acest pachet este
procesat pentru a se obţine formatul pentru ESP în mod tunel;
adresa IP din noul header va fi adresa firewall-ului.
- Pachetul este rutat către firewall-ul de destinaţie. Fiecare ruter
intermediar examinează şi procesează header-ul IP exterior şi

16
 extensiile sale necriptate, dar nu examinează pachetul textul
criptat.
- Firewall-ul de destinaţie examinează şi procesează header-ul IP
exterior şi extensiile sale necriptate. Apoi, pe baza SPI –
Indexul Parametrilor de Securitate din header-ul ESP, nodul de
destinaţie decriptează restul pachetului pentru a reconstitui ca
text clar pachetul IP încapsulat.
- Pachetul IP reconstituit este rutat în reţeaua locală către staţia de
destinaţie.

Managementul cheilor

Managementul cheilor în cadrul IPSec se referă la stabilirea şi

distribuirea cheilor criptografice utilizate de SA - asocierile de securitate. În
mod tipic sunt necesare patru chei criptografice pentru a se asigura
comunicarea între două aplicaţii: câte o pereche pentru criptare-decriptare
pentru protocoalele AH şi ESP. Management automat al cheilor pentru
IPSec este realizat prin intermediul următoarelor protocoale:
- Oakley Key Determination Protocol, un protocolul de stabilire a
cheilor bazat pe algoritmul de schimb de chei Diffie-Hellman,
dar care asigură elemente de securitate suplimentară
- ISAKMP - Internet Security Association and Key Management
Protocol, care asigură protocolul, inclusiv formatele, pentru
negocierea atributelor de securitate. ISAKMP nu impune un
algoritm specific pentru stabilirea cheilor; Oakley este
algoritmul indicat iniţial pentru ISAKMP
- IKE (Internet Key Exchange), pentru care ultima versiune –
IKEv.2 a fost distribuită ca draft în 2003, preia elemente din
protocoalele anterioare.

Algoritmul Oakley are următoarele caracteristici importante:

- utilizează un mecanism numit cookies pentru a
contracara atacurile „clogging”
- permite celor două părţi să negocieze un grup; în
esenţă acesta specifică parametrii globali ai schimbului de chei
Diffie-Hellman
- utilizează nonces –numere folosite o singură dată -
pentru a contracara atacurile prin repetare.

17
 - autentifică entităţile din schimbul Diffie-Hellman
pentru a contracara atacurile „man-in-the-middle”.

In atacurile „clogging” intrusul copiază adresa sursei unei entităţi

legitime şi trimite o cheie publică Diffie-Hellman entităţii atacate în mod
repetat, blocând capacitatea de calcul a acestei entităţi. Schimbul de cookies
presupune ca fiecare entitate să trimită un număr pseudoaleator, numit
cookie, în mesajul iniţial, şi ca acest număr să fie confirmat de cealaltă
entitate. Această confirmare trebuie repetată în primul mesaj al schimbului
de chei Diffie-Hellman. În cazul în care entitatea care a iniţiat schimbul a
folosit o adresă falsă, aceasta pierde confirmarea; entitatea atacată poate fi
obligată doar să emită confirmări, dar se evită calcularea cheilor.
ISAKMP impune ca generarea de cookies să satisfacă trei cerinţe de
bază:
- cookie trebuie să depindă de caracteristici ale entităţilor implicate.
Aceasta împiedică un intrus să obţină un cookie utilizând o
adresă IP reală şi un port UDP şi apoi să utilizeze acest cookie
pentru cereri de la diferite adrese IP sau porturi UDP.
- nu trebuie să poată fi generate cookies care să poată fi validate de o
entitate, altele decât cele generate de entitatea respectivă.
Aceasta implică utilizarea unei informaţii secrete locale, care să
nu poată fi dedusă din cookies. Existenţa unui procedeu de
verificare a cookies elimină necesitatea memorării acestora,
făcând procedeul mai puţin vulnerabil în cazul unui atac.
- Metodele de generare a cookies trebuie să fie rapide pentru a
contracara atacurile bazate pe sabotarea resurselor de calcul.

Metoda recomandată de generare a cookies este executarea unui

algoritm hash, de exemplu MD5 asupra adreselor IP pentru sursă şi
destinaţie, porturile UDP sursă şi destinaţie şi informaţia secretă locală.
Oakley este compatibil cu grupurile clasice definite pentru schimbul
de chei Diffie-Hellman; fiecare grup include definirea a doi parametri
globali şi a identităţii algoritmului. Specificaţia Oakley indică următoarele
grupuri:
- Ridicare la putere modulo un număr de 768 biţi
q = 2768 - 2704 - 1 + 264 x (2683 x  + 149686 )
a=2
- Ridicare la putere modulo un număr de 1024 biţi

18
 q = 21024 – 2960 - 1 + 264 x (2894 x  + 129093 )
a=2
- Ridicare la putere modulo un număr de 1024 biţi
parametri nedeterminaţi

Oakley utilizează nonces - numere folosite o singură dată - pentru a

contracara atacurile prin repetare; fiecare nonce este un număr
pseudoaleator generat local.
Metodele de autentificare care pot fi folosite sunt:
- Semnături digitale: schimbul de mesaje este autentificat prin
semnarea unui hash care poate fi calculat de ambele părţi
asupra unor parametri importanţi, de exemplu ID-ul
utilizatorilor şi nonces, şi este criptat cu cheia privată a fiecărei
părţi.
- Criptare asimetrică: se criptează cu cheia privată a fiecărei părţi ID-
ul utilizatorilor şi nounces.
- Criptarea simetrică: se utilizează pentru criptarea schimbului de
mesaje o cheie secretă partajată printr-o procedură externă
metodei Oakley.

Specificaţia pentru Oakley include mai multe exemple de schimburi

permise cu acest protocol. Exemplul de mai jos indică schimbul de mesaje
numit agresiv, care realizează transmiterea cheii prin doar trei mesaje.

I >> R: CKYI , OK_KEYX, GRP, gx, EHAO, NIDP, IDI, IDR, NI, SI
cu SI = SKI[ IDI  IDR  NI  GRP  gx  EHAO ]

R >> I: CKYR, CKYI , OK_KEYX, GRP, gy, EHAS, NIDP, IDR, IDI, NR,
NI,SR
cu SR = SKR[ IDR  IDI  NR  NI  GRP  gy  gx  EHAS ]

I >> R: CKYI, CKYR , OK_KEYX, GRP, gx, EHAS, NIDP, IDI, IDR, NI,
NR,SI
cu SR = SKI[ IDI  IDR  NI  NR  GRP  gx  gy  EHAS ]

Notaţii:

19
 I = entitate care iniţiază schimbul de chei
R = entitatea care răspunde
CKYI, CKYR = cookies pentru I/R
OK_KEYX = mesaj de tip schimb de chei
GRP = numele grupului Diffie-Hellman utilizat pt. acest
schimb
gx, gy = cheia publică pentru I/R; gxy cheia de sesiune
EHAO, EHAS = funcţii de criptare, hash, autentificare
oferite/selectate
NIDP = nu se foloseşte criptarea pentru restul mesajului
IDI, IDR = identificatorul pentru I/R
NI, NR = nonces generate de I/R
SKI [X], SKR[ X] = indică semnătura pentru X cu cheia privata pentru
I/R

Schimbul de chei Oakley agresiv

In prima etapă, entitatea iniţiatoare I transmite către entitatea care

trebuie să răspundă R un cookie, grupul de parametri care trebuie folosit şi
cheia sa publică Diffie-Hellman; indică de asemenea oferta de algoritmi de
criptare cu cheie publică, algoritmi hash şi algoritmi de autentificare pentru
utilizare în această sesiune, identificatorul pentru I şi pentru R, un nonce
pentru I. Mesajul se încheie cu semnătura generată cu cheia privată a lui I
asupra următorilor parametri: identificatori, nonce, numele grupului, cheia
publică Diffie-Hellman pentru I, şi numele algoritmilor oferiţi.
In a doua etapă, după primirea mesajului de către R, acesta verifică
semnătura utilizând cheia publică a lui I. R confirmă mesajul prin
retransmiterea către I a următorilor parametri generaţi de I: cookie,
identificator, nonce, grup; R include in mesaj un cookie, cheia sa publică
Diffie-Hellman, algoritmii selectaţi din oferta lui I şi un nonce propriu.
Mesajul se încheie cu semnătura generată cu cheia privată a lui R asupra
următorilor parametri: cei doi identificatori, cele două nonce, numele
grupului, cele două chei publice Diffie-Hellman, numele algoritmilor
selectaţi.
A treia etapă constă în primirea mesajului de către I şi emiterea unui
mesaj de confirmare către R a primirii cheii acestuia. I verifică semnătura
lui R utilizând cheia publică a acestuia; valorile nonces din mesaj îl asigură

20
pe I că mesajul primit este răspunsul la mesajul său şi nu este o copie a unui
mesaj mai vechi.

ISAKMP (Internet Security Association and Key

Management Protocol)

ISAKMP defineşte formatele pachetelor utilizate pentru stabilirea,

negocierea, modificarea şi ştergerea asocierilor de securitate; aceste formate
asigură o structură coerentă, independentă de protocolul de schimb de chei,
de algoritmul de autentificare sau de cel de criptare.
Un mesaj ISAKMP este format dintr-un header urmat de una sau mai
multe unităţi de date utile – payload. Mesajul este destinat transmiterii de
către un protocol de transport; specificaţiile pentru ISAKMP impun
compatibilitatea cu protocolul de transport UDP.
Header-ului ISAKMP este format din următoarele câmpuri:
- Initiator Cookie: cookie pentru entitatea care iniţiază SA
- Responder Cookie: cookie pentru entitatea care răspunde; câmp nul
în primul mesaj al entităţii iniţiatoare
- Next Payload: indică tipul primei payload
- Major Version
- Minor Version
- Exchange Type: indică tipul schimbului de mesaje
- Flags: indică setul de opţiuni pentru schimbul de mesaje în curs; sunt
definiţi doi biţi: unul indică criptarea datelor utile care urmează
cu algoritmul utilizat de SA, al doilea este folosit pentru a nu se
recepţiona date criptate înainte de stabilirea completă a SA.
- Message ID: un identificator unic al mesajului
- Length: Lungimea mesajul: header şi payloads, în octeţi.

21
 Fig 2.6 Formatele ISAKMP
Toate unităţile de date utile încep cu acelaşi header generic prezentat
în figura de mai jos . Câmpul Next Payload are valoarea 0, dacă este ultima
payload din mesaj, altfel indică tipul următoarei payload.

Tabelul 2.3 Tipuri de payload ISAKMP

Tip Descriere
SA Security Utilizat pentru a iniţia stabilirea unei SA; indică ca domeniu de
Association securitate IPSec
P Proposal Utilizat în timpul negocierii SA; indică protocolul care va fi
utilizat pentru SA: AH/ESP
T Transform Utilizat pentru a indica transformarea criptografică utilizată de
protocol: de exemplu DES pt. ESP, HMAC-SHA-1-96 pt. AH şi
atributele asociate
KE Key Exchange Utilizat pentru a indica protocolul de schimb de chei: Oakley,
Diffie-Hellman şi datele necesare generării cheilor criptografice
ID Identification Utilizat pentru informaţie de identificare a entităţilor

22
 Tip Descriere
CERT Certificate Utilizat pentru a transmite certificate şi informaţii legate de
acestea
CR Certificate Request Utilizat pentru a cere certificate; indică tipul de certificate cerute
şi autorităţile de certificare acceptate
HASH Hash Conţine date generate de o funcţie hash
SIG Signature Conţine date generate de un algoritm de semnătură digitală
NONCE Nonce Conţine o valoare nonce
N Notification Utilizat pentru a transmite notificări, de exemplu, o condiţie de
eroare
D Delete Indică invalidarea unei asocieri de securitate

Tipurile indicate de câmpul Exchange Type depind de protocolul de

schimb care foloseşte formatul; pentru protocolul IKE, acest tipuri sunt
menţionate în continuare.

IKE (Internet Key Exchange)

IKE este protocolul care execută autentificări mutuale, stabileşte

asocierile de securitate SA pentru IPSec şi gestionează toate SA de pe o
anumită gazdă. Acest protocol utilizează formatele definite de ISAKMP
(Internet Security Association and Key Management Protocol) şi elemente
din metoda de schimb a cheilor OAKLEY. Protocolului IKE este
independent de metoda particulară de criptare care este utilizată pentru
autentificarea sau confidenţialitatea datelor. Varianta actuală a protocolului
este IKEv.2.
Protocolul IKEv.2 presupune un schimb de mesaje iniţial între două
părţi pentru negocierea algoritmilor criptografici, autentificarea mutuală şi
stabilirea unei chei de sesiune; se creează astfel o asociere de securitate
IKE-SA şi o primă asociere de securitate IPSec-SA.
Toate mesajele IKEv2 sunt perechi cerere/răspuns; în cazul în care
răspunsul nu este primit într-un interval dat, partea care a transmis cererea
va efectua o retransmisie.

Moduri de operare IKE

Modul principal creează un canal securizat cu o gazdă situată la
distanţă, care va fi folosit pentru negocierile următoare. Pentru a crea o
conexiune sigură, nodul care iniţiază conexiunea trimite o listă de parametri
pe care îi propune pentru asociere, incluzând algoritmul de criptare şi
hashing, o metodă de autentificare, opţiunea asupra utilizării protocolului

23
AH sau a protocolul ESP şi alte date necesare. Cele două părţi se autentifică
reciproc folosind metoda cheilor publice; sunt utilizate certificate digitale.
Modul agresiv operează cu mai puţine schimburi de mesaje,
transferând mai multe informaţii în cadrul aceluiaşi schimb. Autentificarea
este mai puţin riguroasă ca în modul principal.
Cele două moduri menţionate au ca rezultat o asociere de securitate
care va fi folosită de protocolul IKE. După realizarea acestei asocieri,
protocolul IKE poate fi utilizat pentru a configura asocierea de securitate
curentă pentru un canal de comunicaţii securizat.
Modul rapid este utilizat pentru negocierea asocierilor de securitate
pentru IPSec. Deoarece între părţi a fost stabilit deja un canal sigur de
comunicaţii în timpul configurării iniţiale, modul rapid poate utiliza pachete
criptate. Rezultatul schimbului de mesaje utilizând modul rapid este
stabilirea a două asocieri de securitate, câte una pentru fiecare direcţie, între
gazdele care negociază canalul. Partea de la capătul de destinaţie al fiecărei
asocieri de securitate unidirecţionale alege un nonce care va fi folosit pentru
indexul asocierii de securitate - SPI şi îl comunică celeilalte părţi.

24
 3. SNMP

Securitatea informaţiei în protocolul SNMP

Concepte de bază

Arhitectura SNMP

Procesarea mesajelor şi modelul de securitate

Controlul accesului la MIB

25
 Securitatea informaţiei în protocolul SNMP

Acest capitol evidenţiază cadrul de ansamblu definit pentru

management prin SNMP şi studiază principalele facilităţi de securitate
definite în SNMPv3: autentificarea, confidenţialitatea şi controlul accesului.
SNMP - Simple Network Management Protocol este cel mai utilizat
protocol pentru managementul reţelelor bazate pe TCP/IP. Deşi
funcţionalitatea SNMPv1 s-a îmbunătăţit prin elaborarea SNMPv2, primele
două versiuni ale acestui protocol nu dispun de implementările de securitate,
în special în domeniul autentificării şi confidenţialităţii, necesare pentru a
putea folosi integral facilităţile SNMP. Setul de RFC-uri cunoscut sub
numele de SNMPv3 corectează această deficienţă.
SNMP defineşte nu numai un protocol pentru schimbul de informaţii
de management, dar şi formatul pentru reprezentarea acestor informaţii şi
modul de organizare a sistemelor distribuite în staţii de management şi
agenţi supuşi managementului. În plus, sunt definite, ca parte a SNMP,
structuri de baze de date, numite Management Information Bases (MIB);
aceste MIB specifică obiectele administrate pentru cele mai uzuale aspecte
ale managementului reţelelor, incluzând: punţi, rutere, reţele locale.
Deficienţele SNMPv1, constatate odată cu rapida răspândire a acestui
protocol, se încadrează în două categorii: deficienţe funcţionale şi deficienţe
care privesc securitatea. Multe din deficienţele funcţionale au fost rezolvate
de versiunea SNMPv2, publicată pentru prima dată în 1993 ca set RFC.
Facilităţile privind securitatea existente în această variantă nu au fost
acceptate, astfel încât au fost eliminate din varianta revizuită SNMPv2c din
1996. Această variantă utilizează autentificarea pe bază de parolă, existentă
şi în SNMPv1. În 1998 au fost propuse RFC 2271-2275 (TABELA 3. 1) de
către grupul de lucru IETF pentru SNMPv3. Aceste documente definesc un
cadru pentru includerea mecanismelor de securitate într-un ansamblu bazat
pe mecanismele funcţionale definite de SNMPv1 sau SNMP3. În plus,
documentele definesc un set specific de mecanisme pentru securitatea
reţelelor şi controlul accesului.

Număr Titlu
RFC 2271 An Architecture for Describing SNMP
Management Frameworks

26
 Număr Titlu
RFC 2272 Message Processing and Dispatching for SNMP
RFC 2273 SNMPv3 Applications
RFC 2274 User-Based Security Model for SNMPv3
RFC 2275 View-Based Access Control Model (VACM) for
SNMP

Tabela 3.1

Figura 3.1 descrie relaţia dintre diferitele versiuni ale SNMP cu

ajutorul formatelor utilizate. Informaţia este schimbată între o staţie de
management şi un agent în forma unui mesaj SNMP. Procesele legate de
securitate au loc la nivelul mesajului: de exemplu, SNMPv3 specifică un
model de securitate utilizator - User Security Model (USM) care utilizează
câmpuri din header-ul mesajului. Câmpul de date (payload) al unui mesaj
SNMP este o unitate de date de protocol (PDU) SNMPv1 sau SNMPv2. O
unitate PDU indică un tip de acţiune de management (de exemplu get/set
pentru un obiect administrat) sau o listă de nume de variabile legate de
această acţiune.

Fig 3.1 – Arhitectura SNMP

RFC 2271 – 2275 elaborate de grupul de lucru pentru SNMPv3

descriu o arhitectură globală, structuri specifice pentru mesaje şi

27
implementări ale mecanismelor de securitate, dar nu definesc un nou format
pentru SNMP PDU. Formatele existente, SNMPv1 PDU sau SNMPv2 PDU
sunt folosite în noua arhitectură. O implementare denumită SNMPv3 constă
în mecanismele de securitate şi caracteristici arhitecturale definite de
SNMPv3 şi formatele şi funcţiile PDU definite de documentele SNMPv2.

Concepte de bază

Ideea de bază a organizării managementului unei reţele este existenţa

în configuraţia de reţea a două tipuri de sisteme: agenţi şi manageri. Orice
nod al reţelei care trebuie gestionat – calculatoare personale, staţii de lucru,
servere, punţi, rutere, include un modul agent. Agentul îndeplineşte
următoarele funcţii:
 Colectarea şi actualizarea informaţiei locale de stare
 Furnizarea acestei informaţii către un manager, fie ca
răspuns la o cerere, fie fără a fi solicitată, atunci când au
loc evenimente importante în reţea
 Executarea comenzilor manager-ului pentru
modificarea configuraţiei sau parametrilor de operare
locali.
O configuraţie de reţea include în mod obligatoriu una sau mai multe
staţii de administrare sau manageri. Staţia manager asigură de regulă o
interfaţă de utilizator astfel ca un operator uman să poată observa şi
controla procesul de management al reţelei. Această interfaţă permite
utilizatorului să dea comenzi şi include logica necesară pentru procesarea
informaţiei colectate de sistem.
În centrul sistemului de management al reţelei se află un set de
aplicaţii care îndeplinesc cerinţele pentru administrarea reţelei. În varianta
minimă un sistem va include aplicaţii elementare pentru a realiza
monitorizarea performanţelor, controlul configurării şi facturarea serviciilor.
Sistemele mai dezvoltate pot include aplicaţii mai elaborate din categoriile
de mai sus, facilităţi pentru detectarea şi corectarea erorilor, facilităţi pentru
gestionarea mecanismelor de securitate ale reţelei. Toate aplicaţiile pentru
managementul reţelei utilizează de regulă un acelaşi protocol de
management . Acest protocol asigură funcţiile fundamentale pentru a obţine

28
informaţiile de management de la agenţi şi pentru a transmite comenzi către
agenţi. Protocolul de management utilizează la rândul lui protocoalele de
comunicaţie aflate pe nivelurile inferioare, de exemplu TCP/IP.
Fiecare agent asigură o bază de date cu informaţii de management –
MIB, care conţine informaţii asupra configuraţiei locale şi a traficului;
aceste informaţii descriu atât starea curentă, cât şi succesiunea stărilor
anterioare. Fiecare staţie manager vor asigura un MIB global, care
centralizează informaţiile de la agenţi.
Specificaţiile SNMPv1 şi SNMPv2 sunt formate dintr-un set de
documente care definesc un protocol de management al reţelelor, o structură
generală pentru MIB, un număr de structuri de date MIB specifice anumitor
scopuri de management. Specificaţiile includ aplicaţii minimale de
management; nu sunt incluse facilităţi pentru interfaţa cu utilizatorul, astfel
încât este necesară implementarea unei aplicaţii de management care să
ruleze deasupra protocolului SNMP.
SNMP este conceput pentru a fi implementat cu un consum minim de
resurse de procesor şi de reţea; permite asigurarea unei structuri pentru
facilităţile de management. În esenţă, protocolul asigură patru funcţii:
 Get: utilizat de un manager pentru a obţine o
înregistrare din MIB-ul unui agent
 Set: utilizat de un manager pentru a modifica o valoare
în MIB-ul unui agent
 Trap: utilizat de un agent pentru a trimite un mesaj de
alarmă unui manager
 Inform: utilizat de un manager pentru a trimite un
mesaj de alarmă unui alt manager.

Specificitatea şi eficienţa SNMP este asigurată de setul de structuri

MIB definite; MIB-ul unui agent stabileşte ce informaţii colectează şi
stochează agentul. De exemplu, există un număr de variabile în MIB – urile
standardizate care se referă la operaţiile efectuate de protocoalele de nivel
inferior TCP şi IP, incluzând numărul de pachete trimise şi recepţionate,
pachete eronate etc. Deoarece toţi agenţii asigură acelaşi set de variabile,
aplicaţiile scrise pentru staţiile manager pot folosi uşor aceste informaţii.

Arhitectura SNMP

29
 Arhitectura SNMP, aşa cum este descrisă de RFC 2271, constă dintr-o
mulţime de entităţi SNMP distribuite, care interacţionează. Fiecare entitate
implementează o parte din posibilităţile SNMP şi poate acţiona ca un nod
agent, nod manager sau o combinaţie a celor două tipuri de noduri de reţea.
Fiecare entitate SNMP este formată dintr-o mulţime de module care
interacţionează unele cu altele pentru a asigura servicii. Aceste interacţiuni
pot fi modelate printr-un set abstract de primitive şi parametri.
RFC 2271 impune proiectarea unei arhitecturi modulare care să
îndeplinească următoarele cerinţe:
 Să permită implementarea într-o gamă largă de
condiţii de operare, de la condiţii cu necesităţi
funcţionale minimale până la condiţii care să impună
implementarea unor facilităţi adiţionale, necesare
managementului reţelelor mari.
 Să permită dezvoltarea unor componente ale arhitecturii
din cadrul standardului, chiar dacă nu există consens
asupra tuturor componentelor.
 Să permită utilizarea unor modele de securitate
alternativă.

Fiecare entitate SNMP include o singură maşină SNMP; o maşină

SNMP implementează funcţii pentru transmiterea şi recepţionarea
mesajelor, pentru autentificarea şi criptarea/decriptarea mesajelor şi pentru
controlul accesului la obiectele administrate. Aceste funcţii sunt furnizate ca
servicii către una sau mai multe aplicaţii, care au în configuraţie maşina
SNMP respectivă . Atât maşina SNMP, cât şi aplicaţia pentru care lucrează,
sunt definite ca o mulţime de module. Această arhitectură asigură
următoarele avantaje:
 Rolul unei entităţi SNMP este determinat de modulele
implementate în această entitate. De exemplu, un anume
set de module este necesar pentru un agent SNMP şi un
alt set este necesar pentru un manager SNMP, dar cele
două seturi pot avea module comune.
 Structura modulară a specificaţiei face posibilă definirea
a diferite versiuni pentru fiecare modul. Se permit astfel:
o Definirea unor variante diferite sau îmbunătăţite
pentru SNMP fără a fi necesară o nouă versiune

30
 o Specificarea clară a strategiilor de coexistenţă şi
tranziţie.

In continuare va fi prezentată utilizarea modulelor pentru agenţi şi

pentru manageri SNMP tradiţionali; termenul tradiţional este folosit în
specificaţii pentru a sublinia faptul că în practică o implementare
(netradiţională) poate realiza şi funcţii de agent şi funcţii de manager.

 Managerul SNMP tradiţional este prezentat în figura

3.2, realizată pe baza RFC 2271. Managerul
interacţionează cu agentul prin emiterea comenzilor (get
şi set) şi prin recepţionarea de mesaje trap; managerul
mai poate interacţiona cu alţi manageri prin emiterea de
Inform Request PDU, care indică alarmă, şi prin
recepţionarea de Inform Response PDU, care confirmă
Inform Request PDU. In terminologia SNMP, un
manager SNMP tradiţional include trei categorii de
aplicaţii:
 Generator de comenzi: monitorizează şi manipulează
date privind managementul pentru agenţi
 Generator de notificări: iniţiază mesaje asincrone -
Inform Request PDU
 Receptor de notificări: - Inform Request PDU şi
SNMP v2-Trap PDU; în cazul recepţionării Inform
Request PDU, emite Inform Response PDU.

31
Fig 3.2- Manager SNMP tradiţional

32
 Toate tipurile de aplicaţii descrise utilizează serviciile asigurate de
maşina SNMP pentru această entitate:
 Acceptarea PDU generate de aplicaţiile SNMP,
procesarea acestora – inclusiv inserarea codurilor de
autentificare şi criptare, încapsularea acestora în mesaje
pentru transmisie.
 Acceptarea mesajelor SNMP de la nivelul de transport,
procesarea acestora – inclusiv autentificarea şi
decriptarea, extragerea PDU din mesaje şi pasarea
acestora aplicaţiilor SNMP corespunzătoare.

Maşina SNMP este formată din: dispecer, subsistem de procesare a

mesajelor, subsistem de securitate.
Dispecerul este un manager de trafic. Pentru PDU generate de
aplicaţii, dispecerul determină tipul de procesare necesar (SNMPv1,
SNMPv2, SNMPv3) şi pasează PDU modulului adecvat din subsistemul de
procesare a mesajelor. Acesta returnează PDU după ataşarea header-ului
adecvat, apoi dispecerul pasează mesajul nivelului de transport. Pentru
mesajele primite de la nivelul de transport, dispecerul asigură pasarea către
modulul de procesare adecvat, care returnează PDU din mesaj; apoi PDU
este dirijat către modulul de aplicaţie de destinaţie.
Subsistemul pentru procesarea mesajelor asigură pentru mesajele
care provin de la aplicaţii împachetarea acestora cu header-ul corespunzător,
iar pentru mesajele care provin de la nivelul de transport, extragerea PDU
conţinut de aceste mesaje. O implementare a acestui subsistem poate
conţine un singur modul, corespunzător unei singure versiuni SNMP sau
mai multe module, pentru compatibilitate cu mai multe versiuni.
Subsistemul de securitate asigură funcţii de autentificare şi
criptare/decriptare. Fiecare mesaj care urmează să fie transmis este pasat
subsistemului de securitate de către subsistemul de procesare a mesajelor. În
funcţie de serviciile cerute, subsistemul de securitate poate cripta PDU
inclus în mesaj şi eventual anumite câmpuri ale header-ului; mai poate fi
generat un cod de autentificare care este inserat în header-ul mesajului.
Mesajul procesat astfel este apoi returnat subsistemului de procesare a
mesajelor. Similar, fiecare mesaj recepţionat este pasat subsistemului de
securitate de către subsistemul de procesare a mesajelor. Dacă este necesar,
este testat codul de autentificare al mesajului, apoi mesajul este decriptat.
Mesajul astfel procesat este returnat subsistemului de procesare a mesajelor.

33
O implementare a subsistemului de securitate poate include mai multe
modele de securitate . RFC 2274 defineşte modelul USM – User-Based
Security Model.

34
35
 Fig. 3.3 –Agent SNMP tradiţional

Agentul SNMP tradiţional este prezentat în figura 3.3 – realizată pe

baza RFC 2271. Acest agent poate conţine trei tipuri de aplicaţii:
 Generator de răspunsuri la comenzi: asigură accesul la
managementul datelor. Aceste aplicaţii răspund la
recepţionarea unei cereri prin emiterea unui Response
PDU
 Generator de notificări: iniţiază mesaje asincrone;
pentru această aplicaţie sunt utilizate SNMPv2 – Trap
sau SNMPv3 – Trap

36
  Aplicaţie Proxy Forwarder; retransmite mesaje între
entităţi.

Maşina SNMP pentru un agent tradiţional are toate componentele

maşini SNMP pentru un manager tradiţional, plus un subsistem de control
al accesului. Acest subsistem asigură servicii pentru controlul accesului la
MIB pentru citirea şi setarea stărilor obiectelor administrate. Aceste servicii
sunt executate pe baza conţinutului PDU. O implementare a subsistemului
de control al accesului poate include mai multe modele. RFC 2275 defineşte
modelul VACM – View-Based Access Control Model.
Funcţiile legate de securitate sunt organizate în două subsisteme
separate: securitate şi control al accesului. Este un foarte bun exemplu de
proiectate modulară, deoarece cele două subsisteme execută funcţii net
diferite, deci are sens să se permită standardizarea independentă a acestora.
Subsistemul de securitate procesează mesajele şi asigură autentificarea şi
confidenţialitatea, subsistemul de control al accesului procesează PDU din
mesaje şi asigură controlul accesului la informaţia de management.

Terminologia introdusă de RFC 2271 este definită pe scurt în Tabela

3.2. Asociat cu fiecare entitate SNMP, este definit un identificator unic,
snmpEngineID. Pentru controlul accesului, fiecare entitate SNMP
administrează mai multe contexte ale informaţiei de management, fiecare
având un contextName, unic în cadrul entităţii. Pentru a evidenţia existenţa
unui singur manager al contextelor în fiecare entitate, fiecare entitate este
asociată cu un contextEngineID; acesta este identic ca valoare cu
snmpEngineID. Controlul accesului este determinat de contextul specific
în care se face accesul şi de identitatea utilizatorului care solicită accesul.
Identitatea utilizatorului va fi apoi exprimată ca principal, acesta putând fi
un utilizator individual, o aplicaţie sau un grup de aplicaţii.

Alţi termeni din tabel se referă la procesarea mesajelor. Formatul şi

versiunea SNMP a mesajului sunt determinate de
snmpMessageProcessingModel. Modelul de securitate este determinat de
snmpSecurityModel, iar snmpSecurityLayer determină care servicii de
securitate sunt cerute pentru o anumită operaţie; utilizatorul poate cere
autentificare, autentificare şi criptare sau poate să nu solicite servicii de
securitate.

37
SnmpEngineID Identificator unic al unei maşini
SNMP şi al entităţii SNMP care
corespunde acestei maşini

ContextEngineID Identifică în mod unic o entitate

SNMP care realizează un context cu
un contextName dat.
ContextName Identifică un context dat în cadrul
unei maşini SNMP; este pasat ca
parametru către dispecer şi
subsistemul de control al accesului.
ScopedPDU Un bloc de date format din:
contextEngineID, contextName şi
SNMP PDU; este pasat ca parametru
spre/de către subsistemul de
securitate.
snmpMessageProcessingModel Identificator unic al modelului
pentru subsistemul de procesare a
mesajelor; valorile posibile includ
SNMPv1, SNMPv2, SNMPv3.
SnmpSecurityModel Identificator unic al modelului
pentru subsistemul de securitate;
valorile posibile includ SNMPv1,
SNMPv2c i USM.
SnmpSecurityLevel Nivelul de securitate la care
mesajele SNMP pot fi transmise sau
la care operaţiile sunt procesate;
indică dacă autentificarea şi/sau
confidenţialitatea sunt necesare.
Valorile posibile sunt:
noAuthnoPriv, authNoPriv, authPriv
Principal Entitatea pentru care sunt furnizate
servicii sau pentru care se face
procesarea.
SecurityName Un şir de caractere care reprezintă
un principal şi poate fi citit de un
operator uman; este pasat ca

38
 parametru în toate primitivele
SNMP (Dispacher, Message
Processing, Security, Access
Control)
Tabela 3.2. Terminologia SNMPv3.

Aplicaţiile SNMPv3 sunt de mai multe tipuri:

 Generator de comenzi
 Generator de răspunsuri la comenzi
 Generator de notificări
 Receptor de notificări
 Proxy forwarder

Serviciile dintre modulele unei entităţi SNMP sunt definite cu ajutorul

primitivelor şi al parametrilor. O primitivă specifică funcţia de executat, iar
parametrii sunt utilizaţi pentru a asigura pasarea datelor şi a informaţiilor de
control; în acest sens, primitivele şi parametrii reprezintă modul de definire
formală a serviciilor SNMP. Modul efectiv de realizare a primitivei depinde
de implementare.
Figura 3.4, realizată pe baza RC2271 permite evidenţierea modului în
care lucrează primitivele. Figura 3.4a arată secvenţa de evenimente prin
care, într-un manager SNMP, o aplicaţie de tipul generator de comenzi sau
emiţător de notificări cere emiterea unui PDU şi apoi primeşte răspunsul
corespunzător. Figura 3.4b prezintă aceeaşi secvenţă în cadrul unui agent
SNMP; se arată cum un mesaj primit se transformă într-un PDU adresat
unei aplicaţii şi cum răspunsul aplicaţiei este transformat în mesaj. Săgeţile
care reprezintă apeluri (call) sunt etichetate cu numele primitivei, săgeţile
neetichetate reprezintă răspunsul (return) pentru un apel, iar liniile punctate
- corespondenţa între apeluri şi răspunsuri.
RFC 2273 defineşte procedurile care trebuie respectate de fiecare tip
de aplicaţii atunci când generează PDU pentru transmisie sau când
procesează PDU primite. În toate cazurile procedurile sunt definite prin
interacţiunea cu dispecerul, prin primitivele acestuia.

Aplicaţiile de tip generator de comenzi utilizează următoarele

primitive dispecer:

39
  sendPdu
 processResponsePdu

Procedura sendPdu furnizează către dispecer PDU care trebuie

transmis şi informaţia asupra destinaţiei şi parametrilor de securitate.
Dispecerul invocă pentru pregătirea mesajului subsistemul pentru
procesarea mesajelor, care invocă, la rândul lui, subsistemul de securitate.

Fig. 3.4 – Flux SNMPv3

Dispecerul pasează mesajul astfel pregătit către nivelul de transport
(de ex. protocolul UDP) pentru transmisie. Dacă mesajul nu poate fi

40
pregătit, dispecerul returnează o indicaţie de eroare; în caz de succes,
dispecerul alocă un identificator sendPduHandle pentru PDU din mesaj şi
returnează această valoare către generatorul de comenzi. Generatorul de
comenzi memorează valoarea, astfel încât să poată stabili corespondenţa
dintre cererea iniţială şi răspunsul aferent.
Dispecerul livrează fiecare PDU primit ca răspuns către aplicaţia
generator de comenzi corespunzătoare, folosind primitiva
processResponsePdu.

Aplicaţiile de tip generator de răspunsuri la comenzi utilizează

patru primitive dispecer:
 registerContextEngineID
 unregisterContextEngineID
 processPdu
 returnResponsePdu

şi o singură primitivă a subsistemului de control al accesului:

 isAccessAllowed.

Primitiva registerContextEngineID validează asocierea unei aplicaţii

de tipul generator de răspunsuri la comenzi, cu o maşină SNMP pentru a
procesa anumite tipuri de PDU în cadrul unui context. Odată stabilită o
asociere, toate mesajele primite, care conţin combinaţia contextEngineID –
pduType înregistrată pentru o anumită aplicaţie, sunt trimise către aplicaţia
respectivă. O aplicaţie de tip generator de răspunsuri la comenzi poate fi
disociată de o maşină SNMP, folosind primitiva
unregisterContextEngineID.
Dispecerul livrează fiecare request PDU primit către aplicaţia
generator de răspunsuri la comenzi corespunzătoare utilizând primitiva
processPdu. Generatorul de răspunsuri la comenzi execută următorii paşi:
 generatorul de răspunsuri la comenzi examinează
conţinutul pentru request PDU. Tipul operaţiei trebuie
să corespundă unuia din tipurile înregistrate de aplicaţie
 generatorul de răspunsuri la comenzi determină dacă
accesul pentru executarea operaţiei de management,
cerută de PDU, este permis. Este apelată primitiva
isAccessAllowed

41
  Dacă accesul este permis, aplicaţia execută operaţia de
management şi pregăteşte un response PDU. Dacă
accesul nu este permis, aplicaţia pregăteşte un response
PDU care indică eroarea.
 Aplicaţia apelează dispecerul cu primitiva
returnResponsePdu pentru a trimite response PDU.

Aplicaţiile de tip generator de notificări respectă procedura generală

utilizată de aplicaţiile generator de comenzi. Dacă trebuie trimis Inform
Request PDU, sunt folosite primitivele sendPdu şi processResponsePdu;
dacă trebuie trimis trap PDU, se foloseşte numai primitiva sendPdu.

Aplicaţiile de tip receptor de notificări respectă procedura pentru

aplicaţiile generator de răspunsuri la comenzi. Aplicaţia trebuie să se
înregistreze pentru a primi Inform şi/sau trap PDU. Ambele tipuri de PDU
sunt recepţionate cu ajutorul primitivei processPdu; primitiva
returnResponsePdu este folosită pentru a răspunde în cazul unei Inform
PDU.

Aplicaţiile de tip proxy forwarder utilizează primitivele pentru

dispecer pentru a retransmite patru tipuri de bază de mesaje:
 Mesaje care conţin tipuri de PDU de la o aplicaţie de tip
generator de comenzi. Trebuie stabilită entitatea SNMP
de destinaţie şi trimisă o request PDU către această
entitate sau către o entitate cât mai apropiată de ea .
 Mesaje care conţin tipuri de PDU de la o aplicaţie de tip
generator de notificări. Trebuie determinate entităţile
cărora li s-ar putea adresa notificarea şi trimise PDU-uri
de notificare către acestea.
 Mesaje care conţin Response PDU. Aplicaţia proxy
forwarder determină dacă există o cerere sau o
notificare retransmisă anterior care corespunde acestei
Response PDU şi o retransmite corespunzător.
 Mesaje care conţin Report PDU – unităţi date folosite
în SNMPv3 pentru comunicarea între manageri.
Aplicaţia proxy forwarder determină dacă există o
cerere sau o notificare retransmisă anterior care

42
 corespunde acestei Report PDU şi retransmite Report
PDU către emiţătorul cererii sau notificării.

Procesarea mesajelor şi modelul de securitate

Procesarea mesajelor implică un model general de procesare a
mesajelor şi un model de securitate specific; această relaţie a fost prezentată
în fig.3.4
RFC 2272 defineşte un model general de procesare a mesajelor.
Acest model include acceptarea PDU-urilor de la dispecer, încapsularea lor
în mesaje şi invocarea modelului de securitate al utilizatorului – USM
pentru inserarea parametrilor legaţi de securitate în header-ul mesajului. De
asemenea, modelul de procesare al mesajelor include acceptarea mesajelor
primite, invocarea USM pentru procesarea parametrilor legaţi de securitate
din header-ul mesajului şi transmiterea către dispecer a PDU încapsulat în
mesaj.
Figura 3.5 prezintă structura mesajului. Primele cinci câmpuri sunt
generate/procesate de modelul de procesare al mesajului pentru mesaje
transmise/recepţionate. Următoarele şase câmpuri indică parametrii de
securitate utilizaţi de USM. PDU, împreună cu contextEngineID şi
contextName formează un PDU ţintă (scoped PDU), utilizat pentru
procesarea PDU.
Primele cinci câmpuri sunt:
 msgVersion: setat pentru SNMPv3 (3)
 msgID: un identificator unic, utilizat între două
entităţi SNMP pentru a coordona mesajele de
cerere/răspuns şi de către procesorul de mesaje pentru
coordonarea procesării mesajelor de către diferite
subsisteme ale arhitecturii; este un număr cuprins
între 0 şi 231-1.
 msgMaxSize: dimensiunea maximă a mesajului
acceptată de expeditorul mesajului de la o altă
entitate SNMP; este un număr cuprins între 484 şi
231-1.
 msgFlags: un octet care conţine trei indicatori (flag)
în biţii cel mai puţin semnificativi: reportableFlag,
privFlag, authFlag. Dacă reportableFlag =1, atunci
trebuie returnat un Report PDU în cazul în care sunt

43
 îndeplinite condiţiile pentru generarea acestuia. Acest
indicator este folosit numai dacă apar erori la citirea
PDU din mesaj (de exemplu la decriptare). Indicatorii
privFlag şi authFlag indică folosirea criptării,
respectiv a metodelor de autentificare; sunt permise
toate combinaţiile cu excepţia criptării fără
autentificare (privFlag=1 şi authFlag=0).
 msgSecurityModel: un identificator al modelului de
securitate utilizat de expeditor pentru procesarea
mesajului; este un număr cuprins între 0 şi 231-1.
Valorile rezervate sunt 1 pentru SNMPv1, 2 pentru
SNMPv2, 3 pentru SNMPv3.

Fig 3.5 – Formatul mesajului SNMPv3 cu USM

44
 Modelul de securitate definit de RFC 2274 se numeşte USM - User
Security Model; asigură autenticitatea şi confidenţialitatea serviciilor pentru
protocolul SNMP. Acest model este proiectat pentru a contracara
următoarele tipuri de atacuri:
 Modificarea informaţiei: o entitate poate modifica în
timpul tranzitului un mesaj generat de o entitate
autorizată pentru a efectua operaţii de management
neautorizate. Esenţa acestui atac constă în faptul că o
entitate neautorizată ar putea schimba orice parametru
de management, inclusiv pe cei legaţi de configurare,
comenzi, evidenţă.
 Modificarea identităţii (masquerade): entităţi care
nu sunt autorizate pentru anumite operaţii pot încerca
să execute aceste operaţii prin asumarea identităţii
unei entităţi care are autorizarea necesară.
 Modificarea fluxului de mesaje: SNMP este
proiectat pentru a lucra deasupra unui protocol de
transport fără conexiune; există deci posibilitatea ca
mesajele să fie reordonate, întârziate sau duplicate
pentru a se realiza operaţii de management
neautorizate.
 Interceptarea informaţiei: o entitate poate urmări
schimburile de mesaje între un manager şi un agent
pentru a cunoaşte valorile pentru obiectele
administrate şi evenimentele care sunt notificate.

USM nu urmăreşte contracararea următoarelor tipuri de atacuri:

Interzicerea accesului la servicii: Atacul constă în
împiedicarea schimburilor de mesaje între entităţile
SNMP.
Analiza traficului: atacul constă în observarea
desfăşurării schimbului de mesaje.

Lipsa unor măsuri împotriva celor două tipuri de atacuri menţionate

mai sus este justificată de următoarele consideraţii:

45
  In cele mai multe cazuri, interzicerea accesului la
servicii nu poate fi deosebită de defecţiunile din reţea
pe care orice aplicaţie de management viabilă trebuie să
le administreze.
 Este probabil ca interzicerea accesului la servicii să
afecteze orice schimb de informaţii prin reţea, nu numai
schimburile necesare unui protocol de management;
contracararea acestui tip de atac este o problemă de
securitate globală a reţelei.
 În ceea ce priveşte analiza traficului, este util de
observat că succesiunea mesajelor unui protocol de
management este predictibilă, astfel încât rezultatele
analizei traficului nu sunt în general utile.

Funcţii criptografice definite de USM sunt autentificarea şi criptarea.

Pentru a asigura aceste funcţii, o entitate SNMP utilizează două valori: o
cheie privată (privKey) şi o cheie pentru autentificare (authKey). Există
valori diferite ale acestor două chei pentru următoarele tipuri de utilizatori:
 Utilizatori locali: orice entitate pentru care sunt
furnizate servicii sau pentru care se face procesarea pe o
maşină locală
 Utilizatori la distanţă: orice entitate aflată pe o maşină
pentru care este necesară comunicaţia

Valorile cheilor sunt memorate pentru fiecare utilizator; valorile

privKey şi authKey nu sunt accesibile cu ajutorul protocolului SNMP.
USM permite utilizarea a două protocoale alternative de autentificare:
HMAC-MD5-96 şi HMAC-SHA-96. HMAC foloseşte o funcţie hash şi o
cheie secretă pentru a genera un cod de autentificare a mesajului; HMAC
este definit de RFC 2104 şi est utilizat în multe aplicaţii pentru Internet.
HMAC-MD5-96 foloseşte funcţia hash MD5, cheia de autentificare este de
16 octeţi; algoritmul generează un cod de 16 octeţi care este trunchiat la 12
octeţi. HMAC-sha-96 foloseşte funcţia hash SHA-1, cheia de autentificare
este de 20 de octeţi; algoritmul generează un cod de 20 de octeţi care este
trunchiat la12 octeţi.
USM foloseşte pentru criptare standardul Data Encryption Standard –
DES în mod Cipher Block Chaining - CBC. Cheia secretă are o lungime de
16 octeţi; primii 8 octeţi sunt folosiţi drept cheie pentru DES, ceilalţi 8

46
octeţi sunt folosiţi pentru generarea vectorului de iniţializare IV pentru
CBC. Deoarece DES utilizează o cheie de 56 de biţi, cel mai puţin
semnificativ bit din primii 8 octeţi este ignorat.

Entităţi cu autoritate şi entităţi fără autoritate. În orice transmisie

de mesaje, una din cele două entităţi, emiţător sau receptor, este considerată
entitate SNMP cu autoritate, conform următoarelor reguli:
 Dacă un mesaj SNMP are un conţinut care presupune
un răspuns (de exemplu Get, GetNext, GetBulk,
Inform PDU), atunci receptorul mesajului este entitate
cu autoritate.
 Dacă un mesaj SNMP are un conţinut care nu
presupune un răspuns ( de exemplu: SNMPv2-Trap,
Response PDU , Report PDU), atunci emiţătorul
mesajului este entitate fără autoritate.

Desemnarea entităţilor ca fiind cu autoritate sau fără autoritate este

utilă în două scopuri:
 Corectitudinea temporală pentru un mesaj este
determinată prin raportare la un ceas generat de
entitatea cu autoritate. Atunci când entitatea cu
autoritate trimite un mesaj (Trap, Response, Report),
mesajul conţine valoarea curentă a ceasului entităţii cu
autoritate, astfel încât receptorul, entitate fără
autoritate, se poate sincroniza cu acest ceas. Atunci
când o entitate fără autoritate trimite un mesaj (Get,
GetNext, GetBulk, Set, Inform), acesta include
propria estimare a valorii ceasului de la destinaţie,
permiţând astfel receptorului să estimeze corectitudinea
temporală a mesajului.
 Un proces de localizare a cheii criptografice, care va fi
descris ulterior, validează o singură entitate principală
pentru a deţine chei memorate în mai multe entităţi;
aceste chei sunt localizate către entitatea cu autoritate
în aşa fel încât entitatea principală este responsabilă
pentru o singură cheie şi evită riscurile memorării unor
copii multiple ale aceleiaşi chei într-un sistem
distribuit.

47
 Desemnarea ca entitate cu autoritate a receptorului mesajelor care
conţin comenzi şi Inform PDU este justificată de efectul acestor mesaje
asupra operaţiilor de management al obiectelor, şi anume citirea sau
modificarea informaţiei din MIB; este normal ca receptorul să poată verifica
corectitudinea temporală pentru aceste mesaje deoarece întârzierea sau
repetarea lor poate avea efecte nedorite. Întârzierea unui mesaj Response
sau trap are efecte mai puţin importante.

Câmpurile din header-ul unui mesaj SNMP dependente de

modelul de securitate sunt adăugate/procesate de USM atunci când
mesajul este emis/recepţionat. Parametrii de securitate ai unui mesaj sunt
următorii (figura5):
 msgAuthoritativeEngineID: conţine valoarea
snmpEngineID a entităţii cu autoritate implicate în
transmiterea mesajului; se referă la sursa mesajului
pentru Trap, Response, Report şi la destinaţia
mesajului pentru Get, GetNext, GetBulk, Set, Inform.
 msgAuthoritativeEngineBoots: conţine valoarea
snmpEngineBoots a entităţii cu autoritate implicate în
transmiterea mesajului; este un număr întreg cuprins
între 0 şi 231-1 şi indică de câte ori această entitate a
fost iniţializată sau s-a reiniţializat de la configurarea
iniţială.
 msgAuthoritativeEngineTime: conţine valoarea
snmpEngineTime a entităţii cu autoritate implicate în
transmiterea mesajului; este un număr întreg cuprins
între 0 şi 231-1 şi indică intervalul de timp în secunde,
scurs de la ultima incrementare de către entitatea cu
autoritate a snmpEngineBoots. Fiecare entitate cu
autoritate este responsabilă pentru incrementarea
valorii proprii pentru snmpEngineBoots, o dată pe
secundă; o entitate fără autoritate este responsabilă
pentru incrementarea valorii estimate proprii pentru
fiecare entitate cu autoritate cu care comunică.
 msgUserName: conţine numele utilizatorului
(principal) pentru care mesajul este transmis.

48
  msgAuthenticationParameters: este nul dacă nu se
foloseşte autentificarea pentru mesajul curent; în caz
contrar, este un parametru de autentificare: HMAC
dacă modelul de securitate este USM.
 msgPrivacyParameters: este nul dacă nu se foloseşte
criptarea pentru mesajul curent, în caz contrar este un
parametru de criptare: valoarea destinată calculării
valorii iniţiale (IV) pentru algoritmul DES-CBC, dacă
modelul de securitate este USM.

Figura 3.6 descrie operaţiile pentru USM:

La transmiterea unui mesaj, dacă se foloseşte criptarea, scoped PDU
este criptat şi reprezintă conţinutul mesajului; valoarea
msgPrivacyParameters este setată cu valoarea necesară pentru generarea
valorii de iniţializare. Apoi, dacă se foloseşte autentificarea, întregul mesaj,
incluzând scoped PDU este folosit ca intrare pentru algoritmul HMAC;
codul de autentificare rezultat este plasat în câmpul
msgAuthenticationParameters.
La recepţionarea unui mesaj, dacă se foloseşte autentificarea, USM
testează codul MAC recepţionat prin compararea acestuia cu codul MAC
calculat ; dacă cele două valori sunt identice, mesajul este considerat
autentic (provine de la sursa declarată şi nu a fost modificat în timpul
transmisiei). Apoi USM testează corectitudinea temporală a mesajului,
adică dacă acesta a sosit într-un interval de timp acceptabil, după procedura
descrisă mai jos; dacă acest test eşuează, mesajul nu este considerat
autentic. În sfârşit, dacă mesajul este criptat, USM realizează decriptarea şi
returnează textul clar.

49
Fig 3.6 – USM - procesarea mesajului

50
 Mecanismul de verificare al corectitudinii temporale inclus de
USM asigură protecţia împotriva întârzierii şi a repetării mesajelor. Orice
entitate SNMP, pentru a putea fi entitate cu autoritate trebuie să actualizeze
două valori pentru evidenţa timpului local: snmpEngineBoots şi
snmpEngineTime. La instalarea iniţială a unei entităţi SNMP, aceste două
valori sunt setate la 0; apoi snmpEngineTime este incrementată la fiecare
secundă. Dacă snmpEngineTime atinge valoarea maximă, (231-1), atunci
snmpEngineBoots este incrementată, la fel ca la reiniţializarea sistemului,
iar snmpEngineTime este setată la 0 şi începe să fie incrementată din nou.
Entităţile fără autoritate trebuie să menţină, cu ajutorul unui mecanism de
sincronizare, estimări ale valorilor de timp pentru toate entităţile cu
autoritate cu care comunică. Valorile estimate sunt înscrise în fiecare mesaj
transmis şi permit entităţilor cu autoritate să determine dacă un mesaj a fost
recepţionat la timp.
Mecanismul de sincronizare: Fiecare entitate fără autoritate menţine o
copie locală pentru trei variabile ale fiecărei entităţi cu autoritate cu care
comunică:
 snmpEngineBoots: cea mai recentă valoare pentru
entitatea cu autoritate
 snmpEngineTime: evaluarea locală a
snmpEngineTime pentru entitatea cu autoritate aflată
la distanţă. Această valoare este sincronizată cu
entitatea de la distanţă prin procesul de sincronizare
descris mai jos. Între momentele de sincronizare,
această valoare este incrementată la fiecare secundă
pentru a menţine o corespondenţă aproximativă cu
entitatea cu autoritate.
 latestReceiveEngineTime: cea mai mare valoare
pentru msgAuthoritativeEngineTime care a fost
recepţionat de entitatea locală de la entitatea cu
autoritate aflată la distanţă. Scopul acestei variabile
este de a contracara un atac prin repetarea mesajului,
care împiedică entitatea fără autoritate să incrementeze
valoarea estimată a snmpEngineTime.

Aceste trei valori sunt păstrate de entitatea fără autoritate, prin

indexare cu valorile snmpEngineID corespunzătoare fiecărei entităţi cu
autoritate aflate la distanţă. Pentru a permite entităţilor fără autoritate să

51
păstreze sincronizarea, fiecare entitate cu autoritate inserează valorile sale
curente de timp şi valoarea snmpEngineID în fiecare mesaj Trap,
Response sau Report în câmpurile msgAuthoritativeEngineBoots,
msgAuthoritativeEngineTime, msgAuthoritativeEngineId. Dacă mesajul
este autentic şi dacă este recepţionat în fereastra de timp admisă, atunci
entitatea fără autoritate receptoare îşi actualizează variabile locale
(snmpEngineBoots, snmpEngineTime şi latestReceivedEngineTime)
asociate entităţii de la care s-a primit mesajul, conform următoarelor reguli:
1. O actualizare are loc dacă cel puţin una din următoarele două
condiţii este adevărată:
 (msgAuthoritativeEngineBoots >
snmpEngineBoots) or
 [(msgAuthoritativeEngineBoots =
snmpEngineBoots) and
(msgAuthoritativeEngineTime >
latestReceivedEngineTime)]

Prima condiţie stabileşte că o actualizare ar trebui să aibă loc dacă

entitatea cu autoritate a fost reiniţializată de la ultima actualizare. A doua
condiţie stabileşte că, dacă nu a avut loc o reiniţializare a entităţii cu
autoritate, atunci ar trebui să aibă loc o actualizare, dacă valoarea primită
pentru EngineTime este mai mare decât cea primită anterior. Valoarea
primită pentru EngineTime poate fi mai mică decât cea primită anterior,
dacă mesajele nu sunt primite în ordinea de la emisie, ceea ce este posibil,
sau dacă are loc un atac prin repetare; în ambele cazuri nu se va face
actualizarea.

2. Dacă se face o actualizare, atunci au loc următoarele

modificări:
 snmpEngineBoots ia valoarea
msgAuthoritativeEngineBoots
 snmpEngineTime ia valoarea
msgAuthoritativeEngineTime
 latestReceivedEngineTime ia valoarea
msgAuthoritativeEngineTime

Sincronizarea se face numai pentru mesajele pentru care serviciul de

autentificare este folosit şi numai dacă prin metoda HMAC mesajul este

52
declarat autentic. Această restricţie este esenţială deoarece domeniul de
autentificare include msgAuthoritativeEngineID,
msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime; se
verifică astfel că aceste valori sunt valide.
SNMPv3 stabileşte că un mesaj trebuie să fie recepţionat într-o
fereastră (interval) de timp rezonabil pentru a se evita întârzierile şi
atacurile prin repetare. Fereastra de timp trebuie aleasă cât mai mică,
ţinându-se seama de acurateţea ceasurilor implicate, de întârzierile datorate
timpilor de propagare şi de intervalele la care sunt sincronizate ceasurile.
Dacă fereastra este prea mică, vor fi rejectate mesaje autentice, dacă
fereastra este mai mare, creşte vulnerabilitatea la atacuri.
Vom considera testarea corectitudinii temporale în cazul unui receptor
cu autoritate; cazul unui receptor fără autoritate este asemănător. Pentru
fiecare mesaj care a fost autentificat şi care are acelaşi
msgAuthoritativeEngineID cu snmpEngineId propriu receptorului,
receptorul compară valorile msgAuthoritativeEngineBoots şi
msgAuthoritativeTime din mesaj cu valorile locale snmpEngineBoots şi
snmpEngineTime. Mesajul primit este considerat în afara ferestrei de timp
dacă oricare din următoarele condiţii este îndeplinită:
 snmpEngineBoots = 231-1 sau
 msgAuthoritativeEngineBoots  snmpEngineBoots
sau
 valoarea pentru msgAuthoritativeEngineTime diferă
de valoarea pentru snmpEngineTime cu mai mult de
150s

Prima condiţie arată că în cazul în care snmpEngineBoots este blocat

la valoarea maximă, nici un mesaj recepţionat nu este considerat autentic. A
doua condiţie indică faptul că în cazul în care receptorul s-a reiniţializat şi
entitatea aflată la distanţă nu s-a sincronizat cu receptorul după
reiniţializare, mesajele sosite de la entitatea aflată la distanţă nu sunt
considerate autentice. Condiţia finală impune o diferenţă mai mică sau cel
mult egală cu 150s între ceasul celor două entităţi.
Dacă un mesaj este considerat în afara ferestrei de timp, mesajul este
rejectat ca fiind neautentic şi este generată o indicaţie de eroare:
notInTimeWindow.

53
 La fel ca pentru sincronizare, testarea corectitudinii temporale se face
numai dacă serviciul de autentificare este utilizat şi dacă mesajul a fost
autentificat, autentificându-se implicit şi header-ul.

Localizarea cheii criptografice. Pentru a se putea folosi serviciile

care asigură autentificarea şi confidenţialitatea în comunicarea dintre un
utilizator principal de pe o entitate fără autoritate şi o entitate cu autoritate
(de regulă , agent), cele două entităţi trebuie să partajeze două chei
criptografice secrete: o cheie pentru autentificare şi o cheie pentru criptare.
RFC 2274 indică modul de creare, actualizare şi administrare al acestor
chei.
În scopul simplificării administrării cheilor criptografice, fiecare
utilizator principal trebuie să păstreze numai două chei, una pentru
autentificarea şi una pentru criptare. Aceste chei nu sunt memorate în MIB
şi nu sunt accesibile prin SNMP. Managementul cheilor criptografice se
bazează pe două metode ce vor fi prezentate în continuare:
 Cheile sunt generate pe bază de parolă
 Conceptul de localizare a cheilor permite unui utilizator
principal să partajeze câte o cheie unică, pentru
autentificare, respectiv criptare, cu fiecare entitate aflată
la distanţă, păstrând local câte o singură cheie pentru
autentificare, respectiv criptare.

Un utilizator are nevoie de o cheie pentru criptare de 16 octeţi şi de o

cheie pentru autentificare de 16 sau 20 octeţi. În cazul cheilor folosite de
operatori umani este preferabil ca acestea să fie reprezentate de şiruri de
cuvinte şi nu de şiruri de biţi. RFC2274 defineşte un algoritm care asociază
parolelor chei criptografice de 16 şi 20 octeţi. USM nu stabileşte restricţii
asupra parolelor, dar este indicat ca instrucţiunile de exploatare să impună
utilizarea unor parole care nu pot fi deduse uşor.
Generarea cheilor criptografice se face astfel:
1. Se obţine un şir de lungime 220 octeţi, denumit digest0,
prin repetarea parolei de câte ori este necesar, cu
trunchierea ultimei repetări, dacă este necesar.
2. Acest şir este folosit ca şir de intrare pentru algoritmul
MD5 dacă se doreşte o cheie de 16 octeţi sau pentru SHA-
1 pentru o cheie de 20 octeţi. Rezultatul, digest1, este
cheia criptografică.

54
 Această metodă de generare a cheii criptografice are două avantaje:
 Creşte în mod semnificativ durata de găsire a cheii în
cazul unui atac cu forţă brută, care presupune generarea
tuturor cheilor posibile.
 Separă cheile utilizatorului de sistemul de management al
reţelei (NMS – Network Management System). NMS nu
trebuie să stocheze cheile utilizatorului, aceste vor fi
generate de câte ori este nevoie plecând de la parolă.

Generarea cheilor plecând de la parolă are următoarele avantaje:

 În cazul în care se preferă memorarea cheilor în locul
generării lor plecând de la parolă, este necesară stocarea
lor centralizată; aceasta reduce siguranţa sistemului şi
poate face imposibilă accesarea cheilor în cazul unei
defecţiuni care afectează fişierul în care sunt stocate
acestea.
 Dacă sunt folosite copii ale fişierului pentru chei, se
creează ţinte suplimentare pentru un eventual atac asupra
securităţii sistemului.

Ambele chei criptografice, pentru autentificare şi pentru criptare pot fi

generate pornind de la o singură parolă; opţional, pentru o securitate sporită
se pot utiliza parole diferite pentru autentificare şi pentru criptare.
RFC 2274 numeşte cheia partajată de un utilizator şi o entitate SNMP
cu autoritate, cheie criptografică localizată. Utilizatorul trebuie să păstreze
câte o singură cheie pentru autentificare, respectiv pentru criptare. Cheia
efectiv partajată este rezultatul procesului de localizare, prin care cheia unui
utilizator este convertită în chei diferite, câte una pentru fiecare entitate
SNMP cu care comunică utilizatorul.
Managementul cheilor implică următoarele cerinţe:
 Fiecare agent SNMP dintr-un sistem distribuit să
deţină câte o cheie criptografică pentru fiecare utilizator
care este autorizat să-l administreze. Dacă este compromisă
cheia criptografică pentru un utilizator, cheile pentru
ceilalţi utilizatori să poată fi folosite în continuare.
 Fiecare utilizator dintr-un sistem distribuit să deţină
câte o cheie criptografică pentru fiecare agent pe care este

55
 autorizat să-l administreze. Dacă este compromisă cheia
criptografică pentru un agent, cheile pentru ceilalţi agenţi
să poată fi folosite în continuare.
 Funcţiile de management al reţelei să poată fi
executate de utilizator din orice punct al reţelei,
independent de configurarea sistemului de management al
reţelei. Această cerinţă este satisfăcută în cazul SNMP prin
algoritmul de asociere parolă – cheie criptografică descris
anterior.
 Un utilizator să nu fie obligat să administreze un
număr mare de chei, care să crească odată cu adăugarea de
noi agenţi administraţi.
 Un adversar care descoperă cheia unui agent să nu
fie capabil să se substituie nici unei alte entităţi din reţea,
cu excepţia agentului respectiv.

Fig 3.7 – Localizarea cheilor

Pentru a realiza aceste cerinţe, singura cheie a unui utilizator este

asociată cu ajutorul unei funcţii neinversabile (de exemplu o funcţie hash

56
one-way), cu diferite chei localizate pentru diferiţi agenţi. Procedura este
următoarea:
1. Se formează şirul digest2 prin concatenarea şirului:
digest1 (cheia criptografică unică), a cărui formare a fost
descrisă anterior, valoarea snmpEngineID pentru entitatea
autorizată, digest1.
2. Digest2 este folosit ca şir de intrare pentru algoritmul
MD5, dacă se doreşte o cheie de 16 octeţi, sau pentru
SHA-1, dacă se doreşte o cheie de 20 octeţi. Şirul rezultat
este cheia criptografică localizată pentru entitatea având
snmpEnginID utilizat de algoritm şi utilizatorul având
cheia digest1.

Cheia criptografică rezultată poate fi apoi configurată pe sistemul

agent. Datorită utilizării unui algoritm nereversibil prin natura sa (MD5 sau
SHA-1), un adversar nu poate afla cheia utilizatorului, chiar dacă reuşeşte
să cunoască o cheie localizată.
Figura 3.7 prezintă schematic procesele descrise mai sus.

Controlul accesului la MIB implementează mecanismele care

stabilesc dacă este permis accesul unui utilizator la înregistrările MIB-
Management Information Base ale unui agent SNMP. În principiu pot fi
concepute mai multe modele de control al accesului. Documentele SNMPv3
definesc modelul VACM – View-Based Access Control.
RFC 2275 defineşte cinci elemente care constituie VACM: grupurile,
nivelul de securitate, contextele, MIB views şi politica de acces.
Grupul este definit ca o mulţime formată din perechi
<securityModel, securityName> utilizate pentru accesul la obiectele
SNMP. Un securityName se referă la un utilizator principal; drepturile de
acces pentru toţi utilizatorii principali dintr-un grup sunt identice. Un singur
groupName este asociat cu fiecare grup. Conceptul de grup este util pentru
a organizarea managerilor pe baza drepturilor de acces.
O pereche securityModel şi securityName poate aparţine unui singur
grup. Rezultă că pentru un agent dat, un utilizator principal pentru care
comunicaţia este protejată de un anumit model de securitate, poate fi inclus
într-un singur grup.
Nivelul de securitate. Drepturile de acces pentru un grup pot fi
diferite în funcţie de nivelul de securitate al mesajului care conţine cererea

57
de acces. De exemplu, un agent poate să ceară autentificarea mesajului
pentru a permite scrierea în MIB, dar să permită citirea informaţiei fără
autentificarea mesajului. În plus, pentru anumite obiecte, agentul poate cere
ca mesajele de cerere şi de răspuns să folosească serviciul de criptare.
Contexte. Un context MIB este un concept legat de controlul
accesului şi reprezintă o submulţime a obiectelor administrate existente la
un agent. Contextele asigură un mod util de a asocia obiectele în mulţimi
cărora le corespunde o politică de acces diferită.
MIB-Views. Acest concept permite limitarea accesului unui anume
grup la anumite obiecte ale unui agent. Obiectele unui agent sunt organizate
în baza de date locală în mod ierarhic, în structuri arborescente. Un MIB-
view este definit ca o familie de structuri arborescente, pentru fiecare arbore
secundar putându-se specifica includerea sau excluderea sa dintr-un MIB-
view. Accesul la un context se realizează cu ajutorul MIB-view.
Politica de acces a modelului VACM permite configurarea anumitor
drepturi de acces pentru o maşină SNMP. Drepturile de acces sunt
determinate de:
 Utilizatorul principal care face cererea de acces; modelul
permite ca un agent să permită drepturi de acces diferite
pentru diferiţi utilizatori. De exemplu, un manager de
sistem responsabil cu configurarea reţelei poate avea
dreptul de a modifica toate obiectele din MIB-ul local, în
timp ce un utilizator responsabil cu monitorizarea, poate
avea numai drepturi de citire, eventual numai pentru o
parte din obiectele din MIB-ul agentului. Utilizatorii
principali sunt organizaţi în grupuri, iar politica de acces
este definită cu referire la aceste grupuri.
 Nivelul de securitate al mesajului SNMP cu care este
comunicată cererea; în mod normal, un agent va impune
autentificarea pentru mesajele care presupun operaţii de
scriere în MIB.
 Modelul de securitate utilizat pentru procesarea
mesajului de cerere; dacă sunt implementate mai multe
modele pentru un agent, agentul poate fi configurat pentru
a asigura drepturi de acces diferite, în funcţie de modelul
de securitate după care a fost procesat mesajul.
 Contextul MIB pentru cererea de acces.

58
  Obiectul specific pentru care este cerut accesul; anumite
obiecte pot conţine informaţie mai critică pentru sistem
decât alte obiecte de acelaşi fel.
 Tipul de acces; sunt definite trei tipuri: citire, scriere,
notificare, şi fiecărui tip i se poate aplica diferite politici de
control al accesului.

Procesarea controlului accesului. În aplicaţiile SNMP modelul

VACM este invocat prin primitiva isAccessAlowed cu următorii parametri
de intrare: securityModel, securityName, viewType, contextName,
VariableName; toţi aceşti parametri sunt necesari pentru luarea unei decizii
asupra controlului accesului. Această implementare asigură un mod de
configurare foarte flexibil al controlului accesului la MIB-ul unui agent
SNMP.
Figura 3.8, realizată după RFC2275, arată modul în care parametrii de
mai sus şi tabelele VACM determină deciziile privind controlul accesului:
 who: combinaţia securityModel, securityName identifică
utilizatorul principal ale cărui comunicaţii sunt protejate de
un model de securitate dat. Această combinaţie aparţine
acelui grup al maşinii SNMP, al cărui groupName rezultă
din tabela vacmSecurityToGroupTable.
 Where: parametrul contextName indică unde se găseşte
obiectul la care se face referire; vacmContextTable
conţine lista pentru contextName existente.
 How: combinaţia securityModel, securityLevel defineşte
cum a fost protejată cererea sau Inform PDU. Combinaţia
who, where, how defineşte intrarea în vacmAccessTable,
dacă această intrare există.
 Why: parametrul viewType specifică pentru ce operaţie
este cerut accesul: scriere, citire, notificare. Intrarea
selectată pentru vacmAccessTable conţine câte un MIB
viewName pentru fiecare din aceste trei operaţii;
viewType este folosit pentru selecţie. Parametrul
viewName selectat determină alegerea unui MIB view
corespunzător din vacmViewTreeFamilyTable.

59
  What: parametrul variableName este un identificator de
obiect; prefixul lui indică un tip de obiect, iar sufixul o
implementare particulară.
 Which: Implementarea particulară a obiectului indică ce
informaţie este căutată.

În final variableName este comparat cu MIB-view selectat; dacă

variableName corespunde unui element din MIB-view, accesul este
permis.
Descrierea modelului de securitate cu un număr relativ mare de
variabile asigură flexibilitatea şi funcţionalitatea acestuia.

Fig 3.8 – Logica VACM

60
 4. SSL
Arhitectura SSL

SSL Record Protocol

Handshake Protocol

61
 Protocolul SSL - Secure Socket Layer a fost iniţiat de Netscape
Communications în anul 1994 pentru asigurarea tranzacţiilor comerciale pe
Web; este inclus în browserele Netscape şi Microsoft Explorer. Protocolul
este compatibil cu peste 30 de algoritmi criptografici, inclusiv algoritmi
recenţi, de exemplu AES – Advanced Encryption Standard. Varianta SSLv3
reprezintă baza pentru protocolul TSL – Transport Layer Security, dezvoltat
ca standard pentru Internet în cadrul IEFT (RFC 2246).

Arhitectura SSLv3

SSL este proiectat pentru a utiliza protocolul TCP astfel încât să se

asigure un serviciu sigur între utilizatorii finali. SSL este un protocol
implementat pe două nivele, deasupra nivelului de transport. Figura 4. 1
prezintă stiva de protocoale, în cazul folosirii SSL în cadrul modelului
TCP/IP.

Fig 4.1 –Stiva de protocoale SSL

62
 SSL Record Protocol asigură servicii de securitate de bază pentru
protocoalele aflate pe nivelul superior, în particular pentru protocolul HTTP
– Hypertext Transfer Protocol, care asigură serviciile pentru comunicarea
client-server în aplicaţiile pentru Web. Trei protocoale de nivel înalt:
Handshake Protocol, Change Cipher Spec Protocol şi Alert Protocol, sunt
definite ca parte a SSL şi sunt folosite pentru managementul schimburilor de
informaţie SSL.
Specificaţia SSL utilizează conceptele de sesiune şi conexiune.
Sesiunea SSL este o asociere dintre un client şi un server; este creată de
Handshake Protocol şi defineşte un set de parametri criptografici care pot fi
partajaţi de mai multe conexiuni asociate aceleiaşi sesiuni. Sesiunile sunt
folosite pentru a evita negocierea parametrilor criptografici pentru fiecare
conexiune. Conexiunea este o legătură logică tranzitorie care asigură servicii
de transport între două entităţi asociate într-o sesiune. Între entităţile
pereche, aplicaţie http client / aplicaţie http server, pot există mai multe
conexiuni simultane.
O sesiune este asociată cu un număr de stări, corespunzătoare stabilirii
legăturii, recepţiei sau transmisiei. Conform specificaţiei SSL, starea unei
sesiuni este definită de următorii parametri:
 Identificatorul de sesiune: o secvenţă arbitrară de
octeţi aleasă de server pentru a identifica o stare
activă sau în aşteptare.
 Certificatul X509v3. al entităţii pereche;
parametrul poate fi nul
 Metoda de compresie: algoritmul utilizat pentru
compresia datelor înainte de criptare.
 Specificaţia criptografică: algoritmul de criptare,
algoritmul hash şi lungimea codului de autentificare
a mesajului.
 Secretul principal: 48 de octeţi partajaţi de client şi
server.
 Indicator: dacă sesiunea poate fi folosită pentru a
iniţia noi conexiuni.

Starea unei conexiuni este definită de următorii parametri:

 Secvenţa aleatoare de octeţi aleasă de client şi
server pentru fiecare conexiune.

63
  Cheia secretă a serverului pentru autentificare
folosită la transmisia datelor de către server.
 Cheia secretă a clientului pentru autentificare
folosită la transmisia datelor de către client.
 Cheia secretă a serverului: cheia convenţională
folosită pentru criptare de către server şi pentru
decriptare de către client.
 Cheia secretă a clientului: cheia convenţională
folosită pentru criptare de către client şi pentru
decriptare de către server.
 Vectori de iniţializare folosiţi pentru cifruri bloc în
mod înlănţuit (CBC). Pentru fiecare cheie, există un
vector care este iniţializat de către SSL Handshake
Protocol; apoi blocul final al cifrului pentru fiecare
înregistrare este păstrat şi folosit ca vector de
iniţializare pentru înregistrarea următoare.
 Numere de secvenţă. Fiecare entitate păstrează
numere de secvenţă separate pentru mesajele
transmise şi recepţionate în cadrul fiecărei
conexiuni; valoarea maximă admisă este 264-1.

SSL Record Protocol

SSL Record Protocol asigură următoarele două servicii pentru

conexiunile SSL:
 Confidenţialitate prin definirea unei chei
criptografice simetrice folosite pentru criptarea
conţinutului mesajului.
 Integritatea mesajului prin definirea unei chei
simetrice pentru generarea codului de autentificare
a mesajului.

64
 Fig 4.2 Etapele protocolului SSL Record

Figura 4.2 prezintă modul de operare al SSL Record Protocol.

Mesajul generat de aplicaţie pentru transmisie este preluat de protocol
pentru a fi fragmentat în blocuri care pot fi procesate, apoi aceste blocuri
sunt comprimate, completate cu codul de autentificare – MAC, criptate,
completate cu un header şi predate protocolului de transport, TCP, pentru
transmisie. La recepţie operaţiile se execută în ordine inversă, mesajul
reasamblat fiind predat aplicaţiei căreia îi este destinat.
Fragmentarea se face în blocuri de cel mult 214 octeţi. Compresia este
opţională, iar protocolul nu indică un anumit algoritm. Calcularea MAC este
definită astfel:

65
 hash(MAC_write_secret pad_2 hash(MAC_write_secret pad_1
seq_num
SSL.Compressed.type SSL.Compressed.length
SSL.Compressed.fragment))

unde:
 = concatenare
MAC_write_secret = cheie secretă simetrică
hash = algoritm pentru hash: MD% sau
SHA-1
pad_1 = octetul 36H repetat de 48 de ori
pentru MD5 sau de
40 de ori pentru SHA-1
pad2 = octetul 5CH repetat de 48 de ori
pentru MD5 sau de
40 de ori pentru SHA-1
seq_num = numărul de secvenţă al mesajului
SSL.Compressed.type = protocolul de nivel superior care
procesează fragmentul
SSL.Compressed.length = lungimea fragmentului
SSL.Compressed.fragment = fragmentul după compresie (dacă nu
se foloseşte compresia, textul clar)

Blocul care rezultă prin adăugarea MAC la fragmentul compresat este

criptat cu un algoritm de criptare simetrică, de exemplu: IDEA, DES,
3DES, Fortezza.

66
 Fig 4.3 SSL Record Format

În final se adaugă blocului rezultat prin criptare, un header cu

următoarea structură (figura 4.3):
 Content Type (8 biţi): protocolul de nivel superior care
procesează fragmentul
 Major Version (8 biţi): valoarea pentru SSLv3 este 3
 Minor Version: valoarea pentru SSLv3 este 0
 Compressed length: lungimea textului clar din fragment
în octeţi; valoarea maximă este 214 +2048.

Tipurile de conţinut definite de standard sunt următoarele:

change_cipher_spec, alert, hand-shake, application_data. Primele trei
corespund protocoalelor specifice SSL care, au fost menţionate anterior; nu
se face nici o deosebire între diferitele aplicaţii (de exemplu http) care
utilizează SSL.

67
 Handshake Protocol

Handshake Protocol asigură crearea sesiunilor, autentificarea părţilor,

negocierea algoritmului de criptare şi schimbul de informaţie pentru
generarea cheilor criptografice. Figura 4.4 indică modul de lucru al acestui
protocol.

Fig 4.4 – Handshake Protocol

68
Fazele stabilirii unei sesiuni sunt următoarele:
1. Atunci când un client este gata
pentru a stabili o legătură cu un server, clientul trimite un
mesaj iniţial, client_hello, care este folosit pentru a stabili
parametrii de securitate ai sesiunii. Acest mesaj informează
serverul asupra versiunii de protocol, ID-ului de sesiune,
suitei de algoritmi criptografici şi metodelor de compresie
disponibile pentru client. Mesajul conţine de asemenea date
generate aleatoriu de client. Mesajul server_hello conţine
numărul celei mai recente versiuni admisibile pentru server
şi client, un singur algoritm de cifrare selectat de server
dintre cele propuse de client şi date identice cu cele
recepţionate.
2. Opţional, clientul poate cere
autentificarea serverului. În acest scop, clientul utilizează
certificatul serverului. În primul rând, clientul verifică dacă
data de pe certificatul serverului este validă; apoi verifică
dacă autoritatea de certificare se află pe lista sa de CA de
încredere. Al treilea pas al autentificării serverului este
validarea semnăturii digitale a CA cu cheia publică
obţinută din certificatul CA. În acest moment clientul a
stabilit dacă certificatul serverului este valid sau nu.
Ultimul pas, opţional, verifică dacă adresa de reţea a
serverul corespunde cu numele de domeniu specificat în
certificat. Clientul este avertizat dacă autentificarea
serverului eşuează. În finalul acestei faze, serverul
transmite mesajul server_hello_done şi apoi aşteaptă un
răspuns al clientului.
3. Dacă serverul a cerut autentificarea
clientului, clientul trimite propriul certificat şi un set de
date semnate. Serverul execută paşii procesului de
autentificare.
4. Ultima fază, trimiterea de către
client, apoi de către server, a mesajelor change_cipher-
spec şi finished, încheie stabilirea unei conexiuni sigure

69
prin confirmarea parametrilor criptografici negociaţi, ca
parametri criptografici curenţi.

70