Compartilhar via

Arquitetura do cartão inteligente

Este tópico para o profissional de TI descreve a arquitetura do sistema que dá suporte a cartões inteligentes no sistema operacional Windows, incluindo a arquitetura do provedor de credenciais e a arquitetura do subsistema smart cartão.

A autenticação é um processo para verificar a identidade de um objeto ou pessoa. Quando você autentica um objeto, como um cartão inteligente, o objetivo é verificar se o objeto é genuíno. Quando você autentica uma pessoa, o objetivo é verificar se você não está lidando com um impostor.

Em um contexto de rede, a autenticação é o ato de provar identidade para um aplicativo de rede ou recurso. Normalmente, a identidade é comprovada por uma operação criptográfica que usa uma chave que somente o usuário sabe (como com criptografia de chave pública) ou uma chave compartilhada. O lado do servidor da troca de autenticação compara os dados assinados com uma chave criptográfica conhecida para validar a tentativa de autenticação. Armazenar as chaves criptográficas em um local central seguro torna o processo de autenticação escalonável e mantêvel.

Para cartões inteligentes, o Windows dá suporte a uma arquitetura de provedor que atende aos requisitos de autenticação segura e é extensível para que você possa incluir provedores de credencial personalizados. Este tópico inclui informações sobre:

Arquitetura do provedor de credenciais

A tabela a seguir lista os componentes incluídos na arquitetura de entrada interativa:

Componente Descrição
Winlogon Fornece uma infraestrutura de entrada interativa.
Interface do usuário de logon Fornece renderização interativa da interface do usuário.
Provedores de credenciais (senha e cartão inteligentes) Descreve informações de credencial e credenciais de serialização.
Autoridade de Segurança Local (LSA) Processa credenciais de entrada.
Pacotes de autenticação Inclui o NTLM e o protocolo Kerberos. Comunica-se com pacotes de autenticação de servidor para autenticar usuários.

A entrada interativa no Windows começa quando o usuário pressiona CTRL+ALT+DEL. A combinação de chaves CTRL+ALT+DEL é chamada de SAS (sequência de atenção segura). Para impedir que outros programas e processos o usem, o Winlogon registra essa sequência durante o processo de inicialização.

Depois de receber o SAS, a interface do usuário gera o bloco de entrada das informações recebidas dos provedores de credencial registrados. O gráfico a seguir mostra a arquitetura para provedores de credencial no sistema operacional Windows.

Arquitetura do provedor de credenciais.

Normalmente, um usuário que entra em um computador usando uma conta local ou uma conta de domínio deve inserir um nome de usuário e uma senha. Essas credenciais são usadas para verificar a identidade do usuário. Para entrada cartão inteligente, as credenciais de um usuário estão contidas no chip de segurança do cartão inteligente. Um leitor de cartão inteligente permite que o computador interaja com o chip de segurança no cartão inteligente. Quando os usuários entram com um cartão inteligente, eles inserem um PIN (número de identificação pessoal) em vez de um nome de usuário e senha.

Provedores de credenciais são objetos COM em processo que são executados no sistema local e são usados para coletar credenciais. A interface do usuário do Logon fornece renderização interativa da interface do usuário, o Winlogon fornece infraestrutura de entrada interativa e os provedores de credencial trabalham com esses dois componentes para ajudar a coletar e processar credenciais.

O Winlogon instrui a interface do usuário do Logon a exibir blocos do provedor de credencial depois de receber um evento SAS. A interface do usuário do Logon consulta cada provedor de credencial pelo número de credenciais que deseja enumerar. Os provedores de credencial têm a opção de especificar um desses blocos como o padrão. Depois que todos os provedores enumeraram seus blocos, a interface do usuário do Logon os exibe para o usuário. O usuário interage com um bloco para fornecer as credenciais adequadas. A interface do usuário do Logon envia essas credenciais para autenticação.

