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 consta din doua parti: corpul mesajului si header-e. Header-ele
formeaza o colectie de perechi camp/valoare, structurate conform RFC 822,
pe cand corpul mesajului este structurat conform MIME. d2t17tf
MOSS (MIME Object Security Services) se bazeaza, in cea mai mare parte,
pe protocolul PEM, definit in RFC 1421. MOSS este un standard prin care
se executa servicii de semnatura digitala si criptare pentru obiecte MIME. Serviciile
sunt oferite prin folosirea criptografiei capat la capat (end-to-end), intre
expeditor si destinatar, la nivel aplicatie. El este mult asemanator standardului
PEM descris anterior.
3.1 Serviciul MOSS de semnatura digitala
Folosirea unui serviciu de semnatura digitala MOSS presupune sa se dispuna
de urmatoarele componente:
- datele pentru semnat;
- cheia secreta a expeditorului;
Semnatura digitala este creata prin aplicarea unei functii hash asupra datelor
ce se doresc a fi transmise si criptarea valorii obtinute cu cheia secreta a
expeditorului. Serviciul de semnatura digitala MOSS se aplica asipracorpului
obiectului MIME. Urmatoarea secventa de operatii reprzinta algoritmul de aplicare
a unei semnaturi digitale. a) corpul obiectului MIME trebuie adus in forma canonica, b) se genereaza semnatura digitala si informatiile de control, c) se includ informatiile de control in tipurile corespunzatoare din continutul
MIME; d) 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: a) Canonicitatea -; corpul obiectului MIME -; trebuie convertit intr-o
forma canonica, reprezentata unic si neambigua, atat pentru expeditor,
cat si pentru destinatar. Transformarea intr-o forma canonica se
face in doi pasi:
- conversia corpului MIME intr-o forma neambigua, reprezentativa pentru
cele mai multe calculatoare gazda;
- convertirea delimitatoarelor de linii intr-o reprezentare unica si neambigua.
Reprezentarea aleasa pentru indeplinirea primului pas este de 7 biti.
Cel mai semnifcativ bit din fiecare octet de date trebuie sa fie 0. In cadrul
acestui pas, daca se vor codifica corespunzator pentru transferul continutului
si se va adauga 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 canonica, se
face inlocuirea delimitatorilor de linii locali cu secventa de caractere
“<CR> <LF>”. Conversia acestor delimitatori este necesara
doar pentru a nu apare erori in cazul calculului semnaturii digitale.
Expeditorul trebuie sa faca mai intai conversia delimitatorilor
si apoi saa calculeze semnatura digitala, insa trebuie sa transfere datele
fara conversia delimitatorilor. Similar, destinatarul va aplica mai intai
conversia delimitatorilor si apoi va calcula semnatura digitala. b) Informatiile de control pentru semnatura digitala -; informatiile de
control genrate de serviciul de semnatura digitala vor cuprinde header-ele si
semnatura propriu-zisa, care nu este altceva decat un numar. Fiecare header
si valoarea sa corespunzatoare generata de serviciul de semnatura digitala trebuie
sa incapa pe o singura linie.
Setul complet de header-e este urmatorul:
- Version: indica versiunea protocolului MOSS;
- Originator-ID: contine identificatorul proprietarului cheii secrete folosite
la crearea semnaturii digitale si a cheii publice corespunzatoare, ce va fi
folosita pentru verificarea semnaturii;
- MIC-Info: contine identificatorul algoritmului de hash, identificatorul algoritmului
de semnare si valoarea semnaturii digitale (semnatura propriu-zisa).
Fiecare apel al serviciului de semnatura digitala poate crea un singur header-Version
si cel putin o pereche de header-e Originator-ID - MIC-Info. Ultimele doua header-e
vor fi generate intotdeauna perechi, pentru toti destinatarii, iar ordine
este indicata mai sus.
Tipul-continut “application/moss-signature” cuprinde semnatura datelor
din corpul MIME si alte informatii de control necesare la verificarea semnaturii.
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 publica emitator
Mic-Info: RSA-MD5, RSA, Semnatura propriu-zisa
--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 data
in RFC 822. Setul complet de header-e generate de serviciul de criptare
este urmatorul:
- DEK-info: indica 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 doua valori -; identificatorul algoritmului de criptare
a cheii cu care au fost cifrate datele si valoarea criptata, cu cheia publica
a destinatarului, a cheii folosite la criptarea datelor.
Fiecare apel al serviciului de criptare creeaza 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>a“,”<dekparameters>i
CRLF
<recipasymflds>::= <recipid> <asymkeyinfo>
<recipid>::= “Recipient-ID:” <id> CRLF
<asymkeyinfo>::= “Key-Info””:”<ikalgid>””,”<asymencdek>
CRLF
De exemplu, un obiect MIME, criptat dupa standardul MOSS, arata astfel:
-- Encrypted Message
Content-Type: “application/moss-keys”
Version: 5
Dek-Info: DES-CBC, Informatii de DEK
Recipient-ID: Informatii de identificare cheie publica destinatar
Key-Info: RSA, Cheia de sesiune criptata
-- 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 leaga fiecare cheie publica de un nume. Acesta
reprezinta numele prin care este identificat proprietarul acelei chei. In
standardul MOSS, un utilizator nu trebuie sa aiba un certificat. Orice serviciu
MOSS impune ca utilizatorul sa cel putin o pereche de chei cheie-publica/cheie-secreta.
MOSS cere serviciilor de semnatura digitala si de criptare sa emita header-ul
potrivit Originator-ID, respectiv header-ul Recipient-ID. O valoare posibila
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 aleasa
si declarata 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 pastra compatibilitatea cu PEM). In cazul
in care un utilizator are mai multe chei publice si doreste sa foloseasca
acelasi nume pentru toate, atunci mai este necesar inca un parametru,
pentru a putea identifica cheia. De aceea, trebuie asignat un selector unic
fiecarei chei.