Bezpieczenstwo poczty elektronicznej

Adam Zalcman

Spis tresci

1. Wprowadzenie do technik kryptograficznych

1.1. Szyfrowanie symetryczne

Kazdy algorytm szyfrujacy przyjmuje jako argumenty nie tylko tekst do zaszyfrowania ale rowniez pewna ustalona z gory i ukrywana w tajemnicy wartosc zwana kluczem. Podobnie algorytm deszyfrujacy przyjmuje oprocz kryptogramu wartosc klucza. W przypadku algorytmow szyfrowania symetrycznego ten sam klucz jest wykorzystywany przy szyfrowaniu i deszyfrowaniu.

Najwazniejszymi przykladami algorytmow symerycznych sa DES i jego odmiany (3DES, DESX), RC2, Blowfish.

1.2. Szyfrowanie asymetryczne

Szyfrowanie asymetryczne tym rozni sie od symetrycznego, ze klucz stosowany do szyfrowania K_E i klucz K_D do deszyfrowania sa rozne i z jednego nie da sie wyliczyc wartosci drugiego.

Najwazniejszym algorytmem szyfrowania asymetrycznego jest RSA.

1.3. Funkcje haszujace

Innym waznym narzedziem kryptograficznym sa funkcje haszujace. Funkcja haszujaca to taka funkcja H, ktora dla potencjalnie duzego (jako porcji informacji) argumentu oblicza jego hash, ktory jest znacznie mniejszy i ma te wlasnosc, ze dla danej wartosci h nie mozna znalezc takiego argumentu M, ze H(M)=h. Rowniez majac taki M₁, ze H(M₁)=h nie mozna znalezc drugiego takiego M₂<>M₁, ze H(M₂)=h.

Dwie najpopularniejsze obecnie funkcje haszujace to MD5, ktora dla wejscia dowolnych rozmiarow zwraca wynik o dlugosci 128 bitow oraz SHA-1, ktora dla dowolnego wejscia zwraca wynik dlugosci 160 bitow.

Funkcje haszujace wykorzystuje sie do sprawdzania czy to co podlegalo haszowaniu (kod programu, list, dokument) nie zostalo zmodyfikowane.

Oto przyklad obliczenia wartosci funkcji md5 dla pewnego tekstu przy pomocy komendy md5 dostepnej w niektorych UNIXach:

[jkowalski@vidmo]$ md5
To jest tekst, ktory jest chroniony przed modyfikacja za pomoca funkcji haszujacej MD5.
69d79e120d662bf3942b6240439bace4
[jkowalski@vidmo]$ 

1.4. Podpis elektroniczny

Podpis elektroniczny to wartosc dolaczana do jakiejs porcji informacji (programu komputerowego, e-maila, dokumentu, etc) zapewniajaca, ze jej autorem jest okreslona osoba (podpisujacy). Zanim ktos bedzie mogl podpisywac sie elektronicznie musi wygenerowac sobie pare kluczy (publiczny i prywatny) do szyfrowania asymetrycznego. Nastepnie musi zadbac o to aby wszystkie osoby, ktore beda zainteresowane weryfikacja jej podpisow znaly jej klucz publiczny oraz o to by nikt nie zdobyl dostepu do jej klucza prywatnego. Klucz prywatny bedzie wykorzystywany przy podpisywaniu, a publiczny przy weryfikacji podpisu.

Do tworzenia podpisow elektronicznych wykorzystuje sie wybrana funkcje haszujaca H oraz wybrany algorytm szyfrowania asymetrycznego D/E.

Tworzenie podpisu elektronicznego odbywa sie w nastepujacy sposob:

• Osoba chca umiescic podpis pod wiadomoscia M, oblicza H(M), gdzie H jest wybrana funkcja haszujaca.
• Wartosc h=H(M) jest szyfrowana przy uzyciu klucza prywatnego tej osoby.
• Uzyskana wartosc S=E_Kprv(h) jest dolaczana do M jako podpis elektroniczny.

Weryfikacja podpisu elektronicznego polega na wykonaniu nastepujacych czynnosci:

• Wartosc S przekazana jako podpis elektroniczny jest deszyfrowana przy pomocy znanego klucza publicznego osoby, ktora podaje sie za autora wiadomosci M.
• Obliczana jest wartosc funkcji haszujacej H dla przekazanej wiadomosci M.
• Porownywane sa dwie wartosci:
  1. Obliczona w pierwszym kroku h₁=D_Kpub(S).
  2. Obliczona w drugim kroku h₂=H(M).
  Jesli te dwie wartosci sa takie same oznacza to, ze osoba obliczjaca S (tj, podpisujaca M) uzyla tej samej wiadomosci M do obliczenia S, a to zapewnia, ze nikt nie zmodyfikowal wiadomosci. Ponadto nikt inny poza osoba znajaca K_prv nie mogl obliczyc S co gwarantuje, ze autorem podpisu jest osoba, ktorej klucz publiczny wykorzystano do weryfikacji podpisu.

1.5. Certyfikaty

Aby opisany w poprzednim punkcie protokol postepowania byl skuteczny musi istniec sposob na powiazanie osob z ich kluczami publicznymi. Sposob ten musi byc godny zaufania.

Jednym z rozwiazan problemu powiazania kluczy publicznych z osobami sa certyfikaty. Certyfikat jest niewielka porcja informacji, ktora zawiera opis osoby i jej klucz publiczny. Aby nie dopuscic do falszerstwa, certyfikat jest podpisywany elektronicznie przez inna osobe lub instytucje. Aby jednak zweryfikowac podpis pod certyfikatem danej osoby trzeba miec klucz publiczny tego kto podpisywal jej certyfikat. Ten klucz publiczny uzyskuje sie z jeszcze innego certyfikatu, ktory jest z kolei podpisany przy uzyciu klucza jeszcze innej organizacji. Caly ten zespol zaleznosci tworzy drzewo powiazan. Na samym szczycie tego drzewa znajduja sie organizacje zwane CA (ang. Certificate Authority), ktorych klucze publiczne sa powszechnie znane (chocby dlatego, ze sa z reguly wbudowywane lub dostarczane z oprogramowaniem, ktore bedzie korzystalo z certyfikatow, jak np. klient poczty elektronicznej czy przegladarka sieci Web).

1.6. X.509

