Doświadczenie w wykorzystaniu technologii Rutoken do rejestracji i autoryzacji użytkowników w systemie (część 1)

Dzień dobry Chcę podzielić się swoim doświadczeniem w tym temacie.

Rutoken to rozwiązania sprzętowe i programowe z zakresu uwierzytelniania, bezpieczeństwa informacji i podpisu elektronicznego. Zasadniczo jest to dysk flash, na którym można przechowywać dane uwierzytelniające, których użytkownik używa do logowania się do systemu.

W tym przykładzie użyto Rutoken EDS 2.0.

Aby pracować z tym Rutokenem, potrzebujesz zainstaluj sterownik w systemie Windows.

W przypadku systemu Windows zainstalowanie tylko jednego sterownika zapewnia zainstalowanie wszystkiego, co jest potrzebne, dzięki czemu system operacyjny widzi Twój Rutoken i może z nim pracować.

Możesz wchodzić w interakcję z Rutokenem na różne sposoby. Dostęp do niego można uzyskać ze strony serwera aplikacji lub bezpośrednio ze strony klienta. W tym przykładzie przyjrzymy się interakcji z Rutokenem po stronie klienta aplikacji.

Część kliencka aplikacji współdziała z rutokenem poprzez wtyczkę rutoken. Jest to program instalowany osobno w każdej przeglądarce. W przypadku systemu Windows wystarczy pobrać i zainstalować wtyczkę, znajduje się pod tym linkiem.

To wszystko, teraz możemy wchodzić w interakcję z Rutokenem ze strony klienta aplikacji.

W tym przykładzie omówiono pomysł wdrożenia algorytmu autoryzacji użytkownika w systemie z wykorzystaniem schematu wyzwanie-odpowiedź.

Istota pomysłu jest następująca:

  1. Klient wysyła żądanie autoryzacji do serwera.
  2. Serwer odpowiada na żądanie klienta wysyłając losowy ciąg znaków.
  3. Klient uzupełnia ten ciąg losowymi 32 bitami.
  4. Klient podpisuje otrzymany ciąg znaków swoim certyfikatem.
  5. Klient wysyła otrzymaną zaszyfrowaną wiadomość na serwer.
  6. Serwer weryfikuje podpis odbierając oryginalną niezaszyfrowaną wiadomość.
  7. Serwer usuwa ostatnie 32 bity z odebranej niezaszyfrowanej wiadomości.
  8. Serwer porównuje otrzymany wynik z komunikatem, który został wysłany przy żądaniu autoryzacji.
  9. Jeżeli komunikaty są takie same, autoryzację uznaje się za udaną.

W powyższym algorytmie istnieje coś takiego jak certyfikat. W tym przykładzie musisz zrozumieć pewną teorię kryptograficzną. Na Habré jest świetny artykuł na ten temat.

W tym przykładzie użyjemy algorytmów szyfrowania asymetrycznego. Aby wdrożyć algorytmy asymetryczne, musisz mieć parę kluczy i certyfikat.

Para kluczy składa się z dwóch części: klucza prywatnego i klucza publicznego. Klucz prywatny, jak sama nazwa wskazuje, musi być tajny. Używamy go do odszyfrowywania informacji. Klucz publiczny może zostać przekazany każdemu. Klucz ten służy do szyfrowania danych. Zatem każdy użytkownik może zaszyfrować dane przy użyciu klucza publicznego, ale tylko właściciel klucza prywatnego może odszyfrować te informacje.

Certyfikat to dokument elektroniczny zawierający informacje o użytkowniku będącym właścicielem certyfikatu, a także klucz publiczny. Za pomocą certyfikatu użytkownik może podpisać dowolne dane i przesłać je na serwer, który może zweryfikować podpis i odszyfrować dane.

Aby poprawnie podpisać wiadomość certyfikatem należy go poprawnie utworzyć. Aby to zrobić, najpierw tworzona jest para kluczy na Rutokenie, a następnie należy powiązać certyfikat z kluczem publicznym tej pary kluczy. Certyfikat musi mieć dokładnie ten sam klucz publiczny, który znajduje się na Rutokenie, to ważne. Jeśli po prostu utworzymy parę kluczy i certyfikat bezpośrednio po stronie klienta aplikacji, w jaki sposób serwer może następnie odszyfrować tę zaszyfrowaną wiadomość? W końcu nie wie nic ani o parze kluczy, ani o certyfikacie.

Jeśli zagłębisz się w ten temat, możesz znaleźć ciekawe informacje w Internecie. Istnieją pewne urzędy certyfikujące, którym niewątpliwie ufamy. Te urzędy certyfikacji mogą wystawiać użytkownikom certyfikaty; instalują te certyfikaty na swoim serwerze. Następnie, gdy klient uzyskuje dostęp do tego serwera, widzi właśnie ten certyfikat i widzi, że został on wydany przez urząd certyfikacji, co oznacza, że ​​temu serwerowi można ufać. W Internecie jest też mnóstwo informacji o tym, jak wszystko poprawnie skonfigurować. Możesz na przykład zacząć od tego.

Jeśli wrócimy do naszego problemu, rozwiązanie wydaje się oczywiste. Trzeba jakoś stworzyć własne centrum certyfikacji. Ale wcześniej musisz dowiedzieć się, na jakiej podstawie centrum certyfikacji powinno wydać certyfikat użytkownikowi, ponieważ on nic o tym nie wie. (Na przykład jego imię, nazwisko itp.) Istnieje coś takiego, jak żądanie certyfikatu. Więcej informacji na temat tego standardu można znaleźć np. w Wikipedii ru.wikipedia.org/wiki/PKCS
Będziemy używać wersji 1.7 - PKCS#10.

Opiszmy algorytm generowania certyfikatu na Rutokenie (oryginalne źródło: dokumentacja):

  1. Tworzymy parę kluczy na kliencie i zapisujemy ją na Rutokenie. (zapisywanie następuje automatycznie)
  2. Tworzymy żądanie certyfikatu na kliencie.
  3. Od klienta wysyłamy to żądanie do serwera.
  4. Kiedy na serwerze otrzymamy żądanie certyfikatu, wydajemy certyfikat od naszego urzędu certyfikacji.
  5. Certyfikat ten wysyłamy do klienta.
  6. Zapisujemy certyfikat Rutoken na kliencie.
  7. Certyfikat musi być powiązany z parą kluczy utworzoną w pierwszym kroku.

Teraz staje się jasne, w jaki sposób serwer będzie w stanie odszyfrować podpis klienta, ponieważ sam wydał mu certyfikat.

W następnej części przyjrzymy się bliżej, jak skonfigurować urząd certyfikacji w oparciu o pełnoprawną bibliotekę kryptograficzną open source openSSL.

Źródło: www.habr.com

Dodaj komentarz