MP202 - Segurança da Informação Professor: Ricardo Dahab Tecnologias de hardware para prevenção de ataques: processadores invioláveis

Transcrição

1 MP202 - Segurança da Informação Professor: Ricardo Dahab Tecnologias de hardware para prevenção de ataques: processadores invioláveis Ana Cristina Livino Cabral - RA Paulo Henrique Nóbrega Tavares - RA de novembro de 2003

2 Conteúdo 1 Introdução Ambientes inseguros ou não confiáveis Ameaças Máquinas desprotegidas Erros de software Empregados, subcontratados e clientes desonestos Cópias de segurança e recuperação de desastres Ambientes hostis Processadores seguros ou invioláveis Arquitetura Operação Como os processadores respondem a ameaças Máquinas e circuitos vulneráveis Erros de software Empregados, subcontratados e clientes desonestos Cópias de segurança e recuperação de desastres Principais aplicações Segurança de PKI e aplicações seguras Encriptação segura Máquinas de pagamento seguras (PIN) e processamento de senhas Autenticação segura de usuários Autoridades Certificadoras Aceleradores de Transações Assinaturas Digitais Informação correta de tempo Distribuição de conteúdo Digital As famílias de processadores seguros Chip Card Personal Tokens

3 2.5.3 Aceleradores criptográficos Processador seguro de alto padrão Estudo de caso Autoridades certificadoras Descrição do problema Requisitos da solução Solução utilizando processador seguro Vantagens Padronização e Certificação Objetivos Funcionais de Segurança Especificação do módulo criptográfico Critério comum Projeto Modular Módulos do Software - Interfaces e procedimentos Construção Interna Documentação do código Linguagem Assembly Níveis de avaliação de acordo com o Critério Comum EAL EAL EAL EAL Níveis de segurança de acordo com FIPS Nível Nível Nível Nível Requisitos de segurança Segurança física de acordo com o FIPS Ataques Classes de atacantes Classe I (atacantes externos inteligentes) Classe II (atacantes internos com conhecimento) Classe III (Organizações) Tipos de ataque Análise da potência Análise do sincronismo Indução a falha

4 5.2.4 Ataque tempestade Produtos IBM Arquitetura Firmware Software ncipher NForce payshield nethsm Key Safe Rainbow CryptoSwift HSM Conclusão 46 3

5 Capítulo 1 Introdução O propósito geral do trabalho é descrever o que são processadores seguros ou invioláveis, algumas de suas características gerais e aplicações, mencionando o principal padrão existente para avaliação de tais processadores e concluindo com exemplos de processadores comerciais existentes no mercado. HSM (Hardware Security Module) é um dispositivo de segurança baseado em hardware que gera, armazena e protege chaves criptográficas e outras informações críticas para que não possam ser adulteradas ou roubadas. Geralmente o HSM trabalha em conjunto com aplicações hospedeiras, como por exemplo, aplicações para Autoridades Certificadoras que autenticam identidades digitais e protegem as chaves privadas de outras aplicações, aplicações para realizar operações criptográficas. Muitas vezes o HSM é acoplado a um servidor para proteger as informações importantes e também para agilizar as autenticações do programas ou clientes desse mesmo servidor. Os HSM podem ser aplicados em quase todas as soluções que exijam segurança e criptografia, só é necessária uma análise de custos e riscos para se escolher o melhor hardware que se aplica ao problema. 1.1 Ambientes inseguros ou não confiáveis É provavelmente indiscutível [13] que a segurança é crítica para muitos sistemas financeiros, de comércio eletrônico, militares etc. Entretanto, um aspecto frequëntemente negligenciado nestes sistemas são as máquinas e dispositivos de armazenamento. Certamente poucos considerariam adequado deixar um pacote de dinheiro sobre o guichê enquanto se busca uma guia de depósito, no entanto um computador inseguro pode não ser um lugar muito melhor para deixar o dinheiro. Dados ou algoritmos podem ser modificados e controle sobre os bens pode ser usurpado ou perdido. Por causa desta situação, muitas operações computacionais e de armazena- 4

6 mento têm que ocorrer em um ambiente seguro, de forma que as partes que precisam possam confiar que as operações satisfazem algumas propriedades como: A chave privada foi revelada a alguém? Houve uma mudança espúria na quantidade de fundos armazenados? O par de chaves foi gerado aleatoriamente ou de uma forma que pode ter sido prevista por um adversário? Os fundos foram transferidos de forma atômica (em uma transação) ou um erro de comunicação criou fundos espúrios? A chave privada gerou somente as assinaturas autorizadas pelo proprietário? 1.2 Ameaças Algumas das ameaças de segurança mais difíceis de conter vêm de adversários potenciais com acesso ao hardware ou software que executam uma operação e podem se beneficiar de sua eventual alteração, um problema que só aumentou com o crescimento do comércio eletrônico e a conectividade das máquinas em rede Máquinas desprotegidas Máquinas fisicamente desprotegidas são particularmente vulneráveis a ataques, seja por vândalos ou por atacantes mais sérios. Qualquer um com acesso a uma máquina pode tentar reinicializá-la, alterar seus arquivos, carregar software falso ou até mesmo roubar a máquina para tentar quebrar a sua segurança em segredo. As recentes tendências de disponibilizar os serviços em qualquer lugar (por exemplo caixas eletrônicos) têm colocado máquinas em ambientes remotos, distantes das localizações tradicionais seguras (num banco, num centro de computação etc). Estas máquinas são claramente mais vulneráveis a ataques do que aquelas com acesso físico mais controlado. Circuitos desprotegidos também são vulneráveis a ataques. Um atacante com acesso físico ao circuito pode com relativa facilidade utilizar equipamentos que permitem analisar o tráfego de dados em um circuito impresso e observar, por exemplo, chaves que são trocadas entre a memória e os dispositivos de criptografia. 5