Aby zapewnic kompatybilnosc oprogramowania pochodzacego od roznych producentow i mozliwosc wymiany certifatow pomiedzy roznymi programami strukture certyfikatow ustandaryzowano. Najpopularniejszym standardem certyfikatow jest X.509. Obecnie najnowsza wersja tego standardu jest 3.

Kazdy certyfikat X.509v3 musi zawierac nastepujace elementy:

• Wersje certyfikatu.
• Numer seryjny certyfikatu sluzacy do identyfikacji certyfikatu w zbiorze certyfikatow zystawionych przez dana organizacje/osobe.
• Algorytm asymetryczny i funkcja haszujaca wykorzystane do podpisania tego certyfikatu (np: rsa+md5, dsa+sha1).
• Nazwe osoby badz organizacji, ktora wystawila certyfikat. Nazwa ta musi miec strukture taka jak objekty katalogu X.500.
• Okres waznosci.
• Nazwe osoby badz organizacji, dla ktorej certyfikat zostal wystawiony.
• Klucz publiczny osoby badz organizacji, dla ktorej wystawiono certyfikat.
• Podpis elektroniczny osoby badz organizacji, ktora wystawila certyfikat.

1.7. Hasla jednorazowe

Za kazdym razem gdy haslo dajace dostep do jakiegos systemu jest wpisywane na klawiaturze komputera badz wysylane poprzez siec jest narazone na przechwycenie i pozniejsze wykorzystanie w tzw. replay attack polegajacym na wyslaniu do atakowanego systemu tej samej sekwencji bajtow jaka zostala wykorzystana prze uprawniona osobe.

Najskuteczniejszym sposobem ustrzezenia sie przed tego rodzaju atakiem jest uzycie hasel, ktorych waznosc konczy sie wraz z pierwszym ich zastosowaniem. Poniewaz jednak pamietanie wielu hasel dostepu jest problemem a ich zapisanie moze narazic system na niebezpieczenstwo wieksze niz w przypadku stosowania klasycznych hasel, stosuje sie hasla jednorazowe, ktore daja sie wyliczyc z pewnej innej dobrze strzezonej informacji zwanej dalej sekretem.

Hasla jednorazowe musza miec te wlasnosc, ze z n-tego nie da sie wyliczyc n+1-szego. Taka wlasnosc mozna uzyskac wykorzystujac funkcje haszujace. Obliczanie hasel jednorazowych wykonuje sie nastepujaco:

Widac, ze z i-tego hasla h_n-i+1 nie da sie wyliczyc hasla i+1-szego h_n-i, gdyz h_n-i+1=H(h_n-i), a funkcja H nie da sie odwrocic.

W praktyce zamiast liczb korzysta sie z generowanych z nich fraz tekstowych.

Oto jak wyglada poslugiwanie sie haslami jednorazowymi w praktyce:

• Zanim bedzie sie moglo uzywac hasel jednorazowych nalezy uzyc komendy opiepasswd(1) by wygenerowac hasla.

  [jkowalski@vidmo]$ opiepasswd -cfs vi1111
  Updating jkowalski:
  Only use this method from the console; NEVER from remote. If you are using
  telnet, xterm, or a dial-in, type ^C now or exit with no password.
  Then run opiepasswd without the -c parameter.
  Using MD5 to compute responses.
  Enter old secret pass phrase:
  Enter new secret pass phrase:
  Again new secret pass phrase:
  ID jkowalski OTP key is 499 vi1111
  SEEM SNOB DUD PIE WHOA RAYS
  [jkowalski@vidmo]$ cat /etc/opiekeys | grep jkowalski
  jkowalski 0499 vi1111           d8bc103f99efb39a  Jun 02,2005 19:31:17
  [jkowalski@vidmo]$ 
  

  Niewidoczny powyzej "secret pass phrase" to s z powyzszych rozwazan. Ciag szesciu angielskich wyrazow "SEEM SNOB DUD PIE WHOA RAYS" to haslo jednorazowe. Liczba 499 z pliku /etc/opiekeys to numer hasla. Po wykorzystaniu hasla "SEEM SNOB DUD PIE WHOA RAYS" zmniejszy sie ona na 498. Szesnastkowa liczba d8bc103f99efb39a to ostatnie uzyte haslo podane w postaci liczbowej. Ciag znakow vi1111 to tzw seed, ktory dodaje element losowosci przy wyborze hasla.
• W dowolnym momencie mozna sprawdzic ktore haslo bedzie wykorzystane przy nastepnym uwierzytelnianiu:

  [jkowalski@vidmo]$ opieinfo
  498 vi1111
  [jkowalski@vidmo]$ 
  

• Uzycie hasla jednorazowego polega na podaniu go zamiast zwyklego. Jesli system jest odpowiednio skonfigurowany to powinien sprawdzic jakie to haslo (odpowiedniej konfiguracji najlatwiej dokonac przy pomocy PAM). Do wyliczenia kolejnego hasla wykorzystuje sie komende opiekey.

  [jkowalski@vidmo]$ opiekey -f 498 vi1111
  Using the MD5 algorithm to compute response.
  Reminder: Don't use opiekey from telnet or dial-in sessions.
  Sorry, but you don't seem to be on the console or a secure terminal.
  Warning: Continuing could disclose your secret pass phrase to an attacker!
  Enter secret pass phrase:
  STAY COD TROD SHE VIE TOWN
  [jkowalski@vidmo]$
  

  Mozna obliczac od razu kilka hasel przy uzyciu opcji -n. Najlepiej obliczac hasla na urzadzeniu, do ktorego ma sie dostep bezposredni (aby uniknac koniecznosci logowania i mozliwosci podsluchania s), np. na telefonie komorkowym wyposazonym w odpowiednie oprogramowanie.

1.8. MAC

MAC (ang. Message Authentication Code) jest narzedziem pozwalajacym na zapewnienie integralnosci komunikatu. MAC otrzymuje sie jako wartosc dwuargumentowej funkcji jednokierunkowej (dajacej sie obliczac tylko w jedna strone) dla wartosci tajnego klucza k oraz wiadomosci M:

Do konstrukcji funkcji f wykorzystuje sie w praktyce funkcje haszujace.

1.9. HMAC

