Capítulo 13. Protocolo de Senha Remota de Segurança

O protocolo da Senha Remota de Segurança (Secure Remote Password - SRP) é uma implementação de introdução de troca de chave pública descrita na Solicitação do Grupo de Trabalho Padrão para Comentários - Internet Standards Working Group Request For Comments 2945 (RFC2945). O resumo do RFC2945 declara:
Este documento descreve um mecanismo de autenticação de rede potente criptográfica conhecido como protocolo da Senha Remota de Segurança - Secure Remote Password (SRP). Este mecanismo é útil para negociação de conexões de segurança usando uma senha de usuário fornecida, enquanto eliminando os problemas de segurança tradicionalmente associados com as senhas reutilizáveis. Além disso, o sistema executa uma troca da chave de segurança no processo de autenticação, permitindo camadas de segurança (privacidade e/ou proteção de integridade) a serem ativadas durante a sessão. Os servidores de chave confiável e infra-estruturas de certificado não são solicitados e os clientes não precisam armazenar ou gerenciar quaisquer chaves de longo termo. O SPR oferece ambas vantagens de implantação e segurança sobre técnicas de respostas de desafio existentes, fazendo disto uma substituição ideal onde a autenticação de senha é necessária.
A especificação RFC2945 completa pode ser obtida a partir do http://www.rfc-editor.org/rfc.html. Informações adicionais sobre o algoritmo SRP e sua história podem ser encontradas no http://www-cs-students.stanford.edu/~tjw/srp/.
Algoritmos como o Diffie-Hellman e RSA são conhecidos como algoritmos de troca de chave pública. O conceito de algoritmo de chave pública é que você possui duas chaves, uma pública que está disponível para todos e uma privada de apenas seu conhecimento. Quando alguém desejar lhe enviar alguma informação criptografada, a informação é criptografada usando a chave pública. Apenas você está apto a criptografar a informação usando a chave privada. Compare isto com uma senha compartilhada mais tradicional baseada nos esquemas de criptografia que requerem que o remetente e destinatário saibam da senha compartilhada. Os algoritmos de chave pública eliminam a necessidade de compartilhar senhas.
O JBossSX framework inclui uma implementação do SRP que consiste dos seguintes elementos:
  • Uma implementação do protocolo de introdução do SRP que é independente de qualquer protocolo de cliente/servidor particular.
  • Uma implementação RMI de protocolo de introdução como uma implementação SRP do servidor/cliente padrão.
  • Uma implementação JAAS LoginModule ao lado do cliente que usa uma implementação para uso de autenticação dos clientes num modo de segurança.
  • Um JMX MBean para gerenciamento da implantação do servidor RMI. O MBean permite que a implementação do servidor RMI seja conectável ao JMX framework e que externaliza a configuração do armazenamento de informação de verificação. Isto também estabiliza um cache de autenticação que é vinculado ao JNDI namespace do servidor do JBoss.
  • Uma implementação JAAS LoginModule ao lado do servidor que usa um cache de autenticação gerenciado pelo SRP JMX MBean.
A Figura 13.1, “Os componentes do JBossSX do framework do cliente-servidor SRP.” descreve os componentes chaves envolvidos na implementação do framework do cliente/servidor SRP.
Os componentes do JBossSX do framework do cliente-servidor SRP.

Figura 13.1. Os componentes do JBossSX do framework do cliente-servidor SRP.