Combinados com o hardware de suporte, os provedores de credencial podem estender o sistema operacional Windows para permitir que os usuários entrem usando biometria (por exemplo, impressão digital, retinal ou reconhecimento de voz), senha, PIN, certificado de cartão inteligente ou qualquer pacote de autenticação personalizado. Empresas e profissionais de TI podem desenvolver e implantar mecanismos de autenticação personalizados para todos os usuários de domínio e podem exigir explicitamente que os usuários usem esse mecanismo de entrada personalizado.

Observação

Provedores de credencial não são mecanismos de imposição. Eles são usados para coletar e serializar credenciais. O LSA e os pacotes de autenticação impõem a segurança.

Os provedores de credencial podem ser projetados para dar suporte ao SSO (logon único). Nesse processo, eles autenticam os usuários em um ponto de acesso de rede seguro (usando RADIUS e outras tecnologias) para entrar no computador. Os provedores de credenciais também são projetados para dar suporte à coleta de credenciais específica do aplicativo e podem ser usados para autenticação em recursos de rede, junção de computadores a um domínio ou para fornecer consentimento do administrador para o Controle de Conta de Usuário (UAC).

Vários provedores de credencial podem coexistir em um computador.

Os provedores de credenciais devem ser registrados em um computador que executa o Windows e são responsáveis por:

  • Descrevendo as informações de credencial necessárias para autenticação
  • Manipulando a comunicação e a lógica com autoridades de autenticação externas
  • Empacotar credenciais para entrada interativa e de rede

Observação

A API do Provedor de Credenciais não renderiza a interface do usuário. Ele descreve o que precisa ser renderizado.
Somente o provedor de credencial de senha está disponível no modo de segurança.
O provedor de credencial de cartão inteligente está disponível no modo de segurança durante a rede.

Arquitetura do subsistema smart cartão

Os fornecedores fornecem cartões inteligentes e leitores de cartão inteligentes e, em muitos casos, os fornecedores são diferentes para o cartão inteligente e o leitor de cartão inteligente. Os drivers para leitores de cartão inteligentes são gravados no padrão Computador Pessoal/Smart Card (PC/SC). Cada cartão inteligente deve ter um CSP (Provedor de Serviços Criptográficos) que usa as interfaces CryptoAPI para habilitar operações criptográficas e as APIs WinSCard para habilitar as comunicações com hardware de cartão inteligente.

CSP base e arquitetura de minidriver de cartão inteligente

O gráfico a seguir mostra a relação entre o CryptoAPI, os CSPs, o Provedor de Serviços Criptográficos base de cartão inteligente (CSP) e os minidrivers de cartão inteligentes.

CSP base e arquitetura de minidriver de cartão inteligente.

Cache com CSP base e smart cartão KSP

A arquitetura de cartão inteligente usa mecanismos de cache para ajudar a simplificar as operações e melhorar o acesso de um usuário a um PIN.

  • Cache de dados: o cache de dados fornece um único processo para minimizar operações inteligentes de E/S cartão
  • Cache de PIN: o cache PIN ajuda o usuário a ter que reentrada em um PIN sempre que o cartão inteligente não for autenticado

Cache de dados

Cada CSP implementa o cache de dados de cartão inteligente atual separadamente. O CSP base implementa um mecanismo de cache robusto que permite um único processo para minimizar operações inteligentes de E/S cartão.

O cache global existente funciona da seguinte maneira:

  1. O aplicativo solicita uma operação criptográfica. Por exemplo, um certificado de usuário deve ser lido do cartão inteligente
  2. O CSP verifica seu cache para o item
  3. Se o item não for encontrado no cache ou se o item estiver armazenado em cache, mas não estiver atualizado, o item será lido do cartão inteligente
  4. Depois que qualquer item tiver sido lido do cartão inteligente, ele será adicionado ao cache. Qualquer cópia desatualizada existente desse item é substituída

Três tipos de objetos ou dados são armazenados em cache pelo CSP: pinos (para obter mais informações, consulte cache DE PIN), certificados e arquivos. Se algum dos dados armazenados em cache for alterado, o objeto correspondente será lido do cartão inteligente em operações sucessivas. Por exemplo, se um arquivo for gravado no cartão inteligente, o cache CSP ficará desatualizado para os arquivos e outros processos lerão o cartão inteligente pelo menos uma vez para atualizar o cache CSP.

O cache de dados global está hospedado no serviço Smart Cards for Windows. O Windows inclui duas chamadas de API de cartão inteligentes públicas, SCardWriteCache e SCardReadCache. Essas chamadas de API disponibilizam a funcionalidade de cache de dados global para aplicativos. Cada cartão inteligente que esteja em conformidade com a especificação do minidriver cartão inteligente tem um identificador de cartão de 16 bytes. Esse valor é usado para identificar exclusivamente dados armazenados em cache que pertencem a uma determinada cartão inteligente. O tipo guid padrão do Windows é usado. Essas APIs permitem que um aplicativo adicione dados e leia dados do cache global.

Cache de PIN

O cache PIN protege o usuário de inserir um PIN sempre que o cartão inteligente não for autenticado. Depois que um cartão inteligente for autenticado, ele não será diferenciado entre aplicativos do lado do host— qualquer aplicativo pode acessar dados privados no cartão inteligente.

Para atenuar isso, o cartão inteligente entra em um estado exclusivo quando um aplicativo se autentica na cartão inteligente. No entanto, isso significa que outros aplicativos não podem se comunicar com o cartão inteligente e serão bloqueados. Portanto, essas conexões exclusivas são minimizadas. O problema é que um protocolo (como o protocolo Kerberos) requer várias operações de assinatura. Portanto, o protocolo requer acesso exclusivo à cartão inteligente por um longo período ou requer várias operações de autenticação. É aqui que o cache PIN é usado para minimizar o uso exclusivo do cartão inteligente sem forçar o usuário a inserir um PIN várias vezes.

O exemplo a seguir ilustra como isso funciona. Nesse cenário, há dois aplicativos: Outlook e Internet Explorer. Os aplicativos usam cartões inteligentes para diferentes finalidades.

  1. O usuário inicia o Outlook e tenta enviar um email assinado. A chave privada está no cartão inteligente
  2. O Outlook solicita ao usuário o PIN de cartão inteligente. O usuário insere o PIN correto
  3. Os dados de email são enviados para o cartão inteligente para a operação de assinatura. O cliente do Outlook formata a resposta e envia o email
  4. O usuário abre a Internet Explorer e tenta acessar um site protegido que requer autenticação TLS (Transport Layer Security) para o cliente
  5. O Explorer da Internet solicita ao usuário o PIN de cartão inteligente. O usuário insere o PIN correto
  6. A operação de chave privada relacionada ao TLS ocorre no cartão inteligente e o usuário é autenticado e conectado
  7. O usuário retorna ao Outlook para enviar outro email assinado. Desta vez, o usuário não é solicitado para um PIN porque o PIN é armazenado em cache da operação anterior. Da mesma forma, se o usuário usar a Internet Explorer novamente para outra operação, a Internet Explorer não solicitará ao usuário um PIN

O CSP base mantém internamente um cache por processo do PIN. O PIN é criptografado e armazenado na memória. As funções usadas para proteger o PIN são RtlEncryptMemory, RtlDecryptMemory e RtlSecureZeroMemory, que esvaziarão buffers que continham o PIN.

Seleção de cartão inteligentes

As seções a seguir neste artigo descrevem como o Windows usa a arquitetura de cartão inteligente para selecionar o software, o provedor e as credenciais de leitor inteligente corretos de cartão para uma entrada cartão inteligente bem-sucedida:

Níveis de especificação de contêiner

Em resposta a uma chamada CryptAcquireContext no CryptoAPI, o CSP base tenta corresponder ao contêiner que o chamador especifica para um cartão inteligente e leitor específico. O chamador pode fornecer um nome de contêiner com diferentes níveis de especificidade, conforme mostrado na tabela a seguir, e classificado da mais específica para solicitações menos específicas.

Da mesma forma, em resposta a uma chamada NCryptOpenKey no CNG, o cartão inteligente KSP tenta corresponder ao contêiner da mesma maneira, e ele usa o mesmo formato de contêiner, conforme mostrado na tabela a seguir.

Observação

Antes de abrir uma chave usando o smart cartão KSP, uma chamada para NCryptOpenStorageProvider (MS_SMART_CARD_KEY_STORAGE_PROVIDER) deve ser feita.

Tipo Nome Formato
Eu Nome do leitor e nome do contêiner \.<Reader Name><Container Name>
II Nome do leitor e nome do contêiner (NULL) \.<Reader Name>
III Somente nome do contêiner <Container Name>
IV Somente contêiner padrão (NULL) NULL

O CSP base e o smart cartão cartão inteligente de cache KSP lidam com informações sobre o processo de chamada e sobre os cartões inteligentes que o processo acessou. Ao procurar um contêiner de cartão inteligente, o CSP base ou o cartão inteligente KSP verifica primeiro seu cache para o processo. Se o identificador armazenado em cache for inválido ou nenhuma correspondência for encontrada, a API SCardUIDlg será chamada para obter o identificador cartão.

Operações de contêiner

As três operações de contêiner a seguir podem ser solicitadas usando CryptAcquireContext:

  1. Crie um novo contêiner. (O equivalente CNG de CryptAcquireContext com dwFlags definido como CRYPT_NEWKEYSET é NCryptCreatePersistedKey.)
  2. Abra um contêiner existente. (O equivalente CNG de CryptAcquireContext para abrir o contêiner é NCryptOpenKey.)
  3. Excluir um contêiner. (O equivalente CNG de CryptAcquireContext com dwFlags definido como CRYPT_DELETEKEYSET é NCryptDeleteKey.)

A heurística usada para associar um identificador criptográfico a um determinado cartão inteligente e leitor baseia-se na operação de contêiner solicitada e no nível de especificação de contêiner usado.

A tabela a seguir mostra as restrições para a operação de criação de contêiner.

Especificação Restrição
Sem contexto silencioso A criação de contêiner de chave deve sempre ser capaz de mostrar a interface do usuário, como o prompt PIN.
Sem substituição de contêineres existentes Se o contêiner especificado já existir no cartão inteligente escolhido, escolha outro cartão inteligente ou cancele a operação.

Sinalizadores de contexto

A tabela a seguir mostra os sinalizadores de contexto usados como restrições para a operação de criação de contêiner.

Sinalizador Descrição
CRYPT_SILENT Nenhuma interface do usuário pode ser exibida durante essa operação.
CRYPT_MACHINE_KEYSET Nenhum dado armazenado em cache deve ser usado durante essa operação.
CRYPT_VERIFYCONTEXT Somente dados públicos podem ser acessados no cartão inteligente.

Além de operações de contêiner e especificações de contêiner, você deve considerar outras opções de usuário, como os sinalizadores CryptAcquireContext, durante a seleção de cartão inteligentes.

Importante

O sinalizador CRYPT_SILENT não pode ser usado para criar um novo contêiner.

Criar um novo contêiner em contexto silencioso

Os aplicativos podem chamar o CSP base com CRYPT_DEFAULT_CONTAINER_OPTIONAL, definir o PIN em contexto silencioso e criar um novo contêiner em contexto silencioso. Essa operação ocorre da seguinte maneira:

  1. Chame CryptAcquireContext passando o nome do leitor de cartão inteligente como um nível de especificação de contêiner tipo II e especificando o CRYPT_DEFAULT_CONTAINER_OPTIONAL sinalizador
  2. Chame CryptSetProvParam especificando PP_KEYEXCHANGE_PIN ou PP_SIGNATURE_PIN e um PIN ASCII encerrado em nulo.
  3. Liberar o contexto adquirido na Etapa 1
  4. Chame CryptAcquireContext com CRYPT_NEWKEYSET, e especifique o nível de especificação de contêiner do tipo I
  5. Chame CryptGenKey para criar a chave