W RFC 2104 "HMAC: Keyed-Hashing for Message Authentication" opisana jest dwuargumentowa funkcja jednokierunkowa sluzaca do obliczania MAC zwana HMAC. Jest to w istocie schemat, na podstawie ktorego mozna tworzyc wiele roznych funkcji obliczajacych MAC (oczywiscie kazda z nich oblicza inny MAC dla tych samych danych: klucza i wiadomosci). By korzystac z HMAC nalezy wybrac pewna funkcje haszujaca H oraz klucz K. Argument kazdej funkcji haszujacej ma okreslony rozmiar w bajtach. Niech B bedzie rozmiarem argumentu dla H (jesli H=MD5 lub H=SHA-1 to B=64). Podobnie dla kazdej funkcji H okreslony jest rozmiar jej wartosci. Niech L bedzie rozmiarem wartosci zwracanych przez H (jesli H=MD5 to L=16, jesli H=SHA-1 to L=20). Klucz K powinien miec rozmiar B, a jesli jest krotszy nalezy uzupelnic go zerami do rozmiaru B.

2. Poczta elektroniczna

2.1. Protokol SMTP

• EHLO host
  Sluzy programom klienckim do przedstawienia sie serwerowi i inicjacji komunikacji. Jedyny wymagany argument powinien byc pelna kwalifikowana nazwa komputera, na ktorym dziala program klienta.
• MAIL FROM:<adres e-mail>
  Pozwala podac adres e-mailowy nadawcy. W pewnych przypadkach adres ten moze byc pusty.
• RCPT TO:<adres e-mail>
  Umozliwia podanie adresu odbiorcy.
• DATA
  Sluzy do przeslania tresci listu do serwera. Po podaniu tej komendy jesli wszystko poszlo dobrze serwer oczekuje na dane. Koniec listu jest sygnalizowany pojedyncza kropka w linii.
• QUIT
  Informuje serwer o zakonczeniu komunikacji.

Protokol SMTP przewiduje mozliwosc tworzenia rozszerzen (ang. extensions) do protokolu. Zazwyczaj maja one postac dodatkowych komend, ktore serwer moze zaakceptowac. Wszystkie rozszerzenia, ktore dany serwer rozumie musza zostac wymienione przez niego po komendzie EHLO.

Oto przykladowy dialog w protokole SMTP.

[jkowalski@vidmo]$ telnet elf.ii.uj.edu.pl 25
Trying 149.156.65.17...
Connected to elf.ii.uj.edu.pl.
Escape character is '^]'.
220 elf.ii.uj.edu.pl ESMTP (elf II UJ)
EHLO vidmo.net
250-elf.ii.uj.edu.pl
250-PIPELINING
250-SIZE 20000000
250-ETRN
250 8BITMIME
MAIL FROM:<jkowalski@vidmo.net>
250 Ok
RCPT TO:<jan.kowalski@ii.uj.edu.pl>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Tresc maila
.
250 Ok: queued as 668B71100096B
QUIT
221 Bye
Connection closed by foreign host.
[jkowalski@vidmo]$

2.2. SMTP relay

Z reguly serwer, z ktorym laczy sie program wysylajacy poczte jest serwerem, ktorego nazwa znajduje sie po '@' w adresie e-mail odbiorcy wiadomosci lub jesli po '@' jest nazwa domeny to ktorys z serwerow poczty dla tej domeny uzyskany z DNS z rekordu MX. W obu tych przypadkach skrzynka pocztowa odbiorcy znajduje sie na serwerze, z ktorym laczy sie klient. Nie zawsze musi jednak tak byc. Mozna polaczyc sie z w zasadzie dowolnym komputerem i prosic go o przeslanie e-maila na dowolny adres. W takiej sytuacji, jesli serwer przyjmie taka wiadomosc musi ja potem przekazac dalej w imieniu nadawcy. Sytuacja taka nazywa sie SMTP-relay i jest czesto wykorzystywana do omijania niektorych rodzajow zabezpieczen antyspamowych.

W terminach protokolu SMTP mozna powiedziec, ze SMTP-relay to sytuacja majaca miejsce wtedy gdy skrzynka, ktorej adres zostal podany jako argument komendy RCPT TO: nie znajduje sie na komputerze, z ktorym nastapilo polaczenie.

Kazdy serwer pocztowy ma prawo odmowic relay'owania poczty.

2.3. Naglowek rfc822

Chociaz dane wysylane przy uzyciu komendy DATA protokolu SMTP moga w zasadzie miec dowolny format powinno przestrzegac sie formatu ustalonego przez RFC 822 i jego aktualizacje. Wiadomosc sformatowana zgodnie z zaleceniami tego dokumentu sklada sie z naglowka i tresci. Naglowek zas sklada sie z szergu pol, z ktorych kazde ma nazwe i wartosc. Kazde pole wystepuje na odrebenej linii. Kazda wartosc jest oddzielona od nazwy pola dwukropkiem. Naglowek powinien byc oddzielony od tresci co najmniej jedna pusta linia. Nie powinno byc zadnych pustych linii wewnatrz naglowka.

Oto niektore z pol zdefiniowanych w RFC 822:

• Date:
• From:
• To:
• Subject:
• Reply-To:
• Return-Path:
• Received:

Oto transmisja wiadomosci zawierajacej naglowek RFC 822.

[jkowalski@vidmo]$ telnet elf.ii.uj.edu.pl 25
Trying 149.156.65.17...
Connected to elf.ii.uj.edu.pl.
Escape character is '^]'.
220 elf.ii.uj.edu.pl ESMTP (elf II UJ)
EHLO vidmo.net
250-elf.ii.uj.edu.pl
250-PIPELINING
250-SIZE 20000000
250-ETRN
250 8BITMIME
MAIL FROM:<jkowalski@vidmo.net>
250 Ok
RCPT TO:<jan.kowalski@ii.uj.edu.pl>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: <jkowalski@vidmo.net>
Subject: Your account has been removed.
To: Awful Hacker <hacker@ii.uj.edu.pl>

As indicated in the subject!

Regards,
The admin

.
250 Ok: queued as D28FF1100096C
QUIT
221 Bye
Connection closed by foreign host.
[jkowalski@vidmo]$

Wiadomosci e-mail sa umieszczane w skrzynce o adresie podanej w RCPT TO: bez wzgledu na wartosc pola To naglowka RFC 822.

2.4. Transfer encoding

Nie wszystkie komputery w sieci Internet posluguja sie osmiobitowym bajtem. Niektore maja bajt o dlugosci 7 bitow. Jesli jakis e-mail zawierajacy znak, ktorego kod w reprezentacji binarnej ma ustawiony (rowny jeden) najstarszy (osmy) bit, przechodzi przez gateway pocztowy, ktory ma siedmiobitowy bajt to osmy bit we wszystkich bajtach oryginalnej wiadomosci jest zerowany. Moze to powodowac znieksztalcenie widadomosci.