O SRP aparece como uma implementação LoginModule do JAAS personalizado, ao lado do cliente, que comunica-se com o servidor de autenticação através de um org.jboss.security.srp.SRPServerInterface proxy. O cliente ativa a autenticação usando o SRP pela criação de uma entrada de configuração de logon que inclui o org.jboss.security.srp.jaas.SRPLoginModule. Este módulo suporta as seguintes opções de configuração:
principalClassName
Valor constante configurado para org.jboss.security.srp.jaas.SRPPrincipal.
srpServerJndiName
O nome do JNDI do objeto usado para comunicar-se com o servidor da autenticação do SRP. Caso ambas opções srpServerJndiName e srpServerRmiUrl forem especificadas, o srpServerJndiName leve prioridade sobre o srpServerRmiUrl.
srpServerRmiUrl
A sequência URL do protocolo RMI para a localização do SRPServerInterface proxy usado para comunicar-se com o servidor de autenticação SRP.
externalRandomA
Aviso que especifica se é que um componente aleatório da chave pública do cliente "A" deve vir do retorno de chamada do usuário. Isto pode ser usado para inserir um número qualquer criptográfico a partir de um token de hardware. O recurso é ativado, caso ele seja configurado para true.
hasAuxChallenge
O aviso que especifica se é que uma sequência será enviada ao servidor com um desafio adicional para validação do servidor. Caso a sessão do cliente suportar uma codificação de criptografia, a criptografia temporária será criada usando a chave privada da sessão e o objeto de desafio enviado com um javax.crypto.SealedObject. O recurso será desativado, caso configurado para true.
multipleSessions
O sinalizador especifica se é que o cliente gerado pode possuir sessões ativas múltiplas de logon. O recurso será ativado, caso ativado para true.
Outras opções passadas que não combinam com uma das opções anteriores nomeadas são tratadas como uma propriedade de uso para o ambiente passado ao construtor InitialContext. Isto é útil caso a interface do servidor SRP não esteja disponível no InitialContext padrão.
O SRPLoginModule e ClientLoginModule padrão podem ser configurados para permitir que credenciais sejam usadas para validação de acesso para os componentes do Java EE de segurança. Uma amostra de configuração de logon pode ser encontrada no Exemplo 13.1, “Entrada de Configuração de Segurança”.

Exemplo 13.1. Entrada de Configuração de Segurança

srp {
    org.jboss.security.srp.jaas.SRPLoginModule required
    srpServerJndiName="SRPServerInterface"
    ;
            
    org.jboss.security.ClientLoginModule required
    password-stacking="useFirstPass"
    ;
};
Existem dois MBeans que gerenciam os objetos que coletivamente formam o servidor SRP. O serviço primário é o org.jboss.security.srp.SRPService MBean. O outro MBean é o org.jboss.security.srp.SRPVerifierStoreService.
O org.jboss.security.srp.SRPService é responsável por expor uma versão RMI acessível do SRPServerInterface assim como uma atualização do cache da sessão de autenticação SRP.
Os atributos SRPService MBean configuráveis incluem o seguinte:
JndiName
Especifica o nome pelo qual o SRPServerInterface proxy deve estar disponível. Esta é a localização onde o SRPService realiza o bind no proxy do dinâmico serializável para o SRPServerInterface. O valor padrão é srp/SRPServerInterface.
VerifierSourceJndiName
Especifica o nome da implementação SRPVerifierSource que o SRPService deve usar. O padrão do nome JNDI de fonte é srp/DefaultVerifierSource.
AuthenticationCacheJndiName
Especifica o nome pelo qual a implementação da autenticação org.jboss.util.CachePolicy usada para informação de autenticação de cache o bind é aplicado. O padrão do cache JNDI de autenticação é srp/AuthenticationCache.
ServerPort
O portal RMI para o SRPRemoteServerInterface. O valor padrão é 10099.
ClientSocketFactory
Nome da classe de implementação java.rmi.server.RMIClientSocketFactory personalizada opcional usada durante a exportação do SRPServerInterface. O valor padrão é RMIClientSocketFactory.
ServerSocketFactory
Nome da classe de implementação java.rmi.server.RMIServerSocketFactory personalizada opcional usada durante a exportação do SRPServerInterface. O valor padrão é RMIServerSocketFactory.
AuthenticationCacheTimeout
O intervalo da política de cache (em segundos). O valor padrão é 1800 (30 minutos).
AuthenticationCacheResolution
Especifica a resolução da política de cache (em segundos). Isto controla o intervalo entre as checagens para intervalos. O valor padrão é 60 (1 minuto).
RequireAuxChallenge
Configurado caso um cliente fornecer um desafio auxiliar como parte da fase de verificação. Isto fornece controle sobre a configuração SRPLoginModule usada pelo cliente independente da opção useAuxChallenge estar ativada ou não.
OverwriteSessions
Especifica se é que uma autenticação do usuário com êxito para uma sessão existente deve ser substituída ou não na sessão atual. Isto controla o comportamento do cache da sessão SRP do servidor quando clientes não tiverem ativado a sessão múltipla por modo de usuário. Caso configurado para false, a segunda tentativa de autenticação do usuário será concluída com êxito, no entanto a sessão SRP resultante não substituirá o estado da sessão SRP anterior. O valor padrão é false.
VerifierStoreJndiName
Especifica a localização da implementação do armazenamento da informação de senha SRP que deve ser fornecida e disponibilizada através do JNDI.
O org.jboss.security.srp.SRPVerifierStoreService é um serviço MBean de amostra que aplica o bind na implementação da interface SRPVerifierStore, que usa um arquivo dos objetos serializados como um armazenamento de persistência. Mesmo que não isto não seja realístico para um ambiente de produção, ele permite testes para o protocolo SRP e fornece uma amostra de solicitações para um serviço SRPVerifierStore.\n
Os atributos SRPVerifierStoreService MBean incluem o seguinte:
JndiName
O nome JNDI pelo qual a implementação SRPVerifierStore deve estar disponível. O padrão é srp/DefaultVerifierSource, caso não seja especificado.
StoreFile
A localização do arquivo de armazenamento do objeto serializado do verificador de senha do usuário. Isto pode ser tanto um URL ou um nome de recurso a ser encontrado no classpath. O padrão é SRPVerifierStore.ser, caso não seja especificado.
O SRPVerifierStoreService MBean também suporta as operações addUser e delUser para adição e remoção de usuários. As assinaturas são as seguintes: 
public void addUser(String username, String password) throws IOException;
public void delUser(String username) throws IOException;
Uma configuração de amostra destes serviços é apresentada no Exemplo 13.2, “A interface SRPVerifierStore ” .

