Compartir a través de

Arquitectura de tarjeta inteligente

En este tema para profesionales de TI se describe la arquitectura del sistema que admite tarjetas inteligentes en el sistema operativo Windows, incluida la arquitectura del proveedor de credenciales y la arquitectura del subsistema de tarjetas inteligentes.

La autenticación es un proceso para comprobar la identidad de un objeto o persona. Cuando se autentica un objeto, como una tarjeta inteligente, el objetivo es comprobar que el objeto es original. Al autenticar a una persona, el objetivo es comprobar que no está tratando con un impostor.

En un contexto de red, la autenticación es el acto de probar la identidad de una aplicación o recurso de red. Normalmente, la identidad se comprueba mediante una operación criptográfica que usa una clave que solo el usuario conoce (por ejemplo, con criptografía de clave pública) o una clave compartida. El lado servidor del intercambio de autenticación compara los datos firmados con una clave criptográfica conocida para validar el intento de autenticación. El almacenamiento de las claves criptográficas en una ubicación central segura hace que el proceso de autenticación sea escalable y fácil de mantener.

En el caso de las tarjetas inteligentes, Windows admite una arquitectura de proveedor que cumple los requisitos de autenticación segura y es extensible para que pueda incluir proveedores de credenciales personalizadas. En este tema se incluye información sobre:

Arquitectura del proveedor de credenciales

En la tabla siguiente se enumeran los componentes que se incluyen en la arquitectura de inicio de sesión interactivo:

Componente Descripción
Winlogon Proporciona una infraestructura de inicio de sesión interactiva.
Interfaz de usuario de inicio de sesión Proporciona representación interactiva de la interfaz de usuario.
Proveedores de credenciales (contraseña y tarjeta inteligente) Describe la información de credenciales y la serialización de las credenciales.
Autoridad de seguridad local (LSA) Procesa las credenciales de inicio de sesión.
Paquetes de autenticación Incluye NTLM y el protocolo Kerberos. Se comunica con paquetes de autenticación de servidor para autenticar a los usuarios.

El inicio de sesión interactivo en Windows comienza cuando el usuario presiona CTRL+ALT+SUPR. La combinación de teclas CTRL+ALT+SUPR se denomina secuencia de atención segura (SAS). Para evitar que otros programas y procesos lo usen, Winlogon registra esta secuencia durante el proceso de arranque.

Después de recibir la SAS, la interfaz de usuario genera el icono de inicio de sesión a partir de la información recibida de los proveedores de credenciales registrados. En el siguiente gráfico se muestra la arquitectura de los proveedores de credenciales en el sistema operativo Windows.

Arquitectura del proveedor de credenciales.

Normalmente, un usuario que inicia sesión en un equipo mediante una cuenta local o una cuenta de dominio debe escribir un nombre de usuario y una contraseña. Estas credenciales se usan para comprobar la identidad del usuario. Para el inicio de sesión con tarjeta inteligente, las credenciales de un usuario están contenidas en el chip de seguridad de la tarjeta inteligente. Un lector de tarjetas inteligentes permite que el equipo interactúe con el chip de seguridad de la tarjeta inteligente. Cuando los usuarios inician sesión con una tarjeta inteligente, escriben un número de identificación personal (PIN) en lugar de un nombre de usuario y una contraseña.

Los proveedores de credenciales son objetos COM en proceso que se ejecutan en el sistema local y se usan para recopilar credenciales. La interfaz de usuario de inicio de sesión proporciona representación interactiva de la interfaz de usuario, Winlogon proporciona infraestructura de inicio de sesión interactiva y los proveedores de credenciales funcionan con ambos componentes para ayudar a recopilar y procesar credenciales.

Winlogon indica a la interfaz de usuario de inicio de sesión que muestre los iconos del proveedor de credenciales después de recibir un evento sas. La interfaz de usuario de inicio de sesión consulta a cada proveedor de credenciales el número de credenciales que quiere enumerar. Los proveedores de credenciales tienen la opción de especificar uno de estos iconos como predeterminado. Una vez que todos los proveedores han enumerado sus iconos, la interfaz de usuario de inicio de sesión los muestra al usuario. El usuario interactúa con un icono para proporcionar las credenciales adecuadas. La interfaz de usuario de inicio de sesión envía estas credenciales para la autenticación.

