Foi efetuada uma análise aos sistemas de assinatura remota existentes, em particular àqueles que permitem, ou que foram projetados para a geração de assinaturas qualificadas, com o objetivos de de- terminar as tecnologias utilizadas, as funcionalidades mais comuns, e os componentes que compõem os sistemas, para possibilitar uma análise comparativa e até de concorrência, face à solução que se pretende implementar, apresentada por último.
Esta análise debruçou-se fundamentalmente sobre soluções cuja conformidade com os requisitos para a criação de assinaturas digitais qualificadas foi comprovada por organismos de avaliação (A-SIT3, OCSI4),
que disponibilizam publicamente as declarações de conformidade. A análise da concorrência baseou-se nesses documentos, visto que permitem tirar conclusões mais técnicas sobre os sistemas, no entanto, como nos foi possível explorar oADSSna íntegra, a sua análise foi já mais pormenorizada.
Destaque-se uma outra análise, sobre sistemas de assinatura remota, não necessariamente qualificada, que pode ser consultada em [42].
3https://www.a-sit.at/ 4http://www.ocsi.isticom.it/ 40
4.4. SOLUÇÕES EXISTENTES
Austrian Mobile Phone Signature
Solução utilizada pelo governo austríaco nos seus serviços de e-government, tendo cerca de 10.000
a 15.000 utilizações em dias úteis. Ainterfacede assinatura consiste num iframe que é embebido nos
diversoswebsites. Obackend do sistema é composto por umHSM, por uma base de dados de chaves,
e por umgatewaySMS [43]. O sistema foi avaliado pelo organismo A-SIT, face aos requisitos da diretiva
1999/93/CE, que determinou que o sistema permite a criação de assinaturas qualificadas [44].
Para obter um registo no sistema, o cidadão dirige-se presencialmente a um centro ou autoridade de registo, onde fornece os seus dados pessoais. Os seus dados de acesso ao sistema são o seu número de telemóvel e uma password. Para confirmar o registo, o cidadão submete um código que recebe por SMS.
Esta confirmação despoleta a geração do seu par de chaves noHSM, a exportação da chave de assinatura
(cifrada) para a base de dados, e a respetiva certificação da chave pública.
Para assinar, o utilizador começa por introduzir o seu número de telemóvel e a sua password. Após a
autenticação, é enviado um pedido de assinatura para oHSM, que gera um valor de hash sobre os dados
a assinar. Esse valor é apresentado ao utilizador no iframe e enviado também por SMS para efeitos de
confirmação, juntamente com um OTP, válido por cinco minutos. Por fim, o utilizador introduz o OTP,
despoletando a operação de assinatura.
PkBox
O sistema é composto por duas máquinas especializadas,PkBox HSM, que gere o dispositivo criptográ-
fico ePkBox Remote, responsável por receber pedidos da aplicação cliente (PkBox Client). A conformidade do sistema com a norma EN 419 241 foi avaliada pelo organismo A-SIT, pelo que o sistema permite a criação de assinaturas qualificadas [45].
O sistema implementa mecanismos de balanceamento de carga tendo em conta as interações entre as diversas máquinas, pelo que a aplicação cliente tem sempre ao seu dispor um conjunto de recursos adequado.
Os pares de chaves são gerados noHSMe armazenados cifrados numa base de dados. A autenticação
do signatário caracteriza-se pelo uso de um PIN, que o utilizador define no processo de registo, e de um
mecanismoOTP. OPkBoxpode ser adaptado a diversos provedoresOTP, desde soluções que se baseiam
em dispositivosOTP, da Vasco ou da RSA, a soluções baseadas em telemóveis, sejam software tokens ou
SMSOTPs.
O sistema disponibiliza aindaweb servicespara comunicar comARs eACs no sentido de obter certifi- cados para os pares de chaves gerados.
CAPÍTULO 4. SISTEMA DE ASSINATURA REMOTA
CoSign
O CoSign é uma plataforma de assinatura na Cloud da empresa DocuSign, disponível como aplicação
desktop, web ou móvel. Cada utilizador possui credenciais de acesso à plataforma e ainda chaves de assinatura, para assinar documentos.
OHSMutilizado, com o mesmo nome da plataforma, foi já alvo de uma certificação Common Criteria,
sendo considerado como um dispositivo seguro de criação de assinaturas, pelo que permite a criação de assinaturas qualificadas [46]. Esta solução tem a particularidade de integrar um servidorOTPRadius, que
se localiza no meio operacional doHSM.
O par de chaves de cada utilizador é gerado noHSMe protegido por uma password associada à conta
de utilizador. A cada utilizador é atribuído um dispositivo gerador deOTPs com um identificador único.
Quando o utilizador pretende assinar um documento, ele fornece a password e umOTPobtido a partir
do dispositivo. OHSMvalida a password internamente e comunica com o servidor deOTPRadius, usando
o protocolo Radius, para validar oOTP. Por sua vez, o servidor envia a resposta para oHSM, e caso seja válido, o documento é assinado.
Destaque-se ainda que oHSMCoSign permite uma configuração de alta disponibilidade, caso a arqui-
tetura do sistema integre mais que um dispositivo.
Outras soluções avaliadas
• AliasLab CryptoAccelerator [47]; • Protect & Sign Personal Signature [48]; • SIAVAL SafeCert [49];
Advanced Digital Signature Services Server
OAdvanced Digital Signature Services Server(ADSS) é uma solução de software que quase podemos
considerar como o “canivete suíço” dos serviços de confiança. Por meio de webservices SOAP, o ADSS
disponibiliza a aplicações de terceiros uma série de serviços, que inclui a emissão de certificados digitais, a criação de assinaturas, a validação cronológica, entre outros.
Embora o ADSS não tenha sido alvo de uma avaliação de conformidade relativamente à criação de
assinaturas qualificadas remotas, a sua conformidade com os requisitos para sistemasPKIconfiáveis, de
acordo com oCEN Workshop Agreement 14167-1, já lhe valeu uma certificação [50].
Vamos, em seguida, fazer uma análise aos módulos doADSSque permitem construir um sistema de
assinatura remota.
4.4. SOLUÇÕES EXISTENTES
Key Manager
Este módulo permite configurar o dispositivo criptográfico seguro que será utilizado para processar as
chaves e as operações criptográficas. Para oADSScomunicar com oHSMé necessário definir aAPIatravés
da qual eles irão interagir, como PKCS#11, por exemplo, bem como indicar a biblioteca para o controlador. Podemos também configurar de que forma as chaves serão protegidas, isto é, se serão mantidas no
HSMou se serão exportadas para uma base de dados, cifradas a partir de uma chave derivada de uma pas-
sword, e ainda definir o mecanismo de autenticação, seja apenas por password, ou password combinada
com SMSOTP.
ADSS Certification Service
Figura 4.1: ADSS Server Certification Service.
O módulo de certificação fornece serviços de autoridade de certificação a aplicações cliente, que atuam comoARs, solicitando a geração de chaves e a certificação de chaves públicas.
Para configurar o serviço, é necessário indicar a ACque vai emitir os certificados, o dispositivo onde as chaves serão geradas, e definir parâmetros das chaves e dos certificados, como o algoritmo de chave pública, o tamanho da chave e os atributos dos certificados.
Uma vez configurado, é possível gerar, renovar, e apagar um par de chaves e o respetivo certificado, obter a chave privada e o certificado (no formato PKCS#12) e mudar a password que protege a chave privada.
No caso da geração de um par de chaves, por exemplo, uma aplicação cliente envia os campos que
CAPÍTULO 4. SISTEMA DE ASSINATURA REMOTA
privada poderão ser futuramente identificados. Recebido o pedido, oADSSgera o par de chaves noHSM,
identificado peloaliasenviado, e protege as chaves de acordo com o método definido noKey Managerpara
o dispositivo escolhido. O serviço gera ainda oCSR, que é enviado para uma determinadaAC, configurada noADSS. Por fim, o certificado é devolvido e armazenado.
ADSS Signing Service
Figura 4.2: ADSS Server Signing Service.
O módulo de assinatura possibilita o processamento de documentos para a criação de assinaturas, utilizando chaves geradas noCertification Service.
O serviço pode ser configurado de acordo com o tipo de assinaturas que se pretende gerar, ao nível do formato das assinaturas (PDF, XML, CMS, PKCS#1), do algoritmo de hash utilizado, entre outros.
Para fazer um pedido de assinatura, podemos enviar um documento ou um valor de hash, já computado
do lado do cliente, o aliasdo certificado e a password do mesmo. O serviço obtém a chave, a partir do
alias, processa o documento ou o hash e faz um pedido aoHSMpara o assinar com a chave indicada.
Os pedidos de assinatura podem ser protegidos por um segundo fator de autenticação - umOTPenviado
por SMS.
ADSS Go>Sign Service
O Go>Sign Serviceé um serviço do ADSS que disponibiliza uma interface de assinatura, escrita em
JavaScript, que permite visualizar e assinar documentos a partir do browser. Para uma aplicação web incorporar a interface de assinatura, basta fazer um pedido HTTP ao serviçoGo>Sign, enviando no pedido
4.5. FUNCIONALIDADE
alguns parâmetros de configuração. O serviço retorna código e bibliotecasJavaScript, que ao serem embe- bidos na página, fornecem a funcionalidade pretendida, nomeadamente a criação de campos de assinatura, criação e verificação de assinaturas, download dos documentos, entre outras. Para criar assinaturas do lado do servidor, oGo>Signrecorre aoSigning Service.
4.5 Funcionalidade
4.5.1 Atores
Embora o principal objetivo de um sistema de assinatura remota seja o de disponibilizar, aos utilizadores finais, a funcionalidade de assinatura de documentos, existe uma série de operações, desempenhadas por outros utilizadores do sistema, que suportam todo o seu funcionamento.
O sistema terá de integrar umaARe umaAC. Apesar do papel que aACdesempenha se tratar de um
processo automático, aARimplica um agente de registo, responsável pelas operações de gestão dos utili-
zadores finais do sistema, nomeadamente a aprovação de registos, que despoleta processos automáticos como a geração de chaves e pedidos de certificado.
O sistema requer também um administrador, que seja responsável pelas operações de instalação, configuração e manutenção dos seus componentes.
Podemos assim identificar quatro tipos de atores, que intervêm no sistema: • Utilizador (signatário): clientes do serviço de assinatura.
• Autoridade de registo: responsável por validar a identidade dos utilizadores, por gerar os pares de chaves para os mesmos e por solicitar a emissão de certificados.
• Autoridade de certificação: responsável emitir e revogar certificados.
• Administrador do sistema: responsável pela administração dos componentes do sistema.
4.5.2 Casos de uso
Tendo em conta os atores identificados, podemos então apresentar as possíveis interações de cada um deles com o sistema, sob a forma de um diagrama de casos de uso.
Utilizador
• Registar conta: permite ao utilizador criar uma conta de utilizador no sistema. O utilizador define os seus dados de acesso e indica toda a informação necessária para o seu certificado digital. Após
CAPÍTULO 4. SISTEMA DE ASSINATURA REMOTA
Figura 4.3: Casos de uso do sistema de assinatura remota.
a criação da conta, esta fica pendente de aprovação por parte da autoridade de registo, só podendo ser utilizada depois da aprovação.
• Iniciar sessão: possibilita ao utilizador o início de sessão no sistema, através dos dados de acesso que definiu no registo.
• Enviar documento: permite ao utilizador enviar um documento para o sistema, para ser assinado. • Assinar documento: permite ao utilizador usar a sua chave de assinatura para assinar documentos.
Esta operação implica a autenticação do signatário.
• Autenticar signatário: o utilizador usa o seu token de segurança para obter os dados para a ativação da sua chave. Estes dados são submetidos pelo utilizador e verificados num componente adequado do sistema, que fará com que a operação de assinatura prossiga ou seja interrompida, caso os dados sejam ou não válidos.
• Descarregar documento: possibilita o download de um documento, depois de assinado. Autoridade de registo
• Aprovar registo: depois de validar o pedido de certificado associado à conta de utilizador, a AR
aprova o registo da conta do utilizador no sistema. Esta ação despoleta uma série de operações: – Gerar par de chaves: gera o par de chaves no dispositivo seguro;
4.5. FUNCIONALIDADE
– GerarCSR: gera o pedido de certificado, com a informação indicada pelo utilizador no registo; – Inicializar token de segurança: inicializa um token de segurança para o utilizador;
Autoridade de certificação
• Emitir certificado: recebe o pedido de certificado e emite o respetivo certificado.
Alguns casos de uso foram excluídos para simplificar a análise, nomeadamente o cancelamento da conta de um utilizador, por exemplo. Por outro lado, visto que a função do administrador é gerir os componentes do sistema, a sua interação com o mesmo foi omitida do diagrama.
4.5.3 Componentes
Dispositivo Criptográfico Seguro
Dispositivo protege chaves criptográficas e que realiza as operações criptográficas do sistema, nomea- damente, a geração de chaves e a geração de assinaturas.
Aplicação de assinatura
A aplicação de assinatura processa o documento que o utilizador pretende assinar, autentica o utilizador para determinar se ele é efetivamente o detentor da chave de assinatura e gera uma assinatura digital sob uma representação do documento. A aplicação de assinatura divide-se em três componentes:
• Interface de assinatura: permite ao utilizador visualizar o documento que vai assinar e submeter os dados para autorizar a operação de assinatura.
• Componente de autenticação: recebe e valida os dados de ativação da chave, autorizando ou não o uso da chave de assinatura.
• Componente de geração de assinatura: recebe os dados resultantes do processamento do do- cumento e, através de uma função de criação de assinaturas, gera uma assinatura no dispositivo seguro utilizando a chave do utilizador.
Aplicação da AR
Aplicação operada pelo agente de registo, que lhe permite aprovar o registo de utilizadores no sistema. Divide-se em três componentes:
• Componente de geração de chaves: permite a geração de pares de chaves diretamente no dispo- sitivo seguro.
CAPÍTULO 4. SISTEMA DE ASSINATURA REMOTA
• Componente de geração de certificados: permite a criação deCSRs com a informação fornecida
pelo utilizador e o seu envio para aAC; recebe o certificado e armazena-o juntamente com a chave
de assinatura, no dispositivo seguro.
• Componente de gestão de tokens de segurança: permite a gestão dos tokens de segurança dos utilizadores, o que implica registar a informação do token no sistema, para que o componente de autenticação consiga verificar os dados de autenticação do utilizador.
Base de dados
Base de dados que armazena a informação que sustenta o sistema, nomeadamente informação das contas dos utilizadores, das suas chaves e certificados.
Figura 4.4: Interação entre os componentes do sistema.
4.6 Recursos a proteger
• Credenciais de acesso: permitem ao utilizador iniciar sessão no sistema. • Chave de privada de assinatura: permitem ao utilizador assinar documentos.
• Certificado digital: certificado emitido pelaACpara uma chave pública, que permite verificar assi- naturas digitais efetuadas com a chave privada correspondente.
• Dados de ativação da chave: dados obtidos a partir do token do segurança, que permitem ao utilizador confirmar a sua intenção de assinar.
4.7. ATACANTES
• Documento: documento que o utilizador pretende assinar.
• Assinatura: assinatura efetuada por um utilizador sobre um documento.
• Informação do utilizador: registo da associação entre o utilizador e a localização da sua chave e do certificado no dispositivo seguro, bem como entre utilizadores e o identificador do seu token de segu- rança. A primeira associação permite ao componente de geração de assinatura determinar a chave a obter para um determinado utilizador. A segunda associação permite ao componente de auten- ticação verificar que os dados de ativação enviados por um utilizador, correspondem efetivamente aos dados de ativação que o token que lhe foi destinado gerou/recebeu.
• Servidor de assinatura: máquina que aloja a aplicação de assinatura e que disponibiliza o serviço de assinatura aos utilizadores.
• Dispositivo Criptográfico Seguro: protege chaves criptográficas e realiza as operações criptográficas do sistema.
• Base de dados: armazena a informação que sustenta o sistema.
• Função de criação de assinatura: função que cria uma assinatura, a partir de uma chave privada e de um documento.
4.7 Atacantes
Podemos identificar vários tipos de atacantes, de acordo com a sua relação com o sistema. Podemos ter:
• Atacante externo, isto é, que não possui nem uma conta de utilizador ativada, nem acesso a qualquer componente do sistema. Este tipo de atacante pode ficar à escuta de informação, para tentar obter acesso ou a uma conta de utilizador, ou a um componente do sistema.
• Atacante externo, mas que possui acesso uma conta de utilizador ativada no sistema. Este tipo de atacante pode ser representado por um utilizador legítimo do sistema. Este utilizador pode tirar partido do acesso que possui para explorar vulnerabilidades do sistema, como por exemplo tentar quebrar mecanismos de autorização para aceder a informação de outros utilizadores.
• Atacante interno, ou seja, que tem permissões de acesso a pelo menos um componente do sistema. Este tipo de atacante pode ser representado pelo agente de registo, ou pelo administrador de um ou mais componentes do sistema (da base de dados, do dispositivo criptográfico seguro, etc). Este tipo de utilizador pode, a partir de do(s) componente(s) a que tem acesso, tentar aceder a outros componentes do sistema.
Num sistema de assinatura remota, o principal objetivo de qualquer um dos tipos de atacantes passará sempre por obter uma determinada chave privada e/ou forjar uma assinatura.
CAPÍTULO 4. SISTEMA DE ASSINATURA REMOTA
4.8 Ameaças
Credenciais de acesso
• A1. Obter as credenciais de acesso de um utilizador: As credenciais permitem que um atacante inicie sessão no sistema sob a identidade do utilizador correspondente às credenciais e aceda a funcionalidades restritas.
• A2. Obter uma sessão válida: O atacante pode também atacar a sessão estabelecida entre o utilizador e o sistema.
As duas ameaças permitem ao utilizador ultrapassar mecanismos de autenticação e autorização. Chave de privada de assinatura
• A3. Obter acesso à chave privada: As chaves privadas são manipuladas durante operações de geração e armazenamento das chaves e na criação de assinaturas. Se o dispositivo onde essas operações são executadas não for adequadamente configurado, um atacante pode tirar partido de mecanismos do próprio dispositivo para expor e obter uma cópia da chave, como por exemplo mecanismos de exportação de chaves criptográficas.
• A4. Derivar a chave privada a partir de informação pública: Um atacante pode obter todas as assinaturas criadas com uma determinada chave privada, e obter também a chave pública corres- pondente. Com essa informação, o atacante pode tentar derivar a chave privada.
• A5. Modificar a chave: Por exemplo, se a chave se encontrar num dispositivo seguro, o atacante pode tentar modificar as propriedades da chave para obter o seu valor. Por outro lado, o atacante pode simplesmente alterar a chave, para que as assinaturas efetuadas com ela sejam inválidas. Estes ataques comprometem a confidencialidade e a integridade das chaves, possibilitando a geração de assinaturas em nome do legítimo detentor da chave.
Certificado digital
• A6. Armazenar um certificado que não corresponde à chave privada: Depois da geração do
par de chaves, é gerado umCSRque contém a chave pública e informação do utilizador, assinado
com a chave privada. O CSRé enviado para aAC, sendo gerado um certificado que é enviado de
volta para o sistema, para ser armazenado juntamente com a chave privada. Se for enviado um
CSRerrado (embora válido para um determinado par de chaves), obtém-se um certificado que não
corresponde à chave privada. Por outro lado, mesmo quando já armazenado, o certificado pode ser substituído por outro. A alteração do certificado implica que as verificações das assinaturas resultem
4.8. AMEAÇAS
em assinaturas inválidas. Dados de ativação da chave
• A7. Obter acesso aos dados de ativação do signatário: Caso um atacante saiba e/ou possua os dados de ativação da chave de um signatário, então ele será capaz de os utilizar para se autenticar e assinar em nome do signatário.
• A8. Modificar os dados de ativação submetidos por um signatário: Um atacante pode modificar os dados de ativação de um signatário e impedir, dessa forma, a autenticação e a consequente assinatura do signatário.
• A9. Derivar dados de ativação a partir de dados previamente utilizados: Um atacante pode capturar informação que lhe permita derivar novos dados de ativação válidos, para se autenticar e assinar em nome do signatário.
Documento
• A10. Modificar o documento a ser assinado: O atacante pode intercetar uma operação de assi- natura e modificar o documento a ser assinado, ou mesmo introduzir um novo documento. Desta forma, sem que o signatário se aperceba, consentiu a operação de assinatura num documento que não corresponde ao que pretendia assinar. Assim, o atacante será capaz de obter uma assinatura do utilizador para um documento escolhido por ele.