7 1.2.2 Erros de software Erros de software, sejam intencionais ou não, podem facilmente comprometer a segurança de um sistema. Em um ambiente supostamente seguro (um smart card, por exemplo) em que não há isolamento entre tarefas, uma aplicação com erros pode estragar os dados de outra aplicação (como o saldo restante). Falhas nos sistemas operacionais (e mais recentemente em ambientes de execução como o do Java) também podem levar a graves problemas de segurança Empregados, subcontratados e clientes desonestos Empregados desonestos são um problema particularmente complicado. Como funcionários, eles têm que ter acesso à informação e aos sistemas para fazer o seu trabalho mas freqüentemente é difícil fazer um controle muito fino deste acesso. Por exemplo, um administrador de sistema tem que ter acesso irrestrito a uma máquina para fazer atualizações de software, cópias de segurança etc. Infelizmente, em muitas máquinas o controle não tem granularidade suficiente para permitir isso mas impedir a cópia indevida de arquivos para venda a competidores. No caso dos subcontratados a situação é ainda mais difícil porque a sua ligação com a empresa é tipicamente muito menor do que a de um empregado regular. Clientes desonestos são ainda menos sujeitos a controle. Não é possível despedir um cliente (ou impedir que ele volte) e, como não pode distinguir os honestos dos desonestos, um fornecedor tem que tratar todos os seus clientes com cortesia, sem demonstrar suspeita. Hoje em dia os clientes muitas vezes têm acesso a bases de dados de catálogos, preços e outras informações potencialmente sensíveis que podem ser valiosas para competidores Cópias de segurança e recuperação de desastres O objetivo explícito das cópias de segurança e recuperação de desastres é replicar dados críticos em um número suficiente de lugares de forma a ser possível a recuperação de qualquer falha única. Neste caso, o desafio é proteger esta enorme quantidade de dados de roubo, modificação ou mau uso, especialmente quando as cópias de segurança são armazenadas remotamente, sob a guarda de terceiros (que é o que normalmente ocorre). 1.3 Ambientes hostis Em muitos tipos de aplicação (como por exemplo comércio eletrônico) todos que têm acesso à infraestrutura incluindo o usuário final podem ser considerados 6

8 adversários. Neste cenário todo o ambiente deve ser considerado hostil. 7