En combinación con el hardware auxiliar, los proveedores de credenciales pueden ampliar el sistema operativo Windows para permitir que los usuarios inicien sesión mediante biometría (por ejemplo, huella digital, retinal o reconocimiento de voz), contraseña, PIN, certificado de tarjeta inteligente o cualquier paquete de autenticación personalizado. Las empresas y los profesionales de TI pueden desarrollar e implementar mecanismos de autenticación personalizados para todos los usuarios del dominio, y pueden requerir explícitamente que los usuarios usen este mecanismo de inicio de sesión personalizado.

Nota

Los proveedores de credenciales no son mecanismos de cumplimiento. Se usan para recopilar y serializar credenciales. El LSA y los paquetes de autenticación aplican la seguridad.

Los proveedores de credenciales se pueden diseñar para admitir el inicio de sesión único (SSO). En este proceso, autentican a los usuarios en un punto de acceso de red seguro (mediante RADIUS y otras tecnologías) para iniciar sesión en el equipo. Los proveedores de credenciales también están diseñados para admitir la recopilación de credenciales específicas de la aplicación y se pueden usar para la autenticación en los recursos de red, la unión de equipos a un dominio o para proporcionar el consentimiento del administrador para el Control de cuentas de usuario (UAC).

Varios proveedores de credenciales pueden coexistir en un equipo.

Los proveedores de credenciales deben estar registrados en un equipo que ejecute Windows y son responsables de lo siguiente:

  • Descripción de la información de credenciales necesaria para la autenticación
  • Control de la comunicación y la lógica con entidades de autenticación externas
  • Empaquetado de credenciales para el inicio de sesión interactivo y de red

Nota

La API del proveedor de credenciales no representa la interfaz de usuario. Describe lo que se debe representar.
Solo el proveedor de credenciales de contraseña está disponible en modo seguro.
El proveedor de credenciales de tarjeta inteligente está disponible en modo seguro durante las redes.

Arquitectura del subsistema de tarjetas inteligentes

Los proveedores proporcionan tarjetas inteligentes y lectores de tarjetas inteligentes, y en muchos casos los proveedores son diferentes para la tarjeta inteligente y el lector de tarjetas inteligentes. Los controladores para los lectores de tarjetas inteligentes se escriben en el estándar de equipo personal/tarjeta inteligente (PC/SC). Cada tarjeta inteligente debe tener un proveedor de servicios criptográficos (CSP) que use las interfaces CryptoAPI para habilitar las operaciones criptográficas y las API de WinSCard para habilitar las comunicaciones con hardware de tarjeta inteligente.

Csp base y arquitectura de minidriver de tarjeta inteligente

En el gráfico siguiente se muestra la relación entre cryptoAPI, CSP, proveedor de servicios criptográficos base de tarjeta inteligente (CSP base) y minidriveres de tarjeta inteligente.

Csp base y arquitectura de minidriver de tarjeta inteligente.

Almacenamiento en caché con CSP base y KSP de tarjeta inteligente

La arquitectura de tarjeta inteligente usa mecanismos de almacenamiento en caché para ayudar a optimizar las operaciones y mejorar el acceso de un usuario a un PIN.

Almacenamiento en caché de datos

Cada CSP implementa la caché de datos de tarjeta inteligente actual por separado. El CSP base implementa un mecanismo de almacenamiento en caché sólido que permite un único proceso para minimizar las operaciones de E/S de tarjeta inteligente.

La memoria caché global existente funciona de la siguiente manera:

  1. La aplicación solicita una operación criptográfica. Por ejemplo, un certificado de usuario debe leerse desde la tarjeta inteligente.
  2. El CSP comprueba la memoria caché del elemento.
  3. Si el elemento no se encuentra en la memoria caché o si el elemento está almacenado en caché pero no está actualizado, el elemento se lee desde la tarjeta inteligente.
  4. Después de leer cualquier elemento de la tarjeta inteligente, se agrega a la memoria caché. Se reemplaza cualquier copia desactualizadas existente de ese elemento.

El CSP almacena en caché tres tipos de objetos o datos: anclajes (para obtener más información, consulte Almacenamiento en caché de PIN), certificados y archivos. Si alguno de los datos almacenados en caché cambia, el objeto correspondiente se lee de la tarjeta inteligente en operaciones sucesivas. Por ejemplo, si un archivo se escribe en la tarjeta inteligente, la memoria caché de CSP deja de estar actualizada para los archivos y otros procesos leen la tarjeta inteligente al menos una vez para actualizar su caché de CSP.

La caché de datos global se hospeda en el servicio Tarjetas inteligentes para Windows. Windows incluye dos llamadas API de tarjeta inteligente públicas, SCardWriteCache y SCardReadCache. Estas llamadas API hacen que la funcionalidad de almacenamiento en caché de datos global esté disponible para las aplicaciones. Cada tarjeta inteligente que se ajusta a la especificación del minidriver de tarjeta inteligente tiene un identificador de tarjeta de 16 bytes. Este valor se usa para identificar de forma única los datos almacenados en caché que pertenecen a una tarjeta inteligente determinada. Se usa el tipo GUID estándar de Windows. Estas API permiten a una aplicación agregar datos a la memoria caché global y leerlos.

Almacenamiento en caché de PIN

La caché de PIN protege al usuario de escribir un PIN cada vez que la tarjeta inteligente no está autenticada. Una vez autenticada una tarjeta inteligente, no diferenciará entre las aplicaciones del lado host: cualquier aplicación puede acceder a datos privados en la tarjeta inteligente.

Para mitigar esto, la tarjeta inteligente entra en un estado exclusivo cuando una aplicación se autentica en la tarjeta inteligente. Sin embargo, esto significa que otras aplicaciones no pueden comunicarse con la tarjeta inteligente y se bloquearán. Por lo tanto, estas conexiones exclusivas se minimizan. El problema es que un protocolo (como el protocolo Kerberos) requiere varias operaciones de firma. Por lo tanto, el protocolo requiere acceso exclusivo a la tarjeta inteligente durante un período prolongado o requiere varias operaciones de autenticación. Aquí es donde se usa la caché de PIN para minimizar el uso exclusivo de la tarjeta inteligente sin forzar al usuario a escribir un PIN varias veces.

En el ejemplo siguiente se muestra cómo funciona. En este escenario, hay dos aplicaciones: Outlook e Internet Explorer. Las aplicaciones usan tarjetas inteligentes para diferentes propósitos.

  1. El usuario inicia Outlook e intenta enviar un correo electrónico firmado. La clave privada está en la tarjeta inteligente
  2. Outlook solicita al usuario el PIN de la tarjeta inteligente. El usuario escribe el PIN correcto
  3. Los datos de correo electrónico se envían a la tarjeta inteligente para la operación de firma. El cliente de Outlook da formato a la respuesta y envía el correo electrónico.
  4. El usuario abre Internet Explorer e intenta acceder a un sitio protegido que requiere la autenticación de seguridad de la capa de transporte (TLS) para el cliente.
  5. Internet Explorer solicita al usuario el PIN de la tarjeta inteligente. El usuario escribe el PIN correcto
  6. La operación de clave privada relacionada con TLS se produce en la tarjeta inteligente y el usuario se autentica e inicia sesión
  7. El usuario vuelve a Outlook para enviar otro correo electrónico firmado. Esta vez, al usuario no se le pide un PIN porque el PIN se almacena en caché de la operación anterior. Del mismo modo, si el usuario usa Internet Explorer de nuevo para otra operación, Internet Explorer no solicitará al usuario un PIN.

El CSP base mantiene internamente una caché por proceso del PIN. El PIN se cifra y almacena en memoria. Las funciones que se usan para proteger el PIN son RtlEncryptMemory, RtlDecryptMemory y RtlSecureZeroMemory, que vaciarán los búferes que contenían el PIN.

Selección de tarjeta inteligente

En las secciones siguientes de este artículo se describe cómo Windows usa la arquitectura de tarjeta inteligente para seleccionar el software, el proveedor y las credenciales de lector de tarjetas inteligentes correctos para un inicio de sesión correcto de tarjeta inteligente:

