Usługi Windows RMS pozwalają precyzyjnie sterować uprawnieniami nie tyle do dokumentów, ile do ich treści.

Zabezpieczanie danych polegało dotychczas na stosowaniu mechanizmów zapewnianych przez systemy operacyjne, głównie poprzez nadawanie atrybutów plikom w systemie plików w postaci praw dostępu. Ponieważ jednak mechanizmy kontroli dostępu do plików są wobec nich "zewnętrzne", nie zabezpieczają zawartych w nich informacji przed prostym skopiowaniem czy na wypadek zgubienia nośnika. Aby je przed tym uchronić, konieczne jest zabezpieczenie samej treści.

Producenci aplikacji od lat pozwalają zabezpieczać pliki za pomocą haseł. Microsoft i Adobe od dawna stosują nie tylko hasła, ale także blokowanie możliwości modyfikacji, wydruku itp. w plikach PDF czy ZIP. Wiele z tych metod można w prosty sposób obejść (np. w przypadku PDF, aby wydrukować dokument, wystarczy posłużyć się przeglądarką inną niż Adobe Reader). Z kolei stałe hasło jest łatwe do złamania.

Znacznie trudniejsze do obejścia są metody zabezpieczania oparte na certyfikatach cyfrowych funkcjonujących w ramach infrastruktury klucza publicznego. Jednym z nich jest system opracowany przez Microsoft - Windows Rights Management System (RMS). Dzięki infrastrukturze do dystrybucji licencji będących pochodnymi (nie: odpowiednikami) certyfikatów cyfrowych, funkcjonalny odpowiednik hasła jest "jednorazowy" i właściwy tylko dla danego dokumentu i konkretnego adresata (adresatów), a przy tym jego ważność jest ograniczona w czasie.

Jak to działa

Mechanizm zabezpieczania, a zwłaszcza "publikacji" i dystrybucji treści w Windows RMS, działa bardzo interesująco. Uczestnik systemu RMS musi się aktywować oraz uzyskać licencję. Aktywacja polega na pobraniu pliku DLL spełniającego rolę "skrytki" odpowiadającej za operacje kryptograficzne i powiązanej z lokalną modułem kryptograficznym.

Następnie użytkownik otrzymuje tzw. licencję GIC (Group Identity Certificate) - certyfikat przypisany jemu, ale jednocześnie powiązany z kluczem aktywacyjnym. Dalsze czynności są związane właśnie z licencją GIC.

W przypadku publikacji, w pierwszym kroku autor rejestruje się w RMS. Otrzymuje swoją "skrytkę" do szyfrowania, a także pobiera certyfikat "publikującego". Następnie określa zasady dostępu do konkretnego dokumentu. Standardowo RMS obsługuje zestaw praw "typowy" dla dokumentów biurowych czy wiadomości e-mail (tylko do odczytu, zakaz zapisu/przesyłania dalej itp.). Ponieważ jednak prawa wyrażane są w języku XrML, zależą praktycznie od tego, co "rozumie" przeglądarka chronionej treści.

Po określeniu licencji publikujący szyfruje treść, używając własnego klucza symetrycznego. Następnie serwer ten klucz koduje, używając własnego klucza. Dopiero wynikowy klucz używany jest do kodowania treści dokumentu przy użyciu szybkiego 128-bitowego algorytmu ASE. Dzięki temu mamy wysokie bezpieczeństwo (klucze serwera i publikującego mają zwykle co najmniej 1024 bitów), a równocześnie samo szyfrowanie nie jest bardzo kosztowne. Dopiero taki plik jest publikowany.

Certyfikat i licencja

Jeżeli inny użytkownik chce otrzymać dostęp do tych informacji, najpierw musi uzyskać indywidualną licencję do treści. Najpierw oczywiście musi się "zarejestrować" w RMS. Warto tu dodać, że nie musi to być ten sam system RMS, którego używa publikujący. Przeglądarka, której używa klient, żąda licencji. Przesyła certyfikat konta odbiorcy (klucz publiczny) oraz licencję, która jest "doklejona" do zabezpieczonego pliku (de facto - zakodowany symetryczny klucz, który może być użyty do odkodowania treści). Serwer RMS sprawdza, czy żądanie jest uprawnione. Na przykład - w treści "polisy" (XrML) dana osoba (czy grupa) może być określona jako "uprawnieni do czytania". Można też określać przeglądarkę, która może żądać dostępu.