Aby temu zapobiec wprowadzono tzw. "transfer encodings". Sa to takie sposoby zakodowania wiadomosci, ktore nie korzystaja z osmego bitu i tym samym chronia wiadomosc przed skutami przejscia przez siedmiobitowy gateway pocztowy.

Poniewaz wszystkie znaki ASCII maja kody siedmiobitowe nastepujace kodowania maja powyzsza wlasnosc.

• quoted-printable
  

  Jest to kodowanie, w ktorym kazdy znak o kodzie, w ktorym osmy bit jest ustawiony na 1 zamieniany jest na nastepujacy ciag znakow: znak rownosci ('='), dwucyfrowa liczba szesnastkowa bedaca kodem kodowanego znaku. Przy pomocy tego kodowania mozna rowniez kodowac znaki, ktorych osmy bit jest rowny zero, choc nie zawsze ma to sens.

  Oto przyklad wiadomosci zakodowanej quoted-printable.

  Znak ' ', tj. "spacja"=20ma kod 32, co szesnastkowo=20jest
  rowne 20.

• base64
  

  W tym kodowaniu cala wiadomosc dzielona jest na 3-bajtowe fragmenty. Kazdy taki fragment skladajacy sie z 24 bitow jest dzielony na 4 czesci po 6 bitow. Kazda taka szesciobitowa czesc jest interpretowana jako liczba z zakresu od 0 do 63. Liczbom tym sa arbitralnie przypisane niektore znaki ASCII. Cztery znaki koduja wiec kazde trzy bajty. Jesli rozmiar pierwotnej wiadomosci nie byl podzielny przez 3 to do wiadomosci przed jej zakodowaniem dopisywany jest jeden lub dwa bajty o wartosci zero a do wyniku kodowania by zachowac informacje o rozmiarze pierwotnej wiadomosci dopisywane sa jeden lub dwa znaki '='. Kodowanie to powoduje wzrost dlugosci wiadomosci o ok 33%.

  Oto przyklad wiadomosci zakodowanej base64.

  [jkowalski@vidmo]$ echo "To zdanie zakodowano base64." | base64
  VG8gemRhbmllIHpha29kb3dhbm8gYmFzZTY0Lgo=
  [jkowalski@vidmo]$ echo "VG8gemRhbmllIHpha29kb3dhbm8gYmFzZTY0Lgo=" | base64 -d
  To zdanie zakodowano base64.
  [jkowalski@vidmo]$
  

2.5. Format MIME

Standardy poczty elektronicznej opisane dotychczas nie pozwalaja na przesylanie arbitralnych plikow jako tzw. zalacznikow. By bylo to mozliwe musi istniec sposob podzialu wiadomosci na skladowe oraz przypisania kazdemej skladowej informacji o rodzaju danych jakie zawiera. Umozliwia to standard definiujacy format wiadomosci e-mailowych MIME (ang. Multipurpose Internet Mail Extensions).

Standard MIME definiuje dodatkowe pola dodawane do pol naglowka RFC 822 a takze sposob laczenia roznych rodzajow danych w jedna wiadomosc.

Podstawowym polem naglowka MIME jest pole Content-Type. Jego wartoscia jest ciag znakow postaci typ/podtyp gdzie typ definiuje rodzaj informacji umieszczonych w tej skladowej wiadomosci, do ktorej sie odnosi, a podtyp doprecyzowuje o jaki format danych chodzi. Oto przyklady typow i podtypow MIME:

• text/plain (dowolny tekst)
• text/html (dokument napisany w jezyku HTML)
• text/rfc (dokument tekstowy w formacie Rich Text Format)
• audio/midi (dzwiek w formacie MIDI)
• audio/mpeg (dzwiek w formacie MPEG)
• audio/x-wav (dzwiek w formacie WAVE)
• image/jpeg (obraz w formacie JPEG)
• image/gif (obraz w formacie GIF)
• video/mpeg (obraz w formacie MPEG)
• video/quicktime (obraz w fomacie QuickTime)
• application/pdf (dokument w formacie PDF)
• application/octet-stream (dane binarne)
• message/rfc822 (wiadomosc e-mail w formacie okreslonym w RFC 822 lub jego aktualizacjach)
• multipart/mixed (wiadomosc MIME skladajaca sie z kilku czesci, z ktorych kazda powinna byc przekazana uzytkownikowi)
• multipart/alternative (wiadomosc MIME skladajaca sie z kilku czesci, ktore sa uwazane za rownowazne i, z ktorych jedna powinna byc pokazana uzytkownikowi)

Oto przyklad transmisji wiadomosci MIME skladajacej sie z wiadomosci tekstowej i zalacznika bedacego obrazem w formacie GIF.

[jkowalski@vidmo]$ cat q.gif | base64
R0lGODlhFAAUAOMAAIHL73vF6nW/42+43Wmy11CavmOs0VagxdjY2OXl5V2my/////Hx8cvL
y////////yH5BAEKAA8ALAAAAAAUABQAAASn8IFAgZg06yCH/2DoEUUwEsSAqoaaEsZRACwM
D0gyGDaslC4eQbAoLgQohUHxo6EIikExQFygDNifqUdEGgILBI8p28J4WBhj0UgvZzXFdVi0
KbU1LI/I2OmZcHNCRTtXS3hJZwQLDHpoMYFoPYZ/BkBPY1IMcoaANGhyPEV/Pk0uiY9CoWUs
SqRLS1Bvn3ewta53M4cKB7xkTLy9BzIPBcbHyMnHDxEAOw==
[jkowalski@vidmo]$ telnet elf.ii.uj.edu.pl 25
Trying 149.156.65.17...
Connected to elf.ii.uj.edu.pl.
Escape character is '^]'.
220 elf.ii.uj.edu.pl ESMTP (elf II UJ)
EHLO vidmo.net
250-elf.ii.uj.edu.pl
250-PIPELINING
250-SIZE 20000000
250-ETRN
250 8BITMIME
MAIL FROM:<jkowalski@vidmo.net>
250 Ok
RCPT TO:<jan.kowalski@ii.uj.edu.pl>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: <jkowalski@vidmo.net>
To: <hacker@ii.uj.edu.pl>
Date: today
Subject: A message with an attachment
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="bound"

