Segurança

Email seguro usando certificados digitais

Matt Clapham and Blake Hutchinson

À primeira vista:

• Criando uma identidade verificável
• Atualizando o status do certificado
• Obtendo e trocando os certificados
• Solucionando problemas do sistema S/MIME

Por milênios, os humanos usaram vários métodos para ocultar informações em trânsito, validar o remetente e autenticar a mensagem. Conforme a civilização foi evoluindo, foi desenvolvido um método para realizar todas as três tarefas e que está sendo cada vez mais usado. S/MIME (Secure Multi-Purpose Internet Mail)

As extensões S/MIME formam um sistema para enviar email de maneira segura usando criptografia e assinaturas digitais.

As tecnologias de criptografia (ocultar) atuais são de dois tipos principais: algoritmos de chave simétrica (secreta) como, por exemplo, DES (padrão de criptografia de dados) ou AES (Advanced Encryption Standard) e algoritmos de chave assimétrica (pública/privada) como RSA ou ECC (Elliptical Curve Cryptography). As ferramentas modernas para validação do remetente são funções unidirecionais matemáticas chamadas hashes que criam assinaturas exclusivas. Os dois métodos de hash mais usados são MD5 (algoritmo Message Digest 5) e SHA (Secure Hash Algorithm). Os computadores podem usá-los para gerar um hash exclusivo ou número correspondente ao texto de origem individual (o hash de textos de origem idênticos tem o mesmo valor). Essas ferramentas simples são aproveitadas e combinadas para criar um sistema PKI (infra-estrutura de chave pública).

Uma identidade verificável

Recursos de autoridade de certificação

• Usando uma autoridade de certificação no serviço de arquivos com criptografia
• Não é possível renomear ou remover servidores de autoridade de certificação da rede
• Como remover uma autoridade de certificação confiável dos computadores no domínio
• Como descomissionar uma autoridade de certificação corporativa do Windows e remover todos os objetos relacionados do Windows Server 2003 e do Windows 2000 Server
• Como mover uma autoridade de certificação para um novo servidor em execução em um controlador de domínio

As identidades dentro de um sistema PKI são gerenciadas usando-se certificados digitais, que não são diferentes da identificação federal que a maioria das pessoas carrega em viagens internacionais: o passaporte. O padrão passaporte no mundo do certificado digital é o formato X.509, sendo amplamente usado tanto na assinatura quanto na criptografia em tecnologias como, por exemplo, S/MIME, protocolo IPsec (Internet Protocol Security), SSH (Secure Shell), segurança de rede sem fio, VPNs (redes virtuais privadas) e até mesmo comunicações com servidor seguro (como sites SSL).

Os certificados se baseiam na criptografia assimétrica e nos hashes. Para criar um certificado, o solicitante (a entidade que deseja uma chave assinada por alguma autoridade superior) gera uma chave privada. A chave é mantida bloqueada para que sua autenticidade jamais seja desafiada. Com a chave privada, uma chave pública correspondente também é gerada. Como o próprio nome diz, a parte pública do par não é segredo, sendo distribuída livremente, ainda que, de alguma forma, garanta sua autenticidade.

Esse par de chaves permite duas operações fundamentais. Primeiro, qualquer um pode usar a chave pública para criptografar algo que só a chave privada pode descriptografar e, segundo, a chave pública pode ser usada para descriptografar algo criptografado com a chave privada. Isso é importante para verificar uma assinatura que somente uma chave privada pode ter criado.

A solicitação feita à autoridade de certificação inclui detalhes como, por exemplo, a identidade da pessoa ou do computador ao qual se destina a chave, a força e o tipo de algoritmo, além da parte pública do par de chaves. A CA (autoridade de certificação) recebe e valida as informações da solicitação e, usando um algoritmo de hash, cria um identificador exclusivo correspondente às informações.

Usando sua chave privada, a CA criptografa o hash das informações e as monta em um formato padrão (como, por exemplo, X.509), criando um certificado correspondente à solicitação original. O certificado X.509 conterá uma lista das declarações, inclusive a identidade do certificado (o assunto), um período de validade, a chave pública e as operações nas quais o certificado pode ser usado. Em seguida, o certificado retorna ao solicitante; trata-se de um token que afirma: "eu, a CA, concedo esta chave pública e sua parte privada correspondente, tendo em vista todos os usos aqui descritos".

Em CAs raiz (aquelas no nível mais alto da cadeia de confiança), os certificados são assinados automaticamente. A maioria das CAs raiz aceitáveis vem pré-instalada no sistema operacional base ou aplicativo, embora possa ser atualizada ou alterada por meio de pacotes ou da configuração corporativa. Entre a CA raiz e um nó folha (que normalmente descreve um indivíduo ou sistema), talvez haja uma ou mais CAs intermediárias.

A cadeia consiste em todos os nós e todos os certificados anteriores embutidos, assinados pela CA exatamente nesse nível. Um terceiro que esteja tentando validar o certificado pode verificar o hash calculado localmente e compará-lo com um descriptografado pelo certificado usando a chave pública correspondente a essa CA específica ou individual. É isso – uma cadeia de confiança totalmente validada, da folha à raiz – pressupondo, obviamente, que a raiz seja confiável.

Atualizando o status do certificado

Toda boa CA conta com meios para distribuir uma lista de certificados que devem deixar de ser confiáveis. Essa CRL (lista de certificados revogados) descreve quais itens emitidos foram especificamente negados pela CA. Como medida prática, o local da CRL costuma ser uma propriedade do certificado da CA.

As CAs quase sempre emitem CRLs baseadas em duas coisas: um cronograma (talvez a cada duas semanas) ou um evento (alguma ocorrência que indique que um certificado emitido deixou de ser confiável). Uma CA assinará as CRLs emitidas quando as publicar. Ao avaliar a validade de uma cadeia, um sistema de recepção normalmente tenta adquirir a CRL de cada CA emissora da cadeia (por meio dos detalhes embutidos nos próprios certificados ou de algum mecanismo de distribuição confiável predefinido). Caso alguma CRL não esteja disponível, o cliente pode retornar a uma cópia recente, armazenada com êxito em cache, desde que ela não seja anterior ao período de atualização da CRL especificada. No entanto, em caso de falha, os sistemas do cliente normalmente mostrarão algum tipo de erro indicando que o certificado aparenta ser válido, mas que o status de revogação não pode ser determinado.

Muitos aplicativos demoram significativamente mais para carregar um certificado caso não possam validar a cadeia ou a CRL de todos os nós da cadeia. Dependendo do que o certificado estava protegendo, o usuário pode ou não confiar nele. Um ponto de distribuição da CRL sempre atualizado e amplamente disponível é absolutamente necessário para todas as CAs, especialmente para as raízes públicas.

As raízes constituem a base da cadeia de certificados e a cadeia, a base de todas as hierarquias de certificados. Grande parte dos sistemas ou dos aplicativos só irá pressupor a validade de um certificado de nó folha se este estiver encadeado em uma raiz confiável. Ela pode ser uma CA corporativa, de propriedade e operada por uma empresa particular, ou uma CA raiz pública (como, por exemplo, a VeriSign).

No caso das CAs raiz públicas, existe a expectativa de uma experiência profissional significativa, logo, essa integridade é garantida. As empresas devem buscar o mesmo nível para suas operações internas, porque a segurança de uma CA raiz nesse contexto é tão importante quanto. Tendo em vista a proteção ideal, as CAs raiz devem, na verdade, ser mantidas offline e só serem usadas para emitir certificados e atualizar CRLs. Para obter mais informações sobre as práticas recomendadas sobre a CA operacional, consulte os artigos listados na barra lateral "Recursos de autoridade de certificação".

