ANEXO I

FORMATO E GESTÃO DA CONFIANÇA

Estrutura de dados genérica, mecanismos de codificação e mecanismo de codificação de transporte num formato de leitura ótica (a seguir designado por «QR»)

1. Introdução

As especificações técnicas definidas no presente anexo incluem uma estrutura de dados genérica e mecanismos de codificação para o Certificado Digital COVID da UE («DCC»). Especificam ainda um mecanismo de codificação de transporte num formato de leitura ótica («QR»), que pode ser exibido no ecrã de um dispositivo móvel ou impresso. Os formatos do contentor do certificado sanitário eletrónico destas especificações são genéricos, mas utilizados, neste contexto, para incluir o DCC.

2. Terminologia

Para efeitos do presente anexo, entende-se por «emitentes» as organizações que utilizam estas especificações para emitir certificados sanitários e por «verificadores» as organizações que aceitam certificados sanitários como prova do estado de saúde. Por «participantes», entende-se os emitentes e os verificadores. Alguns aspetos definidos no presente anexo devem ser coordenados entre os participantes, designadamente, a gestão de um espaço de nomes e a distribuição de chaves criptográficas. Presume-se que uma entidade, a seguir designada por «secretariado», executa estas tarefas.

3. Formato do contentor do certificado sanitário eletrónico

O formato do contentor do certificado sanitário eletrónico («HCERT») destina-se a disponibilizar um veículo uniforme e normalizado para certificados sanitários dos diferentes emitentes («emitentes»). O objetivo das presentes especificações consiste em harmonizar a forma como esses certificados sanitários são representados, codificados e assinados com vista a facilitar a interoperabilidade.

A capacidade de ler e interpretar um DCC emitido por qualquer emitente exige uma estrutura de dados comum, bem como um acordo quanto ao significado de cada campo de dados da carga útil. A fim de facilitar essa interoperabilidade, é definida uma estrutura de dados comum e coordenada através da utilização de um esquema «JSON», que constitui o enquadramento do DCC.

3.1. Estrutura da carga útil

A carga útil é estruturada e codificada como CBOR com uma assinatura digital COSE, geralmente conhecida como «CBOR Web Token» (CWT) e definida no RFC 8392 (1). A carga útil, conforme definida nas secções seguintes, é transportada num atributo («claim») hcert.

A integridade e autenticidade de origem dos dados da carga útil devem ser verificáveis pelo verificador. A fim de disponibilizar este mecanismo, o emitente deve assinar o CWT utilizando um esquema de assinatura eletrónica assimétrico conforme definido na especificação COSE (RFC 8152 (2)).

3.2. Atributos CWT

3.2.1. Descrição geral da estrutura CWT

Cabeçalho protegido

— algoritmo de assinatura (alg, etiqueta 1)

— identificador de chave (kid, etiqueta 4)

Carga útil

— emitente (iss, chave de atributo 1, opcional, ISO 3166-1 alfa-2 do emitente)

— emitido em (iat, chave de atributo 6)

— prazo de expiração (exp, chave de atributo 4)

— certificado sanitário (hcert, chave de atributo -260)

— certificado Digital COVID da UE v1 (eu_DCC_v1, chave de atributo 1)

Assinatura

3.2.2. Algoritmo de assinatura

O parâmetro do algoritmo de assinatura (alg) indica o algoritmo utilizado para a criação da assinatura. Deve cumprir ou exceder as diretrizes do SOG-IS em vigor, resumidas nos parágrafos seguintes.

São definidos um algoritmo primário e um secundário. O algoritmo secundário só deve ser utilizado se o algoritmo primário não for aceitável no âmbito das regras e dos regulamentos impostos ao emitente.

A fim de garantir a segurança do sistema, todas as implementações têm de incorporar o algoritmo secundário. Por esta razão, tanto o algoritmo primário como o secundário devem ser implementados.

Os níveis definidos pelo SOG-IS para os algoritmos primário e secundário são os seguintes:

— Algoritmo primário: o algoritmo primário é o algoritmo de assinatura digital de curva elíptica (ECDSA), conforme definido na norma (ISO/IEC 14888–3:2006), secção 2.3, utilizando os parâmetros P–256, definidos no apêndice D (D.1.2.3) da norma (FIPS PUB 186–4) em combinação com o algoritmo de dispersão SHA–256, definido na função 4 da norma (ISO/IEC 10118–3:2004).

