Standardul MOSS

sau securitatea în posta electronică multimedia

Un nou standard este pe punctul de a fi adoptat. El a primit denumirea de MOSS (MIME Object Security Services) si contine specificatiile pentru asigurarea securitătii mesajelor de postă electonică ce contin atât portiuni de text, cât si sunet sau imagine.

Monica Ioana Pietrosanu

Vulnerabilitatea postei electronice din punct de vedere al securitătii, datorată mediului nesigur pe care mesajele îl tranzitează în drumul lor de la expeditor la destinatar, reprezintă una din problemele actuale ale comunicatiei în retelele de calculatoare. În ultimii ani s-au gasit o serie de solutii la această problemă, unele fiind chiar adoptate ca standarde, altele fiind încă obiectul unor largi dezbateri în cercurile stiintifice si grupurile de lucru ce se ocupă cu aceasta.

În suplimentul numărului 29 al PC Report-ului s-a făcut prezentarea postei electronice cu facilităti de securitate sporită. Standardul pentru acest tip de serviciu electronic, referit sub numele de PEM (Privacy Enhanced Mail), functionează deja ca standard de facto în Internet încă de la începutul lui 1993. Dar PEM-ul asigură facilităti de securitate doar pentru mesajele textuale. Este firesc să se dorească si în posta cu facilităti multimedia (MIME - Multipurpose Internet Mail Extensions) asigurarea unei securităti sporite a mesajelor transmise sau receptionate.

Desi încă în stadiul de Internet Draft, standardul pentru integrarea capabilitătilor PEM cu cele multimedia (MIME) se pare că a ajuns la ultima versiune (a 8-a!) înaintea adoptării sale ca standard de facto în Internet. El este elaborat de un colectiv din cadrul IETF (Internet Engineering Task Force), numit Privacy-Enhanced Electronic Mail Working Group-PEMWG care a elaborat si standardul pentru PEM. Documentul contine specificatiile pentru MIME Object Security Services (MOSS), un protocol care utilizează framework-uri de tipul multipart/signed si multipart/encrypted pentru aplicarea semnăturii digitale si serviciilor de criptare asupra obiectelor MIME. În continuare vom încerca o prezentare a noului standard din punctul de vedere al serviciilor oferite si al noutătilor pe care le aduce în serviciile de postă electronică. Termeni ca multipart, signed, encrypted si content , specifici standardului MIME vor fi explicitati în mod corespunzător.

Terminologie

Pentru cei mai putin familiarizati cu aceste notiuni, precizăm în primul rând că Internet Draft-urile sunt documente de lucru ale IETF (organismul administrativ al Internet SOCiety - ISOC - însărcinat cu dezvoltarea specificatiilor pentru standarde) si working group-urilor subordonate acestuia. Aceste documente, odată lansate în Internet, sunt valabile pe o perioadă de maximum sase luni, în această perioadă ele fiind dezbătute, modificate si actualizate în cadrul grupurilor de lucru respective. Discutiile se poartă atât direct cât si prin listele de mail (mailing lists) si grupurile de news dedicate temei respective. De exemplu, lista de mail prin care s-au dezbătut problemele referitoare la MOSS a fost pem-dev@tis.com (PEM developers mailing list).

Punctul final spre care tinde un astfel de document este adoptarea lui ca standard de către IAB (Internet Architecture Board) si trecerea sa în categoria RFC-urilor (Request For Comments).

Internet Draft-ul referitor la MOSS a ajuns în acest stadiu final si este posibil ca, în momentul în care cititi acest articol, MOSS-ul să figureze deja în categoria standardelor proaspăt adoptate în Internet.

Protocolul MIME

MIME, acronim pentru "Multipurpose Internet Mail Extensions" este standardul pentru posta electronică cu facilităti multimedia (transmitere de voce, imagine prin postă).

