Поделиться через

Архитектура смарт-карт

В этом разделе для ИТ-специалистов описывается архитектура системы, которая поддерживает смарт-карты в операционной системе Windows, включая архитектуру поставщика учетных данных и архитектуру подсистемы интеллектуальной карта.

Проверка подлинности — это процесс проверки удостоверения объекта или человека. При проверке подлинности объекта, например интеллектуального карта, целью является проверка подлинности объекта. При проверке подлинности пользователя цель заключается в том, чтобы убедиться, что вы не имеете дело с самозваном.

В сетевом контексте проверка подлинности — это проверка подлинности сетевого приложения или ресурса. Как правило, удостоверение подтверждается криптографической операцией, в которой используется ключ, известный только пользователю (например, с шифрованием с открытым ключом) или общий ключ. Серверная часть обмена проверкой подлинности сравнивает подписанные данные с известным криптографическим ключом для проверки попытки проверки подлинности. Хранение криптографических ключей в безопасном центральном расположении делает процесс проверки подлинности масштабируемым и обслуживаемым.

Для смарт-карт Windows поддерживает архитектуру поставщика, которая соответствует требованиям к безопасной проверке подлинности и расширяема, чтобы можно было включить пользовательских поставщиков учетных данных. В этом разделе содержатся сведения о:

Архитектура поставщика учетных данных

В следующей таблице перечислены компоненты, включенные в архитектуру интерактивного входа.

Компонент Описание
Winlogon Предоставляет интерактивную инфраструктуру входа.
Пользовательский интерфейс входа Обеспечивает интерактивную отрисовку пользовательского интерфейса.
Поставщики учетных данных (пароль и смарт-карта) Описание учетных данных и сериализация учетных данных.
Локальный центр безопасности (LSA) Обрабатывает учетные данные входа.
Пакеты проверки подлинности Включает NTLM и протокол Kerberos. Обмен данными с пакетами проверки подлинности сервера для проверки подлинности пользователей.

Интерактивный вход в Windows начинается, когда пользователь нажимает клавиши CTRL+ALT+DEL. Сочетание клавиш CTRL+ALT+DEL называется последовательностью безопасного внимания (SAS). Чтобы другие программы и процессы не использовали его, Winlogon регистрирует эту последовательность во время процесса загрузки.

После получения SAS пользовательский интерфейс создает плитку входа на основе сведений, полученных от зарегистрированных поставщиков учетных данных. На следующем рисунке показана архитектура поставщиков учетных данных в операционной системе Windows.

Архитектура поставщика учетных данных.

Как правило, пользователь, который входит на компьютер с помощью локальной учетной записи или учетной записи домена, должен ввести имя пользователя и пароль. Эти учетные данные используются для проверки удостоверения пользователя. Для смарт-карта входа учетные данные пользователя содержатся в микросхеме безопасности смарт-карта. Интеллектуальное средство чтения карта позволяет компьютеру взаимодействовать с микросхемой безопасности на смарт-карта. Когда пользователи входят с помощью смарт-карта, они вводят личный идентификационный номер (ПИН-код) вместо имени пользователя и пароля.

Поставщики учетных данных — это внутрипроцессные COM-объекты, которые выполняются в локальной системе и используются для сбора учетных данных. Пользовательский интерфейс входа обеспечивает интерактивную отрисовку пользовательского интерфейса, Winlogon — интерактивную инфраструктуру входа, а поставщики учетных данных работают с обоими этими компонентами, помогая собирать и обрабатывать учетные данные.

Winlogon указывает пользовательскому интерфейсу входа отображать плитки поставщика учетных данных после получения события SAS. Пользовательский интерфейс входа запрашивает у каждого поставщика учетных данных количество учетных данных, которые он хочет перечислить. Поставщики учетных данных могут указать одну из этих плиток по умолчанию. Когда все поставщики перечислит свои плитки, пользовательский интерфейс входа отображает их для пользователя. Пользователь взаимодействует с плиткой, чтобы предоставить необходимые учетные данные. Пользовательский интерфейс входа отправляет эти учетные данные для проверки подлинности.