Um aspecto importante a ser considerado é a recuperação da chave. Para facilitar as investigações e garantir que os dados não sejam bloqueados por um usuário de modo que não possam ser recuperados, a empresa deve fazer cópias de backup de todas as chaves emitidas pelo usuário. Além disso, essas cópias de backup devem ser armazenadas em um repositório seguro. Dessa forma, caso a chave de um usuário desapareça, por exemplo, quando um cartão inteligente é esquecido em um táxi, todo conteúdo protegido pela chave continua sendo acessível.

Por fim, em todo bom sistema criptográfico está o conceito de gerenciamento do ciclo de vida. À medida que os computadores se tornam mais rápidos, os algoritmos ficam mais fracos. Todo bom sistema criptográfico precisa ter a capacidade de se renovar e recorrer a novos algoritmos e tamanhos de chave com o passar do tempo. As CAs deverão ser atualizadas corretamente quando forem identificadas deficiências criptográficas e determinadas funções forem introduzidas ou suprimidas.

Implementando S/MIME

Há vários estágios para inicializar, redigir, enviar e receber emails assinados ou criptografados usando S/MIME. Abordaremos os detalhes, os problemas e as soluções potenciais à medida que avançarmos em um cenário de S/MIME típico: dois usuários enviando emails assinados e/ou criptografados um para o outro em duas florestas do Active Directory® e cadeias de autoridade de certificação diferentes (ou seja, em duas entidades separadas em termos operacionais, independentemente de ser na mesma empresa ou não) usando o Microsoft® Office Outlook® 2007.

Iremos pressupor que a infra-estrutura necessária já esteja in-loco para habilitar as operações que descreveremos. Em nosso caso, estamos usando um servidor de certificados corporativo integrado ao Active Directory.

Obtendo certificados

A primeira tarefa é obter os certificados apropriados. Para isso, abra o MMC Gerenciador de Certificados (certmgr.msc), clique com o botão direito do mouse na pasta Pessoal, selecione Todas as Tarefas na lista pop-up e Solicitar Novo na lista.

Isso inicia o assistente Registro de Certificado, como mostrado na Figura 1. Por padrão, várias opções centradas na empresa serão mostradas, mas o certificado Usuário é a mais importante. Ele será usado para habilitar os processos de assinatura e criptografia posteriormente. O certificado deve ser usado em:

Figura 1** Solicitando um certificado **(Clique na imagem para uma visão ampliada)

• Assinaturas digitais (criando uma mensagem com um selo de autenticidade do criador)
• Codificação de chave (protegendo uma chave com outra em tecnologias como, por exemplo, o Encrypting File System)
• Email seguro (sistema de mensagens criptografadas que só podem ser lidas pelo destinatário desejado de posse da chave privada correspondente)

Para enviar emails assinados S/MIME, a propriedade de codificação de chave não é obrigatória. No entanto, para enviar ou receber emails criptografados, essa propriedade é obrigatória, ainda que a propriedade da assinatura não seja. Por padrão, os modelos dos Serviços de Certificados do Windows® habilitam essas três propriedades. Se o usuário não tiver permissão para solicitar novos certificados, nenhum será mostrado quando o assistente for iniciado. Se nenhuma CA corporativa estiver disponível, o usuário receberá um "Erro no registro" indicando que não foi possível entrar em contato com o domínio ou a CA. Neste passo a passo, iremos pressupor um único certificado permitindo tanto a assinatura quanto a codificação.

Trocando certificados

A forma mais fácil para que dois usuários comecem a enviar emails criptografados é simplesmente enviando mensagens assinadas um para o outro. Depois de redigir uma mensagem, o usuário clica no botão Assinar. (Às vezes, o botão permanece oculto por padrão no Outlook até ser usado pelo menos uma vez. Ele pode ser encontrado clicando-se na configuração Opções para novas mensagens, no botão "Configurações de Segurança..." e, em seguida, marcando a caixa "Adicionar assinatura digital a esta mensagem" na caixa de diálogo Propriedades de Segurança.) O botão de assinatura (um pequeno envelope amarelo com uma faixa de opções vermelha com os dizeres Assinar) adiciona uma assinatura digital à mensagem para estabelecer a autenticidade de sua origem.

