Robert Gavrilă
Modelul de apel de proceduri la distantă este similar cu modelul apelului local de proceduri. În cazul local apelandul plasează argumentele unei proceduri în niste locatii bine specificate si îsi continuă activitatea.
Apelul procedurilor este o metodă binecunoscută de transfer al controlului dintr-o parte în alta, cu returul la apelant. Multe din procesoarele existente implementează această metodă printr-o instructiune de forma "salt la subrutină".
Pentru a se realiza apelul unei proceduri la distantă "apelandul" trebuie să-i comunice "apelatului" ce anume doreste să apeleze, acest lucru realizându-se printr-un mesaj care printre alte componente are si niste componente de autentificare.
Protocolul RPC furnizează un câmp necesar unui client pentru a se identifica în cazul cererii unui serviciu pentru fiecare apel si răspuns de la "apelant". Serviciile de securitate au fost construite pornind de la un câmp pentru credit, un câmp pentru verificare, în cadrul cererii si un câmp de verificare în cadrul răspunsului.
Mecanismul de autentificare este realizat printr-o serie de metode, una dintre ele folosind algoritmul DES.
Astfel se verifică dacă un server poate valida cererea unui client. Continutul câmpului de autentificare este initial o stampilă de timp (timestamp) criptată. Serverul poate decripta această "stampilă de timp"si dacă timpul se încadrează în limitele admise atunci se poate spune că, clientul a criptat-o corect. Doar clientul care a criptat corect cunoaste "cheia de conversatie" a sesiunii RPC deci putem spune că el este un client real.
Stabilirea cheilor de conversatie pentru o sesiune RPC se realizează folosind schema Diffie -Hellman, pe care o vom prezenta în continuare.
Această schemă de criptare are în componenta sa două constante:
- baza (BASE);
- modulul (MODULUS)
Protocolul dezvoltat de Sun are următoarele valori pentru aceste constante:
const BASE =3;
const MODULUS ="d4a0ba0250b 6fd2ec626e7efd637df76c716e22d0944b88b";
Pentru a exemplifica modul de functionare a acestei scheme vom da un exemplu.
Astfel fie două persoane "A" si "B" care vor să trimită mesaje criptate între ele si alte persoane. Deci "A" si "B" vor genera chei secrete pe care nu le cunoaste nimeni altcineva. Vom numi aceste chei SK(A) si SK(B). Într-un director "public" vor scrie cheile lor "publice" astfel încât ele să poată să fie cunoscute de oricine. Aceste chei publice se calculează după formula:
PK(A) = ( BASE ** SK(A) )
mod MODULUS
PK(B) = ( BASE ** SK(B) )
mod MODULUS
Notatia "**" este folosită aici pentru exponentială. Acum "A" si "B" pot ajunge la o cheie comună reprezentată de CK(A, B) fără să-si cunoască între ele cheile secrete.
Formula pentru CK(A, B) calculată de "A" este:
CK(A, B) = ( PK(B) ** SK(A) )
mod MODULUS
"B" va calcula:
CK(A, B) = ( PK(A) ** SK(B) )
mod MODULUS
Aceste formule trebuie sa fie echivalente:
(PK(B) ** SK(A) ) mod MODULUS = (PK(A) ** (SK(B) )mod MODULUS
Eliminând partea cu " mod MODULUS" obtinem :
PK(B) ** SK(A) = PK(A) ** SK(B)
Înlocuind PK(B) si PK(A) conform formulelor de mai sus ajungem la următoarea formă:
( BASE ** SK(B) ) ** SK(A) = ( BASE ** SK(A) ) ** SK(B)
ceea ce este echivalent cu:
BASE ** ( SK(B) * SK(A)) = BASE ** (SK(A) * SK(B) )
Cheia comună CK(A, B) nu este utilizată pentru a cripta "stampila de timp" folosită de protocol. Ea este utilizată doar pentru a cripta o cheie de conversatie ce va fi folosită la criptarea "stampilei de timp". Motivul este următorul: "cheia comună trebuie folosită cât mai putin " pentru a se elimina posibilitătile de spargere" ale acesteia.
Cheia de conversatie este o cheie DES cu lungimea de 56 biti în timp ce cheia comună are lungimea de 192 biti.
Este interesant modul în care s-a redus dimensiunea de la 192 de biti la numai 56 biti. Astfel din mijlocul sirului de 192 de biti s-au extras 8 octeti iar la fiecare octet din acestia se atasează un bit de paritate rezultând 56 de biti.
În continuare în toate operatiile care necesită criptare se va folosi această cheie de conversatie. Aceasta este pasată serverului de către client în cadrul primului apel RPC.
Clientul si serverul trebuie să aibă aceleasi notiuni despre timpul curent deoarece timpul este esential pentru toate tranzactiile pe care le realizează. Dacă sincronizarea timpului nu poate fi garantată de retea atunci clientul trebuie să afle timpul serverului înainte de începerea conversatiei.
Modul în care serverul determină dacă "stampila de timp " a clientului este validă câteodată este complicat. Pentru orice tranzactie cu exceptia primei tranzactii serverul verifică două lucruri:
1. dacă "stampila de timp" este mai mare decât una venită anterior de la acelasi client;
2. dacă "stampila de timp" nu a expirat.
O "stampilă de timp" expiră în momentul în care timpul serverului este mai mare decât suma dintre "stampila de timp" a clientului si "fereastra" acestuia. O "fereastră" este un număr pe care clientul îl pasează serverului (numărul este criptat) în cadrul primei tranzactii. Acestă "fereastră" reprezintă de fapt durata creditului clientului, bineînteles totul fiind privit prin prisma timpului.
Clientul trebuie să testeze câmpul de verificare întors de server pentru a fi sigur că este legitimat (evident pentru urmatoarele tranzactii). Serverul trimite clientului o "stampilă de timp" criptată ce are o valoare mai mică cu o secundă decât cea trimisă de client. Dacă clientul primeste ceva diferit atunci va rejecta acest mesaj.
Datorită acestui mecamism cu "stampile de timp" destul de bine pus la punct, protocolul RPC prezintă o mare fiabilitate in timp.