Смарт карта для ноутбука что это такое
В этом разделе для ИТ-специалистов описывается архитектура системы, которая поддерживает смарт-карты в операционной системе Windows, включая архитектуру поставщика учетных данных и архитектуру подсистемы смарт-карт.
Проверка подлинности — это процесс проверки личности объекта или пользователя. При проверке подлинности объекта, например смарт-карты, целью является проверка подлинности объекта. При проверке подлинности пользователя цель заключается в том, чтобы убедиться, что вы не работаете с самонавязателем.
В сетевом контексте проверка подлинности — это проверка удостоверения сетевого приложения или ресурса. Как правило, удостоверение определяется криптографической операцией, использующей только ключ, который известен пользователю (например, с шифрованием открытого ключа) или общий ключ. На стороне сервера обмена проверкой подлинности подписанные данные сравниваются с известным криптографическим ключом для проверки попытки проверки подлинности. Хранение криптографических ключей в безопасном центральном расположении делает процесс проверки подлинности масштабируемым и поддерживаемым.
Для смарт-карт Windows поддерживает архитектуру поставщика, которая соответствует требованиям безопасной проверки подлинности и является расширяемой, чтобы можно было включить пользовательских поставщиков учетных данных. В этом разделе содержатся сведения о:
Архитектура подсистемы смарт-карт
Поставщики предоставляют смарт-карты и средства чтения смарт-карт, и во многих случаях поставщики отличаются для смарт-карт и средства чтения смарт-карт. Драйверы для средств чтения смарт-карт записываются в стандарт "Персональный компьютер /Смарт-карта" (PC/SC). Каждая смарт-карта должна иметь поставщик служб шифрования (CSP), который использует интерфейсы CryptoAPI для включения криптографических операций, и API WinSCard для обеспечения связи с оборудованием смарт-карт.
Выбор смарт-карты
В следующих разделах этого раздела описывается, Windows использует архитектуру смарт-карт для выбора правильного программного обеспечения, поставщика и учетных данных для успешного входа в смарт-карты:
Все мы пользуемся разными видами смарт-карт в повседневной жизни. Наиболее яркими примерами смарт-карт являются: SIM-карты, кредитные карты, электронные документы и т.д.
По сути, смарт-карта — это оптимизированный для криптографии микроконтроллер с повышенным уровнем безопасности. Что это означает? В отличие от стандартного микроконтроллера доступ к памяти смарт-карты строго контролируется процессором. Таким образом, чтение данных с карты их написание на ней регулируются ПО самой карты. Более того, производители чипов предпринимают меры по предотвращению несанкционированного доступа (копирования всей памяти, перепрограммирования) к карте на электронном и физическом уровне.
Применение смарт-карты
Смарт-карта используется в тех случаях, когда необходимо удостоверить подлинность ее обладателя. Примером тому служит SIM-карта. Ее главной ролью является доказать оператору, что телефон, подключившийся к сети, принадлежит конкретному абоненту. После подобной проверки оператор сможет направлять коммуникацию с номера и на номер абонента именно тому телефону, а также регистрировать платежный баланс абонента.
- Сохранение идентификационных данных обладателя карты (чаще всего ID-номера, а не контактные данные обладателя).
- Сохранение и проверка PIN-кодов для осуществления двухфакторной аутентификации.
- Генерация и сохранение криптографических ключей и сертификатов. Обычно данные ключи используются исключительно для исполнения других функции внутри карты и не подлежат чтению.
- Генерация цифровой подписи.
- Аутентификация по схеме «Вызов-ответ».
- Иные специфические функции, присущие тому или иному виду карты.
Работа смарт-карты
Карты не работают автономно, а только в связке с так называемым терминалом (телефон, банкомат, иной проводной или беспроводной электронный читатель). Читатель обеспечивает карту электричеством и посылает команды. Карта никогда не инициирует коммуникацию, а всегда обязательно отвечает на любые посланные ей терминалом команды. В случае отсутствия ответа карта будет считаться «MUTED», т.е. не работающей. В подобной ситуации терминал либо никак не реагирует на ошибку, либо пытается восстановить общение с картой после осуществления RESET.
На логическом уровне коммуникация между терминалом и картой происходит в формате APDU, описанном стандартом ISO7816-4. Что касается физического уровня, то выше упомянутое общение регулируется не каким-то одним определенным стандартом, а их множеством. К примеру, существуют стандарты для контактного (ISO7816-3 T=0 и T=1, USB и т.д.) и бесконтактного (ISO14443, NFC/SWP) общения.
- Инициализация физического канала (Cold reset, ATR, и т.д.)
- Выбор с помощью команды SELECT желаемой программы. Данный шаг является опциональным. В случае если он не исполняется, то общение будет осуществляться с программой, выбранной по умолчанию при инициализации канала
- Дальнейшее общение для реализации конкретных задач
Карты Native и Javacard
Некоторые смарт-карты выходят в производство с уже заранее установленными на них и не подлежащими изменению, дополнению, либо удалению одной или более программами, предназначенными для исполнения конкретных функций (SIM и USIM, EMV и т.д.). Подобные карты, носящие название Native, являются привлекательными благодаря их низкой цене (при оптовых закупках) и относительной простоте используемого для их программирования кода, что уменьшает вероятность проблем с безопасностью карты. Однако наиболее интересными, на мой взгляд, картами являются карты на основе JavaCard и Global Platform, в которых ОС карты — это платформа, на которой можно установить различные приложения. Приложения, написанные для JavaCard, с использованием стандартных API, можно будет загрузить на все карты, поддерживающие совместимую версию платформы, вне зависимости от производителя карты. Что касается Global Platform, то это набор спецификаций, регулирующий безопасную администрацию карты, в том числе установку, блокировку либо удаление тех или иных приложений, а также управление жизненным циклом (Life Cycle) карты.
Маленькое примечание по поводу администрации карты. Пользователь карты, как правило, не является владельцем и администратором карты. К примеру, администратором SIM-Карты является оператор мобильной связи, а не абонент. Только оператор имеет право устанавливать или удалять приложения на/с карты. Тем не менее, существует также возможность приобрести «пустые» карты для собственной разработки приложений.
Таким образом, в данной части своей статьи я коснулся базиса работы смарт-карты, как на внешнем, так и на внутреннем уровне, а также дал краткое определение понятия смарт-карты. Следующие части статьи я хотел бы посвятить:
Поскольку статья вводная и обзорная, то рассматриваться будет простейшая разновидность смарт-карт — SIM-карты, полагаю, что таких карт на планете сейчас больше всего.
По сегодняшним меркам стандарт SIM выглядит архаично, но зато он идеален для первого знакомства с миром смарт-карт, усвоение принципов, которые заложены в основу этого стандарта, облегчит дальнейшее погружение в тему.
Если Вы «карточник», то вряд ли узнаете для себя что-то новое, разве что какие-нибудь не очень понятные моменты разложатся по полочкам, а может быть Вы разложете по полочкам то, что недопонял автор (но, напоминаю, держимся в рамках SIM!).
Смарт-карта является программно-аппаратным комплексом, по сути — миниатюрным компьютером, в состав которого входят, как минимум:
- процессор;
- оперативная память;
- подсистема хранения данных;
- операционная система.
Часто, но не всегда, в состав карты входит и Java VM. ОС, как таковая, конечному пользователю не видна.
Роль API выполняет обмен данными с картой посредством т.н. APDU .
Множество различных APDU представляет из себя набор команд, каждая из которых имеет следующую структуру (согласно ISO7816-4):
Элемент | Размер (байт) | Описание |
---|---|---|
CLA | 1 | класс команды |
INS | 1 | код инструкции |
P1 | 1 | параметр №1 |
P2 | 1 | параметр №2 |
L | 1 | длина данных, передаваемых карте. |
Data | L | данные |
APDU принято записывать в виде набора шестнадцатиричных цифр, вот так:
A0 A4 00 00 02 3F00
Для GSM SIM-карт используется CLA = A0 .
Приведу несколько кодов инструкций:
Инструкция | Описание |
---|---|
A4 | SELECT FILE |
B0 | READ BINARY |
B2 | READ RECORD |
C0 | GET RESPONSE |
20 | VERIFY CODE |
D6 | UPDATE BINARY |
DC | UPDATE RECORD |
В ответ на APDU карта всегда возвращает, как минимум, 2 байта, т.н. Status Word (SW),
причем первый и второй байт соответственно принято называть SW1 и SW2. По SW можно определить статус исполнения команды, причем SW1 обычно предоставляет основную информацию, а SW2 — дополнительную. В случае SIM-карт об успехе выполнения будут говорить статусы 90 00 и 9F xx (здесь xx — шестнадцатиричная цифра, длина дополнительной информации, о которой ниже).
Помимо SW карта может вернуть и данные. Есть также команды, после выполнения которых возможно получить дополнительную информацию.
Для этого предназначена команда:
Для того, чтобы воспользоваться «услугами» этой инструкции, нужно иметь в виду, что она должна быть вызвана сразу после той команды, результат которой требуется запросить. При вызове любой инструкции, отличной от GET RESPONSE, контекст предыдущей команды будет утрачен.
Если какая-либо инструкция позволяет использовать после своего вызова GET RESPONSE, то она в SW2 возвращает объем данных в байтах, который вернет команда GET RESPONSE.
Одним из ярких применений GET RESPONSE является ее использование после команды SELECT — оно дает возможность получить полезную информацию о выбранном объекте файловой системы.
Кстати, самое время вспомнить о файловой системе карты. Система эта является иерархической, существует корневая папка (Master File, MF), обычные папки (Dedicated File, DF) и, собственно, файлы (Elementary File, EF). Каждый объект файловой системы имеет идентификатор (File ID, FID), который, в простейшем случае, состоит из четырех шестнадцатиричных цифр и который заменяет ему имя. Например, MF всегда имеет идентификатор 3F00 . В рамках каждого карточного стандарта существует свой перечень зарезервированных файловых идентификаторов, например, файл адресной книги на SIM имеет идентификатор 6F3A, а файл для хранения SMS — 6F3C. У стандартных файлов также имеются и произносимые имена (исключительно для удобства человека, API их не использует), для указанных выше файлов они, такие:
EF ADN для 6F3A ;
EF SMS для 6F3С .
Базовая архитектура CSP и мини-хранилища смарт-карт
На рисунке 2 показана связь между CryptoAPI, CSP, базовым поставщиком служб шифрования смарт-карт (Base CSP) и мини-хранилищами смарт-карт.
Рис. 2 Базовая архитектура CSP и мини-хранилища смарт-карт
Архитектура поставщика учетных данных
В следующей таблице перечислены компоненты, включенные в архитектуру интерактивного входа Windows Server и Windows операционных систем.
Компонент | Описание |
---|---|
Winlogon | Предоставляет интерактивную инфраструктуру входа. |
Пользовательский интерфейс входа | Обеспечивает интерактивную отрисовку пользовательского интерфейса. |
Поставщики учетных данных (пароль и смарт-карта) | Описание сведений об учетных данных и сериализации учетных данных. |
Local Security Authority (LSA) | Обрабатывает учетные данные для входа. |
Пакеты проверки подлинности | Включает NTLM и протокол Kerberos. Взаимодействует с пакетами проверки подлинности сервера для проверки подлинности пользователей. |
Интерактивный вход в Windows начинается, когда пользователь нажимает клавиши CTRL+ALT+DEL. Сочетание клавиш CTRL+ALT+DEL называется безопасной последовательностью внимания (SAS). Чтобы другие программы и процессы не используют ее, Winlogon регистрирует эту последовательность во время процесса загрузки.
Рис. 1 Архитектура поставщика учетных данных
Как правило, пользователь, который входит на компьютер с помощью локальной учетной записи или учетной записи домена, должен ввести имя пользователя и пароль. Эти учетные данные используются для проверки удостоверения пользователя. При входе в систему смарт-карты учетные данные пользователя содержатся в микросхеме безопасности смарт-карты. Средство чтения смарт-карт позволяет компьютеру взаимодействовать с микросхемой безопасности на смарт-карте. При входе с помощью смарт-карты пользователи введите персональный идентификационный номер (ПИН-код) вместо имени пользователя и пароля.
Поставщики учетных данных — это объекты COM, которые выполняются в локальной системе и используются для сбора учетных данных. Пользовательский интерфейс входа обеспечивает интерактивную отрисовку пользовательского интерфейса, Winlogon предоставляет интерактивную инфраструктуру входа, а поставщики учетных данных работают с обоими этими компонентами для сбора и обработки учетных данных.
Winlogon указывает пользовательскому интерфейсу входа отображать плитки поставщика учетных данных после получения события SAS. Пользовательский интерфейс входа запрашивает у каждого поставщика учетных данных количество учетных данных, которые он хочет перечислить. Поставщики учетных данных могут указать одну из этих плиток в качестве значения по умолчанию. После того как все поставщики перечислили свои плитки, пользовательский интерфейс входа отображает их пользователю. Пользователь взаимодействует с плиткой, чтобы предоставить правильные учетные данные. Пользовательский интерфейс входа отправляет эти учетные данные для проверки подлинности.
В сочетании с вспомогательным оборудованием поставщики учетных данных могут расширить операционную систему Windows, чтобы пользователи могли входить в систему с помощью биометрических данных (например, отпечатков пальцев, retinal или голосового распознавания), пароля, ПИН-кода, сертификата смарт-карты или любого пользовательского пакета проверки подлинности. Предприятия и ИТ-специалисты могут разрабатывать и развертывать пользовательские механизмы проверки подлинности для всех пользователей домена, и им может явно потребоваться, чтобы пользователи могли использовать этот пользовательский механизм входа.
Примечание Поставщики учетных данных не являются механизмами принудительного применения. Они используются для сбора и сериализации учетных данных. Пакеты LSA и проверки подлинности обеспечивают безопасность.
Поставщики учетных данных могут быть разработаны для поддержки единого входа. В этом процессе они аутентификация пользователей в защищенной точке доступа к сети (с помощью RADIUS и других технологий) для входа на компьютер. Поставщики учетных данных также предназначены для поддержки сбора учетных данных для конкретного приложения и могут использоваться для проверки подлинности сетевых ресурсов, присоединения компьютеров к домену или предоставления согласия администратора для контроля учетных записей (UAC).
На компьютере может сосуществовать несколько поставщиков учетных данных.
Описание учетных данных, необходимых для проверки подлинности.
Обработка взаимодействия и логики с помощью внешних центров проверки подлинности.
Упаковка учетных данных для интерактивного и сетевого входа.
Примечание API поставщика учетных данных не отображает пользовательский интерфейс. В нем описывается, что необходимо отобразить.
В безопасном режиме доступен только поставщик учетных данных паролей.
Поставщик учетных данных смарт-карты доступен в безопасном режиме во время работы в сети.
Кэширование с базовым CSP и KSP смарт-карт
Архитектура смарт-карт использует механизмы кэширования для упрощения операций и улучшения доступа пользователя к ПИН-коду.
Кэширование данных. Кэш данных обеспечивает единый процесс для минимизации операций ввода-вывода смарт-карт.
Кэширование ПИН-кодов. Кэш ПИН-кода помогает пользователю повторно ввести ПИН-код при каждой проверке подлинности смарт-карты.
Кэширование данных
Каждый поставщик облачных служб реализует текущий кэш данных смарт-карт отдельно. Базовый CSP реализует надежный механизм кэширования, позволяющий одному процессу свести к минимуму операции ввода-вывода смарт-карт.
Существующий глобальный кэш работает следующим образом:
Приложение запрашивает криптографическую операцию. Например, сертификат пользователя должен считываться из смарт-карты.
CSP проверяет кэш для элемента.
Если элемент не найден в кэше или кэширован, но не является актуальным, элемент считывается из смарт-карты.
После считывания любого элемента из смарт-карты он добавляется в кэш. Любая существующая устарелая копия этого элемента заменяется.
CSP кэширует три типа объектов или данных: контакты (дополнительные сведения см. в разделе "Кэширование ПИН-кода"), сертификаты и файлы. При изменении любого из кэшированных данных соответствующий объект считывается из смарт-карты в последующих операциях. Например, если файл записывается на смарт-карту, кэш CSP становится неактивным для файлов, а другие процессы считывает смарт-карту хотя бы один раз, чтобы обновить кэш CSP.
Глобальный кэш данных размещается в смарт-картах для Windows службы. Windows включает два вызова API общедоступных смарт-карт: SCardWriteCache и SCardReadCache. Эти вызовы API делают функции глобального кэширования данных доступными для приложений. Каждая смарт-карта, которая соответствует спецификации мини-диска смарт-карты, имеет 16-байтовый идентификатор карты. Это значение используется для уникальной идентификации кэшированных данных, относящихся к заданной смарт-карте. Используется стандартный Windows GUID. Эти API позволяют приложению добавлять данные в глобальный кэш и считывать их.
Кэширование ПИН-кода
Кэш ПИН-кода защищает пользователя от ввода ПИН-кода при каждой проверке подлинности смарт-карты. После проверки подлинности смарт-карты она не будет отличаться между приложениями на стороне узла — любое приложение может получить доступ к частным данным на смарт-карте.
Чтобы устранить эту проблему, смарт-карта переходит в монопольное состояние при проверке подлинности приложения на смарт-карте. Однако это означает, что другие приложения не могут взаимодействовать со смарт-картой и будут заблокированы. Таким образом, такие монопольные подключения свернуты. Проблема в том, что протоколу (например, протоколу Kerberos) требуется несколько операций подписывания. Таким образом, протоколу требуется монопольный доступ к смарт-карте в течение длительного периода времени или несколько операций проверки подлинности. Здесь кэш ПИН-кода используется для минимизации монопольного использования смарт-карты без принудительного ввода ПИН-кода пользователем несколько раз.
В следующем примере показано, как это работает. В этом сценарии существует два приложения: Outlook и Internet Explorer. Приложения используют смарт-карты для различных целей.
Outlook запрашивает ПИН-код смарт-карты. Пользователь вводит правильный ПИН-код.
Пользователь открывает Internet Explorer и пытается получить доступ к защищенному сайту, для которого требуется проверка подлинности TLS для клиента.
Internet Explorer запрашивает у пользователя ПИН-код смарт-карты. Пользователь вводит правильный ПИН-код.
Операция закрытого ключа, связанная с TLS, выполняется на смарт-карте, и пользователь выполняет проверку подлинности и выполняет вход.
Базовый CSP внутренне поддерживает кэш ПИН-кода для каждого процесса. ПИН-код шифруется и хранится в памяти. Для защиты ПИН-кода используются следующие функции: RtlEncryptMemory, RtlDecryptMemory и RtlSecureZeroMemory, которые будут пустыми буферами, содержащим ПИН-код.
Типы файлов
API смарт-карт предусматривает манипуляции с тремя типами файлов:
аналог обычного бинарного файла любой файловой системы.
Средства работы с такими файлами — пара команд READ BINARY/UPDATE BINARY .
Файл, состоящий из фиксированного количества записей, причем все записи одинаковой длины, длина записи задается при создании файла.
Записей не может быть больше 255 шт., каждая запись не может быть длинее 255 байт.
Средство работы — пара READ RECORD/UPDATE RECORD.
Можно использовать как абсолютную (по номеру записи) так и относительную адресацию (следующая/предыдущая, но без цикличности).
Пример использования — записная книжка на SIM-карте.
В целом — то же, что и Linear Fixed, но со следующей дополнительной функциональностью:
При чтении: замкнутость — при использовании относительной адресации, переходя с последней на следующую запись попадаем на первую, переходя с первой на предыдущую запись, попадаем на последнюю.
При записи: допустима только относительная адресация с обращением только к предыдущей записи. Есть даже специальная команда, только для циклических файлов, которая обновляет самую старую запись файла (после этого она становится самой новой) — INCREASE.
Первая запись всегда хранит самые новые данные, а последняя — самые старые.
Пример использования — список ранее набранных номеров. Вообще, файлы данного типа используются гораздо реже, чем файлы других типов.
- INVALIDATE — обратимо изменяет состояние файла так, что:
- для него выставляется специальный флаг, т.е. мы можем узнать о том, что файл инвалидирован.
- в зависимости от настроек инвалидированного файла операции чтения и записи могут стать невозможны.
- REHABILITATE — возвращает инвалидированный ранее файл в обычное состояние, при этом возможные ограничения, наложенные инвалидацией, снимаются.
- Access Condition (AC) — состояние карты, в пределах текущей сесии, при котором для определенного файла возможен определенный вид операции.
- Условия доступа, самым известным из которых является предъявление PIN-кода.
Конечно же, то, что я здесь описал, не является реальной файловой системой — как правило, за этой абстракцией, на уровне ОС, спрятана знакомая всем FAT.
В завершение я просто обязан привести пример использования данного API в реальной жизни.
Думаю, многие уже догадались (или знали?), что самым известным и массовым устройством, использующим этот API постоянно и интенсивно, является обыкновенный мобильный терминал.
PS:
В следующей статье планирую рассказать о том, как можно применить полученные сейчас знания, работая с картой программно.
Технический справочник smart Card описывает инфраструктуру Windows для физических смарт-карт и работу компонентов, связанных с смарт-картами, в Windows. В этом документе также содержатся сведения о средствах, которые разработчики и администраторы информационных технологий могут использовать для устранения неполадок, отладки и развертывания сильной проверки подлинности на основе смарт-карт на предприятии.
Что такое смарт-карты?
Смарт-карты — это переносные портативные устройства, которые могут повысить безопасность таких задач, как проверка подлинности клиентов, подписание кода, защита электронной почты и вход с Windows учетной записью домена.
Хранилище с устойчивостью к взлому для защиты частных ключей и других форм личной информации.
Изоляция критически важных для безопасности вычислений, которые включают проверку подлинности, цифровые подписи и обмен ключами с других частей компьютера. Эти вычисления выполняются на смарт-карте.
Переносимость учетных данных и другой личной информации между компьютерами на работе, дома или в пути.
Смарт-карты можно использовать для входов только в учетные записи домена, а не для локальных учетных записей. При использовании пароля для интерактивного доступа к учетной записи домена Windows для проверки подлинности используется протокол Kerberos версии 5 (v5). При использовании смарт-карты операционная система использует проверку подлинности Kerberos v5 с сертификатами X.509 v3.
Виртуальные смарт-карты были Windows Server 2012 и Windows 8 для облегчения необходимости физической смарт-карты, средства чтения смарт-карт и связанного администрирования этого оборудования. Сведения о технологии виртуальных смарт-карт см. в обзоре виртуальных смарт-карт.
В этом разделе для ИТ-специалистов и разработчиков смарт-карт описывается, как смарт-карты для службы Windows (прежнее название — smart card Resource Manager) управляют средствами чтения и взаимодействиями с приложениями.
Служба "Смарт-карты для Windows" предоставляет базовую инфраструктуру для всех остальных компонентов смарт-карт, так как она управляет средствами чтения смарт-карт и взаимодействием приложений на компьютере. Он полностью соответствует спецификациям, задамой рабочей группой PC/SC. Дополнительные сведения об этих спецификациях см. на веб-сайте спецификаций рабочей группы PC/SC.
Смарт-карты для Windows службы выполняются в контексте локальной службы и реализуются как общая служба процесса узла служб (svchost). Служба Smart Cards for Windows, Scardsvr, имеет следующее описание службы:
Примечание Чтобы winscard.dll в качестве правильного установщика класса, INF-файл для средства чтения смарт-карт должен указывать следующие значения для class и ClassGUID:
Class=SmartCardReader
ClassGuid=
По умолчанию служба настроена для работы в ручном режиме. Создатели драйверов чтения смарт-карт должны настроить свои INF, чтобы они запускали службу автоматически, а winscard.dll файлы вызывайте предопределенную точку входа, чтобы запустить службу во время установки. Точка входа определяется как часть класса SmartCardReader и не вызывается напрямую. Если устройство объявляет себя как часть этого класса, точка входа автоматически вызывается для запуска службы при вставке устройства. Использование этого метода гарантирует, что служба будет включена при необходимости, но она также будет отключена для пользователей, которые не используют смарт-карты.
При запуске службы она выполняет несколько функций:
Он регистрируется для уведомлений службы.
Он регистрируется для Plug and Play (PnP), связанных с удалением и добавлением устройств.
Он инициализирует кэш данных и глобальное событие, которое сообщает о запуске службы.
Служба смарт-карт Windows классифицирует каждый слот чтения смарт-карт как уникальный модуль чтения, и каждый слот также управляется отдельно, независимо от физических характеристик устройства. Служба смарт-карт Windows обрабатывает следующие высокоуровневые действия:
Аудитория
В этом документе объясняется, как Windows инфраструктура смарт-карт. Чтобы понять эту информацию, необходимо иметь базовые знания об инфраструктуре общедоступных ключей (PKI) и понятиях смарт-карт. Этот документ предназначен для:
Enterprise ИТ-разработчиков, менеджеров и сотрудников, которые планируют развертывание или использование смарт-карт в своей организации.
Поставщики смарт-карт, которые пишут минидрайверы смарт-карт или поставщики учетных данных.
Читайте также: