• OS1. Geração do par de chaves: o sistema deve garantir que apenas utilizadores autorizados são capazes de gerar pares de chaves;
• OS2. Chave privada única: o sistema deve utilizar um algoritmo de geração de chaves adequado, que garanta que as chaves privadas geradas nunca se repitam;
• OS3. Correspondência entre as chaves pública e privada: o sistema deve garantir a correspon-
4.11. OBJETIVOS DE SEGURANÇA
dência entre as chaves pública e privada;
• OS4. Proteção da chave privada: a confidencialidade e a integridade da chave privada devem ser asseguradas.
• OS5. Segurança criptográfica da assinatura digital: o sistema deve criar assinaturas que não sejam possíveis de reproduzir sem o conhecimento da chave privada; a chave privada não pode ser reconstruída a partir das assinaturas ou de quaisquer dados;
• OS6. Função de criação de assinatura para o legítimo signatário: o sistema deve limitar a geração de assinaturas ao legítimo proprietário da chave, impedindo que terceiros utilizem diretamente a chave privada de um signatário na função de criação de assinaturas.
• OS7. Integridade do documento a assinar: o sistema deve garantir que o documento não é modifi- cado, desde que este é enviado para o sistema até que a assinatura é aposta ao mesmo, de forma a garantir que o documento que é enviado pelo signatário é aquele que é efetivamente assinado no dispositivo criptográfico. É necessário ainda garantir a integridade da representação do docu- mento, visto que a assinatura é gerada sobre esta representação. A integridade quer do documento, quer da sua representação garantem que as assinaturas são geradas sobre os dados pretendidos. • OS8. Deteção e resistência face a ataques: o sistema deve ser capaz de detetar tentativas de instru-
são e manipulação, físicas e eletrónicas, dos seus componentes, e de dar uma resposta apropriada face a essas tentativas, oferecendo resistência e proteção dos componentes ou dados.
• OS9. Registo de todas as interações com o sistema: o sistema deve manter um registo, protegido contra modificações, de todas as operações efetuadas pelos utilizadores do sistema.
• OS10. Autenticação multifator do signatário: o sistema deve autenticar o signatário antes de lhe conceder o acesso à chave privada. A autenticação poderá ser baseada em algo que o signatário sabe, isto é, as credenciais da sua conta de utilizador, e os dados para a ativação da sua chave, obtidos a partir do token de segurança que o utilizador possui.
• OS11. Autenticação dos utilizadores: todos os utilizadores do sistema, incluindo os agentes de registo e os administradores, devem autenticar-se antes de desempenhar qualquer tarefa no sistema. • OS12. Separação de contas: o sistema deverá garantir que os utilizadores só serão capazes de
aceder às suas próprias contas e de utilizar apenas as suas chaves privadas.
• OS13. Replicação segura de informação: caso o sistema integre uma ou maisappliances, será
necessário implementar mecanismos para garantir a confidencialidade e a integridade da informação das contas dos utilizadores, incluindo das respetivas chaves, no processo de replicação periódico que irá ocorrer da replica primária para as alternativas.
• OS14. Autenticidade das chaves públicas: aACdeve verificar a integridade e a origem da chave
CAPÍTULO 4. SISTEMA DE ASSINATURA REMOTA
do certificado.
• OS15. Geração de certificados qualificados: o componente de geração de certificados gera certifi- cados qualificados que incluem os atributos necessários para conformidade com os requisitos legais (pelo menos o nome do signatário, a chave pública e a assinatura do provedor do serviço).
• OS16. Proteção do dispositivo criptográfico contra ataques: o dispositivo deve estar protegido contra ataques físicos e acessos não autorizados, quer físicos, quer através da rede, devendo para isso ser colocado numa área segura e na rede interna da organização, protegida por firewall(s). O administrador deve verificar periodicamente se o dispositivo sofreu ataques físicos e verificar se não foi instalado hardware ou software que possa comprometer a segurança do dispositivo. No caso da utilização de vários dispositivos, as réplicas devem situar-se nas mesmas instalações seguras e na mesma rede, de tal forma que a comunicação entre elas não saia da rede local.
• OS17. Configuração do dispositivo criptográfico: utilização de algoritmos de funções de hash e de assinatura de acordo com os standards existentes.
• OS18. Modo de operação seguro do dispositivo criptográfico: o sistema deve garantir que o dispositivo criptográfico se encontra num modo de operação correto e seguro, bem como assegurar que o dispositivo leva a cabo todas as operações criptográficas num ambiente protegido.
• OS19. Proteção dos dados de ativação da chave: a confidencialidade e a integridade dos dados de ativação da chave deverá ser assegurada pelo token de segurança.
• OS20. Gestão segura de tokens de segurança: a segurança dos processos de configuração e atri- buição dos tokens aos utilizadores deve ser garantida. Caso a conta de um utilizador seja cancelada, o token de segurança tem de ser desativado. O utilizador deve reportar ao provedor de serviços em caso de comprometimento do seu token.
• OS21. Validação dos dados de ativação da chave: o componente de autenticação deverá validar os dados de ativação submetidos pelo utilizador, derivando corretamente o valor que lhe permite fazer essa validação. O componente deverá assegurar a confidencialidade e a integridade dos dados de ativação. O resultado da validação deverá ser comunicado ao componente de geração de assinatura através de um protocolo seguro, para que seja concedida a autorização para a operação prosseguir. • OS22. Proteção do token de segurança: o token deverá possuir um identificador único, não pode
ser duplicado e deve implementar mecanismos tamper resistant.
• OS23. Disponibilidade: devem ser implementados mecanismos para que o sistema esteja sempre disponível. O sistema deve assegurar que não há perda de informação no caso de ocorrência de erros.
• OS24. Canais seguros: os componentes do sistema comunicam entre si a partir de canais seguros. Os utilizadores devem assegurar-se de que estabelecem uma ligação segura com o sistema.
4.11. OBJETIVOS DE SEGURANÇA
• OS25. Controlo de acessos: o acesso aos componentes do sistema tem de ser restrito a pessoas e componentes autorizados.
• OS26. Controlo de acesso à informação do utilizador: o sistema deve assegurar que a informação de cada utilizador armazenada na base de dados é acedida apenas pelo próprio utilizador (ou por componentes do sistema devidamente autorizados), e utilizada apenas nos processos de criação de assinatura do utilizador.
• OS27. Integridade da informação do utilizador: o sistema deve garantir que não é possível fazer alterações não autorizadas da informação do utilizador no sistema. Não deverá ser possível alterar a informação do token de segurança do utilizador, nem a informação da sua chave de assinatura.
Capítulo 5
Componentes do Sistema
Neste capítulo são apresentadas implementações concretas dos componentes identificados no capítulo anterior, explorando de que forma os mecanismos de segurança que disponibili- zam permitem alcançar os objetivos de segurança definidos para o sistema.
5.1 Dispositivo Criptográfico Seguro
Como vimos anteriormente, as chaves privadas de assinatura requerem proteção da sua confidenci-
alidade e da sua integridade [5]. O componente responsável por garantir essa proteção é o dispositivo
criptográfico seguro, que no contexto dos sistemas de assinatura remota, se concretiza numHSM.
OsHSMs garantem implicitamente as duas propriedades de segurança indicadas, visto que são dispo-
sitivos invioláveis. A geração de um par de chaves resulta na criação de objetos correspondentes às chaves pública e privada, sendo-lhes atribuído um identificador. Este identificador, único para cada par, poderia ser associado ao respetivo utilizador, e ser usado para obter a chave privada nas operações de assinatura. Neste caso, as chaves seriam armazenadas e utilizadas exclusivamente dentro do dispositivo.
No entanto, o armazenamento das chaves na memória segura dosHSMs torna-se um problema quando
existe um grande número de chaves, visto que os dispositivos têm uma capacidade de armazenamento
limitada. A solução mais natural seria criar um cluster de dispositivos, para aumentar a capacidade de
armazenamento, o que traria por acréscimo maior capacidade de processamento criptográfico. No entanto,
o elevado custo dosHSMs impede muitas vezes seguir este caminho.
A solução passa por exportar as chaves para uma base de dados, o que nos permite obter uma capaci- dade de armazenamento virtualmente ilimitada. Ao enveredar por esta opção temos de utilizar mecanismos de exportação adequados, que assegurem confidencialidade e a integridade das chaves privadas. Essas
duas propriedades podem ser obtidas recorrendo a esquemas de cifragem autenticada (authenticated en-
CAPÍTULO 5. COMPONENTES DO SISTEMA
[52]), ou então a partir da combinação de um esquema de cifra simétrica com umMessage Authentication
Code(MAC). Em particular, existe um algoritmo designado por key wrapping[53], baseado em cifragem
autenticada, que foi especialmente concebido para a proteção de chaves criptográficas. A chave simétrica
utilizada nas operações dekey wrappingtoma a designação dekey-encryption key(KEK).
Se aKEKutilizada for mantida numHSM, garantimos que as chaves nunca podem ser reconstituídas
fora dele, o que torna o esquema seguro.
Uma vantagem, que advém deste esquema, é o facto das chaves poderem ser carregadas emHSMs
onde esteja instalada uma mesmaKEK, o que aliado a mecanismos de balanceamento de carga, permite
distribuir os pedidos pelosHSMs pertencentes a um mesmo grupo, o que confere maior escalabilidade ao
sistema. Por outro lado, caso umHSMseja alvo de um ataque e aKEKseja eliminada, como consequência
dos mecanismos que lhe conferem tamper-resistance, as chaves de assinatura podem continuar a ser
utilizadas, visto que outrosHSMs do mesmo grupo são capazes de as reconstruir.
Ao nível do standard PKCS#11 [54], a função que permite o encapsulamento de chaves privadas é a
funçãoC_WrapKey. A operação inversa é a funçãoC_UnwrapKey. Tendo em consideração que o algoritmo
de cifra simétrica de referência é oAdvanced Encryption Standard(AES), analisamos quais os mecanismos baseados neste algoritmo que podemos utilizar nessas operações, chegando ao seguinte conjunto de me- canismos: AES_ECB, AES_CBC, AES_CBC_PAD, AES_OFB, AES_CFB, AES_CTR, AES_CTS, AES_GCM, AES_CCM, AES_KEY_WRAP.
Temos de ter em atenção que nem todos os mecanismos possíveis de ser utilizados, podem ser su-
portados pelo HSM. Considerando, por exemplo, os mecanismos suportados pelo HSM Luna SA para
key wrap/unwrap, baseados na cifra AES, e aprovados pelo FIPS, o conjunto reduz-se para AES_ECB,
AES_CBC, e AES_CBC_PAD [55]. Com os outros fabricantes deHSMs passa-se precisamente o mesmo
[56]. Isto deve-se ao facto da versão mais utilizada do PKCS#11 ser ainda a 2.20, publicada em 2004,
que contempla apenas os três mecanismos referidos. A última versão, a 2.40, foi publicada em 2015.
Por essa razão, o standard recomenda ainda a utilização do mecanismo AES_CBC_PAD parakey wrap
de chaves privadas, em particular chaves RSA. Para ser encapsulada, uma chave privada deve ser codi-
ficada de acordo com a estrutura PrivateKeyInfo, definida no standard PKCS#8 [57], estrutura essa que
será o input para a operação de wrap. Ora, como encapsulamos a chave juntamente com a sua infor-
mação, o tamanho da estrutura resultante é superior ao tamanho da chave, pelo que será necessário um
padding. Os outros mecanismos, isto é, o AES_ECB e o AES_CBC, só estão preparados para processar o valor das chaves propriamente dito, isto é, um input de tamanho múltiplo do tamanho do bloco da cifra, pelo que quaisquer outras informações das chaves, como o seu tipo, tamanho, ou mesmo o conjunto de atributos que as caracterizam, têm de ser geridas separadamente. Posto isto, não devem ser utilizados para encapsular chaves privadas.
5.1. DISPOSITIVO CRIPTOGRÁFICO SEGURO
Embora não seja referido pelo standard, deverá ser calculado um MAC (HMAC, por exemplo) sobre o
resultado da operação dekey wrap, de forma a assegurar a integridade da chave.
Resta-nos abordar a problemática da proteção das chaves pelo seu legítimo detentor. As soluções propostas na literatura sugerem a utilização de mecanismos de derivação de chaves,key derivation, rela-
cionando amaster keydoHSM, com uma password, definida para cada utilizador, para obter então a já
referidaKEKpara a operação dekey wrapping. A password poderá ser concatenada com umsalt, isto é,
um valor aleatório, para conferir proteção adicional, nomeadamente contra ataques de dicionário erainbow tables[58]. Ao ser derivada a partir da password, é estabelecida uma ligação com o detentor da chave, pelo que a password constitui assim um fator que vai permitir a ativação da chave.
A derivação de chaves pode ser feita a partir de uma operação de cifra [59], a partir de umaPassword Based Key Derivation Function(PBKDF) [60] ou mesmo através de operações XOR.
Ao nível do standard PKCS#11, a função que permite a derivação de chaves designa-se por C_DeriveKey, com a exceção da PBKDF, que ao nível do PKCS#11 é considerada como um mecanismo de geração de cha- ves. No que diz respeito à derivação de chaves a partir de uma operação de cifra, os mecanismos baseados
na cifraAES, possíveis de ser utilizados são CKM_AES_ECB_ENCRYPT_DATA e CKM_AES_CBC_ENCRYPT
_DATA. O mecanismo CKM_PKCS5_PBKD2 corresponde à geração de chaves a partir de uma PBKDF. Por fim, o mecanismo CKM_XOR_BASE_AND_DATA permite a derivação de uma chave recorrendo a operações
XOR, entre uma chave e dados deinput. Ao nível doFIPS, apenas os mecanismos de derivação baseados
em operações de cifra referidos estão aprovados [55].
Como originalmente osHSMforam desenhados para armazenar o material criptográfico na sua memória
segura, nem todos permitem a exportação de chaves criptográficas, pelo que é necessário ter atenção a esta característica na escolha do dispositivo.
Naqueles que o permitem, a exportação de chaves baseia-se em mecanismos de key wrapping, utili-
zando amaster keydoHSM. NosHSMs daThales, este mecanismo designa-se porSecure Tokenization
([61], [62]), e tem a particularidade das chaves serem encapsuladas juntamente com umaAccess Control
List(ACL), que define as restrições associadas à chave. Para além disso, aThalesdisponibiliza também
umtoken lógico, designado por softcard, construído a partir de uma password e utilizado para proteger o
acesso às chaves, num ambiente remoto [63]. Já os HSMs da SafeNetparecem não ter uma tecnologia
específica para os mecanismos de exportação e controlo remoto de chaves.
OsHSMsnShield Solo(PCI), quer onShield Connect(dispositivo de rede), daThales, foram já utilizados em sistemas de assinatura remota baseados na exportação de chaves ([45], [47], [64]). A variante Key Export do Luna PCI, da SafeNet, também já foi escolhida como dispositivo seguro para um sistema de assinatura remota ([49]). No contexto das assinaturas remotas, oHSMCoSign, da ARX, tendo já sido alvo
CAPÍTULO 5. COMPONENTES DO SISTEMA
5.1.1 Vulnerabilidades da derivação e do encapsulamento de chaves
Embora o PKCS#11 seja considerado como aAPIde referência para dispositivos criptográficos, o stan-
dard apresenta uma série de vulnerabilidades que se não forem tratadas, podem levar ao comprometimento das chaves criptográficas geridas pelo dispositivo ([65], [66]).
A principal causa dessas vulnerabilidades está na utilização indevida dos atributos das chaves, isto é, as propriedades que caracterizam uma chave. Os atributos podem determinar, por exemplo, em que tipo
operações a chave pode ser utilizada, se pode ou não ser extraída do token (CKA_EXTRACTABLE 1), se
pode ou não ser revelada em texto limpo fora dotoken(CKA_SENSITIVE). Por exemplo, quer amaster key,
quer as KEKs, deverão ter o atributo CKA_EXTRACTABLE a FALSE e o atributo CKA_SENSITIVE a TRUE.
Já as chaves de assinatura deverão ter ambos esses atributos a TRUE.
Vamos abordar, em particular, as vulnerabilidades relacionadas com os mecanismos que pretendemos utilizar, começando pelo mecanismo de derivação de chaves.
Suponhamos que amaster key, para além de ter os atributos CKA_SENSITIVE e CKA_DERIVE a TRUE,
tem também o atributo CKA_ENCRYPT a TRUE. Como já referimos, o mecanismo de derivação de chaves sugerido baseia-se na obtenção de uma chave a partir do criptograma produzido por uma operação de
cifra sobre a password do utilizador. A chave derivada, aKEK, será também CKA_SENSITIVE, pelo que só
poderá ser utilizada dentro do HSM. Ora, como o atributo CKA_ENCRYPT permite a utilização damaster
keyna funçãoC_Encrypt, podemos cifrar uma determinada password e obter o valor da respetivaKEKem
texto limpo, isto é, o criptograma resultante, deitando por terra a propriedade CKA_SENSITIVE. Assim, é possível, fora doHSM, decifrar a chave de assinatura cifrada por essaKEK. Conclui-se então que amaster
keydeverá ter o atributo CKA_ENCRYPT a FALSE.
Passemos agora aos mecanismos de exportação e importação de chaves, associados às funções
C_WrapKeyeC_UnwrapKey, respetivamente.
Suponhamos que aKEK, tem os atributos CKA_WRAP e CKA_DECRYPT a TRUE. Um ataque bastante
simples consiste na decifragem da chave encapsulada, o que permite a um atacante obter a chave de assi-
natura em texto limpo. Conclui-se então que umaKEKdeverá ter os atributos CKA_WRAP e CKA_UNWRAP
a TRUE, e os atributos CKA_ENCRYPT e CKA_DECRYPT a FALSE.
Um outro problema está relacionado com o facto de ser possível redefinir o template da chave que
pretendemos importar. Suponhamos que, para além da chave encapsulada, passamos um template, com
o atributo CKA_SENSITIVE a FALSE, como parâmetros da função C_UnwrapKey. Ao ser importada, a
chave perde essa restrição, passando a ser possível obtê-la em texto limpo. A solução para este problema passa utilizar a já referida estruturaPrivateKeyInfo, que guarda os atributos originais da chave associada.
1No PKCS#11, CKA corresponde ao prefixo dos atributos. 62