Este corresponde ao parâmetro ES256 do algoritmo COSE.

— Algoritmo secundário: o algoritmo secundário é RSASSA-PSS conforme definido no (RFC 8230 (3)), com um módulo de 2048 bits em combinação com o algoritmo de dispersão SHA–256, definido na função 4 da norma (ISO/IEC 10118–3:2004).

Este corresponde ao parâmetro PS256 do algoritmo COSE.

3.2.3. Identificador de chave

O atributo de identificador de chave (kid) indica o certificado de signatário de documento (DSC) que contém a chave pública a utilizar pelo verificador para controlar a exatidão da assinatura digital. A governação dos certificados de chave pública, incluindo os requisitos aplicáveis aos DSC, é descrita no anexo IV.

O atributo de identificador de chave (kid) é utilizado pelos verificadores para selecionar a chave pública correta a partir de uma lista de chaves relativas ao emitente indicadas no atributo de emitente (iss). Um emitente pode utilizar várias chaves em paralelo por razões administrativas e ao efetuar substituições de chaves. O identificador de chave não constitui um campo crítico no plano da segurança. Por esta razão, pode também ser inserido num cabeçalho não protegido, se necessário. Os verificadores devem aceitar ambas as opções. Se ambas as opções estiverem presentes, deve ser utilizado o identificador de chave do cabeçalho protegido.

Devido à redução do identificador (por razões de limite de tamanho), há uma hipótese mínima, mas não nula, de que a lista geral de DSC aceites por um verificador possa conter DSC com kid duplicado. Por esta razão, um verificador deve controlar todos os DSC com esse kid.

3.2.4. Emitente

O atributo de emitente (iss) é um valor em cadeia que pode conter opcionalmente o código de país ISO 3166-1 alfa-2 da entidade que emite o certificado sanitário. Este atributo pode ser utilizado por um verificador para identificar o conjunto de DSC a utilizar para verificação. É utilizada a chave de atributo 1 para identificar este atributo.

3.2.5. Prazo de expiração:

O atributo de prazo de expiração (exp) deve conter um selo temporal no formato de número inteiro NumericDate (conforme especificado no RFC 8392 (4), secção 2) indicando durante quanto tempo esta assinatura concreta da carga útil é considerada válida, após o que um verificador deve considerar que o prazo da carga útil expirou e rejeitá-la. O objetivo do parâmetro de validade é impor um limite ao período de validade do certificado sanitário. É utilizada a chave de atributo 4 para identificar este atributo.

O prazo de expiração da assinatura não deve exceder o período de validade do DSC.

3.2.6. Emitido em

O atributo «Emitido Em» (iat) deve conter um selo temporal no formato de número inteiro NumericDate (conforme especificado no RFC 8392 (5), secção 2) indicando a hora a que o certificado sanitário foi criado.

A data do campo «Emitido Em» não deve ser anterior ao período de validade do DSC.

Os verificadores podem aplicar políticas adicionais a fim de limitar a validade do certificado sanitário com base na hora de emissão. É utilizada a chave de atributo 6 para identificar este atributo.

3.2.7. Atributo de certificado sanitário

O atributo de certificado sanitário (hcert) é um objeto JSON (RFC 7159 (6)) que contém as informações sobre o estado de saúde. Podem existir sob o mesmo atributo vários tipos diferentes de certificados sanitários, um dos quais o DCC.

O JSON é utilizado exclusivamente para efeitos de esquema. O formato de representação é o CBOR, conforme definido no (RFC 7049 (7)). É possível que os programadores de aplicações nunca descodifiquem ou codifiquem realmente de e para o formato JSON, mas utilizem a estrutura na memória.

A chave de atributo a utilizar para identificar este atributo é -260.

As cadeias do objeto JSON devem ser normalizadas de acordo com o Formato de Normalização de Composição Canónica (NFC) definida na norma Unicode. As aplicações de descodificação devem, todavia, ser permissivas e robustas no tocante a estes aspetos e a aceitação de qualquer conversão de tipo razoável é fortemente incentivada. Se forem detetados dados não normalizados durante a descodificação ou em funções subsequentes de comparação, as implementações devem comportar-se como se a entrada de dados fosse normalizada de acordo com o NFC.

