Ao ser importada, a função deunwrapdeve verificar se os atributos originais entram em conflito com os
enviados como parâmetro, e caso isso se suceda, a operação deve lançar um erro.
Porém, nem todas as vulnerabilidades estão associadas a atributos. Por exemplo, a funçãoC_WrapKey
permite o encapsulamento de chaves por uma KEKde nível de segurança inferior, pelo que o atacante
precisa apenas de atacar aKEKpara recuperar a chave original. AKEKtem de ter um tamanho de chave
que assegure um nível de segurança igual ou superior às chaves que encapsula.
Uma outra vulnerabilidade, da funçãoC_UnwrapKey, permite levar a cabo um ataque designado por
padding oracle attack, em chaves encapsuladas com o mecanismo AES_CBC_PAD [67]. A funçãoC_UnwrapKey
retorna uma mensagem de erro caso opadding de uma mensagem cifrada esteja incorreto, informação
essa que é aproveitada para correr o algoritmo que permite obter o valor da chave. Esta vulnerabilidade pode resolver-se com uma verificação da integridade do criptograma, antes de se proceder à sua decifra-
gem. Podemos fazê-lo aplicacionalmente, no entanto o ideal seria utilizar um mecanismo dekey wrapping,
com authenticated encryption implícita, como o AES_GCM, o AES_CCM. Uma outra opção poderia ser
o AES_KEY_WRAP_PAD [68], que embora tenha sido concebido com o objetivo de encapsular chaves, a
especificação do PKCS#11 ainda não recomenda a sua utilização para esse fim.
Os fabricantes dos HSMs, ao conceber as suas implementações concretas do PKCS#11, devem re-
solver as vulnerabilidades apresentadas. A título de exemplo, podemos constatar que, por exemplo, a
Safenetapresentou uma solução para evitar o referidopadding oracle attack[69]. Por outro lado, osHSMs permitem aplicar uma série de restrições na sua configuração, que podem resolver as vulnerabilidades
apresentadas. Um exemplo é o facto de ser possível definir que a operação deunwrapresulta na importa-
ção de uma chave que obrigatoriamente terá o atributo CKA_SENSITIVE a TRUE.
O HSM escolhido deverá, por isso, ter umaAPI robusta e deverá ser configurado com as definições
adequadas para derivação e encapsulamento de chaves.
5.2 Aplicação de assinatura
5.2.1 Componente de autenticação
Na especificação dos objetivos de segurança, foi estabelecido que deve ser implementada uma autenti- cação multifator do signatário. Tendo em conta a análise efetuada na secção anterior, acerca da proteção das chaves, a escolha mais natural para o primeiro fator parece ser uma password, ou seja, algo que o utilizador sabe. O outro fator poderá ser um valor dinâmico, obtido a partir de algo que o utilizador possui, ou seja, um token de segurança.
CAPÍTULO 5. COMPONENTES DO SISTEMA
remota, as chaves de assinatura devem ser ativadas por dispositivos de hardware que ofereçam um nível de garantia de nível 4 (de acordo com [8]).
Em resposta à publicação daEurosmart, a empresaCryptomathicafirma que as soluções de assinatura
remota perdem o seu propósito e conveniência se a autenticação do utilizador exigir a utilização de um dispositivo dedicado, que por si só lhe poderia permitir realizar assinaturas localmente (ex: smart cards) [71].
Os objetivos da DigitalSign vão ao encontro da posição daCryptomathic, isto é, pretende-se encontrar uma alternativa segura, que não implique a utilização um dispositivo adicional.
Grande parte dos sistemas de assinatura remota analisados, optam por uma autenticação multifator
baseada na combinação de uma password com SMSOTPs, ouOTPs geradas em dispositivos de hardware.
Na literatura encontramos também abordagens que utilizam esta combinação ([51], [52]).
A norma EN 419 241 refere que deve ser utilizado um mecanismo de autenticação de pelo menos
dois fatores, admitindo a utilização de um token em software, como uma aplicação de smartphone, em
combinação com algo que o utilizador sabe.
O mecanismo de autenticação para assinaturas remotas deve: ser independente da plataforma, criar um vínculo entre o documento e os dados de ativação que autorizaram a operação de assinatura, ser fácil de usar, de integrar e ainda economicamente eficiente [72].
Uma autenticaçãomobile-based, baseada em criptografia assimétrica permite cumprir, não só os obje-
tivos de segurança definidos anteriormente, como também praticamente todas as propriedades que aca- bamos de referir. Por estas razões vamos explorá-la de seguida, no protocolo de ativação de assinatura.
Protocolo de ativação da assinatura
Tomando como referência a norma EN 419 241 [36], temos dois níveis de controlo exclusivo da chave
privada:
• No nível 1, ilustrado na figura5.1, a autenticação do signatário é realizada ao nível da aplicação de assinatura, pelo que a chave a utilizar é obtida a partir da identidade autenticada do utilizador; • No nível 2, ilustrado na figura5.2, a autenticação é levada a cabo no dispositivo criptográfico seguro,
através dos dados de ativação de assinatura do signatário, que permitem a “libertação” e o uso da chave.
Segundo a norma, o nível necessário para produzir assinaturas eletrónicas qualificadas é o nível 2, pelo que o dispositivo seguro deve estar diretamente envolvido no processo de autenticação.
Segundo a publicação [8], existem duas abordagens para implementar uma autenticação multifator:
• multi-token: o signatário submete um segredo e os dados derivados a partir do token, separada-
5.2. APLICAÇÃO DE ASSINATURA
Figura 5.1: Nível 1 - autenticação baseada na aplicação. Figura 5.2: Nível 2 - autenticação baseada no dispositivo seguro.
mente.
• single-token: o signatário introduz o segredo no token e este deriva os dados de ativação da chave.
A norma admite estas duas variantes [36]. A norma refere ainda que os dados de ativação têm de ser
fornecidos aoHSMpara este, no momento em que a chave privada de assinatura é gerada, os associar à
chave. O único fator que poderá ser associado à chave é a password, visto que é estática. Numa abordagem
single-token, a password não é enviada para o componente de autenticação, sendo apenas utilizada para permitir a geração dos dados de ativação da chave no token, que por sua vez são dinâmicos. A abordagem
terá, por isso, de sermulti-token, em que o utilizador submete a password na interface de assinatura e
utiliza uma aplicação móvel para obter o fator dinâmico. A aplicação móvel comunica diretamente com o
componente de autenticação, que por sua vez comunica com oHSM. São, por isso, utilizados dois canais
de comunicação distintos. Sugerimos, de seguida, um protocolo de ativação, baseado numa autenticação
multi-token, num protocolochallenge-responsee na utilização de chaves assimétricas (ilustrado na figura
5.3).
Partimos do princípio que o utilizador já tem a aplicação de autenticação instalada no seusmartphone, bem como um par de chaves de autenticação, gerado pela aplicação. Assumimos ainda que a chave pública foi enviada para o componente de autenticação, e associada ao utilizador no componente de gestão de tokens de segurança.
• O utilizador, com sessão iniciada na interface de assinatura, submete o documento e a sua password; • A aplicação de assinatura gera o identificador da transação, e reencaminha o documento, e a pas-
sword para os devidos componentes;
• O componente de geração de assinaturas gera o hash do documento;
• O componente de autenticação pede aoHSMpara:
– decifrar a chave de assinatura com a password; – gerar o desafio;
CAPÍTULO 5. COMPONENTES DO SISTEMA
• O componente de autenticação, a partir do identificador do utilizador, obtém o identificador da res- petiva aplicação, no componente de gestão de tokens de segurança.
• O componente de autenticação envia uma notificação push para a aplicação do utilizador, contendo o desafio, o identificador da transação e o hash do documento;
• O utilizador recebe a notificação na aplicação, revê a informação da transação e aceita-a; • A aplicação gera uma resposta sobre o desafio, utilizando a chave privada de autenticação; • A resposta é enviada, para o componente de autenticação;
• O componente de autenticação obtém a chave pública de autenticação do utilizador, no componente de gestão de tokens de segurança, e com ela valida a resposta;
• Após esta validação, o componente de geração de assinaturas está finalmente autorizado a pedir
aoHSMpara assinar o hash do documento, enviando-lhe o desafio para oHSMdecifrar e utilizar a
chave;
• O componente de geração de assinaturas junta a assinatura ao documento; • O utilizador visualiza, na interface de assinatura, o documento assinado;
Como podemos constatar, a partir da descrição acima, oHSMestá ativamente envolvido no protocolo
de autenticação.
Resumidamente, o papel do componente de autenticação será:
• despoletar operações de cifragem e decifragem sobre as chaves de assinatura; • despoletar a geração do desafio;
• enviar notificações push;
• validar os dados de ativação da assinatura, isto é, a resposta enviada pelo utilizador a partir da aplicação de autenticação;
• autorizar o processo de assinatura, a ser levado a cabo pelo componente de geração de assinaturas;
5.2.2 Interface de assinatura
What You See Is What You Sign
Como foi referido na análise de segurança, o sistema deverá assegurar que o documento que é assinado, é efetivamente aquele que o signatário se encontrava a visualizar, e que concedeu autorização para que o processo de assinatura tivesse lugar.
Esta propriedade pode ser implementada através da confirmação do valor de hash do documento. Depois do utilizador submeter o documento, pode ser-lhe apresentado o respetivo valor de hash. O cálculo do valor de hash pode até ser feito client-side.
A notificação push que é enviada para o utilizador deverá conter o mesmo valor de hash. Caso seja
5.2. APLICAÇÃO DE ASSINATURA
CAPÍTULO 5. COMPONENTES DO SISTEMA
efetivamente o mesmo, significa que o utilizador irá autorizar a operação de assinatura sobre o documento que submeteu. Se o valor não for o mesmo, o utilizador deverá rejeitar a operação, caso contrário poderá estar a assinar algo que não corresponde ao que enviou.
Uma abordagem do mesmo tipo é utilizada na Austrian Mobile Phone Signature, em que o hash do
documento é enviado por SMS, juntamente com oOTP.
Para além disso, várias aplicações de autenticação, baseadas em notificações push, por exemplo, apresentam diversas informações da transação ao utilizador (IP, browser, localização, etc). No caso da nossa aplicação, é conveniente que seja apresentado o valor de hash.
5.2.3 Componente de geração de assinaturas
O componente de geração de assinaturas é o responsável por gerar o hash dos documentos, segundo um determinado algoritmo de hash, que tem de ser definido. Como vimos anteriormente, para assinaturas digitais, o algoritmo de hash recomendado à data atual é o SHA-256.
Depois de enviar o hash para oHSM, e obter a assinatura, o componente deverá juntá-la ao documento
original, segundo o formato de assinatura escolhido, e de acordo com o standard de assinatura eletrónica do ETSI, TS 102 778.
Os formatos possíveis são:
• PDF Advanced Electronic Signature (PAdES); • XML Advanced Electronic Signatures (XAdES); • CMS Advanced Electronic Signatures (CAdES);