--bound
Content-Type: text/plain
Content-Disposition: inline

Hello :-)

Enclosed please find a picture of '?'.

Kind regards,
jkowalski

--bound
Content-Type: image/gif; name="q.gif"
Content-Disposition: attachment; filename="q.gif"
Content-Transfer-Encoding: base64

R0lGODlhFAAUAOMAAIHL73vF6nW/42+43Wmy11CavmOs0VagxdjY2OXl5V2my/////Hx8cvL
y////////yH5BAEKAA8ALAAAAAAUABQAAASn8IFAgZg06yCH/2DoEUUwEsSAqoaaEsZRACwM
D0gyGDaslC4eQbAoLgQohUHxo6EIikExQFygDNifqUdEGgILBI8p28J4WBhj0UgvZzXFdVi0
KbU1LI/I2OmZcHNCRTtXS3hJZwQLDHpoMYFoPYZ/BkBPY1IMcoaANGhyPEV/Pk0uiY9CoWUs
SqRLS1Bvn3ewta53M4cKB7xkTLy9BzIPBcbHyMnHDxEAOw==

--bound--
.
250 Ok: queued as F23D01100096D
QUIT
221 Bye
Connection closed by foreign host.
[jkowalski@vidmo]$

3. Zagrozenia zwiazane z poczta elektroniczna

3.1. Naduzycia SMTP relay

Jednym z najczestszych naduzyc zwiazanych z poczta elektroniczna jest spam. Poniewaz adresy IP komputerow, z ktorych wysylana jest duza ilosc spamu czesto blokowane sa na firewallu spamerzy znajduja inne sposoby na dostarczenie swojego poslania do skrzynek przymusowych odbiorcow.

Jednym z takich sposob jest naduzycie serwerow pocztowych, ktore nie sa odpowiednio zabezpieczone i pozwalaja byle komu na relay dokadkolwiek. Spamer, ktorego IP jest odrzucany przez docelowy system moze wyslac swoj szmelc laczac sie nie z docelowym systemem, lecz z ktoryms ze zle skonfigurowanych serwerow pocztowych, ktore z kolei przekaza jego "wiadomosc" do systemu docelowego korzystajac z faktu, ze czesto IP takiego zle skonfigurowanego serwera pocztowego nie jest blokowany przez firewall systemu docelowego.

Umozliwiajac wiec relay dowolnym uzytkownikom, ktorzy tylko zdolaja sie polaczyc z portem 25 danego systemu ryzykuje sie, ze po jakims czasie jego IP znajdzie sie na liscie antyspamowej, gdyz administratorzy systemow, ktore byly spamowane z wykorzystaniem tego zle zabezpieczonego systemu jako SMTP relay zablokuja jego IP na firewallu uniemozliwiajac wysylanie maili rowniez uzytkownikom nie majacym zlych intencji.

Czesto jednak nie mozna wylaczyc SMTP relay calkowicie gdyz jest on powszechnie stosowany przez ludzi, ktorzy nie sa sklonni czytac swojej poczty bezposrednio na serwerze i preferuja uzywac programow uruchamianych na ich lokalnym komputerze i wykorzystujacych SMTP relay i POP3 do wysylania i odbierania maili.

Najlepszym sposobem zabezpieczenia sie w takim przypadku jest zezwolenie na SMTP relay jedynie tym uzytkownikom, ktorzy dokonaja uprzednio autoryzacji (patrz rozdzial 4).

3.2. Fake-mail

Jak widzielismy w rozdziale 2.3 dane umieszczane w naglowku wiadomosci email nie zawsze musza odpowiadac prawdzie. W zasadzie jedynym polem, ktoremu naprawde mozna ufac jest pole Received i to tez jedynie ostatnie dopisane przez nasz wlasny serwer pocztowy. Informuje ono o tym skad nadeszla dana wiadomosc. Wszystkie pozostale dane moga byc sfabrykowane dokladnie tak jak bylo to pokazane w poprzednim rozdziale.

Jedynym pewnym sposobem weryfikacji rzeczywistego autorstwa poczty elektronicznej jest podpis cyfrowy pod ta wiadomoscia (opisany w rozdziale 5.1.3).

3.3. Prywatnosc

Wszystkie wiadomosci email wysylane przez standardowy SMTP bez rozszerzen sa transmitowane otwartym tekstem. Oznacza to, ze kazdy kto ma dostep do wezlow sieci posredniczacych w transmisji lub do segmentow sieci, poprzez ktore wiadomosc jest transmitowana moze zapoznac sie z jej zawartoscia lub nawet ja zmodyfikowac.

Ochrone przed modyfikacja zapewnic moze podpisywanie elektroniczne wiadomosci. Prywatnosc korespondencji mozna zapewnic poprzez stosowanie szyfrowania. Obie funkcjonalnosci sa zapewniane przez rozszerzenie standardu MIME pozwalajace na stosowanie technik kryptograficznych - S/MIME (ang. Secure Multipurpose Internet Mail Extensions) opipsany w rozdziale 5.1.

Istnieje rowniez rozszerzenie protkolu SMTP pozwalajace na szyfrowanie dialogu SMTP wykorzystujace SSL (ang. Secure Socket Layer). Rozszerzenie to opisane jest w rozdziale 4.7.

4. Metody uwierzytelniania i szyfrowania w protokole SMTP

4.1. SMTP AUTH

Aby umozliwic uwierzytelnianie w protokole SMTP zdefiniowane zostalo rozszerzenie tego protokolu o nazwie AUTH. Pozwala ono na uzycie kilku metod uwierzytelniania, z ktorych nie kazda musi byc zaimplementowana przez serwer i wykorzystywana przez klienta. Rozszerzenia wspierane przez serwer sa przezen sygnalizowane w odpowiedzi na inicjujaca dialog SMTP komende EHLO. W ponizszym przykladzie serwer informuje klienta, ze wspiera nastepujace metody autoryzacji:

• PLAIN
• LOGIN
• CRAM-MD5
• DIGEST-MD5

[jan.kowalski@elf]$ telnet vidmo.net 25
Trying 83.16.216.214...
Connected to vidmo.net.
Escape character is '^]'.
220 vidmo.net ESMTP Postfix
EHLO elf.ii.uj.edu.pl
250-vidmo.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250-AUTH=LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250 8BITMIME
QUIT
221 Bye
Connection closed by foreign host.
[jan.kowalski@elf]$

4.2. Metoda PLAIN

W metodzie PLAIN klient wysyla serwerowi jeden komunikat zawierajacy trzy informacje:

• authid - nazwa uzytkownika uzywana do uwierzytelnienia klienta.
• userid - nazwa uzytkownika, ktorego uprawnienia klient pragnie uzyskac.
• password - haslo.

Komunikat wysylany przez klienta do serwera w metodzie PLAIN oblicza sie w nastepujacy sposob:

[jan.kowalski@elf]$ telnet vidmo.net 25
Trying 83.16.216.214...
Connected to vidmo.net.
Escape character is '^]'.
220 vidmo.net ESMTP Postfix
EHLO elf.ii.uj.edu.pl
250-vidmo.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250-AUTH=LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250 8BITMIME
AUTH PLAIN fhjksdhfkjhsdfhklsdh
535 Error: authentication failed
AUTH PLAIN amtvd2Fsc2tpAGprb3dhbHNraQBibGVibGU=
235 Authentication successful

[jkowalski@vidmo]$ echo -n 'jkowalski#jkowalski#bleble' | tr '#' "\000" | base64
amtvd2Fsc2tpAGprb3dhbHNraQBibGVibGU=
[jkowalski@vidmo]$

4.3. Metoda LOGIN

Metoda login wyglada podobnie do zwyklego logowania w protokole telnet lub ssh.

1. Serwer zadaje pytanie o username uzytkownika.
2. Uzytkownik odpowiada podajac swoj login.
3. Serwer zadaje pytanie o haslo uzytkownika.
4. Uzytkownik odpowiada podajac swoje haslo.

[jan.kowalski@elf]$ telnet vidmo.net 25
Trying 83.16.216.214...
Connected to vidmo.net.
Escape character is '^]'.
220 vidmo.net ESMTP Postfix
EHLO elf.ii.uj.edu.pl
250-vidmo.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250-AUTH=LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250 8BITMIME
AUTH LOGIN
334 VXNlcm5hbWU6
amtvd2Fsc2tp
334 UGFzc3dvcmQ6
aGFzZWxrbw==
235 Authentication successful

[jkowalski@vidmo]$ echo VXNlcm5hbWU6 | base64 -d
Username:[jkowalski@vidmo]$ echo -n jkowalski | base64
amtvd2Fsc2tp
[jkowalski@vidmo]$ echo UGFzc3dvcmQ6 | base64 -d
Password:[jkowalski@vidmo]$ echo -n haselko | base64
aGFzZWxrbw==
[jkowalski@vidmo]$

4.4. Zastosowanie hasel jednorazowych

Jak widac metody PLAIN i LOGIN pozostawiaja wiele do zyczenia jesli chodzi o bezpieczenstwo. Przesylanie hasel uzytkownika zakodowanych jedynie za pomoca base64, ktory mozna bardzo latwo odkodowac jest duzym ryzykiem. To powoduje, ze metody te powinny byc stosowane jedynie w dwoch przypadkach:

• Gdy stosowane hasla sa haslami jednorazowymi (patrz rozdzial 1.7).
• Gdy autoryzacja przebiega poprzez zabezpieczony kanal komunikacyjny, np. taki, ktory jest tworzony przez STARTTLS (patrz rozdzial 4.7).

W celu umozliwienia stosowania hasel OPIE w SMTP stosownych zmian konfiguracyjnych dokonac nalezy w PAM (ang. Pluggable Authentication Modules) i SASL (ang. Simple Authentication and Security Layer).

W przypadku gdy nie jest stosowane szyfrowanie dialogu SMTP (przy uzyciu rozszerzenia STARTTLS) a hasla uzywane przez uzytkownikow nie sa haslami jednorazowymi nie nalezy stosowac metod PLAIN ani LOGIN, lecz zastosowac jedna z bezpiecznych metod uwierzytelniania opisanych w nastepnych rozdzialach. Niestety bardzo wielu uzytkownikow poczty zapomina skonfigurowac swoje programy tak by korzystaly z SSL tym samym zarazajac sie na ryzyko przechwycenia ich hasel.

4.5. Metoda CRAM-MD5

Metoda uwierzytelniania CRAM-MD5 polega na wykazaniu przez klienta, ze zna pewien sekret (haslo), ktore jest rowniez znane serwerowi. Podczas przeprowadzania tego dowodu sekret nie jest jednak wysylany poprzez siec co gwarantuje bezpieczenstwo tej metody.

Uwierzytelnianie metoda CRAM-MD5 odbywa sie wg nastepujacej procedury:

1. Serwer losuje ciag bajtow zw. challenge, koduje go base64 i wysyla klientowi.
2. Klient oblicza wartosc HMAC (opartego na MD5, patrz rozdzial 1.8) z wartosci odkodowanego base64 challenge przy uzyciu sekretu jako klucza.
   authtoken=HMAC(sekret, challenge)
   authtoken=MD5(sekret XOR opad . MD5(sekret XOR ipad . challenge))
   Tak obliczony authtoken jest zapisywany jako ciag 32 cyfr szesnastkowych w ASCII
3. Klient konstruuje ciag znakow 'username authtoken' (odsperowane spacja) i po zakodowaniu go base64 odsyla do serwera.

[jkowalski@vidmo]$ telnet vidmo.net 25 Trying 83.16.216.214... Connected to vidmo.net. Escape character is '^]'. 220 vidmo.net ESMTP Postfix EHLO vidmo.net 250-vidmo.net 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-AUTH LOGIN PLAIN CRAM-MD5 250-AUTH=LOGIN PLAIN CRAM-MD5 250 8BITMIME AUTH CRAM-MD5 334 PDEzODQyMzA3NDUuMTAwNzg2MDVAdmlkbW8ubmV0Pg== amtvd2Fsc2tpIGFjN2QwYTRjNjM1ZjhjNGY1ZmRmNjU4OTIzOTRjZjIx 235 Authentication successful