9 Capítulo 2 Processadores seguros ou invioláveis A seção 1.2 descreveu algumas das ameaças aos sistemas existentes hoje. Um processador inviolável que também pode ser chamado de (co)processador 1 seguro (secure coprocessor) HSMs (High Security Machines ou High Security Modules) é essencialmente um dispositivo que tem como objetivo ajudar a endereçar aquelas ameaças e permitir a execução de cálculos apesar das tentativas de adulteração perpetradas pelos adversários. Normalmente são utilizados para armazenar e processar informações sensíveis (chaves, senhas etc). Se as informações de um banco de dados, por exemplo, estiverem criptografadas adequadamente não é necessário armazenar todas os dados num processador seguro, apenas as chaves que permitem acesso às informações. 2.1 Arquitetura A figura 2.1 (extraída de [13] mostra um dispositivo genérico. Uma fronteira segura protege a CPU e a memória. Um subconjunto da memória é especificado como seguro. O projeto físico tem como objetivo assegurar que tentativas de penetrar no dispositivo ou adulterá-lo resultará na destruição dos dados da memória segura. Esta memória segura permite aplicações seguras. Por exemplo, uma chave privada colocada nesta memória permite que o dispositivo atue como uma testemunha confiável, já que uma parte remota pode confiar que uma mensagem assinada corretamente por esta chave deve ter sido produzida por um dispositivo intacto. Este modelo pode ser estendido para prover segurança para uma aplicação inteira. A eficácia de um tal processador como uma ferramenta para construir aplicações seguras depende da eficácia da sua proteção de memória e da sua capacidade 1 não faremos a distinção entre processador e coprocessador neste trabalho, visto que os objetivos e configuração destes são bastante semelhantes 8

10 Figura 2.1: Arquitetura hardware típica de um processador seguro computacional. Além disso ele requer algumas propriedades adicionais: executar apenas os programas que deve executá-los sem interferências permitir que se distinga um programa real de um que tenta se passar por ele, mesmo que o processador seguro esteja a milhares de quilômetros Tipicamente os processadores seguros incorporam criptografia de alto desempenho mas não basta a eles serem processadores criptográficos já que outras operações além de criptografia são executadas lá. 2.2 Operação A operação dos processadores seguros geralmente requer uma senha ou chave para que possam ser programados e para que certas operações sejam autorizadas. Em alguns casos (e.g. IBM 4758) o próprio processador gera uma chave interna e em outros o fabricante fornece esta chave, que deve ser usada posteriormente para acesso ao dispositivo. Uma discussão maior sobre a inicialização de um dispositivo pode ser encontrada em [14], que enfoca o caso do IBM Freqüentemente os processadores são também colocados em um ambiente fisicamente seguro, que pode incluir mecanismos sofisticados (controles biométricos, por exemplo) para permitir o acesso físico ao dispositivo. 9

11 2.3 Como os processadores respondem a ameaças Disponibilizando poder computacional mas resistindo e reagindo a ataques físicos, um processador seguro de alto desempenho é ideal para prover segurança em ambientes hostis: O processador em um ambiente hostil pode executar a parte da aplicação que deve ser protegida de adversários O dispositivo é suficientemente poderoso para que estas operações sejam razoavelmente complexas Um atacante que tentar modificar esta operação disparará a resposta à intrusão Um atacante que desmontar o dispositivo não descobrirá nenhum segredo Com um software adequado, um tal dispositivo pode ser uma ferramenta para endereçar as ameaças descrita em 1.2. [12] discute em mais detalhes possíveis aplicações para um tal processador. Alguns exemplos de aplicação são mostrados na seção Máquinas e circuitos vulneráveis Processadores seguros são projetados para poderem ser colocados em ambientes fisicamente expostos. Vândalos podem atacar à vontade mas não serão capazes de encontrar segredos dentro dos processadores (se estes forem capazes de responder a tentativas de intromissão ou adulteração). Tampouco serão capazes de carregar software falso no processador. O dispositivo irá apagar os seus segredos e se desligar em caso de tentativa de penetração no empacotamento resistente a intromissão para descobrir segredos ou interferir na execução. O projeto de segurança física ([14]) geralmente contempla as seguintes possibilidades: evidência de adulteração (tamper evidence), quando o empacotamento força a (tentativa de) adulteração a deixar mudanças físicas indeléveis resistência a adulteração (tamper resistance), quando o empacotamento do dispositivo torna a adulteração difícil deteção de adulteração (tamper detection), quando o dispositivo toma conhecimento da adulteração 10

12 resposta a adulteração (tamper response), quando o dispositivo toma medidas como resposta à adulteração A deteção de penetração fisica pode ser feita, por exemplo, através de uma rede de condutores envolvendo o dispositivo. Em geral esta rede está recoberta por um outro material semelhante (para dificultar a deteção da rede de proteção) e, nos dispositivos capazes de responder à tentativa de adulteração, dispara as operações apropriadas quando rompida Erros de software Os processadores seguros oferecem isolamento (tanto de hardware quanto de software) entre as aplicações e entre o sistema operacional e as aplicações. (Em alguns casos é necessário proteger certas regiões de memória até do sistema operacional). Desta forma, uma aplicação executando dentro de um processador seguro não consegue causar dano a outra que esteja no mesmo processador. Nem o sistema operacional consegue danificar o microcódigo ou a sua área de armazenamento protegida dentro do processador. A ameaça de comprometer a criptografia pode ser tratada pelo suporte em hardware para operações básicas (como uma fonte hardware para aleatoriedade) e autenticação da configuração de software Empregados, subcontratados e clientes desonestos Os processadores podem ser usados para verificar os direitos de acesso a dados sensíveis tanto dos empregados quanto dos clientes. Além disso, graças à possibilidade de programar o processador, os controles de acesso podem ser razoavelmente complexos como, por exemplo, estabelecer limites de dia, hora, dia da semana etc Cópias de segurança e recuperação de desastres Como tornam possíveis a criptografia de dados sensíveis em alta velocidade, os processadores podem ser usados para operações de cópia de segurança. As chaves também podem ser armazenadas em mais de um processador seguro ao redor do mundo e acessadas apenas em condições adequadas. Desta forma os empregados nas localidades remotas vêem apenas dados criptografados, o texto em claro aparece apenas em uma recuperação autorizada. 11

13 2.4 Principais aplicações Segurança de PKI e aplicações seguras Com o aumento da demanda por segurança e privacidade, mais e mais aplicações utilizam criptografia na forma de PKI (Public Key Infrastructure Infraestrutura de Chave Pública), certificados digitais, assinaturas eletrônicas, encriptação de conteúdo, confirmação de identidade, autenticação, não repudiação, etc. Ao mesmo tempo em que estas aplicações de segurança são críticas para proteção da informação, elas mesmas correm risco se são protegidas apenas por software: as chaves confidenciais podem ser extraídas dos servidores e o software da aplicação pode ser modificado e corrompido. Com um aumento no número de aplicações que estão sendo automatizadas ou colocadas em terminais remotos, é essencial não somente que as chaves confidenciais estejam seguras dos usuários autorizados, mas também que ninguém consiga violar o código que controla as aplicações criticas Encriptação segura Para dados enviados através de um canal SSL (Secure Socket Layer) que precisam ser encriptados no seu destino existe o risco de comprometimento destes dados. Afinal os dados vão chegar como texto claro no servidor. Existe uma solução de HSM para ser colocada em uma conexão SSL de modo que os dados já deixem o equipamento corretamente encriptados, não havendo o risco de contaminação ou roubo da informação Máquinas de pagamento seguras (PIN) e processamento de senhas Informações confidenciais são colocadas nesta máquina, como informações do cartão de crédito e da senha dos usuários. É muito importante que este tipo de hardware seja seguro e tenha proteção contra roubo de informações. E as informações devem ser armazenadas e enviadas criptografadas Autenticação segura de usuários Os servidores que fazem a validação de acesso de usuário a um determinado sistema podem ser facilmente invadidos e as senhas dos usuários capturadas. O ideal é utilizar uma solução HSM para isso, deste modo o HSM pode ter uma cópia encriptada das chaves e através de comparação validar ou usuário ou não. E ainda tem-se a garantia que as informações não serão roubadas ou corrompidas. 12

14 Figura 2.2: Terminal para autenticação segura de usuários Autoridades Certificadoras A falha na proteção das chaves privadas da raiz da Autoridade certificadora (que é o coração da sua infra-estrutura de PKI), põe em risco toda a infra-estrutura da Autoridade Certificadora. Existem HSMs específicos para serem usados para proteger a integridade das chaves privadas de Autoridades Certificadoras, esses HSMs fornecem soluções para PKI e Gerenciamento Avançado de chaves Aceleradores de Transações Com a expansão das aplicações PKI a cada nova transação uma requisição de validação é feita, isso criou um sério gargalo nas transações. Existe uma solução de HSM para prover mais de 20 vezes mais assinaturas por segundo do que um servidor comum e ainda a solução em HSM tem o compromisso da proteção das chaves privadas, que o servidor não tem. É geralmente usado junto com um servidor. Comunicação Segura Uma comunicação segura entre os diversos componentes de uma infra-estrutura empresarial é tão importante quanto a segurança das aplicações em si. HSM usado conjuntamente com canais SSL fornece essa segurança necessária Assinaturas Digitais A assinatura digital fornece uma maneira padronizada e garantida de se fazer transações comercias pela Internet. Este novo tipo de prática deve envolver equipamentos que garantam que aquela assinatura é somente daquele usuário e que esta assinatura não será roubada. Pode- se usar um HSM na base de dados que armazenará a assinatura e o usuário pode usar um HSM (smart card) para carregar consigo a sua assinatura. 13

15 2.4.8 Informação correta de tempo O tempo real é uma informação vital para várias aplicações, como processos bancários on-line, negociações de contratos, mercados de ações. Uma informação segura e autêntica do tempo pode ser provida por um hardware HSM Distribuição de conteúdo Digital Um HSM também pode ser usado para validar as licenças do usuário, garantir que somente os usuários que possuam a autorização vão receber o conteúdo e para garantir a correta criação das licenças. 2.5 As famílias de processadores seguros Os dispositivos genericamente descritos como processadores seguros podem se enquadrar em diversas categorias e representam compromissos diferentes entre segurança, capacidade computacional e criptográfica e custo. Descrevemos abaixo as principais famílias (de acordo com a taxonomia utilizada em [13]) Chip Card O membro menos poderoso da família é o smart card2 (também conhecido com chip card). Um smart card típico de hoje inclui um pequeno processador de 8 bits, 512 bytes de RAM, 8 Kbytes de ROM, 8 Kbytes de EEPROM e um acelerador de hardware para operações criptográficas. Estes dispositivos precisam ser programados na fábrica uma vez que o seu software é colocado de forma permanente na ROM quando os chips são fabricados. Como o espaço de memória é muito limitado o software é geralmente feito em linguagem de máquina otimizada. Smart cards oferecem deteção limitada de ataques físicos. Entretanto, a resposta a estes ataques depende de o dispositivo estar alimentado ou não. A resposta quando o cartão está inserido em uma leitora, por exemplo, pode ser muito diferente da resposta a um ataque quando ele está sem alimentação em uma bancada do atacante. Sem alimentação o dispositivo é incapaz de apagar os dados sensíveis armazenados na EEPROM. Mesmo que haja alimentação apagar os dados em uma janela de tempo limitada é pouco provável ou mesmo impossível. A proteção contra ataques lógicos é limitada. Os processadores nestes cartões geralmente não têm a combinação entre modo supervisor e proteção de hardware para regiões de memória, que é um elemento essencial para impedir que uma aplicação acesse a memória de outra. Isto é normalmente controlado através da 14

16 inspeção cuidadosa das aplicações que coexistirão no mesmo cartão. Uma outra limitação é a velocidade de entrada e saída da interface serial do cartão tipicamente limitada a 9600 bits/segundo. As vantagens principais do cartão são o baixo custo, a portabilidade e a robustez física Personal Tokens Um Personal Token, como um cartão PCMCIA ou smart button é o próximo na escala de capacidades de desempenho criptográfico. Em muitos casos é simplesmente um reempacotamento de um chip card com mais espaço de memória, bateria ou proteções maiores. No outro fim da escala ele pode ter muitas das características dos aceleradores criptográficos e/ou processadores seguros de alto desempenho. Estes cartões são freqüentemente resistentes a adulteração e, em alguns casos, têm características de evidenciar a adulteração ou mesmo responder a ela. O dispositivo típico é capaz de desempenhar funções como autenticação, criptografia de arquivos e armazenado de segredos fora do host. A maioria dos cartões PCMCIA disponíveis são dispositivos com função pré-definida e não são programáveis, embora alguns ofereçam alguma capacidade de programação quando acordado com o fabricante Aceleradores criptográficos Os aceleradores criptográficos tipicamente incluem um microprocessador pequeno (ARM7, por exemplo), uma quantidade razoável de memória (EEPROM de 2 megabytes, RAM de 512K) e chips para incrementar o desempenho critográfico. O propósito principal de tais dispositivos é acelerar operações criptográficas enquanto oferece um certo grau de proteção física às chaves. Esses dispositivos são freqüentemente resistentes à adulteração mas raramente são capazes de responder a uma tentativa de adulteração. (Por exemplo, o seu empacotamento pode ser difícil de abrir mas não apaga dados sensíveis se são abertos) Normalmente não são programáveis pelo cliente final mas podem receber uma programação especial do fabricante para clientes que compram em alto volume Processador seguro de alto padrão O dispositivo mais sofisticado da família é um processador de alto desempenho, com um microprocessador poderoso, megabytes de RAM e memória FLASH, chips para incrementar o desempenho criptográfico, relógio para manter a hora 15

17 corrente e um gerador de números aleatórios implementado em hardware, tudo isso em um empacotamento capaz de responder a tentativas de adulteração. As dificuldades práticas para construir um tal processador são discutidas em [13]. 16

18 Capítulo 3 Estudo de caso 3.1 Autoridades certificadoras Descrição do problema Conforme indicado na seção 2.4.5, a segurança da chave é crítica para uma autoridade certificadora. A chave privada da autoridade certificadora é utilizada para assinar as chaves públicas dos portadores de certificados e, além disso, assinar a própria chave pública da autoridade certificadora. Se esta chave for comprometida, todos os certificados emitidos pela autoridade tornar-se-ão suspeitos e a sua credibilidade será arruinada. A guarda desta chave é uma das principais aplicações de um processador seguro. Em geral as autoridades certificadoras utilizam equipamentos com certificação FIPS nível 3 ou maior para armazenamento e geração de chaves Requisitos da solução Alguns pontos importantes a considerar na montagem de uma infraestrutura para armazenamento de chaves são os seguintes: Geração de chaves todas as chaves privadas são geradas em um dispositivo seguro? Armazenamento de chaves todas as chaves privadas são armazenadas em um dispositivo seguro 100% do tempo? Cópia de segurança de chaves as chaves privadas são copiadas de um dispositivo com segurança FIPS nível 3 para outro dispositivo idêntico? Assinatura de certificados todos os certificados são assinados dentro do dispositivo seguro 100 % das vezes? 17

19 Tráfego da chave raiz o tráfego ou cópia de segurança da chave raiz não deve expor a chave em claro Acesso ao módulo seguro acesso ao módulo de segurança que armazena a chave deve exigir autenticação forte e/ou controle de acesso compartilhado do tipo m/n, onde m > 2 e n > 4 (por exemplo, 3/5). Segurança física ataque físico ao módulo deve desabilitar as funções criptográficas e destruir as chaves Solução utilizando processador seguro Um processador seguro pode ser usado para armazenar a chave privada raiz mantendo-a segura durante todo o tempo. Este mesmo processador pode comunicarse com outros para receber as chaves públicas e gerar os certificados sem passar a chave privada em claro para fora do perímetro de segurança do processador. Para cópia de segurança o ideal é que a chave seja criptografada e dividida em vários pedaços, de forma que ninguém tenha sozinho a posse de todas as partes necessárias para reconstituir a chave caso o processador seguro seja destruído ou violado Vantagens Uma solução utilizando processadores seguros apresenta várias vantagens em relação a uma solução que considere apenas software e barreiras físicas: hardware talvez seja menos suscetível a falhas e adulterações de sistema como vírus o conteúdo do dispositivo pode ser copiado para outro dispositivo igualmente seguro, possibilitando a recuperação de falha e mantendo a segurança pode-se exigir uma senha para ativar a chave privada, o que aumentaria a segurança do módulo hardware provê segurança melhor do que meios de armazenamento removíveis, como fitas, disquetes etc o custo de barreiras físicas (cofres, entradas seguras etc) pode ser proibitivo para utilizações em autoridades certificadoras menores (de uma universidade, por exemplo) 18

20 cópias de segurança da chave podem levar à existência de cópias múltiplas e não-controladas da chave, não havendo como assegurar que a chave não foi copiada indevidamente o hardware pode ser usado para controlar quantas cópias das chaves existem e onde elas se encontram. A figura 3.1 (extraída de [10]) mostra a diferença entre as duas alternativas: Figura 3.1: criptografia baseada em hardware versus software É importante lembrar também que como em qualquer situação, a utilização de práticas organizacionais adequadas é tão importante quanto os mecanismos de segurança oferecido pelo hardware e software. 19

21 Capítulo 4 Padronização e Certificação O documento Requisitos de segurança para módulos criptógraficos ([11]), que faz parte do conjunto de padrões do FIPS (Federal Information Processing Standard) emitidos pelo NIST (National Institute of Standards and Technology) também conhecido como FIPS é a forma mais utilizada para avaliação de segurança de módulos criptográficos. O Critério Comum (Common Criteria) ([8]) é um padrão para avaliação de segurança de tecnologia da informação que foi desenvolvido conjuntamente por vários países (Alemanha, Canadá, Estados Unidos, França, Holanda, Reino Unido) e está alinhado com a norma ISO 15408:1999. Vários aspectos do FIPS estão baseados no Critério Comum 4.1 Objetivos Funcionais de Segurança De acordo com o FIPS ([11]), os objetivos de segurança para um módulo criptográfico são: Empregar e implementar corretamente as funções de segurança para a proteção de informação sensível Proteger um módulo criptográfico de uso ou operação não autorizados Evitar a revelação não autorizada dos conteúdos do módulo criptográfico, incluindo chaves criptográficas em claro e CSPs (Critical Security Parameters - Parâmetros Críticos de Segurança). Evitar a modificação não autorizada e não detectada do módulo criptográfico e algoritmos criptográficos, incluindo a modificação, substituição, inserção e remoção de chaves criptográficas e CSPs. Fornecer indicações do estado operacional do módulo criptográfico 20

22 Assegurar que os módulos criptográficos operem apropriadamente quando funcionando em um modo de operação aprovado. Detectar erros na operação dos módulos criptográficos e evitar o comprometimento de dados sensíveis e CSPs resultantes desses erros. 4.2 Especificação do módulo criptográfico Para [11] um módulo criptográfico deve ser um conjunto de hardware, software, firmware, ou de alguma combinação que implemente funções criptográficas ou processos, incluindo algoritmos criptográficos e, opcionalmente, geração de chave e estejam contidos dentro de um limite criptográfico definido. Um módulo criptográfico deve executar ao menos uma função aprovada de segurança usada em um modo de operação aprovada. As funções de segurança não aprovadas podem também ser incluídas para o uso em modos de operação não aprovados. O operador deve ser capaz de determinar quando um modo de operação aprovada é selecionado. Para os níveis 1 e 2 de segurança, a política de segurança do módulo criptográfico pode especificar quando um módulo criptográfico está executando em um modo de operação aprovada. Para os níveis 3 e 4 de segurança, um módulo criptográfico deve indicar quando um modo de operação aprovado é selecionado. Um limite criptográfico consistirá em um perímetro explicitamente definido que estabeleça os limites físicos de um módulo criptográfico. Se um módulo criptográfico tiver componentes de software ou firmware, o limite criptográfico deve conter o processador e outros componentes de hardware que armazenam e protegem os componentes de software e firmware. O hardware, o software, e o firmware de um módulo criptográfico podem ser excluídos das exigências deste padrão se estes componentes não afetam a segurança do módulo. 4.3 Critério comum As principais recomendações do critério comum estão descritas nas seções a seguir Projeto Modular Um projeto modular é recomendado, especialmente para softwares desenvolvidos em larga escala. Cada módulo do software deve ter interfaces lógicas e bem definidas que possam ser prontamente compreendidas. 21

23 Os componentes do software devem ser construídos usando os princípios de abstração dos dados. Se possível, usar uma linguagem de alto nível, orientada a objetos, que suporte a construção de tipos de dados abstratos. O software deve ser estruturado hierarquicamente em várias camadas Módulos do Software - Interfaces e procedimentos As entradas para um software modular ou um procedimento devem utilizar chamadas em rotinas explicitamente definidas na interface. Cada procedimento deve ter somente um ponto de entrada e pelo menos dois pontos de saída, um para saídas normais e um para saídas de erro. Os dados que precisam ser transmitidos entre os módulos do software ou entre procedimentos devem ser transmitidos com o uso de listas de argumento e/ou valores de retorno explícitos. Variáveis globais não devem ser usadas entre os procedimentos exceto onde for necessário para a implementação de tipos de dados abstratos. Os valores da entrada devem ser verificados para ver se há erros de escala de modo que se forem inválidos o programa retorne uma mensagem de erro e nenhum dano mais grave possa ser causado Construção Interna Cada procedimento deve executar somente uma única função bem definida. O fluxo de controle usando um único thread deve ser definido usando somente condicionais para programação estruturadas (por exemplo, if-thenelse ou case) e construções de laços para programação estruturada (por exemplo, while-do ou repeat-until). Se a execução simultânea for implementada (por exemplo, múltiplos threads, tarefas, ou processos), os componentes do software devem ter limites bem definidos para o grau máximo de concorrência permitido e devem usar construções estruturadas para sincronização e controle de acesso dos dados compartilhados. A equivalência das variáveis não deve ser usada de modo a não permitir o uso múltiplo da memória. Desse modo evitam-se conflitos entre múltiplos processos. 22

24 A análise e o parser são mecanismos que devem ser implementados para se ter uma proteção contra requisições malformadas, fora da escala ou buffer overflow da entrada ou saída Documentação do código Cada módulo, procedimento, e estruturas principais do software devem ser documentados especificando as funções executadas junto com a especificação (formal ou informal) de todas as pré-condições e pós-condições. Cada laço deve ser precedido por um argumento que explique o critério de parada. Os nomes das variáveis devem ser usados somente dentro do mesmo procedimento onde elas foram declaradas. Cada variável deve ter um comentário associado a ela para identificar a sua finalidade e a escala de valores permissíveis, incluindo se a escala for irrestrita. Se a concorrência for implementada, a documentação deve especificar quais os limites e o grau máximo permitido de concorrência e como os acessos aos dados compartilhados são sincronizados a fim de evitar erros durante a execução Linguagem Assembly As seguintes práticas de programação devem ser usadas quando a implementação está na linguagem assembly: Todo o código deve ter posição independente à não ser onde a segurança, a eficiência, ou os requisitos de hardware exijam dependência da posição. Todas as referências aos registradores devem usar nomes simbólicos para eles. Códigos auto-modificáveis não devem ser usados. Todos os procedimentos devem ser responsáveis por salvar e restaurar o conteúdo dos registradores que forem usados dentro do procedimento. As instruções de transferência de controle não devem usar números literais. Cada unidade deve conter os comentários que descrevem qual registrador está sendo usando na unidade. 23

25 4.4 Níveis de avaliação de acordo com o Critério Comum De acordo com o Critério Comum ([8]), o Alvo da Avaliação (TOE Target of Evaluation) é a parte de um produto ou sistema que é alvo de avaliação. A segurança TOE cuida dos objetivos, requisitos e especificação das funções de segurança de um produto. Toda esta documentação junta gera o Alvo da Segurança ou ST (Security Target) e este documento é usado pelos auditores como base para fazer uma auditoria de segurança sobre um determinado produto EAL1 EAL1 é aplicável onde alguma confiança em uma operação segura é requerida, mas as ameaças à segurança não são vistas como sérias. EAL1 fornece um nível básico de garantia através da análise das funções de segurança usando uma especificação funcional das interfaces e documentação do comportamento seguro do produto. Para produtos certificados com nível EAL1 que contêm criptografia, uma avaliação criptográfica completa não foi feita. Para estes produtos, o mínimo avaliado é que os algoritmos criptográficos usados no produto são apropriados, entretanto, a exatidão de sua implementação não foi avaliada. A avaliação EAL1 fornece um aumento significativo na garantia do produto se comparado com um produto ou sistema não avaliado. Entretanto, EAL1 não é mais do que um exame de verificação do produto que requer um mínimo de documentação EAL2 EAL2 é aplicada nas circunstâncias onde os desenvolvedores ou usuários precisam de um nível moderado de segurança assegurada, mesmo quando eles não dispõem da documentação completa sobre o desenvolvimento. Tal situação pode ser aplicada a sistemas legados ou onde o acesso ao desenvolvedor pode ser limitado. EAL2 fornece garantia através da análise das funções de segurança, usando uma especificação funcional, a especificação da interface, a documentação guia do produto e a documentação alto nível do TOE. Com esses documentos pode-se fazer uma análise do comportamento seguro do produto. Este nível de EAL fornece um aumento significativo na garantia do EAL1 devido a exigência de testes durante o desenvolvimento, uma análise de vulnerabilidade e testes independentes baseados nas especificações mais detalhadas TOE. 24

26 4.4.3 EAL3 EAL3 é aplicável naquelas circunstâncias onde os desenvolvedores ou usuários precisam de um nível moderado de segurança e exigem uma investigação completa do TOE e do desenvolvimento do produto sem o uso de reengenharia. EAL3 fornece garantia através da análise das funções de segurança, usando uma especificação funcional, a especificação da interface, a documentação guia do produto e a documentação alto nível do TOE. Com esses documentos pode-se fazer uma análise do comportamento seguro do produto. Este nível de EAL fornece um aumento significativo na garantia do EAL2 devido a exigência da cobertura completa de todas as funções de segurança e dos mecanismos e/ou procedimentos que fornecem garantia de que o TOE não sofrerá violação ou adulteração durante o desenvolvimento EAL4 EAL4 é aplicável naquelas circunstâncias onde os desenvolvedores ou usuários precisam de um nível elevado de segurança nos TOE convencionais do produto e podem exigir segurança adicional não coberta nos aspectos da segurança dos TOEs. EAL4 fornece garantia através da análise das funções de segurança, usando uma especificação funcional, a especificação da interface, a documentação guia do produto e a documentação alto nível do TOE. Além desses documentos uma analise da política de segurança e do modelo informal do TOE também é exigida. Este nível de EAL fornece um aumento significativo na garantia do EAL3 exigindo uma descrição detalhada do projeto, um subconjunto da implementação e os mecanismos e/ou procedimentos melhorados que fornecem a garantia de que o TOE não será alterado ou violado durante o desenvolvimento ou a entrega. 4.5 Níveis de segurança de acordo com FIPS As seções a seguir descrevem os níveis de segurança de acordo com o padrão FIPS ([11]) Nível 1 O nível 1 fornece o nível mais baixo de segurança. As exigências básicas de segurança são especificadas para um módulo criptográfico (por exemplo, ao menos um algoritmo aprovado ou uma função de segurança aprovada devem ser usados). Nenhum mecanismo físico específico de segurança é obrigatório em um módulo 25

27 criptográfico de nível 1 além da exigência básica para componentes de produção em série. Um exemplo de módulo criptográfico com nível 1 é uma placa de encriptar para PC. O nível 1 permite a componentes de software e firmware de um módulo criptográfico serem executados em um sistema computacional de propósito geral que usa um sistema operacional não avaliado. Esta implementação pode ser apropriada para algumas aplicações que necessitem de baixo nível de segurança quando outros controles, tais como segurança física, segurança de rede, e procedimentos administrativos são limitados ou inexistentes. A implementação de um software criptográfico pode ser uma solução mais viável economicamente nestes casos do que uma solução baseada em hardware. A solução de software criptográfico permite as organizações uma solução barata para sistemas que não necessitem de altos níveis de segurança Nível 2 O nível 2 melhora os mecanismos físicos de segurança de um módulo criptográfico de nível 1 adicionando o requisito de evidência de intrusão no sistema. Isto inclui o uso de revestimentos ou de selos que evidenciem a violação e também o uso de travas que dificultem toda e qualquer remoção de tampas ou portas removíveis do módulo. Os revestimentos e selos que evidenciam a violação são colocados em um módulo criptográfico de modo que o revestimento ou o selo possa ser quebrado para se ter acesso físico às chaves criptográficas e aos parâmetros críticos de segurança (CSPs) dentro do módulo. Os selos e os fechamentos que evidenciam a intrusão são colocados nas tampas ou nas portas para proteger o módulo de um acesso físico não autorizado. O nível 2 requer, no mínimo, a autenticação baseada em papéis onde o módulo criptográfico autentica a autorização de um operador. Desse modo cada usuário do modulo só pode executar as funções autorizadas para o seu papel. O nível 2 permite a componentes de software e firmware de um módulo criptográfico serem executados em um sistema computacional de propósito geral que: Atende as exigências funcionais especificadas nos Perfis de Proteção (PP) do Critério Comuns (CC). É avaliado pelo CC no nível de garantia EAL2 ou superior. Usa um sistema operacional avaliado que possui segurança equivalente. Um sistema operacional confiável provê um nível de confiança de modo que os módulos criptográficos que executam nestas plataformas computacionais 26

28 sejam comparáveis aos módulos criptográfico que executam em sistemas de hardware dedicados Nível 3 Além dos mecanismos físicos de evidência de intrusão requeridos no nível 2, o nível 3 tenta impedir que o intruso ganhe acesso aos parâmetros críticos de segurança (CSPs - Critical Security Parameters) que ficam escondidos dentro do módulo criptográfico. Os mecanismos físicos de segurança requeridos no nível 3 devem ter uma probabilidade elevada de detectar e de responder às tentativas de acesso, uso ou na modificação física do módulo criptográfico. Os mecanismos físicos de segurança podem incluir o uso de vedações fortes e de circuitos que respondam a tentativas de intrusão ou modificação. Estes circuitos quando detectam a intrusão tem como função zerar ou destruir os CSPs. O nível 3 requer mecanismos de autenticação baseados em identificação, isso aumenta a segurança fornecida pelos mecanismos de autenticação baseados em papeis especificados para o nível 2. O módulo criptográfico autentica a identidade de um operador e depois verifica que o operador identificado está autorizado a desempenhar um papel específico o que corresponde a algumas funções e serviços que ele pode executar. O nível 3 requer que a entrada ou a saída dos parâmetros CSPs (esses parâmetros saem em texto claro, ou seja, não criptografados) seja executada usando portas que são separadas fisicamente das outras portas, ou interfaces que são separadas logicamente das outras interfaces e que usam um trajeto confiável. Os parâmetros CSPs em texto claro podem ser incorporados ou retirados do módulo criptográfico de modo encriptado (neste caso podem viajar através de sistemas fechados ou protegidos). O nível 3 permite à componentes de software e firmware de um módulo criptográfico serem executados em um sistema computacional de propósito geral onde: O Sistema atende as exigências funcionais especificadas no critério comum mais a exigência extra de um trajeto confiável (FTA_TRP.1 Trusted Path) significa que os dados possam passar por este caminho sem serem observados por outras partes do sistema. O Sistema é avaliado no nível EAL3 da garantia do Critério Comum. O Sistema atenda a exigência adicional (ADV_SPM.1 Security policy modeling) do TOE. 27

29 Um sistema operacional confiável pode ser usado. Deve somente ter um trajeto confiável para proteger os parâmetros CSPs em modo claro e os componentes do módulo criptográfico devem estar protegidos contra o software ou o firmware que não sejam confiáveis Nível 4 O nível 4 fornece o nível mais elevado de segurança definido neste padrão. Neste nível de segurança, os mecanismos físicos de segurança fornecem um envelope de proteção completo em torno do módulo criptográfico com a intenção de detectar e de responder a todas as tentativas não autorizadas de acesso físico. A penetração do cerco do módulo criptográfico tem uma probabilidade muito elevada de ser detectada, tendo por resultado a remoção imediata (todos os parâmetros são zerados) dos valores dos parâmetros CSPs em modo claro. Os módulos criptográficos de nível 4 são úteis para a operação em ambientes fisicamente desprotegidos. O nível 4 também protege o módulo criptográfico contra as variações das condições ambientais ou contra flutuações de temperatura e voltagem fora da escala de operação normal do módulo. Estas incursões intencionais fora das escalas normais podem ser usadas por um atacante para derrubar as defesas de um módulo criptográfico. Para um módulo criptográfico de nível 4 é requerido incluir características especiais de proteção projetadas para detectar flutuações e condições climáticas rigorosas. Este módulo deve ter proteção e no caso de ser submetido a uma situação extrema as informações dos CSPs devem ser apagadas como acontece no caso de intrusão. O nível 4 permite a componentes de software e firmware de um módulo criptográfico serem executados em um sistema computacional de propósito geral onde: O sistema atende todas as exigências pro nível 3. Atende as exigências do nível EAL4 do CC. 4.6 Requisitos de segurança Os requisitos de segurança cobrem as áreas relacionadas ao projeto e à implementação de um módulo criptográfico. Estas áreas incluem: A especificação do módulo criptográfico; 28

30 As portas e as interfaces do módulo; Papéis, serviços, e autenticação; Modelo de estado finito; Segurança física; Ambiente operacional; Gerência de chave criptográfica; Compatibilidade a interferências eletromagnética (EMI/EMC); Testes e garantia do projeto. A tabela abaixo sumariza as exigências de segurança em cada uma destas áreas (MC significa Módulo Criptográfico): Tabela 4.1: Resumo das exigências de segurança do padrão FIPS Especificação do MC Portas e Interfaces do MC Papéis, serviços e autenticação Modelo de Estados Finitos Segurança Física Nível 1 Nível 2 Nível 3 Nível 4 Especificação do MC, fronteiras Criptográficas, Algoritmos aprovados e modos aprovados de operação. Descrição do MC incluindo todos os módulos de hardware, firmware e software. Especificação de todas as interfaces e de todos os caminhos de entrada e da saída de dados. Portas de Dados para parâmetros críticos de segurança devem ser separados fisicamente das outras portas de dados. Separação lógica Autenticação de Autenticação de operadores baseada de papéis e serviços requeridos e opcionais. operadores baseada em papéis ou identidade. em identidade. Especificação do modelo de estados finitos. Estados requeridos e estados opcionais. Indique o diagrama de transição e a especificação de transições de estado. Equipamento Comum. Revestimentos ou selos que evidenciem a violação. Detecção de violação e resposta a violação. Detecção de violação e resposta a violação. Envelopamento das chaves criptográficas. Proteção eletromagnética, contra variação de temperatura e tensão. continua na próxima página 29

31 continuação da página anterior Gerenciamento de Chave Criptográfica Ope- Ambiente racional Nível 1 Nível 2 Nível 3 Nível 4 Operador Único. AEL2 mecanismo AEL3 mais mo- Código executável. de controle delo de política Técnica de acesso. de segurança. aprovada de integridade. Mecanismos de gerência de chaves: geração do número aleatório e da chave, estabelecimento de chave, distribuição da chave, entrada e saída da chave, armazenamento da chave, e remoção da chave em caso de intrusão. As chaves secretas e confidenciais estabelecidas usando métodos manuais podem ser inseridas ou retiradas no formato de texto claro. EMI/EMC 47 CFR FCC Parte 15. Sub parte B, Classe A (Uso Comercial). Auto testes Garantia Projeto Do Proteção contra ataques AEL4 mais caminho seguro. As chaves secretas e confidenciais estabelecidas usando métodos manuais podem ser inseridas ou retiradas cifradas ou com procedimentos de divisão do conhecimento. 47 CFR FCC Parte 15. Sub parte B, Classe B (Uso Caseiro). Testes de potência, testes do algoritmo de criptografia, testes de integridade do software e firmware, testes das funções críticas e testes condicionais. Gerência de configuração CM Geração e instalação seguras. Projeto e policia correspondente. Documentos que garantam o projeto. Sistema CM. Distribuição Segura, especificação funcional Implementação em linguagens de alto nível. Especificação e proteção contra ataques para os requisitos disponíveis. Modelo formal. Explicações detalhadas (provas informais). Pré-condições e pós-condições Segurança física de acordo com o FIPS Um módulo criptográfico deve utilizar mecanismos físicos de segurança para impedir o acesso físico não autorizado ao conteúdo do módulo e deter o uso ou modificação não autorizados do módulo (substituições, inclusive do módulo inteiro) quando instalado. Todo o hardware, software, firmware, e componentes de dados dentro do limite criptográfico devem ser protegidos. Um módulo criptográfico que é implementado completamente em software de modo que a segurança física é feita unicamente pela plataforma do hardware utilizado não atende às exigências físicas de segurança deste padrão. As exigências físicas de segurança são especificadas para três tipos de módulo criptográfico: 30