13.1. Entendendo o Algoritmo

O recurso do algoritmo SRP é que ele permite a autenticação mútua do cliente e servidor usando senhas de texto simples sem um canal de comunicação de segurança.

Nota

A informação adicional no algoritmo SRP e seu histórico podem ser encontrados no http://srp.stanford.edu/.
Existem seis etapas executadas para completar a autenticação:
  1. O SRPLoginModule ao lado do cliente restaura a partir do serviço de nomeação da instância SRPServerInterface para o servidor de autenticação remoto.
  2. O SRPLoginModule seguinte ao lado do cliente solicita que os parâmetros SRP associem-se com o nome do usuário na tentativa do logon. Existe um número de parâmetros envolvidos no algoritmo SRP que devem ser escolhidos quando a senha do usuário é primeiro transformada na forma de verificador usada pelo algoritmo SRP. Ao invés da codificação rígida aos parâmetros (que poderia ser feita com um risco mínimo de segurança), a implantação do JBossSX permite que um usuário restaure esta informação como parte de seu protocolo Exchange. A chamada getSRPParameters(username) restaura os parâmetros do SRP para o nome do usuário gerado.
  3. O SRPLoginModule ao lado do cliente inicia uma sessão SRP pela criação de um objeto SRPClientSession usando o nome do usuário do logon, senha de texto simples e parâmetros SRP obtidos na etapa 2. O cliente então cria um número aleatório A que será usado para construir a chave de sessão SRP primária. Em seguida, o cliente inicializa ao lado do servidor da sessão SRP pela invocação do método SRPServerInterface.init e passa o nome do usuário e cliente gerados no número aleatório A. O servidor retorna seu próprio número aleatório B. Esta etapa corresponde à troca das chaves públicas.
  4. O SRPLoginModule ao lado do cliente obtém uma chave de sessão SRP privada que é gerada como um resultado de trocas de mensagens anteriores. Isto é salvo como um credencial privado no Subject do logon. A resposta do desafio do servidor M2 a partir da etapa 4 é verificada pela invocação do método SRPClientSession.verify. Caso isto suceda, a autenticação mútua do cliente para o servidor, e do servidor para o cliente são completadas. O SRPLoginModule ao lado do cliente seguinte cria um M1 de desafio para o servidor pela invocação do método SRPClientSession.response, passando o número aleatório B do servidor como um argumento. Este desafio é enviado ao servidor através do método SRPServerInterface.verify e a resposta do servidor é salva como um M2. Esta etapa corresponde a uma troca de desafios. Nessas alturas, o servidor verificou que o usuário é quem ele disse ser.
  5. O SRPLoginModule ao lado do cliente salva o nome do usuário do logon e o desafio do M1 no mapa sharedState do LoginModule. Isto é usado como nome e credenciais do Principal pelo ClientLoginModule do JBoss padrão. O desafio do M1 é usado no lugar da senha como prova de identidade em quaisquer métodos de invocação nos componentes do Java EE. O desafio do M1 é um hash forte de criptografia associado com a sessão SRP. Não é possível obter a senha do usuário através desta própria intercepção através de terceiros.
  6. No final deste protocolo de autenticação, o SRPServerSession é posicionado no cache de autenticação do SRPService para uso subsequente pelo SRPCacheLoginModule.