[jkowalski@vidmo]# ls -l total 10 -rw-r--r-- 1 jkowalski wheel 64 May 29 15:45 ipad -rw-r--r-- 1 jkowalski wheel 64 May 29 15:48 ipadxored -rw-r--r-- 1 jkowalski wheel 64 May 29 15:45 opad -rw-r--r-- 1 jkowalski wheel 64 May 29 15:48 opadxored -rw-r--r-- 1 jkowalski wheel 64 May 29 15:47 secret [jkowalski@vidmo]# base64 -d > challenge PDEzODQyMzA3NDUuMTAwNzg2MDVAdmlkbW8ubmV0Pg== [jkowalski@vidmo]# cat ipadxored challenge > ipadchall [jkowalski@vidmo]# cat ipadchall | md5 | dehex > innerhash [jkowalski@vidmo]# cat opadxored innerhash | md5 ac7d0a4c635f8c4f5fdf65892394cf21 [jkowalski@vidmo]# echo -n 'jkowalski ac7d0a4c635f8c4f5fdf65892394cf21' | base64 amtvd2Fsc2tpIGFjN2QwYTRjNjM1ZjhjNGY1ZmRmNjU4OTIzOTRjZjIx [jkowalski@vidmo]#

(Komenda dehex jest programem, ktory zamienia ciag cyfr szesnastkowych zapisanych w ASCII na dane binarne.)

Wada metody CRAM-MD5 jest to, ze nie uwierzytelnia serwera wzgledem klienta a jedynie klienta wzgledem serwera, a zatem ktos moze sie pod niego podszywac jesli zdola oszukac routing lub DNS. Jest wiec podatna na atak podszywania.

Inna wada tej metody jest to, ze serwer musi znac haslo klienta, co powoduje, ze nie mozna jej stosowac w polaczeniu ze standardowym mechanizmem hasel w UNIXie gdyz w nim serwer nie zna hasel a jedynie wartosc pewnej funkcji haszujacej obliczonej dla hasla uzytkownika.

4.6. Metoda DIGEST-MD5

Metoda DIGEST-MD5 podobnie jak CRAM-MD5 bazuje na funkcji haszujacej i MAC (ang. Message Authentication Code) by nie wysylac sekretu sluzacego do uwierzytelniania poprzez siec. Dokonuje ona jednak uwierzytelnienia nie tylko klienta ale i serwer uniemozliwiajac tym samym atak podszywania.

Podobnie jak w metodzie CRAM-MD5 serwer musi znac haslo klienta co powoduje trudnosci w integracji tej metody ze standardowym systemem hasel w UNIXie.

Jest to zdecydowanie najbezpieczniejsza metoda uwierzytelniania z czterech opisanych w tym rozdziale.

4.7. Rozszerzenie STARTTLS

Poniewaz dialog SMTP odbywa sie standardwowo jako wymiana komunikatow i danych tekstem otwartym, jest on narazony na podsluch, ktory w przypadku korespondencji utrudnia zachowanie prywatnosci. Aby poprawic ta sytuacje stworzono rozszerzenie protokolu SMTP, ktore pozwala na szyfrowanie wymienianych komunikatow.

Rozszerzenie to nazywa sie STARTTLS, tak samo jak komenda, ktora powoduje uaktywnienie warstwy SSL, ktora dokonuje szyfrowania wszystkich wymienianych komunikatow.

Wykorzystanie STARTTLS wyglada nastepujaco:

[jan.kowalski@elf]$ telnet vidmo.net 25
Trying 83.16.216.214...
Connected to vidmo.net.
Escape character is '^]'.
220 vidmo.net ESMTP Postfix
EHLO vidmo.net
250-vidmo.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250-AUTH=LOGIN PLAIN DIGEST-MD5 CRAM-MD5
250 8BITMIME
STARTTLS
220 Ready to start TLS

Oczywiscie by mozna bylo uzyc tej komendy serwer musi ja wspierac, a wiec musi ona wystapic na liscie wspieranych rozszerzen wyslanych przez serwer w odpowiedzi na komende EHLO.

5. Prywatnosc w poczcie elektronicznej

5.1. S/MIME

S/MIME (ang. Secure Multipurpose Internet Mail Extensions) jest standardem rozszerzajacym mozliwosci MIME tak by wspierac prywatnosc i uwierzytelnianie korespondencji. Standard S/MIME definiuje dodatkowe typy danych sluzacych do opisu danych zaszyfrowanych, podpisanych, samych podpisow (tzw. podpisow zewnetrznych) oraz certyfikatow i list CRL (ang. Certificate Revokation List):

• application/pkcs7-mime
• multipart/signed
• application/pkcs7-signature

5.1.1. CMS

Zaszyfrowana lub podpisana wiadomosc umieszczana wewnatrz komunikatu S/MIME musi zostac stworzona zgodnie ze standardem CMS (ang. Cryptographic Message Syntax), ktory definiuje sposob organizacji danych umieszczanych w takiej wiadomosci. Wiadomosc taka ma bowiem dosc skomplikowana strukture wewnatrzna - musi zawierac certyfikaty uzytych kluczy, wartosci podpisow cyfrowych oraz sama informacja, ktora ma otrzymac jej odbiorca.

CMS definiuje kilka rodzajow informacji, z ktorych S/MIME wykorzystuje dwa:

• SignedData
• EnvelopedData

S/MIME definiuje parametr o nazwie smime-type, ktorego wartoscia jest nazwa rodzaju obiektu CMS znajdujacego sie po naglowku S/MIME. Pole to moze przyjmowac m.in. nastepujace wartosci: 'signed-data' i 'enveloped-data' w zaleznosci od tego jaki obiekt CMS jest przenoszony w wiadomosci.

Obiekty CMS przenoszone w wiadomosciach S/MIME sa kodowane base64.

5.1.1.1. SignedData

Obiekt CMS zwany SignedData zawiera m.in. nastepujace informacje:

• Dane, ktore sa podpisywane.
• Wartosci podpisow cyfrowych (moze byc ich kilka).
• Certyfikaty zawierajace klucze publiczne sluzace do weryfikacji podpisow oraz opcjonalnie wszystkie certyfikaty uwiarygadniajace podpis, az do certyfikatow CA (ang. Certificate Authority).

Istnieje mozliwosc stworzenia obiektu CMS SignedData bez danych zawierajacego sam podpis elektroniczny. Zaklada sie wtedy, ze dane, ktore sa podpisane beda dostepne dla weryfikujacego podpis w inny sposob. Wykorzystuje sie to przy tzw. "zewnetrznych" podpisach opisanych w rozdziale 5.1.3.2.

Obiekt CMS SignedData moze rowniez sluzyc do przenoszenia certyfikatow lub CRLow (ang. Certificate Revokation List). W takim przypadku nie zawiera danych, a pole z podpisem jest puste. Ta mozliwosc S/MIME wykorzystuje do konstrukcji wiadomosci przenoszacych certyfikaty i CRLe (patrz. rozdzial 5.1.4).