В сочетании со вспомогательным оборудованием поставщики учетных данных могут расширить операционную систему Windows, позволяя пользователям выполнять вход с помощью биометрических данных (например, распознавания отпечатков пальцев, сетчатки или голоса), пароля, ПИН-кода, смарт-сертификата карта или любого пользовательского пакета проверки подлинности. Предприятия и ИТ-специалисты могут разрабатывать и развертывать пользовательские механизмы проверки подлинности для всех пользователей домена и явно требовать от пользователей использования этого пользовательского механизма входа.

Примечание.

Поставщики учетных данных не являются механизмами принудительного применения. Они используются для сбора и сериализации учетных данных. Пакеты LSA и проверки подлинности обеспечивают безопасность.

Поставщики учетных данных могут быть разработаны для поддержки единого входа. В этом процессе они проверяют подлинность пользователей в безопасной точке сетевого доступа (с помощью RADIUS и других технологий) для входа на компьютер. Поставщики учетных данных также предназначены для поддержки сбора учетных данных для конкретного приложения, и их можно использовать для проверки подлинности сетевых ресурсов, присоединения компьютеров к домену или предоставления согласия администратора для контроля учетных записей пользователей (UAC).

На компьютере могут существовать несколько поставщиков учетных данных.

Поставщики учетных данных должны быть зарегистрированы на компьютере под управлением Windows и отвечают за:

  • Описание учетных данных, необходимых для проверки подлинности
  • Обработка связи и логики с внешними центрами проверки подлинности
  • Упаковка учетных данных для интерактивного и сетевого входа

Примечание.

API поставщика учетных данных не отображает пользовательский интерфейс. В нем описывается, что необходимо отрисовывать.
В безопасном режиме доступен только поставщик учетных данных пароля.
Поставщик учетных данных интеллектуальной карта доступен в безопасном режиме во время сети.

Архитектура подсистемы интеллектуальной карта

Поставщики предоставляют смарт-карты и средства чтения смарт-карта, и во многих случаях поставщики отличаются для смарт-карта и смарт-карта читателя. Драйверы для чтения смарт-карта написаны в стандарте персональный компьютер/смарт-карта (PC/SC). Каждая интеллектуальная карта должна иметь поставщика служб шифрования (CSP), который использует интерфейсы CryptoAPI для включения криптографических операций, и API WinSCard для обеспечения связи с интеллектуальным карта оборудованием.

Базовая архитектура CSP и smart карта minidriver

На следующем рисунке показана связь между CryptoAPI, CSP, поставщиком базовых служб шифрования смарт-карт (Base CSP) и интеллектуальными карта мини-drivers.

Базовая архитектура CSP и интеллектуального карта minidriver.

Кэширование с помощью базового CSP и интеллектуального карта KSP

Интеллектуальная архитектура карта использует механизмы кэширования для упрощения операций и улучшения доступа пользователя к ПИН-коду.

  • Кэширование данных. Кэш данных обеспечивает единый процесс, чтобы свести к минимуму интеллектуальные карта операций ввода-вывода.
  • Кэширование ПИН-кода. Кэш ПИН-кода помогает пользователю повторно ввести ПИН-код каждый раз, когда смарт-карта не прошел проверку подлинности.

Кэширование данных

Каждый поставщик служб CSP реализует текущий кэш данных интеллектуальной карта отдельно. Базовый CSP реализует надежный механизм кэширования, который позволяет одному процессу свести к минимуму интеллектуальные карта операций ввода-вывода.

Существующий глобальный кэш работает следующим образом:

  1. Приложение запрашивает криптографическую операцию. Например, сертификат пользователя считывается из смарт-карта
  2. Поставщик служб CSP проверяет кэш элемента.
  3. Если элемент не найден в кэше или элемент кэшируется, но не является актуальным, он считывается из смарт-карта
  4. После считывания любого элемента из смарт-карта он добавляется в кэш. Все существующие устаревшие копии этого элемента заменяются.

CSP кэширует три типа объектов или данных: контакты (дополнительные сведения см. в разделе Кэширование ПИН-кода), сертификаты и файлы. Если какие-либо кэшированные данные изменяются, соответствующий объект считывается из смарт-карта в последующих операциях. Например, если файл записывается в смарт-карта, кэш CSP становится устаревшим для файлов, а другие процессы считывают смарт-карта хотя бы один раз, чтобы обновить кэш CSP.

Глобальный кэш данных размещается в службе смарт-карт для Windows. Windows включает два общедоступных вызова API смарт-карта: SCardWriteCache и SCardReadCache. Эти вызовы API делают глобальное кэширование данных доступными для приложений. Каждый интеллектуальный карта, соответствующий спецификации smart карта minidriver, имеет 16-байтовый идентификатор карта. Это значение используется для уникальной идентификации кэшированных данных, относящихся к заданному интеллектуальному карта. Используется стандартный тип GUID Windows. Эти API позволяют приложению добавлять данные в глобальный кэш и считывать их из них.

Кэширование ПИН-кода

Кэш ПИН-кодов защищает пользователя от ввода ПИН-кода каждый раз, когда смарт-карта не прошел проверку подлинности. После проверки подлинности смарт-карта не будет различаться между приложениями на стороне узла. Любое приложение может получить доступ к частным данным на смарт-карта.

Чтобы устранить эту проблему, смарт-карта переходит в монопольное состояние, когда приложение проходит проверку подлинности на смарт-карта. Однако это означает, что другие приложения не могут взаимодействовать со смарт-карта и будут заблокированы. Таким образом, такие монопольные подключения сведены к минимуму. Проблема заключается в том, что для протокола (например, протокола Kerberos) требуется несколько операций подписывания. Таким образом, протокол требует монопольного доступа к интеллектуальной карта в течение длительного периода времени или требует нескольких операций проверки подлинности. Здесь кэш ПИН-кодов используется для минимизации монопольного использования смарт-карта, не заставляя пользователя вводить ПИН-код несколько раз.

В следующем примере показано, как это работает. В этом сценарии есть два приложения: Outlook и Internet Обозреватель. Приложения используют смарт-карты для различных целей.

  1. Пользователь запускает Outlook и пытается отправить подписанное сообщение электронной почты. Закрытый ключ находится на смарт-карта
  2. Outlook предлагает пользователю ввести ПИН-код смарт-карта. Пользователь вводит правильный ПИН-код.
  3. Данные электронной почты отправляются в смарт-карта для операции сигнатуры. Клиент Outlook форматирует ответ и отправляет сообщение электронной почты
  4. Пользователь открывает интернет-Обозреватель и пытается получить доступ к защищенному сайту, требующего проверки подлинности TLS для клиента.
  5. Интернет-Обозреватель запрашивает у пользователя ПИН-код смарт-карта. Пользователь вводит правильный ПИН-код.
  6. Операция с закрытым ключом, связанная с TLS, выполняется на смарт-карта, и пользователь проходит проверку подлинности и вошел в систему.
  7. Пользователь возвращается в Outlook для отправки другого подписанного сообщения электронной почты. На этот раз пользователю не будет предложено ввести ПИН-код, так как ПИН-код кэшируется из предыдущей операции. Аналогичным образом, если пользователь снова использует интернет-Обозреватель для другой операции, интернет-Обозреватель не запрашивает у пользователя ПИН-код.

Базовый поставщик CSP внутренне поддерживает кэш ПИН-кода для каждого процесса. ПИН-код шифруется и хранится в памяти. Для защиты ПИН-кода используются функции RtlEncryptMemory, RtlDecryptMemory и RtlSecureZeroMemory, которые будут пустыми буферами, содержащими ПИН-код.

Выбор смарт-карта