4. Serialização e criação da carga útil do DCC

É aplicado o esquema seguinte como padrão de serialização:

O processo tem início com a extração de dados, por exemplo, de um repositório de dados de saúde (ou de uma fonte de dados externa) estruturando os dados extraídos de acordo com os esquemas de DCC definidos. Neste processo, a conversão para o formato de dados definido e a transformação para efeitos de legibilidade humana podem ocorrer antes de a serialização para CBOR ter início. Os acrónimos dos atributos devem ser identificados em todos os casos para os nomes visíveis antes da serialização e após a desserialização.

Não é permitida a inclusão de conteúdo de dados nacionais opcionais em certificados emitidos em conformidade com o Regulamento (UE) 2021/953 (8). O conteúdo de dados limita-se aos elementos de dados definidos no conjunto de dados mínimos especificado no anexo do Regulamento 2021/953.

5. Codificações de transporte

5.1. Em bruto

Para interfaces de dados arbitrárias, o contentor HCERT e as respetivas cargas úteis podem ser transferidos no estado em que se encontram, utilizando qualquer transporte de dados subjacente, fiável e seguro, de 8 bits. Estas interfaces podem incluir a comunicação de campo próximo, Bluetooth ou transferência através de um protocolo de camada de aplicação, por exemplo, a transferência de um HCERT do emitente para o dispositivo móvel de um titular.

Se a transferência do HCERT do emitente para o titular se basear numa interface apenas de apresentação (por exemplo, SMS, correio eletrónico), obviamente a codificação de transporte em bruto não se aplica.

5.2. Código de barras

5.2.1. Compressão da carga útil (CWT)

A fim de reduzir o tamanho e de melhorar a rapidez e a fiabilidade do processo de leitura do HCERT, o CWT deve ser comprimido utilizando o ZLIB (RFC 1950 (9)) e o mecanismo de compressão Deflate no formato definido no RFC 1951 (10).

5.2.2. Código de barras QR 2D

A fim de melhor gerir equipamentos preexistentes, concebidos para funcionar com cargas úteis ASCII, o CWT comprimido é codificado como ASCII utilizando Base45 antes de ser codificado num código de barras 2D.

Deve ser utilizado o formato QR definido na norma (ISO/IEC 18004:2015) na geração do código de barras 2D. Recomenda-se uma taxa de correção de erro de «Q» (de cerca de 25 %). Uma vez que se utiliza Base45, o código QR tem de utilizar a codificação alfanumérica (modo 2, indicado pelos símbolos 0010).

Para que os verificadores possam detetar o tipo de dados codificados e selecionar o esquema de descodificação e processamento adequado, os dados codificados com Base45 (de acordo com esta especificação) devem ser precedidos da cadeia de identificadores de contexto «HC1:». As futuras versões desta especificação que tenham impacto na compatibilidade com versões anteriores devem definir um novo identificador de contexto, ao passo que o caráter a seguir a «HC» deve ser retirado do conjunto de carateres [1-9A-Z]. A ordem dos incrementos é definida segundo esta sequência, ou seja, primeiro [1-9] e depois [A-Z].

Recomenda-se que o código ótico seja representado nos meios de apresentação com uma dimensão diagonal entre 35 mm e 60 mm para suportar leitores com ótica fixa, em que os meios de apresentação devem ser colocados sobre a superfície do leitor.

Se o código ótico for impresso em papel utilizando impressoras de baixa resolução (< 300 dpi), deve ter-se cuidado para representar cada símbolo (ponto) do código QR exatamente em quadrado. A escala não proporcional terá como resultado que algumas linhas ou colunas no QR tenham símbolos retangulares, o que, em muitos casos, dificulta a legibilidade.

6. Formato da lista de confiança (lista de CSCA e DSC)

Cada Estado-Membro é obrigado a fornecer uma lista que inclua uma ou mais autoridades de certificação signatárias nacionais (CSCA) e uma lista de todos os certificados de signatários de documentos (DSC) válidos, bem como a manter estas listas atualizadas.

6.1. CSCA/DSC simplificados

A partir desta versão das especificações, os Estados-Membros não devem assumir que é utilizada qualquer informação da lista de revogação de certificados (CRL), nem que o período de utilização de chaves privadas é verificado pelos responsáveis pela implementação.

O mecanismo de validade primário será antes a presença do certificado na versão mais recente dessa lista de certificados.

6.2. Infraestrutura de chave pública (PKI) do documento de viagem eletrónico de leitura ótica (eMRTD) da OACI e centros de confiança

Os Estados-Membros podem utilizar uma CSCA separada, mas também podem apresentar os seus certificados CSCA de eMRTD e/ou DSC existentes, podendo mesmo optar por obtê-los junto de centros de confiança (comerciais) e apresentá-los. No entanto, qualquer DSC deve ser sempre assinado pela CSCA comunicada por esse Estado-Membro.

7. Considerações em matéria de segurança

Ao conceber um sistema de acordo com esta especificação, os Estados-Membros devem identificar, analisar e monitorizar determinados aspetos de segurança.

Deverão, no mínimo, ser tidos em conta os seguintes aspetos:

7.1. Período de validade da assinatura do HCERT

O emitente do HCERT deve limitar o período de validade da assinatura especificando um prazo de expiração da assinatura. Tal obriga o titular de um certificado sanitário a renová-lo a intervalos regulares.

O período de validade aceitável pode ser determinado por condicionalismos práticos. Por exemplo, um viajante pode não ter a possibilidade de renovar o certificado sanitário durante uma viagem ao estrangeiro. No entanto, pode também dar-se o caso de um emitente considerar que existe a possibilidade de algum tipo de comprometimento de segurança que o obrigue a retirar um DSC (invalidando todos os certificados sanitários emitidos com essa chave que ainda estejam dentro do respetivo período de validade). As consequências dessa ocorrência podem ser limitadas substituindo regularmente as chaves do emitente e exigindo a renovação de todos os certificados sanitários num intervalo razoável.

7.2. Gestão de chaves

A presente especificação depende largamente de mecanismos criptográficos fortes para proteger a integridade dos dados e a autenticação da origem dos dados. Por conseguinte, é fundamental manter a confidencialidade das chaves privadas.

A confidencialidade das chaves criptográficas pode ser comprometida de várias formas, nomeadamente:

— o processo de geração de chaves pode ser deficiente, resultando em chaves fracas,

— as chaves podem ser reveladas devido a erro humano,

— as chaves podem ser roubadas por criminosos externos ou internos,

— as chaves podem ser calculadas através de criptoanálise,

A fim de atenuar os riscos de o algoritmo de assinatura ser fraco, permitindo que as chaves privadas fiquem comprometidas na sequência de criptoanálise, esta especificação recomenda que todos os participantes implementem um algoritmo de assinatura secundário de recurso baseado em parâmetros diferentes ou num problema matemático diferente do primário.

Quanto aos riscos mencionados relacionados com os ambientes operacionais dos emitentes, devem ser implementadas medidas de atenuação para assegurar um controlo eficaz, nomeadamente para a geração, o armazenamento e a utilização das chaves privadas em módulos de segurança físicos (HSM). Incentiva-se fortemente a utilização de HSM para assinar certificados sanitários.

Independentemente de o emitente decidir ou não utilizar HSM, deverá ser estabelecido um calendário de substituição de chaves em que a frequência das substituições seja proporcional à exposição das chaves a redes externas, a outros sistemas e ao pessoal. Um calendário de substituição devidamente definido também limita os riscos associados a certificados sanitários emitidos erroneamente, permitindo que um emitente revogue esses certificados sanitários por lotes, retirando uma chave, se necessário.

7.3. Validação de dados de entrada

As presentes especificações podem ser utilizadas de uma forma que implique a receção de dados de fontes não fiáveis em sistemas que podem ser de natureza crítica. Para minimizar os riscos associados a este vetor de ataque, todos os campos de entrada devem ser devidamente validados por tipos, comprimentos e conteúdos de dados. A assinatura do emitente deverá também ser verificada antes de qualquer tratamento do conteúdo do HCERT. No entanto, a validação da assinatura do emitente implica a análise, em primeiro lugar, do cabeçalho protegido do emitente, em que um potencial atacante pode tentar injetar informações cuidadosamente elaboradas para comprometer a segurança do sistema.