Ao pressionar o botão Enviar, o usuário pode ser solicitado a fornecer tokens adicionais de posse da chave como, por exemplo, inserir um cartão inteligente ou digitar um PIN. Isso depende dos métodos particulares de proteção da chave in-loco na organização.

O usuário que recebe a mensagem assinada com S/MIME precisará exibir e clicar com o botão direito no nome do remetente (depois do De:) e selecionar "Adicionar a Contatos do Outlook" no menu de contexto, que adiciona uma nova entrada de contato ou atualiza uma existente. Dessa forma, o certificado é associado a essa entrada de contato em especial. Observe que, em um mesmo ambiente do Active Directory (dois usuários na mesma floresta ou empresa), a distribuição do certificado de usuário público é feita automaticamente por meio dos atributos no objeto do Active Directory do usuário).

Outra forma de trocar certificados é cada usuário enviando seu(s) certificado(s) S/MIME como um anexo. Para isso, ambas as partes precisarão exportar seu(s) certificado(s) para um arquivo CER. Os usuários precisarão exibir o certificado e seguir o processo de exportação que abordaremos daqui a pouco, tomando o cuidado de não exportar a chave privada junto, como mostrado na Figura 2.

Figura 2** Ao trocar certificados, não exporte a chave privada **(Clique na imagem para uma visão ampliada)

Em seguida, cada destinatário cria manualmente uma entrada de contato no Outlook e adiciona o certificado à entrada do destinatário. Depois de trocar os certificados, os dois usuários poderão trocar emails criptografados.

Solução de problemas

Às vezes, o destinatário tem dificuldade para abrir a mensagem criptografada. As três causas mais prováveis dos problemas que vimos em relação a isso são CAs raiz não confiáveis, CAs intermediárias que não podem ser validadas e CRLs não disponíveis.

Uma CA raiz não confiável costuma ser mostrada no Outlook como uma mensagem de erro associada à assinatura: "Há problemas com a assinatura. Clique no botão de assinatura para obter detalhes." Para resolver o problema, abra o certificado no Outlook e clique no botão "Exibir a Autoridade de Certificação" da caixa de diálogo pop-up. Observe a mensagem na guia Geral da caixa de diálogo das propriedades do certificado. Caso ela indique que o certificado da CA raiz não é confiável e que precisa ser instalado, vá até a guia Detalhes. Clique no botão "Copiar para Arquivo..." e siga o assistente, aceitando todos os padrões e fornecendo um nome de arquivo e pasta quando solicitado.

Agora abra um novo MMC (Console de Gerenciamento Microsoft) como administrador de máquina. Vá até Arquivo|Adicionar/Remover Snap-in (Ctrl+M), selecione Certificados e o adicione à conta do computador, escolhendo o computador Local quando solicitado. Em seguida, expanda o nó Certificados na árvore à esquerda e faça o mesmo com as Autoridades de Certificação de Raiz Confiáveis. Clique com o botão direito do mouse e selecione Todas as Tarefas|Importar no menu pop-up. Importe o arquivo de certificado exportado e mencionado anteriormente para Autoridades de Certificação de Raiz Confiáveis e clique em Concluir. Em seguida, peça que o usuário afetado reinicie o Outlook.

Essas instruções só devem ser usadas para adicionar uma CA raiz reconhecidamente confiável. Nem todas as raízes são criadas da mesma maneira. Considere atentamente quem é o proprietário e quem opera a CA raiz, antes de usar esse método para adicionar uma raiz ao repositório usando em todo o sistema. Se a empresa controlar a lista de raízes confiáveis por meio da Diretiva de Grupo, a configuração será levada até os sistemas do cliente. Nesse caso, as instruções podem não funcionar. Caso elas não funcionem, você talvez precise explorar alternativas como, por exemplo, sites seguros ou servidores para trocar os dados, uma vez que o email não será uma experiência direta e protegida.