Comportamento de seleção de cartão inteligente

Em alguns dos cenários a seguir, o usuário pode ser solicitado a inserir uma cartão inteligente. Se o contexto do usuário estiver silencioso, essa operação falhará e nenhuma interface do usuário será exibida. Caso contrário, em resposta à interface do usuário, o usuário pode inserir uma cartão inteligente ou selecionar Cancelar. Se o usuário cancelar a operação, a operação falhará. O gráfico de fluxo mostra as etapas de seleção executadas pelo sistema operacional Windows.

Processo de seleção de cartão inteligente.

Em geral, o comportamento de seleção de cartão inteligente é tratado pela API SCardUIDlgSelectCard. O CSP base interage com essa API chamando-a diretamente. O CSP base também envia funções de retorno de chamada que têm a finalidade de filtrar e corresponder cartões inteligentes candidatos. Os chamadores do CryptAcquireContext fornecem informações inteligentes cartão correspondentes. Internamente, o CSP base usa uma combinação de números de série cartão inteligentes, nomes de leitor e nomes de contêiner para encontrar cartões inteligentes específicos.

Cada chamada para SCardUI * pode resultar em informações adicionais lidas de uma cartão inteligente do candidato. Os retornos de chamada de seleção de cartão inteligentes CSP base armazenam essas informações em cache.

Fazer uma correspondência de leitor de cartão inteligente

Para níveis de especificação de contêiner tipo I e tipo II, o processo de seleção de cartão inteligente é menos complexo porque apenas o cartão inteligente no leitor nomeado pode ser considerado uma correspondência. O processo para combinar um cartão inteligente com um leitor de cartão inteligente é:

  1. Encontre o leitor de cartão inteligente solicitado. Se ele não puder ser encontrado, o processo falhará (isso requer uma pesquisa de cache pelo nome do leitor)
  2. Se nenhuma cartão inteligente estiver no leitor, o usuário será solicitado a inserir uma cartão inteligente. (isso só está no modo não silent; se a chamada for feita no modo silencioso, ela falhará)
  3. Somente para o nível de especificação de contêiner II, o nome do contêiner padrão no cartão inteligente escolhido é determinado
  4. Para abrir um contêiner existente ou excluir um contêiner existente, localize o contêiner especificado. Se o contêiner especificado não puder ser encontrado neste cartão inteligente, o usuário será solicitado a inserir um cartão inteligente
  5. Se o sistema tentar criar um novo contêiner, se o contêiner especificado já existir neste cartão inteligente, o processo falhará

Fazer uma correspondência de cartão inteligente

Para os níveis de especificação de contêiner III e IV, um método mais amplo é usado para corresponder a um cartão inteligente apropriado com um contexto de usuário, pois vários cartões inteligentes armazenados em cache podem atender aos critérios fornecidos.

Abra um contêiner padrão existente (sem leitor especificado)

Observação

Essa operação exige que você use o cartão inteligente com o CSP base.

  1. Para cada cartão inteligente que foi acessada pelo CSP base e as informações de identificador e contêiner são armazenadas em cache, o CSP base procura um contêiner padrão válido. Uma operação é tentada no SCARDHANDLE armazenado em cache para verificar sua validade. Se o identificador de cartão inteligente não for válido, o CSP base continuará procurando por uma nova cartão inteligente
  2. Se uma cartão inteligente correspondente não for encontrada no cache CSP base, o CSP base chamará para o subsistema de cartão inteligente. SCardUIDlgSelectCard() é usado com um filtro de retorno de chamada apropriado para encontrar uma cartão inteligente correspondente com um contêiner padrão válido

Abra um contêiner com nome GUID existente (sem leitor especificado)

Observação

Essa operação exige que você use o cartão inteligente com o CSP base.

  1. Para cada cartão inteligente que já está registrado no CSP base, pesquise o contêiner solicitado. Tente uma operação no SCARDHANDLE armazenado em cache para verificar sua validade. Se o identificador de cartão inteligente não for válido, o número de série do cartão inteligente será passado para a SCardUI * API para continuar procurando por esse cartão inteligente específico (em vez de apenas uma correspondência geral para o nome do contêiner)
  2. Se uma cartão inteligente correspondente não for encontrada no cache CSP base, uma chamada será feita para o subsistema cartão inteligente. SCardUIDlgSelectCard()é usado com um filtro de retorno de chamada apropriado para encontrar uma cartão inteligente correspondente com o contêiner solicitado. Ou, se um número de série cartão inteligente resultante da pesquisa na Etapa 1, o filtro de retorno de chamada tentará corresponder ao número de série, não ao nome do contêiner

Criar um novo contêiner (sem leitor especificado)

Observação

Essa operação exige que você use o cartão inteligente com o CSP base.

Se o PIN não estiver armazenado em cache, nenhum CRYPT_SILENT será permitido para a criação do contêiner porque o usuário deve ser solicitado para um PIN, no mínimo.

Para outras operações, o chamador pode ser capaz de adquirir um contexto de verificação em relação ao contêiner CRYPT_DEFAULT_CONTAINER_OPTIONAL padrão e, em seguida, fazer uma chamada com CryptSetProvParam para armazenar em cache o PIN do usuário para operações subsequentes.

  1. Para cada cartão inteligente já conhecida pelo CSP, atualize o SCARDHANDLE armazenado e faça as seguintes verificações:
    1. Se o cartão inteligente tiver sido removido, continue a pesquisa
    2. Se o cartão inteligente estiver presente, mas já tiver o contêiner nomeado, continue a pesquisa
    3. Se o cartão inteligente estiver disponível, mas uma chamada para CardQueryFreeSpace indicar que o cartão inteligente não tem armazenamento suficiente para um contêiner de chave adicional, continue a pesquisa
    4. Caso contrário, use o primeiro cartão inteligente disponível que atenda aos critérios acima para a criação do contêiner
  2. Se uma cartão inteligente correspondente não for encontrada no cache CSP, faça uma chamada para o subsistema cartão inteligente. O retorno de chamada usado para filtrar cartões inteligentes enumerados verifica se uma cartão inteligente do candidato ainda não tem o contêiner nomeado e que o CardQueryFreeSpace indica que o cartão inteligente tem espaço suficiente para um contêiner adicional. Se nenhuma cartão inteligente adequada for encontrada, o usuário será solicitado a inserir uma cartão inteligente

Excluir um contêiner

  1. Se o nome do contêiner especificado for NULL, o contêiner padrão será excluído. A exclusão do contêiner padrão faz com que um novo contêiner padrão seja selecionado arbitrariamente. Por esse motivo, essa operação não é recomendada
  2. Para cada cartão inteligente já conhecida pelo CSP, atualize o SCARDHANDLE armazenado e faça as seguintes verificações:
    1. Se o cartão inteligente não tiver o contêiner nomeado, continue a pesquisa
    2. Se o cartão inteligente tiver o contêiner nomeado, mas o identificador de cartão inteligente não for mais válido, armazene o número de série do cartão inteligente correspondente e passe-o para o SCardUI
  3. Se uma cartão inteligente correspondente não for encontrada no cache CSP, faça uma chamada para o subsistema cartão inteligente. O retorno de chamada usado para filtrar cartões inteligentes enumerados deve verificar se um candidato inteligente cartão tem o contêiner nomeado. Se um número de série foi fornecido como resultado da pesquisa de cache anterior, o retorno de chamada deverá filtrar cartões inteligentes enumerados no número de série em vez de em correspondências de contêiner. Se o contexto não for silencioso e nenhum cartão inteligente adequado for encontrado, exiba a interface do usuário que solicita que o usuário insira uma cartão inteligente

