STANDARDUL MOSS-MIME PENTRU SECURITATEA POSTEI ELECTRONICE CU OBIECTE MULTIMEDIA
Standardul MIME (Multiporpose Internet Mail Extensions) defineste formatul continutului unui mesaj e-mail pe Internet, mesaj care poate avea orice format, nu numai cel de text. El constǎ din douǎ pǎrti: corpul mesajului si header-e. Header-ele formeazǎ o colectie de perechi camp/valoare, structurate conform RFC 822, pe cand corpul mesajului este structurat conform MIME. 46531ecg87zpv5u MOSS (MIME Object Security Services) se bazeazǎ, in cea mai mare parte, pe protocolul PEM, definit in RFC 1421. MOSS este un standard prin care se executǎ servicii de semnǎturǎ digitalǎ si criptare pentru obiecte MIME. Serviciile sunt oferite prin folosirea criptografiei capǎt la capǎt (end-to-end), intre expeditor si destinatar, la nivel aplicatie. El este mult asemǎnǎtor standardului PEM descris anterior. 3.1 Serviciul MOSS de semnatura digitala Folosirea unui serviciu de semnǎturǎ digitalǎ MOSS presupune sǎ se dispunǎ de urmǎtoarele componente: cp531e6487zppv datele pentru semnat; cheia secretǎ a expeditorului; Semnǎtura digitalǎ este creatǎ prin aplicarea unei functii hash asupra datelor ce se doresc a fi transmise si criptarea valorii obtinute cu cheia secretǎ a expeditorului. Serviciul de semnatura digitala MOSS se aplica asipracorpului obiectului MIME. Urmatoarea secventa de operatii reprzinta algoritmul de aplicare a unei semnaturi digitale. corpul obiectului MIME trebuie adus ]n forma canonica, se genereaza semnatura digitala si informatiile de control, se includ informatiile de control in tipurile corespunzǎtoare din continutul MIME; partea de informatii de control si partea de date din corpul obiectului MIME include in tipul-continut “multipart/signed”. Fiecare din acesti pasi este descris in continuare: Canonicitatea – corpul obiectului MIME – trebuie convertit intr-o formǎ canonicǎ, reprezentatǎ unic si neambiguǎ, atat pentru expeditor, cat si pentru destinatar. Transformarea intr-o formǎ canonicǎ se face in doi pasi: conversia corpului MIME intr-o formǎ neambiguǎ, reprezentativǎ pentru cele mai multe calculatoare gazdǎ; convertirea delimitatoarelor de linii intr-o reprezentare unicǎ si neambiguǎ. Reprezentarea aleasǎ pentru indeplinirea primului pas este de 7 biti. Cel mai semnifcativ bit din fiecare octet de date trebuie sǎ fie 0. In cadrul acestui pas, dacǎ se vor codifica corespunzǎtor pentru transferul continutului si se va adǎuga header-ul Content-Transfer-Encoding. Secventa de caractere desemnate a reprezenta un delimitator de linii este “<CR> <LF>”. In al doilea pasal conversiei la forma canonicǎ, se face inlocuirea delimitatorilor de linii locali cu secventa de caractere “<CR> <LF>”. Conversia acestor delimitatori este necesarǎ doar pentru a nu apare erori in cazul calculului semnǎturii digitale. Expeditorul trebuie sǎ facǎ mai intai conversia delimitatorilor si apoi sǎa calculeze semnǎtura digitalǎ, insǎ trebuie sǎ transfere datele fǎrǎ conversia delimitatorilor. Similar, destinatarul va aplica mai intai conversia delimitatorilor si apoi va calcula semnǎtura digitalǎ. Informatiile de control pentru semnǎtura digitalǎ – informatiile de control genrate de serviciul de semnǎturǎ digitalǎ vor cuprinde header-ele si semnǎtura propriu-zisǎ, care nu este altceva decat un numǎr. Fiecare header si valoarea sa corespunzǎtoare generatǎ de serviciul de semnǎturǎ digitalǎ trebuie sǎ incapǎ pe o singurǎ linie. Setul complet de header-e este urmǎtorul: Version: indicǎ versiunea protocolului MOSS; Originator-ID: contine identificatorul proprietarului cheii secrete folosite la crearea semnǎturii digitale si a cheii publice corespunzǎtoare, ce va fi folositǎ pentru verificarea semnǎturii; MIC-Info: contine identificatorul algoritmului de hash, identificatorul algoritmului de semnare si valoarea semnǎturii digitale (semnǎtura propriu-zisǎ). Fiecare apel al serviciului de semnǎturǎ digitalǎ poate crea un singur header-Version si cel putin o pereche de header-e Originator-ID - MIC-Info. Ultimele douǎ header-e vor fi generate intotdeauna perechi, pentru toti destinatarii, iar ordine este indicatǎ mai sus. Tipul-continut “application/moss-signature” cuprinde semnǎtura datelor din corpul MIME si alte informatii de control necesare la verificarea semnǎturii. Corpul unui “application/moss-signature” este construit astfel: Content-Type: “application/moss-signature” <mosssig>::= <version> (1*<origasymflds>) <version>::= “ Version: “ “ 5 “ CRLF <origasymflds>::= <origid> <micinfo> <origid>::= “ Originator-ID: “ <id> CRLF <micinfo>::= “Mic-Info:” <micalgid>”,”<ikalgid>”,”<asymsignmic> CRLF
De exemplu, un mesaj MOSS semnat are structura: --Signed Message Content-Type: “application/moss-signature”
Version: 5 Originator-ID: Informatie de identificare cheie publicǎ emitǎtor Mic-Info: RSA-MD5, RSA, Semnǎturǎ propriu-zisǎ --Signed Message 3.2 Serviciul MOSS de criptare Aplicarea serviciului de criptare va genera informatii de control care includ si pe cele de criptare a datelor. Sintaxa informatiilor de control este datǎ in RFC 822. Setul complet de header-e generate de serviciul de criptare este urmǎtorul: DEK-info: indicǎ algoritmul si modul de folosire a acestuia in criptarea datelor; Recipient-ID: permite identificarea cheii publice folosite la cifrarea cheii de sesiune cu care au fost criptate datele; Key-Info: contine douǎ valori – identificatorul algoritmului de criptare a cheii cu care au fost cifrate datele si valoarea criptatǎ, cu cheia publicǎ a destinatarului, a cheii folosite la criptarea datelor. Fiecare apel al serviciului de criptare creeazǎ un singur header Version, un singur header DEK-Info si cel putin o pereche de header-e Recipient-ID – Key-Info. Corpul unui tip application/moss-keys este construit ca mai jos: Content-Type: “application/moss-keys” <mosskeys>::= <version> <dekinfo> 1*<recipasymflds> <version>::= “ Version: “ “ 5 “ CRLF <dekinfo>::= “DEK-Info””:”<dekalgid>[“,”<dekparameters>] CRLF <recipasymflds>::= <recipid> <asymkeyinfo> <recipid>::= “Recipient-ID:” <id> CRLF <asymkeyinfo>::= “Key-Info””:”<ikalgid>””,”<asymencdek> CRLF De exemplu, un obiect MIME, criptat dupǎ standardul MOSS, aratǎ astfel: -- Encrypted Message Content-Type: “application/moss-keys” Version: 5 Dek-Info: DES-CBC, Informatii de DEK Recipient-ID: Informatii de identificare cheie publicǎ destinatar Key-Info: RSA, Cheia de sesiune criptatǎ
-- Encrypted Message Content-Type: “application/octet-stream”
Date cifrate -- Encrypted Message 3.3 Identificarea expeditorului, destinatarului si a cheilor acestora In specificatiile PEM, cheile publice trebuie incluse in certificate. Un certificat este un obiect care leagǎ fiecare cheie publicǎ de un nume. Acesta reprezintǎ numele prin care este identificat proprietarul acelei chei. In standardul MOSS, un utilizator nu trebuie sǎ aibǎ un certificat. Orice serviciu MOSS impune ca utilizatorul sǎ cel putin o pereche de chei cheie-publicǎ/cheie-secretǎ. MOSS cere serviciilor de semnǎturǎ digitalǎ si de criptare sǎ emitǎ header-ul potrivit Originator-ID, respectiv header-ul Recipient-ID. O valoare posibilǎ pentru aceste header-e ar fi cheile publice ale ambilor participanti in comunicatie. In cadrul header-elor Originator-ID si Recipient-ID, MOSS defineste alti doi identificatori: forma numelui si selectorul cheii. Forma numelui este aleasǎ si declaratǎ de proprietarul perechii de chei. In documentul MOSS sunt specificate trei forme ale numelui: un sir arbitrar, adresa de e-mail si un nume distinct X500 (pentru a pǎstra compatibilitatea cu PEM). In cazul in care un utilizator are mai multe chei publice si doreste sǎ foloseascǎ acelasi nume pentru toate, atunci mai este necesar incǎ un parametru, pentru a putea identifica cheia. De aceea, trebuie asignat un selector unic fiecǎrei chei.