В следующих разделах этой статьи описывается, как Windows использует архитектуру интеллектуального карта для выбора правильного программного обеспечения, поставщика и учетных данных для интеллектуального карта карта.

Уровни спецификации контейнера

В ответ на вызов CryptAcquireContext в CryptoAPI базовый поставщик CSP пытается сопоставить контейнер, заданный вызывающим элементом, определенному интеллектуальному карта и средству чтения. Вызывающий объект может предоставить имя контейнера с различными уровнями специфики, как показано в следующей таблице, и отсортировать его от наиболее конкретных к наименее конкретным запросам.

Аналогичным образом в ответ на вызов NCryptOpenKey в CNG смарт-карта KSP пытается сопоставить контейнер таким же образом и принимает тот же формат контейнера, как показано в следующей таблице.

Примечание.

Перед открытием ключа с помощью интеллектуальной карта KSP необходимо выполнить вызов NCryptOpenStorageProvider (MS_SMART_CARD_KEY_STORAGE_PROVIDER).

Тип Имя Формат
Я Имя читателя и имя контейнера \.<Reader Name><Container Name>
II Имя читателя и имя контейнера (NULL) \.<Reader Name>
III Только имя контейнера <Container Name>
IV Только контейнер по умолчанию (NULL) NULL

Базовый CSP и интеллектуальный карта KSP кэша смарт-карта обрабатывать сведения о процессе вызова и смарт-картах, к которые получил доступ процесс. При поиске контейнера интеллектуальной карта базовый CSP или интеллектуальный карта KSP сначала проверяет кэш для процесса. Если кэшированный дескриптор недопустим или совпадение не найдено, вызывается API SCardUIDlg для получения карта дескриптора.

Операции с контейнерами

С помощью CryptAcquireContext можно запросить следующие три операции контейнера:

  1. Создайте контейнер. (Эквивалент CNG CryptAcquireContext с параметром dwFlags имеет значение CRYPT_NEWKEYSET — NCryptCreatePersistedKey.)
  2. Откройте существующий контейнер. (Эквивалент CNG CryptAcquireContext для открытия контейнера — NCryptOpenKey.)
  3. Удаление контейнера. (Эквивалент CNG CryptAcquireContext с параметром dwFlags, для CRYPT_DELETEKEYSET имеет значение NCryptDeleteKey.)

Эвристика, используемая для связывания криптографического дескриптора с определенным интеллектуальным карта и средством чтения, основана на запрошенной операции контейнера и используемом уровне спецификации контейнера.

В следующей таблице показаны ограничения для операции создания контейнера.

Спецификация Ограничение
Без автоматического контекста Создание контейнера ключей должно всегда иметь возможность отображать пользовательский интерфейс, например запрос ПИН-кода.
Отсутствие перезаписи существующих контейнеров Если указанный контейнер уже существует в выбранной интеллектуальной карта, выберите другой интеллектуальный карта или отмените операцию.

Флаги контекста

В следующей таблице показаны флаги контекста, используемые в качестве ограничений для операции создания контейнера.

Flag Описание
CRYPT_SILENT Во время этой операции невозможно отобразить пользовательский интерфейс.
CRYPT_MACHINE_KEYSET Во время этой операции не следует использовать кэшированные данные.
CRYPT_VERIFYCONTEXT На смарт-карта можно получить доступ только к общедоступным данным.

Помимо операций с контейнерами и спецификаций контейнеров, при выборе интеллектуального карта необходимо учитывать другие пользовательские параметры, такие как флаги CryptAcquireContext.

Важно.

Флаг CRYPT_SILENT нельзя использовать для создания контейнера.

Создание контейнера в автоматическом контексте

