Odpowiedź: Takie funkcjonowanie obsługi czytnika kart elektronicznych wynika z architektury systemu terminalowego wbudowanego w MS Windows. W ramach zdalnej sesji terminalowej użytkownik ma udostępnione te zasoby serwera, które przewiduje architektura usług terminalowych i zostały odpowiednio skonfigurowane przez administratora (nie obejmuje to portów USB Serwera!) oraz wybrane zasoby lokalne stacji roboczej, z której następuje zdalne połączenie do serwera terminalowego Windows (czyli tej stacji roboczej, na której pracuje aplikacja klienta terminalowego RDP Client).

Wśród zasobów, które mogą być przenoszone ze zdalnej stacji roboczej do sesji terminalowej na serwerze Windows 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 użytkowników zdalnych pracujących na tym serwerze.

Dlatego właśnie aplikacja użytkownika uruchomiona w sesji terminalowej „widzi” czytnik i kartę włożoną do tego czytnika tylko jeśli jest to czytnik lokalny podłączony do zdalnej stacji roboczej, na której uruchomiony jest RDP Client i z której następuje połączenie do serwera Windows. Aplikacja ta niestety nie może „widzieć” czytnika podłączonego bezpośrednio do portów USB serwera Windows.

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

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 bibliotek API obsługi czytników kart elektronicznych zgodnego z architekturą 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 dowolnymi komputerami (w tym również sesją terminalową na serwerze Windows i serwerem Windows), 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.

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

• Czytnik musi zostać podłączony poprawnie do stacji klienckiej np. Windows 10. 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 aplikacji klienta 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 Windows).
• Na serwerze Windows (dostępnym przez RDP) musi być zainstalowane oprogramowanie CryptoCard Suite dla kart CryptoCard Graphite (Plus/Pro)

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

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

– oprogramowanie CC Suite pracuje na serwerze terminalowym Windows (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 miniDriver API albo CryptoTech PKCS#11 API) 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), 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 aplikacji klienta RDP pracującej 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 Windows.

Odpowiedź: Niezależnie od rodzaju używanej karty i metody dostępu do funkcjonalności karty używanej przez aplikację użytkownika, w ramach konfiguracji komputera i systemu operacyjnego musi poprawnie działać czytnik kart i obsługujące go komponenty tego systemu operacyjnego (stos PC/SC oraz sterownik czytnika kart).

Uruchamiając aplikację CryptoCard Manager dla używanej karty (np. CryptoCard Graphite) należy sprawdzić czy aplikacja pokazuje czytnik kart, który jest fizycznie podłączony do komputera oraz pokazuje nazwę/model włożonej do niego karty. Karta odpowiednia od pracy z zainstalowanym oprogramowaniem będzie rozpoznana i wskazywana jako karta CryptoCard (np.) Graphite Plus.

Dodatkowo w dolnej części kontekstowej aplikacji CryptoCard Manager pojawią się podstawowe informacje o czytniku i karcie w nim włożonej (jeśli jest to karta z rodziny CryptoCard). Czytniki „mini” w formacie USB Pendrive posiadają kartę w formacie ID-000 (format „SIM”) na stałe włożoną do czytnika, czyli wkładając/wyciągając taki czytnik do portu USB będzie znikała/pojawiała się karta razem z czytnikiem w ramach zasobów systemu operacyjnego.

Brak ikony czytnika w tej aplikacji, informacja „Brak karty” lub „Nieznana karta” wskazują na określone wady konfiguracji systemu operacyjnego użytkownika lub niewłaściwą kartę włożoną do czytnika (np. kartę innego producenta lub kartę uszkodzoną).

Należy zwrócić uwagę, że rozwiązanie CryptoCard Suite wykorzystuje dostępne w systemie operacyjnym czytniki kart zgodne ze standardem PC/SC i jeśli czytnik nie jest poprawnie obsługiwany przez komponenty systemu operacyjnego, ma niewłaściwe sterowniki, jest uszkodzony itp. to aplikacja CryptoCard Manager nie będzie w stanie poprawnie współdziałać z takim czytnikiem i kartą CryptoCard do niego wsuniętą.

W systemach rodziny Windows, za obsługę czytnika w systemie operacyjnym odpowiedzialna jest głównie usługa systemu Windows (service) o nazwie „Karta Inteligentna” (Smart Card). Jeśli ta usługa jest zatrzymana lub zgłasza błędy, żadna aplikacja pracująca na tym systemie operacyjnym nie będzie w stanie komunikować się z kartą elektroniczną w czytniku i wykorzystywać jej funkcji (w tym oczywiście biblioteki i aplikacje z pakietu CryptoCard Suite oraz dowolne aplikacje użytkownika, które chciałby by wykorzystywać funkcje karty CryptoCard).

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.

Odpowiedź: Logowanie kartami jest możliwe jedynie wtedy, gdy komputer znajduje się w domenie Windows Active Directory i administrator poprawnie skonfigurował używanie kart do celu uwierzytelniania użytkowników w procesie logowania do komputera zarejestrowanego w ramach tej domeny.

Do takiego logowania konieczne jest m.in. wydanie na karcie certyfikatu umożliwiającego logowanie (stosując szablon Smart Card User lub Smart Card Logon) oraz odpowiednie skonfigurowanie Domeny Windows przez jej Administratora.

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ć odpowiednią ścieżkę do lokalizacji, gdzie zainstalowano oprogramowanie CryptoCard Suite w danym systemie operacyjnym.

Zależnie od tego czy używana jest aplikacja Mozilla Thunderbird w wersji 32bity czy 64bity, należy wskazać bibliotekę PKCS#11 DLL dla kart CryptoCard w odpowiedniej edycji (32 lub 64 bity).

W systemach 32bitowych instalowana jest tylko jedna wersja biblioteki PKCS#11 DLL (32bity) i znajduje się ona domyślnie w folderze „C:\Program Files\CryptoTech\CryptoCard\ CCGraphiteP11.dll”.

W systemach 64bitowych instalowane są dwie wersje biblioteki PKCS#11 DLL i zależnie od architektury aplikacji Thunderbird wskazać należy właściwą dla niej edycję tej biblioteki PKCS#11:

64bity: „C:\Program Files\CryptoTech\CryptoCard\ CCGraphiteP1164.dll”

32bity: “„C:\Program Files (x86)\CryptoTech\CryptoCard\CCGraphiteP11.dll”

Następnie po wybraniu przycisku OK w ramach opcji aplikacji Thunderbird, na liście dostępnych urządzeń powinno pojawić się dodatkowe urządzenie zgodne z PKCS#11 i lista raportowanych przez daną bibliotekę „slotów”, w których mogą znajdować się logiczne tokeny PKCS#11. Sloty zwykle odpowiadają fizycznym lub wirtualnym czytnikom kart zainstalowanym w systemie operacyjnym, ale czasami możliwa jest prezentacja tego samego czytnika wielokrotnie jeśli karta znajdująca się w tym czynniku zgłasza kilka logicznych tokenów PKCS#11.

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”.

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.

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

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.

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”.