Componente de geração de chaves e certificados

O papel do componente de geração de chaves é o de despoletar a geração do par de chaves propria-

mente dito noHSM, enviando-lhe os parâmetros necessários para a operação. Exemplos desses parâmetros

são o tamanho da chave e o algoritmo da chave. Como vimos anteriormente, para assinaturas digitais, o algoritmo mais frequente é o RSA, com um tamanho de chave de 2048 bits.

Outro dos parâmetros que deverá ser enviado é a password, que será combinada com amaster key

doHSMpara obter aKEKque irá proteger a chave de assinatura gerada, de acordo com o mecanismo já

descrito em5.1.

A password pode ser inicialmente definida pelo componente de geração de chaves, e enviada ao utili- zador, por meios seguros, ou então escolhida pelo próprio utilizador. De destacar que a password definida deverá seguir uma política de segurança adequada.

Por outro lado, o componente de geração de certificados deverá receber a chave pública, resultante

da operação de geração, e criar umCSRa partir dela e da informação que deverá constar no certificado,

informação essa fornecida pelo utilizador e validada pelo agente de registo.

Uma vez que existem diferentes tipos de certificado, este componente deverá ser o responsável por gerir os diferentes perfis, permitindo definir os campos que deverão constar em cada um deles. De referir que a norma EN 319 412 apresenta a especificação dos campos que deverão constar em cada perfil de certificado, de acordo com o novo regulamento eIDAS.

Capítulo 6

Protótipo

Apresentamos, por fim, as decisões que foram tomadas relativamente à arquitetura do sis- tema, bem como as etapas da construção do protótipo, em contexto empresarial.

6.1 Contextualização

Depois de determinar os componentes necessários para o sistema, e de conhecer os mecanismos que

as medidas de proteção implicam, debruçamo-nos sobre o estudo doADSSno sentido de perceber se seria

possível utilizar os seus módulos e serviços para implementar o sistema. Segue-se um mapeamento direto

entre os componentes do sistema e os módulos ou serviços doADSSque estão relacionados com a sua

gestão e configuração.

Componente Módulo/Serviço doADSS

Dispositivo Criptográfico Seguro Key Manager

Componente de autenticação Key Manager

Interface de assinatura Go>Sign Service

Componente de geração de assinaturas Signing Service

Componente de gestão de tokens de segurança Não existe

Componente de geração de chaves e certificados Key Manager, Certification Service

Tabela 6.1: Implementação dos componentes do sistema noADSS.

Praticamente todos os módulos ou serviços doADSSimplementam mecanismos semelhantes aos des-

critos na secção anterior. OADSSapresenta, no entanto, uma limitação no que diz respeito à autenticação,

visto que a única possibilidade para o segundo fator de autenticação são as SMSOTP. No capítulo ante-

CAPÍTULO 6. PROTÓTIPO

implicitamente não-repúdio por parte do signatário, vinculando-o à transação através de uma assinatura.

Existe uma solução para dotar as SMS OTP da mesma propriedade, no entanto, pressupõe alguma im-

plementação do lado das aplicações cliente, que não podemos assumir como certa. Por essa razão, por

agora assumimos a utilização das SMSOTP, e remetemos a solução para este problema para a secção de

discussão.

Como o segundo fator de autenticação são então as SMSOTP, o token de segurança será obviamente

o telemóvel do utilizador. NoADSSnão existe qualquer módulo para gerir a associação entre certificados e os tokens de segurança que permitem a sua utilização. Para colmatar esta necessidade, será necessário criar um componente adicional para gestão de tokens de segurança e utilizadores.

Este componente, que designamos por QSCD Proxy, que vem deQualified Signature Creation Device

Proxy, pode ser visto como uma ponte, ou interface, entre oADSSe as aplicações cliente que consomem

o serviço de assinatura remota. O QSCD Proxy, juntamente com o ADSS e o HSM compõem o nosso

dispositivo qualificado de criação de assinaturas.

A DigitalSign optou por avançar com esta arquitetura do sistema e com o desenvolvimento e teste de um protótipo, no sentido de determinar se será ou não viável prosseguir com uma certificação segundo a norma CEN/TS 419 241.