Приложения могут вызывать базовый CSP с CRYPT_DEFAULT_CONTAINER_OPTIONALпомощью , задать ПИН-код в автоматическом контексте, а затем создать новый контейнер в автоматическом контексте. Эта операция выполняется следующим образом:

  1. Вызовите CryptAcquireContext, передав смарт-карта имя средства чтения в в качестве уровня спецификации контейнера типа II и указав CRYPT_DEFAULT_CONTAINER_OPTIONAL флаг
  2. Вызовите CryptSetProvParam, указав PP_KEYEXCHANGE_PIN или PP_SIGNATURE_PIN и ПИН-код ASCII, завершающийся null.
  3. Освобождение контекста, полученного на шаге 1
  4. Вызовите CryptAcquireContext с CRYPT_NEWKEYSETпомощью и укажите уровень спецификации контейнера типа I.
  5. Вызовите CryptGenKey, чтобы создать ключ

Поведение выбора интеллектуального карта

В некоторых из следующих сценариев пользователю может быть предложено вставить смарт-карта. Если контекст пользователя работает без звука, эта операция завершается ошибкой и пользовательский интерфейс не отображается. В противном случае в ответ на пользовательский интерфейс пользователь может вставить смарт-карта или нажать кнопку Отмена. Если пользователь отменяет операцию, операция завершается ошибкой. На блок-диаграмме показаны шаги выбора, выполняемые операционной системой Windows.

Процесс выбора интеллектуальной карта.

Как правило, поведение выбора интеллектуальной карта обрабатывается API SCardUIDlgSelectCard. Базовый поставщик служб CSP взаимодействует с этим API, вызывая его напрямую. Базовый поставщик служб CSP также отправляет функции обратного вызова, которые имеют целью фильтрацию и сопоставление смарт-карт кандидатов. Вызывающие элементы CryptAcquireContext предоставляют интеллектуальные карта соответствующие сведения. Для поиска определенных смарт-карт в базовом CSP используется сочетание смарт-карта серийных номеров, имен читателей и имен контейнеров.

Каждый вызов может привести к SCardUI * дополнительной информации, считываемой из смарт-карта кандидата. Эти сведения кэшируются в интеллектуальном карта обратном вызове выбора базового CSP.

Соответствие интеллектуальному карта читателю

Для уровней спецификации контейнеров типа I и II процесс выбора интеллектуальной карта менее сложный, так как только интеллектуальные карта в именованном средстве чтения могут считаться совпадением. Процесс сопоставления интеллектуального карта с интеллектуальным средством чтения карта выполняется следующим образом:

  1. Найдите запрошенное средство чтения смарт-карта. Если его не удается найти, процесс завершается сбоем (для этого требуется поиск в кэше по имени читателя).
  2. Если в средстве чтения нет интеллектуальной карта, пользователю будет предложено вставить смарт-карта. (это только в нерабочем режиме; если вызов выполняется в автоматическом режиме, он завершается ошибкой)
  3. Только для уровня спецификации контейнера II определяется имя контейнера по умолчанию в выбранном интеллектуальном карта.
  4. Чтобы открыть существующий контейнер или удалить существующий контейнер, найдите указанный контейнер. Если указанный контейнер не найден в этой интеллектуальной карта, пользователю будет предложено вставить смарт-карта
  5. Если система пытается создать новый контейнер, если указанный контейнер уже существует на этом интеллектуальном карта, процесс завершается сбоем.

Создание интеллектуального карта соответствия

Для уровней спецификации контейнеров III и IV используется более широкий метод для сопоставления соответствующего интеллектуального карта с контекстом пользователя, так как несколько кэшированных смарт-карт могут соответствовать указанным критериям.

Открытие существующего контейнера по умолчанию (читатель не указан)

Примечание.

Для выполнения этой операции требуется использовать интеллектуальный карта с базовым поставщиком служб CSP.

  1. Для каждой интеллектуальной карта, к которому обращается базовый поставщик служб CSP, а сведения о дескрипторе и контейнере кэшируются, базовый поставщик CSP ищет допустимый контейнер по умолчанию. Выполняется попытка выполнить операцию в кэшированном SCARDHANDLE, чтобы проверить ее допустимость. Если дескриптор интеллектуальной карта недопустим, базовый поставщик CSP продолжает поиск нового интеллектуального карта
  2. Если соответствующий интеллектуальный карта не найден в кэше базового CSP, базовый поставщик CSP вызывает подсистему интеллектуальной карта. SCardUIDlgSelectCard() используется с соответствующим фильтром обратного вызова для поиска соответствующего интеллектуального карта с допустимым контейнером по умолчанию

