FAQ

Spis zagadnień:

Dlaczego pracując w sesji terminalowej Windows Terminal Services ``nie działa`` czytnik zainstalowany na serwerze terminalowym a działa tylko czytnik lokalny mojej stacji roboczej?.

Odpowiedź: Takie funkcjonowanie obsługi czytnika kart elektronicznych wynika z architektury systemu terminalowego wbudowanego w MS Windows. W ramach sesji terminalowej użytkownik ma udostępnione te zasoby serwera, które przewiduje architektura TS i zostały odpowiednio skonfigurowane przez administratora oraz wybrane zasoby lokalne stacji roboczej na której pracuje aplikacja klienta terminalowego (RDP Client). Wśród zasobów, które mogą być przenoszone ze stacji roboczej do sesji terminalowej na serwerze jest czytnik kart elektronicznych. Jego przenoszenie ze stacji roboczej do serwera jest konfigurowalne przez użytkownika w opcjach dodatkowych klienta terminalowego (aplikacji RDP Client). Niestety czytnik kart elektronicznych podłączony do fizycznych portów serwera terminalowego nie jest udostępniany dla sesji terminalowych pracujących na tym serwerze. Dlatego właśnie aplikacja użytkownika uruchomiona w sesji terminalowej “widzi” czytnik i kartę włożoną do niego tylko jeśli jest to czytnik lokalny podłączony do stacji roboczej, na której uruchomiony jest RD Client ale “nie widzi” czytnika podłączonego bezpośrednio do portów serwera terminalowego.

I odwrotnie: aplikacje uruchamiane bezpośrednio na serwerze (ale nie w ramach sesji terminalowej) potrafią używać wyłącznie jego czytniki lokalnie podłączone do serwera i “nie widzą czytników” podłączonych do stacji roboczych użytkowników.

Przenoszenie czytników w standardowy sposób w Windows Terminal Services nie odbywa się na poziomie przenoszenia komunikacji z “urządzeniem USB” ale jest to przenoszenie logicznej komunikacji z kartą elektroniczną na poziomie stosu obsługi czytników kart elektronicznych PC/SC.

Istnieją aplikacje firm trzecich rozszerzające standardową architekturę terminalową MS Windows i pozwalające na przenoszenie wybranych urządzeń podłączonych do portów USB pomiędzy stacją robocza a serwerem, jednak użycie takich aplikacji może powodować kolizję z naturalnymi mechanizmami udostępniania np. czytnika kart ze stacji roboczej dla aplikacji pracującej w sesji terminalowej na serwerze i nie jest objęte standardowo wsparciem naszej firmy.

Nie działa karta inteligentna (i czytnik) podłączony do stacji roboczej, z której następuje łączenie się do serwera terminalowego (przez protokół RDP).