O segundo problema observado acima, CAs intermediárias que não podem ser validadas, normalmente ocorre em duas situações: um cliente que está tentando validar o certificado não consegue chegar ao local AIA (Acesso a Informações da Autoridade) definido no certificado, ou o cliente tem uma versão do certificado da CA intermediária que não corresponde ao que a CA está emitindo (o cliente normalmente está uma ou duas versões atrasado). Essas condições aparentam ser muito semelhantes dentro da interface do usuário do Outlook. Só vimos isso em uma circunstância muito específica quando uma CA de nível intermediário na cadeia expirou e foi reemitida antes que outros certificados subordinados emitidos expirassem.

Basicamente, esse problema ocorre quando a cadeia apresenta lacunas. Alguns certificados pai talvez não estejam tão bem detalhados ou estejam corretamente embutidos no nó folha, o que complica ainda mais a situação.

Para resolver esse problema, o remetente precisará abrir uma nova mensagem e clicar em Opções da nova mensagem, no botão Configurações de Segurança e no botão Alterar Configurações. Agora clique no botão Escolher quanto ao certificado de assinatura e no botão Exibir Certificado na caixa de diálogo do menu pop-up. Vá até a guia Caminho do Certificado, selecione o emissor do nó folha (ou seja, um nível acima na cadeia) e clique no botão Exibir Certificado. Clique na guia Detalhes e no botão Copiar para Arquivo... e, em seguida, conclua o assistente de exportação, selecionando PKCS #7 (.P7B). Verifique se a opção "Incluir todos os certificados no caminho de certificação" está marcada, como mostrado na Figura 3. Por fim, envie o arquivo da cadeia exportado para o destinatário desejado.

Figura 3** Preenchendo as lacunas de uma cadeia de certificados **(Clique na imagem para uma visão ampliada)

Depois de obter a cadeia do certificado exportada, o destinatário precisará abrir e importá-la praticamente da mesma forma que importamos uma raiz anteriormente. A única diferença é que a pasta de armazenamento escolhida deve ser Autoridades de Certificação Intermediárias. Caso a mensagem seja aberta e o certificado, mostrado como válido no Outlook, é sinal de que as coisas estão funcionando corretamente.

Quanto ao terceiro problema, o das CRLs não estarem disponíveis, a correção é comparativamente simples. A resposta inicial do Outlook será bem semelhante à do problema anterior. Porém, o erro mostrará até mesmo se a CA de assinatura raiz ou intermediária é confiável. Para cada nível da cadeia de certificados acima da folha, abra as propriedades do certificado e, em seguida, a guia dos detalhes e observe um campo chamado "Pontos de Distribuição da Lista de Certificados Revogados".

Para cada ponto de distribuição da CRL listado (especialmente os acessíveis na Internet), verifique se a URL do arquivo da CRL pode ser aberta. Na medida em que cada nível for validado, suba um nível na cadeia. Caso nenhuma CRL possa ser adquirida, é provável que ela seja a origem do problema. Para resolvê-lo, você deve verificar se a diretiva de rede local não está bloqueando o seu acesso. Do contrário, tente entrar em contato com a empresa proprietária da CA ou aguarde o retorno do status operacional do ponto de distribuição da CRL da CA.

Distribuindo certificados

A distribuição é a parte mais fácil. Basicamente, a mensagem assinada é transmitida para um servidor de email, que acaba enviando-a de um local para outro usando um método de tentativa e acerto, SMTP. O único problema que vimos no email assinado ou criptografado em trânsito é que alguns sistemas de email rejeitam ou quebram mensagens assinadas ou criptografadas que passam por eles. A saída é trabalhar com o gerente de TI do sistema para que os tipos de mensagem sejam permitidos. Obviamente, você talvez tenha de conviver com o fato de alguns tipos de mensagem serem bloqueados. A parte destinatária pode ter uma boa razão para não permitir mensagens criptografadas em um determinado ambiente operacional.

