Pergunta

Temos um aplicativo baseado em navegador, onde queremos tornar o usuário reautenticar quando ele o inserir. Então, quando eles acessam esse URL, queremos que eles sejam apresentados com o prompt PIN, para que tenham que se autenticar. Existe uma maneira razoável de fazer isso?

Informações adicionadas: isso é para um cartão CAC e as estações de trabalho têm ActivIdentity e Tumbleweed. Além disso, eu poderia adicionar um serviço às estações de trabalho, se necessário. Os navegadores são tudo IE7. O servidor da Web é IIS 6 e as páginas são escritas no ASP.NET (principalmente).

Foi útil?

Solução

Existem algumas peças de software diferentes aqui.

Primeiro é o próprio cartão. Para realizar uma assinatura digital, o CAC deve estar em um estado "verificado", o que significa que um alfinete foi inserido após a inserção do cartão. Além disso, cada chave no cartão possui um sinalizador que indica se o pino deve ser inserido toda vez que a chave é usada. Eu não verifiquei, mas acho que isso está definido para o par de teclas "email" em um CAC. Assim, você precisará descobrir quais teclas têm esse conjunto de sinalizadores "sempre verificar" e configurar o validador de caminho no serviço para aceitar apenas essas chaves. Você pode exigir um OID específico no uso de chaves estendidas ou excluir alguns dos certificados intermediários do Departamento de Defesa da construção do caminho (sinalizando -os como revogados, talvez).

O middleware da máquina conversando com o cartão também pode armazenar em cache o pino e fornece -o ao cartão sempre que o cartão indica que ele exige um pino antes de concluir uma operação. Eu acho que o ActivClient estava fazendo isso com seu recurso de cache de pinos na versão 6, mas na versão 7, essa opção parece ter desaparecido. Não encontrei nada assim no suporte ao PIV embutido do Windows. Esse "recurso" pode comprometer a segurança, então meu palpite é que ele foi removido deliberadamente e não haveria hacks de registro ou para restaurar o comportamento. Isso é algo que você não teria controle, a menos que você gerencie as máquinas dos usuários; Não há opção HTTP Cabeçalho ou TLS que você possa usar para aplicar a entrada do PIN. Mas, com sistemas mais novos, não deve ser um problema.

No lado do servidor, um aperto de mão completo deve ocorrer para fazer com que o cliente execute a autenticação. A autenticação do cliente não acontecerá se houver uma sessão TLS válida. Portanto, você precisará encontrar uma maneira de invalidar a sessão do TLS (não a sessão do aplicativo, que provavelmente está vinculada a um cookie HTTP) antes de solicitar autenticação ou direcionar a solicitação de autenticação para outra interface que não possui sessões ativadas.

Outras dicas

Existem duas maneiras de fazer a autenticação do cliente SmartCard na Web: TLS/SSL padrão ou plugins personalizados para o navegador. Presumo que você esteja falando sobre navegadores da Web padrão (ou seja/FF/Safari) e autenticação SSL.

Há duas coisas que importam para solicitações de pinos:

  • SSL Session e SSL Session Cache do navegador
  • Estado de autenticação no cartão da chave privada relacionada
  • A maneira como o middleware é implementado.

No final, da perspectiva de segurança, é o cartão que sabe quando "pedir" um alfinete - alguns cartões e chaves exigem um pino para cada operação com a chave, alguns cartões estão bem para obter um alfinete uma vez e deixar as chaves em estado autenticado até ser removido do leitor ou redefinido por um aplicativo.

Se a sessão no cache do navegador não puder ser reutilizada ou quando a conexão estiver sendo estabelecida, o middleware do cartão inteligente (PKCS#11 no Linux, o módulo Cryptoapi/Basecsp no Windows ou tokend no OSX) precisa falar com as chaves no cartão. Se o estado de autenticação no cartão exigir que um pino seja inserido, um retorno de chamada geralmente será acionado pelo navegador. Ou, se o middleware souber que precisará do PIN, ele pedirá antes de falar com o cartão.

Não existe uma relação 1: 1 entre inserir um PIN e realmente autenticar os direitos de acesso à Chave Privada e re-autenticar a sessão SSL.

Com o SSL padrão, você depende da maneira como o SSL é implementado nos navegadores e não pode ter uma "re-autenticação 100% confiável ao inserir o pino" no lado do cliente.

Se você estiver usando o Linux, com o OpenSC (que, o Afaik pode usar cartões CAC), você pode definir "transaction_reset" no openSC.conf como true, o que resulta no reinicialização do cartão após todas as transações (todas as negociações da sessão SSL) e dessa maneira Você pode ter certeza de que, sempre que abrir uma nova sessão SSL, o usuário precisa inserir o pino novamente. Porém, essa é uma configuração do lado do cliente, não é um recurso iniciado pelo servidor.

Você pode usar a função JavaScript para fazer o navegador esquecer o cache SSL existente em poucos navegadores:

function logout() {
    // clear browser authentication cache
    // IE specific
    try
    {
        document.execCommand("ClearAuthenticationCache", "false");
    }
    catch(e)
    {
        // do nothing
    }

    // clear for firefox or any browser that supports window.crypto API
    if (window.crypto && typeof window.crypto.logout === "function") {
        window.crypto.logout();
    }
}

Você pode usar o método JavaScript Settimeout para chamar a função de logout acima e possivelmente redirecioná -los para logout.aspx para forçar o cliente a inserir o novo pino.

Mas ele usa JavaScript e o código depende do navegador e não funciona para todos os navegadores.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top