Niveles de especificación de contenedor

En respuesta a una llamada a CryptAcquireContext en CryptoAPI, el CSP base intenta hacer coincidir el contenedor que el autor de la llamada especifica con una tarjeta inteligente y un lector específicos. El autor de la llamada puede proporcionar un nombre de contenedor con distintos niveles de especificidad, como se muestra en la tabla siguiente, y ordenados de las solicitudes más específicas a las menos específicas.

De forma similar, en respuesta a una llamada NCryptOpenKey en CNG, la tarjeta inteligente KSP intenta coincidir con el contenedor de la misma manera y toma el mismo formato de contenedor, como se muestra en la tabla siguiente.

Nota

Antes de abrir una clave mediante la tarjeta inteligente KSP, se debe realizar una llamada a NCryptOpenStorageProvider (MS_SMART_CARD_KEY_STORAGE_PROVIDER).

Tipo Nombre Formato
I Nombre del lector y nombre del contenedor \.<Reader Name><Container Name>
II Nombre del lector y nombre del contenedor (NULL) \.<Reader Name>
III Solo nombre de contenedor <Container Name>
IV Solo contenedor predeterminado (NULL) NULL

El CSP base y la tarjeta inteligente KSP almacenan en caché la información sobre el proceso de llamada y sobre las tarjetas inteligentes a las que ha accedido el proceso. Al buscar un contenedor de tarjeta inteligente, el CSP base o KSP de tarjeta inteligente comprueba primero el proceso en la memoria caché. Si el identificador almacenado en caché no es válido o no se encuentra ninguna coincidencia, se llama a la API SCardUIDlg para obtener el identificador de tarjeta.

Operaciones de contenedor

Las tres operaciones de contenedor siguientes se pueden solicitar mediante CryptAcquireContext:

  1. Cree un nuevo contenedor. (El equivalente de CNG de CryptAcquireContext con dwFlags establecido en CRYPT_NEWKEYSET es NCryptCreatePersistedKey).
  2. Abra un contenedor existente. (El equivalente de CNG de CryptAcquireContext para abrir el contenedor es NCryptOpenKey).
  3. Elimine un contenedor. (El equivalente de CNG de CryptAcquireContext con dwFlags establecido en CRYPT_DELETEKEYSET es NCryptDeleteKey).

La heurística que se usa para asociar un identificador criptográfico con una tarjeta inteligente y un lector determinados se basa en la operación de contenedor solicitada y en el nivel de especificación de contenedor utilizado.

En la tabla siguiente se muestran las restricciones de la operación de creación de contenedores.

Especificación Restricción
Sin contexto silencioso La creación de contenedores de claves siempre debe poder mostrar la interfaz de usuario, como el símbolo del pin.
Sin sobrescribir contenedores existentes Si el contenedor especificado ya existe en la tarjeta inteligente elegida, elija otra tarjeta inteligente o cancele la operación.

Marcas de contexto

En la tabla siguiente se muestran las marcas de contexto usadas como restricciones para la operación de creación de contenedores.

Bandera Descripción
CRYPT_SILENT No se puede mostrar ninguna interfaz de usuario durante esta operación.
CRYPT_MACHINE_KEYSET No se deben usar datos almacenados en caché durante esta operación.
CRYPT_VERIFYCONTEXT Solo se puede acceder a los datos públicos en la tarjeta inteligente.

Además de las operaciones de contenedor y las especificaciones de contenedor, debe tener en cuenta otras opciones de usuario, como las marcas de CryptAcquireContext, durante la selección de tarjeta inteligente.

Importante

No se puede usar la marca de CRYPT_SILENT para crear un nuevo contenedor.

Creación de un nuevo contenedor en contexto silencioso

Las aplicaciones pueden llamar al CSP base con CRYPT_DEFAULT_CONTAINER_OPTIONAL, establecer el PIN en contexto silencioso y, a continuación, crear un nuevo contenedor en contexto silencioso. Esta operación tiene lugar de la siguiente manera:

  1. Llame a CryptAcquireContext pasando el nombre del lector de tarjeta inteligente en como un nivel de especificación de contenedor de tipo II y especificando la CRYPT_DEFAULT_CONTAINER_OPTIONAL marca
  2. Llame a CryptSetProvParam especificando PP_KEYEXCHANGE_PIN o PP_SIGNATURE_PIN y un PIN ASCII terminado en null.
  3. Liberación del contexto adquirido en el paso 1
  4. Llame a CryptAcquireContext con CRYPT_NEWKEYSETy especifique el nivel de especificación del contenedor de tipo I.
  5. Llamar a CryptGenKey para crear la clave

