The issue is due to the architecture of the terminal system embedded in MS Windows. Within a terminal session, the user is provided with the resources of the server as defined by the TS architecture and appropriately configured by the administrator, as well as selected local resources of the workstation on which the terminal client application (RDP Client) is running. Among the resources that can be redirected from the workstation to the terminal session on the server is the card reader. Its redirection from the workstation to the server is configurable by the user in the additional options of the terminal client (RDP Client) application. Unfortunately, a card reader connected to the physical ports of the terminal server is not available to terminal sessions running on that server. Therefore, the user application running in the terminal session “sees” the card reader and the card inserted into it only if it is a local reader connected to the workstation where the RD Client is running but does not “see” the reader connected directly to the ports of the terminal server. 

Similarly, applications launched directly on the server (but not within a terminal session) can only use its local readers connected directly to the server and “do not see” readers connected to users’ workstations. 

The transfer of readers in the standard way in Windows Terminal Services does not involve transferring communication at the “USB device” level but is the transfer of logical communication with the smart card at the level of the PC/SC smart card stack. 

There are third-party applications that extend the standard MS Windows terminal architecture and allow the transfer of selected devices connected to USB ports between the workstation and the server. However, using such applications may cause conflicts with the natural mechanisms of reader’s transfer and is not supported. 

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.

For the card reader and the card to function in a terminal connection (RDP), the following conditions must be met: 

• The reader must be properly connected to the client workstation (e.g., Windows 10). The reader drivers must be installed on this workstation. The reader must be visible in the device manager and function correctly on the workstation (e.g. correctly indicate the insertion/removal of the electronic card). 
• The smart card system service must be operational on the client workstation. 

• In the RDP client, the option to redirect the local smart card reader in the RDP session must be enabled (i.e. sharing the inserted cards for applications on the terminal server). 
• The CryptoCard Suite software must be installed on the Terminal Server, preferably downloaded from the website: http://www.cryptotech.com.pl/Produkty/CryptoCard_Suite,content.html 

The usage scenario in such a configuration is as follows: 

• An application running in a terminal session on the Windows Terminal Services server (e.g., MS Outlook), launches middleware software provided by the card manufacturer (one of the API interfaces of the CryptoCard Suite software in the case of using the CryptoCard Graphite card). 
• CC Suite runs on the terminal server (its installation on the RDP client workstation is not required). 
• CC Suite asks the operating system for a list of available card readers. 
• The system provides a list of TRANSFERRED card readers in the RDP session from the RDP client workstation (readers connected to the client workstation on which the RDP client is currently running, e.g., the Remote Desktop Connection application). 
• If an electronic card is inserted into the reader on the client workstation, CC Suite (e.g., the Cryptotech CSP module or CryptoTech PKCS#11) operating on the server will detect the inserted card in the card reader and can initiate a dialogue with this card. 
• The application (e.g., MS Outlook) sends a series of commands to CC Suite (e.g., executing an electronic signature using the CryptoCard multiSIGN card), which are translated into an appropriate sequence of low-level commands passed to the card reader available for applications running in the terminal session. 
• The commands are transparently transferred from the terminal server (from inside the terminal session of a given user), via the RDP channel, to the RDP client on the user’s workstation. 
• The RDP client forwards these commands to the card inserted into the reader connected locally to this workstation. 
• The card performs the assigned tasks, e.g., generates an electronic signature requested by the application (e.g., MS Outlook) running on the terminal server. 

The CryptoCard Suite solution comes with a configuration validation tool called the “Configuration Assistant.” To launch it, select “Configuration Assistant” from the Start menu (Start->Programs->CryptoTech->CryptoCard Suite 1.2), and then follow the program’s instructions. As a result of the application’s operation, a report will be generated containing information regarding the correctness of the CryptoCard Suite installation. This report can be helpful in identifying the source of any issues that may arise. 

The basic components (devices and software) required to use cryptographic cards with the CryptoCard Suite solution are illustrated in the diagram below. 

It is important to note that the CryptoCard Suite solution utilizes card readers compatible with the PC/SC standard available in the operating system. 

Since improperly configured operating systems or card readers are often the cause of problems, users should ensure that they have a properly configured operating system and correctly installed/configured cryptographic card readers before reporting any issues. 

Logging in with cards is only possible when the computer is part of an Active Directory domain. To enable card login, it’s necessary to issue a certificate on the card allowing login (Smart Card User or Smart Card Logon templates)

In Thunderbird menu Tools -> Options -> Advanced select the Certificates section. Click on the “Manage Security Devices…” button. In the newly opened window, enter “CryptoCard” in the “Module Name” field, and in the “Module filename” field, enter “C:\Program Files\CryptoTech\CryptoCard\CCPkiP11.dll” (for CCS 1.12 version, “%WINDOWS%\System32\ccpkip11.dll”, where %WINDOWS% should be replaced with the correct path pointing to the disk and directory where MS Windows system is installed. Usually, it’s the C:\WINDOWS directory, but in specific cases, this path may differ). After selecting OK, the device “CryptoCard” should appear in the list of available devices.

Unfortunately, current Windows systems do not allow storing the key and certificate for EFS anywhere other than the ‘Personal store’ 

CryptoCard Graphite multiSIGN cards have 6432 kB of memory, of which ~????25 kB is available for the user, which should be sufficient to store even 510 certificates with keys. Unfortunately, there is no specific limit on the size of the certificate, so the values provided above are not guaranteed and should be treated only as approximate. 

It stems from the purpose of the qualified certificate, whose structure clearly defines its purpose (non-repudiation) and excludes any other use. 

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