MIME contine specificatiile pentru formatul corpurilor mesajelor de e-mail ce au mai multe părti (multipart messages) textuale (text pur) sau ne-textuale (sunet, imagine). Acest standard se găseste în RFC 1521 si a fost adoptat în septembrie 1993.

MIME standardizează modalitatea de creare a obiectelor multi-media structurate. Este proiectat pentru a se integra perfect într-un continut compatibil cu standardul RFC 822 (pentru formatul mesajelor de postă electronică) dar nu necesită neapărat un astfel de context. Din acest motiv el poate fi folosit si pentru alte medii, cum ar fi Web-ul.

Un mesaj de postă electronică cu facilităti multimedia din Internet este alcătuit din două părti: header-ele si corpul. Header-ele formează o colectie de perechi câmp/valoare structurate în concordantă cu RFC 822, în timp ce corpul este definit în concordantă cu standardul MIME.

MIME nu furnizează servicii de securitate pentru mesaje. Cu toate acestea, un agent MIME poate include suport atât pentru încapsularea mesajelor de postă multimedia cât si pentru un mecanism de interactiune cu un protocol de securizare a acestora.

Mesajele de postă electronică ce respectă standardul MIME se împart, după tipul continutului lor, în două categorii :

Integrarea serviciilor de securitate cu cele MIME s-a făcut prin introducerea a două subtipuri de securitate în cadrul tipului de continut multipart pentru mesajele MIME. Aceste două subtipuri sunt: signed si encrypted. În fiecare din cele două subtipuri de mesaje mentionate există exact două părti în corpul mesajului ce reflectă tipul: una ce contine datele protejate si alta ce contine informatia de control.

Tipul multipart/signed al continutului unui mesaj (tipul este mentionat în câmpul Content-Type din header-ul mesajului MIME) specifică faptul că mesajul suportă autentificare prin semnătură digitală. Informatia de control se găseste în a doua din cele două părti ale mesajului mentionate mai sus.

Tipul continutului unui mesaj (multipart/encrypted) specifică faptul că datelor li s-a aplicat serviciul de confidentialitate prin criptare. Pentru acest tip, informatia de control este continută în prima din cele două părti ale mesajului mentionate mai sus.

Protocolul PEM

PEM, acronim pentru Privacy Enhanced Mail, este un standard ce defineste procedurile de criptare si autentificare pentru mesajele de postă textuale folosind un mecanism de management al cheilor bazat pe certificate. Un certificat este o structură de date atribuită unui utilizator de către o autoritate de certificare. El contine următoarele informatii :

Certificatul în PEM este o dovadă a valabilitătii unei chei publice.

Standardul este continut în RFC 1421 - 1424 si a fost adoptat în 1993. Specificatiile sale includ câteva caracteristici ce sunt mai usor si mai natural suportate de către MIME, de exemplu operatia de codificare a mesajului pentru transfer si serviciile suport specificate de RFC 1424.

Succesiunea transformărilor efectuate asupra unui mesaj de către un filtru ce functionează în conformitate cu standardul PEM constă în: aducerea mesajului la o formă canonică, calculul digest-ului, criptarea mesajului (optională), si codificarea criptogramei (mesajului criptat) în formă tipăribilă. O parte din aceste transformări se regăsesc si în standardul pentru MOSS, fiind însă adaptate si extinse în functie de contextul respectiv.

Standardul este limitat prin aceea că prevede aplicarea serviciilor de securitate doar mesajelor text. După cum am spus, acest standard si serviciile de securite ce le asigură au fost detaliate în PC Report nr. 29 (supliment).

În caseta alăturată sunt prezentate câteva din cele mai importante implementări ale PEM-ului existente în lume la ora actuală. Lista a fost alcătuită de David Balenson (Trusted Information Systems -5 decembrie 1994) si actualizată de autoare.