Comportamiento de selección de tarjeta inteligente

En algunos de los siguientes escenarios, se puede pedir al usuario que inserte una tarjeta inteligente. Si el contexto de usuario es silencioso, se produce un error en esta operación y no se muestra ninguna interfaz de usuario. De lo contrario, en respuesta a la interfaz de usuario, el usuario puede insertar una tarjeta inteligente o seleccionar Cancelar. Si el usuario cancela la operación, se produce un error en la operación. El gráfico de flujo muestra los pasos de selección realizados por el sistema operativo Windows.

Proceso de selección de tarjeta inteligente.

En general, el comportamiento de selección de tarjeta inteligente se controla mediante la API SCardUIDlgSelectCard. El CSP base interactúa con esta API llamándola directamente. El CSP base también envía funciones de devolución de llamada que tienen el propósito de filtrar y hacer coincidir tarjetas inteligentes candidatas. Los autores de llamadas de CryptAcquireContext proporcionan información de coincidencia de tarjeta inteligente. Internamente, el CSP base usa una combinación de números de serie de tarjeta inteligente, nombres de lector y nombres de contenedor para buscar tarjetas inteligentes específicas.

Cada llamada a puede dar lugar a SCardUI * la lectura de información adicional de una tarjeta inteligente candidata. Las devoluciones de llamada de selección de tarjeta inteligente csp base almacenan en caché esta información.

Hacer coincidir un lector de tarjetas inteligentes

Para los niveles de especificación de contenedor de tipo I y tipo II, el proceso de selección de tarjeta inteligente es menos complejo porque solo la tarjeta inteligente del lector con nombre se puede considerar una coincidencia. El proceso para hacer coincidir una tarjeta inteligente con un lector de tarjetas inteligentes es:

  1. Busque el lector de tarjetas inteligentes solicitado. Si no se encuentra, se produce un error en el proceso (esto requiere una búsqueda en caché por nombre de lector)
  2. Si no hay ninguna tarjeta inteligente en el lector, se le pedirá al usuario que inserte una tarjeta inteligente. (esto solo está en modo no válido; si la llamada se realiza en modo silencioso, se produce un error)
  3. Solo para el nivel de especificación de contenedor II, se determina el nombre del contenedor predeterminado en la tarjeta inteligente elegida.
  4. Para abrir un contenedor existente o eliminar un contenedor existente, busque el contenedor especificado. Si no se encuentra el contenedor especificado en esta tarjeta inteligente, se le pedirá al usuario que inserte una tarjeta inteligente.
  5. Si el sistema intenta crear un nuevo contenedor, si el contenedor especificado ya existe en esta tarjeta inteligente, se produce un error en el proceso.

Hacer una coincidencia de tarjeta inteligente

Para los niveles de especificación de contenedor III y IV, se usa un método más amplio para hacer coincidir una tarjeta inteligente adecuada con un contexto de usuario, ya que varias tarjetas inteligentes almacenadas en caché podrían cumplir los criterios proporcionados.

Abrir un contenedor predeterminado existente (no se especificó ningún lector)

Nota

Esta operación requiere que use la tarjeta inteligente con el CSP base.

  1. Para cada tarjeta inteligente a la que ha accedido el CSP base y el identificador y la información del contenedor se almacenan en caché, el CSP base busca un contenedor predeterminado válido. Se intenta realizar una operación en el SCARDHANDLE almacenado en caché para comprobar su validez. Si el identificador de tarjeta inteligente no es válido, el CSP base sigue buscando una nueva tarjeta inteligente.
  2. Si no se encuentra una tarjeta inteligente coincidente en la caché de CSP base, el CSP base llama al subsistema de tarjeta inteligente. SCardUIDlgSelectCard() se usa con un filtro de devolución de llamada adecuado para buscar una tarjeta inteligente coincidente con un contenedor predeterminado válido

