Podpisywanie dokumentu XML podpisem cyfrowym. Jak poprawnie podpisać plik podpisu cyfrowego. Moduły oprogramowania platformy Polygon Pro
Przez długi czas Dla mnie najbardziej palącym pytaniem było, jak i czym podpisywać dokumenty i pliki XML podpisem elektronicznym lub podpisem cyfrowym. Dobrze, gdy jesteś w biurze i masz wszystkie programy do podpisywania dokumentów i Pliki XML, zainstalowany w Twoim miejscu pracy. Ale w mojej pracy często zdarzały się sytuacje, gdy trzeba było sporządzić i podpisać dokumenty, pliki XML, będąc daleko od miejsca pracy lub, jak zawsze, zrobić to pilnie i teraz, będąc w domu. Kup i zainstaluj oprogramowanie Podpisywanie się elektronicznym podpisem cyfrowym, także w domu, czy na laptopie i noszenie go zawsze przy sobie, jest zbyt drogie. Następnie zabrałem się za poszukiwania w Internecie swobodnie rozpowszechnianych programów, które umożliwiają podpisywanie dokumentów i plików XML elektronicznym podpisem cyfrowym – EDS. To właśnie te programy, a także jeden płatny, rozważymy poniżej.
Aby zostać wysłanym do Rosreestr, co jest obowiązkowe, wszystkie dokumenty muszą być podpisane elektronicznym podpisem cyfrowym (elektroniczny podpis cyfrowy), a czasami trzeba sprawdzić swój własny lub cudzy podpis cyfrowy.
A więc przyjrzyjmy się, jak i co oprogramowanie Elektronicznym podpisem cyfrowym możesz podpisać dokument lub plik XML. Jednym z programów jest GIS „Panorama” – „Map-2011” w wersji 11.10.4. Podpisywanie dokumentów działa nawet w wersji niezarejestrowanej. Procedura podpisywania dokumentów, plików Lista programów umożliwiających podpisywanie dokumentów, plików XML, EDS (elektroniczny podpis cyfrowy) do wymiany danych z portalem usług publicznych Służba federalna rejestracja państwowa, kataster i kartografia, Rosreestr, przez Internet elektroniczny podpis cyfrowy wygląda następująco: uruchom „Map-2011” lub „Map-mini”, naciśnij „F12”, wywołując menu uruchamiania aplikacji. W wyświetlonym oknie wybierz zadanie dokumenty elektroniczne, Dalej Tworzenie elektronicznego podpisu cyfrowego
Plik podpisu: wybierz plik, który ma zostać podpisany, i odpowiednio wymagany certyfikat w certyfikacie. To wszystko, Twój dokument lub plik XML jest podpisany podpisem elektronicznym. Jeśli chcesz sprawdzić istniejący podpis, wybierz plik podpisu (plik z rozszerzeniem „sig”). Oficjalna strona internetowa GIS „” .
Drugim programem do podpisywania dokumentów i plików XML jest CryptoLine. Darmowy, w pełni funkcjonalny, pozwala na podpisywanie i szyfrowanie dokumentów, a także sprawdzanie podpisów cyfrowych. Pobierać ten program Możesz z oficjalnej strony internetowej lub pobrać poprzez bezpośredni link ze strony tej witryny. Praca z programem jest prosta i wygodna. Wybierz i dodaj pliki, które chcesz podpisać, następnie wybierz certyfikat, którym chcesz podpisać dokumenty, pliki XML i podpisz dokumenty. Bądź ostrożny - wybierz do podpisania tylko jeden certyfikat!!! W przeciwnym razie dokumenty zostaną podpisane dokładnie taką liczbą certyfikatów, jaką dodasz do programu. Instrukcje użytkowania znajdują się w archiwum programu. Poniżej podam przykład podpisania dostawy do Rossreestr.
Po zainstalowaniu programu i uruchomieniu go dodaj do programu pliki, które wymagają podpisu. Zakładka „Akcje”, przycisk „dodaj”.
Aby podpisać wszystkie pliki na raz, musisz je wszystkie zaznaczyć - „Shift + prawy przycisk mysz” lub „Shift + strzałka w dół”. Następnie kliknij „Podpisz” i w wyświetlonym oknie dodaj certyfikat lub pozostaw wybrany wcześniej lub zmień go na inny. Jeszcze raz pamiętam, że do przesłania do Rosreestr w tym oknie nie powinien znajdować się więcej niż 1 certyfikat! Skonfiguruj także wszystkie ustawienia zgodnie z rysunkiem:
Podpiszmy. Po podpisaniu pliki z rozszerzeniem „sigO” zostaną dodane do Twojej listy. To jest podpis pliku. Pozostaje tylko przesłać pliki podpisów lub wszystkie pliki (według własnego uznania). Wybierz, co chcesz przesłać, w tym przypadku trzy pliki podpisów, i kliknij „Prześlij”. To chyba wszystko. Ale jak wszyscy inni darmowy ser jest mały niuans. Rosreestr przeklina rozszerzenie pliku „sigO”, więc potrzebujesz go w Eksploratorze lub w dowolnym innym menedżer plików zmień nazwę rozszerzenia z „sigO” na „sig”.
Podpis tego programu nie został zweryfikowany przez stronę internetową Rosreestr. Weryfikacja podpisu została przeprowadzona przez oprogramowanie współpracujące z portalem usług rządowych Federalnej Służby Rejestracji Państwowej, Katastru i Kartografii. Wszystkie trzy programy sprawdzające sygnaturę wykonaną przez ten program dały wynik pozytywny. Kontrolę przeprowadziły wskazane tutaj programy, GIS „Panorama”, Crypto ARM oraz program Polygon-Land Survey Plan. Podpis również został zweryfikowany serwis internetowy weryfikację autentyczności elektronicznego podpisu cyfrowego w serwisie.
Kolejnym programem do podpisywania dokumentów i plików XML jest . Można go pobrać z oficjalnej strony programu. Sam program jest dość funkcjonalny i atrakcyjny, koszt nie jest wysoki, tylko 1200 rubli za 1 Miejsce pracy. Jest technologia. wsparcie, a także wszechstronną pomoc. Najbardziej kompletne i aktualne informacje można uzyskać pod adresem. Przeczytaj także o EDS w notatce
Szlachetny cel uszlachetnia działania w imię tego celu.
K.LiebknechtaObecnie staje się ML, czyli eXtensible Markup Language w standardowy sposób przenoszenie informacji do sieci (i nie tylko). Co więcej, pojawia się coraz więcej dodatków wykorzystujących składnię XML (aplikacje XML). Należą do nich na przykład uproszczony protokół dostępu do obiektów SOAP (Simple Object Access Protocol), w którym XML działa jako uniwersalny sposób reprezentowania parametrów do wywoływania zdalnych procedur RPC (Remote Procedury Call). Innym przykładem wtyczki jest framework RDF (Resource Opis Framework). Możesz zajrzeć do konsorcjum World Wide Web Consortium (W3C), które opracowuje standardy w tej dziedzinie (http://www.w3.org/), i zobaczyć, że XML rzeczywiście cieszy się coraz większym zainteresowaniem.
Przypomnijmy, że głównym celem XML-a jest opisanie struktury i semantyki dokumentu. Główną zaletą XML w porównaniu z innymi formatami dokumentów elektronicznych jest to, że oddziela opis zewnętrznej prezentacji dokumentu od struktury dokumentu i jego zawartości. XML to elastyczny język, którego można używać do różnych celów i który może współpracować z wieloma systemami i bazami danych. Dlatego dzisiaj XML jest używany w wielu krajach systemy informacyjne jako główny format wymiany danych. Co więcej, producenci systemów zarządzania bazami danych zrobili potężny krok w kierunku XML. Na przykład firma Oracle udostępniła narzędzie XSU (XML-SQL Utility), które jest dodatkiem do JDBC umożliwiającym przechowywanie i pobieranie danych XML z bazy danych (http://otn.oracle.com/tech/xml/ xdk_java/content .html). XSU to hierarchia klas Java zaprojektowana do przekształcania danych z tabel i widoków obiektowo-relacyjnych baz danych do formatu XML, wstawiania danych z dokumentów XML do tabel i widoków oraz wykonywania innych przydatnych operacji.
Konieczność ochrony dokumentów XML
ML to potężne narzędzie często wykorzystywane do wymiany danych przez Internet. Ale niestety sam w sobie nie zapewnia niezbędnej ochrony danych, które „przenosi”. Innymi słowy, istnieją poważne problemy bezpieczeństwo podczas korzystania z formatu XML (podobnie jak w przypadku innych formatów).
XML można łatwo wykorzystać do przesyłania komunikatów transakcyjnych pomiędzy bankiem a bankomatem, poufnych lub półpoufnych informacji o osobach, informacji o transakcjach elektronicznych lub po prostu do przesyłania zastrzeżonych dokumentów w tym formacie. Jednocześnie jednak konieczne jest zapewnienie ochrony informacji przed mimowolnymi lub celowymi zniekształceniami zarówno ze strony użytkowników systemów informatycznych, jak i przekazywanych kanałami komunikacji. Ochrona powinna opierać się na następujących funkcjach:
- uwierzytelnianie wchodzących w interakcję stron;
- potwierdzanie autentyczności i integralności informacji;
- kryptograficzne zamknięcie przesyłanych danych.
Aby zapewnić ochronę tych informacji, zaleca się stosowanie elektronicznego podpisu cyfrowego (EDS) i metod szyfrowania danych. Co więcej, podpis cyfrowy z reguły zapewnia uwierzytelnienie, potwierdzenie autentyczności i integralności, a zamknięcie danych odbywa się poprzez szyfrowanie.
Ogólne informacje o elektronicznych podpisach cyfrowych
EDS i możliwość jego sfałszowania
Elektroniczny podpis cyfrowy są to dane dodane do pierwotnego bloku informacji (dokumentu), uzyskane w wyniku jego kryptograficznej transformacji (w zależności od tajnego klucza i pierwotnego bloku informacji lub dokumentu). EDS zapewnia integralność wiadomości (dokumentów) z gwarancją identyfikacji ich autora (osoby, która podpisała dokument), najczęściej przesyłanych niechronionymi publicznymi kanałami telekomunikacyjnymi.
Weryfikacja elektronicznego podpisu cyfrowego bloku informacji odbywa się poprzez kryptograficzną transformację podpisu cyfrowego przy użyciu klucza publicznego odpowiadającego tajnemu kluczowi, który brał udział w procesie instalowania podpisu cyfrowego.
Niemożność sfałszowania elektronicznego podpisu cyfrowego osiąga się za pomocą bardzo dużej liczby obliczeń matematycznych (na przykład niemożność sfałszowania podpisu może wynikać ze złożoności rozwiązania problemu logarytmu dyskretnego w polu p elementów El-Gamala schemat podpisu). Złożenie podpisu na dokumencie nie powoduje zmiany samego dokumentu, a jedynie umożliwia weryfikację autentyczności i autorstwa otrzymanych informacji (czyli do samego dokumentu lub oddzielnie od niego dodawany jest blok danych – podpis cyfrowy ten dokument).
Urząd certyfikacji
Powyżej wspomnieliśmy o terminach „klucz prywatny” i „klucz publiczny”. Skąd wzięły się te klucze? Tworzy je urząd certyfikacji - pewna struktura (organizacja) zarządzająca certyfikatami. Certyfikat klucza publicznego/prywatnego reprezentuje następujący zestaw danych:
- nazwa podmiotu lub przedmiotu systemu, która jednoznacznie identyfikuje go w systemie;
- klucz publiczny/prywatny podmiotu lub obiektu systemu;
- dodatkowe atrybuty określone przez wymagania dotyczące wykorzystania certyfikatu w systemie;
- elektroniczny podpis cyfrowy wydawcy (organu certyfikującego), potwierdzający całość tych danych.
Zatem na przykład certyfikat klucza prywatnego zawiera sam klucz prywatny i Dodatkowe informacje do niego.
Dla każdego zarejestrowanego użytkownika systemu informatycznego centrum certyfikacji (CA) generuje dwa certyfikaty: certyfikat klucza prywatnego i certyfikat klucza publicznego. W takim przypadku pierwsze SO jest wydawane osobiście zarejestrowanemu użytkownikowi (na przykład na dyskietce) i nikomu innemu - jest to „podpis”. Drugi certyfikat, otwarty, jest publikowany przez urząd certyfikacji w publicznym repozytorium, tak aby każdy zainteresowany mógł go łatwo odnaleźć.
Generowanie i weryfikacja podpisu cyfrowego
Nadawca informacji, wykorzystując tajny klucz i algorytm asymetryczny (algorytm podpisu cyfrowego) wybrany wcześniej w drodze umowy pomiędzy abonentami, szyfruje przesyłaną informację przedstawioną w postaci cyfrowej i tym samym otrzymuje cyfrowy podpis danych. Następnie nadawca informacji przesyła do odbiorcy niezaszyfrowaną informację wraz z uzyskanym w sposób opisany powyżej podpisem cyfrowym za pośrednictwem otwartego kanału komunikacji.
Odbiorca wiadomości za pomocą klucza publicznego (który jest publicznie dostępny) oraz algorytmu podpisu cyfrowego wybranego w drodze porozumienia między subskrybentami, odtajnia podpis cyfrowy. Następnie porównuje otrzymane niezaszyfrowane informacje z informacjami uzyskanymi podczas deszyfrowania podpisu cyfrowego. Jeżeli podpis cyfrowy nie został sfałszowany, a przesyłana informacja jawna nie jest zniekształcona, wówczas te dwie informacje powinny całkowicie do siebie pasować. Jeśli podpis zostanie sfałszowany, otrzymana informacja jawna i informacja uzyskana podczas deszyfrowania będą się znacząco różnić (ryc. 1).
Funkcje mieszające
W powyższym schemacie interakcji nadawcy i odbiorcy brakuje jednej operacji. Związany jest z etapem szyfrowania danych, podczas którego tworzony jest elektroniczny podpis cyfrowy. Jeśli po prostu wygenerujemy podpis cyfrowy, okaże się, że (w zależności od algorytmu) będzie on z reguły mniej więcej tej samej długości co oryginalny blok danych i będziemy musieli przesłać przez sieć wiadomość o podwójnej długości. Oczywiście miałoby to negatywny wpływ na całe działanie systemu. Dlatego wcześniej generacji podpisu cyfrowego oryginalne dane są przetwarzane przy użyciu funkcji skrótu, dzięki czemu podpis staje się zwarty. Oczywiście, aby uzyskać poprawny wynik, odbiorca musi dokonać tej samej transformacji na odebranym bloku danych.
Używana funkcja skrótu musi umożliwiać konwersję komunikatu o dowolnej długości na sekwencję binarną o stałej długości. Ponadto musi spełniać następujące wymagania:
- wiadomość po zastosowaniu funkcji skrótu musi zależeć od poszczególnych bitów oryginalnej wiadomości i ich kolejności;
- Używając zaszyfrowanej wersji wiadomości, nie ma możliwości zrekonstruowania samej wiadomości.
Zrozumienie szyfrowania
Szyfrowanie danych i jego różnica w stosunku do podpisu cyfrowego
Szyfrowanie informacji transformacja matematyczna (kryptograficzna) jeden do jednego w zależności od klucza (tajnego parametru transformacji), który pasuje do bloku otwarte informacje, prezentowany w pewnym kodowaniu cyfrowym, blok zaszyfrowanej informacji, również prezentowany w kodowaniu cyfrowym. Szyfrowanie łączy w sobie dwa procesy: szyfrowanie i deszyfrowanie informacji (ryc. 2).
Podstawowa różnica między podpisem cyfrowym a metodami szyfrowania (rozważamy obecnie algorytmy asymetryczne, w których do szyfrowania i deszyfrowania używane są różne, ale matematycznie powiązane klucze) polega na tym, że podczas szyfrowania używany jest klucz publiczny odbiorcy, a podczas deszyfrowania klucz prywatny , natomiast w Algorytm podpisu cyfrowego wymaga tajnego klucza autora do podpisania wiadomości oraz klucza publicznego autora wiadomości do weryfikacji podpisu cyfrowego.
Łamanie
Teoretycznie każdy algorytm szyfrowania wykorzystujący klucz można złamać, przeszukując wszystkie wartości klucza. Jeśli klucz zostanie wybrany, wymagana moc komputera rośnie wykładniczo wraz z długością klucza. Klucz 32-bitowy wymaga 232 (około 109) kroków. To zadanie jest w zasięgu każdego amatora i można je rozwiązać komputer domowy. Systemy z kluczem 40-bitowym (np. eksportowana amerykańska wersja algorytmu RC4) wymagają 240 kroków, taką moc komputera posiada większość małych firm. Otwarcie systemów z kluczami 56-bitowymi (DES) wymaga znacznego wysiłku, ale można je łatwo otworzyć za pomocą specjalnego sprzętu. Koszt takiego sprzętu jest znaczny, ale jest dostępny dla mafii, dużych firm i rządów. Klucze o długości 64 bitów mogą obecnie otwierać duże państwa, a za kilka lat będą mogły je otwierać organizacje przestępcze, duże firmy i małe państwa. W przyszłości klucze 80-bitowe mogą stać się podatne na ataki. Klucze o długości 128 bitów prawdopodobnie pozostaną nie do złamania przy użyciu brutalnej siły w dającej się przewidzieć przyszłości. Można również zastosować dłuższe klawisze.
Długość klucza to jednak nie wszystko. Wiele szyfrów można złamać bez wypróbowywania wszystkich możliwych kombinacji, ale przy użyciu specjalnego algorytmu (na przykład ze złożonością wielomianową). Ogólnie rzecz biorąc, bardzo trudno jest wymyślić szyfr, którego nie dałoby się otworzyć inną metodą, skuteczniejszą niż brutalna siła.
Należy pamiętać, że system kryptograficzny jest tak mocny, jak jego najsłabsze ogniwo. Nie należy pomijać żadnego aspektu projektu systemu, począwszy od wyboru algorytmu, a skończywszy na zasadach wykorzystania kluczowych elementów i zasadach dystrybucji.
Elektroniczny podpis cyfrowy dokumentów XML
Osoby pracujące z XML od dawna rozumieją znaczenie kontroli nad danymi przesyłanymi i reprezentowanymi w formacie XML. Główne wymagania dotyczące przesyłanych danych to uwierzytelnianie współpracujących stron oraz potwierdzenie autentyczności i integralności informacji zawartych w dokumencie XML. Takie problemy rozwiązuje cyfrowy podpis dokumentów XML.
Specyfikacje podpisu cyfrowego XML z W3C
W3C pracuje obecnie nad specyfikacją składni i przetwarzania podpisu XML oraz innymi powiązanymi dokumentami. Na razie ma status rekomendacji (http://www.w3.org/TR/xmldsig-core/). Dokument ten umożliwia podpisanie zarówno całego dokumentu XML, jak i jego części. Aby proces podpisywania XML był unikalny, zdefiniowano koncepcję kanonicznej reprezentacji danych XML. Na przykład w dokumencie XML znaczniki znajdujące się na tym samym poziomie w drzewie hierarchii mogą być ze sobą mieszane, co powoduje niejednoznaczność procesu podpisywania. Kanoniczna reprezentacja XML jest rodzajem sortowania (a raczej redukcji do najprostsza forma), który nie pozwala na taką swobodę. Metody i zasady kanonizacji XML zostały opisane w odrębnym dokumencie „Canonical XML” (http://www.w3.org/TR/xml-c14n), który również ma status rekomendacji. Inne materiały dotyczące podpisywania dokumentów XML są dostępne pod adresem: http://www.w3.org/Signature/.
Etykietka Podpis XML
Zalecenie „Składnia i przetwarzanie podpisu XML” precyzuje, że podpis i informacje na jego temat powinny znajdować się w tagu
- Metoda CanonicalizationMethod definiuje określony zestaw reguł upraszczających i porządkujących wystąpienie XML przed podpisaniem. Informacja ta gwarantuje, że podpisane dane są w prawidłowej formie, tak aby algorytm weryfikacji dał wynik pozytywny, jeśli dane dotyczące treści nie uległy zmianie;
- metoda podpisu (SignatureMethod) definiuje algorytm podpisu skrótu wiadomości. Skrót wiadomości to unikalny ciąg znaków o stałym rozmiarze, będący wynikiem przetwarzania danych przy użyciu jednokierunkowej funkcji skrótu określonej przez metodę skrótu;
- metoda skrótu (DigestMethod) algorytm kompilacji skrótu wiadomości podpisanej przy użyciu danej metody podpisu. Określenie konkretnej metody podsumowania gwarantuje, że dane będą przetwarzane w ten sam sposób;
- wartość skrótu (DigestValue) sam skrót wiadomości, czyli ciąg o stałej długości powstały w wyniku przetwarzania danych przy użyciu algorytmu skrótu. Ciąg taki jest unikalny i nieodwracalny: praktycznie nie da się go uzyskać z innej treści, ani nie da się odtworzyć z niego oryginalnych danych. To jak odcisk palca dla podpisywanych danych; pozytywne porównanie wartości skrótu gwarantuje integralność treści;
- sam podpis (SignatureValue) są to dane uzyskane po przetworzeniu metodą podpisu;
- informacja o kluczu publicznym (KeyInfo) służącym do weryfikacji podpisu cyfrowego. Dokładniej, nie klucz, ale certyfikat, ponieważ w nim oprócz samego klucza można wskazać nazwisko właściciela i algorytm podpisu cyfrowego.
Nie jest to oczywiście wyczerpująca informacja o tym, co może zawierać znacznik.
Tworzenie podpisu cyfrowego XML
Należy zaznaczyć, że istnieją pewne różnice pomiędzy procesem podpisywania XML a klasycznym. Faktem jest, że proces podpisywania instancji XML rozpoczyna się od kanonizacji, czyli uproszczenia struktury danych. Jak już wspomniano, procedura ta jest konieczna, aby podpis cyfrowy mógł zostać poprawnie zweryfikowany dla tego samego dokumentu XML, prezentowanego na różne sposoby. Oznacza to, że przed podpisaniem wszystkie dokumenty XML muszą zostać przekonwertowane do jednej postaci kanonicznej. Pozostałe kroki są takie same, jak w przypadku standardowego procesu dodawania podpisu cyfrowego: dla danych tworzona jest wartość skrótu przy użyciu określonej metody, następnie wartość ta jest podpisana kluczem prywatnym autora dokumentu.
Weryfikacja podpisu cyfrowego XML
Aby zweryfikować podpis, należy wykonać dwa kroki: weryfikację samego podpisu oraz weryfikację wartości skrótu.
Sam podpis jest najpierw weryfikowany, aby zapewnić autentyczność jego właściciela i zapobiec jego odrzuceniu. Następnie sprawdzana jest wartość skrótu, aby upewnić się, że dane nie uległy zmianie, oraz weryfikowana jest integralność treści dokumentu XML.
Szyfrowanie dokumentów XML
Specyfikacje W3C dotyczące szyfrowania XML
Przejdźmy do szyfrowania, które pozwala nam zamknąć (czyli przekształcić do postaci o niejasnym znaczeniu) przesyłane dane i przywrócić je po stronie odbierającej. Konsorcjum W3C utworzyło grupę roboczą (http://www.w3.org/Encryption/2001/), która zajmuje się konkretnie kwestiami szyfrowania danych XML. Specyfikacja składni i przetwarzania szyfrowania XML jest obecnie zaleceniem i jest dostępna pod adresem: http://www.w3.org/TR/xmlenc-core/.
Etykietka
- metoda szyfrowania (EncryptionMethod) opisuje algorytm szyfrowania danych. Jeżeli brakuje tego tagu, to algorytm szyfrowania musi być znany stronie odbierającej, w przeciwnym razie odszyfrowanie wiadomości nie będzie możliwe;
- zaszyfrowane dane (CipherData) rzeczywiste zaszyfrowane dane lub link do ich lokalizacji. Różnorodność typów danych podlegających szyfrowaniu i sposobów ich logicznej organizacji jest praktycznie nieograniczona;
- informacje o kluczach (KeyInfo) informacje o kluczach, za pomocą których wykonywane jest szyfrowanie i odpowiednio deszyfrowanie. Można je przechowywać w innym miejscu i zastąpić w instancji XML łączem URL;
- inne informacje (na przykład o zamierzonych odbiorcach).
Przykład tagu
Proces szyfrowania i deszyfrowania
Szyfrowanie Dane XML tworzone przy użyciu tradycyjnych metod kryptografii klucza publicznego. W pierwszej kolejności szyfrowane są same dane, zwykle przy użyciu losowo wygenerowanego tajnego klucza, który następnie jest również szyfrowany przy użyciu klucza publicznego zamierzonego odbiorcy. Informacje te są spakowane w taki sposób, że tylko zamierzony odbiorca może wyodrębnić tajny klucz i odszyfrować dane. Tajny klucz służy do odszyfrowania tajnego klucza, a następnie dane są odszyfrowywane przy użyciu znalezionego tajnego klucza.
Implementacja ochrony dokumentów XML
Dokonaliśmy przeglądu ogólnych zasad działania elektronicznych podpisów cyfrowych oraz specyfikacji opracowanych w tym obszarze przez konsorcjum W3C. Wszystko fajnie, ale co jeśli faktycznie zaistnieje potrzeba wdrożenia opisanych schematów ochrony danych XML?
Już dziś, pomimo tego, że standardy W3C pojawiły się całkiem niedawno, niektóre firmy ogłosiły wypuszczenie swoich pakietów (bibliotek klas), które implementują zarówno podpis cyfrowy, jak i szyfrowanie. Przyjrzyjmy się możliwościom niektórych z nich.
Pakiet zabezpieczeń XML (IBM)
Ten pakiet językowy Programowanie w Javie, dostępny pod adresem http://www.alphaworks.ibm.com/tech/xmlsecuritysuite. XML Security Suite to narzędzie zapewniające funkcje zabezpieczeń, takie jak podpisywanie cyfrowe, szyfrowanie i kontrola dostępu do dokumentów XML. Z jego pomocą możesz osiągnąć Wielki sukces zamiast korzystać z możliwości protokołów bezpieczeństwa warstwy transportowej (na przykład Secure Sockets Layer, SSL).
Pakiet ten implementuje trzy technologie:
- Podpis cyfrowy jest oparty na specyfikacji „Składnia i przetwarzanie podpisu XML” opracowanej przez W3C i IETF (oraz na specyfikacji „Canonical XML”);
- szyfrowanie jest realizowane w oparciu o specyfikację „Składnia i przetwarzanie szyfrowania XML” firmy W3C;
- kontrola dostępu do dokumentów XML (język kontroli dostępu XML).
XML Security Suite jest jednym z najlepszych nowoczesne środki do ochrony dokumentów XML. Oprócz samego archiwum (JAR) z biblioteką klas, zawiera szczegółową dokumentację i przykłady, które pozwalają szybko poruszać się po hierarchii klas.
Bezpieczeństwo XML (Apache)
Ochrona danych w oparciu o XML
Język znaczników potwierdzenia zabezpieczeń (SAML)
Obszarem odmiennym od ochrony danych XML, choć ściśle z nim powiązanym, jest poprawa bezpieczeństwa i ochrony systemów (protokołów) opartych na XML. W tym przypadku inne dokumenty/systemy/aplikacje są chronione przy użyciu XML. Obecnie komitet ds. bezpieczeństwa Organizacji na rzecz Rozwoju Standardów Informacji Strukturalnej (OASIS) opracowuje język znaczników bezpieczeństwa (SAML).
Ustawa federalna „O elektronicznym podpisie cyfrowym”
Cele
Zróbmy sobie małą przerwę od ustawodawców w dziedzinie sieci i rozważmy ustawę federalną „O elektronicznym podpisie cyfrowym”, zatwierdzoną przez Prezydenta Federacji Rosyjskiej 10 stycznia 2002 r. (http://www.internet-law .ru/intlaw/laws/ecp.htm). Przyjęcie tej ustawy stworzyło warunki prawne stosowania elektronicznych podpisów cyfrowych w dokumentach elektronicznych, z zastrzeżeniem, że elektroniczny podpis cyfrowy w dokumencie elektronicznym jest uznawany za równoważny podpisowi odręcznemu w dokumencie papierowym. W ten sposób położono podwaliny pod stworzenie prawnie istotnego elektronicznego zarządzania dokumentami.
Warunki równoważności podpisu elektronicznego i podpisu zwykłego
Ustawa definiuje podstawowe pojęcia stosowane w procedurze podpisu cyfrowego, takie jak certyfikat, klucze publiczne i prywatne, potwierdzenie autentyczności elektronicznego podpisu cyfrowego (badaliśmy je wcześniej) itp. Ponadto ustawa określa warunki, na jakich elektroniczny podpis cyfrowy w dokumencie elektronicznym jest równoważny podpisowi w dokumencie papierowym. Oznacza to przede wszystkim, że certyfikat klucza podpisu związany z tym elektronicznym podpisem cyfrowym nie wygasł w momencie weryfikacji lub w momencie składania podpisu dokument elektroniczny. Ponadto należy potwierdzić autentyczność elektronicznego podpisu cyfrowego oraz upewnić się, że podpis cyfrowy jest używany zgodnie z informacjami określonymi w certyfikacie klucza podpisu.
Certyfikaty i urzędy certyfikujące
Ustawa szczegółowo opisuje, z czego składa się certyfikat klucza podpisu (unikalny numer rejestracyjny, imię i nazwisko właściciela, publiczny klucz podpisu cyfrowego, nazwa i lokalizacja centrum certyfikacji itp.); warunki i tryb przechowywania certyfikatu w centrum certyfikacji. Tym samym okres przechowywania certyfikatu klucza podpisu w formie dokumentu elektronicznego w centrum certyfikacji określa umowa pomiędzy centrum certyfikacji a właścicielem certyfikatu klucza podpisu. Jeśli chodzi o przechowywanie, określa to prawo Federacja Rosyjska o archiwach i pracy archiwalnej.
Osobny rozdział ustawy poświęcony jest centrom certyfikacji. Proces opracowywania i weryfikacji elektronicznego podpisu cyfrowego może odbywać się bez udziału ośrodków certyfikacji, jeżeli zostanie to potwierdzone umową między stronami. Jednak w publicznych systemach informacyjnych oraz w wielu korporacyjnych systemach informatycznych stosowanie podpisów cyfrowych bez funkcjonowania centrów certyfikacji jest niemożliwe, ponieważ doprowadzi to do dość prostych mechanizmów fałszowania podpisu.
Klucze prywatne (tajne).
Elektroniczny podpis cyfrowy może spełniać swoje funkcje tylko wtedy, gdy podpisujący dysponuje informacjami niedostępnymi dla obcych osób. Informacje te przypominają klucz szyfrujący i dlatego nazywane są „kluczem prywatnym elektronicznego podpisu cyfrowego” (wcześniej używano podobnego określenia „tajny klucz”). Konieczne jest zachowanie w tajemnicy zarówno klucza prywatnego, jak i klucza szyfrującego, gdyż znajomość prywatnego klucza podpisującego odpowiada czystej kartce papieru z podpisem właściciela klucza prywatnego, na której atakujący może napisać dowolny tekst, który będzie przypisać prawdziwemu właścicielowi klucza prywatnego. Sztuka. 12 ustawy wprost wskazuje obowiązek właściciela certyfikatu klucza podpisu do zachowania tajemnicy klucza prywatnego i niezwłocznego żądania zawieszenia certyfikatu klucza podpisu, jeżeli zachodzi podejrzenie, że tajemnica klucza podpisu prywatnego została naruszona.
Sztuka. 5 ustawy określa tryb tworzenia kluczy podpisu prywatnego z uwzględnieniem ścisłego zachowania tajemnicy ich tworzenia. Na tę samą okoliczność wskazuje także art. 9 ustawy o działalności ośrodków certyfikacji. W korporacji struktury informacyjne kwestię produkcji i dystrybucji kluczy prywatnych EDS można rozwiązać naszymi własnymi metodami, jednakże użytkownik EDS musi być świadomy możliwe konsekwencje taka organizacja funkcjonowania podpisu cyfrowego. Jest całkiem możliwe, że jako klucz prywatny zostanie użyta pewna regularna sekwencja, tak jak ma to miejsce w przypadku korzystania z systemu haseł.
Krajowe standardy algorytmów podpisu cyfrowego
Schemat El Gamala
W 1994 roku przyjęto pierwszy krajowy standard w dziedzinie podpisu cyfrowego GOST R34.10 94” Technologia informacyjna. Ochrona informacji kryptograficznej. Procedury opracowywania i weryfikacji elektronicznego podpisu cyfrowego w oparciu o algorytm kryptografii asymetrycznej.” Definiuje procedury pracy z podpisami cyfrowymi w oparciu o schemat ElGamal. Niemożność sfałszowania podpisu wynika ze złożoności rozwiązania problemu logarytmu dyskretnego w polu p elementów lub złożoności wyznaczenia liczby x danej dużej liczbie pierwszej p oraz liczb a, b z przedziału od 2 do p-1, który przeprowadza się przez porównanie:
Ax==bmodp.
Matematycy nie stoją jednak w miejscu i działają Ostatnio Duży postęp nastąpił w opracowaniu metod rozwiązywania problemu logarytmu dyskretnego w polu p elementów. Ostatnio powstała tzw. metoda sita pól liczbowych. Za jego pomocą można zhakować podpis cyfrowy wygenerowany powyższą metodą (przynajmniej w przypadku 512-bitowego modułu p).
Jednym z najprostszych rozwiązań tego problemu jest zwiększenie długości modułu p. Ale niestety wraz ze wzrostem p pogarszają się właściwości operacyjne algorytmu, ponieważ zwiększa się długość klucza publicznego oraz czas generowania i weryfikacji podpisu.
Krzywa eliptyczna
Rosyjscy naukowcy ostatecznie doszli do wniosku, że można nieco skomplikować schemat El-Gamala i w ten sposób bez dodatkowych kosztów obliczeniowych zwiększyć złożoność fałszowania podpisu cyfrowego wiele tysięcy razy. Nowa wersja schematu ElGamala wykorzystuje aparat krzywych eliptycznych na skończonym polu p elementów, które definiuje się jako zbiór par liczb (x, y) (każda z nich mieści się w przedziale od 0 do p-1 ) spełniający porównanie (liczby a i b są stałe i odpowiadają dodatkowemu warunkowi):
Y2 == x3 + topór + bmodp.
Inne zasoby
- Informacje o narzędziu Oracle XML-SQL Utility http://otn.oracle.com/tech/xml/xdk_java/content.html
- Specyfikacje SAML http://www.oasis-open.org/committees/security/
- Specyfikacja XKMS http://www.w3.org/TR/xkms/
- prawo federalne„O elektronicznym podpisie cyfrowym”
Od momentu obrotów dokumenty biznesowe i korespondencja elektroniczna zaczęła zyskiwać na popularności, niezwykle potrzebny stał się proces ustalania autentyczności pliku elektronicznego i jego podpisywania. Praca z elektronicznymi podpisami cyfrowymi i plikami w różnych formatach stała się już powszechną częścią naszego życia. Ale dla tych, którzy po raz pierwszy mają do czynienia z taką akcją, nieuchronnie pojawia się pytanie, jak podpisać plik podpisu elektronicznego. W zależności od opcji tworzenia różni się także sposób złożenia tego podpisu. Dlatego konieczne jest przeanalizowanie cech każdej metody.
Certyfikacja tekstów tworzonych w formacie XML
Jeśli musisz podpisać raport skompilowany w formacie XML, warto wziąć pod uwagę, że istnieje kilka opcji przeprowadzenia tej akcji.
- Możesz użyć nowego komponentu Microsoft Office– InfoPath 2003 do generowania podpisów cyfrowych w formacie XML.
- Tworzenie autografu, jak w zwykłym formacie. W takim przypadku będziesz musiał skorzystać z programu CryptoPro.
Często, aby podpisać raport w tym formacie, konieczne jest utworzenie dodatkowego atrybutu w jego tagu. Podpis cyfrowy jest do niego wprowadzany z ciągu znaków o różnej długości i zawierającego wartość atrybutów. To podejście, które jest dość interesujące, ale mimo to całkiem akceptowalne, można również spotkać dość często.
Praca z formatem PDF
Często pojawia się pytanie, jak podpisać plik podpisem elektronicznym, jeśli dokument został utworzony w formacie PDF. W celu generowania i weryfikacji podpisów cyfrowych dokumentacji tworzonej w formacie PDF firma CryptoPro stworzyła program CryptoPro PDF. Ten produkt umożliwia generowanie i weryfikację podpisów cyfrowych dla listów, które zostały utworzone w Programy Adobe Acrobat, Adobe Reader.
Dość istotnym faktem jest to, że CryptoPro jest darmowy program, czyli aby z niego skorzystać, nie będziesz musiał płacić za świadczone usługi. Aby korzystać z tego oprogramowania, musisz je zainstalować, a następnie będziesz mógł sprawdzać dokumenty.
Podpisywanie przesyłek wieloplikowych
Czasami pojawia się pytanie, jak podpisać pliki EDS, jeśli przesyłka zawiera nie jeden, a kilka aktów. W takim przypadku możesz stworzyć swój autograf podpisu osobno dla każdego z nich.
Jeśli z jakiegoś powodu ta opcja nie jest możliwa, możesz utworzyć dodatkowy element typu tekstowego, w którym będziesz później pisać parametry identyfikacyjne dokumentu, a także wskaźniki funkcji skrótu każdego osobny plik w dokumencie. Ułatwi to pracę zarówno Tobie, jak i odbiorcy listu.
Jeden z aktualnie realizowanych projektów rozwiązał problem podpisywania (stosowania podpisu elektronicznego) dokumentów XML, czyli pakietów SOAP. Zalecanym formatem był standard OASIS 200401 z profilem tokenu certyfikatu X.509. Dokumenty te opisują użycie formatu www-consortium (W3C). podpisy elektroniczne XML (XMLDSig - XML Digital Signature) w komunikatach SOAP. Podpisy XML, podobnie jak inne typy podpisów elektronicznych, wspierają uwierzytelnianie, integralność danych i niezaprzeczalność podpisu danych.
Zwrócę uwagę na kilka cech formatu XMLDSig:
1. Przedmiotem podpisu nie może być cały dokument XML, a jedynie jego część, tj. konkretny węzeł. Zgodnie ze standardem OASIS 200401 podpisywanym obiektem jest ciało (node Ciało) Wiadomości SOAP.
2. Różne części dokumentu XML mogą być podpisane przez wielu sygnatariuszy.
3. Podpis XML może znajdować się na różnych poziomach w stosunku do podpisywanego obiektu:
- struktura podpisu może zawierać URI(jednolity identyfikator zasobu);
- Podpis XML może znajdować się na tym samym poziomie, co podpisywany węzeł;
- Podpis XML może znajdować się wewnątrz podpisywanego węzła;
- Podpisywany węzeł może być zawarty w strukturze podpisu XML.
4. Do sprawdzenia ważności podpisu elektronicznego niezbędny jest dostęp do przedmiotu podpisu.
Struktura koperty SOAP
Ogólnie rzecz biorąc, wiadomość składa się z nagłówka i treści: nagłówek I Ciało. nagłówek zawiera metadane i Ciało dane. Podpis XML jest umieszczany w węźle nagłówek.
Algorytmy kryptograficzne i kanonizacja.
Aby rozwiązać problem, którego użyliśmy GOST R 34.11-94- Rosyjski standard kryptograficzny do obliczeń funkcji skrótu i GOST R 34.10-2001- standard podpisu elektronicznego.
Ze względu na elastyczność reguł kompozycji XML, ta sama struktura dokumentu i ta sama informacja mogą być reprezentowane przez różne dokumenty XML. Przyjrzyjmy się dwóm dokumentom:
Z logicznego punktu widzenia są one równoważne, czyli mają ten sam schemat XML. Jednak pliki XML tych list nie zawierają tej samej sekwencji znaków, co będzie prowadzić do różnych wyników, na przykład podczas pobierania wartości skrótu.
Aby uniknąć takich rozbieżności, przyjęto rygorystyczne zasady formatowania i wymagania dotyczące treści komunikatów XML. Nazywa się proces doprowadzenia dokumentów XML do ujednoliconej (kanonicznej) formy kanonizacja(angielski: kanonizacja). Przykładami reguł może być użycie określonego schematu kodowania (UTF-8), normalizacja wartości atrybutów, użycie podwójnych cudzysłowów dla wartości atrybutów, określona kolejność atrybutów i deklaracje przestrzeni nazw itp. Kanonizacja XML występuje w kilku typach, które różnią się składem przepisów. Więcej o procesie kanonizacji możesz przeczytać w oficjalnej specyfikacji W3C (artykuły w języku rosyjskim na ten temat można znaleźć i)
Biblioteka SIRCrypt
Aby zaimplementować podpisywanie XML w DIRECTUM, napisano bibliotekę COM, w ramach której opisane są 3 klasy: Hasher, Sygnatariusz I XMLCanonicalizer w celu uzyskania odpowiednio skrótu, wartości ES i kanonizacji dokumentów XML.
Biblioteka wymaga Crypto PRO CSP(testowane na wersji Crypto PRO CSP 3.6.6497 KC2) I .INTERNET(minimum 2,0).
Rejestracja biblioteki odbywa się poprzez wykonanie następującego polecenia:
> regasm.exe „ścieżka do biblioteki dll” /codebase /tlb
Obiekt Hasher do obliczania skrótu zgodnie z GOST
Zawiera pola Treść (wpisz „string”) i HashValueAsBase64 (wpisz „string”), a także metodę obliczania wartości skrótu Haszysz(). Aby obliczyć, należy zdefiniować Treść , wywołaj metodę Haszysz(), w wyniku czego w terenie HashValueAsBase64 wartość skrótu zostanie zapisana w Base64.
Obiekt podpisujący w celu uzyskania wartości ES zgodnie z GOST
Zawiera pola Treść (wpisz „string”), Nazwa kontenera (wpisz „string”), CertyfikatAsPEM (wpisz „string”), BESignatureValueAsBase64 (wpisz „string”), metoda Podpisać(). Po zainicjowaniu obiektu należy go zdefiniować Treść (szczegóły podpisu), Nazwa kontenera (nazwa kontenera klucza prywatnego certyfikatu), metoda wywołania Podpisać(). Potem w polu CertyfikatAsPEM odpowiedni trafi prywatny klucz certyfikat w Base64 i w terenie BESignatureValueAsBase64 wartość podpisu jako ciąg Base64.
Obiekt XMLCanonicalizer do kanonizacji XML
Zawiera pola Treść XML (wpisz „string”), Kanoniczny XML (wpisz „string”), metoda C14NExc(). Aby uzyskać kanoniczny formularz XML, musisz określić Treść XML , dzwonić C14NExc(), uzyskaj wynik z pola Kanoniczny XML .
Struktura podpisu XML
Tworzenie podpisu wygląda następująco: najpierw formowana jest podstawa opakowania mydła, czyli węzły nagłówek I Ciało. Ciało jest wypełniany danymi i dodawany jest atrybut wsu:ID="Treść"- identyfikator podpisanych danych.
Wypełnienie konstrukcji Bezpieczeństwo dzieje się w następującej kolejności:
- Wartość skrótu z węzła Body jest przyjmowana w formie kanonicznej i umieszczana w węźle DigestValue.
- Węzeł Podpisane informacje sprowadzone do postaci kanonicznej, podpisane podpisem elektronicznym. Wynik w formacie ciągu Base64 trafia do węzła Wartość podpisu.
- W węźle umieszczany jest klucz publiczny certyfikatu, który został użyty do podpisania Binarny token bezpieczeństwa w formacie ciągu Base64.
Aby sprawdzić wygenerowany w ten sposób ES, należy wykonać wszystkie kroki w odwrotnej kolejności, czyli:
- uzyskać postać kanoniczną elementu Podpisane informacje.
- Korzystając z wyniku poprzedniego kroku, sprawdź, czy wartość ES z węzła jest poprawna Wartość podpisu przy użyciu klucza publicznego certyfikatu. Na tym etapie sprawdzana jest jedynie poprawność podpisu elektronicznego, co nie gwarantuje niezmienności danych.
- Jeżeli sprawdzenie ważności podpisu elektronicznego zakończy się pomyślnie, porównywany jest skrót z węzła Wartość podsumowania i skrót z węzła z danymi. Jeżeli są one nierówne, wówczas podpisane dane zostały zmienione i cały podpis elektroniczny jest nieważny.
Przykład użycia
Zestaw deweloperski i biblioteka
Przykłady podpisu XML na ISBL (skrypt): dev.zip (5,95 KB)
Do stałego użytku kod realizujący standardowe podpisanie gotowej koperty SOAP zostaje przeniesiony do funkcji ZnakSOAP().
Do podpisywania używany jest certyfikat z osobistego magazynu certyfikatów bieżącego użytkownika.
Nie mogę dojść do ogólnego zrozumienia mechanizmów podpisywania dokumentów XML. Byłbym wdzięczny za pomoc w rozwiązaniu tego problemu)
Moja sytuacja wygląda następująco:
1) istnieje urząd certyfikacji, którego wystawione certyfikaty umieszczane są na serwerach w pamięci systemu Windows... osobiste, zaufane i tak dalej... nie o to chodzi.
Użytkownik logując się do aplikacji podpisuje losowo wygenerowany ciąg znaków wybranym przez siebie certyfikatem. Na serwerze weryfikowany jest ten podpis:
CAPICOM.SignedData _signedData = nowy CAPICOM.SignedData(); _signedData.Verify(signedData, false, CAPICOM_SIGNED_DATA_VERIFY_FLAG.CAPICOM_VERIFY_SIGNATURE_AND_CERTIFICATE); if (_signedData.Content != dane) zgłosić nowy wyjątek("Treść podpisu nie zgadza się z odebraną treścią"); var _certificate = _signedData.Certificates; // certyfikat użytkownika
W ten sposób uzyskujemy certyfikat użytkownika (klucz publiczny). Co ważne, podpis zostanie zweryfikowany tylko wtedy, gdy odpowiadający mu klucz publiczny certyfikatu znajdzie się na serwerze w bazie certyfikatów. Tego właśnie potrzebujemy, aby wpuszczać tylko tych, których certyfikaty sami wydaliśmy) Tutaj wydaje się jasne.
2) teraz potrzebujemy, aby ci sami użytkownicy podpisali pliki XML swoimi certyfikatami. Moje oprogramowanie na kliencie generuje same pliki XML i podpisuje je certyfikatem określonym przez użytkownika:
Publiczny statyczny void SignXml(XmlDocument xmlDoc, /*RSA*/AsymmetricAlgorithm Key) ( SignedXml SignedXml = new SignedXml(xmlDoc); podpisanyXml.SigningKey = klucz; Referencja referencyjna = new Reference(); reference.Uri = "";//podpis cały dokument XML XmlDsigEnvelopedSignatureTransform env = new XmlDsigEnvelopedSignatureTransform(); reference.AddTransform(env);signXml.AddReference(reference); KeyInfo keyInfo = new KeyInfo(); keyInfo.AddClause(CryptService.GetKeyInfoClause(Key)); // RSA lub GOST podpisanyXml.KeyInfo = keyInfo; podpisanyXml.ComputeSignature(); XmlElement xmlDigitalSignature = podpisanyXml.GetXml(); xmlDoc.DocumentElement.AppendChild(xmlDoc.ImportNode(xmlDigitalSignature, true)); )
Dokument XmlDocument = nowy Dokument Xml(); doc.PreserveWhitespace = true; doc.Load(ścieżka); SignedXml sx = nowy SignedXml(doc); XmlNodeList lista węzłów = doc.GetElementsByTagName("Podpis"); sx.LoadXml((XmlElement)nodeList); zwróć sx.CheckSignature();
Kod działa, ale mam pytania ze zrozumieniem: w tym przypadku xml można podpisać absolutnie dowolnym certyfikatem nie wydanym przez nasz urząd certyfikacji, a ponieważ informacja o kluczu publicznym jest przechowywana w samym podpisanym xml, podpis jest weryfikowany . Ta opcja mi nie odpowiada. Metoda CheckSignature posiada przeciążenie parametrem typu AsymmetricAlgorithm, który sprawdzi obecność certyfikatu podpisującego w sklepie, sprawdzi jego ważność, datę ważności itd. Tego właśnie potrzebuję, ale nie wiem z góry, który użytkownik wysłał podpisany plik XML.
Proszę o podpowiedź: jak sprawdzić podpis XML lub jak go poprawnie utworzyć, aby weryfikowane były tylko te pliki XML, które są podpisane wyłącznie naszymi certyfikatami (które są zainstalowane w magazynie)?
P.s. i jaki jest ogólny sens przechowywania zarówno samego podpisu, jak i klucza publicznego do odszyfrowania podpisu w formacie XML? Jeśli usuniesz linię SignXml.KeyInfo = keyInfo; , wówczas plik XML nie przechodzi weryfikacji podpisu.