Открытие существующего контейнера с именем GUID (средство чтения не указано)

Примечание.

Для выполнения этой операции требуется использовать интеллектуальный карта с базовым поставщиком служб CSP.

  1. Для каждой интеллектуальной карта, уже зарегистрированной в базовом CSP, найдите запрошенный контейнер. Попробуйте выполнить операцию в кэшированном SCARDHANDLE, чтобы проверить ее допустимость. Если дескриптор интеллектуальной карта недопустим, серийный номер смарт-карта передается SCardUI * в API, чтобы продолжить поиск по этому конкретному интеллектуальному карта (а не только общее совпадение с именем контейнера).
  2. Если соответствующий интеллектуальный карта не найден в кэше базового CSP, выполняется вызов подсистемы интеллектуальной карта. SCardUIDlgSelectCard()используется с соответствующим фильтром обратного вызова для поиска соответствующего интеллектуального карта с запрошенным контейнером. Или, если интеллектуальный карта серийный номер получен в результате поиска на шаге 1, фильтр обратного вызова пытается соответствовать серийному номеру, а не имени контейнера.

Создание контейнера (не указано средство чтения)

Примечание.

Для выполнения этой операции требуется использовать интеллектуальный карта с базовым поставщиком служб CSP.

Если ПИН-код не кэшируется, для создания контейнера не допускается CRYPT_SILENT, так как пользователю необходимо как минимум ввести ПИН-код.

Для других операций вызывающий объект может получить контекст проверки контейнера по умолчанию CRYPT_DEFAULT_CONTAINER_OPTIONAL , а затем выполнить вызов с помощью CryptSetProvParam, чтобы кэшировать ПИН-код пользователя для последующих операций.

  1. Для каждой интеллектуальной карта, уже известной поставщику служб CSP, обновите хранимую SCARDHANDLE и выполните следующие проверки:
    1. Если смарт-карта удалена, продолжите поиск
    2. Если смарт-карта присутствует, но у него уже есть именованный контейнер, продолжите поиск
    3. Если смарт-карта доступен, но вызов CardQueryFreeSpace указывает, что смарт-карта недостаточно места для дополнительного контейнера ключей, продолжайте поиск.
    4. В противном случае используйте первую доступную интеллектуальную карта, которая соответствует указанным выше критериям для создания контейнера.
  2. Если соответствующий интеллектуальный карта не найден в кэше CSP, вызовите подсистему интеллектуальной карта. Обратный вызов, используемый для фильтрации перечисляемых смарт-карт, проверяет, что смарт-карта-кандидат еще не имеет именованного контейнера, а CardQueryFreeSpace указывает, что смарт-карта имеет достаточно места для дополнительного контейнера. Если подходящие интеллектуальные карта не найдены, пользователю предлагается вставить смарт-карта

Удаление контейнера

  1. Если указанное имя контейнера имеет значение NULL, контейнер по умолчанию удаляется. При удалении контейнера по умолчанию новый контейнер по умолчанию выбирается произвольно. По этой причине эта операция не рекомендуется
  2. Для каждой интеллектуальной карта, уже известной поставщику служб CSP, обновите хранимую SCARDHANDLE и выполните следующие проверки:
    1. Если у смарт-карта нет именованного контейнера, продолжайте поиск.
    2. Если смарт-карта имеет именованный контейнер, но дескриптор интеллектуального карта больше не действителен, сохраните серийный номер соответствующего смарт-карта и передайте его в SCardUI.
  3. Если соответствующий интеллектуальный карта не найден в кэше CSP, вызовите подсистему интеллектуальной карта. Обратный вызов, используемый для фильтрации перечисляемых смарт-карт, должен убедиться, что смарт-карта-кандидат имеет именованный контейнер. Если серийный номер был указан в результате предыдущего поиска кэша, обратный вызов должен фильтровать перечисляемые смарт-карты по серийному номеру, а не по соответствию контейнера. Если контекст не является автоматическим и не найден подходящий интеллектуальный карта, отобразится пользовательский интерфейс, предлагающий пользователю вставить смарт-карта