Abrir un contenedor con nombre GUID existente (no se especificó ningún lector)

Nota

Esta operación requiere que use la tarjeta inteligente con el CSP base.

  1. Para cada tarjeta inteligente que ya esté registrada con el CSP base, busque el contenedor solicitado. Intente una operación en el SCARDHANDLE almacenado en caché para comprobar su validez. Si el identificador de tarjeta inteligente no es válido, el número de serie de la tarjeta inteligente se pasa a la SCardUI * API para seguir buscando esta tarjeta inteligente específica (en lugar de solo una coincidencia general para el nombre del contenedor)
  2. Si no se encuentra una tarjeta inteligente coincidente en la caché de CSP base, se realiza una llamada al subsistema de tarjeta inteligente. SCardUIDlgSelectCard() se usa con un filtro de devolución de llamada adecuado para buscar una tarjeta inteligente coincidente con el contenedor solicitado. O bien, si un número de serie de una tarjeta inteligente resultó de la búsqueda en el paso 1, el filtro de devolución de llamada intenta coincidir con el número de serie, no con el nombre del contenedor.

Crear un nuevo contenedor (no se especificó ningún lector)

Nota

Esta operación requiere que use la tarjeta inteligente con el CSP base.

Si el PIN no se almacena en caché, no se permite ningún CRYPT_SILENT para la creación del contenedor porque se debe solicitar al usuario un PIN, como mínimo.

Para otras operaciones, el autor de la llamada puede adquirir un contexto de comprobación en el contenedor CRYPT_DEFAULT_CONTAINER_OPTIONAL predeterminado y, a continuación, realizar una llamada con CryptSetProvParam para almacenar en caché el PIN del usuario para las operaciones posteriores.

  1. Para cada tarjeta inteligente ya conocida por el CSP, actualice el SCARDHANDLE almacenado y realice las siguientes comprobaciones:
    1. Si se ha quitado la tarjeta inteligente, continúe con la búsqueda.
    2. Si la tarjeta inteligente está presente, pero ya tiene el contenedor con nombre, continúe con la búsqueda.
    3. Si la tarjeta inteligente está disponible, pero una llamada a CardQueryFreeSpace indica que la tarjeta inteligente no tiene suficiente almacenamiento para un contenedor de claves adicional, continúe con la búsqueda.
    4. De lo contrario, use la primera tarjeta inteligente disponible que cumpla los criterios anteriores para la creación del contenedor.
  2. Si no se encuentra una tarjeta inteligente coincidente en la caché de CSP, realice una llamada al subsistema de tarjetas inteligentes. La devolución de llamada que se usa para filtrar las tarjetas inteligentes enumeradas comprueba que una tarjeta inteligente candidata aún no tiene el contenedor con nombre y que CardQueryFreeSpace indica que la tarjeta inteligente tiene espacio suficiente para un contenedor adicional. Si no se encuentra ninguna tarjeta inteligente adecuada, se le pedirá al usuario que inserte una tarjeta inteligente.

Eliminación de un contenedor

  1. Si el nombre de contenedor especificado es NULL, se elimina el contenedor predeterminado. La eliminación del contenedor predeterminado hace que un nuevo contenedor predeterminado se seleccione arbitrariamente. Por este motivo, no se recomienda esta operación.
  2. Para cada tarjeta inteligente ya conocida por el CSP, actualice el SCARDHANDLE almacenado y realice las siguientes comprobaciones:
    1. Si la tarjeta inteligente no tiene el contenedor con nombre, continúe con la búsqueda.
    2. Si la tarjeta inteligente tiene el contenedor con nombre, pero el identificador de la tarjeta inteligente ya no es válido, almacene el número de serie de la tarjeta inteligente coincidente y pásela a SCardUI.
  3. Si no se encuentra una tarjeta inteligente coincidente en la caché de CSP, realice una llamada al subsistema de tarjetas inteligentes. La devolución de llamada que se usa para filtrar las tarjetas inteligentes enumeradas debe comprobar que una tarjeta inteligente candidata tiene el contenedor con nombre. Si se proporcionó un número de serie como resultado de la búsqueda de caché anterior, la devolución de llamada debe filtrar las tarjetas inteligentes enumeradas en el número de serie en lugar de en las coincidencias de contenedor. Si el contexto no es silencioso y no se encuentra ninguna tarjeta inteligente adecuada, muestre la interfaz de usuario que pida al usuario que inserte una tarjeta inteligente.