Protocolul MOSS este un descendent direct din protocolul PEM si este bazat în mare parte pe acesta, asa cum este el descris în RFC 1421. Multe din caracteristicile PEM-ului si multe din specificatiile acestuia sunt incluse în MOSS.

O comparatie între PEM si MOSS este făcută în finalul articolului.

Folosirea serviciilor MOSS

Pentru a putea folosi serviciile MOSS, un utilizator (fie el om sau aplicatie) trebuie să posede cel putin o pereche de chei. O astfel de pereche este formată dintr-o cheie publică si una secretă. Cheia publică trebuie să fie făcută disponibilă pentru a putea fi cunoscută de ceilalti utilizatori cu care se doreste realizarea unei comunicatii securizate. Cheia secretă (privată) nu trebuie dezvăluită niciunui alt utilizator.

Cheia privată a originatorului unui mesaj este folosită pentru semnarea digitală a obiectelor MIME (obiectele sunt părtile textuale sau ne-textuale din mesajul MIME repectiv); pentru verificarea semnăturii digitale, recipientul trebuie să folosească cheia publică a originatorului.

În acelasi timp, cheia publică a recipientului unui mesaj este folosită pentru criptarea DEK-ului (Data Encryption Key). DEK-ul este cheia folosită pentru criptarea unui obiect MIME. Operatia aceasta mai este numită în unele lucrări de specialitate si anveloparea cheii. La receptie, recipientul trebuie să folosească cheia sa secretă pentru decriptarea cheii pentru ca apoi, folosind această cheie să poată decripta continutul obiectului MIME respectiv.

Atâta vreme cât cheile secrete nu sunt compromise, adică nu sunt accesibile decât utilizatorului căruia i-au fost asignate, recipientul mesajului semnat digital va sti de către cine a fost trimis mesajul iar originatorul unui mesaj cifrat va putea fi sigur că doar recipientul dorit este capabil să-l citească.

Cheile publice trebuie protejate de orice modificare ce poate fi efectuată asupra lor de către persoane neautorizate.

Aplicarea serviciilor MOSS

Serviciul de semnătură digitală. Aplicarea serviciului MOSS de semnătură digitală necesită urmatoarele componente:

(1) Datele ce trebuie semnate

(2) Cheia secretă a originatorului

Semnătura digitală este creată prin generarea unui rezumat (digest) al mesajului folosind o functie de hash iar apoi criptând acest rezumat cu cheia secretă a originatorului. Semnătura digitală, câteva informatii auxiliare (ce vor fi descrise în continuare) si datele sunt apoi încorporate în corpul mesajului multipart/signed. În final, corpul multipart/ signed poate fi transferat recipientului sau procesat mai departe (de exemplu, poate fi criptat).

Serviciul MOSS de semnătură digitală este aplicat obiectelor MIME, mai precis corpului acestora. Corpul MIME al unui obiect este creat în conformitate cu o conventie locală de reprezentare (ce depinde de caracteristicile statiei pe care a fost creat: set de caractere, caracteristici de reprezentare pe statia respectivă a imaginilor si sunetelor, etc). iar apoi acest corp este disponibilizat pentru serviciul de semnătură digitală.

Aplicarea acestui serviciu presupune parcurgerea următoarei secvente de pasi :

Pasul 1 Corpul mesajului ce va fi semnat trebuie canonizat: el va fi convertit la o formă canonică unic si neambiguu reprezentabilă cel putin în mediul în care semnătura digitală este creată si în mediul în care aceasta va fi verificată (adică mediile originatorului si recipientului). Dacă forma canonică este reprezentabilă pe mai multe host-uri diferite, atunci datele semnate pot fi transmise mai departe (forwarded) de recipienti spre alti recipienti aditionali care vor fi de asemenea capabili să verifice semnătura originală. Acest serviciu este numit autentificare transmisibilă (forwardable authentication).