Arquitetura baseada em CSP e KSP base no Windows

O diagrama a seguir mostra a arquitetura de criptografia usada pelo sistema operacional Windows.

Arquitetura de criptografia.

Propriedades CSP base e smart cartão KSP no Windows

Observação

As definições de API estão localizadas em WinCrypt.h e WinSCard.h.

Propriedade Descrição
PP_USER_CERTSTORE - Usado para retornar um HCERTSTORE que contém todos os certificados de usuário no cartão inteligente
- Somente leitura (usado apenas por CryptGetProvParam)
– Chamador responsável por fechar o repositório de certificados
– Certificado codificado usando PKCS_7_ASN_ENCODING ou X509_ASN_ENCODING
- CSP deve definir KEY_PROV_INFO em certificados
- O repositório de certificados deve ser considerado um repositório na memória
- Os certificados devem ter um válido CRYPT_KEY_PROV_INFO como uma propriedade
PP_ROOT_CERTSTORE - Leitura e gravação (usada por CryptGetProvParam e CryptSetProvParam)
- Usado para gravar uma coleção de certificados raiz no cartão inteligente ou retornar HCERTSTORE, que contém certificados raiz do cartão inteligente
- Usado principalmente para ingressar em um domínio usando uma cartão inteligente
– Chamador responsável por fechar o repositório de certificados
PP_SMARTCARD_READER - Somente leitura (usado apenas por CryptGetProvParam)
- Retorna o nome do leitor de cartão inteligente como uma cadeia de caracteres ANSI usada para construir um nome de contêiner totalmente qualificado (ou seja, um leitor de cartão inteligente mais um contêiner)
PP_SMARTCARD_GUID - Retornar o GUID de cartão inteligente (também conhecido como número de série), que deve ser exclusivo para cada cartão inteligente
- Usado pelo serviço de propagação de certificado para rastrear a origem de um certificado raiz
PP_UI_PROMPT - Usado para definir a cadeia de caracteres de pesquisa para a SCardUIDlgSelectCard caixa de diálogo cartão inserção
- Persistente para todo o processo quando ele é definido
- Somente gravação (usado apenas por CryptSetProvParam)

Implicações para CSPs no Windows

Os CSPs (Provedores de Serviços Criptográficos), incluindo CSPs cartão inteligentes personalizados, continuam com suporte, mas essa abordagem não é recomendada. Usar o CSP base existente e o smart cartão KSP com o modelo de minidriver cartão inteligente para cartões inteligentes fornece benefícios significativos em termos de desempenho e cache de PIN e dados. Um minidriver pode ser configurado para funcionar em camadas CryptoAPI e CNG. Isso fornece benefícios do suporte criptográfico aprimorado, incluindo criptografia de curva elíptica e AES.

Se um cartão inteligente for registrado por um CSP e um minidriver cartão inteligente, o que foi instalado mais recentemente será usado para se comunicar com a cartão inteligente.

Gravar um minidriver de cartão inteligente, CSP ou KSP

CSPs e KSPs devem ser gravados somente se a funcionalidade específica não estiver disponível na arquitetura do minidriver smart cartão atual. Por exemplo, a arquitetura de minidriver smart cartão dá suporte a módulos de segurança de hardware, portanto, um minidriver pode ser gravado para um módulo de segurança de hardware, e um CSP ou KSP pode não ser necessário, a menos que seja necessário dar suporte a algoritmos que não são implementados no CSP base ou no cartão inteligente KSP.

Para obter mais informações sobre como escrever um minidriver de cartão inteligente, CSP ou KSP, consulte Minidrivers de Cartão Inteligente.