Segurança em Java

1. Segurança em Java Carlos Bazilio Depto de Ciência e Tecnologia Pólo Universitário de Rio das Ostras Universidade Federal Fluminense

2. Segurança • Alguns conceitos: • Criptografia simétrica x assimétrica (método que utiliza a mesma chave – simétrica - ou chaves diferentes – assimétrica - na cifração e decifração) • Criptografia de chave pública • Assinatura Digital • Autoridade Certificadora (CA – Entidade responsável por garantir a validade das chaves públicas) • Certificado (chave pública + chave de uma CA) • Keystores (BD de chaves criptográficas)

3. Criptografia Assimétrica

4. Assinatura Digital

5. Assinatura Digital • Idéia básica, supondo que se deseja enviar um documento de forma segura: • Você assina o documento usando alguma de suas chaves privadas • Envia o documento assinado para o destinatário • Disponibiliza ao destinatário sua chave pública • O destinatário usa sua chave pública para se certificar que foi você quem a assinou • Como o destinatário se certifica que a chave pública é autêntica? • Usualmente, a chave pública é disponibilizada juntamente com a chave de alguma Autoridade Certificadora (CA), o que chamamos de certificado

6. Assinatura em Mensagem sem Privacidade

7. Assinatura em Mensagem com Privacidade

9. Autoridade Certificadora • Uma Autoridade Certificadora é uma entidade, pública ou privada, que estabelece previamente a identidade do futuro portador do certificado digital (pessoa física ou jurídica), por meio dos documentos necessários, e emite esse certificado (Definição da ICP: https://www.icpbrasil.gov.br) • Exemplo: VeriSign (http://www.verisign.com.br/)

10. Autoridade Certificadora

11. Certificados • Um certificado digital é um documento eletrônico, assinado digitalmente por uma terceira parte confiável, que associa uma entidade (pessoa, processo, servidor) a uma chave pública • Na prática, o certificado digital funciona como uma carteira de identidade virtual que permite a identificação segura de uma mensagem ou transação na rede

12. Certificados • Um certificado contém: • Uma chave pública • Informações do dono do certificado: nome, organização, cidade, país, etc • Uma assinatura digital da certificadora • Informações da certificadora • Um receptor pode checar um certificado analisando sua assinatura digital com a chave pública da certificadora • Esta chave também pode estar armazenada num certificado, o qual cria uma recorrência

13. Cadeia de Certificados • Relação de confiança entre autoridades certificadoras (CA) • Também chamada de hierarquia de certificados • Em termos práticos, a confiança numa CA implica na confiança nas CAs acima hierarquicamente dessa

14. Listando Certificados • Certificados podem fazer parte do SO, dos navegadores ou de Java • No Firefox: • Tools > Options > Advanced > View Certificates • No IE: • Tools > Internet Options > Content > Certificates • Windows: • Start > Control Panel > Internet Options > Content > Certificates • Em Java: • WinNT\Profiles\<usuário>\.keystore (certificados) • <Java>\jre\lib\security\cacerts (autoridades certificadoras)

15. Impressão Digital de Certificados • Fingerprints Certificates • Quando uma cadeia segura não é encontrada, a impressão digital do certificado pode ser calculada • Cada impressão digital é um pequeno número que única e confiavelmente identifica um certificado (tecnicamente, é um valor hash) • Daí basta comparar a impressão digital calculada com uma fornecida pelo proprietário do certificado

16. Keystores • Bancos de dados protegidos por senha que armazenam chaves privadas e seus correspondentes certificados • Um keystore pode ter diversas entradas, cada entrada identificada por um alias • Certificados em keystores são chamados de certificados confiáveis (trusted certificates) • O JDK disponibiliza uma ferramenta chamada keytool para manipulação de keystores

17. Segurança em Java • Inclui um vasto conjunto de APIs, ferramentas e implementações • Estas APIs compreendem: • Criptografia (JCA) • Infra-estrutura de chave pública (PKI) • Comunicação segura (JSSE) • Autenticação e controle de acesso (JAAS) • Assinatura digital de XML • Como na maioria da arquitetura Java, estas APIs são generalizadas de forma a se trabalhar com versões de diferentes fabricantes

18. Keytool • Ferramenta utilizada para gerenciar um keystore (base de dados de chaves criptográficas, cadeias de certificados e certificados confiáveis) • Esta é distribuída junto com o kit de desenvolvimento Java – JDK (http://java.sun.com/javase/6/docs/technotes/tools/windows/keytool.html) • Com ela podemos: • Criar chaves privadas e os correspondentes certificados públicos • Gerar solicitações de certificados, os quais podem ser enviados às autoridades certificadoras • Importar certificados emitidos pelas certificadoras • Gerenciar o Keystore • Estas atividades também podem ser realizadas pela API da linguagem (pacote java.security)

19. Gerando Chaves com o Keytool <JAVA_HOME>/bin/keytool –genkey –alias sirius –keyalg RSA • A execução deste comando irá gerar um arquivo denominado “.keystore” em seu diretório home (ex.: “..\Documents and Settings\bazilio\.keystore”); • Outras opções podem ser consultadas através do comando “keytool –help”;

20. Gerando Requisição de Certificado para CA <JAVA_HOME>/bin/keytool –certreq –alias sirius –file pedido.csr • Este comando gera uma requisição de certificado a ser enviada para um CA e coloca num arquivo denominado “pedido.csr” (CSR – Certification Signing Request) • A resposta da CA será um certificado, assinado por ela, autenticando a chave pública fornecida anteriormente (gerada pelo comando keytool do slide anterior) • Essa resposta usualmente é off-line e pode ser retornado uma cadeia de certificados

21. Importando o Resultado de uma Requisição • Suponha que a resposta seja recebida num arquivo chamado “resposta.cer” <JAVA_HOME>/bin/keytool –importcert –alias siriusca –file resposta.cer • Este comando cria um certificado confiável no keystore com os dados do arquivo “resposta.cer” e associa ao alias “siriusca”

22. Exportando um Certificado <JAVA_HOME>/bin/keytool -exportcert -alias siriusca –file minha_chave_ca.cer • Exporta a entrada autenticada pela CA para o arquivo “minha_chave_ca.cer”

23. Exemplos em Java • Geração de Assinatura Digital • Geração das chaves • Geração da assinatura digital usando a chave privada • Exportação da chave pública e da assinatura para arquivos • Verificação da Assinatura Digital • Importação da chave pública • Verificação da autenticidade da assinatura

24. SSL • SSL (Secure Socket Layer) é uma tecnologia que permite servidores web e navegadores se comunicarem de forma segura • Com SSL, as mensagens trafegadas são cifradas e decifradas no lado do cliente e no lado do servidor • Quando um cliente inicia uma comunicação com um servidor através de uma conexão segura, este envia um certificado “se identificando” • A tecnologia também permite que o servidor requisite um certificado do cliente (autenticação do cliente), embora isto seja pouco comum

25. SSL no Tomcat • Configurar conexões seguras no Tomcat só faz sentido quando este está executando como um servidor stand-alone • Quando é utilizado um servidor como Apache ou IIS para recebimento das requisições, este servidor faria o processo de cifragem/decifragem • Assim, o Tomcat só teria o papel de ser um contêiner para servlets/jsps

26. SSL no Tomcat • Para oferecermos conexões seguras no Tomcat precisamos de um certificado, o qual será enviado por ele no início de uma conexão segura • Para tal podemos utilizar a ferramenta keytool • Neste caso, o parâmetro alias precisa ser “tomcat” e a senha padrão esperada pelo Tomcat é “changeit” • Ambas as senhas do keystore e do certificado precisam ter o mesmo valor

27. SSL no Tomcat <JAVA_HOME>/bin/keytool –genkey –alias tomcat –keyalg RSA • Este comando irá gerar o arquivo .keystore no diretório “..\Documents and Settings\usuário\.keystore” • Observe, entretanto, que um certificado gerado com a ferramenta keytool não deveria ter a mesma confiabilidade de um certificado emitido por uma CA • Esses certificados são chamados de self-signed • Os navegadores normalmente alertam o usuário no recebimento de um certificado como esses, o qual poderia ser enviado por um servidor web não confiável

28. SSL no Tomcat • Como o processo de cifragem/decifragem é caro, deve ser utilizado de forma inteligente • Ou seja, só este tipo de conexão deve ser definida para partes do site que transmitem dados confidenciais, e não para todo o site • Estas páginas passarão a ser acessadas usando https • A porta TCP padrão de conexões https é 443 • O Tomcat utiliza a porta 8443

29. SSL no Tomcat • A versão corrente do Tomcat trabalha com keystores no formato JKS (Java Keystore), PKCS11 e PKCS12 (Public Key Cryptography Standards 11 e 12) • http://en.wikipedia.org/wiki/PKCS • Após a geração do certificado, precisamos configurar o Tomcat para permitir conexões seguras • Para tal, modificaremos o arquivo de configuração “<tomcat>/conf/server.xml”

30. SSL no Tomcat • No arquivo server.xml devemos retirar o comentário do conector 8443 e modificá-lo da seguinte forma: <Connector port="8443" minSpareThreads="5" maxSpareThreads="75" enableLookups="true" disableUploadTimeout="true" acceptCount="100" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" keystoreFile="c:\Java\Tomcat6\.keystore" keystorePass="changeit" clientAuth="false" sslProtocol="TLS"/> • Após atualizar o arquivo, basta reiniciar o Tomcat e digitar o seguinte endereço no browser: https://localhost:8443/

31. Autenticação no Tomcat • Aplicações web são hospedadas no Tomcat no diretório: <tomcat>/webapps • Usualmente, a configuração de uma aplicação reside num arquivo denominado descritor de implantação: <tomcat>/webapps/app/WEB-INF/web.xml • Dentro do elemento raiz <webapp /> 2 elementos são importantes: • <login-config />: indica o tipo de autenticação utilizada • <security-constraint />: indica que parte da aplicação deve ser resguardada e quem tem acesso

32. Autenticação Básica no Tomcat <web-app> ... <login-config> <auth-method>BASIC</auth-method> <realm-name>Área de Testes</realm-name> </login-config> </web-app> • Indica que a aplicação exige um tipo básico de autenticação • O elemento <login-config /> deve ser colocado dentro do elemento <webapp /> • Ainda deverá ser fornecido as partes da aplicação que deverão se resguardadas e que conteúdos (slides à seguir) • Os métodos possíveis de autenticação são: BASIC, DIGEST, FORM e CLIENT-CERT • A autenticação básica solicita apenas um usuário e senha válidos no servidor (tomcat) – por exemplo, através do arquivo <tomcat>/conf/tomcat-users.xml

33. Cliente 1. Cliente solicita um recurso protegido 3. O usuário insere o nome e a senha dele 4. A máquina do cliente cria um hash das informações: (nome + senha + url + método http + nonce) Autenticação de Resumo no Tomcat Servidor 2. O servidor cria o nonce aleatório e o envia ao cliente 5. O servidor valida o hash criando seu próprio para verificar se ele corresponde ao do cliente 6. Envia o recurso requisitado ao cliente ou uma página de erro

34. Autenticação de Resumo no Tomcat • Modificação do arquivo web.xml <web-app> ... <login-config> <auth-method>DIGEST</auth-method> <realm-name>Área de Testes</realm-name> </login-config> </web-app>

35. Autenticação de Formulário no Tomcat • Personalização da autenticação através do fornecimento de uma página de login/senha própria; • Além disso, também deve ser fornecida uma página erro; • A construção do formulário deverá conter campos com nome padrão, já que é o Tomcat que valida o usuário: • j_security_check para o nome da ação; • j_username para o nome do usuário; • j_password para senha.

36. Autenticação de Formulário no Tomcat <html> <head> <title>Formulário de Login</title> </head> <body> <h1>Por favor, autentique-se:</h1> <form action="j_security_check" method="post"> Usuário: <input type="text" name="j_username"/><br/> Senha: <input type="password" name="j_password"/><br/> <input type="submit" value="Envie"/> </form> </body> </html>

37. Autenticação de Formulário no Tomcat • Modificação do arquivo web.xml <web-app> ... <login-config> <auth-method>FORM</auth-method> <realm-name>Testes de Formulário</realm-name> <form-login-config> <form-login-page>/login.html</form-login-page> <form-error-page>/erro.html</form-error-page> </form-login-config> </login-config> </web-app>

38. Autenticação SSL de 2 vias no Tomcat • Neste método, ambos servidor e cliente precisam apresentar certificados válidos para autenticação • Além desta configuração precisamos realizar outros 2 passos para completar esta configuração: • Definir o elemento <user-data-constraint /> (a ser visto a seguir) para alguma porção da sua aplicação (configuração para HTTPS) • Prover algum certificado válido, no lado do cliente, para testes <login-config> <auth-method>CLIENT-CERT</auth-method> <realm-name>Área de Testes</realm-name> </login-config>

39. Autenticação no Tomcat • Para indicarmos que partes da aplicação devem ser resguardadas utilizamos o elemento <security-constraint />, sub-elemento de <web-app> <security-constraint> <web-resource-collection> <web-resource-name>Área Segura</web-resource-name> <url-pattern>/seg/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>tomcat</role-name> </auth-constraint> </security-constraint>

40. Autenticação no Tomcat • Descrição dos sub-elementos de <security-constraint />: • <url-pattern />: indica o subdiretório raiz à partir do qual a autenticação é exigida • <http-method />: indica sobre qual método http a autenticação é exigida • <auth-constraint />: indica que papéis (sub-elemento <role-name />) de usuários têm acesso ao conteúdo indicado em <url-pattern /> • Observe que os elementos <security-constraint />, <url-pattern />, <http-method /> e <role-name /> podem ocorrer de forma repetida; isto facilita a configuração de porções da aplicação que possuem regras de autenticação similares

41. Configuração da Aplicação para HTTPS • Para que os dados entre cliente e servidor sejam enviados de forma segura, criamos o elemento <user-data-constraint /> como sub-elemento de <security-constraint /> <security-constraint> ... <user-data-constraint> <transport-guarantee> CONFIDENTIAL </transport-guarantee> </user-data-constraint> </security-constraint>

42. Configuração da Aplicação para HTTPS • As opções para a tag transport-guarantee são: • CONFIDENTIAL: os dados devem ser transmitidos sem interceptação • INTEGRAL: os dados devem ser transmitidos sem interceptação e preservando a integridade (similar ao resumo) • NONE: nenhuma garantia é exigida. • Tanto CONFIDENTIAL quanto INTEGRAL resultam no uso de SSL

43. Autenticação usando SGBD via JDBC no Tomcat • Copiar driver JDBC para a pasta <tomcat>/lib/ e reiniciar o Tomcat • Criar 2 tabelas no SGBD escolhido:

44. Autenticação usando SGBD via JDBC no Tomcat • Há 2 opções de configuração da aplicação: • <tomcat>/conf/server.xml (configuração global): o elemento xml fornecido à seguir deve ser colocado dentro do elemento <Engine /> • <tomcat>/webapps/app/META-INF/context.xml (configuração local): o elemento xml fornecido à seguir deve ser colocado dentro do elemento <Context />

45. Autenticação usando SGBD via JDBC no Tomcat • Exemplo utiliza o MySQL • Descrição dos atributos à seguir

46. Autenticação usando SGBD via JDBC no Tomcat

47. Referências • http://jf.eti.br/autenticando-aplicacao-web-com-tomcat-5-e-banco-de-dados/ • Tutorial de configuração do Tomcat com SGBDs