Faza de canonizare este un proces în doi pasi. În primul rând corpul mesajului trebuie convertit la o formă care să fie neambiguu reprezentabilă pe cât mai multe hosturi. În al doilea rând corpul trebuie să aibă delimitatorii de linie convertiti la o unică reprezentare (în cazul în care corpul contine texte).

Reprezentarea aleasă pentru a satisface primul pas este cea numită 7bit (cel mai semnificativ bit al fiecărui octet de date ce va fi semnat trebuie să fie 0) si este descrisă in standardul MIME. O parte a corpului MIME este formată din două părti : header-ele si continutul. Deoarece header-ele sunt deja în reprezentarea 7bit, acest pas nu necesită schimbarea header-elor. Acest pas necesită însă ca, în cazul în care continutul nu este deja în reprezentare 7bit, el să fie codificat cu unul din mecanismele de codificare specificate de standardul MIME (ex.: quoted-printable sau base64) iar la mesaj să fie adăugat un header Content-Transfer-Encoding, în care să se specifice mecanismul de codificare folosit.

Pasul 2 : Se generează semnătura digitală si alte informatii de control

Semnătură digitală este ea însăsi o informatie de control. Sintaxa informatiei de control este aceeasi cu a unui set de header-e RFC 822 cu exceptia că strîngerea la un loc a valorilor header-elor în continuarea liniilor este explicit interzisă. Fiecare header si pereche de valori generate prin serviciul de semnătură digitală trebuie să fie iesirea unei singure linii. Header-ele generate prin serviciul de semnătură digitală sunt următoarele :

Version:

indică ce versiune de protocolol MOSS reprezintă header-ele rămase

Originator-ID:

indică cheia secretă folosită pentru crearea semnăturii digitale si cheia publică corespunzătoare ce trebuie utilizată pentru a verifica semnătura.

MIC-Info:

contine valoarea semnăturii digitale.

Fiecare invocare a serviciului de semnătură digitală trebuie să emită exact un header Version si cel putin o pereche de header-e Originator-ID si MIC-Info, în această ordine. Standardul permite originatorului să genereze semnături multiple ale datelor, folosind chiar diferiti algoritmi pentru aceste semnături si să le includă pe toate în informatia de control din mesaj.

Pasul 3 : Întegrarea informatiei de control în tipul corespunzător de continut MIME

În cea de-a doua parte a corpului unui mesaj multipart/signed încapsulat se aplică eticheta "application/moss-signature". Se includ de asemenea atât algoritmul folosit pentru generarea semnăturii cât si semnătura.

Pasul 4 : Partea din corp corespunzătoare informatiei de control si cea corespunzătoare datelor trebuie integrate în mesajul de tipul multipart/signed.

În urma acestui pas, un continut de tipul multipart/signed cu protocolul MOSS trebuie să arate după cum urmează:

Content-Type: multipart/signed; protocol="application/moss-signature"; 
micalg="rsa-md5"; boundary="Signed Message" 
-Signed Message 
Content-Type: text/plain 
Aici este un exemplu de text. 
-Signed Message 
Content-Type: application/moss-signature 
Version: 5 
Originator-ID: ID-INFORMATION 
MIC-Info: RSA-MD5,RSA,SIGNATURE-INFORMATION 
-Signed Message- 

unde ID-INFORMATION si SIGNATURE-INFORMATION simbolizează informatia ce ar trebui să apară într-un corp de mesaj real.

Serviciul de criptare. Aplicarea serviciului MOSS de criptare necesită următoarele componente :

(1) Datele ce trebuie criptate

(2) O cheie de criptare a datelor (DEK)

(3) Cheia publică a recipientului

Originatorul crează o cheie de criptare a datelor (DEK) si criptează datele folosind această cheie. Cheia publică a recipientului este folosită pentru criptarea cheii de criptare a datelor. Datele criptate si câteva informatii auxiliare sunt apoi încorporate în corpul mesajului multipart/ encrypted care, în continuare este fie transmis recipientului, fie procesat mai departe (de exemplu, poate fi semnat).