Odpowiedź: Aby czytnik i karta działały w połączeniu terminalowym (RDP) muszą być spełnione następujące warunki:

  • Czytnik musi zostać podłączony poprawnie do stacji klienckiej np. Windows XP. Na tej stacji muszą zostać zainstalowane sterowniki czytnika. Czytnik musi być widoczny w managerze urządzeń i poprawnie działać na stacji roboczej (np. poprawnie informować o włożeniu/wyciągnięciu karty elektronicznej).
  • Na stacji klienckiej musi działać usługa systemowa “Karta Inteligentna” (Smartcard).
  • W kliencie RPD, w opcjach zaawansowanych musi być włączone przenoszenie lokalnego czytnika kart elektronicznych w sesji RDP (tzn. udostępnianie kart w nim włożonych dla aplikacji na serwerze terminalowym).
  • Na serwerze Terminalowym (RDP) musi być zainstalowane oprogramowanie CryptoCard Suite (najlepiej w wersji pobranej ze strony: http://www.cryptotech.com.pl/Produkty/CryptoCard_Suite,content.html)

Scenariusz funkcjonowania takiej konfiguracji wygląda następująco:

– aplikacja pracująca w sesji terminalowej na serwerze Windows Terminal Services (np. MS Outlook), (której wizualizację użytkownik widzi w okienku Klienta RDP na stacji roboczej), chcąc skorzystać z karty elektronicznej uruchamia oprogramowanie middleware pochodzące od producenta karty (jeden z interfejsów API oprogramowania CryptoCard Suite w przypadku używania karty CryptoCard multiSIGN),

– CC Suite pracuje na serwerze terminalowym (nie jest wymagana jego instalacja na stacji roboczej Klienta RDP),

– CC Suite prosi system operacyjny o listę dostępnych dla niego czytników kart,

– system udostępnia listę czytników PRZENOSZONYCH w sesji RDP ze stacji klienta RDP (czytników podłączonych do stacji klienta, na której uruchomiony jest w danej chwili RDP Klient, np. aplikacja Remote Desktop Connection),

– jeśli w czytniku na stacji Klienta włożona jest karta elektroniczna, to CC Suite (np. moduł Cryptotech CSP albo CryptoTech PKCS#11) pracujący na serwerze zobaczy włożoną kartę do czytnika kart i może rozpocząć dialog z tą kartą,

– aplikacja (np. MS Outlook) przekazuje dla CC Suite serię poleceń (np. wykonania podpisu elektronicznego z użyciem karty CryptoCard multiSIGN), które są tłumaczone na stosowną sekwencję komend niskiego poziomu przekazywanych do czytnika kart dostępnego dla aplikacji pracujących w sesji terminalowej),

– komendy te są transparentnie przenoszone z serwera terminowego (z wnętrza sesji terminalowej danego użytkownika), przez kanał RDP,do klienta RDP pracującego na stacji roboczej użytkownika,

– Klient RDP przekazuje te komendy do karty włożonej do czytnika podłączonego lokalnie do tej stacji roboczej,

– karta wykonuje zlecone zadania, np. generuje podpis elektroniczny “zlecony” jej przez aplikację (np. MS Outlook) pracującą na serwerze terminalowym.

Jak można zdiagnozować poprawność konfiguracji mojego komputera do pracy z kartami CryptoCard?

Problem: Jak można zdiagnozować poprawność konfiguracji mojego komputera do pracy z kartami CryptoCard?

Odpowiedź: Rozwiązanie CrytpoCard Suite została wyposażona w narządzie do weryfikacji poprawności konfiguracji o nazwie “Asystent Konfiguracji”. W celu jego uruchomienia należy wybrać pozycję “Asystent Konfiguracji” z menu Start (Start->Programy->CryptoTech->CryptoCard Suite 1.2), a następnie postępować zgodnie z instrukcjami programu. W efekcie działania aplikacji powstanie raport, który zawiera informacje dotyczące poprawności instalacji CryptoCard Suite i może być pomocny podczas identyfikacji źródła problemów, jeśli takie wystąpią.

Na poniższym rysunku przedstawiono podstawowe komponenty (urządzenia i oprogramowanie), które wraz z rozwiązaniem CrytpoCard Suite umożliwiają korzystanie z kart kryptograficznych.

Należy zwrócić uwagę, że rozwiązanie CryptoCard Suite wykorzystuje dostępne w systemie operacyjnym czytniki kart zgodne ze standardem PC/SC.

Ponieważ często okazuje się, że przyczyną problemów jest niepoprawnie skonfigurowany system operacyjny lub czytnik kart, użytkownik przed zgłoszeniem problemu powinien upewnić się, że posiada odpowiednio skonfigurowany system operacyjny oraz prawidłowo zainstalowany/skonfigurowany czytnik kart kryptograficznych.

Nie mogę logować się kartą do mojego komputera mimo tego, że czytnik jest podłączony a oprogramowanie działa poprawnie.

Odpowiedź: Logowanie kartami jest możliwe jedynie wtedy, gdy komputer znajduje się w domenie Active Directory (Windows 2000/2003). Do takiego logowania konieczne jest wydanie na karcie certyfikatu umożliwiającego logowanie (szablony Smart Card User lub Smart Card Logon). Możliwe jest dodanie logowania się kartami do komputerów nie będących członkami domeny Active Directory przy pomocy dodatkowej aplikacji np. CryptoCard Logon.

Jak dodać do Mozilla Thunderbird możliwość podpisywania i szyfrowania korespondencji z użyciem kart CryptoCard?

Odpowiedź: Z menu Tools -> Options -> Advanced wybrać sekcję Certificates. Nacisnąć przycisk “Manage Security Devices…”. W nowo otwartym okienku wpisać w polu “Module Name” – CryptoCard, w polu Module filename: wpisać “C:\Program Files\CryptoTech\CryptoCard\CCPkiP11.dll” (dla wersji CCS 1.12 “%WINDOWS%\System32\ccpkip11.dll”, gdzie %WINDOWS% należy zastąpić prawidłową ścieżką wskazującą na dysk i katalog, w którym zainstalowany jest system MS Windows. Zazwyczaj jest to katalog C:\WINDOWS jednak w poszczególnych przypadkach ścieżka ta może być inna). Następnie po wybraniu przycisku OK na liście dostępnych urządzeń powinno pojawić się urządzenie “CryptoCard”. Dokładny opis instalacji modułu można pobrać tutaj.

Jak przenieść na kartę klucz i certyfikat służący do szyfrowania systemu plików (EFS)?

Odpowiedź: Niestety, obecne systemy rodziny Windows , oprócz Windows VISTA SP1, nie umożliwiają przechowywania klucza i certyfikatu do EFS w jakimkolwiek innym miejscu oprócz “Magazynu osobistego”.

Ile certyfikatów zmieści się na moją kartę?

Odpowiedź: Karty CryptoCard PKI posiadają 16 kB pamięci zapisywalnej, z których ~10 kB jest dostępnych dla kluczy i certyfikatów. W zależności od wielkości certyfikatu na takiej karcie powinno zmieścić się od 2 do 4 certyfikatów wraz z odpowiednimi kluczami. Karty CryptoCard multiSIGN mają 32 kB pamięci z czego dla użytkownika dostępne jest ~25 kB, co powinno być wystarczające do przechowywania nawet 5 certyfikatów z kluczami. Nie ma niestety żadnego ograniczenia na wielkość certyfikatu dlatego też podane wyżej wartości nie są gwarantowane i powinny być traktowane jedynie orientacyjnie.

Nie mogę podpisać wiadomości e-mail mimo tego, że posiadam certyfikat kwalifikowany.

Odpowiedź: Wynika to z przeznaczenia certyfikatu kwalifikowanego, którego budowa jednoznacznie definiuje jego przeznaczenie (niezaprzeczalność) i równie jednoznacznie wyklucza jakiekolwiek inne użycie.

Czy są narzucone jakieś ograniczenia dotyczące nadawani kodów PIN dla aplikacji komponentu technicznego (SSCD)

Odpowiedź: W ramach części kwalifikowanej karty (SSCD) istnieje konieczność stosowania aplikacji karty o bardzo ściśle kontrolowanych parametrach bezpieczeństwa, które są zdefiniowane w profilu zabezpieczeń danej platformy kartowej i opisane w dokumentacji certyfikacyjnej ITSEC/CC/FIPS.

Parametry te narzucają pewne ograniczenia na swobodę definiowania i zmiany kodów PIN/PUK dla tego obszaru karty. Przykładowo dla kart CryptoCard multiSIGN v2 z aplikacją SSCD występują następujące ograniczenia (w zakresie polityki PIN):

  • Dla kart dostarczonych w trybie “Zero PIN Delivery”, czyli bez zdefiniowanego kodu PIN użytkownika, kod PIN musi zostać zdefiniowany przed jakimkolwiek użyciem komponentu technicznego do złożenia bezpiecznego podpisu weryfikowanego z użyciem kwalifikowanego certyfikatu.
  • Podczas tej jednorazowej operacji definiowania kodu PIN, można ustawić PIN o długości od 6 do 8 znaków.
  • Długość pierwszego kodu PIN ustawianego w tym momencie determinuje, na cały okres używania komponentu technicznego, minimalną długość kodu PIN jaki będzie można dla niego ustawiać. Np. ustawiając pierwszy kod PIN o długości 7 znaków, będzie można w przyszłości zmieniać jego wartość, ale jedynie kody PIN o długości 7 i 8 znaków będą dopuszczalne. Nie będzie możliwości ustawienia kodu PIN 6 znakowego, pomimo iż jest to generalnie długość dopuszczalna przez wymagania bezpieczeństwa dla aplikacji SSCD. Podobnie ustawiając pierwszy kod PIN na długość 8 znaków, już konsekwentnie do końca “życia” komponentu technicznego będzie można ustawiać kod PIN wyłącznie o długości 8 znaków.
  • Zalecane jest ustawienie pierwszego kodu PIN na długość 6 znaków, jeśli użytkownik chce mieć możliwość w przyszłości ustawiania tej długości jak i kodów PIN dłuższych (7 i 8 znaków). Bezpośrednio po ustawieniu pierwszego kodu PIN na 6 znaków można go oczywiście od razu zmienić na kod 7 czy 8 znakowy, ale dzięki tej operacji w przyszłości, gdy pojawi się taka konieczność, będzie możliwa zmiana kodu PIN na krótszy (np. 6 znakowy).

Dla kart CryptoCard multiSIGN v3 powyższe ograniczenia mają nieco inną postać:

  • Karty te dostarczane są z poufnym kodem transportowym o wybranej przez wystawcę długości (od 6 do 8 znaków).
  • Przed pierwszym użyciem klucza do składania bezpiecznego podpisu niezbędna jest zmiana transportowego kodu PIN na kod użytkownika (operacja jednorazowa).
  • Długość kodu użytkownika nie może być krótsza niż długość kodu transportowego, jaki został nadany karcie na etapie jej personalizacji. Np. dla karty o nadanym transportowym kodzie PIN o długości 7 znaków, użytkownik może dokonać jego zmiany wyłącznie na kod 7 lub 8 znakowy. Przez cała życie komponentu technicznego dopuszczalne długości kodu PIN, podczas zmian jego wartości, są nie krótsze niż długość transportowego kodu PIN. PIN z jakim użytkownik otrzymał kartę od wydawcy.

W czasie próby podpisania dokumentu w Adobe Reader okno do wpisania PIN pojawia się dopiero po zamknięciu/zabiciu aplikacji Adobe Reader.

Odpowiedź: Sandbox w którym domyslnie działa aplikacja Adobe Reader DC niepoprawnie wywołuje okno z pytaniem o PIN. W polskiej wersji AR DC należy odznaczyć: “Podczas uruchamiania włącz tryb chroniony” w: Edycja -> Preferencje -> Zabezpieczenia (Rozszerzone) -> “Podczas uruchamiania włącz tryb chroniony”.

W angielskiej wersji AR DC należy odznaczyć: “Enable Protection Mode at startup” w: Edit -> Preferences -> Security (Enhanced) -> “Enable Protection Mode at startup”.