Na fase de testes envolvemos uma das plataformas eletrónicas de contratação pública portuguesas, a Vortal. Estas plataformas são como uma comunidade, onde entidades públicas solicitam bens e serviços, e onde fornecedores apresentam propostas, face às oportunidades de negócio. O processo de contratação termina, eventualmente, com a celebração de um contrato entre as partes, que é assinado digitalmente. Como provedor de serviços de confiança, a DigitalSign desempenha já um papel importante nestas pla- taformas, através da disponibilização do serviço de validação cronológica, que permite assegurar a hora legal em que as transações ocorrem.

Para complementar a sua oferta de serviços na plataforma, a DigitalSign propôs à Vortal a integração deste novo serviço de assinaturason-demand. Do ponto de vista da arquitetura do sistema, a Vortal repre- senta então uma aplicação cliente, que consome o serviço, através do QSCD Proxy. Assim, no processo de aquisição de um certificado digital, os utilizadores da Vortal poderão optar pela geração do par de chaves

numHSMcentralizado, em vez do habitual suporte físico. Nesta modalidade, o utilizador terá de adquirir

um plano de assinaturas, visto que por cada documento assinado, é descontada uma assinatura do saldo da sua conta no QSCD Proxy.

No sentido de clarificar os processos os processos de subscrição e assinatura, segue-se uma breve descrição de cada um.

6.1. CONTEXTUALIZAÇÃO

Processo de subscrição

• O cliente da Vortal adquire um certificado digital e um plano de assinaturas;

• A Vortal comunica, via webservice, as seguintes informações à autoridade de registo da DigitalSign: – os dados para a conta de utilizador no QSCD Proxy, bem como o número de telemóvel que irá

utilizar para se autenticar;

– as informações que deverão constar no certificado;

– o plano de assinaturas escolhido, que se traduz num determinado número de assinaturas; • O agente de registo da DigitalSign valida a informação do certificado, bem como o número de tele-

móvel, assegurando-se de que este pertence efetivamente ao titular;

• A autoridade de registo da DigitalSign autoriza a emissão do certificado, despoletando: – criação da conta de utilizador no QSCD Proxy, com determinado saldo de assinaturas; – pedido de criação do par de chaves e certificado, através do QSCD Proxy; nesta fase o proxy

comunica com oADSS, que internamente trata da operação, sendo o certificado devolvido e

associado à conta de utilizador; a chave de assinatura é armazenada noADSS, cifrada sobre

um PIN gerado aleatoriamente;

– envio do PIN do certificado para o cliente, através de correio registado ou outro meio seguro;

Processo de assinatura

• O cliente faz um pedido de assinatura de um documento, na plataforma da Vortal.

– a Vortal pede ao QSCD Proxy os certificados associados ao utilizador, identificado pelo nome de utilizador/email;

– o QSCD Proxy retorna uma lista de alias de certificados associados ao utilizador; – o utilizador escolhe o certificado que pretende utilizar e introduz o PIN;

– a Vortal faz o pedido para ao QSCD Proxy, enviando o nome de utilizador, o alias do certificado, o PIN e o nome e o hash do documento;

• o QSCD Proxy regista a transação, gera um identificador que é retornado para a Vortal, e reencaminha

o pedido de assinatura para oADSS, juntando aos parâmetros o número de telemóvel do utilizador;

• oADSS:

– obtém o certificado a partir do alias;

– decifra a chave de assinatura, noHSM, a partir do PIN;

– gera umOTPnoHSM, que é utilizado para cifrar a chave;

– envia oOTPpara o número de telemóvel do utilizador, através daAPIdo provedor de serviço

CAPÍTULO 6. PROTÓTIPO

• O utilizador recebe oOTP, confirma o nome do documento, e insere oOTPna plataforma da Vortal;

• A Vortal envia oOTP, juntamente com o alias do certificado e o identificador da transação, para o

QSCD Proxy;

• O QSCD Proxy verifica a existência da transação e reencaminha o pedido de confirmação de assina- tura para oADSS;

• oADSS:

– obtém o certificado a partir do alias;

– decifra a chave de assinatura, noHSM, a partir doOTP;

– utiliza a chave, no HSM, para assinar o hash do documento, retornando a assinatura (no

formato PKCS#1);

• O QSCD Proxy reencaminha a assinatura para a Vortal, finalizando o processo;

Segue-se a demonstração da construção do protótipo, desde a configuração doHSM, passando pela

configuração doADSS, pela criação do QSCD Proxy, até à demonstração da interface de assinatura, em

duas vertentes: oGo>Sign Document Viewere aAPIRESTful que a Vortal irá utilizar.