Aplicarea serviciului MOSS de criptare presupune executarea următoarei secvente de actiuni:

Pasul 1 : Partea corpului ce trebuie criptată trebuie să fie în formă canonică MIME.

Pasul 2 : Generarea cheii de criptare a datelor si a altor informatii de control.

În acest pas originatorul trebuie în primul rând să regăsească cheia publică a recipientului. Această regăsire poate fi făcută folosindu-se o bază de date locală sau un serviciu la distantă. Folosind această cheie originatorul criptează mesajul cu cifrul bloc de criptare simetrică DES-CBC.

Pasul 3 : Informatia de control trebuie încadrată într-un tip de continut MIME corespunzător

Pasul 4 : Partea din corp corespunzătoare informatiei de control si cea corespunzătoare datelor criptate trebuie integrate într-un tip corespunzător de continut multipart/encrypted.

În urma acestui pas, un continut de tipul multipart/encrypted are următoarea formă:

Content-Type: multipart/encrypted; protocol="application/moss-keys"; 
boundary="Encrypted Message" 
-Encrypted Message 
Content-Type: application/moss-keys 
Version: 5 
DEK-Info: DES-CBC,DEK-INFORMATION 
Recipient-ID: ID-INFORMATION 
Key-Info: RSA,KEY-INFORMATION 
-Encrypted Message 
Content-Type: application/octet-stream 
ENCRYPTED-DATA 
-Encrypted Message- 

unde DEK-INFORMATION, ID-INFORMATION, si KEY-INFORMATION simbolizează informatia ce ar trebui să se găsească în acea parte a corpului în cazul unui mesaj real.

Exemple

Mesajul original pregătit pentru a i se aplica protectia

Următorului mesaj i se vor aplica serviciile de protectie.

To: Ned Freed <ned@innosoft.com> 
Subject: Hi Ned! 
How do you like the new MOSS? 
Jim 

Semnarea Textului Mesajului Original

Când textul mesajului original este semnat, el va arăta ca mai jos. Liniile cu un ampersand '&' sunt semnate digital signed (de observat folosirea identificatorului pentru cheia publică cu identificatorul pentru numele de email inclus pe liniile marcate cu un asterisc '*')

To: Ned Freed <ned@innosoft.com> 
Subject: Hi Ned! 
MIME-Version: 1.0 
Content-Type: multipart/signed; protocol="application/moss-signature"; 
micalg="rsa-md5"; boundary="Signed Boundary" 
-Signed Boundary 
& Content-Type: text/plain; charset="us-ascii" 
& Content-ID: <21436.785186814.2@tis.com> 
& 
& How do you like the new MOSS? 
& 
& Jim 
-Signed Boundary 
Content-Type: application/moss-signature 
Content-ID: <21436.785186814.1@tis.com> 
Content-Transfer-Encoding: quoted-printable 
Version: 5 
* Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1= 
* fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghG= 
* dhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com 
MIC-Info: RSA-MD5,RSA,PnEvyFV3sSyTSiGh/HFgWUIFa22jbHoTrFIMVERfMZXUKzFs= 
HbmKtIowJlJR56OoImo+t7WjRfzpMH7MOKgPgzRnTwk0T5dOcP/lfbsOVJjleV7vTe9yoN= 
p2P8mi/hs7 
-Signed Boundary- 

Semnarea Header-elor si Textului Mesajului Original

Dacă, în schimb, alegem să protejăm header-ele cu textul mesajului original, acesta va arăta în felul următor (liniile marcate cu un ampersand) :

To: Ned Freed <ned@innosoft.com> 
Subject: Hi Ned! 
MIME-Version: 1.0 
Content-Type: multipart/signed; protocol="application/moss-signature"; 
micalg="rsa-md5"; boundary="Signed Boundary" 
 