5.1.1.2. EnvelopedData

Obiekt EnvelopedData sluzy ochronie prywatnosci danych i zawiera nastepujace informacje:

• Dane zaszyfrowane algorytmem symetrycznym.
• Klucz uzyty do szyfrowania danych, zaszyfrowany kluczem publicznym odbiorcy przy pomocy wybranego algorytmu szyfrowania asymetrycznego (jesli odbiorcow jest wielu ten element moze wystapic wielokrotnie - jest to wtedy ten sam klucz uzyty do zaszyfrowania danych zaszyfrowany za kazdym razem innym kluczem publicznym).

5.1.2. Poczta zaszyfrowana

Zaszyfrowana wiadomosc, ktora ma zostac przeslana zgodnie ze standardem S/MIME powinna zostac przetworzona zgodnie z CMS w obiekt EnvelopedData, a nastepnie zakodowana base64. Nastepnie dodaje sie do niej naglowek S/MIME z Content-Type ustawionym na application/pkcs7-mime z parametrem smim-type o wartosci "enveloped-data".

Oto przyklad takiej wiadomosc:

Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
     name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V

5.1.3. Poczta podpisana

Standard S/MIME przewiduje dwa sposoby transmisji wiadomosci podpisanej elektronicznie. W pierwszym z nich wiadomosc i podpis ukrywane sa wewnatrz obiektu CMS SignedData przesylanego nastepnie odbiorcy. W drugim tworzony jest obiekt CMS SignedData zawierajacy jedynie podpis wiadomosci. Nastepnie wiadomosc i podpis w postaci obiektu SignedData sa wysylane jako odrebne czesci jednej wiadomosci. Drugi z tych sposobow ma ta przewage nad pierwszym, ze wiadomosc tak wyslana jest czytelna rowniez dla odbiorcow, ktorzy nie moga przetwarzac S/MIME i CMS (chociaz sa oni w stanie odczytac taka wiadomosc nie moga oczywiscie zweryfikowac podpisu pod nia). Wada tego sposobu transmisji podpisanej elektronicznie wiadomosci jest to, ze niektore bramy pocztowe moga tak zmodyfikowac jej postac, ze weryfikacja podpisu moze sie nie powiesc.

5.1.3.1. Podpis zintegrowany z listem

Wiadomosc S/MIME z podpisem i wiadomoscia ukryta razem wewnatrz obiektu CMS SignedData podobnie jak wiadomosc zaszyfrowana wykorzystuje Content-Type application/pkcs7-mime. Roznia sie one wartoscia parametru smime-type, ktory w przypadku wiadomosci podpisanej ma wartosc "signed-data". Pod kazdym innym wzgledem jest ona konstruowana podobnie do wiadomosci zaszyfrowanej.

Oto przyklad:

Content-Type: application/pkcs7-mime; smime-type=signed-data;
     name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75

5.1.3.2. Podpis "zewnetrzny"

Wiadomosc S/MIME, ktora ma byc czytelna dla odbiorcy niezaleznie od tego czy jego oprogramowanie wspiera S/MIME czy nie musi byc skonstruowana tak by wiadomosc nie byla ukryta wewnatrz obiektu CMS SignedData. Jest to wiec wiadomosc dwuczesciowa skladajaca sie z

1. Wiadomosci w czytelnej postaci przenoszonej jak kazda inna wiadomosc zgodna z MIME.
2. Podpisu elektronicznego w postaci obiektu CMS SignedData, ktory nie zawiera wiadomosci.

Pierwsza czesc moze byc dowolna wiadomoscia MIME. Druga musi miec Content-Type application/pkcs7-signature i zawierac zakodowany base64 obiekt CMS SignedData z podpisem pierwszej czesci. Obie te wiadomosci sa laczone w wiekosza wiadomosc S/MIME z Content-Type multipart/signed. Ta ostatnia wartosc pola Content-Type wymaga podania dwoch parametrow: protocol, ktory powinien zawsze miec wartosc "application/pkcs7-signature" oraz micalg, ktorego wartoscia powinno byc "md5" jesli podpis elektroniczny korzysta z funkcji haszujacej MD5, "sha1" jesli korzysta z SHA-1 lub "unknown" w przypadku gdy zadna z powyzszych funkcji haszujacych nie jest wykorzystywana. Parametr micalg pozwala na weryfikacje podpisu bez dwukrotnego czytania wiadomosci.

Oto przyklad wiadomosci S/MIME z "zewnetrznym" podpisem. Jak wiadac tresc wiadomosci nie jest ukryta wewnatrz obiektu CMS.

Content-Type: multipart/signed;
   protocol="application/pkcs7-signature";
   micalg=sha1; boundary=boundary42

--boundary42
Content-Type: text/plain

This is a clear-signed message.

--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756

--boundary42--

5.1.4. Wiadomosci przenoszace certyfikaty

Jak wspomniano przy opisie obiektow CMS SignedData moga one nie przenosic podpisu i danych, lecz same certyfikate lub listy certyfikatow odrzuconych (CRL). Wiadomosc taka wyglada dokladnie jak wiadomosc application/pkcs7-mime przenoszaca podpisane lub zaszyfrowane informacje z ta roznica, ze parametr smime-type ma wartosc "certs-only" (a nazwa pliku podana w parametrze name i filename maja rozszerzenie ".p7c").

5.1.5. Ochrona naglowka

Informacje, ktore sa przekazywane do podpisania lub zaszyfrowania do modulu realizujacego operacje tworzenia obiektow CMS skladaja sie z wiadomosci wraz z naglowkiem MIME. Naglowek RFC 822 normalnie nie jest brany pod uwage przy tworzeniu podpisu lub szyfrowaniu. Oznacza to, ze jest on narazony na modyfikacje.

Mozna jednak sie przed tym uchronic tworzac z wiadomosci i jej naglowka RFC 822 komunikat MIME typu message/rfc822 i szyfrujac badz podpisujac tak utworzona nowa wiadomosc.

Oczywiscie ten sam badz inny naglowek RFC 822 i tak bedzie musial zostac dodany na zewnatrz obiektu CMS ujawniajac wszystkie informacje w nim zawarte. Nie ma jednak mozliwosci ukrycia ich, gdyz sa to informacje wykorzystywane do przesylania wiadomosci - musza one byc dostepne dla systemow przenoszacyc wiadomosc, by wiedzialy one jak i dokad ja dostarczyc.