Zabezpieczanie wiadomości e-mail przy użyciu certyfikatów cyfrowych
 |
Zawartość strony
Od tysiącleci ludzie wykorzystywali wiele różnych metod ukrywania przesyłanych informacji, weryfikowania nadawcy i uwierzytelniania wiadomości. Wraz z rozwojem cywilizacyjnym powstała pewna metoda pozwalająca na realizowanie wszystkich trzech zadań, która staje się obecnie coraz bardziej popularna. Secure Multi-Purpose Internet Mail Extensions (S/MIME) to system służący do przesyłania wiadomości e-mail w bezpieczny sposób przy użyciu szyfrowania i podpisów cyfrowych.
Współczesne technologie szyfrowania (ukrywania) można podzielić na dwa główne typy: algorytmy symetrycznego (sekretnego) klucza, takie jak Data Encryption Standard (DES) lub Advanced Encryption Standard (AES) oraz algorytmy asymetrycznego klucza (publicznego/prywatnego), takie jak RSA lub Elliptical Curve Cryptography (ECC). Nowoczesne narzędzia do weryfikacji nadawcy stanowią matematyczne jednokierunkowe funkcje nazywane funkcjami mieszającymi (ang. hashing), które tworzą unikatowe podpisy. Dwie powszechnie znane metody mieszania to algorytmy Message Digest 5 (MD5) oraz Secure Hash Algorithm (SHA). Komputery mogą wykorzystywać je do generowania unikatowej wartości mieszania lub liczby, która odpowiada wybranemu tekstowi źródłowemu (identyczne teksty źródłowe mają tę samą wartość mieszania). Te proste narzędzia zostały zastosowane w połączeniu ze sobą do zbudowania systemu infrastruktury klucza publicznego (Public Key Infrastructure - PKI).
Weryfikowalna tożsamość
Proces zarządzania tożsamościami w systemie PKI wiąże się z wykorzystaniem certyfikatów cyfrowych, które przypominają państwowy dokument identyfikacyjny, którym większość ludzi posługuje się przy przekraczaniu granicy, a mianowicie paszport. Standard paszportowy w świecie certyfikatów cyfrowych to format X.509, który jest powszechnie wykorzystywany do podpisywania i szyfrowania w technologiach takich jak S/MIME, Internet Protocol Security (IPsec), Secure Shell (SSH), zabezpieczenia sieci bezprzewodowej, wirtualne sieci prywatne (VPN), a nawet bezpieczna komunikacja z serwerem (np. w witrynach sieci Web opartych na protokole SSL).
Certyfikaty są zbudowane na bazie asymetrycznych funkcji kryptograficznych i funkcji mieszania. Aby stworzyć certyfikat, strona żądająca (jednostka potrzebująca klucza podpisanego przez wybrany urząd o większym autorytecie) generuje klucz prywatny. Klucz ten jest przechowywany w zamknięciu, a zatem jego autentyczność nie podlega wątpliwości. Wraz z kluczem prywatnym generowany jest również odpowiadający mu klucz publiczny. Jak sama nazwa wskazuje, publiczna część tej pary nie stanowi sekretu i może być swobodnie dystrybuowana, choć nadal w sposób gwarantujący jej autentyczność.
Ta para kluczy pozwala na wykonywanie dwóch podstawowych operacji. Po pierwsze każdy może użyć klucza publicznego do zaszyfrowania czegoś, co można zdeszyfrować jedynie przy użyciu klucza prywatnego. Po drugie klucz publiczny może posłużyć do deszyfrowania czegoś, co zostało zaszyfrowane przy użyciu klucza prywatnego. Ma to znaczenie w przypadku weryfikowania podpisu, który mógł zostać stworzony jedynie przy pomocy klucza prywatnego.
Żądanie wysyłane do urzędu certyfikacji (CA) zawiera takie informacje szczegółowe, jak tożsamość osoby lub komputera, dla którego przeznaczony jest klucz, typ i moc algorytmu oraz publiczna część pary kluczy. Urząd certyfikacji (CA) odbiera i waliduje informacje na żądanie, a następnie przy użyciu algorytmu mieszania tworzy unikatowy identyfikator odpowiadający informacjom.
Wykorzystując klucz prywatny, urząd certyfikacji szyfruje wartość mieszania informacji i umieszcza ją w standardowym formacie (takim jak X.509), tworząc certyfikat odpowiadający oryginalnemu żądaniu. Certyfikat X.509 będzie zawierać listę oświadczeń, między innymi tożsamość certyfikatu (podmiot), okres ważności, klucz publiczny i operacje, do wykonywania których może posłużyć dany certyfikat. Następnie certyfikat jest zwracany stronie żądającej. Jest to token, który w praktyce deklaruje, że "organizacja certyfikująca ręczy za dany klucz publiczny i odpowiadającą mu prywatną część w zakresie wszystkich wymienionych zastosowań".
Główne urzędy certyfikacji (te na najwyższym poziomie w łańcuchu zaufania) same podpisują certyfikaty. Lista zawierająca większość akceptowanych głównych urzędów certyfikacji zostaje wstępnie zainstalowana w podstawowym systemie operacyjnym lub aplikacji, ale może zostać uaktualniona lub zmodyfikowana przy użyciu pakietów lub mechanizmu Enterprise Configuration. Pomiędzy głównym urzędem certyfikacji a węzłem liścia (który zazwyczaj opisuje pojedynczą osobę lub system) może istnieć jeden lub więcej pośrednich urzędów certyfikacji.
Łańcuch składa się z wszystkich węzłów i wbudowanych w nie certyfikatów poprzedzających podpisanych przez urząd certyfikacji na danym poziomie. Firma zewnętrzna, która próbuje zweryfikować certyfikat, może sprawdzić lokalnie wyliczaną wartość mieszania i porównać ją z wartością zdeszyfrowaną na podstawie certyfikatu przy użyciu odpowiedniego klucza publicznego tego określonego urzędu certyfikacji lub organizacji. Jest to w pełni weryfikowalny łańcuch zaufania od węzła liścia do korzenia, oczywiście przy założeniu, że korzeń (główny urząd) jest zaufany.
Aktualizowanie stanu certyfikatu
Każdy szanujący się urząd certyfikacji opracował środki dystrybucji listy certyfikatów, które nie powinny być już zaufane. Ta lista odwołania certyfikatów (CRL) opisuje, które wystawione zaświadczenia zostały unieważnione przez urząd certyfikacji. Dla ułatwienia lokalizacja listy CRL stanowi zwykle właściwość certyfikatu urzędu certyfikacji.
Zazwyczaj urzędy certyfikacji publikują listy CRL na dwa sposoby: regularnie (na przykład co dwa tygodnie) lub w konsekwencji zdarzenia (sytuacji, która sprawiła, że wystawiony certyfikat nie powinien być już zaufany). Urząd certyfikacji podpisuje wydawaną listę CRL w momencie jej publikowania. Gdy system odbiorcy ocenia poprawność łańcucha, zwykle usiłuje pozyskać listę CRL dla każdej urzędu certyfikacji obecnego w łańcuchu (poprzez informacje wbudowane w same certyfikaty lub za pośrednictwem predefiniowanego, godnego zaufania mechanizmu dystrybucji). Jeśli którakolwiek z list CRL jest niedostępna, system kliencki może cofnąć się do ostatniej, pomyślnie zbuforowanej kopii, o ile nie jest ona starsza od określonego okresu aktualizacji listy CRL. Niepowodzenie powoduje zazwyczaj, że systemy klienckie pokazują pewien rodzaj błędu wskazujący, iż certyfikat jawi się jako poprawny, jednakże nie mógł zostać określony stan odwołania.
Wiele aplikacji potrzebuje znacznie dłuższego czasu do załadowania certyfikatu, gdy nie jest w stanie zweryfikować łańcucha lub listy CRL dla każdego węzła w łańcuchu. W zależności od tego co chronił dany certyfikat, użytkownik może, ale nie musi mu zaufać. Regularnie aktualizowany, powszechnie dostępny punkt dystrybucji list CRL jest absolutnie niezbędny dla każdego urzędu certyfikacji, a w szczególności dla publicznych urzędów głównych.
Korzenie stanowią podstawę łańcucha certyfikacji, a powiązania łańcuchowe stanowią fundament dla wszystkich hierarchii certyfikatów. Większość systemów klienckich lub aplikacji przyjmuje założenie, że certyfikat węzła liścia jest poprawny, jeśli jego łańcuch prowadzi z powrotem do zaufanego korzenia. Korzeniem może być korporacyjny urząd certyfikacji znajdujący się w posiadaniu wybranej firmy lub publiczny główny urząd certyfikacji (taki jak VeriSign).
Od publicznych głównych urzędów certyfikacji oczekuje się profesjonalnego działania w celu zapewnienia rzetelności. Korporacje powinny dążyć do tego samego poziomu wiarygodności w swoich operacjach wewnętrznych, ponieważ nienaruszalność głównego urzędu certyfikacji w tym kontekście jest równie istotna. W celu zapewnienia maksymalnej ochrony główne urzędy certyfikacji powinny w zasadzie znajdować się w trybie offline i służyć jedynie do wystawiania certyfikatów oraz aktualizacji list CRL. Więcej informacji na temat najlepszych praktyk działania urzędów certyfikacji znaleźć można w artykułach, których lista została zaprezentowana w ramce o tytule "Materiały dodatkowe dotyczące urzędów certyfikacji".
Jedną z ważniejszych kwestii, które trzeba wziąć pod uwagę, jest odzyskiwanie klucza. Z myślą o umożliwieniu przeprowadzenia analizy danych oraz zagwarantowaniu, iż treść wiadomości nie zostanie nieodwracalnie zablokowana przez użytkownika, korporacja powinna tworzyć kopie zapasowe wszystkich kluczy wystawionych na żądanie użytkowników. Co więcej kopie zapasowe powinny być przechowywane w bezpiecznym repozytorium. W ten sposób jeśli klucz użytkownika zaginie, na przykład w wyniku pozostawienia karty pamięci w taksówce, nadal będzie można uzyskać dostęp do zawartości chronionej przez ten klucz.
Na zakończenie w każdym dobrym systemie kryptograficznym istnieje koncepcja zarządzania cyklem życia. W miarę wzrostu szybkości komputerów, maleje moc algorytmów. Każdy dobry system kryptograficzny musi posiadać możliwość odnowienia samego siebie i zastosowania nowych algorytmów oraz rozmiarów klucza. Urzędy certyfikacji powinny być we właściwy sposób informowane o wykrywanych słabych punktach algorytmów kryptograficznych oraz gdy określone funkcje zostają wprowadzone lub wycofane z użycia.
Implementacja systemu S/MIME
Istnieje kilka etapów inicjowania, tworzenia, wysyłania i odbierania podpisanych lub zaszyfrowanych wiadomości e-mail przy użyciu systemu S/MIME. Do zaprezentowania szczegółowych informacji, problemów i potencjalnych rozwiązań posłuży omówienie typowego scenariusza S/MIME: dwaj użytkownicy przesyłający do siebie podpisane i/lub zaszyfrowane wiadomości z różnych lasów usługi Active Directory® i różnych łańcuchów urzędu certyfikacji (to znaczy z operacyjnie odrębnych jednostek, niezależnie od tego czy znajdują się one w tej samej firmie czy też nie) z wykorzystaniem programu Microsoft® Office Outlook® 2007.
Przyjmiemy założenie, że zainstalowana została niezbędna infrastruktura, która umożliwia przeprowadzenie omawianych operacji. W naszym przykładzie posługujemy się korporacyjnym serwerem certyfikatów zintegrowanym z usługą Active Directory.
Pozyskiwanie certyfikatów
Pierwsze zadanie polega na pozyskaniu odpowiednich certyfikatów. W tym celu należy otworzyć konsolę MMC menedżera certyfikatów (certmgr.msc), prawym przyciskiem myszy kliknąć folder Osobisty (Personal), wybrać opcję Wszystkie zadania (All Tasks) z wyświetlonej listy, a następnie wybrać opcję Żądaj nowego certyfikatu (Request New).
To spowoduje uruchomienie kreatora Rejestrowane certyfikatów (Certificate Enrollment), jak pokazano na Rysunku 1. Domyślnie dostępnych będzie kilka opcji skoncentrowanych wokół korporacji, jednak dla nas najważniejsza jest opcja certyfikatu użytkownika (User). Posłuży ona do późniejszego włączenia procesów podpisywania i szyfrowania. Certyfikat musi umożliwiać zastosowanie go w zakresie:
• Podpisów cyfrowych (tworzenie wiadomości z pieczęcią autentyczności jej twórcy)
• Szyfrowania klucza (ochrona jednego klucza przy użyciu innego na potrzeby takich technologii jak System szyfrowania plików)
• Zabezpieczania poczty (szyfrowane wiadomości, które mogą być odczytywane jedynie przez określonego odbiorcę będącego w posiadaniu odpowiedniego klucza prywatnego)
Rysunek 1: Żądanie certyfikatu.
Właściwość szyfrowania klucza nie jest niezbędna do wysłania podpisanej w standardzie S/MIME wiadomości e-mail. Jednak w przypadku wysyłania lub odbierania zaszyfrowanej poczty, właściwość ta jest wymagana, w przeciwieństwie do właściwości podpisu. Domyślnie powyższe trzy właściwości są włączone dla wszystkich szablonów w usługach Windows® Certificate Services. Jeśli użytkownik nie ma prawa do żądania nowych certyfikatów, po uruchomieniu kreatora nie zobaczy żadnego szablonu. W przypadku braku dostępu do jakiegokolwiek urzędu certyfikacji użytkownik zobaczy "błąd rejestracji" wskazujący, że nie można było skontaktować się z domeną lub urzędem certyfikacji. W tym instruktażowym przykładzie przyjmiemy założenie, że istnieje jeden certyfikat pozwalający na podpisywanie i szyfrowanie.
Wymiana certyfikatów
Najprostszy sposób wymiany zaszyfrowanych wiadomości e-mail pomiędzy dwoma użytkownikami polega po prostu na przesyłaniu odpowiednio podpisanych wiadomości. Po stworzeniu wiadomości użytkownik klika przycisk Podpisz (Sign). Czasem przycisk ten jest domyślnie ukryty w programie Outlook, dopóki nie zostanie wykorzystany przynajmniej raz. Można go odnaleźć, klikając ustawienie Opcje (Options) nowej wiadomości, klikając przycisk "Ustawienia zabezpieczeń..." (Security Settings...), a następnie zaznaczając pole wyboru "Dodaj podpis cyfrowy do tej wiadomości" (Add a digital signature to this message) w oknie dialogowym Właściwości zabezpieczeń (Security Properties). Przycisk podpisywania (mała żółta koperta z czerwoną wstążką i etykietą Podpisz) powoduje dodanie do wiadomości podpisu cyfrowego w celu określenia autentyczności jej pochodzenia.
Użytkownik może być monitowany nie tylko o naciśnięcie przycisku Wyślij (Send), ale także o zapewnienie dodatkowych dowodów świadczących o posiadaniu klucza np. o włożenie karty pamięci lub wpisanie kodu PIN. Zależy to od określonych metod ochrony klucza wdrożonych w danej organizacji.
Użytkownik odbierający wiadomość podpisaną zgodnie ze standardem S/MIME będzie musiał wyświetlić i prawym przyciskiem myszy kliknąć nazwę nadawcy (Od:) i wybrać z menu kontekstowego opcję "Dodaj do kontaktów programu Outlook" (Add to Outlook contacts), co spowoduje dodanie nowego wpisu kontaktu lub aktualizacji istniejącego wpisu. Certyfikat jest następnie powiązywany z określonym wpisem kontaktu. Należy zauważyć, że w typowym środowisku Active Directory (dwóch użytkowników w tym samym lesie lub firmie), publiczna dystrybucja certyfikatów użytkowników odbywa się w sposób automatyczny za pośrednictwem atrybutów w obiekcie Active Directory użytkownika.
Inna metoda wymiany certyfikatów przez użytkowników polega na wysłaniu certyfikatu S/MIME w postaci załącznika. W tym celu obie strony muszą wyeksportować swoje certyfikaty do pliku CER. Użytkownicy będą musieli wyświetlić certyfikat i przeprowadzić procedurę eksportu, która zostanie za chwilę omówiona, uważając, aby nie wyeksportować jednocześnie klucza prywatnego (patrz Rysunek 2).
Rysunek 2: Wymieniając certyfikaty, nie należy eksportować klucza prywatnego.
Następnie każdy odbiorca własnoręcznie tworzy wpis kontaktu w programie Outlook i dodaje certyfikat do wpisu nadawcy. Po wymianie certyfikatów użytkownicy będą mogli wymieniać między sobą zaszyfrowane wiadomości e-mail.
Rozwiązywanie problemów
Czasem odbiorca ma trudności z otwarciem zaszyfrowanej wiadomości. Trzy najbardziej prawdopodobne źródła tego problemu to: niezaufane główne urzędy certyfikacji, pośrednie urzędy certyfikacji, które nie mogą zostać zweryfikowane oraz niedostępne listy CRL.
Niezaufany główny urząd certyfikacji zazwyczaj skutkuje pokazaniem w programie Outlook komunikatu o błędzie: "Wystąpiły problemy z podpisem. Aby poznać informacje szczegółowe, kliknij ikonę podpisu."(There are problems with the signature. Click the signature button for details). Aby rozwiązać ten problem, należy otworzyć certyfikat w programie Outlook i kliknąć przycisk "Wyświetl urząd certyfikacji" (View Certificate Authority) w wyświetlonym oknie dialogowym. Należy odnaleźć komunikat na karcie Ogólne (General) w oknie dialogowym właściwości certyfikatu. Jeśli wskazuje on, że certyfikat główny urzędu certyfikacji nie jest zaufany i musi zostać zainstalowany, należy przejść do karty Szczegóły (Details). Następnie należy kliknąć przycisk "Kopiuj do pliku" (Copy to File...) i kontynuować pracę z kreatorem, akceptując wszystkie ustawienia domyślne i podając żądaną nazwę pliku oraz folder.
A teraz należy otworzyć nową konsolę programu Microsoft Management Console (MMC) w kontekście administratora maszyny. Należy wybrać opcje Plik (File)|Dodaj/Usuń przystawkę (Add/Remove Snap-in) (Ctrl+M), wybierając element Certyfikaty (Certificates) i dodając go do konta komputera, zaznaczając opcję Komputer lokalny (Local computer) w wyświetlonym oknie dialogowym. Następnie należy rozwinąć węzeł Certyfikaty umieszczony w drzewie po lewej stronie i wykonać to samo dla węzła Zaufane główne urzędy certyfikacji (Trusted Root Certificate Authorities). Kliknąć prawym przyciskiem myszy i wybrać z menu opcję Wszystkie zadania (All Tasks)|Importuj (Import). Następnie należy zaimportować wspomniany wcześniej wyeksportowany plik certyfikatu do Zaufanych głównych urzędów certyfikacji i kliknąć przycisk Zakończ (Finish). Na zakończenie użytkownik powinien ponownie uruchomić program Outlook.
Instrukcje te powinniśmy wykorzystywać jedynie do dodawania głównego urzędu certyfikacji, do którego mamy zaufanie. Nie wszystkie urzędy główne są sobie równe. Należy z rozwagą przeanalizować, kto jest właścicielem i odpowiada za działanie głównego urzędu certyfikacji, przed wykorzystaniem tej metody do dodania urzędu do magazynu dla całego systemu. Jeśli korporacja kontroluje listę zaufanych urzędów głównych za pomocą Zasad Grupy, konfiguracja zostanie zastosowana w systemach klienckich i powyższe instrukcje mogą nie działać. W takiej sytuacji warto rozważyć alternatywne metody wymiany danych, takie jak bezpieczne witryny lub serwery sieci Web, ponieważ wiadomości e-mail nie zapewnią niezauważalnego dla użytkownika i bezpiecznego rozwiązania.
Drugi z wymienionych powyżej problemów, a mianowicie brak możliwości walidowania pośrednich urzędów certyfikacji, pojawia się zazwyczaj w dwóch sytuacjach: system kliencki, który próbuje zweryfikować certyfikat, nie może dotrzeć do lokalizacji Authority Information Access (AIA) zdefiniowanej w certyfikacie lub system kliencki posiada wersję certyfikatu pośredniego urzędu certyfikacji, która nie pasuje do wersji wystawianej przez urząd certyfikacji (system kliencki jest często o jedną lub dwie wersje z tyłu). Obie przyczyny przejawiają się w bardzo podobny sposób w interfejsie użytkownika programu Outlook. Widzimy je jedynie w bardzo specyficznych okolicznościach, gdy pośredni urząd certyfikacji w łańcuchu wygasa i zostaje ponownie autoryzowany, zanim zdążą wygasnąć inne podrzędne certyfikaty, które zostały przez niego wystawione.
Zasadniczo problem pojawia się w wyniku przerwania łańcucha. Pewne nadrzędne certyfikaty mogą nie być wystarczająco opisane lub odpowiednio wbudowane w węzeł liścia, co dodatkowo komplikuje sytuację.
Aby rozwiązać ten problem, nadawca musi otworzyć nową wiadomość i kliknąć Opcje nowej wiadomości, a następnie przycisk Ustawienia zabezpieczeń (Security settings) oraz przycisk Zmień ustawienia (Change settings). Teraz należy kliknąć przycisk Wybierz (Choose) dla certyfikatu podpisywania, a później przycisk Wyświetl certyfikat (View Certificate) w wyświetlonym oknie dialogowym. Następnie przejść do karty Ścieżka certyfikacji (Certificate Path), wybrać wystawcę węzła liścia (to znaczy kolejny wyższy poziom w łańcuchu) i kliknąć przycisk Wyświetl certyfikat, kliknąć kartę Szczegóły (Details) i przycisk Kopiuj plik do... oraz zakończyć prace z kreatorem eksportowania, wybierając opcję PKCS #7 (.P7B). Należy upewnić się, że zaznaczona jest opcja "Załącz wszystkie certyfikaty w ścieżce certyfikacji" (Include all certificates in the certification path), jak pokazano na Rysunku 3. Na zakończenie należy wysłać wyeksportowany plik łańcucha do odpowiedniego odbiorcy.
Rysunek 3: Korygowanie luk w łańcuchu certyfikacji.
Po pozyskaniu wyeksportowanego łańcucha certyfikacji odbiorca będzie musiał otworzyć i zaimportować łańcuch, w podobny sposób w jaki zaimportowany został urząd główny. Główna różnica polega na tym, że wybranym folderem magazynowania powinien być folder Intermediate Certificate Authorities. Jeśli wiadomość zostanie otworzona, a certyfikat określony jako prawidłowy w programie Outlook, wszystko działa tak, jak powinno.
W przypadku trzeciego problemu, niedostępnych list CRL, rozwiązanie jest stosunkowo proste. Początkowa reakcja programu Outlook będzie przypominać reakcję na poprzedni problem. Jednak błąd zostanie zaprezentowany, nawet jeśli główne lub pośrednie urzędy certyfikacji podpisu są zaufane. Dla każdego poziomu łańcucha certyfikacji ponad poziomem liści należy otworzyć właściwości certyfikatu, a następnie kartę szczegółów i spojrzeć na pole o nazwie "Punkty dystrybucji listy CRL" (CRL Distribution Points).
Dla każdego wymienionego punktu dystrybucji listy CRL (w szczególności tych dostępnych z Internetu) należy sprawdzić, czy można otworzyć adres URL pliku CRL. Należy przeprowadzić walidację kolejnych poziomów w łańcuchu. Jeśli którakolwiek z list CRL nie może zostać pobrana, prawdopodobnie to ona jest przyczyną problemów. Aby rozwiązać ten problem należy sprawdzić, czy zasada sieci lokalnej nie blokuje dostępu. W przeciwnym przypadku należy spróbować skontaktować się z firmą będącą właścicielem urzędu certyfikacji lub odczekać, aż punkt dystrybucji listy CRL urzędu certyfikacji ponownie zacznie działać.
Dystrybucja certyfikatów
Dystrybucja to łatwa sprawa. Zasadniczo podpisana wiadomość jest przesyłana na serwer pocztowy, który następnie przesyła ją z jednej lokalizacji do innej przy użyciu znanej i sprawdzonej metody SMTP. Jeden z problemów związanych z podpisaną lub szyfrowaną pocztą w czasie przesyłania polega na tym, że niektóre systemy pocztowe odrzucają lub uszkadzają przekazywane za ich pośrednictwem podpisane lub zaszyfrowane wiadomości. Rozwiązanie tej kwestii wymaga współpracy z menedżerem IT systemu w celu pozyskania dozwolonych typów wiadomości. Oczywiście istnieje ryzyko, iż trzeba będzie pogodzić się z faktem blokowania pewnych typów wiadomości. Strona odbierająca może mieć dobry powód, dla jakiego nie zezwala na stosowanie zaszyfrowanych wiadomości w określonym środowisku operacyjnym.
Szyfrowanie odpowiedzi
Aby stworzyć zaszyfrowaną odpowiedź (przy założeniu, że opisany powyżej proces inicjalizacji został ukończony), nadawca musi jedynie stworzyć wiadomość, a następnie kliknąć przycisk Szyfruj (Encrypt) (żółtą małą kopertę z niebieską kłódką i napisem Szyfruj) w oknie tworzenia wiadomości. Jeśli przycisk Szyfruj nie jest dostępny, należy postępować zgodnie z instrukcją wysyłania podpisanej wiadomości, pomijając ostatni krok i zaznaczając pole wyboru "Szyfruj treść i załączniki wiadomości" (Encrypt message contents and attachments).
Podpisywanie w standardzie S/MIME nie jest niezbędne do wysyłania zaszyfrowanych wiadomości do odbiorcy, ale te dwa mechanizmy dobrze ze sobą współdziałają, ponieważ podpis pozwala osobie czytającej zweryfikować nadawcę (funkcja szyfrująca nie określa nadawcy). Proces szyfrowania to próba zaszyfrowania wiadomości przy użyciu klucza publicznego znanego wszystkim odbiorcom. Jeśli system nie zdoła odnaleźć certyfikatów dla wybranych odbiorców, ich lista zostanie zaprezentowana w oknie dialogowym wraz z propozycją wysłania niezaszyfrowanej wiadomości, jak widać na Rysunku 4.
Rysunek 4: W przypadku napotkania problemów z certyfikatem można zdecydować się na przesłanie niezaszyfrowanej wiadomości.
Domyślnie mechanizm podpisywania i szyfrowania powinien współdziałać z innymi podobnie skonfigurowanymi systemami klienckimi, ale czasem zaszyfrowane lub podpisane wiadomości przesyłane między wersjami mogą mieć kłopoty, gdy algorytm mieszania lub szyfrowania nie jest wspierany. Tego typu problem napotykaliśmy, przesyłając podpisaną wiadomość (przy użyciu algorytmu mieszania SHA-512) do użytkownika z systemem Windows XP SP2. Ponieważ odbierający system nie wspierał algorytmu mieszania, użytkownik nie mógł sprawdzić poprawności podpisu i odczytać wiadomości. Jednak o ile nie zostaną zmienione domyślne ustawienia programu Outlook, użytkownicy nie powinni napotkać wielu problemów na tym etapie.
Po otrzymaniu wiadomości odbiorca powinien mieć możliwość otwarcia jej pod warunkiem, że dostępny jest klucz prywatny powiązany z publicznym certyfikatem . Kolejny raz użytkownik może zostać poproszony o dostarczenie dodatkowego tokenu zabezpieczeń w celu udowodnienia faktu posiadania klucza prywatnego, w zależności od typu rozmieszczenia. Inni użytkownicy, którzy ukończyli analogiczny proces inicjalizacji, mogą wziąć udział w podobnej szyfrowanej i podpisywanej komunikacji z nadawcą. Jeśli użytkownik zmieni w pewnym momencie swój klucz prywatny (na przykład z powodu utraty komputera), będzie musiał ponownie zażądać certyfikatów i rozdystrybuować podpisaną wiadomość lub plik certyfikatu między innymi użytkownikami, którzy chcą wymieniać z nim zaszyfrowane wiadomości.
Podsumowanie
Konfiguracja mechanizmu podpisywania i szyfrowania w standardzie S/MIME między dwoma użytkownikami znajdującymi się w dwóch różnych katalogach lub organizacjach zazwyczaj nie jest dużo bardziej skomplikowana niż zaprezentowane przed chwilą instrukcje. Podpisywanie jest bardzo użyteczne, gdy jest odpowiednio wykorzystywane, ponieważ zwiększa autentyczność wiadomości. Szyfrowane wiadomości zapewniają dodatkowy poziom zabezpieczeń poufnych informacji na etapie przesyłania. Obie te metody w połączeniu ze sobą zapewniają autentyczność źródła i tajność danych. A opisane w tym artykule procesy ułatwiają użytkownikom korzystanie z tych możliwości.
O autorach
Matt Clapham, CISSP, pełni funkcję Security Engineer w dziale Microsoft IT. W dzień odpowiada za analizy zabezpieczeń aplikacji LOB, a w nocy hobbistycznie zajmuje się technologiami, grami, muzyką komputerową i bezpieczeństwem. Okazjonalnie zabiera głos w społeczności Puget Sound IT. Można skontaktować się z nim pod adresem matt.clapham@microsoft.com.
Blake Hutchinson pełni funkcję Support Analyst w grupie Business Online Services Group (BOSG) w firmie Microsoft. Jego rola polega na udzielaniu operacyjnego wsparcia i analizowaniu projektów narzędzi LOB tworzonych wewnętrznie na potrzeby klientów korporacyjnych BOSG. Blake pasjonuje się fotografią, narciarstwem oraz grami komputerowymi. Można skontaktować się z nim pod adresem blakeh@microsoft.com.