Jeżeli odpowiednie warunki są spełnione, serwer tworzy dla danego użytkownika licencję. Najpierw dekoduje klucz symetryczny, używając swojego klucza prywatnego, a następnie koduje go, stosując klucz publiczny użytkownika (dzięki temu z licencji może skorzystać tylko dana osoba). Do licencji dodawane są informacje o cechach "polisy" (czas obowiązywania itp.). Interpretacja tych elementów zależy od sytuacji. Następnie przeglądarka otrzymuje licencję, sprawdza jej poprawność (łańcuch uprawnień itp.), po czym dekoduje pliki i pozwala z nimi pracować zgodnie z tym, co przekazała "polisa".

Duża dawka paranoi

Aby opublikować dokument, trzeba w jakiś sposób przekazać informacje tak, by serwer był w stanie je przetworzyć. W przypadku RMS Microsoft proponuje MHTML - czyli specjalny format MIME, w którym znajduje się zarówno kod (np. HTML), jak i rysunki itp., a więc to, co może być udostępnione w szeroko pojętych technologiach WWW . Technologie MHTML stosuje Internet Explorer, zapisując stronę WWW jako jeden plik (.mht).

Publikowanie informacji w formacie MHTML jest zadaniem względnie prostym. Służy do tego specjalny zestaw bibliotek (RMS Server SDK), który pozwala dokleić informacje o licencji czy kluczach. W SDK dostępny jest przykład witryny do bezpiecznej publikacji dokumentów. Za wyświetlanie treści odpowiada specjalny dodatek do Internet Explorer lub Office 2003. Działanie zgodne z domyślnym scenariuszem zawsze jest proste. Sytuacja komplikuje się, gdy chcemy stworzyć własną przeglądarkę treści zabezpieczonych RMS.

Przeprowadzanie procesu aktywacji czy uzyskiwania licencji to tak naprawdę kwestia wywołania odpowiednich funkcji bibliotecznych. Jednak główna trudność tkwi w takim napisaniu tej "przeglądarki", by nie było możliwe użycie jej niezgodnie z przeznaczeniem. Programista musi pamiętać o tym, że np. duży obszar pamięci może być przeniesiony do pliku wymiany i tam (potencjalnie) odczytany przez inny, złośliwy kod.

Dekodowanie trzeba organizować tak, by były używane jak najmniejsze porcje pamięci - tak by w danym momencie w pamięci RAM nie był dostępny np. cały dokument. W przypadku polecenia dump (zrzut zawartości pamięci na dysk po zawieszeniu się programu) może się znaleźć właśnie taki zdekodowany plik. Kolejna sprawa dotyczy kanałów komunikacyjnych - jeżeli przeglądarka już zdekoduje treść, może z nią zrobić cokolwiek. Byłoby lepiej, gdyby np. dokument nie był przesyłany dalej jako np. niezakodowany pakiet SOAP.

Kolejna kwestia dotyczy "bibliotek firm trzecich". Programista może ufać własnemu kodowi, ale zwykle musi też wskazać, jakie biblioteki zewnętrzne mogą być używane. Z tym problemem Microsoft poradził sobie w dosyć oczywisty sposób - kod używający funkcji klienckich RMS musi mieć manifest, który określa, jakie biblioteki mogą być wczytane przez program.

Wciąż na etapie testów

Obecnie, oprócz zainstalowania własnego serwera RMS (Windows 2003), można skorzystać z darmowej infrastruktury serwerów MSN - udostępniają one zarówno mechanizmy aktywacji, jak i certyfikacji dostosowane głównie do Office 2003, ale z powodzeniem można na tym testować własne rozwiązania. Microsoft podkreśla, że jest to wciąż usługa testowa - będzie działać przez co najmniej 3 miesiące od uzyskania certyfikatu.

RMS ma zastosowanie wszędzie tam, gdzie konieczne jest zabezpieczenie nie tyle "dostępu" do danego elementu, ile pewnej treści. W porównaniu z bardzo szybkim mechanizmem kontroli dostępu opartym na listach dostępowych (ACL), RMS wydłuża nieco czas otwierania dokumentu (mniej więcej o 1 s). Użytkownik musi każdorazowo otrzymać unikatową licencję dla danej treści (w przypadku dostępu offline licencja może być buforowana).