8. Gestão da confiança

A assinatura do HCERT exige uma chave pública para verificação. Os Estados-Membros devem disponibilizar estas chaves públicas. Em última instância, cada verificador tem de dispor de uma lista de todas as chaves públicas em que está disposto a confiar (já que a chave pública não faz parte do HCERT).

O sistema consiste em (apenas) duas camadas; para cada Estado-Membro, um ou mais certificados nacionais que assinam, cada um, um ou mais certificados de signatários de documentos que são utilizados nas operações quotidianas.

Os certificados dos Estados-Membros são designados por certificados das autoridades de certificação signatárias nacionais (CSCA) e são (normalmente) autoassinados. Os Estados-Membros podem ter mais do que um (por exemplo, em caso de descentralização regional). Estes certificados CSCA assinam regularmente os certificados de signatários de documentos (DSC) utilizados para assinar HCERT.

O «secretariado» desempenha um papel funcional. Deve agregar e publicar regularmente os DSC dos Estados-Membros, depois de os ter verificado em relação à lista de certificados CSCA (que foram transmitidos e verificados por outros meios).

A lista de DSC resultante deve então apresentar o conjunto agregado de chaves públicas aceitáveis [e os identificadores de chaves (kid) correspondentes] que os verificadores podem utilizar para validar as assinaturas nos HCERT. Os verificadores devem completar e atualizar esta lista regularmente.

Essas listas específicas dos Estados-Membros podem ser adaptadas no formato adequado ao seu próprio contexto nacional. Deste modo, o formato de ficheiro desta lista de confiança pode variar; pode ser, por exemplo, um JWKS assinado (formato de conjunto de JWK de acordo com o RFC 7517 (11), secção 5) ou qualquer outro formato específico da tecnologia utilizada nesse Estado-Membro.

Para garantir a simplicidade, os Estados-Membros podem apresentar os seus certificados CSCA existentes a partir dos seus sistemas de eMRTD conformes com as normas da OACI ou, tal como recomendado pela OMS, criar um especificamente para este domínio de saúde.

8.1. Identificadores de chaves (kid)

O identificador de chave (kid) é calculado ao estabelecer a lista de chaves públicas de confiança a partir dos DSC e consiste numa impressão digital SHA-256 truncada (primeiros 8 bytes) do DSC codificada no formato DER (em bruto).

Os verificadores não precisam de calcular o identificador de chave com base no DSC e podem fazer corresponder diretamente o identificador de chave no certificado sanitário emitido ao identificador de chave na lista de confiança.

8.2. Diferenças em relação ao modelo de confiança da PKI do eMRTD da OACI

Embora inspirado nas melhores práticas do modelo de confiança da PKI do eMRTD da OACI, deve ser realizado um conjunto de simplificações no interesse da celeridade:

— um Estado-Membro pode apresentar vários certificados CSCA,

— o período de validade do DSC (utilização da chave) pode ser definido com qualquer duração que não exceda a do certificado CSCA e pode estar ausente,

— o DSC pode conter identificadores de políticas (utilização alargada da chave) específicos dos certificados sanitários,

— os Estados-Membros podem optar por nunca efetuar qualquer verificação das revogações publicadas, fazendo simplesmente fé nas listas de DSC que recebem diariamente do secretariado ou que coligem.

(1) rfc8392 (ietf.org).

(2) rfc8152 (ietf.org).

(3) rfc8230 (ietf.org).

(4) rfc8392 (ietf.org).

(5) rfc8392 (ietf.org).

(6) rfc7159 (ietf.org).

(7) rfc7049 (ietf.org).

(8) Regulamento (UE) 2021/953 do Parlamento Europeu e do Conselho de 14 de junho de 2021 relativo a um regime para a emissão, verificação e aceitação de certificados interoperáveis de vacinação, teste e recuperação da COVID-19 (Certificado Digital COVID da UE), a fim de facilitar a livre circulação durante a pandemia de COVID-19, JO L 211 de 15.6.2021, p. 1.

(9) rfc1950 (ietf.org).

(10) rfc1951 (ietf.org).

(11) rfc7517 (ietf.org).