The Card Monitor Test checks for correct detection of the smart card insertion state, and the correct handling of operations interrupted by an unexpected removal of a smart card. The tests verify that IOCTLSMARTCARDISPRESENT and IOCTLSMARTCARDISABSENT produce valid results. Test detects any empty readers by using IOCTLSMARTCARDISPRESENT.

• Modern Hebrew Reader Self Study

Test detects an inserted smart card by using IOCTLSMARTCARDISPRESENT. Test detects the removal of an inserted smart card by using IOCTLSMARTCARDISABSENT. Test detects any empty readers by using IOCTLSMARTCARDISABSENT. Tests the correct handling of a randomly timed card insertion and removal event over 15 seconds. The test ends after a maximum of ten insertion and removal cycles. The Card Reader Interface Test checks that the property and state information in the card reader driver are handled correctly. Test verifies whether the device name reported by the driver is Windows Embedded CE-compliant.

Test verifies whether the driver correctly handles attribute read requests with NULL return buffer. Test reads the smart card reader attributes when no smart card is inserted in the card reader:. SCARDATTRVENDORName Nonzero length string. SCARDATTRVENDORIFDTYPE Nonzero length string.

Feb 01, 2000 Step-by-Step Guide to Installing and Using a Smart Card Reader. A logo program for smart card readers. There is no formal testing to verify. After downloading the self-extracting file. OMNIKEY Smart Card Readers (USB, ExpressCard. For a functional test, insert a working smart card into the reader.

SCARDATTRDEVICEUNIT Value. The Resource Manger Simulation Test verifies whether the state-change operations normally commanded by the Smart Card Resource Manager complete successfully. Test verifies whether IOCTLSMARTCARDGETSTATE succeeds without a card inserted. Test verifies whether the returned state is SCARDABSENT.

Test verifies whether a call to IOCTLSMARTCARDISPRESENT is canceled correctly by using IOCTLSMARTCARDCANCELBLOCKING. Test verifies whether IOCTLSMARTCARDGETSTATE succeeds without a card inserted.

Test operator inserts a smart card. Test verifies whether IOCTLSMARTCARDGETSTATE succeeds with smart card inserted.

Test verifies whether the returned state is valid ( SCARDABSENT). Test verifies whether a call to IOCTLSMARTCARDISABSENT is canceled correctly by using IOCTLSMARTCARDCANCELBLOCKING. Test performs a cold-reset of the smart card. Test verifies whether the smart card state is SCARDNEGOTIABLE. Test sets the Smart Card Protocol to T0 or T1. Test verifies whether the smart card state is SCARDSPECIFIC.

Test verifies whether the IOCTLSMARTCARDPOWER to turn off the smart card succeeds. Test operator removes the smart card.

Test verifies whether the return value from IOCTLSMARTCARDISABSENT is correct. Test verifies whether IOCTLSMARTCARDGETSTATE succeeds without a card inserted. Test verifies whether the card state is SCARDABSENT. Answer to Reset (ATR) Values 3B EF 00 00 81 31 20 49 00 5C 50 43 54 10 27 F8 D2 76 00 00 38 33 00 4D. Test tries to read when the buffer is too small.

Test checks the waiting-time extension request, and routes the request figure to file 001. Then it reads it back and verifies it. Test verifies block-chaining resynchronization on file 0002 and verifies whether the card accepts first block. The card then repeatedly requests retransmission of block two, and the host re-synchronizes. Expect ERRORIODEVICE. Test verifies block-chaining resynchronization on file 0002.

The card repeatedly declares an EDC error on block two. The host then resynchronizes. Expect ERRORIODEVICE.

Test issues wrong block sequence by read-to-file 0003. Expect ERRORIODEVICE. Test issues a Write command of a size equal to that of the Information Field Size for Card (IFSC). Expect success.

Test issues a read-to-file 00 05 command. The expected result is ERRORIODEVICE. Read and process the result file (A000).

Parse and report errors. Athena T0 Test Card (Card 1). Answer to Reset (ATR) Values 3B D6 18 00 80 B1 80 6D 1F 03 80 51 00 61 10 30 9E.

Reset with ATR transmission time of 900 milliseconds. Set Protocol to T0. Expect success. Delete all card files by proprietary command. Expect success. Create test file 0002.

Expect success. Select test file 0002. Expect success.

Write 256 bytes as four blocks of 64 bytes. Expect success. Read and verify 256 bytes as four blocks of 64 bytes. Expect success. Write 255 bytes as a single block. Expect success. The card will receive the bytes in single-byte mode until eight bytes remain.

Then, the rest of the data will be requested from the host as a single block. Expect success. Set Receive Buffer to nine bytes and try to receive a ten-byte response from the smart card. Expect ERRORINSUFFICIENTBUFFER. Send improperly formed Select command (known to be inconsistent with the length of the data): 00 a4 00 00 08 00. Expect ERRORINVALIDPARAMETER.

Test selects a nonexistent file. The expected result is that the command will succeed with a procedure byte sequence of SW1=0x64, SW2=0x82, which corresponds to 'File Not Found'. Send command 80 00 01 00 01 11 to silence the card. Expect ERRORSEMTIMEOUT. Reset the smart card. Send an echo command to the card to test the request wait time extension for extension counts of 1, 2, 5, and 30 extensions. Expect success.

Athena T0 Inverse Convention Test Card (Card 2). Answer to Reset (ATR) Values 3F 96 18 80 01 80 51 00 61 10 30 9F. Reset with ATR transmission time of 900 milliseconds.

Set Protocol to T0. Expect success. Delete all card files by proprietary command.

Expect success. Create test file 0002. Expect success. Select test file 0002.

Expect success. Write 256 bytes as four blocks of 64 bytes. Expect success. Read and verify 256 bytes as four blocks of 64 bytes. Expect success.

Write 255 bytes as a single block. Expect success. The card will receive the bytes in single-byte mode until 128 bytes remain. Then the rest of the data will be requested from the host as a single block.

Expect success. Set Receive Buffer to nine bytes and try to receive a ten-byte response from the smart card. Expect ERRORINSUFFICIENTBUFFER. Send improperly formed Select command: 00 a4 00 08 00.

Expect ERRORINVALIDPARAMETER. Select a nonexistent file. Expect 6A 82. Send command 80 00 01 00 01 11 to silence the card.

Expect ERRORSEMTIMEOUT. Reset the smart card. Send an echo command to the card to test the request wait time extension for extension counts of 1, 2, 5, and 30 extensions. Expect success. Axalto 32K eGate Test Card (Card 3). Answer to Reset (ATR) Values 3B 95 18 40 FF 62 01 02 01 04. Try to set protocol T=1 and expect ERRORNOTSUPPORTED.

Set protocol T=0. Authenticate by using the card transport key. Expect success. Clean the card state by deleting files from previous runs. For example, remove RSA public and private key files, the user PIN file, and the test file.

Expect success. Create a new test file, 0055. Expect success.

Test writing blocks of 1, 25, 75, and 128 bytes to the test file. Expect success. Test reading 128 bytes from the test file. Compare the data. Expect success. Delete test file 0055.

Expect success. Create a PIN file. Expect success. Set the user PIN to 00000000. Expect success.

Create a private key file. Expect success. Create a public key file. Expect success.

Select the private key file. Expect success. Authenticate the user with the user PIN. Expect success. Generate a key pair. Expect success. Hash 16 bytes of data.

Expect success. Obtain response data (20 bytes + 2 bytes) from the hash operation.

Expect success. Infineon SiCrypt Module Test Card (Card 4). Answer to Reset (ATR) Values 3B DF 18 00 81 31 FE 67 00 5C 49 43 4D D4 91 47 D2 76 00 00 38 33 00 58. Try to set protocol T=0. Expect ERRORNOTSUPPORTED.

Set protocol T=1. Expect success. Authenticate by using PIN 12345678. Expect success.

Modern Hebrew Reader Self Study

Remove any existing files from previous runs. Create a new test file, 0007. Expect success. Select file 0007. Expect success.

Record system time. Write test blocks of 1, 25, 50, 75, 100, 125, and 128 bytes to the card. Read and verify the data after writing each block. Expect success.

Get the system time again and show the elapsed time for test completion in seconds. Select file 0007. Expect success. Write a 128-byte block of by value 55.

Read back and verify. Expect success. Write a 128-byte block of by value AA. Read back and verify.

Expect success. Write a 128-byte block of by value 00. Read back and verify. Expect success. Write a 128-byte block of by value FF. Read back and verify. Expect success.

Select nonexistent file 7777. Expect 94 04. Select MF by 00 a4 00 00. Expect success (90 00). Select file 77, a file known to be not valid. Send improperly formed Select command (known to be inconsistent with the length of the data): 00 a4 00 00 08 00.

Expect 94 04. Send improperly formed Select command (known to be too short): 00 a4 00. Expect 67 00.

Create DF 5555 from the MF. Expect success. Select into 5555. Expect success. Create DF 5656 from 5555. Expect success. Select into 5656.

Expect success. Create file 5757 in DF 5656.

Expect success. Select that file from MF by using the full path. Expect success. Write eight bytes to the file. Read back and verify.

Expect success. Delete the selected file. Expect success. Try to select the deleted file by using the full path. Expect 94 04. Select and delete DF 5656. Expect success.

Select and delete DF 5555. Expect success. Select and delete file 0007. Expect success. The Power Management Test verifies that the smart card driver returns the correct state information to the smart card reader across all suspend/resume sequences, even when the state of the card reader changes during the suspend state by the insertion or removal of a smart card. This test assumes that the device being tested has not been configured to prevent the USB bus from powering down while suspended.

Test operator removes all cards. Test calls IOCTLSMARTCARDISPRESENT. Test suspends device. Test resumes device. Test verifies that the IOCTLSMARTCARDISPRESENT call returns STATUSCANCELLED. Test verifies that the current card reader handle is not valid. Test obtains a new driver handle.

Test verifies that the card reader state is SCARDABSENT. Test operator inserts card. Test calls IOCTLSMARTCARDISABSENT. Test suspends device. Test operator removes card while devices is suspended. Test resumes device.

Test verifies that the IOCTLSMARTCARDISABSENT call returns STATUSCANCELLED. Test verifies that the current card reader handle is not valid.

Test obtains a new driver handle. Test verifies that the card reader state is SCARDABSENT. Test operator inserts card. Test calls IOCTLSMARTCARDISABSENT. Test suspends device. Test resumes device.

Test verifies that the IOCTLSMARTCARDISABSENT call returns STATUSCANCELLED. Test verifies that the current card reader handle is not valid. Test obtains a new driver handle.

Test verifies that the card reader state is SCARDABSENT. Test operator removes card. Test calls IOCTLSMARTCARDISPRESENT.

Test suspends device. Test operator inserts card while device is suspended. Test resumes device. Test verifies that the IOCTLSMARTCARDISABSENT call returns STATUSCANCELLED. Test verifies that the current card reader handle is not valid.

Test obtains a new driver handle. Test verifies that the card reader state is SCARDABSENT. Test operator removes card.

Smart Card Reader Testing Prerequisites. 4 minutes to read In this article This section describes the tasks that you must complete before you test a smart card reader by using the Windows Hardware Lab Kit (Windows HLK):.

Hardware requirements The following hardware is required for testing a smart card reader. You might need additional hardware if the test device offers other features.

To determine whether additional hardware requirements apply, see the test description for each test that appears for the device in Windows HLK Studio. One test computer. The test computer must meet the Windows HLK requirements. For more information, see. The smart card reader that you want to test. Note If the device supports universal serial bus (USB), you must have two test devices to run the USB Serial Number test.

For more information, see. One Personal Computer / Smart Card (PC/SC) workgroup test card (from card set 2).

This card set can be purchased from the. Test the product by using the smart cards that the PC/SC workgroup test card set includes. Do not include these smart cards with your test submission.

One of the following, depending on the type of connection that the smart card reader implements:. A USB 2.0 hub (if the card reader connects through a USB connection). An IEEE 1394 controller (if the card reader connects through a 1394 connection). Note To certify your product for use on servers, the test computer must support four processors and a minimum of 1 GB of RAM. These system capabilities are required to test the Rebalance, D3 State, and Multiple Processor Group functionality of the device and driver. You do not need a computer that actually has more than 64 processors to test your device.

Additionally, the server system(s) being used for device or driver testing must have Server Core installed prior to testing. For more information see. If you use a pool of test computers to test devices, at least one computer in the pool must contain four processors and a minimum of 1 GB of RAM. Additionally, that computer must contain the device and the driver that you want to test. As long as the driver is the same on all the computers in the pool, the system creates a schedule to run against all test computers. For tests that do not include a driver to test, such as hard disk drive tests, the Windows HLK scheduler constrains the tests that validate the device's and driver's Rebalance, D3 State and Multiple Processor Groups functionality to run on the default test computer. You must manually configure this computer to have multiple processor groups.

The default computer is the first test computer in the list. Test personnel must make sure that the first test computer in the list meets the minimum hardware requirements. Note Multiple Processor Groups Setting You must set the value for the processor group size for Hardware Lab Kit testing of Windows Server 2008 R2 and later device drivers for certification.

This is done by running bcdedit in an elevated command prompt window, using the /set option. The commands for adding the group settings and restarting are as follows: bcdedit.exe /set groupsize 2 bcdedit.exe /set groupaware on shutdown.exe -r -t 0 -f The commands for removing the group settings and rebooting are as follows: bcdedit.exe /deletevalue groupsize bcdedit.exe /deletevalue groupaware shutdown.exe -r -t 0 -f. Note Code Integrity Setting The Virtualization Based Security feature (VBS) of Windows Server 2016 must be enabled using Server Manager first. Once that has occurred, the following Registry key must be created and set: HKLM System CurrentControlSet Control DeviceGuard HypervisorEnforcedCodeIntegrity:REGDWORD 0 or 1 (disabled, enabled) Software requirements The following software is required for testing a smart card reader:. The drivers for the test device. The latest Windows HLK filters or updates. Test computer configuration To configure the test computer for your test device, follow these steps:.

Install the appropriate Windows operating system on the test computer, and then configure the computer for your test network. The test network is the network that contains Windows HLK Studio and Windows HLK Controller. If the reader is an internal device, install the smart card reader in the computer. If the reader is an external device, attach a controller to the test computer, and then attach the reader to the external controller.

If the test device is connected through the USB port, connect the USB 2.0 controller to the high-speed USB 2.0 hub, and then connect the test device to the downstream port of the high-speed USB 2.0 hub. Note Do not connect the USB test device directly to the root hub of the USB 2.0 controller. If you have to install the manufacturer-supplied device driver on the test computer, do this now.

Verify that the smart card reader functions correctly on the test computer. Install the Windows HLK client application on the test computer. Use Windows HLK Studio to create a machine pool, and then move the test computer to that pool. Make sure that the test computer is in the ready state before you begin your testing. If a test requires parameters to be set before it is run, a dialog box will be displayed for that test.

Review the specific test topic for more information. Some Windows HLK tests require user intervention. When running tests for a submission, it is a best practice to run the automated tests in a block separately from manual tests. This prevents a manual test from interrupting completion of an automated test.