-Signed Boundary 
& Content-Type: message/rfc822 
& Content-ID: <21468.785187044.2@tis.com> 
& 
& To: Ned Freed <ned@innosoft.com> 
& Subject:Hi Ned! 
& 
& 
& How do you like the new MOSS? 
& 
& Jim 
 
-Signed Boundary 
Content-Type: application/moss-signature 
Content-ID: <21468.785187044.1@tis.com> 
Content-Transfer-Encoding: quoted-printable 
 
Version: 5 
Originator-ID: PK,MHkwCgYEVQgBAQICAwADawAwaAJhAMAHQ45ywA357G4fqQ61aoC1= 
fO6BekJmG4475mJkwGIUxvDkwuxe/EFdPkXDGBxzdGrW1iuh5K8kl8KRGJ9wh1HU4TrghG= 
dhn0Lw8gG67Dmb5cBhY9DGwq0CDnrpKZV3cQIDAQAB,EN,2,galvin@tis.com 
MIC-Info: RSA-MD5,RSA,ctbDBgkYtFW1sisb5w4/Y/p94LftgQ0IrEn3d6WTwjfxFBvA= 
ceVWfawsZPLijVKZUYtbIqJmjKtzTJlagBawfA/KhUsvTZdR6Dj+4Gd8dBBwMKvqMKTHAU= 
xGXYxwNdbK 
 
-Signed Boundary- 

Criptarea Textului unui Messaj

Dacă am optat pentru criptarea textului următorului mesaj, el va arăta ca mai jos, unde liniile ce se vor cripta sunt marcate asterisk '*':

To: Jim Galvin <galvin@tis.com> 
Subject: an encrypted message 
 
* How do you like the new MOSS? 
* 
* Jim 
mesajul trebuie să arate după cum urmează (de notat folosirea identificatorului numelui de email pe linia marcată cu un asterisk '*'): 
To: Jim Galvin <galvin@tis.com> 
Subject: an encrypted message 
MIME-Version: 1.0 
Content-Type: multipart/encrypted; protocol="application/moss-keys"; 
boundary="Encrypted Boundary" 
 
-Encrypted Boundary 
Content-Type: application/moss-keys 
Content-ID: <21535.785187667.1@tis.com> 
Content-Transfer-Encoding: quoted-printable 
 
Version: 5 
DEK-Info: DES-CBC,D488AAAE271C8159 
* Recipient-ID: EN,2,galvin@tis.com 
Key-Info: RSA,ISbC3IR01BrYq2rp493X+Dt7WrVq3V3/U/YXbxOTY5cmiy1/7NvSqqXS= 
K/WZq05lN99RDUQhdNxXI64ePAbFWQ6RGoiCrRs+Dc95oQh7EFEPoT9P6jyzcV1NzZVwfp= 
+u 
 
-Encrypted Boundary 
Content-Type: application/octet-stream 
Content-Transfer-Encoding: base64 
 
AfR1WSeyLhy5AtcX0ktUVlbFC1vvcoCjYWy/yYjVj48eqzUVvGTGMsV6MdlynUd4jcJgRnQI 
QvIxm2VRgH8W8MkAlul+RWGu7jnxjp0sNsU562+RZr0f4F3K3n4wonUUP265UvvMj23RSTgu 
Z/nl/OxnFM6SzDgV39V/i/RofqI= 
 
-Encrypted Boundary- 

Protejarea Continutului Audio

În afară de text, serviciile MOSS prezentate mai înainte pot proteja si părti din corp arbitrare,cum ar fi, de exemplu, următoarea parte audio de corp :

Content-Type: audio/basic 
AUDIO DATA HERE 

a) Semnarea Continutului Audio