Arquitectura basada en CSP base y KSP en Windows

En el diagrama siguiente se muestra la arquitectura de criptografía que usa el sistema operativo Windows.

Arquitectura criptográfica.

Propiedades de CSP base y KSP de tarjeta inteligente en Windows

Nota

Las definiciones de API se encuentran en WinCrypt.h y WinSCard.h.

Propiedad Descripción
PP_USER_CERTSTORE : se usa para devolver un HCERTSTORE objeto que contiene todos los certificados de usuario de la tarjeta inteligente.
- Solo lectura (solo CryptGetProvParamlo usa )
- Llamador responsable de cerrar el almacén de certificados
- Certificado codificado mediante PKCS_7_ASN_ENCODING o X509_ASN_ENCODING
: CSP debe establecerse KEY_PROV_INFO en certificados
- Se debe suponer que el almacén de certificados es un almacén en memoria.
- Los certificados deben tener una propiedad válida CRYPT_KEY_PROV_INFO como propiedad
PP_ROOT_CERTSTORE - Lectura y escritura (usadas por CryptGetProvParam y CryptSetProvParam)
- Se usa para escribir una colección de certificados raíz en la tarjeta inteligente o devolver HCERTSTORE, que contiene certificados raíz de la tarjeta inteligente.
- Se usa principalmente para unirse a un dominio mediante una tarjeta inteligente
- Llamador responsable de cerrar el almacén de certificados
PP_SMARTCARD_READER - Solo lectura (solo CryptGetProvParamlo usa )
: devuelve el nombre del lector de tarjeta inteligente como una cadena ANSI que se usa para construir un nombre de contenedor completo (es decir, un lector de tarjetas inteligentes más un contenedor)
PP_SMARTCARD_GUID - Devolver guid de tarjeta inteligente (también conocido como número de serie), que debe ser único para cada tarjeta inteligente
: lo usa el servicio de propagación de certificados para realizar un seguimiento del origen de un certificado raíz.
PP_UI_PROMPT : se usa para establecer la cadena de búsqueda del SCardUIDlgSelectCard cuadro de diálogo de inserción de tarjetas
- Persistente para todo el proceso cuando se establece
- Solo escritura (solo se usa por CryptSetProvParam)

Implicaciones para los CSP en Windows

Los proveedores de servicios criptográficos (CSP), incluidos los CSP de tarjeta inteligente personalizados, siguen siendo compatibles, pero no se recomienda este enfoque. El uso del CSP base existente y KSP de tarjeta inteligente con el modelo de minidriver de tarjetas inteligentes para tarjetas inteligentes proporciona ventajas significativas en términos de rendimiento y PIN y almacenamiento en caché de datos. Se puede configurar un minidriver para que funcione en las capas CryptoAPI y CNG. Esto proporciona ventajas de la compatibilidad criptográfica mejorada, incluida la criptografía de curva elíptica y AES.

Si un CSP y un minidriver de tarjeta inteligente registran una tarjeta inteligente, la que se instaló más recientemente se usará para comunicarse con la tarjeta inteligente.

Escritura de un minidriver de tarjeta inteligente, CSP o KSP

Los CSP y KSP están diseñados para escribirse solo si la funcionalidad específica no está disponible en la arquitectura actual del minidriver de tarjeta inteligente. Por ejemplo, la arquitectura de minidriver de tarjeta inteligente admite módulos de seguridad de hardware, por lo que se podría escribir un minidriver para un módulo de seguridad de hardware, y es posible que no sea necesario un CSP o KSP a menos que sea necesario admitir algoritmos que no se implementan en el CSP base o KSP de tarjeta inteligente.

Para obtener más información sobre cómo escribir un minidriver de tarjeta inteligente, CSP o KSP, consulte Minidriveres de tarjeta inteligente.