Mesmo que o SRP possua propriedades interessantes, ele continua sendo um componente no framework do JBoss e possui algumas limitações pelas quais você deve estar ciente. Os problemas de nota incluem o seguinte:
  • A maneira pela qual o JBoss desanexa o protocolo de transporte do método a partir do recipiente pode permitir que um usuário rastreio o desafio M1 do SRP e use efetivamente o desafio para realizar solicitações como do nome do usuário associado. Os interceptores personalizados podem ser usados para prevenir o problema, pela criptografia do desafio usando a chave de sessão do SRP.
  • O SRPService mantém um cache de sessões SRP que entram em intervalo após um período configurável. Após elas entrarem no intervalo, qualquer acesso do componente Java EE falhará uma vez que não há mecanismo para renegociação transparente dos credenciais de autenticação SRP. Você deve tanto configurar o período para intervalo do cache bem longo ou manusear a re-autenticação em seu código na falha.

    Nota

    O SRPService suporta as durações do intervalo até 2,147,483,647 segundos ou aproximadamente 68 anos.
  • Por padrão, pode haver apenas uma sessão SRP para um nome de usuário gerado por padrão. A sessão é classificada como com estado, uma vez que a sessão SRP negociada produz uma chave de sessão privada que pode ser usada para criptografia e descriptografia entre o cliente e servidor. O JBoss suporta múltiplas sessões de SRP por usuário, no entanto não é possível criptografar dados com uma chave de sessão e descriptografá-la com outra.
Você deverá configurar o domínio de segurança pelo qual os componentes são protegidos para usar o org.jboss.security.srp.jaas.SRPCacheLoginModule, com o objetivo de usar a autenticação SPR de ponta-à-ponta. O SRPCacheLoginModule possui uma opção de configuração única nomeada cacheJndiName que determina a localização JNDI da instância CachePolicy de autenticação SRP. Isto deve corresponder ao valor de atributo AuthenticationCacheJndiName do SRPService MBean.
O SRPCacheLoginModule autentica os credenciais do usuário pela obtenção do desafio do cliente a partir do objeto SRPServerSession no cache de autenticação e comparação do mesmo ao desafio passado como credenciais do usuário. A Figura 13.2, “SRPCacheLoginModule com o Cache de Sessão SRP” ilustra a operação da implantação do método SRPCacheLoginModule.login.
SRPCacheLoginModule com o Cache de Sessão SRP

Figura 13.2. SRPCacheLoginModule com o Cache de Sessão SRP