Базовая архитектура CSP и KSP в Windows

На следующей схеме показана архитектура шифрования, используемая операционной системой Windows.

Архитектура шифрования.

Базовые свойства CSP и интеллектуального карта KSP в Windows

Примечание.

Определения API находятся в WinCrypt.h и WinSCard.h.

Свойство Описание
PP_USER_CERTSTORE — используется для возврата HCERTSTORE , содержащего все пользовательские сертификаты в смарт-карта
— только для чтения (используется только ).CryptGetProvParam
— вызывающий объект, отвечающий за закрытие хранилища сертификатов.
— сертификат, закодированный с помощью PKCS_7_ASN_ENCODING или X509_ASN_ENCODING
— CSP должен задаваться KEY_PROV_INFO для сертификатов.
— Хранилище сертификатов должно быть хранилищем в памяти.
— у сертификатов должно быть допустимое CRYPT_KEY_PROV_INFO свойство.
PP_ROOT_CERTSTORE — Чтение и запись (используется CryptGetProvParam и CryptSetProvParam)
— используется для записи коллекции корневых сертификатов в смарт-карта или возврата HCERTSTORE, которая содержит корневые сертификаты из смарт-карта
— используется в основном для присоединения к домену с помощью интеллектуальной карта
— вызывающий объект, отвечающий за закрытие хранилища сертификатов.
PP_SMARTCARD_READER — только для чтения (используется только ).CryptGetProvParam
— возвращает имя средства чтения смарт-карта в виде строки ANSI, которая используется для создания полного имени контейнера (т. е. средства чтения смарт-карта плюс контейнера).
PP_SMARTCARD_GUID — возвращает идентификатор GUID смарт-карта (также называемый серийным номером), который должен быть уникальным для каждого интеллектуального карта
— используется службой распространения сертификатов для отслеживания источника корневого сертификата.
PP_UI_PROMPT — используется для задания строки поиска для диалогового SCardUIDlgSelectCard окна вставки карта.
— постоянный для всего процесса, когда он задан.
— только запись (используется только )CryptSetProvParam

Последствия для поставщиков служб конфигурации в Windows

Поставщики служб шифрования (CSP), включая пользовательские поставщики интеллектуальных карта CSP, по-прежнему поддерживаются, но такой подход не рекомендуется. Использование существующего базового CSP и интеллектуального карта KSP с моделью smart карта minidriver для смарт-карт обеспечивает значительные преимущества с точки зрения производительности, а также кэширования ПИН-кода и данных. Один мини-накопитель можно настроить для работы на уровнях CryptoAPI и CNG. Это обеспечивает преимущества расширенной поддержки шифрования, включая шифрование на эллиптических кривых и AES.

Если смарт-карта зарегистрирован CSP и смарт-карта minidriver, то тот, который был установлен совсем недавно, будет использоваться для связи со смарт-карта.

Создание интеллектуального карта minidriver, CSP или KSP

Поставщики служб конфигурации и ключевые поставщики сертификатов предназначены для записи только в том случае, если в текущей архитектуре интеллектуального карта minidriver недоступны определенные функции. Например, архитектура smart карта minidriver поддерживает аппаратные модули безопасности, поэтому для аппаратного модуля безопасности можно написать мини-driver, а CSP или KSP может не потребоваться, если только они не требуются для поддержки алгоритмов, которые не реализованы в базовом CSP или интеллектуальном карта KSP.

Дополнительные сведения о написании смарт-карта minidriver, CSP или KSP см. в разделе Smart Card Minidrivers.