Criptografando respostas

Para criar uma resposta criptografada (pressupondo que o processo de inicialização acima já tenha sido concluído), o remetente só precisa criar uma mensagem e, em seguida, clicar no botão Criptografar (o pequeno envelope amarelo com um cadeado azul com os dizeres Criptografar) na janela de redação da mensagem. Caso o botão não esteja disponível, execute as etapas para enviar uma mensagem assinada, exceto a última, e marque a caixa de seleção "Criptografar conteúdo da mensagem e anexos".

A assinatura S/MIME não é obrigatória para enviar uma mensagem criptografa a um destinatário, mas ambas se saem muito bem juntas, porque a assinatura permite ao leitor validar o remetente (a função de criptografia não faz nenhuma declaração quanto ao remetente). O processo de criptografia tentará criptografar a mensagem com as chaves públicas conhecidas de todos os destinatários. Se o sistema não conseguir encontrar os certificados de alguns destinatários desejados, estes serão sinalizados em uma caixa de diálogo pop-up que se oferece para enviar a mensagem descriptografada, como mostrado na Figura 4.

Figura 4** É possível optar por enviar uma mensagem descriptografada caso você tenha um problema com um certificado **(Clique na imagem para uma visão ampliada)

Por padrão, assinar e criptografar devem funcionar com os demais sistemas do cliente de configuração semelhante, mas o sistema de mensagens criptografadas ou assinadas em várias versões pode, às vezes, apresentar problemas caso não haja suporte para o nível inferior do algoritmo de hash ou de criptografia. Tivemos um problema assim ao enviar um email assinado (usando SHA-512 como algoritmo de hash) para um usuário com o Windows XP SP2 em execução. Como o sistema de recebimento não dava suporte ao hash, o usuário não conseguiu validar a assinatura nem ler a mensagem. No entanto, é improvável que os usuários tenham tantos problemas a essa altura, a menos que os padrões do Outlook tenham sido alterados.

Após receber a mensagem, o destinatário desejado deve ser capaz de abri-la, dada a disponibilidade da chave privada com o certificado público. Mais uma vez, o usuário talvez precise fornecer um token adicional a fim de provar a posse da chave privada, dependendo da forma com que ela foi implantada. Outros usuários que completaram um processo de inicialização semelhante podem participar da comunicação assinada e criptografada com o remetente. Se alterar sua chave privada em algum momento (talvez por conta da perda de um computador), um usuário precisará solicitar novamente os certificados e redistribuir uma mensagem assinada ou um arquivo certificado para as demais pessoas que queiram trocar emails criptografados.

Conclusão

Fazer com que as extensões S/MIME assinadas e criptografadas funcionem entre dois usuários em dois diretórios ou organizações diferentes não costuma ser muito mais complicado que o abordado aqui. A assinatura é muito prática, quando usada corretamente, por dar autenticidade à mensagem. Tendo em vista detalhes confidenciais, as mensagens criptografadas dão um nível a mais de segurança para os dados em trânsito. Juntas, as duas possibilitam a autenticidade da origem e a segurança dos dados. E com o processo que descrevemos aqui, não será um desafio para a maioria dos usuários usufruir esses recursos.

Matt Clapham, CISSP, é engenheiro de segurança de TI da Microsoft. Ele realiza revisões de segurança em aplicativos LOB durante o dia e brinca com tecnologia, jogos, música eletrônica ou segurança à noite. Ele ocasionalmente faz apresentações para a comunidade de segurança Puget Sound IT. Entre em contato com ele pelo email matt.clapham@microsoft.com.

Blake Hutchinson é analista de suporte do BOSG (Business Online Services Group) na Microsoft. A função que ele ocupa inclui o suporte operacional e a revisão do projeto de ferramentas LOB criadas internamente para os clientes corporativos do BOSG. Blake gosta de fotografia, esqui e jogos de computador. Entre em contato com ele pelo email blakeh@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados; é proibida a reprodução parcial ou completa sem autorização..