Când un continut audio este semnat, el trebuie să arate după cum urmează, unde liniile cu un ampersand '&' sunt semnate digital : 
Content-Type: multipart/signed; protocol="application/moss-signature"; 
micalg="rsa-md5"; boundary="Signed Boundary" 
-Signed Boundary 
& Content-Type: audio/basic 
& Content-Transfer-Encoding: base64 
& 
& base64(AUDIO-DATA-HERE) 
-Signed Boundary 
Content-Type: application/moss-signature 
SIGNATURE-INFORMATION-HERE 
-Signed Boundary- 

unde AUDIO-DATA-HERE si SIGNATURE-INFORMATION-HERE sunt descriptori ai informatiei de continut ce ar trebui să apară într-o parte reală.

b) Criptarea Continutului Audio

Când este criptat, un continut audio trebuie să arate ca mai jos, unde liniile cu un ampersand '&' sunt criptate :

Content-Type: multipart/encrypted; protocol="application/moss-keys"; 
boundary="Encrypted Boundary" 
-Encrypted Boundary 
Content-Type: application/moss-keys 
KEY-INFORMATION-HERE 
-Encrypted Boundary 
Content-Type: application/octet-stream 
Content-Transfer-Encoding: base64 
& Content-Type: audio/basic 
& 
& base64(encrypted(AUDIO-DATA-HERE)) 
-Encrypted Boundary- 

unde KEY-INFORMATION-HERE si AUDIO-DATA-HERE sunt descriptori ai informatiei de continut ce ar trebui să apară într-o parte reală.

Ce aduce nou standardul MOSS ?

Folosirea protocolului MIME integrat cu servicii de securitate (MIME Object Security Services), pentru alcătuirea mesajelor de postă electronică, oferă câteva facilităti total noi:

(1) Este permisă protejarea unor tipuri arbitrare de continuturi, nu numai a unor corpuri de mesaje alcătuite în conformitate cu standardul RFC822.

(2) Este permis ca un mesaj să aibă în corpul său părti care să nu fie protejate.

(3) Este permis ca diferitele componente ale continutului unui mesaj multipart să fie protejate cu servicii diferite.

Folosirea unui agent utilizator (UA) ce suportă protocolul MIME face ca imbricarea, atât de complexă a părtilor protejate ale corpului unui mesaj, să devină mult mai usor de realizat. Aceasta permite o completă separare a serviciilor de securitate: serviciul pentru asigurarea confidentialitătii este complet separat de cel pentru semnătura digitală.

În plus, perechi diferite de chei pot fi folosite pentru diferitele servicii si ele pot fi protejate separat. Acest lucru este util din două motive. Primul ar fi acela că anumiti algoritmi de criptare cu chei publice nu suportă si semnături digitale si criptare; în acest caz ar fi necesare două perechi de chei. Al doilea motiv este ilustrat în următorul exemplu: un functionar al unei companii ar putea să aibă acces la cheia (secretă) de decriptare, dar să nu aibă acces la cheia (secretă) de semnare dându-i-se astfel companiei posibilitatea să decripteze, în caz de urgentă, mesajele adresate functionarului fără a da însă posibilitatea companiei să semneze mesaje în numele functionarului.

PEM vs. MOSS

În continuare vor fi prezentate câteva din caracteristicile prin care MOSS-ul diferă de PEM:

Concluzii

Posta pentru transmiterea mesajelor multimedia (grafice, hărti, înregistrări audio) a devenit o necesitate a comunicatiilor electronice din zilele noastre. Este din ce în ce mai este necesară folosirea acestui serviciu în transmiterea securizată a documentelor oficiale si a celor de importantă comercială.

Adoptarea acestui nou standard pentru posta electronică va da startul începerii dezvoltării de implementări MOSS-compatibile si va marca o schimbare în cadrul softului dezvoltat pentru posta electronică atât din punctul de vedere al problemelor de implementare ce se vor pune cât si al utilizării sale pentru efectuarea de tranzactii complexe în conditii mult mai sigure.

Casete Cifrurile Beale si Legislatia franceză în domeniul criptografiei.


(C) Copyright Computer Press Agora