ÍNDICE
1.Introdução9
1.1.Visão geral e âmbito de aplicação da presente política9
1.2.Definições e siglas11
1.3.Participantes da PKI13
1.3.1.Introdução13
1.3.2.Autoridade da política de certificação de STI-C16
1.3.3.Gestor da lista aprovada17
1.3.4.Auditor acreditado da PKI17
1.3.5.Ponto de contacto para STI-C (CPOC)17
1.3.6.Funções operacionais18
1.4.Utilização de certificados18
1.4.1.Domínios de utilização aplicáveis18
1.4.2.Limites de responsabilidade19
1.5.Administração da política de certificação19
1.5.1.Atualização dos CPS de CA enumerados no ECTL19
1.5.2.Procedimentos de aprovação da CPS20
2.Responsabilidades de publicação e criação de repositórios20
2.1.Métodos para a publicação de informações de certificados20
2.2.Altura ou frequência de publicação21
2.3.Repositórios21
2.4.Controlos de acesso a repositórios21
2.5.Publicação de informações de certificados22
2.5.1.Publicação de informações de certificados pelo TLM22
2.5.2.Publicação de informações de certificados pelas CA22
3.Identificação e autenticação23
3.1.Nomenclatura23
3.1.1.Tipos de nomes23
3.1.1.1.Nomes para TLM, CA de raiz, EA e AA23
3.1.1.2.Nomes para as entidades finais23
3.1.1.3.Identificação de certificados23
3.1.2.Necessidade de os nomes serem significativos23
3.1.3.Anonimato e pseudonímia das entidades finais23
3.1.4.Regras de interpretação das diversas formas de nomes23
3.1.5.Exclusividade dos nomes24
3.2.Validação inicial de identidade24
3.2.1.Método para demonstrar posse de chave privada24
3.2.2.Autenticação de identidade de uma organização24
3.2.2.1.Autenticação da identidade de uma organização de CA24
3.2.2.2.Autenticação da identidade de uma organização do TLM25
3.2.2.3.Autenticação da identidade de uma organização de CA subordinadas25
3.2.2.4.Autenticação da organização do subscritor da entidade final26
3.2.3.Autenticação de entidade individual26
3.2.3.1.Autenticação de entidade individual de TLM/CA26
3.2.3.2.Autenticação de identidade de subscritores de estações de STI-C27
3.2.3.3.Autenticação de identidade de estações de STI-C27
3.2.4.Informações de subscritor não verificadas27
3.2.5.Validação de autoridade27
3.2.5.1.Validação de TLM, CA de raiz, EA, AA27
3.2.5.2.Validação de subscritores de estações de STI-C28
3.2.5.3.Validação de estações de STI-C28
3.2.6.Critérios de interoperação28
3.3.Identificação e autenticação para pedidos de reemissão de chave28
3.3.1.Identificação e autenticação para pedidos de reemissão de chave de rotina28
3.3.1.1.Certificados de TLM28
3.3.1.2.Certificados de CA de raiz28
3.3.1.3.Renovação ou reemissão de chave de certificados de EA/AA28
3.3.1.4.Credenciais de inscrição de entidades finais29
3.3.1.5.Bilhetes de autorização das entidades finais29
3.3.2.Identificação e autenticação para pedidos de reemissão de chave após revogação29
3.3.2.1.Certificados de CA29
3.3.2.2.Credenciais de inscrição de entidades finais29
3.3.2.3.Pedidos de autorização de entidades finais29
3.4.Identificação e autenticação para pedidos de revogação29
3.4.1.Certificados de CA de raiz/EA/AA29
3.4.2.Credenciais de inscrição de estações de STI-C30
3.4.3.Certificados de autorização de estações de STI-C30
4.Requisitos operacionais do ciclo de vida dos certificados30
4.1.Pedido de certificado30
4.1.1.Quem pode submeter um pedido de certificado30
4.1.1.1.CA de raiz30
4.1.1.2.TLM31
4.1.1.3.EA e AA31
4.1.1.4.Estação de STI-C31
4.1.2.Processo de inscrição e responsabilidades31
4.1.2.1.CA de raiz31
4.1.2.2.TLM32
4.1.2.3.EA e AA32
4.1.2.4.Estação de STI-C32
4.2.Processamento de pedidos de certificado33
4.2.1.Realização de funções de identificação e autenticação33
4.2.1.1.Identificação e autenticação de CA de raiz33
4.2.1.2.Identificação e autenticação de TLM33
4.2.1.3.Identificação e autenticação de EA e AA33
4.2.1.4.Identificação e autenticação de subscritores de EE34
4.2.1.5.Certificados de autorização34
4.2.2.Aprovação ou rejeição de pedidos de certificado34
4.2.2.1.Aprovação ou rejeição de certificados de CA de raiz34
4.2.2.2.Aprovação ou rejeição de certificados de TLM34
4.2.2.3.Aprovação ou rejeição de certificados de EA e AA34
4.2.2.4.Aprovação ou rejeição de EC34
4.2.2.5.Aprovação ou rejeição de CA35
4.2.3.Tempo de processamento do pedido de certificado35
4.2.3.1.Pedido de certificado da CA de raiz35
4.2.3.2.Pedido de certificado do TLM35
4.2.3.3.Pedido de certificado da EA e AA35
4.2.3.4.Pedido de EC35
4.2.3.5.Pedido de CA35
4.3.Emissão do certificado35
4.3.1.Ações da CA durante a emissão de certificados35
4.3.1.1.Emissão de certificados de CA de raiz35
4.3.1.2.Emissão de certificados de TLM36
4.3.1.3.Emissão de certificados de EA e AA36
4.3.1.4.Emissão de EC36
4.3.1.5.Emissão de CA36
4.3.2.Notificação da CA aos subscritores da emissão de certificados.36
4.4.Aceitação de certificados37
4.4.1.Realização da aceitação de certificados37
4.4.1.1.CA de raiz37
4.4.1.2.TLM37
4.4.1.3.EA e AA37
4.4.1.4.Estação de STI-C37
4.4.2.Publicação do certificado37
4.4.3.Notificação de emissão de certificado37
4.5.Par de chaves e utilização do certificado37
4.5.1.Chave privada e utilização do certificado37
4.5.1.1.Chave privada e utilização de certificados para TLM37
4.5.1.2.Chave privada e utilização de certificados para CA de raiz37
4.5.1.3.Chave privada e utilização de certificados para EA e AA37
4.5.1.4.Chave privada e utilização de certificados para a entidade final38
4.5.2.Chave pública e utilização de certificados da parte utilizadora38
4.6.Renovação de certificado38
4.7.Reemissão de chave de certificado38
4.7.1.Circunstâncias para a reemissão de chave de certificado38
4.7.2.Quem pode solicitar a reemissão de chave38
4.7.2.1.CA de raiz38
4.7.2.2.TLM38
4.7.2.3.EA e AA38
4.7.2.4.Estação de STI-C39
4.7.3.Processo de reemissão de chave39
4.7.3.1.Certificado do TLM39
4.7.3.2.Certificado da CA de raiz39
4.7.3.3.Certificados de EA e AA39
4.7.3.4.Certificados da estação de STI-C40
4.8.Alteração de certificado40
4.9.Revogação e suspensão de certificado40
4.10.Serviços de estado de certificado40
4.10.1.Características operacionais40
4.10.2.Disponibilidade do serviço40
4.10.3.Características facultativas40
4.11.Fim da subscrição40
4.12.Retenção e recuperação de chaves40
4.12.1.Subscritor40
4.12.1.1.Que par de chaves pode ser retido40
4.12.1.2Quem pode submeter um pedido de recuperação40
4.12.1.3.Processo de recuperação e responsabilidades40
4.12.1.4.Identificação e autenticação40
4.12.1.5Aprovação ou rejeição de pedidos de recuperação40
4.12.1.6.Ações da autoridade de retenção de chaves e da autoridade de recuperação de chaves durante a recuperação do par de chaves41
4.12.1.7.Disponibilidade da autoridade de retenção de chaves e da autoridade de recuperação de chaves41
4.12.2.Política e práticas de encapsulação e recuperação de chaves de sessão41
5.Instalações, gestão e controlos operacionais41
5.1.Controlos físicos41
5.1.1.Localização física e construção41
5.1.1.1.CA de raiz, CPOC e TLM41
5.1.1.2.EA/AA42
5.1.2.Acesso físico42
5.1.2.1.CA de raiz, CPOC e TLM42
5.1.2.2.EA/AA43
5.1.3.Energia e ar condicionado43
5.1.4.Exposição à água43
5.1.5.Prevenção e proteção contra incêndios44
5.1.6.Gestão de suportes44
5.1.7.Eliminação de resíduos44
5.1.8.Salvaguarda fora do local44
5.1.8.1.CA de raiz, CPOC e TLM44
5.1.8.2.EA/AA45
5.2.Procedimentos de controlo45
5.2.1.Funções de confiança45
5.2.2.Número de pessoas necessário por tarefa45
5.2.3.Identificação e autenticação para cada função46
5.2.4.Funções que requerem a separação de tarefas46
5.3.Controlos de pessoal47
5.3.1.Requisitos relativos a qualificações, experiência e credenciação47
5.3.2.Procedimentos de verificação de antecedentes47
5.3.3.Requisitos de formação48
5.3.4.Frequência e requisitos de ações de reciclagem48
5.3.5.Frequência e sequência da rotação de funções48
5.3.6.Sanções para ações não autorizadas48
5.3.7.Requisitos aplicáveis aos contratantes independentes49
5.3.8.Documentação fornecida ao pessoal49
5.4.Procedimentos de registo de auditorias49
5.4.1.Tipos de eventos a serem registados e comunicados por cada CA49
5.4.2.Frequência do registo de processamento50
5.4.3.Período de conservação de registos de auditoria50
5.4.4.Proteção de registos de auditoria51
5.4.5.Procedimentos de salvaguarda de registos de auditoria51
5.4.6.Sistema de recolha de auditorias (interno ou externo)51
5.4.7.Notificação ao sujeito causador de evento51
5.4.8.Avaliação de vulnerabilidades51
5.5.Arquivo de registos52
5.5.1.Tipos de registos arquivados52
5.5.2.Período de conservação de arquivos53
5.5.3.Proteção de arquivos53
5.5.4.Arquivo e armazenamento do sistema53
5.5.5.Requisitos de validação cronológica de registos54
5.5.6.Sistema de recolha de arquivos (interno ou externo)54
5.5.7.Procedimentos para obter e verificar informações do arquivo54
5.6.Transferência da chave para elementos do modelo de confiança de STI-C54
5.6.1.TLM54
5.6.2.CA de raiz54
5.6.3.Certificado da EA/AA54
5.6.4.Auditor55
5.7.Recuperação em caso de comprometimento e catástrofe55
5.7.1.Tratamento de incidentes e comprometimentos55
5.7.2.Corrupção de recursos informáticos, aplicações informáticas e/ou dados56
5.7.3.Procedimentos em caso de comprometimento de chaves privadas de entidades56
5.7.4.Capacidade de continuidade das atividades em caso de catástrofe56
5.8.Cessação e transferência57
5.8.1.TLM57
5.8.2.CA de raiz57
5.8.3.EA/AA58
6.Controlos de segurança técnica58
6.1.Geração e instalação de pares de chaves58
6.1.1.TLM, CA de raiz, EA, AA58
6.1.2.EE — estação móvel de STI-C58
6.1.3.EE — estação fixa de STI-C59
6.1.4.Requisitos de criptografia59
6.1.4.1.Comprimento de algoritmos e chaves — algoritmos de assinatura59
6.1.4.2.Comprimento de algoritmos e chaves — algoritmos de encriptação para inscrição e autorização60
6.1.4.3.Criptoagilidade61
6.1.5.Armazenamento seguro de chaves privadas61
6.1.5.1.Nível de CA de raiz, CA subordinada e TLM61
6.1.5.2.Entidade final62
6.1.6.Salvaguarda de chaves privadas63
6.1.7.Destruição de chaves privadas63
6.2.Dados de ativação63
6.3.Controlos de segurança informática63
6.4.Controlos técnicos do ciclo de vida63
6.5.Controlos de segurança de rede63
7.Perfis de certificados, CRL e CTL63
7.1.Perfil do certificado63
7.2.Validade do certificado64
7.2.1.Certificados de pseudónimos64
7.2.2.Bilhetes de autorização para estações de STI-C fixas65
7.3.Revogação de certificados65
7.3.1.Revogação de certificados de CA, EA e AA65
7.3.2.Revogação de credenciais de inscrição66
7.3.3.Revogação de bilhetes de autorização66
7.4.Lista de revogação de certificados66
7.5.Lista aprovada de certificados europeus66
8.Auditoria de conformidade e outras avaliações66
8.1.Aspetos abrangidos pela auditoria e base da auditoria66
8.2.Frequência das auditorias67
8.3.Identidade/qualificações do auditor67
8.4.Relação do auditor com a entidade auditada67
8.5.Medidas tomadas face a deficiência67
8.6.Comunicação dos resultados68
9.Outras disposições68
9.1.Taxas68
9.2.Responsabilidade financeira68
9.3.Confidencialidade das informações comerciais69
9.4.Plano de privacidade69
10.Referências69
ANEXO III
1.Introdução
1.1.Visão geral e âmbito de aplicação da presente política
A presente política de certificação define o modelo europeu de confiança de STI-C baseado numa infraestrutura de chave pública (PKI) no âmbito do sistema geral de gestão de credenciais de segurança dos STI-C da UE (EU CCMS). Define requisitos para a gestão de certificados de chave pública para aplicações STI-C por entidades emissoras e a sua utilização por entidades finais na Europa. No seu nível mais elevado, a PKI é composta de um conjunto de CA de raiz «ativadas» devido ao facto de o gestor da lista aprovada (TLM) inserir os seus certificados numa lista aprovada de certificados europeus (ECTL), que é emitida e publicada pela entidade central do TLM (ver secções 1.2 e 1.3).
A presente política é vinculativa para todas as entidades que participam no sistema STI-C na Europa. Funciona como auxílio na avaliação do nível de confiança que pode ser estabelecido em relação às informações recebidas por qualquer recetor de uma mensagem autenticada por um certificado de entidade final da PKI. Para permitir a avaliação da confiança nos certificados fornecidos pelo EU CCMS, estabelece um conjunto obrigatório de requisitos para a operação da entidade central do TLM e a compilação e gestão da ECTL. Por conseguinte, o presente documento rege os seguintes aspetos relacionados com a ECTL:
·identificação e autenticação de diretores que obtêm funções de PKI para o TLM, incluindo declarações dos privilégios atribuídos a cada função;
·requisitos mínimos para práticas de segurança locais para o TLM, incluindo controlos físicos, de pessoal e processuais;
·requisitos mínimos para práticas de segurança técnica para o TLM, nomeadamente segurança informática, segurança de rede e controlos de engenharia de módulos criptográficos;
·requisitos mínimos para práticas operacionais para o TLM, incluindo o registo de novos certificados de CA de raiz, o cancelamento temporário ou permanente de CA de raiz existentes e incluídas e a publicação e distribuição de atualizações da ECTL;
·um perfil da ECTL, incluindo todos os campos de dados obrigatórios e facultativos na ECTL, algoritmos criptográficos a utilizar, o formato exato da ECTL e recomendações para o processamento da ECTL;
·gestão do ciclo de vida de certificados da ECTL, incluindo a distribuição de certificados da ECTL, a ativação, a expiração e a revogação;
·gestão da revogação da confiança das CA de raiz quando necessário.
Uma vez que a confiabilidade da ECTL não depende somente da própria ECTL, mas em grande parte também das CA de raiz que compõem a PKI e respetivas CA subordinadas, a presente política também estabelece requisitos mínimos, que são obrigatórios para todas as CA participantes (CA de raiz e CA subordinadas). As áreas sujeitas a requisitos são:
·identificação e autenticação de diretores que obtêm funções de PKI (por exemplo, agentes de segurança, responsáveis pelas questões de privacidade, administradores de segurança, administradores de diretório e utilizadores finais), incluindo uma declaração de deveres, obrigações, responsabilidades e privilégios associados a cada função;
·gestão de chaves, incluindo algoritmos aceitáveis e obrigatórios de assinatura de certificados e de assinatura de dados e períodos de validade de certificados;
·requisitos mínimos para práticas de segurança locais, incluindo controlos físicos, de pessoal e processuais;
·requisitos mínimos para práticas de segurança técnica, como segurança informática, segurança de rede e controlos de engenharia de módulos criptográficos;
·requisitos mínimos para as práticas operacionais da CA, EA AA e entidades finais, nomeadamente, aspetos do registo, do cancelamento de registos (retirada da lista), da revogação, do comprometimento de chaves, da demissão por justa causa, da atualização de certificados, das práticas de auditoria e da não divulgação de informações relacionadas com a privacidade;
·certificado e perfil da CRL, incluindo formatos, algoritmos aceites, campos de dados obrigatórios e opcionais e respetivos intervalos de valores válidos, e a forma como os verificadores devem processar os certificados;
·deveres de monitorização regular, elaboração de relatórios, emissão de alertas e restauração das entidades do modelo de confiança de STI-C, a fim de estabelecer uma operação segura, inclusive em casos de comportamento indevido.
Além dos referidos requisitos mínimos, as entidades que gerem as CA de raiz e CA subordinadas podem decidir os seus próprios requisitos adicionais e defini-los nas declarações de práticas de certificação (CPS) pertinentes, desde que não contradigam os requisitos definidos na política de certificação. Para mais informações sobre o modo como as CPS são auditadas e publicadas, ver secção 1.5.
A CP também estabelece as finalidades para as quais as CA de raiz e CA subordinadas, bem como os respetivos certificados emitidos, podem ser utilizados. Estabelece as responsabilidades assumidas:
·pelo TLM;
·por cada CA de raiz cujos certificados constem na ECTL;
·pelas CA subordinadas da CA de raiz (EA e AA);
·por cada membro ou organização responsável por, ou que opere, uma das entidades do modelo de confiança de STI-C.
A CP define igualmente as obrigações obrigatórias aplicáveis:
·ao TLM;
·a cada CA de raiz cujos certificados constem na ECTL;
·a cada CA subordinada certificada por uma CA de raiz;
·a todas as entidades finais;
·a cada membro da organização responsável por, ou que opere, uma das entidades do modelo de confiança de STI-C.
Por último, a CP estabelece requisitos no que diz respeito à documentação das limitações de responsabilidades e obrigações na CPS de cada CA de raiz cujos certificados constem na ECTL.
A presente CP está em linha com a política de certificação e o quadro de práticas de certificação adotado pela Internet Engineering Task Force (IETF)[3].
1.2.Definições e siglas
Aplicam-se as definições de [2], [3] e [4].
|
AA
|
autoridade de autorização
|
|
CA
|
certificado de autorização
|
|
CA
|
autoridade de certificação
|
|
CP
|
política de certificação
|
|
CPA
|
autoridade da política de certificação de STI-C
|
|
CPOC
|
ponto de contacto para STI-C
|
|
CPS
|
declaração de práticas de certificação
|
|
CRL
|
lista de revogação de certificados
|
|
EA
|
autoridade de inscrição
|
|
EC
|
credencial de inscrição
|
|
ECIES
|
esquema integrado de curva de criptografia elítica
|
|
EE
|
entidade final (ou seja, estação de STI-C)
|
|
ECTL
|
Lista aprovada de certificados europeus
|
|
EU CCMS
|
sistema de gestão de credenciais de segurança dos STI-C da UE
|
|
GDPR
|
Regulamento Geral sobre a Proteção de Dados:
|
|
HSM
|
módulo de segurança do equipamento
|
|
PKI
|
infraestrutura de chave pública
|
|
RA
|
autoridade de registo
|
|
CA subordinada
|
EA e AA
|
|
TLM
|
gestor da lista aprovada
|
Glossário
|
requerente
|
A pessoa singular ou entidade jurídica que solicita (ou pretende renovar) um certificado. Uma vez criado o certificado inicial (inicialização), o requerente é referido como o subscritor.
Para certificados emitidos para entidades finais, o subscritor (requerente do certificado) é a entidade que controla ou opera/mantém a entidade final para a qual o certificado é emitido, mesmo se a entidade final enviar o pedido de certificado real.
|
|
autoridade de autorização
|
No presente documento, o termo «autoridade de autorização» (AA) refere-se não apenas à função específica da AA, mas também à entidade jurídica e/ou operacional que o gere.
|
|
autoridade de certificação
|
A autoridade de certificação de raiz, a autoridade de inscrição e a autoridade de autorização são cumulativamente referidas como a autoridade de certificação (CA).
|
|
Modelo de confiança de STI-C
|
O modelo de confiança de STI-C é responsável por estabelecer uma relação de confiança entre as estações de STI-C. É implementada através da utilização de uma PKI composta de CA de raiz, o CPOC, o TLM, as EA e AA e uma rede segura.
|
|
Criptoagilidade
|
A capacidade das entidades do modelo de confiança de STI-C de adaptar a CP a ambientes em mudança ou a novos requisitos futuros, por exemplo, através da mudança de algoritmos criptográficos e de comprimento da chave ao longo do tempo
|
|
módulo criptográfico
|
Um elemento seguro baseado em equipamento informático no qual as chaves são geradas e/ou armazenadas, são gerados números aleatórios e os dados são assinados ou encriptados.
|
|
autoridade de inscrição
|
No presente documento, o termo «autoridade de inscrição» (EA) refere-se não apenas à função específica da EA, mas também à entidade jurídica e/ou operacional que o gere.
|
|
Participantes da PKI
|
Entidades do modelo de confiança de STI-C, a saber, o TLM, as CA de raiz, as EA, as AA e as estações de STI-C.
|
|
reemissão de chave
|
|
|
repositório
|
O repositório utilizado para armazenar os certificados e informações sobre certificados fornecidos pelas entidades do modelo de confiança de STI-C, conforme definido na secção 2.3.
|
|
autoridade de certificação de raiz
|
No presente documento, o termo «autoridade de certificação de raiz» (CA) refere-se não apenas à função específica da CA, mas também à entidade jurídica e/ou operacional que o gere.
|
|
sujeito
|
A pessoa singular, dispositivo, sistema, unidade ou entidade jurídica identificada num certificado como o sujeito, ou seja, o subscritor ou um dispositivo sob o controlo e a operação do subscritor.
|
|
subscritor
|
Pessoa singular ou entidade jurídica à qual é emitido um certificado e que está juridicamente vinculada por um contrato de subscritor ou termos de utilização.
|
|
contrato de subscritor
|
Um acordo entre a CA e o requerente/subscritor que especifica os direitos e as responsabilidades das partes.
|
1.3.Participantes da PKI
1.3.1.Introdução
Os participantes da PKI desempenham uma função na PKI definida pela presente política. A menos que seja explicitamente proibido, um participante pode assumir várias funções em simultâneo. Pode estar proibido de assumir funções específicas em simultâneo, a fim de evitar conflitos de interesses ou garantir a separação de tarefas.
Os participantes também podem delegar partes da sua função a outras entidades no âmbito de um contrato de serviços. Por exemplo, quando as informações de estado de revogação são fornecidas utilizando CRL, a CA também é o emissor da CRL, mas pode delegar a responsabilidade de emitir CRL numa entidade diferente.
As funções da PKI consistem em:
·funções de autoridade, ou seja, cada função é instanciada de forma única;
·funções operacionais, ou seja, funções que podem ser instanciadas em uma ou mais entidades.
Por exemplo, uma CA de raiz pode ser implementada por uma entidade comercial, um grupo de interesse comum, uma organização nacional e/ou uma organização europeia.
A
Figure 1
mostra a arquitetura do modelo de confiança STI-C baseada na [2]. A arquitetura é aqui brevemente descrita, mas os principais elementos são descritos em maior detalhe nas secções 1.3.2 a 1.3.6.
A CPA nomeia o TLM, que é, por conseguinte, uma entidade de confiança para todos os participantes da PKI. A CPA aprova a operação da CA de raiz e confirma que o TLM pode confiar na(s) CA de raiz. O TLM emite a ECTL que garante a confiança das CA de raiz aprovadas a todos os participantes da PKI. A CA de raiz emite certificados para a EA e a AA, garantindo assim confiança na sua operação. A EA emite certificados de inscrição para as estações STI-C de envio e retransmissão (como entidades finais), garantindo assim confiança na sua operação. A AA emite CA para as estações de STI-C com base na confiança na EA.
A estação de STI-C de receção e retransmissão (como parte retransmissora) pode confiar noutras estações de STI-C, uma vez que os CA são emitidos por uma AA de confiança aprovada por uma CA de raiz, que é aprovada pelo TLM e pela CPA.
Observe-se que a
Figure 1
descreve apenas o nível da CA de raiz do modelo de confiança do STI-C. Os detalhes das camadas inferiores são apresentados nas secções subsequentes da presente CP ou na CPS das CA de raiz específicas.
A
Figure 2
fornece uma visão geral dos fluxos de informação entre os participantes da PKI. Os pontos verdes indicam fluxos que exigem comunicações máquina a máquina. Os fluxos de informação a vermelho definiram requisitos de segurança.
O modelo de confiança de STI-C baseia-se numa arquitetura de CA de raiz múltipla, em que os certificados da CA raiz são transmitidos periodicamente (conforme estabelecido abaixo) para o ponto central de contacto (CPOC) por meio de um protocolo seguro (por exemplo, certificados de ligação) definido pelo CPOC.
Uma CA de raiz pode ser operada por uma organização governamental ou privada. A arquitetura do modelo de confiança de STI-C contém pelo menos uma CA de raiz (a CA de raiz da UE com o mesmo nível que as outras CA de raiz). A CA de raiz da UE é delegada por todas as entidades que participam no modelo de confiança de STI-C que não pretendem configurar sua própria CA de raiz. O CPOC transmite os certificados da CA de raiz recebidos ao TLM, que é responsável por recolher e assinar a lista de certificados da CA de raiz e os enviar de volta ao CPOC, o que os torna publicamente disponíveis para todos (ver abaixo).
As relações de confiança entre as entidades no modelo de confiança de STI-C são descritas nas figuras, nos quadros e nas secções a seguir.
Figura 1: Arquitetura do modelo de confiança de STI-C
Figura 2: Fluxos de informação do modelo de confiança de STI-C
|
ID do fluxo
|
De
|
Para
|
Conteúdo
|
Referência
|
|
(1).
|
CPA
|
TLM
|
aprovação do pedido da CA de raiz
|
8
|
|
(2).
|
CPA
|
TLM
|
informações sobre revogação da CA de raiz
|
8.5
|
|
(3).
|
CPA
|
CA de raiz
|
atualizações da CP
|
1.5
|
|
(4).
|
CPA
|
CA de raiz
|
aprovação/rejeição do formulário de pedido da CA de raiz ou das alterações do pedido da CPS ou do processo de auditoria.
|
8.5, 8.6
|
|
(5).
|
TLM
|
CPA
|
notificação de alteração da ECTL
|
4, 5.8.1
|
|
(6).
|
TLM
|
CPOC
|
Certificado do TLM
|
4.4.2
|
|
(7).
|
TLM
|
CPOC
|
ECTL
|
4.4.2
|
|
(8).
|
CPOC
|
TLM
|
informações de certificado da CA de raiz
|
4.3.1.1
|
|
(9).
|
CPOC
|
TLM
|
revogação de certificado da CA de raiz
|
7.3
|
|
(10).
|
CPOC
|
todas as entidades finais
|
certificado do TLM
|
4.4.2
|
|
(11).
|
CA de raiz
|
CPOC
|
informações de certificado da CA de raiz
|
4.3.1.1
|
|
(12).
|
CA de raiz
|
CPOC
|
revogação de certificado da CA de raiz
|
7.3
|
|
(13).
|
CA de raiz
|
auditor
|
pedido de auditoria
|
8
|
|
(14).
|
CA de raiz
|
CPA
|
formulário de pedido da CA de raiz — pedido inicial
|
4.1.2.1
|
|
(15).
|
CA de raiz
|
CPA
|
formulário de pedido da CA de raiz — alterações da CPS
|
1.5.1
|
|
(16).
|
CA de raiz
|
CPA
|
formulário de pedido da CA de raiz — relatório de auditoria
|
8.6
|
|
(17).
|
CA de raiz
|
CPA
|
relatórios de incidentes da CA de raiz, nomeadamente a revogação de uma CA subordinada (EA, AA)
|
Anexo III, 7.3.1
|
|
(18).
|
CA de raiz
|
EA
|
resposta do certificado da EA
|
4.2.2.3
|
|
(19).
|
CA de raiz
|
AA
|
resposta de certificado da AA
|
4.2.2.3
|
|
(20).
|
CA de raiz
|
Todos
|
certificado da EA/AA, CRL
|
4.4.2
|
|
(21).
|
EA
|
CA de raiz
|
pedido de certificado da EA
|
4.2.2.3
|
|
(22).
|
EA
|
Estação de STI-C
|
resposta de credencial de inscrição
|
4.3.1.4
|
|
(23).
|
EA
|
AA
|
resposta de autorização
|
4.2.2.5
|
|
(24).
|
AA
|
CA de raiz
|
pedido de certificado da AA
|
4.2.2.3
|
|
(25).
|
AA
|
EA
|
pedido de autorização
|
4.2.2.5
|
|
(26).
|
AA
|
Estação de STI-C
|
resposta de bilhete de autorização
|
4.3.1.5
|
|
(27).
|
EA
|
CA de raiz
|
submissão de pedido
|
4.1.2.3
|
|
(28).
|
AA
|
CA de raiz
|
submissão de pedido
|
4.1.2.3
|
|
(29).
|
CA de raiz
|
EA
|
resposta
|
4.12 e 4.2.1
|
|
(30).
|
CA de raiz
|
AA
|
resposta
|
4.12 e 4.2.1
|
|
(31).
|
Estação de STI-C
|
EA
|
pedido de credencial de inscrição
|
4.2.2.4
|
|
(32).
|
Estação de STI-C
|
AA
|
pedido de certificado de autorização
|
4.2.2.5
|
|
(33).
|
fabricante/operador
|
EA
|
registo
|
4.2.1.4
|
|
(34).
|
fabricante/operador
|
EA
|
desativação
|
7.3
|
|
(35).
|
EA
|
fabricante/operador
|
resposta
|
4.2.1.4
|
|
(36).
|
auditor
|
CA de raiz
|
relatório
|
8.1
|
|
(37).
|
todos
|
CPA
|
pedido de alteração da CP
|
1.5
|
|
(38).
|
TLM
|
CPA
|
formulário de pedido
|
4.1.2.2
|
|
(39).
|
CPA
|
TLM
|
aprovação/rejeição
|
4.1.2.2
|
|
(40).
|
TLM
|
CPA
|
Relatório de auditoria
|
4.1.2.2
|
Quadro 1:
Descrição detalhada dos fluxos de informação no modelo de confiança de STI-C
1.3.2.Autoridade da política de certificação de STI-C
(1)A autoridade da política de certificação (CPA) de STI-C é composta pelos representantes dos intervenientes públicos e privados (por exemplo, Estados-Membros, fabricantes de veículos, etc.) que participam no modelo de confiança de STI-C. É responsável por duas subfunções:
(1)gestão da política de certificação, nomeadamente:
·aprovação da presente CP e futuros pedidos de alteração da CP;
·decisão sobre a análise de pedidos de alteração da CP e recomendações enviadas por outros participantes ou entidades da PKI;
·decisão sobre o lançamento de novas versões da CP;
(2)gestão das autorizações da PKI, nomeadamente:
·definir, decidir e publicar a aprovação da CPS e os procedimentos de auditoria da CA (coletivamente designados «procedimentos de aprovação da CA»);
·autorizar o CPOC a operar e apresentar relatórios periodicamente;
·autorizar o TLM a operar e apresentar relatórios periodicamente;
·aprovação da CPS da CA de raiz, se estiver de acordo com a CP comum e válida;
·escrutínio dos relatórios de auditoria do auditor acreditado da PKI para todas as CA de raiz;
·notificar o TLM sobre a lista das CA de raiz aprovadas ou não aprovadas e respetivos certificados com base nos relatórios de aprovação recebidos das CA de raiz e nos relatórios de operações regulares.
(2)O representante autorizado da CPA é responsável por autenticar o representante autorizado do TLM e aprovar o formulário de pedido do processo de inscrição do TLM. A CPA é responsável por autorizar que o TLM opere conforme estabelecido na presente secção.
1.3.3.Gestor da lista aprovada
(3)O TLM é uma entidade única designada pela CPA.
(4)O TLM é responsável:
·pela operação da ECTL de acordo com a CP comum válida e a apresentação regular de relatórios de atividades à CPA para a operação geral segura do modelo de confiança de STI-C;
·por receber certificados de CA do CPOC;
·por incluir/excluir certificados de CA de raiz na ECTL após notificação pela CPA;
·por assinar a ECTL;
·pela comunicação regular e atempada da ECTL ao CPOC.
1.3.4.Auditor acreditado da PKI
(5)O auditor da PKI acreditado é responsável por:
·executar ou organizar auditorias de CA de raiz, TLM e CA subordinada;
·distribuir o relatório de auditoria (de uma auditoria inicial ou periódica) à CPA, de acordo com os requisitos da secção 8 abaixo. O relatório de auditoria deve incluir recomendações do auditor da PKI acreditado;
·notificar a entidade que gere a CA de raiz do sucesso ou insucesso da realização de uma auditoria inicial ou periódica das CA subordinadas;
·avaliar a conformidade da CPS com a presente CP.
1.3.5.Ponto de contacto para STI-C (CPOC)
(6)O CPOC é uma entidade única designada pela CPA. O representante autorizado da CPA é responsável por autenticar o representante autorizado do CPOC e aprovar o formulário de registo do processo de inscrição do CPOC. A CPA é responsável por autorizar que o CPOC opere conforme estabelecido na presente secção.
(7)O CPOC é responsável por:
·estabelecer e contribuir para o intercâmbio seguro de comunicações entre todas as entidades do modelo de confiança de STI-C de forma eficiente e rápida;
·analisar pedidos e recomendações de alteração de procedimentos enviados por outros participantes do modelo de confiança (por exemplo, CA de raiz);
·transmitir certificados da CA de raiz ao TLM;
·publicar a âncora de confiança comum (chave pública atual e certificado de ligação do TLM);
·publicar a ECTL.
A secção 7 contém todos os detalhes relativos à ECTL.
1.3.6.Funções operacionais
(8)As seguintes entidades definidas na norma [2] desempenham uma função operacional, conforme definido no RFC 3647:
|
Elemento funcional
|
Função da PKI ([3] e [4])
|
Função detalhada ([2])
|
|
autoridade de certificação de raiz
|
CA/RA (autoridade de registo)
|
Comprova à EA e AA que pode emitir EC e CA
|
|
autoridade de inscrição
|
subscritor da CA de raiz/sujeito do certificado da EA
CA/RA
|
Autentica uma estação de STI-C e concede-lhe acesso a comunicações STI
|
|
autoridade de autorização
|
subscritor da CA de raiz/sujeito do certificado da AA
CA/RA
|
Comprova irrefutavelmente à estação de STI-C que pode utilizar serviços de STI específicos
|
|
estação de STI-C remetente
|
sujeito do certificado (EE) da entidade final (EE)
|
Adquire os direitos da EA para aceder a comunicações STI
Negoceia os direitos de AA de invocar serviços STI
Envia mensagens de difusão de salto único e retransmitidas
|
|
estação de STI-C de retransmissão (encaminhamento)
|
parte retransmissora / sujeito do certificado de EE
|
Recebe a mensagem de difusão da estação de STI-C remetente e encaminha-a para a estação de STI-C recetora, se necessário
|
|
estação de STI-C recetora
|
parte retransmissora
|
Recebe mensagens de difusão da estação de STI-C remetente ou retransmissora
|
|
fabricante
|
subscritor da EA
|
Instala informações necessárias para a gestão de segurança na estação de STI-C na produção
|
|
operador
|
subscritor da EA/AA
|
Instala e atualiza informações necessárias para a gestão de segurança na estação de STI-C durante a operação
|
Quadro 2: Funções operacionais
Nota: de acordo com a norma [4], a presente CP utiliza termos diferentes para o «subscritor» que contrata a CA para a emissão de certificados e o «sujeito» ao qual o certificado se aplica. São subscritores todas as entidades que possuem uma relação contratual com uma CA. Os sujeitos são as entidades às quais o certificado se aplica. As EA/AA agem na qualidade de subscritores e sujeitos da CA de raiz e podem solicitar certificados EA/AA. As estações de STI-C são sujeitos e podem solicitar certificados de entidade final.
(9)Autoridades de registo:
A EA deve desempenhar a função de uma autoridade de registo para entidades finais. Apenas os subscritores autenticados e autorizados podem registar novas entidades finais (estações de STI-C) numa EA. As CA de raiz pertinentes devem desempenhar a função de autoridades de registo para EA e AA.
1.4.Utilização de certificados
1.4.1.Domínios de utilização aplicáveis
(10)Os certificados emitidos ao abrigo da presente CP destinam-se a ser utilizados para validar assinaturas digitais no contexto de comunicações de STI cooperativos de acordo com a arquitetura de referência da norma [2].
(11)Os perfis de certificado da norma [5] determinam utilizações de certificados para o TLM, a CA de raiz, as EA, as AA e as entidades finais.
1.4.2.Limites de responsabilidade
(12)Os certificados não se destinam a ser utilizados, nem podem sê-lo, em:
·circunstâncias que infrinjam, violem ou se oponham a qualquer lei, regulamento (por exemplo, o GDPR), decreto ou decisão aplicável do governo;
·circunstâncias que violem ou infrinjam os direitos de terceiros;
·violem a presente CP ou o contrato de subscritor pertinente;
·quaisquer circunstâncias em que a respetiva utilização possa levar diretamente à morte, a lesões corporais ou danos ambientais graves (por exemplo, por falha na operação de instalações nucleares, na navegação ou comunicação de aeronaves ou em sistemas de controlo de armas);
·circunstâncias que contrariem os objetivos gerais de uma maior segurança rodoviária e de transportes rodoviários mais eficientes na Europa.
1.5.Administração da política de certificação
1.5.1.Atualização de CPS das CA incluídas na ECTL
(13)Cada CA de raiz incluída na ECTL deve publicar a sua própria CPS, que deve estar em conformidade com a presente política. Uma CA de raiz pode acrescentar requisitos adicionais, mas deve garantir o cumprimento permanente de todos os requisitos da presente CP.
(14)Cada CA de raiz incluída na ECTL deve implementar um processo de alteração apropriado para o seu documento CPS. As principais propriedades do processo de alteração devem ser documentadas na parte pública da CPS.
(15)O processo de alteração deve assegurar que todas as alterações à presente CP são cuidadosamente analisadas e, se necessário para o cumprimento da CP de acordo com as alterações, que a CPS é atualizada dentro do prazo estabelecido na etapa de implementação do processo de alteração para a CP. Em especial, o processo de alteração deve envolver procedimentos de alteração de emergência que garantam a implementação atempada de alterações à CP que sejam relevantes no que respeita à segurança.
(16)O processo de alteração deve incluir medidas apropriadas para verificar a conformidade da CP para todas as alterações à CPS. Qualquer alteração à CPS deve ser claramente documentada. Antes que uma nova versão de uma CPS seja implementada, a sua conformidade com a CP deve ser confirmada por um auditor de PKI acreditado.
(17)A CA de raiz deve notificar a CPA de qualquer alteração feita à CPS com pelo menos as seguintes informações:
·uma descrição exata da alteração;
·os motivos que justificam a alteração;
·um relatório do auditor acreditado da PKI confirmando o cumprimento da CP;
·o contacto da pessoa responsável pela CPS;
·o calendário previsto para a implementação.
1.5.2.Procedimentos de aprovação da CPS
(18)Antes de iniciar as suas operações, uma futura CA de raiz deve apresentar a sua CPS a um auditor de PKI acreditado no âmbito de um pedido de auditoria para verificar a conformidade (fluxo 13) e à CPA para que esta dê a sua aprovação (fluxo 15).
(19)Uma CA de raiz deve apresentar as alterações da sua CPS a um auditor de PKI acreditado no âmbito de um pedido de auditoria para verificar a conformidade (fluxo 13) e à CPA para que esta dê a sua aprovação (fluxo 15) antes de as alterações se tornarem efetivas.
(20)A EA/AA deve apresentar a sua CPS, ou alterações à sua CPS, à CA de raiz. A CA de raiz pode solicitar um certificado de conformidade do organismo nacional ou entidade privada responsável pela aprovação da EA/AA, conforme definido nas secções 4.1.2 e 8.
(21)O auditor de PKI acreditado deve avaliar a CPS de acordo com a secção 8.
(22)O auditor da PKI acreditado deve comunicar os resultados da avaliação da CPS no âmbito do relatório de auditoria, conforme estabelecido na secção 8.1. A CPS deve ser aceite ou rejeitada no âmbito da aceitação do relatório de auditoria referido nas secções 8.5 e 8.6.
2.Responsabilidades de publicação e criação de repositórios
2.1.Métodos para a publicação de informações de certificados
(23)As informações do certificado podem ser publicadas de acordo com a secção 2.5:
·de forma regular ou periódica; ou
·em resposta a um pedido de uma das entidades participantes.
Em cada caso, aplicam-se graus de urgência de publicação diferentes e, por conseguinte, calendários diferentes, mas as entidades devem estar preparadas para ambas as situações.
(24)A publicação regular das informações do certificado permite determinar um prazo máximo até ao qual as informações dos certificados são atualizadas para todos os nós da rede de STI-C. A frequência da publicação de todas as informações do certificado é definida na secção 2.2.
(25)A pedido de entidades participantes da rede de STI-C, qualquer participante pode começar a publicar as informações do certificado a qualquer momento e, dependendo do seu estado, solicitar um conjunto atual de informações do certificado para se tornar um nó de total confiança da rede de STI-C. O principal objetivo dessa publicação é atualizar as entidades quanto ao estado geral atual das informações de certificado na rede e permitir que estas comuniquem com confiança até à próxima publicação regular das informações.
(26)Uma CA de raiz individual também pode iniciar a publicação de informações de certificado a qualquer momento enviando um conjunto atualizado de certificados a todos os «membros inscritos» da rede de STI-C que são recetores regulares dessas informações. Essa situação apoia a operação das CA e permite que estes se dirijam aos membros entre as datas regulares e agendadas para publicar os certificados.
(27)A secção 2.5 define o mecanismo e todos os procedimentos para publicar certificados de CA de raiz e a ECTL.
(28)O CPOC deve publicar os certificados da CA de raiz (conforme incluídos na ECTL e destinados ao consumo público), o certificado do TLM e a ECTL que emite.
(29)As CA de raiz devem publicar os seus certificados EA/AA e CRL e ser capazes de suportar os três mecanismos aqui referidos para os publicar aos seus membros inscritos e partes utilizadoras, tomando todas as medidas necessárias para garantir a transmissão segura, conforme referido na secção 4.
2.2.Altura ou frequência de publicação
(30)Os requisitos aplicáveis ao agendamento da publicação de certificados e CRL devem ser determinados à luz dos vários fatores limitantes dos nós do STI-C individuais, com o objetivo geral de operar uma «rede de confiança» e publicar as atualizações o mais rapidamente possível para todas as estações de STI-C envolvidas.
·Para a publicação regular de informações atualizadas do certificado (por exemplo, alterações na composição da ECTL ou da CRL), é necessário um período máximo de três meses para a operação segura da rede de STI-C.
·As CA de raiz devem publicar os seus certificados de CA e CRL logo que possível após a emissão.
·Para a publicação da CRL, deve ser utilizado o repositório da CA de raiz.
Além disso, o CPS para cada CA deve especificar o período de tempo dentro do qual um certificado será publicado após a CA emitir o certificado.
Esta secção especifica apenas o tempo ou a frequência da publicação regular. Os meios de conectividade para atualizar as estações de STI-C com a ECTL e as CRL no espaço de uma semana após a sua publicação (sob condições normais de operação, por exemplo, com cobertura celular, veículo em operação real, etc.) devem ser implementados em conformidade com os requisitos do presente documento.
2.3.Repositórios
(31)Os requisitos relativos à estrutura do repositório para armazenar os certificados e às informações que são fornecidas pelas entidades da rede de STI-C são os seguintes para as entidades únicas:
·em geral, cada CA de raiz deve utilizar um repositório das suas próprias informações de certificado EA/AA e CRL atualmente ativas para publicar certificados para os outros participantes na PKI (por exemplo, um serviço de diretório baseado em LDAP). O repositório de cada CA de raiz deve suportar todos os controlos de acesso necessários (secção 2.4) e tempos de transmissão (secção 2.2) para cada modalidade de distribuição de informações relacionadas com STI-C;
·o repositório do TLM (que armazena a ECTL e os certificados do TLM publicados pelo CPOC, por exemplo) deve basear-se num mecanismo de publicação capaz de garantir os tempos de transmissão definidos na secção 2.2 para cada modalidade de distribuição.
Os requisitos das AA não estão definidos, mas devem suportar os mesmos níveis de segurança que as outras entidades e devem ser declarados na sua CPS.
2.4.Controlos de acesso a repositórios
(32)Os requisitos de controlo de acesso a repositórios de informações de certificado devem, no mínimo, estar em conformidade com os padrões gerais de tratamento seguro de informações descritos na norma ISO/IEC 27001 e com os requisitos da secção 4. Adicionalmente, devem refletir as necessidades de segurança do processo a serem estabelecidas para as etapas do processo único na publicação das informações do certificado.
·Tal inclui a implementação do repositório para certificados TLM e a ECTL no TLM/CPOC. Cada CA ou operador de repositório deve implementar controlos de acesso em relação a todas as entidades do STI-C e partes externas a pelo menos três níveis diferentes (por exemplo, público, restrito a entidades de STI-C, nível da CA de raiz), para evitar que entidades não autorizadas adicionem, alterem ou excluam entradas do repositório.
·Os mecanismos exatos de controlo de acesso da entidade única devem fazer parte da respetiva CPS.
·Para cada CA de raiz, os repositórios da EA e da AA devem cumprir os mesmos requisitos para os procedimentos de controlo de acesso, independentemente do local ou do vínculo contratual com o prestador de serviços que opera o repositório.
Como ponto de partida para os níveis de controlo de acesso, cada CA de raiz ou operador de repositório deve fornecer pelo menos três níveis diferentes (por exemplo, público, restrito a entidades de STI-C, nível da CA de raiz).
2.5.Publicação de informações de certificados
2.5.1.Publicação de informações de certificados pelo TLM
(33)O TLM no domínio de confiança comum europeu de STI-C deve publicar as seguintes informações através do CPOC:
·todos os certificados de TLM atualmente válidos para o próximo período de operação (certificado atual e de ligação, se disponíveis);
·informações de ponto de acesso para o repositório do CPOC para fornecer a lista assinada da CA de raiz (ECTL);
·ponto de informação geral para a implantação da ECTL e do STI-C.
2.5.2.Publicação de informações de certificados pelas CA
(34)As CA de raiz no domínio de confiança comum europeu de STI-C devem publicar as seguintes informações:
·certificados de CA de raiz emitidos (válidos à data) (certificados atuais e com correta reemissão de chave, incluindo um certificado de ligação) no repositório referido na secção 2.3;
·todas as entidades de EA, AA válidas, com a respetiva identificação de operador e período planeado de operação;
·certificados da CA emitidos nos repositórios referidos na secção 2.3;
·as CRL de todos os certificados de CA revogados que cobrem as respetivas EA e AA subordinadas;
·informações relativas ao ponto de acesso da CA de raiz às informações da CRL e da CA.
Todas as informações do certificado devem ser categorizadas de acordo com três níveis de confidencialidade e os documentos para o público em geral devem estar publicamente disponíveis sem restrições.
3.Identificação e autenticação
3.1.Nomenclatura
3.1.1.Tipos de nomes
3.1.1.1.Nomes para TLM, CA de raiz, EA e AA
(35)O nome no certificado TLM deve consistir num único atributo nome_sujeito com o valor reservado EU_TLM».
(36)O nome das CA de raiz deve consistir num único atributo nome_sujeito com um valor atribuído pela CPA. A exclusividade dos nomes é da inteira responsabilidade da CPA e o TLM deve manter o registo dos nomes da CA de raiz mediante notificação pela CPA (aprovação, revogação/retirada de uma CA de raiz). Os nomes de sujeitos nos certificados têm um limite de 32 bytes. Cada CA de raiz propõe o seu nome à CPA no formulário do pedido (fluxo 14). A CPA é responsável por verificar a exclusividade do nome. Se o nome não for exclusivo, o formulário de pedido será rejeitado (fluxo 4).
(37)O nome em cada certificado de EA/AA pode consistir num único atributo nome_sujeito com um valor gerado pelo emissor do certificado. A exclusividade dos nomes é da inteira responsabilidade da CA de raiz emissora.
(38)Os certificados de EA e AA não devem utilizar um nome que exceda 32 bytes, porque o nome_sujeito em certificados tem um limite de 32 bytes.
(39)Os CA não devem conter um nome.
3.1.1.2.Nomes para as entidades finais
(40)Cada estação de STI-C deve receber dois tipos de identificador único:
·uma identificação canónica que é armazenada no registo inicial da estação de STI-C sob a responsabilidade do fabricante. Deve conter uma subsequência que identifique o fabricante ou operador, para que este identificador possa ser único;
·um sujeito_nome, que pode fazer parte da EC da estação de STI-C, sob a responsabilidade da EA.
3.1.1.3.Identificação de certificados
(41)Os certificados que seguem o formato da norma [5] devem ser identificados através do cálculo de um valor de HashedId8 conforme definido na norma [5].
3.1.2.Necessidade de os nomes serem significativos
Não estipulado.
3.1.3.Anonimato e pseudonímia das entidades finais
(42)A AA deve assegurar que a pseudonímia de uma estação de STI-C é estabelecida fornecendo à estação de STI-C certificados de autorização que não contenham nomes ou informações que possam vincular o sujeito à sua identidade real.
3.1.4.Regras de interpretação das diversas formas de nomes
Não estipulado.
3.1.5.Exclusividade dos nomes
(43)Os nomes para o TLM, as CA de raiz, as EA, as AA e as identificações canónicas para estações de STI-C devem ser únicos.
(44)O TLM deve garantir, no processo de registo de uma determinada CA de raiz na ECTL, que o seu identificador de certificado (HashedId8) é único. A CA de raiz deve garantir, no processo de emissão, que o identificador de certificado (HashedId8) de cada CA subordinada é único.
(45)O HashedId8 de uma EC deve ser único dentro da CA emissora. O HashedId8 de um CA não necessita de ser único.
3.2.Validação inicial de identidade
3.2.1.Método para demonstrar posse de chave privada
(46)A CA de raiz deve comprovar que detém legitimamente a chave privada correspondente à chave pública no certificado autoassinado. O CPOC deve verificar esse elemento de prova.
(47)A EA/AA deve comprovar que detém legitimamente a chave privada correspondente à chave pública a ser inserida no certificado. A CA de raiz deve verificar esse elemento de prova.
(48)A posse de uma nova chave privada (para reemissão de chave) deve ser comprovada pela assinatura do pedido com a nova chave privada (assinatura interna) seguida da geração de uma assinatura externa sobre o pedido assinado com a chave privada válida à data (para garantir a autenticidade do pedido). O requerente deve apresentar o pedido de certificado assinado à CA emissora através de um meio de comunicação seguro. A CA emissora deve verificar se a assinatura digital do requerente na mensagem de pedido foi criada utilizando a chave privada correspondente à chave pública anexada ao pedido do certificado. A CA de raiz deve especificar quais os pedidos de certificado e respostas que suporta na sua CPS.
3.2.2.Autenticação de identidade de uma organização
3.2.2.1.Autenticação da identidade de uma organização de CA
(49)Num formulário do pedido para a CPA (ou seja, fluxo 14), a CA de raiz deve apresentar a identidade da organização e as informações de registo, compostas por:
·nome da organização;
·endereço postal;
·endereço de correio eletrónico;
·o nome da pessoa singular a contactar na organização;
·número de telefone;
·impressões digitais (ou seja, SHA 256 hashvalue) do certificado da CA de raiz em papel;
·informações criptográficas (por exemplo, algoritmos criptográficos, comprimentos de chave) no certificado da CA de raiz;
·todas as permissões que a CA de raiz está autorizada a utilizar e transmitir às CA subordinadas.
(50)A CPA deve verificar a identidade da organização e outras informações de registo fornecidas pelo requerente do certificado para a inserção de um certificado da CA de raiz na ECTL.
(51)A CPA deve reunir elementos de prova diretos, ou uma comprovação de uma fonte apropriada e autorizada, da identidade (por exemplo, o nome) e, se aplicável, quaisquer atributos específicos de sujeitos para os quais é emitido um certificado. Os elementos de prova enviados podem ser em papel ou em formato eletrónico.
(52)A identidade do sujeito deve ser verificada no momento do registo através dos meios adequados e de acordo com a presente política de certificado.
(53)Em cada pedido de certificado, devem ser fornecidos elementos de prova:
·do nome completo da entidade organizacional (organização privada, entidade governamental ou entidade não comercial);
·registo nacionalmente reconhecido ou outros atributos que possam ser utilizados, na medida do possível, para distinguir a entidade organizacional de outras com o mesmo nome.
As regras acima baseiam-se na norma TS 102 042 [4]: A CA deve assegurar que os elementos de prova da identificação do subscritor e do sujeito e a precisão de seus nomes e dados associados são adequadamente analisados no âmbito do serviço definido ou, quando aplicável, concluídos através da análise de atestados de fontes adequadas e autorizadas, e que os pedidos de certificado são precisos e autorizados e estão completos de acordo com os elementos de prova ou atestação reunidos.
3.2.2.2.Autenticação da identidade de uma organização do TLM
(54)A organização que opera o TLM deve apresentar elementos que comprovem a identificação e a precisão do nome e dos dados associados, a fim de permitir a verificação adequada na criação inicial e na reemissão de chave do certificado do TLM.
(55)A identidade do sujeito deve ser verificada no momento de criação do certificado ou de reemissão de chave através dos meios adequados e em conformidade com a presente CP.
(56)A organização deve apresentar elementos de prova conforme especificado na secção 3.2.2.1.
3.2.2.3.Autenticação da identidade de uma organização de CA subordinadas
(57)A CA de raiz deve verificar a identidade da organização e outras informações de registo fornecidas pelos requerentes de certificados para os certificados da CA subordinada (EAAA).
(58)A CA de raiz deve, no mínimo:
·determinar que a organização existe utilizando pelo menos um serviço ou base de dados de verificação de identidade de terceiros ou, em alternativa, documentação da organização emitida pela agência governamental pertinente, ou arquivada junto da mesma, ou autoridade reconhecida que confirme a existência da organização;
·utilizar o correio postal ou um procedimento semelhante solicitando que o requerente do certificado confirme determinadas informações sobre a organização, que autorizou o pedido de certificado e que a pessoa que apresentou o pedido em nome do requerente está autorizada a fazê-lo. Quando um certificado inclui o nome de um indivíduo como representante autorizado da organização, deve ainda confirmar que esse indivíduo está ao seu serviço e o autorizou a agir em seu nome.
(59)Os procedimentos de validação para a emissão de certificados da CA devem ser documentados numa CPS da CA de raiz.
3.2.2.4.Autenticação da organização do subscritor da entidade final
(60)Antes que o subscritor de entidades finais (fabricante/operador) se possa registar numa EA de confiança para permitir que suas entidades finais enviem pedidos de certificados de EC, a EA deve:
·verificar a identidade da organização do subscritor e outras informações de registo fornecidas pelo requerente do certificado;
·verificar se o tipo de estação de STI-C (ou seja, o produto específico que se baseia na marca, no modelo e na versão da estação de STI-C) cumpre todos os critérios de avaliação da conformidade.
(61)A EA deve, no mínimo:
·determinar que a organização existe utilizando pelo menos um serviço ou base de dados de verificação de identidade de terceiros ou, em alternativa, documentação da organização emitida pela agência governamental pertinente, ou arquivada junto da mesma, ou autoridade reconhecida que confirme a existência da organização;
·utilizar o correio postal ou um procedimento semelhante para solicitar que o requerente do certificado confirme determinadas informações sobre a organização, que autorizou o pedido de certificado e que a pessoa que apresentou o pedido em seu nome está autorizada a fazê-lo. Quando um certificado inclui o nome de um indivíduo como representante autorizado da organização, deve ainda confirmar que esse indivíduo está ao seu serviço e o autorizou a agir em seu nome.
(62)Os procedimentos de validação para o registo de uma estação de STI-C pelo seu subscritor devem ser documentados numa CPS da EA.
3.2.3.Autenticação de entidade individual
3.2.3.1.Autenticação de entidade individual de TLM/CA
(63)Para a autenticação de uma entidade individual (pessoa singular) identificada em associação com uma pessoa coletiva ou entidade organizacional (por exemplo, o subscritor), devem ser apresentados elementos que comprovem:
·o nome completo do sujeito (incluindo apelido e nomes próprios, de acordo com a legislação e as práticas nacionais de identificação aplicáveis);
·data e local de nascimento, referência a um documento de identificação nacionalmente reconhecido ou a outros atributos do subscritor que possam ser utilizados, na medida do possível, para distinguir a pessoa de outras pessoas com o mesmo nome;
·nome completo e estatuto jurídico da pessoa coletiva associada ou outra entidade organizacional (por exemplo, o subscritor);
·qualquer informação de registo relevante (por exemplo, registo de empresa) da pessoa coletiva associada ou outra entidade organizacional;
·elementos que comprovem que o sujeito está associado à pessoa coletiva ou a outra entidade organizacional.
Os elementos de prova enviados podem ser em papel ou em formato eletrónico.
(64)Para verificar a sua identidade, o representante autorizado de uma CA de raiz, EA, AA ou subscritor deve apresentar documentos que comprovem que trabalha para a organização (certificado de autorização). Deve também apresentar documentos de identificação oficiais.
(65)Para o processo de inscrição inicial (fluxo 31/32), um representante da EA/AA deve fornecer à CA de raiz correspondente todas as informações necessárias (ver secção 4.1.2).
(66)O pessoal da CA de raiz deve verificar a identidade do representante do requerente do certificado e todos os documentos associados, aplicando os requisitos do «pessoal de confiança», conforme estabelecido na secção 5.2.1. (O processo de validação das informações do pedido e geração do certificado pela CA de raiz deve ser executado por «pessoas de confiança» na CA de raiz, no mínimo sob dupla supervisão, uma vez que se trata de operações delicadas na aceção da secção 5.2.2).
3.2.3.2.Autenticação de identidade de subscritores de estações de STI-C
(67)Os subscritores são representados por utilizadores finais autorizados na organização que estão registados na EA e AA emissora. Esses utilizadores finais designados pelas organizações (fabricantes ou operadores) devem comprovar a sua identidade e autenticidade antes de:
·registar a EE na sua EA correspondente, incluindo a respetiva chave pública canónica, a identidade canónica (identificador único) e as permissões de acordo com a EE;
·registar-se na AA e garantir a existência de elementos que comprovem um contrato de subscritor que possa ser enviado à EA.
3.2.3.3.Autenticação de identidade de estações de STI-C
(68)Os sujeitos da EE das EC devem autenticar-se ao pedir EC (fluxo 31) utilizando a sua chave privada canónica para a autenticação inicial. A EA deve verificar a autenticação utilizando a chave pública canónica correspondente à EE. As chaves públicas canónicas das EE são transmitidas à EA antes que o pedido inicial seja executado, através de um canal seguro entre o fabricante ou operador da estação de STI-C e a EA (fluxo 33).
(69)Os sujeitos da EE dos CA devem autenticar-se ao pedir CA (fluxo 32) utilizando a sua chave privada única de inscrição. A AA deve encaminhar a assinatura para a EA (fluxo 25) para que esta seja validada; a EA deve validá-la e confirmar o resultado à AA (fluxo 23).
3.2.4.Informações de subscritor não verificadas
Não estipulado.
3.2.5.Validação de autoridade
3.2.5.1.Validação de TLM, CA de raiz, EA, AA
(70)Todas as organizações devem identificar na CPS pelo menos um representante (por exemplo, um agente de segurança) responsável por solicitar novos certificados e renovações. Aplicam-se as regras de nomenclatura descritas na secção 3.2.3.
3.2.5.2.Validação de subscritores de estações de STI-C
(71)Deve ser conhecida e aprovada pela EA (ver secção 3.2.3) pelo menos uma pessoa singular responsável por registar as estações de STI-C numa EA (por exemplo, um agente de segurança).
3.2.5.3.Validação de estações de STI-C
(72)O subscritor de uma estação de STI-C pode registar estações de STI-C numa EA específica (fluxo 33), desde que esteja autenticado nessa EA.
Quando a estação de STI-C está registada numa EA com uma identidade canónica única e uma chave pública canónica, pode solicitar uma EC utilizando um pedido assinado com a chave privada canónica associada à chave pública canónica anteriormente registada.
3.2.6.Critérios de interoperação
(73)Para comunicações entre estações de STI-C e as EA (ou AA), a estação de STI-C deve ser capaz de estabelecer comunicações seguras com as EA (ou AA), ou seja, implementar funções de autenticação, confidencialidade e integridade, conforme especificado na norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1]. As EA e AA devem suportar essas comunicações seguras.
(74)A EA e a AA devem suportar pedidos de certificados e respostas em conformidade com a norma [1], que prevê um protocolo seguro de pedido/resposta de CA que suporta o anonimato do requerente em relação à AA e a separação de tarefas entre a AA e a EA. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1]. Para evitar a divulgação da identidade de longo prazo das estações de STI-C, a comunicação entre uma estação de STI-C móvel e uma EA deve ser confidencial (por exemplo, os dados de comunicação devem ser encriptados de ponta a ponta).
(75)A AA deve enviar um pedido de validação de autorização (fluxo 25) para cada pedido de autorização que receber de um sujeito do certificado da EE. A EA deve validar esse pedido no que respeita:
·ao estatuto da EE na EA;
·à validade da assinatura;
·aos AID-STI (ID dos pedidos de STI) e permissões solicitados;
·ao estatuto de prestação de serviços da AA ao subscritor.
3.3.Identificação e autenticação para pedidos de reemissão de chave
3.3.1.Identificação e autenticação para pedidos de reemissão de chave de rotina
3.3.1.1.Certificados de TLM
(76)O TLM gera um par de chaves e dois certificados: um autoassinado e um certificado de ligação nos termos da secção 7.
3.3.1.2.Certificados de CA de raiz
Não aplicável.
3.3.1.3.Renovação ou reemissão de chave de certificados de EA/AA
(77)Antes da expiração de um certificado de EA/AA, a EA/AA deve pedir um novo certificado (fluxo 21/fluxo 24) para manter a continuidade da utilização do certificado. A EA/AA deve gerar um novo par de chaves para substituir o par de chaves que expirou e assinar o pedido de reemissão de chave contendo a nova chave pública com a chave privada válida à data («reemissão de chave»). A EA ou AA gera um novo par de chaves e assina o pedido com a nova chave privada (assinatura interna) para comprovar a posse da nova chave privada. O pedido é integralmente assinado com a chave privada válida à data (assinatura externa) para garantir a integridade e a autenticidade do pedido. Se for utilizado um par de chaves de encriptação e desencriptação, deve ser comprovada a posse de chaves de desencriptação privadas (para uma descrição detalhada da reemissão de chave, ver secção 4.7.3.3).
(78)O método de identificação e autenticação para a reemissão de chave de rotina é o mesmo que para a emissão inicial de uma validação de certificado de EA de raiz inicial, conforme estabelecido na secção 3.2.2.
3.3.1.4.Credenciais de inscrição de entidades finais
(79)Antes da expiração de uma EC existente, a EE deve pedir um novo certificado (fluxo 31) para manter a continuidade da utilização do certificado. A EE deve gerar um novo par de chaves para substituir o par de chaves que está a expirar e solicitar um novo certificado contendo a nova chave pública; o pedido deve ser assinado com a chave privada da EC válida à data.
(80)A EE pode assinar o pedido com a chave privada recém-criada (assinatura interna) para comprovar a posse da nova chave privada. O pedido é depois integralmente assinado com a chave privada válida à data (assinatura externa) e encriptado para a EA recetora, conforme especificado na norma [1], para garantir a confidencialidade, a integridade e a autenticidade do pedido. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].
3.3.1.5.Certificados de autorização das entidades finais
(81)A nova chave do certificado para CA baseia-se no mesmo processo que a autorização inicial, conforme definido na norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].
3.3.2.Identificação e autenticação para pedidos de reemissão de chave após revogação
3.3.2.1.Certificados de CA
(82)A autenticação de uma organização da CA para a reemissão de chave de certificados da CA de raiz, da EA e da AA após a revogação é tratada da mesma forma que a emissão inicial de um certificado da CA, conforme estabelecido na secção 3.2.2.
3.3.2.2.Credenciais de inscrição de entidades finais
(83)A autenticação de uma EE para a reemissão de chave de certificado de EC após a revogação é tratada da mesma forma que a emissão inicial de um certificado da EE, conforme estabelecido na secção 3.2.2.
3.3.2.3.Pedidos de autorização de entidades finais
Não aplicável, uma vez que os CA não são revogados.
3.4.Identificação e autenticação para pedidos de revogação
3.4.1.Certificados de CA de raiz/EA/AA
(84)Os pedidos para excluir um certificado da CA de raiz da ECTL devem ser autenticados pela CA de raiz para o TLM (fluxos 12 e 9). Os pedidos de revogação de um certificado da EA/AA devem ser autenticados pela CA de raiz pertinente e pela própria CA subordinada.
(85)Os procedimentos aceitáveis para autenticar os pedidos de revogação de um subscritor abrangem:
·uma mensagem escrita e assinada em papel de carta da empresa do subscritor solicitando a revogação, fazendo referência ao certificado a ser revogado;
·comunicações com o subscritor que forneçam garantias razoáveis de que a pessoa ou organização que solicita a revogação é, de facto, o subscritor. Dependendo das circunstâncias, essas comunicações podem incluir um ou mais dos seguintes elementos: correio eletrónico, correio postal ou serviço de correio expresso.
3.4.2.Credenciais de inscrição de estações de STI-C
(86)O subscritor da estação de STI-C pode revogar a EC de uma estação de STI-C previamente registada numa EA (fluxo 34). O subscritor requerente deve criar um pedido de revogação de uma determinada estação de STI-C ou lista de estações de STI-C. A EA deve autenticar o pedido de revogação antes de a processar e confirmar a revogação das estações de STI-C e respetiva EC.
(87)A EA pode revogar a EC de uma estação de STI-C em conformidade com a secção 7.3.
3.4.3.Certificados de autorização de estações de STI-C
(88)Os CA não são revogados, devendo a sua validade estar limitada a um período específico. O intervalo de períodos de validade aceitáveis na presente política de certificado encontra-se especificado na secção 7.
4.Requisitos operacionais do ciclo de vida dos certificados
4.1.Pedido de certificado
(89)A presente secção define os requisitos aplicáveis a pedidos iniciais de emissão de um certificado.
(90)O termo «pedido de certificado» refere-se aos seguintes processos:
·registo e configuração de uma relação de confiança entre o TLM e a CPA;
·registo e configuração de uma relação de confiança entre a CA de raiz e a CPA e o TLM, incluindo a inserção do primeiro certificado da CA de raiz na ECTL
·registo e configuração de uma relação de confiança entre a EA/AA e a CA de raiz, incluindo a emissão de um novo certificado da EA/AA;
·registo da estação de STI-C na EA pelo fabricante/operador;
·pedido da estação de STI-C de EC/CA.
4.1.1.Quem pode submeter um pedido de certificado
4.1.1.1.CA de raiz
(91)As CA de raiz geram os seus próprios pares de chaves e emitem o seu certificado de raiz por sua conta. Uma CA de raiz pode enviar um pedido de certificado através do seu representante designado (fluxo 14).
4.1.1.2.TLM
(92)O TLM gera o seu próprio par de chaves e emite o seu certificado por sua conta. A criação inicial do certificado do TLM deve ser processada por um representante da organização do TLM sob o controlo da CPA.
4.1.1.3.EA e AA
(93)Um representante autorizado da EA ou AA pode submeter o pedido de certificado da CA subordinada (AA e/ou AA) ao representante autorizado da CA de raiz pertinente (fluxo 27/28).
4.1.1.4.Estação de STI-C
(94)Os subscritores devem registar cada estação de STI-C na EA em conformidade com a secção 3.2.5.3.
(95)Cada estação de STI-C registada na EA pode enviar pedidos de EC (fluxo 31).
(96)Cada estação de STI-C pode enviar pedidos de CA (fluxo 32) sem solicitar qualquer interação do subscritor. Antes de pedir um CA, uma estação de STI-C deve possuir uma EC.
4.1.2.Processo de inscrição e responsabilidades
(97)As permissões para CA de raiz e CA subordinadas que emitem certificados para finalidades (governamentais) especiais (ou seja, estações de STI-C móveis e fixas especiais) só podem ser concedidas pelos Estados-Membros em que as organizações estão localizadas.
4.1.2.1.CA de raiz
(98)Depois de serem auditadas (fluxos 13 e 36, secção 8), as CA de raiz podem pedir a inserção do(s) seu(s) certificado(s) na ECTL junto da CPA (fluxo 14). O processo de inscrição baseia-se num formulário de pedido manual assinado que deve ser fisicamente entregue à CPA pelo representante autorizado da CA de raiz e que contenha pelo menos as informações referidas nas secções 3.2.2.1, 3.2.3 e 3.2.5.1.
(99)O formulário de pedido da CA de raiz deve ser assinado pelo seu representante autorizado.
(100)Além do formulário de pedido, o representante autorizado da CA de raiz deve fornecer uma cópia da CPS da CA de raiz (fluxo 15) e o seu relatório de auditoria à CPA para que estes sejam aprovados (fluxo 16). Nos casos de aprovação efetiva, a CPA gera e envia um certificado de conformidade ao CPOC/TLM e à CA de raiz correspondente.
(101)Em seguida, o representante autorizado da CA de raiz deve apresentar o seu formulário de pedido (contendo as impressões digitais do certificado autoassinado), a identificação oficial e um elemento que comprove a autorização ao CPOC/TLM. O certificado autoassinado deve ser entregue por via eletrónica ao CPOC/TLM. O CPOC/TLM deve verificar todos os documentos e o certificado autoassinado.
(102)Nos casos de verificações positivas, o TLM deve adicionar o certificado da CA de raiz à ECTL com base na notificação da CPA (fluxos 1 e 2). O processo encontra-se descrito em detalhe na CPS do TLM.
(103)Deve ser possível um procedimento adicional para obter uma aprovação da CPS e um relatório de auditoria de uma CA de raiz num organismo nacional de países específicos.
4.1.2.2.TLM
(104)Depois de ser auditado, o TLM pode inscrever-se na CPA. O processo de inscrição baseia-se num formulário de pedido manual assinado que deve ser fisicamente entregue à CPA (fluxo 38) pelo representante autorizado do TLM e conter pelo menos as informações referidas nas secções 3.2.2.2 e 3.2.3.
(105)O formulário de pedido do TLM deve ser assinado pelo seu representante autorizado.
(106)Em primeiro lugar, o TLM gera seu certificado autoassinado e transmite-o à CPA de forma segura. Em seguida, o TLM apresenta o seu formulário de pedido (contendo as impressões digitais do certificado autoassinado), uma cópia da sua CPS, uma identificação oficial, um elemento que comprove a autorização e o seu relatório de auditoria à CPA (fluxo 40). A CPA deve verificar todos os documentos e o certificado autoassinado. Nos casos de verificação positiva de todos os documentos, do certificado autoassinado e das impressões digitais, a CPA deve confirmar o processo de inscrição enviando a sua aprovação ao TLM e ao CPOC (fluxo 39). A CPA deve armazenar as informações do pedido enviadas pelo TLM. O certificado do TLM é em seguida emitido através do CPOC.
4.1.2.3.EA e AA
(107)Durante o processo de inscrição, a EA/AA deve apresentar os documentos pertinentes (por exemplo, a CPS e o relatório de auditoria) à CA de raiz correspondente para que estes sejam aprovados (fluxo 27/28). Nos casos de verificações positivas dos documentos, a CA de raiz envia uma aprovação às CA subordinadas correspondentes (fluxo 29/30). A CA subordinada (EA ou AA) deve em seguida transmitir o seu pedido assinado eletronicamente, e entregar fisicamente o seu formulário de pedido (em conformidade com a secção 3.2.2.1), elementos que comprovem a autorização e um documento de identificação à CA de raiz correspondente. A CA de raiz verifica o pedido e os documentos recebidos (formulário de pedido que contém as impressões digitais, que é o hashvalue SHA 256 do pedido da CA subordinada, os elementos que comprovam a autorização e o documento de identificação). Se todas as verificações conduzirem a um resultado positivo, a CA de raiz emite o certificado de CA subordinada correspondente. A forma de efetuar um pedido inicial encontra-se descrita em detalhe na sua CPS específica.
(108)Além do formulário de pedido da CA subordinada, o representante autorizado da CA subordinada deve anexar uma cópia da CPS à CA de raiz.
(109)Um auditor de PKI credenciado deve ser informado sobre as auditorias nos termos da secção 8.
(110)Se uma CA subordinada for propriedade de uma entidade diferente da entidade proprietária de uma CA de raiz, antes de emitir um pedido de certificado de CA subordinada, a entidade da CA subordinada deve assinar um contrato referente ao serviço da CA de raiz.
4.1.2.4.Estação de STI-C
(111)O registo inicial de sujeitos de entidades finais (estações de STI-C) deve ser realizado pelo subscritor responsável (fabricante/operador) da EA (fluxos 33 e 35) após a autenticação bem-sucedida da organização do subscritor e um dos seus representantes em conformidade com as secções 3.2.2.4 e 3.2.5.2.
(112)Uma estação de STI-C pode gerar um par de chaves de EC (ver secção 6.1) e criar um pedido de EC assinado em conformidade com a norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].
(113)Durante o registo de uma estação de STI-C normal (por oposição a uma estação especial de STI-C móvel ou fixa), a EA deve verificar se as permissões no pedido inicial não se destinam a utilização governamental. As permissões para utilização governamental são definidas pelos Estados-Membros correspondentes. O procedimento detalhado para o registo e a resposta da EA ao fabricante/operador (fluxos 33 e 35) deve ser estabelecido na CPS correspondente da EA.
(114)Uma estação de STI-C deve ser registada numa EA (secção 3.2.5.3) enviando o seu pedido inicial de EC de acordo com a norma [1].
(115)Após o registo inicial por um representante do subscritor autenticado, a EA aprova os CA que o sujeito da entidade final (ou seja, a estação de STI-C) pode obter. Além disso, é atribuído a cada entidade final um nível de garantia de confiança, que está relacionado com a certificação da entidade final de acordo com um dos perfis de proteção indicados na secção 6.1.5.2.
(116)Os veículos normais devem possuir apenas uma estação de STI-C registada numa EA. Os veículos para fins especiais (como carros da polícia e outros veículos para fins especiais com direitos específicos) podem ser registados numa EA adicional ou possuir uma estação de STI-C adicional para autorizações que recaiam no âmbito da finalidade especial. Os veículos aos quais essa isenção se aplica serão definidos pelos Estados-Membros responsáveis. As permissões para estações de STI-C móveis e fixas especiais apenas serão concedidas pelos Estados-Membros responsáveis. As CPS das CA de raiz ou CA subordinadas que emitem certificados para esses veículos nesses Estados-Membros devem determinar de que forma o processo de certificação se aplica a esses veículos.
(117)Quando o subscritor está em processo de migração de uma estação de STI-C de uma EA para outra EA, a estação de STI-C pode ser registada em duas EA (semelhantes).
(118)Uma estação de STI-C gera um par de chaves do CA (ver secção 6.1) e cria um pedido de CA em conformidade com a norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].
(119)As estações de STI-C enviam um pedido de autorização para o URL da AA (fluxos 32 e 26) enviando pelo menos as informações necessárias referidas na secção 3.2.3.3). A AA e a EA validam a autorização para cada pedido em conformidade com as secções 3.2.6 e 4.2.2.5.
4.2.Processamento de pedidos de certificado
4.2.1.Realização de funções de identificação e autenticação
4.2.1.1.Identificação e autenticação de CA de raiz
(120)O representante autorizado da CPA é responsável por autenticar o representante autorizado da CA de raiz e aprovar o respetivo processo de inscrição em conformidade com a secção 3.
4.2.1.2.Identificação e autenticação de TLM
(121)O representante autorizado da CPA é responsável por autenticar o representante autorizado do TLM e aprovar o respetivo formulário do pedido de processo de inscrição em conformidade com a secção 3.
4.2.1.3.Identificação e autenticação de EA e AA
(122)A CA de raiz correspondente é responsável por autenticar o representante autorizado da EA/AA e aprovar o respetivo formulário do pedido de processo de inscrição em conformidade com a secção 3.
(123)A CA de raiz deve confirmar a sua validação positiva do formulário de pedido à EA/AA. A EA/AA pode em seguida enviar um pedido de certificado à CA de raiz (fluxo 21/24), que deve emitir certificados à EA/AA correspondente (fluxo 18/19).
4.2.1.4.Identificação e autenticação de subscritores de EE
(124)Antes que uma estação de STI-C possa pedir um certificado de EC, o subscritor da EE deve transmitir de forma segura as informações do identificador da estação de STI-C à EA (fluxo 33). A EA deve verificar o pedido e, em caso de verificação positiva, registar as informações da estação de STI-C na sua base de dados e confirmá-lo ao subscritor da EE (fluxo 35). Esta operação é efetuada apenas uma vez pelo fabricante ou operador para cada estação de STI-C. Uma vez registada por uma EA, uma estação de STI-C pode pedir apenas um certificado de EC de que necessita (fluxo 31) de cada vez. A EA autentica e verifica se as informações contidas no pedido de certificado de EC são válidas para uma estação de STI-C.
4.2.1.5.Bilhetes de autorização
(125)Durante os pedidos de autorização (fluxo 32), em conformidade com a norma [1], a AA deve autenticar a EA da qual a estação de STI-C recebeu a sua EC. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1]. Se a AA não puder autenticar a EA, o pedido será rejeitado (fluxo 26). Constitui uma condição necessária o facto de a AA possuir o certificado da EA para autenticar a EA e verificar a sua resposta (fluxos 25 e 23, secção 3.2.5.3).
(126)A EA autentica a estação de STI-C que solicita um CA verificando a sua EC (fluxos 25 e 23).
4.2.2.Aprovação ou rejeição de pedidos de certificado
4.2.2.1.Aprovação ou rejeição de certificados de CA de raiz
(127)O TLM insere/elimina os certificados da CA de raiz na ECTL de acordo com a aprovação da CPA (fluxo 1/2).
(128)O TLM deve verificar a assinatura, as informações e a codificação de certificados de CA de raiz depois de receber uma aprovação pela CPA (fluxo 1). Após a validação positiva e a aprovação da CPA, o TLM deve inserir o certificado de raiz correspondente na ECTL e notificar a CPA (fluxo 5).
4.2.2.2.Aprovação ou rejeição do certificado do TLM
(129)A CPA é responsável por aprovar ou rejeitar os certificados do TLM.
4.2.2.3.Aprovação e rejeição de certificados da EA e da AA
(130)A CA de raiz verifica os pedidos de certificado da CA subordinada (fluxo 21/24) e os relatórios pertinentes (emitidos pelo auditor acreditado da PKI) ao recebê-los (fluxo 36, secção 8) da CA subordinada correspondente da CA de raiz. Se a verificação do pedido conduzir a um resultado positivo, a CA de raiz correspondente emite um certificado para a EA/AA requerente (fluxo 18/19); caso contrário, o pedido é rejeitado e não é emitido qualquer certificado para a EA/AA.
4.2.2.4.Aprovação ou rejeição de EC
(131)A EA deve verificar e validar os pedidos de EC de acordo com as secções 3.2.3.2 e 3.2.5.3.
(132)Se o pedido de certificado em conformidade com a norma [1] estiver correto e válido, a EA deve gerar o certificado solicitado.
(133)Quando o pedido de certificado é inválido, a EA recusa-o e envia uma resposta que indique o motivo da recusa, em conformidade com a norma [1]. Se uma estação de STI-C ainda pretender uma EC, deverá proceder a um novo pedido de certificado. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].
4.2.2.5.Aprovação ou rejeição de CA
(134)O pedido de certificado é verificado pela EA. A AA deve estabelecer uma comunicação com a EA para validar o pedido (fluxo 25). A EA deve autenticar a estação de STI-C requerente e confirmar se tem direito a receber o CA solicitado de acordo com a CP (por exemplo, verificando o estado de revogação e validando a validade hora/região, as permissões, o nível de garantia, etc.). A EA deve enviar de volta uma resposta de validação (fluxo 23) e, se a resposta for positiva, a AA deve gerar o certificado solicitado e transmiti-lo à estação de STI-C. Se o pedido de CA não estiver correto ou a resposta de validação da EA for negativa, a AA recusará o pedido. Se uma estação de STI-C ainda exigir um CA, deverá proceder a um novo pedido de autorização.
4.2.3.Tempo de processamento do pedido de certificado
4.2.3.1.Pedido de certificado da CA de raiz
(135)O período para processar o processo de identificação e autenticação de um pedido de certificado é nos dias úteis e deve estar sujeito a um prazo máximo estabelecido na CPS da CA de raiz.
4.2.3.2.Pedido de certificado do TLM
(136)O processamento do pedido de certificado do TLM deve estar sujeito a um prazo máximo estabelecido na CPS do TLM.
4.2.3.3.Pedido de certificado da EA e AA
(137)O período para processar o processo de identificação e autenticação de um pedido de certificado é nos dias úteis de acordo com o acordo e o contrato entre a CA de raiz do Estado-Membro/da organização privada e a CA subordinada. O período para processar os pedidos de certificado da CA subordinada deve estar sujeito a um prazo máximo estabelecido na CPS da CA subordinada.
4.2.3.4.Pedido de EC
(138)O processamento de pedidos de EC deve estar sujeito a um prazo máximo estabelecido na CPS da EA.
4.2.3.5.Pedido de CA
(139)O processamento de pedidos de CA deve estar sujeito a um prazo máximo estabelecido na CPS da AA.
4.3.Emissão do certificado
4.3.1.Ações da CA durante a emissão de certificados
4.3.1.1.Emissão de certificados de CA de raiz
(140)As CA de raiz emitem os seus próprios certificados de CA de raiz autoassinados, certificados de ligação, certificados de CA subordinadas e CRL.
(141)Após a aprovação da CPA (fluxo 4), a CA de raiz envia o seu certificado ao TLM através do CPOC a ser adicionado à ECTL (fluxos 11 e 8) (ver secção 4.1.2.1). O TLM verifica se a CPA aprovou o certificado (fluxo 1).
4.3.1.2.Emissão de certificados de TLM
(142)O TLM emite o seu próprio certificado de TLM autoassinado e de ligação e envia-o para o CPOC (fluxo 6).
4.3.1.3.Emissão de certificados de EA e AA
(143)As CA subordinadas geram um pedido de certificado assinado e transmitem-no à CA de raiz correspondente (fluxos 21 e 24). A CA de raiz verifica o pedido e emite um certificado à CA subordinada requerente de acordo com a norma [5] com a maior brevidade possível, conforme estabelecido na CPS para as práticas operacionais habituais, o mais tardar cinco dias úteis após a receção do pedido.
(144)A CA de raiz deve atualizar o repositório que contém os certificados das CA subordinadas.
4.3.1.4.Emissão de EC
(145)A estação de STI-C deve enviar um pedido de EC à EA em conformidade com a norma [1]. A EA deve autenticar e verificar se as informações contidas no pedido de certificado são válidas para uma estação de STI-C. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].
(146)Em caso de validação positiva, a EA deve emitir um certificado de acordo com o registo da estação de STI-C (ver ponto 4.2.1.4) e enviá-lo para a estação de STI-C utilizando uma mensagem de resposta de EC, em conformidade com a norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].
(147)Na ausência de um registo, a EA deve gerar um código de erro e enviá-lo para a estação de STI-C utilizando uma mensagem de resposta EC, em conformidade com a norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].
(148)Os pedidos e as respostas de EC devem ser encriptados para garantir a confidencialidade e assinados para garantir a autenticação e a integridade.
4.3.1.5.Emissão de CA
(149)A estação de STI-C deve enviar uma mensagem de pedido de CA à AA em conformidade com a norma [1]. A AA deve enviar um pedido de validação do CA à EA em conformidade com a norma [1]. A EA deve enviar uma resposta de validação do CA à AA. Em caso de resposta positiva, a AA deve gerar um CA e enviá-lo para a estação de STI-C utilizando uma mensagem de resposta de CA, em conformidade com a norma [1]. Em caso de resposta negativa, a AA deve gerar um código de erro e enviá-lo para a estação de STI-C utilizando uma mensagem de resposta de CA, em conformidade com a norma [1]. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].
(150)Os pedidos e as respostas de CA devem ser encriptados (necessário apenas para as estações de STI-C móveis) para garantir a confidencialidade e assinadas para garantir autenticação e integridade.
4.3.2.Notificação da CA aos subscritores da emissão de certificados.
Não aplicável.
4.4.Aceitação de certificados
4.4.1.Realização da aceitação de certificados
4.4.1.1.CA de raiz
Não aplicável.
4.4.1.2.TLM
Não aplicável.
4.4.1.3.EA e AA
(151)A EA/AA deve verificar o tipo de certificado, a assinatura e as informações no certificado recebido. A EA/AA deve rejeitar todos os certificados de EA/AA que não estão verificados corretamente e emitir um novo pedido.
4.4.1.4.Estação de STI-C
(152)A estação de STI-C deve verificar a resposta de EC/CA recebida da EA/AA em relação ao seu pedido original, incluindo a assinatura e a cadeia de certificação. Deve rejeitar todas as respostas de EC/CA que não sejam corretamente verificadas. Nesses casos, deve enviar um novo pedido de EC/CA.
4.4.2.Publicação do certificado
(153)Os certificados de TLM e respetivos certificados de ligação devem ser disponibilizados a todos os participantes através do CPOC.
(154)Os certificados de CA de raiz são publicados pelo CPOC através da ECTL, que é assinada pelo TLM.
(155)Os certificados das subautoridades de certificação (EA e AA) são publicados pela CA de raiz.
(156)As EC e os CA não são publicados.
4.4.3.Notificação de emissão de certificado
Não há lugar a notificações de emissão.
4.5.Par de chaves e utilização do certificado
4.5.1.Chave privada e utilização do certificado
4.5.1.1.Chave privada e utilização de certificados para TLM
(157)O TLM deve utilizar as suas chaves privadas para assinar os próprios certificados (de TLM e de ligação) e a ECTL.
(158)O certificado do TLM deve ser utilizado pelos participantes da PKI para verificar a ECTL e autenticar o TLM.
4.5.1.2.Chave privada e utilização de certificados para CA de raiz
(159)As CA de raiz devem utilizar as suas chaves privadas para assinar os próprios certificados, CRL, certificados de ligação e os certificados de EA/AA.
(160)Os certificados da CA de raiz devem ser utilizados pelos participantes da PKI para verificar os certificados de AA e EA associados, os certificados de ligação e as CRL.
4.5.1.3.Chave privada e utilização de certificados para EA e AA
(161)As EA devem utilizar as suas chaves privadas para assinar EC e para desencriptar pedidos de inscrição.
(162)Os certificados de EA devem ser utilizados para verificar a assinatura das EC associadas e para a encriptação de pedidos de EC e CA por EE conforme definido na norma [1].
(163)As AA devem utilizar as suas chaves privadas para assinar CA e para desencriptar pedidos de CA.
(164)Os certificados de AA devem ser utilizados pelas EE para verificar os CA associados e para a encriptação de pedidos de CA, conforme definido na norma [1].
4.5.1.4.Chave privada e utilização de certificados para a entidade final
(165)As EE devem utilizar a chave privada correspondente a uma EC válida para assinar um novo pedido de inscrição conforme definido na norma [1]. A nova chave privada deve ser utilizada para construir a assinatura interna no pedido, para comprovar a posse da chave privada correspondente à nova chave pública de EC.
(166)As EE devem utilizar a chave privada correspondente a uma EC válida para assinar um pedido de autorização conforme definido na norma [1]. A chave privada correspondente ao novo CA deve ser utilizada para construir a assinatura interna no pedido para comprovar a posse da chave privada correspondente à nova chave pública do CA.
(167)A EE deve utilizar a chave privada correspondente a um CA adequado para assinar mensagens da estação de STI-C conforme definido na norma [5].
4.5.2.Chave pública e utilização de certificados da parte utilizadora
(168)As partes utilizadoras utilizam o caminho de certificação de confiança e as chaves públicas associadas para os fins referidos nos certificados e para autenticar a identidade comum de confiança de EC e CA.
(169)Não devem ser utilizados certificados de CA de raiz, de EA e de AA, EC e CA sem uma verificação preliminar por uma parte utilizadora.
4.6.Renovação de certificado
Não autorizada.
4.7.Reemissão de chave de certificado
4.7.1.Circunstâncias para a reemissão de chave de certificado
(170)Deve ser processado um certificado de reemissão de chave quando um certificado atinge o fim de vida útil ou uma chave privada atinge o fim da utilização operacional, mantendo, contudo, a relação de confiança com a CA. Deve sempre ser gerado e emitido um novo par de chaves, bem como o certificado correspondente.
4.7.2.Quem pode solicitar a reemissão de chave
4.7.2.1.CA de raiz
(171)A CA de raiz não solicita a reemissão de chave. O processo de reemissão de chave é um processo interno para a CA de raiz, uma vez que esta assina o próprio certificado. A CA de raiz deve proceder à reemissão de chave através de certificados de ligação ou de uma nova emissão (ver secção 4.3.1.1).
4.7.2.2.TLM
(172)O TLM não solicita a reemissão de chave. O processo de reemissão de chave é um processo interno para o TLM de raiz, uma vez este assina o próprio certificado.
4.7.2.3.EA e AA
(173)O pedido de certificado da CA subordinada deve ser enviado em tempo útil para garantir a criação de um novo certificado da CA subordinada e um par de chaves operacional da CA subordinada antes de expirar a atual chave da CA subordinada privada. A data de apresentação deve ainda levar em conta o tempo necessário para a aprovação.
4.7.2.4.Estação de STI-C
Não aplicável.
4.7.3.Processo de reemissão de chave
4.7.3.1.Certificado do TLM
(174)O TLM decide proceder à reemissão de chave com base nos requisitos das secções 6.1 e 7.2. O processo encontra-se definido em detalhe na respetiva CPS.
(175)O TLM deve executar o processo de reemissão de chave em tempo útil, a fim de permitir a distribuição do novo certificado de TLM e certificado de ligação a todos os participantes antes de o atual certificado de TLM expirar.
(176)O TLM deve utilizar certificados de ligação para a reemissão de chaves e para garantir a relação de confiança do novo certificado autoassinado. O certificado de TLM e de ligação recém-gerado é transferido para o CPOC.
4.7.3.2.Certificado da CA de raiz
(177)A CA de raiz decide proceder à reemissão de chaves com base nos requisitos das secções 6.1.5 e 7.2. O processo deve ser definido em detalhe na respetiva CPS.
(178)A CA de raiz deve executar o processo de reemissão de chave em tempo útil (antes da expiração do certificado da CA de raiz) para permitir a inserção do novo certificado na ECTL antes de o certificado da CA de raiz se tornar válido (ver secção 5.6.2). O processo de reemissão de chave deve ser realizado seja através de certificados de ligação seja como um pedido inicial.
4.7.3.3.Certificados de EA e AA
(179)A EA ou AA deve solicitar um novo certificado do seguinte modo:
|
Etapa
|
Indicação
|
Pedido de reemissão de chave
|
|
1
|
Geração de par de chaves
|
As CA subordinadas (EA e AA) devem gerar novos pares de chaves de acordo com a secção 6.1.
|
|
2
|
Pedido de geração de certificado e assinatura interna
|
A CA subordinada gera um pedido de certificado a partir da chave pública recém-gerada considerando o esquema de nomenclatura (subject_info) da secção 3, o algoritmo de assinatura, os Service Specific Permissions (SSP) e o parâmetro adicional facultativo e gera a assinatura interna com a nova chave privada correspondente. Se for necessária uma chave de encriptação, a CA subordinada também deve comprovar a posse da chave privada de desencriptação correspondente.
|
|
3
|
Gerar uma assinatura externa
|
Todo o pedido deve ser assinado com a chave privada válida à data, para garantir a autenticidade do pedido assinado.
|
|
4
|
Enviar pedido à CA de raiz
|
O pedido assinado deve ser enviado à CA de raiz correspondente.
|
|
5
|
Verificação do pedido
|
A CA de raiz correspondente deve verificar a integridade e a autenticidade do pedido. Deve, em primeiro lugar, verificar a assinatura externa. Se a verificação for positiva, deve verificar a assinatura interna. Na presença de elementos que comprovem a posse da chave de desencriptação privada, esse elemento também deverá ser verificado.
|
|
6
|
Aceitar ou rejeitar pedido
|
Se todas as verificações conduzirem a um resultado positivo, a CA de raiz aceita o pedido; caso contrário, rejeita-o.
|
|
7
|
Gerar e emitir certificado
|
A CA de raiz gera um novo certificado e o transmite-o à CA subordinada requerente.
|
|
8
|
Enviar reposta
|
A CA subordinada deve enviar uma mensagem de estado (indicando se o certificado foi ou não recebido) à CA de raiz.
|
Quadro 3: Processo de reemissão de chave para EA e AA
(180)Durante a reemissão de chave automática para CA subordinadas, a CA raiz deve garantir que o requerente está realmente na posse da sua chave privada. Devem ser aplicados protocolos adequados para a comprovação da posse de chaves de desencriptação privadas, por exemplo, conforme definido nos RFC 4210 e 4211. Para chaves de assinatura privada, deve ser utilizada a assinatura interna.
4.7.3.4.Certificados da estação de STI-C
Não aplicável a CA.
4.8.Alteração de certificado
Não autorizada.
4.9.Revogação e suspensão de certificado
Ver secção 7
4.10.Serviços de estado de certificado
4.10.1.Características operacionais
Não aplicável
4.10.2.Disponibilidade do serviço
Não aplicável
4.10.3.Características facultativas
Não aplicável
4.11.Fim da subscrição
Não aplicável
4.12.Retenção e recuperação de chaves
4.12.1.Subscritor
4.12.1.1.Que par de chaves pode ser retido
Não aplicável.
4.12.1.2.Quem pode submeter um pedido de recuperação
Não aplicável.
4.12.1.3.Processo de recuperação e responsabilidades
Não aplicável.
4.12.1.4.Identificação e autenticação
Não aplicável.
4.12.1.5.Aprovação ou rejeição de pedidos de recuperação
Não aplicável.
4.12.1.6.Ações da autoridade de retenção de chaves e da autoridade de recuperação de chaves durante a recuperação do par de chaves
Não aplicável.
4.12.1.7.Disponibilidade da autoridade de retenção de chaves e da autoridade de recuperação de chaves
Não aplicável.
4.12.2.Política e práticas de encapsulação e recuperação de chaves de sessão
Não aplicável.
5.Instalações, gestão e controlos operacionais
(181)A PKI é composta pela CA de raiz, a EA/AA, o CPOC e o TLM, incluindo os respetivos componentes de TIC (por exemplo, redes e servidores).
(182)Na presente secção, a entidade responsável por um elemento da PKI é identificada pelo próprio elemento. Por outras palavras, o enunciado «a CA é responsável por executar a auditoria» é equivalente a «a entidade ou o pessoal que gere a CA é responsável por executar ...».
(183)A expressão «elementos do modelo de confiança de STI-C» inclui a CA de raiz, o TLM, a EA/AA, o CPOC e a rede segura.
5.1.Controlos físicos
(184)Todas as operações do modelo de confiança de STI-C devem ser conduzidas num ambiente fisicamente protegido que impeça, previna e detete a utilização, o acesso ou a divulgação não autorizados de informações e sistemas sensíveis. Os elementos do modelo de confiança de STI-C devem utilizar controlos de segurança física em conformidade com as normas ISO 27001 e ISO 27005.
(185)As entidades que gerem os elementos do modelo de confiança de STI-C devem descrever os controlos de segurança física, processual e de pessoal na sua CPS. Em especial, a CPS deve cobrir informações sobre a localização física e a construção dos edifícios e os seus controlos físicos de segurança, garantindo o acesso controlado a todas as divisões utilizadas nas instalações das entidades do modelo de confiança de STI-C.
5.1.1.Localização física e construção
5.1.1.1.CA de raiz, CPOC e TLM
(186)A localização e a construção das instalações que alojam os equipamentos e dados da CA de raiz, do CPOC e do TLM (HSM, dados de ativação, salvaguarda do par de chaves, computador, registo, script de cerimónia de chave, pedido de certificado, etc.) devem ser coerentes com as instalações utilizadas para armazenar informações sensíveis e de elevado valor. A CA de raiz deve ser operada numa área física dedicada, separada das áreas físicas de outros componentes da PKI.
(187)A CA de raiz, o CPOC e o TLM devem implementar políticas e procedimentos para garantir que é mantido um alto nível de segurança no ambiente físico em que o equipamento da CA de raiz está instalado, de modo a garantir que:
·está isolado de redes fora do modelo de confiança;
·está separado numa série de (pelo menos dois) perímetros físicos progressivamente mais seguros;
·os dados sensíveis (HSM, salvaguarda de pares de chaves, dados de ativação, etc.) são armazenados num cofre dedicado localizado numa área física dedicada sob controlo de acesso múltiplo.
(188)As técnicas de segurança utilizadas devem ser concebidas para resistir a um grande número e uma vasta combinação de diversas formas de ataque. Os mecanismos utilizados devem incluir pelo menos:
·alarmes de perímetro, televisão de circuito fechado, paredes reforçadas e detetores de movimento;
·autenticação de dois fatores (por exemplo, cartão inteligente e PIN) para qualquer pessoa e cartão de acesso que entre e saia das instalações da CA de raiz e da área física protegida e segura.
(189)A CA de raiz, o CPOC e o TLM utilizam pessoal autorizado para monitorizar continuamente o equipamento de alojamento das instalações, 24 horas por dia, todos os dias do ano. O ambiente operacional (por exemplo, as instalações físicas) nunca deve ser deixado sem vigilância. O pessoal do ambiente operacional nunca deve ter acesso às áreas seguras das CA de raiz ou das subautoridades de supervisão, a menos que seja autorizado.
5.1.1.2.EA/AA
(190)Aplicam-se as mesmas disposições que na secção 5.1.1.1.
5.1.2.Acesso físico
5.1.2.1.CA de raiz, CPOC e TLM
(191)Os equipamentos e dados (HSM, dados de ativação, salvaguarda do par de chaves, computador, registo, script de cerimónia de chave, pedido de certificado, etc.) devem estar sempre protegidos contra o acesso não autorizado. Os mecanismos de segurança física do equipamento devem, pelo menos:
·monitorizar em permanência, manual ou eletronicamente, intrusões não autorizadas;
·garantir que não é permitido qualquer acesso não autorizado ao equipamento informático e aos dados de ativação;
·assegurar que todos os suportes removíveis e documentos em papel que contêm informações confidenciais de texto simples são armazenados num recipiente seguro;
·garantir de forma permanente que qualquer pessoa que entre em áreas seguras e não autorizadas não fique sem a supervisão de um funcionário autorizado das instalações de CA raiz, CPOC e TLM;
·assegurar a manutenção permanente de um registo de acesso e a sua inspeção periódica;
·garantir pelo menos dois níveis de segurança progressivamente crescente, por exemplo, a nível do perímetro, do edifício e da sala de operações;
·exigir dois controlos de acesso físico fidedignos para os dados criptográficos do HSM e de ativação.
(192)Deve ser efetuada uma verificação de segurança do equipamento de armazenamento das instalações no caso de este ser deixado sem supervisão. No mínimo, a verificação deve confirmar que:
·o equipamento está num estado adequado ao modo de operação atual;
·no caso dos componentes fora de linha, todos os equipamentos estão desligados;
·os recipientes de segurança (sobrescritos invioláveis, cofres, etc.) estão devidamente protegidos;
·os sistemas de segurança física (por exemplo, fechaduras de porta, tampas de ventilação, eletricidade) funcionam corretamente;
·a área está protegida contra o acesso não autorizado.
(193)Os módulos criptográficos removíveis devem ser desativados antes do armazenamento. Quando não estiverem a ser utilizados, esses módulos e os dados de ativação utilizados para lhes aceder ou para os ativar devem ser colocados num cofre. Os dados de ativação devem ser memorizados ou gravados e armazenados de forma compatível com a segurança garantida ao módulo criptográfico. Não devem ser armazenados com o módulo criptográfico, de modo a evitar que apenas uma pessoa tenha acesso à chave privada.
(194)Uma pessoa ou um grupo de funções de confiança deve ser expressamente responsável por efetuar essas verificações. Quando a responsabilidade cabe a um grupo de pessoas, deve ser mantido um registo que identifique a pessoa que realiza cada verificação. Se a instalação não for continuamente vigiada, a última pessoa a sair deverá rubricar uma folha de controlo de saída que indique a data e a hora e confirmar que todos os mecanismos de proteção física necessários estão implementados e ativados.
5.1.2.2.EA/AA
(195)Aplicam-se as mesmas disposições que na secção 5.1.2.1.
5.1.3.Energia e ar condicionado
(196)As instalações protegidas dos elementos do modelo de confiança de STI-C (CA de raiz, CPOC, TLM, EA e AA) devem estar equipadas com acesso fiável à energia elétrica para garantir uma operação sem falhas ou com falhas mínimas. É necessário prever instalações primárias e de salvaguarda em caso de falha de energia externa e o desligamento sem ruturas do equipamento do modelo de confiança de STI-C em caso de falta de energia. As instalações do modelo de confiança de STI-C devem estar equipadas com sistemas de aquecimento/ventilação/ar condicionado, de forma a manter a temperatura e a humidade relativa do equipamento do modelo de confiança de STI-C dentro da gama de funcionamento. A CPS do elemento do modelo de confiança de STI-C descreverá em detalhe o plano e os processos para implementar tais requisitos.
5.1.4.Exposição à água
(197)As instalações protegidas dos elementos do modelo de confiança de STI-C (CA de raiz, CPOC, TLM, EA e AA) devem ser protegidas de forma a minimizar o impacto da exposição à água. Por esta razão, devem ser evitadas as condutas de água e condutas subterrâneas. A CPS do elemento do modelo de confiança de STI-C descreverá em detalhe o plano e os processos para implementar tais requisitos.
5.1.5.Prevenção e proteção contra incêndios
(198)Para evitar a exposição prejudicial a chamas ou fumo, as instalações de segurança dos elementos do modelo de confiança de STI-C (CA de raiz, CPOC, TLM, EA e AA) devem ser construídas e equipadas em conformidade e devem ser implementados procedimentos para fazer face a ameaças relacionadas com incêndios. Os suportes de armazenamento devem ser protegidos contra o fogo em recipientes adequados.
(199)Os elementos do modelo de confiança de STI-C devem proteger os suportes físicos que armazenam cópias de segurança de dados críticos do sistema ou de quaisquer outras informações sensíveis contra riscos ambientais e a utilização, o acesso ou a divulgação não autorizados desses suportes. A CPS do elemento do modelo de confiança de STI-C descreverá em detalhe o plano e os processos para implementar tais requisitos.
5.1.6.Gestão de suportes
(200)Os suportes utilizados nos elementos do modelo de confiança de STI-C (CA de raiz, CPOC, TLM, EA e AA) devem ser manipulados de forma segura, de forma que estejam protegidos contra danos, roubo e acesso não autorizado. Os procedimentos de gestão dos suportes são implementados de forma a proteger contra a obsolescência e a deterioração dos suportes no período em que os registos devem ser mantidos.
(201)Os dados sensíveis devem ser protegidos contra o acesso decorrente de objetos de armazenamento reutilizados (por exemplo, ficheiro eliminados), que podem tornar os dados sensíveis acessíveis a utilizadores não autorizados.
(202)Deve ser mantido um inventário de todos os elementos de informação e devem ser definidos requisitos para a proteção desses elementos em linha com a análise de riscos. A CPS do elemento do modelo de confiança de STI-C descreverá em detalhe o plano e os processos para implementar tais requisitos.
5.1.7.Eliminação de resíduos
(203)Os elementos do modelo de confiança de STI-C (CA de raiz, CPOC, TLM, EA e AA) devem implementar procedimentos para a eliminação segura e irreversível de resíduos (papel, suportes ou qualquer outro resíduo) para impedir a utilização, o acesso ou a divulgação não autorizados de resíduos que contenham informações confidenciais/privadas. Todos os suportes utilizados para o armazenamento de informações sensíveis, tais como chaves, dados de ativação ou ficheiros, devem ser destruídos antes de serem enviados para eliminação. A CPS do elemento do modelo de confiança de STI-C descreverá em detalhe o plano e os processos para implementar tais requisitos.
5.1.8.Salvaguarda fora do local
5.1.8.1.CA de raiz, CPOC e TLM
(204)As salvaguardas completas de componentes da CA de raiz, do CPOC e do TLM, suficientes para a recuperação de falhas do sistema, devem ser efetuadas fora de linha após a implantação da CA de raiz, do CPOC e do TLM e após cada nova geração de um par de chaves. Devem ser feitas cópias de segurança regulares de informações comerciais (par de chaves e CRL) e aplicações informáticas essenciais. Devem ser previstas instalações de salvaguarda adequadas para garantir que todas as informações comerciais e aplicações informáticas essenciais podem ser recuperados após uma catástrofe ou uma falha dos suportes. As medidas de salvaguarda no que respeita a sistemas individuais devem ser testadas regularmente para garantir que cumprem os requisitos do plano de continuidade das atividades. Deve ser armazenada pelo menos uma cópia de segurança completa fora do local (recuperação em caso de catástrofe). A cópia de segurança deve ser armazenada num local com controlos físicos e processuais compatíveis com o sistema da PKI operacional.
(205)Os dados salvaguardados devem estar sujeitos aos mesmos requisitos de acesso que os dados operacionais. Os dados salvaguardados devem ser encriptados e armazenados fora do local. Em caso de perda total de dados, as informações necessárias para colocar a CA raiz, o CPOC e o TLM de novo em funcionamento devem ser totalmente recuperadas a partir dos dados salvaguardados.
(206)O material privado de cifragem da CA de raiz, do CPOC e do TLM não deve ser salvaguardado utilizando mecanismos de salvaguarda padrão, mas utilizando a função de salvaguarda do módulo criptográfico.
5.1.8.2.EA/AA
(207)Aplicam-se a esta secção os processos descritos na secção 5.1.8.1.
5.2.Procedimentos de controlo
A presente secção descreve os requisitos aplicáveis no que respeita a funções, deveres e identificação do pessoal.
5.2.1.Funções de confiança
(208)Os funcionários, contratantes e consultores designados para funções de confiança devem ser considerados «pessoas de confiança». As pessoas que pretendam vir a ser pessoas de confiança assumindo um cargo de confiança devem cumprir os requisitos de rastreio da presente política de certificado.
(209)Pessoas de confiança têm acesso a, ou controlam, operações de autenticação ou criptográficas que podem afetar materialmente:
·as informações de validação dos pedidos de certificado;
·a aceitação, rejeição ou outros processamentos de pedidos de certificado, pedidos de revogação ou pedidos de renovação;
·a emissão ou revogação de certificados, incluindo pessoal com acesso a partes restritas do seu repositório ou o tratamento de informações ou pedidos de subscritores.
(210)A título de exemplo, referem-se as seguintes funções de confiança:
·serviço ao cliente;
·administração do sistema;
·engenharia designada;
·executivos encarregados da gestão da confiabilidade da infraestrutura.
(211)A CA deve apresentar descrições claras de todas as funções de confiança na sua CPS.
5.2.2.Número de pessoas necessário por tarefa
(212)Os elementos do modelo de confiança de STI-C devem estabelecer, manter e aplicar procedimentos de controlo rigorosos para garantir a separação de tarefas com base em funções de confiança e garantir que são necessárias várias pessoas de confiança para realizar tarefas sensíveis. Os elementos do modelo de confiança de STI-C (TLM, CPOC, CA de raiz, EA e AA) devem cumprir a norma [4] e cumprir os requisitos dos parágrafos a seguir.
(213)Devem estar implementadas políticas e procedimentos de controlo para garantir a separação de tarefas com base nas responsabilidades do cargo de trabalho. As tarefas mais sensíveis, como o acesso e a gestão do equipamento informático de criptografia (HSM) da CA e o material de cifragem associado, devem exigir a autorização de várias pessoas de confiança.
(214)Esses procedimentos de controlo interno devem ser projetados para garantir que pelo menos duas pessoas de confiança têm acesso físico ou lógico ao dispositivo. Devem ser aplicadas restrições rigorosas ao acesso ao equipamento informático de criptografia da CA por várias pessoas de confiança em todo o seu ciclo de vida, desde a receção e inspeção de entrada até à destruição final lógica e/ou física. Quando um módulo é ativado com chaves operacionais, é necessário invocar outros controlos de acesso para manter um controlo dividido do acesso físico e lógico ao dispositivo.
5.2.3.Identificação e autenticação para cada função
(215)Todas as pessoas designadas para uma função, conforme descrito na presente CP, são identificadas e autenticadas de forma a garantir que a função lhes permita desempenhar as suas obrigações de PKI.
(216)Os elementos do modelo de confiança de STI-C devem verificar e confirmar a identidade e a autorização de todos os membros do pessoal que pretendam tornar-se uma pessoa de confiança, antes de:
·lhes serem emitidos os seus dispositivos de acesso e lhes ser concedido o acesso às instalações necessárias;
·lhes serem fornecidas credenciais eletrónicas para aceder a, e executar, funções específicas nos sistemas da CA.
(217)A CPS descreve os mecanismos utilizados para identificar e autenticar indivíduos.
5.2.4.Funções que requerem a separação de tarefas
(218)A título de exemplo, referem-se as funções que requerem uma separação das tarefas:
·a aceitação, rejeição e revogação de pedidos e outros processamentos de pedidos de certificado de CA;
·a geração, emissão e destruição de um certificado de CA.
(219)A separação de funções pode ser aplicada utilizando equipamentos ou procedimentos da PKI, ou ambos. Não deve ser atribuída mais de uma identidade a nenhum indivíduo, a menos que seja aprovado pela CA de raiz.
(220)A parte da CA de raiz e da CA relacionada com a geração e a gestão da revogação de certificados deve ser independente de outras organizações para as decisões que tomar relacionadas com o estabelecimento, o fornecimento, a manutenção e a suspensão de serviços, de acordo com as políticas de certificação aplicáveis. Em especial, os respetivos quadros superiores e funcionários que assumem funções de confiança devem estar isentos de quaisquer pressões, nomeadamente comerciais e financeiras, que possam influenciar adversamente a confiança nos serviços prestados.
(221)A EA e a AA que servem estações móveis de STI-C devem ser entidades operacionais separadas, com equipas separadas de infraestrutura de TI e de gestão de TI. Nos termos do GDPR, a EA e a AA não devem trocar quaisquer dados pessoais, exceto no caso das autorizações de pedidos de CA. Devem transferir os dados relativos à aprovação de pedidos de CA utilizando apenas o protocolo de validação de autorização da norma [1] através de uma interface dedicada protegida. Podem ser utilizados outros protocolos, desde que seja implementada a norma [1].
(222)Os ficheiros de registo armazenados pela EA e pela AA podem ser utilizados com o único propósito de revogar EC com comportamento impróprio com base em CA em mensagens CAM/DENM intercetadas. Depois de uma mensagem CAM/DENM ser identificada como maliciosa, a AA procurará a chave de verificação do CA nos registos de emissão e enviará um pedido de revogação à EA contendo a assinatura encriptada sob a chave privada da EC utilizada durante a emissão do CA. Todos os ficheiros de registo devem ser adequadamente protegidos contra o acesso de partes não autorizadas e não podem ser partilhados com outras entidades ou autoridades.
Nota: no momento da elaboração da presente versão da CP, a conceção da função de comportamento impróprio não se encontra definida. Está prevista uma potencial conceção da função de comportamento impróprio em futuras revisões da política.
5.3.Controlos de pessoal
5.3.1.Requisitos relativos a qualificações, experiência e credenciação
(223)Os elementos do modelo de confiança de STI-C empregam um número suficiente de funcionários com os conhecimentos especializados, a experiência e as qualificações necessárias para as funções e os serviços oferecidos. O pessoal da PKI deve cumprir esses requisitos através de formação formal e credenciais, experiência real ou uma combinação de ambos. As funções e responsabilidades de confiança, conforme especificado na CPS, devem ser documentadas em descrições de cargos e claramente identificadas. Os subcontratantes do pessoal da PKI têm descrições de cargos definidos para garantir a separação de deveres e tarefas, e o caráter sensível da posição é determinado com base nos níveis de tarefas e de acesso, a verificação de antecedentes e a formação e sensibilização dos funcionários.
5.3.2.Procedimentos de verificação de antecedentes
(224)Os elementos do modelo de confiança de STI-C devem submeter o pessoal que pretenda tornar-se pessoa de confiança a verificações de antecedentes. No caso do pessoal que ocupa cargos de confiança, as verificações de antecedentes devem ser repetidas, pelo menos, de cinco em cinco anos.
(225)A título de exemplo, referem-se os fatores revelados numa verificação de antecedentes que possam ser considerados motivos para rejeitar candidatos para cargos de confiança ou intentar uma ação contra uma pessoa de confiança existente:
·falsas declarações feitas pelo candidato ou pessoa de confiança;
·referências profissionais altamente desfavoráveis ou pouco fiáveis;
·certas condenações penais;
·indicações de falta de responsabilidade financeira.
(226)O pessoal dos recursos humanos deve avaliar os relatórios que contenham essas informações, devendo tomar medidas adequadas em função do tipo, da magnitude e da frequência do comportamento revelado pela verificação de antecedentes. Essas medidas podem, em última análise, culminar no cancelamento de ofertas de emprego feitas a candidatos para cargos de confiança ou na cessação da relação de trabalho com atuais pessoas de confiança. A utilização das informações reveladas numa verificação de antecedentes como base para tais medidas estará sujeita à legislação aplicável.
(227)A título de exemplo, referem-se fatores da investigação de antecedentes de pessoas que pretendem tornar-se uma pessoa de confiança:
·confirmação de emprego anterior;
·uma verificação de referências profissionais que abranja o respetivo emprego por um período de pelo menos cinco anos;
·uma confirmação do grau de ensino mais elevado ou mais relevante obtido;
·averiguação de registos criminais.
5.3.3.Requisitos de formação
(228)Os elementos do modelo de confiança de STI-C devem fornecer ao seu pessoal a formação necessária para cumprir as suas responsabilidades relacionadas com as operações da CA de forma competente e satisfatória.
(229)Os programas de formação devem ser revistos periodicamente e a sua formação deve incidir sobre assuntos relevantes para as funções desempenhadas pelo seu pessoal.
(230)Os programas de formação devem incidir sobre assuntos relevantes para o ambiente particular do formando, nomeadamente:
·princípios e mecanismos de segurança dos elementos do modelo de confiança de STI-C;
·versões do equipamento informático e de aplicações informáticas utilizadas;
·todos as tarefas que a pessoa deve desempenhar e processos e sequências de relatórios internos e externos;
·processos empresariais e fluxos de trabalho da PKI;
·elaboração de relatórios e tratamento de incidentes e comprometimentos;
·recuperação em caso de catástrofe e procedimentos de continuidade das atividades;
·conhecimentos suficientes em matéria de TI.
5.3.4.Frequência e requisitos de ações de reciclagem
(231)As pessoas designadas para funções de confiança devem atualizar os conhecimentos adquiridos na formação de forma contínua, num ambiente de formação. A formação deve ser repetida sempre que necessário e pelo menos a cada dois anos.
(232)Os elementos do modelo de confiança de STI-C devem fornecer ações de formação de reciclagem e atualizações ao seu pessoal, na medida e com a frequência necessária para garantir que este mantém o nível de proficiência exigido para cumprir as responsabilidades do cargo de forma competente e satisfatória.
(233)Os indivíduos em funções de confiança devem estar cientes das alterações nas operações da PKI, conforme aplicável. Qualquer alteração significativa nas operações deve ser acompanhada de um plano de formação (sensibilização) e a execução desse plano deve ser documentada.
5.3.5.Frequência e sequência da rotação de funções
(234)Sem estipulação, desde que as competências técnicas, a experiência e os direitos de acesso sejam assegurados. Os administradores dos elementos do modelo de confiança de STI-C devem garantir que as alterações no pessoal não afetam a segurança do sistema.
5.3.6.Sanções para ações não autorizadas
(235)Cada elemento do modelo de confiança de STI-C deve desenvolver um processo disciplinar formal para garantir que as ações não autorizadas são devidamente sancionadas. Em casos graves, as atribuições de funções e os privilégios correspondentes devem ser retirados.
5.3.7.Requisitos aplicáveis aos contratantes independentes
(236)Os elementos do modelo de confiança de STI-C podem permitir que os contratantes ou consultores independentes se tornem pessoas de confiança apenas na medida necessária para ter relações de externalização claramente definidas e na condição de a entidade depositar confiança nos contratantes ou consultores tal como se fossem funcionários e de aqueles cumprirem os requisitos aplicáveis aos funcionários.
(237)Caso contrário, os contratantes e consultores independentes apenas devem ter acesso às instalações protegidas da PKI do STI-C se acompanhados e diretamente supervisionados por pessoas de confiança.
5.3.8.Documentação fornecida ao pessoal
(238)Os elementos do modelo de confiança de STI-C devem proporcionar ao seu pessoal a formação necessária e o acesso à documentação de que necessitam para cumprir as responsabilidades do cargo de forma competente e satisfatória.
5.4.Procedimentos de registo de auditorias
(239)A presente secção define os requisitos relativos aos tipos de eventos a serem registados e à gestão dos registos de auditorias.
5.4.1.Tipos de eventos a serem registados e comunicados por cada CA
(240)Um representante da CA deve rever regularmente os registos, os eventos e os procedimentos da CA.
(241)Os elementos do modelo de confiança de STI-C devem registar os seguintes tipos de eventos de auditoria (se aplicável):
·acesso às instalações físicas – o acesso de pessoas singulares às instalações será registado pelo armazenamento dos pedidos de acesso através de cartões inteligentes. Será criado um evento sempre que for criado um registo;
·a gestão de funções de confiança – qualquer alteração na definição e no nível de acesso das diversas funções será registada, incluindo a alteração dos atributos das funções. Será criado um evento sempre que for criado um registo;
·acesso lógico – será gerado um evento quando uma entidade (por exemplo, um programa) tiver acesso a áreas sensíveis (por exemplo, redes e servidores);
·gestão da salvaguarda – é criado um evento sempre que uma salvaguarda é concluída, com ou sem êxito;
·gestão dos registos – os registos serão armazenados. É criado um evento quando um registo excede uma dimensão específica;
·dados do processo de autenticação para subscritores e elementos do modelo de confiança STI-C – serão gerados eventos para cada pedido de autenticação por subscritores e elementos do modelo de confiança de STI-C;
·aceitação e rejeição de pedidos de certificado, incluindo a criação e renovação de certificados – periodicamente, será gerado um evento com uma lista de pedidos de certificado aceites e rejeitados nos últimos sete dias;
·registo do fabricante – será criado um evento quando um fabricante for registado;
·registo da estação de STI-C – será criado um evento quando uma estação de STI-C for registada;
·gestão do HSM – será criado um evento quando se registar uma violação da segurança do HSM;
·gestão de rede e das TI, uma vez que pertencem aos sistemas da PKI – será criado um evento quando um servidor da PKI for desligado ou reiniciado;
·gestão de segurança (tentativas de acesso ao sistema da PKI, com ou sem êxito, ações da PKI e do sistema de segurança executadas, alterações no perfil de segurança, falhas no sistema, falhas do equipamento informático e outras anomalias, atividades da firewall e do roteador; e entradas e saídas das instalações PKI);
·os dados relacionados com eventos serão armazenados por pelo menos cinco anos, a menos se apliquem regras nacionais adicionais.
(242)Nos termos do GDPR, os registos de auditorias não devem permitir o acesso a dados relacionados com a privacidade relativos a veículos particulares da estação de STI-C.
(243)Sempre que possível, os registos de auditorias devem ser automaticamente recolhidos. Caso não seja possível, deve ser utilizado um registo de operações, um formulário em papel ou outro suporte físico. Todos os registos de auditorias de segurança, eletrónicos e não eletrónicos, devem ser conservados e disponibilizados durante as auditorias de conformidade.
(244)Cada evento relacionado com o ciclo de vida do certificado é registado de forma a poder ser associado à pessoa que o executou. Todos os dados relacionados com uma identidade pessoal são encriptados e protegidos contra o acesso não autorizado.
(245)No mínimo, cada registo de auditoria deve incluir o seguinte (gravado automática ou manualmente para cada evento passível de auditoria):
·tipo de evento (a partir da lista acima);
·data e hora de confiança em que o evento ocorreu;
·resultado do evento – êxito ou insucesso, se apropriado;
·identidade da entidade e/ou operador que causou o evento, se aplicável;
·identidade da entidade visada pelo evento.
5.4.2.Frequência do registo de processamento
(246)Os registos de auditoria devem ser analisados em resposta a alertas com base em irregularidades e incidentes dentro dos sistemas da CA e, além disso, periodicamente todos os anos.
(247)O processamento dos registos de auditoria deve consistir numa análise dos registos de auditorias e na documentação do motivo de todos os eventos significativos num resumo do registo de auditorias. As análises dos registos de auditoria devem incluir uma verificação de que o registo não foi adulterado, uma inspeção de todas as entradas de registo e uma investigação de quaisquer alertas ou irregularidades nos registos. As medidas tomadas com base nas análises dos registos de auditorias devem ser documentadas.
(248)O registo de auditoria é arquivado pelo menos uma vez por semana. Um administrador deve arquivá-lo manualmente se o espaço livre no disco para o registo de auditoria for inferior à quantidade esperada de dados do registo de auditoria produzidos naquela semana.
5.4.3.Período de conservação de registos de auditoria
(249)Os registos guardados relacionados com os ciclos de vida dos certificados são mantidos por pelo menos cinco anos após o termo do certificado correspondente.
5.4.4.Proteção de registos de auditoria
(250)A integridade e a confidencialidade do registo de auditoria são garantidas através de um mecanismo de controlo de acesso baseado em funções. Só os administradores poderão ter acesso aos registos de auditoria internos; Os registos de auditoria relacionados com o ciclo de vida de um certificado também podem ser acedidos por utilizadores com uma autorização adequada através de uma página Web com autenticação do utilizador. O acesso deve ser concedido com múltiplos utilizadores (no mínimo, dois utilizadores) e pelo menos dois níveis de autenticação. As condições técnicas devem assegurar que os utilizadores não podem aceder aos seus próprios ficheiros de registo.
(251)Cada entrada de registo deve ser assinada utilizando material de cifragem do HSM.
(252)Os registos de eventos que contêm informações que possam levar à identificação pessoal, como um veículo particular, são encriptados de forma a apenas poderem ser lidos por pessoas autorizadas.
(253)Os eventos são registados de forma a não poderem ser facilmente eliminados ou destruídos (exceto no que toca à transferência para suportes de longo prazo) durante o período em que os registos tiverem de ser mantidos.
(254)Os registos de eventos são protegidos de forma a permanecerem legíveis durante o período de armazenamento.
5.4.5.Procedimentos de salvaguarda de registos de auditoria
(255)Os registos e resumos de auditoria são salvaguardados por meio de mecanismos de salvaguarda empresariais, sob o controlo de funções de confiança autorizadas, separados da geração de origem do seu componente. As salvaguardas de registos de auditoria devem ser protegidas com o mesmo nível de confiança que se aplica aos registos originais.
5.4.6.Sistema de recolha de auditorias (interno ou externo)
(256)O equipamento dos elementos do modelo de confiança de STI-C deve ativar os processos de auditoria na inicialização do sistema e desativá-los apenas no encerramento do sistema. Se os processos de auditoria não estiverem disponíveis, o elemento de modelo de confiança de STI-C deve suspender a sua operação.
(257)No final de cada período de operação e na reemissão de chave de certificados, o estado coletivo do equipamento deve ser comunicado ao gestor de operações e ao órgão que dirige as operações do respetivo elemento da PKI.
5.4.7.Notificação ao sujeito causador de evento
(258)Quando um evento é registado pelo sistema de recolha de auditorias, garante que é associado a uma função de confiança.
5.4.8.Avaliação de vulnerabilidades
(259)A função de conduzir a auditoria e as funções de realizar a operação do sistema PKI nos elementos do modelo de confiança de STI-C explicam todos os eventos significativos num resumo de um registo de auditoria. Essas análises envolvem a verificação de que o registo não foi adulterado e que não existe descontinuidade ou outra perda de dados de auditoria e, em seguida, uma breve inspeção de todas as entradas de registo, averiguando em maior detalhe quaisquer alertas ou irregularidades nos registos. As medidas tomadas na sequência dessa análise devem ser documentadas.
(260)Os elementos do modelo de confiança de STI-C devem:
·implementar controlos de deteção e prevenção organizacionais e/ou técnicos sob o controlo dos elementos do modelo de confiança de STI-C, para proteger os sistemas da PKI contra vírus e programas maliciosos;
·documentar e seguir um processo de correção de vulnerabilidades que incida sobre a identificação, a análise, a resposta e a correção de vulnerabilidades;
·ser objeto de, ou realizar, uma análise de vulnerabilidades:
·após quaisquer alterações no sistema ou na rede que os elementos do modelo de confiança de STI-C considerem significativas para os componentes da PKI; e ainda
·pelo menos uma vez por mês, em endereços IP públicos e privados identificados pela CA e o CPOC como os sistemas da PKI,
·ser objeto de um teste de penetração nos sistemas da PKI pelo menos uma vez por ano e após atualizações ou alterações da infraestrutura ou da aplicação que os elementos do modelo de confiança de STI-C considerem significativas para o componente PKI da CA;
·para sistemas em linha, registar elementos que comprovem que todas as análises de vulnerabilidades e todos os testes de penetração foram realizados por uma pessoa ou entidade (ou respetivo grupo coletivo) com as competências, as ferramentas, a proficiência, o código de ética e a independência necessários para realizar um teste de vulnerabilidades ou de penetração fiável;
·rastrear e corrigir vulnerabilidades de acordo com as políticas de segurança cibernética da empresa e a metodologia de minimização de riscos.
5.5.Arquivo de registos
5.5.1.Tipos de registos arquivados
(261)Os elementos do modelo de confiança de STI-C devem arquivar os registos em detalhe suficiente para estabelecer a validade de uma assinatura e da correta operação da PKI. No mínimo, devem ser arquivados os seguintes registos de eventos da PKI (se aplicável):
·registo de acesso às instalações físicas dos elementos do modelo de confiança de STI-C (no mínimo, um ano);
·registo da gestão de funções de confiança para elementos do modelo de confiança de STI-C (no mínimo, 10 anos);
·registo de acesso de TI para elementos do modelo de confiança de STI-C (no mínimo, cinco anos);
·registo da criação, utilização e destruição da chave da CA (no mínimo, cinco anos) (não para TLM e CPOC);
·registo da criação, utilização e destruição de certificados (no mínimo, dois anos);
·registo de pedidos da CPA (no mínimo, dois anos);
·registo da gestão de dados de ativação para elementos do modelo de confiança STI-C (no mínimo, cinco anos);
·registo de TI e rede para elementos do modelo de confiança STI-C (no mínimo, cinco anos);
·documentação da PKI para elementos do modelo de confiança de STI-C (no mínimo, cinco anos);
·incidente de segurança e relatório de auditoria para os elementos do modelo de confiança de STI-C (no mínimo, 10 anos);
·equipamento do sistema, aplicações informáticas e configuração (no mínimo, cinco anos).
(262)Os elementos do modelo de confiança de STI-C devem manter a seguinte documentação relativa aos pedidos de certificados e respetiva verificação, e todos os certificados de TLM, CA de raiz e CA e respetiva CRL, por pelo menos sete anos após o fim de validade de qualquer certificado que se baseie nessa documentação:
·a documentação de auditoria da PKI mantida pelos elementos do modelo de confiança de STI-C;
·os documentos da CPS mantidos pelos elementos do modelo de confiança de STI-C;
·o contrato entre a CPA e outras entidades mantido pelos elementos do modelo de confiança de STI-C;
·os certificados (ou outras informações de revogação) mantidos pela CA e pelo TLM;
·os registos de pedidos de certificado no sistema da CA de raiz (não aplicável ao TLM);
·outros dados ou aplicações suficientes para verificar o conteúdo do arquivo;
·todo o trabalho relacionado com, ou com origem em, elementos do modelo de confiança C-ITS e auditores de conformidade.
(263)A entidade da CA deve conservar toda a documentação relacionada com os pedidos de certificado e a respetiva verificação, e todos os certificados e respetiva revogação, por pelo menos sete anos após o fim de validade de qualquer certificado que se baseie nessa documentação.
5.5.2.Período de conservação de arquivos
(264)Sem prejuízo da regulamentação que exija um período de arquivamento mais longo, os elementos do modelo de confiança de STI-C devem manter todos os registos por pelo menos cinco anos após o fim de validade do certificado correspondente.
5.5.3.Proteção de arquivos
(265)Os elementos do modelo de confiança de STI-C devem armazenar o arquivo de registos em instalações de armazenamento seguras e protegidas, separadas do equipamento da CA, com controlos de segurança físicos e processuais equivalentes ou superiores aos da PKI.
(266)O arquivo deve ser protegido contra a visualização, a alteração, a eliminação ou outras adulterações não autorizadas através do armazenamento num sistema fiável.
(267)Os suportes que contêm os dados do arquivo e as aplicações necessárias para os processar devem ser mantidos para assegurar a possibilidade de acesso aos mesmos pelo período definido na presente CP.
5.5.4.Arquivo e armazenamento do sistema
(268)Os elementos do modelo de confiança de STI-C devem proceder diariamente a uma salvaguarda suplementar dos arquivos do sistema dessas informações e realizar salvaguardas completas semanalmente. As cópias dos registos em papel devem ser mantidas em instalações protegidas fora do local.
5.5.5.Requisitos de validação cronológica de registos
(269)Os elementos do modelo de confiança de STI-C que gerem uma base de dados de revogação devem assegurar que os registos contêm informações sobre a hora e a data em que os registos de revogação são criados. A integridade dessas informações será implementada com soluções baseadas em criptografia.
5.5.6.Sistema de recolha de arquivos (interno ou externo)
(270)O sistema de recolha de arquivos é interno.
5.5.7.Procedimentos para obter e verificar informações do arquivo
(271)Todos os elementos do modelo de confiança de STI-C apenas devem permitir o acesso ao arquivo a pessoas de confiança autorizadas. As CA de raiz e as CA devem descrever os procedimentos para criar, verificar, criar pacotes, transmitir e armazenar informações de arquivo na CPS.
(272)O equipamento da CA de raiz e da CA deve verificar a integridade das informações antes de ser restaurado.
5.6.Transferência da chave para elementos do modelo de confiança de STI-C
(273)Os seguintes elementos do modelo de confiança STI-C possuem requisitos específicos para a transmissão de chave: certificados do TLM, da CA de raiz e da EA/AA
5.6.1.TLM
(274)O TLM deve eliminar a sua chave privada após o termo de validade do certificado correspondente. Deve gerar um novo par de chaves e um certificado de TLM correspondente antes de desativar a chave privada válida à data. Deve certificar-se de que o novo certificado (de ligação) é inserido na ECTL a tempo de ser transmitido a todas as estações de STI-C antes de passar a ser válido. O certificado de ligação e o novo certificado autoassinado são transferidos para o CPOC.
5.6.2.CA de raiz
(275)A CA de raiz deve desativar e eliminar a chave privada atual (incluindo as chaves de salvaguarda), para que não emita certificados de EA/AA com uma validade que se estenda além da validade do certificado da CA de raiz.
(276)A CA de raiz deve gerar um novo par de chaves e o certificado de CA de raiz e de ligação correspondente antes de desativar a chave privada atual (incluindo as chaves de salvaguarda) e de os enviar ao TLM para inserção na ECTL. O período de validade do novo certificado de CA de raiz deve começar na desativação planeada da chave privada atual. A CA de raiz deve certificar-se de que o novo certificado é inserido na ECTL a tempo de ser distribuído a todas as estações de STI-C antes de passar a ser válido.
(277)A CA de raiz deve ativar a nova chave privada quando o certificado da CA de raiz correspondente passar a ser válido.
5.6.3.Certificado da EA/AA
(278)A EA/AA deve desativar a chave privada atual, para que não emita certificados de EC/CA com uma validade que se estenda além da validade do certificado de EA/AA.
(279)A EA/AA deve gerar um novo par de chaves e solicitar um certificado de EA/AA correspondente antes de desativar a chave privada atual. O período de validade do novo certificado de EA/AA deve começar na desativação planeada da chave privada atual. A EA/AA deve certificar-se de que o novo certificado pode ser publicado a tempo de ser transmitido a todas as estações de STI-C antes de passar a ser válido.
(280)A EA/AA deve ativar a nova chave privada quando o certificado de EA/AA correspondente passar a ser válido.
5.6.4.Auditor
Ausência de disposições.
5.7.Recuperação em caso de comprometimento e catástrofe
5.7.1.Tratamento de incidentes e comprometimentos
(281)Os elementos do modelo de confiança de STI-C devem monitorizar os seus equipamentos de forma contínua, para detetar possíveis tentativas de intrusão ou outras formas de comprometimento. Nesse caso, devem investigar a fim de determinar a natureza e o grau dos danos.
(282)Se o pessoal responsável pela gestão da CA de raiz ou do TLM detetar uma potencial tentativa de intrusão ou outra forma de comprometimento, deverá investigar a fim de determinar a natureza e o grau de dano. Em caso de comprometimento da chave privada, o certificado da CA de raiz deve ser revogado. Os especialistas em segurança de TI da CPA devem avaliar a extensão dos potenciais danos a fim de determinar se é necessário reconstruir a PKI, se apenas alguns certificados devem ser revogados e/ou se a PKI foi comprometida. Além disso, a CPA determina quais os serviços que devem ser mantidos (informações de estado de revogação e de certificado) e de que forma, de acordo com o plano de continuidade das atividades da CPA.
(283)A CPS abrange os incidentes, o comprometimento e a continuidade das atividades, podendo também contar com outros recursos e planos da empresa para a sua implementação.
(284)Se o pessoal responsável pela gestão da EA/AA/CPOC detetar uma potencial tentativa de intrusão ou outra forma de comprometimento, deverá investigar a fim de determinar a natureza e o grau dos danos. Os pessoal responsável pela gestão da CA ou a entidade do CPOC deve avaliar a extensão dos potenciais danos a fim de determinar se é necessário reconstruir o componente da PKI, se apenas alguns certificados devem ser revogados e/ou se o componente da PKI foi comprometido. Além disso, a entidade da CA subordinada determina quais os serviços que devem ser mantidos e de que forma, de acordo com o plano de continuidade das atividades da entidade da CA subordinada. Em caso de comprometimento de um componente da PKI, a entidade da CA deve alertar a sua própria CA de raiz e o TLM através do CPOC.
(285)A CPS abrange os incidentes, o comprometimento e a continuidade das atividades da CA de raiz ou do TLM ou outros documentos pertinentes no caso do CPOC, podendo também contar com outros recursos e planos da empresa para a sua implementação.
(286)A CA de raiz e a CA devem alertar, com informações precisas sobre as consequências do incidente, cada representante do Estado-Membro e CA de raiz com a qual tenham um acordo no contexto do STI-C, para permitir que estes ativem o seu próprio plano de gestão de incidentes.
5.7.2.Corrupção de recursos informáticos, aplicações informáticas e/ou dados
(287)No caso de se verificar uma situação de catástrofe que impeça a correta operação de um elemento do modelo de confiança de STI-C, esse elemento deve suspender a operação e investigar se a chave privada foi comprometida (exceto CPOC). O equipamento informático defeituoso deve ser substituído o mais rápido possível e devem ser aplicados os procedimentos descritos nas secções 5.7.3 e 5.7.4.
(288)Para os níveis de risco mais elevados, a corrupção de recursos informáticos, aplicações informáticas/ou dados deve ser comunicada à CA de raiz num prazo de 24 horas. Todos os outros eventos devem ser incluídos no relatório periódico da CA de raiz, da EA e da AA.
5.7.3.Procedimentos em caso de comprometimento de chaves privadas de entidades
(289)Em caso de comprometimento, perda ou destruição da chave privada de uma CA de raiz, ou caso suspeite que esta foi comprometida, a CA de raiz deve:
·suspender o seu funcionamento;
·iniciar o plano de recuperação e migração em caso de catástrofe;
·revogar o respetivo certificado de CA de raiz;
·investigar o «principal problema» que gerou o comprometimento e notificar a CPA, que revogará o certificado da CA de raiz por via do TLM (ver secção 7);
·alertar todos os subscritores com os quais tenha um contrato.
(290)Em caso de comprometimento, perda ou destruição da chave da EA/AA, ou caso suspeite que esta foi comprometida, a EA/AA deve:
·suspender o seu funcionamento;
·revogar o próprio certificado;
·investigar o «principal problema» e notificar a CA de raiz;
·alertar os subscritores com os quais exista um acordo.
(291)Em caso de comprometimento, perda ou destruição da chave da EA/AA, ou caso suspeite que esta foi comprometida, a EA/AA objeto de subscrição da estação de STI-C deve:
·revogar a EC do STI afetado;
·investigar o «principal problema» e notificar a CA de raiz;
·alertar os subscritores com os quais tenha um contrato.
(292)Se qualquer um dos algoritmos ou parâmetros associados utilizados pela CA de raiz e/ou CA ou estações de STI-C se revelar insuficiente para a restante utilização prevista, a CPA (com uma recomendação de especialistas em criptografia) deve informar a entidade da CA de raiz com a qual possui um acordo e alterar os algoritmos utilizados. (Para mais detalhes, ver secção 6 e as CPS da CA de raiz e da CA subordinada).
5.7.4.Capacidade de continuidade das atividades em caso de catástrofe
(293)Os elementos do modelo de confiança de STI-C que operam instalações seguras para operações da CA devem desenvolver, testar, manter e implementar um plano de recuperação em caso de catástrofe concebido para minimizar os efeitos de qualquer catástrofe natural ou causada pelo homem. Tais planos devem ter em vista a restauração dos serviços de sistemas de informação e das principais funções da atividade.
(294)Após um incidente de um determinado nível de risco, a CA comprometida deve ser novamente auditada por um auditor de PKI acreditado (ver secção 8).
(295)Quando a CA comprometida deixa de poder continuar a funcionar (por exemplo, após um incidente grave), deve ser elaborado um plano de migração para a transferência das suas funções para outra CA de raiz. No mínimo, a CA de raiz da UE deve estar disponível para auxiliar no plano de migração. A CA comprometida deve cessar funções.
(296)As CA de raiz devem incluir o plano de recuperação em caso de catástrofe e o plano de migração na CPS.
5.8.Cessação e transferência
5.8.1.TLM
(297)O TLM não deve cessar a sua atividade, mas uma entidade gestora do TLM pode tomar outra entidade a cargo.
(298)Em caso de mudança da entidade gestora:
·deve solicitar a aprovação da CPA relativamente a uma mudança de gestão do TLM da entidade antiga para a nova entidade;
·a CPA deve aprovar a mudança de gestão do TLM;
·todos os registos de auditoria e registos arquivados devem ser transferidos da entidade de gestão antiga para a nova entidade.
5.8.2.CA de raiz
(299)A CA de raiz não deve cessar/iniciar a sua atividade sem estabelecer um plano de migração (estabelecido na CPS pertinente) que garanta o funcionamento contínuo para todos os subscritores.
(300)Em caso de cessação do serviço da CA de raiz, esta deverá:
·notificar a CPA;
·notificar o TLM para que este possa excluir o certificado da CA de raiz da ECTL;
·revogar a CA de raiz correspondente emitindo uma CRL que a contenha;
·alertar as CA de raiz com as quais tem um acordo para a renovação de certificados de EA/AA;
·destruir a chave privada da CA de raiz;
·comunicar as informações de estado da última revogação (CRL assinada pela CA de raiz) à parte utilizadora, indicando claramente que são as informações mais recentes sobre a revogação;
·arquivar todos os registos de auditoria e outros registos antes da cessação da PKI;
·transferir registos arquivados para uma autoridade adequada.
(301)O TLM deve excluir o certificado da CA de raiz correspondente da ECTL.
5.8.3.EA/AA
(302)Em caso de cessação do serviço da EA/AA, a entidade da EA/AA deve fazer uma aviso antes da cessação. A EA/AA não deve cessar/iniciar a sua atividade sem estabelecer um plano de migração (estabelecido na CPS pertinente) que garanta o funcionamento contínuo para todos os subscritores. A EA/AA deve:
·informar a CA de raiz por carta registada;
·destruir a chave privada da CA;
·transferir a sua base de dados para a entidade designada pela CA de raiz;
·suspender a emissão de certificados;
·durante a transferência da sua base de dados e até que esta esteja totalmente operacional numa nova entidade, manter a capacidade de autorizar pedidos da autoridade de privacidade responsável;
·caso uma CA subordinada tenha sido comprometida, a CA de raiz deve revogar a CA subordinada e emitir uma nova CRL que elenque as CA subordinadas revogadas;
·arquivar todos os registos de auditoria e outros registos antes de cessar a PKI;
·transferir o seu arquivo de registos para a entidade designada pela CA de raiz;
(303)Em caso de cessação dos serviços da CA, esta será responsável por manter todos os registos pertinentes referentes às necessidades da CA e dos componentes da PKI.
6.Controlos de segurança técnica
6.1.Geração e instalação de pares de chaves
6.1.1.TLM, CA de raiz, EA, AA
(304)O processo de geração de pares de chaves deve cumprir os seguintes requisitos:
·cada participante deve ser capaz de gerar os seus próprios pares de chaves em conformidade com as secções 6.1.4 e 6.1.5
·o processo de obtenção de chaves de encriptação simétricas e de uma chave MAC para pedidos de certificado (ECIES) deve ser realizado em conformidade com a norma [1] e [5];
·o processo de geração de chaves deve utilizar os algoritmos e comprimentos de chave descritos nas secções 6.1.4.1 e 6.1.4.2;
·o processo de geração de pares de chaves deve estar sujeito aos requisitos de «armazenamento seguro de chaves privadas» (ver secção 6.1.5);
·as CA de raiz e respetivos subscritores (CA subordinadas) devem garantir que a integridade e a autenticidade das suas chaves públicas e de quaisquer parâmetros associados são mantidos durante a transmissão às entidades registadas na CA subordinada.
6.1.2.EA — estação móvel de STI-C
(305)Cada estação móvel de STI-C deve ser capaz de gerar os seus próprios pares de chaves em conformidade com as secções 6.1.4 e 6.1.5
(306)O processo de obtenção de chaves de encriptação simétricas e de uma chave MAC para pedidos de certificado (ECIES) deve ser realizado em conformidade com a norma [1] e [5].
(307)Os processos de geração de chaves devem utilizar os algoritmos e comprimentos de chave descritos nas secções 6.1.4.1 e 6.1.4.2.
(308)Os processos de geração de pares de chaves devem estar sujeitos aos requisitos de «armazenamento seguro de chaves privadas» (ver secção 6.1.5);
6.1.3.EA — estação fixa de STI-C
(309)Cada estação fixa de STI-C deve ser capaz de gerar o seu próprio par de chaves em conformidade com as secções 6.1.4 e 6.1.5.
(310)Os processos de geração de chaves devem utilizar os algoritmos e comprimentos de chave descritos nas secções 6.1.4.1 e 6.1.4.2.
(311)Os processos de geração de pares de chaves devem estar sujeitos aos requisitos de «armazenamento seguro de chaves privadas» (ver secção 6.1.5);
6.1.4.Requisitos de criptografia
(312)Todos os participantes da PKI devem cumprir os requisitos criptográficos estabelecidos nos parágrafos a seguir, no que diz respeito ao algoritmo de assinatura, ao comprimento de chave, ao gerador de números aleatórios e aos certificados de ligação.
6.1.4.1.Comprimento de algoritmos e chaves — algoritmos de assinatura
(313)Todos os participantes da PKI (TLM, CA de raiz, EA, AA e estações de STI-C) devem poder gerar pares de chaves e utilizar a chave privada para assinar operações com algoritmos selecionados, o mais tardar dois anos após a entrada em vigor do presente regulamento, em conformidade com o
Table 4
.
(314)Todos os participantes da PKI que devem verificar a integridade da ECTL, de certificados e/ou de mensagens assinadas de acordo com sua função, conforme definido na secção 1.3.6, devem suportar os algoritmos correspondentes apresentados no
Table 5
para fins de verificação. Em especial, as estações de STI-C devem poder verificar a integridade da ECTL.
|
|
TLM
|
CA de raiz
|
EA
|
AA
|
Estação de STI-C
|
|
ECDSA_nistP256_with_SHA 256
|
-
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP256r1_with_SHA 256
|
-
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP384r1_with_SHA 384
|
X
|
X
|
X
|
-
|
-
|
|
X indica suporte obrigatório
|
Quadro 4: Geração de pares de chaves e utilização da chave privada para operações de assinatura
|
|
TLM
|
CA de raiz
|
EA
|
AA
|
Estação de STI-C
|
|
ECDSA_nistP256_with_SHA 256
|
X
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP256r1_with_SHA 256
|
X
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP384r1_with_SHA 384
|
X
|
X
|
X
|
X
|
X
|
|
X indica suporte obrigatório
|
Quadro 5: Visão geral da verificação
(315)Se a CPA assim determinar com base em fragilidades criptográficas recentemente constatadas, todas as estações de STI-C devem poder mudar para um dos dois algoritmos (ECDSA_nistP256_with_SHA 256 ou ECDSA_brainpoolP256_with_SHA 256) logo que possível. O(s) algoritmo(s) real(is) utilizado(s) será(ão) determinado(s) na CPS da CA que emite o certificado para a chave pública correspondente, em conformidade com a presente CP.
6.1.4.2.Comprimento de algoritmos e chaves — algoritmos de encriptação para inscrição e autorização
(316)Todos os participantes da PKI (EA, AA e estações de STI-C) devem poder utilizar chaves públicas para encriptar os pedidos/respostas de inscrição e autorização com algoritmos selecionados, o mais tardar dois anos após a entrada em vigor do presente regulamento, em conformidade com o
Table 6
. O(s) algoritmo(s) real(is) utilizado(s) será(ão) determinado(s) na CPS da CA que emite o certificado para a chave pública correspondente, em conformidade com a presente CP.
(317)Os algoritmos apresentados no
Table 6
indicam o comprimento da chave e o comprimento do algoritmo Hash e devem ser implementados de acordo com a norma [5].
|
|
TLM
|
CA de raiz
|
EA
|
AA
|
Estação de STI-C
|
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
X indica suporte obrigatório
|
Quadro 6: Utilização de chaves públicas para encriptação de pedidos/respostas de inscrição e autorização
(318)Todos os participantes da PKI (EA, AA e estações de STI-C) devem poder gerar pares de chaves e utilizar a chave privada para desencriptar pedidos/respostas de inscrição e autorização com algoritmos selecionados, o mais tardar dois anos após a entrada em vigor do presente regulamento, em conformidade com o
Table 7
.
|
|
TLM
|
CA de raiz
|
EA
|
AA
|
Estação de STI-C
|
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
X indica suporte obrigatório
|
Quadro 7: Geração de pares de chaves e utilização de chave privada para a desencriptação de pedidos/respostas de inscrição e autorização
6.1.4.3.Criptoagilidade
(319)É necessário alterar os requisitos aplicáveis aos comprimentos de chave e algoritmos de tempos a tempos, para manter um nível de segurança adequado. A CPA deve verificar a necessidade de tais mudanças à luz das vulnerabilidades reais e dos avanços da técnica em matéria de criptografia. Deverá redigir, aprovar e publicar uma atualização da presente política de certificação se decidir que os algoritmos criptográficos devem ser atualizados. Se uma nova edição da presente CP sinalizar uma mudança de algoritmo e/ou comprimento de chave, a CPA deverá adotar uma estratégia de migração que inclua períodos de transição durante os quais os antigos algoritmos e comprimentos de chave devem ser suportados.
(320)Para permitir e facilitar a transferência para novos algoritmos e/ou comprimentos de chave, recomenda-se que todos os participantes da PKI implementem equipamento informático e/ou aplicações informáticas capazes de transferir os comprimentos de chave e os algoritmos.
(321)As alterações de certificados raiz e TLM devem ser suportadas e executadas com a ajuda de certificados de ligação (ver secção 4.6) utilizados para cobrir o período de transição entre os certificados de raiz antigos e os novos («migração do modelo de confiança»).
6.1.5.Armazenamento seguro de chaves privadas
A presente secção descreve os requisitos aplicáveis ao armazenamento seguro e à geração de pares de chaves e números aleatórios para CA e entidades finais. Estes requisitos são definidos para módulos criptográficos e descritos nas subseções a seguir.
6.1.5.1.Nível de CA de raiz, CA subordinada e TLM
(322)Deve ser utilizado um modelo criptográfico para:
·gerar, utilizar, administrar e armazenar chaves privadas;
·gerar e utilizar números aleatórios (a avaliação da função de geração de números aleatórios deve fazer parte da avaliação e certificação de segurança);
·criar salvaguardas de chaves privadas de acordo com a secção 6.1.6;
·eliminação de chaves privadas.
O módulo criptográfico deve ser certificado com um dos seguintes perfis de proteção (PP), com nível de garantia EAL-4 ou superior:
·PP para HSM
·CEN EN 419 221-2: «Protection profiles for TSP cryptographic modules – Part 2: Cryptographic module for CSP signing operations with backup» (Perfis de proteção para módulos criptográficos de TSP – Parte 2: Módulo criptográfico para operações de assinatura do PSC com salvaguarda;
·CEN EN 419 221-4: «Protection profiles for TSP cryptographic modules – Part 4: Cryptographic module for CSP signing operations without backup» (Perfis de proteção para módulos criptográficos de TSP – Parte 2: Módulo criptográfico para operações de assinatura do PSC sem salvaguarda;
·CEN EN 419 221-5: «Protection profiles for TSP cryptographic modules – Part 5: Cryptographic module for trust services» (Perfis de proteção para módulos criptográficos de TSP – Parte 5: Módulo criptográfico para serviços de confiança);
·PP para cartões inteligentes
·CEN EN 419 211-2: «Protection profiles for secure signature creation device – Part 2: Device with key generation» (Perfis de proteção para dispositivo de criação de assinaturas seguras – Parte 2: Dispositivo com geração de chaves);
·CEN EN 419 211-3: «Protection profiles for secure signature creation device – Part 3: Device with key generation» (Perfis de proteção para dispositivo de criação de assinaturas seguras – Parte 3: Dispositivo com importação de chave).
O acesso manual ao módulo criptográfico requer a autenticação de dois fatores do administrador. Adicionalmente, impõe-se o envolvimento de duas pessoas autorizadas.
A implementação de um módulo criptográfico deve assegurar que as chaves não são acessíveis fora do módulo criptográfico. O módulo criptográfico deve incluir um mecanismo de controlo de acesso para impedir a utilização não autorizada de chaves privadas.
6.1.5.2.Entidade final
(323)Deve ser utilizado um modelo criptográfico para EA para:
·gerar, utilizar, administrar e armazenar chaves privadas;
·gerar e utilizar números aleatórios (a avaliação da função de geração de números aleatórios deve fazer parte da avaliação e certificação de segurança);
·proteger a eliminação de uma chave privada.
(324)O módulo criptográfico deve ser protegido contra a remoção, a substituição e a alteração não autorizadas. Todos os PP e documentos relacionados aplicáveis à certificação de segurança do módulo criptográfico devem ser avaliados, validados e certificados em conformidade com a norma ISO 15408, aplicando o Acordo de Reconhecimento Mútuo de Certificados de Avaliação da Segurança da Tecnologia da Informação do Grupo de Altos Funcionários para a Segurança dos Sistemas de Informação (SOG-IS), ou um sistema de certificação da cibersegurança europeu equivalente submetido ao devido enquadramento europeu de cibersegurança. Dada a importância de manter o nível de segurança mais elevado possível, os certificados de segurança para o módulo criptográfico devem ser emitidos no contexto do sistema de certificação de critérios comuns (ISO 15408) por um organismo de avaliação da conformidade reconhecido pelo comité de gestão no âmbito do Acordo SOG-IS, ou por um organismo de avaliação da conformidade acreditado por uma autoridade nacional de certificação da cibersegurança de um Estado-Membro. Tal organismo deve providenciar condições de avaliação de segurança pelo menos equivalentes às previstas no Acordo de Reconhecimento Mútuo SOG-IS.
Nota: a ligação entre o módulo criptográfico e a estação de STI-C deve ser protegida.
6.1.6.Salvaguarda de chaves privadas
(325)A geração, o armazenamento e a utilização de salvaguardas de chaves privadas devem pelo menos cumprir o requisito do nível de segurança exigido para as chaves originais.
(326)As salvaguardas de chaves privadas devem ser efetuadas pelas CA de raiz, EA e AA.
(327)As salvaguardas de chaves privadas não devem ser efetuadas para EC e CA.
6.1.7.Destruição de chaves privadas
(328)As CA de raiz, EA, AA e estações de STI-C móveis e fixas devem destruir a sua chave privada e todas as salvaguardas correspondentes, se um novo par de chaves e o certificado correspondente tiverem sido gerados e instalados com êxito e já tiver terminado o período de sobreposição (se aplicável — apenas a CA). A chave privada deve ser destruída utilizando o mecanismo oferecido pelo módulo criptográfico utilizado para o armazenamento das chaves ou conforme descrito no PP correspondente, conforme referido na secção 6.1.5.2.
6.2.Dados de ativação
(329)Os dados de ativação referem-se a fatores de autenticação necessários para operar módulos criptográficos a fim de impedir o acesso não autorizado. A utilização dos dados de ativação do dispositivo criptográfico de uma CA deve implicar a ação de duas pessoas autorizadas.
6.3.Controlos de segurança informática
(330)Os controlos de segurança informática das CA devem ser concebidos de acordo com o nível de segurança elevado, cumprindo os requisitos da norma ISO/IEC 27002.
6.4.Controlos técnicos do ciclo de vida
(331)Os controlos técnicos da CA devem cobrir todo o ciclo de vida da CA, nomeadamente, os requisitos da secção 6.1.4.3 («Criptoagilidade»).
6.5.Controlos de segurança de rede
(332)As redes das CA (CA de raiz, EA e AA) devem ser fortemente protegidas contra ataques de acordo com os requisitos e as orientações de implementação das normas ISO/IEC 27001 e ISO/IEC 27002.
(333)A disponibilidade das redes da CA deve ser projetada à luz do tráfego previsto.
7.Perfis de certificados, CRL e CTL
7.1.Perfil do certificado
(334)Os perfis de certificado definidos na norma [5] devem ser utilizados para o TLM, os certificados de raiz, certificados de EA, certificados de AA, CA e EC. As EA governamentais nacionais podem utilizar outros perfis de certificados para EC.
(335)Os certificados da CA de raiz, EA e AA devem indicar as permissões para as quais essas CA (CA de raiz, EA e AA) podem emitir certificados.
(336)Com base na norma [5]:
·cada CA de raiz deve utilizar a sua própria chave privada de assinatura para emitir CRL;
·o TLM deve utilizar a sua própria chave privada de assinatura para emitir a ECTL.
7.2.Validade do certificado
(337)Todos os perfis de certificados de STI-C devem incluir uma data de emissão e de termo, que representam o período de validade do certificado. Em cada nível da PKI, os certificados devem ser gerados em tempo útil antes do termo.
(338)O período de validade dos certificados CA e EC deve incluir um período de sobreposição. Os certificados TLM e CA de raiz devem ser emitidos e inseridos na ECTL durante um período máximo de três meses e, pelo menos, um mês antes do início da sua validade, com base na hora de início do certificado. Essa fase de pré-carregamento é necessária para distribuir com segurança os certificados por todas as partes utilizadoras correspondentes, em conformidade com a secção 2.2. Essa circunstância permite garantir que todas as partes utilizadoras podem verificar as mensagens emitidas com um novo certificado logo desde o início do período de sobreposição.
(339)No início do período de sobreposição, os certificados sucessivos de CA, EC e CA devem ser emitidos (se aplicável), distribuídos às partes utilizadoras correspondentes e instalados pelas mesmas. Durante o período de sobreposição, o certificado atual apenas deve ser utilizado para efeitos de verificação.
(340)Uma vez que os períodos de validade apresentados no
Table 8
não devem exceder o período de validade do certificado superior, aplicam-se as seguintes restrições:
·maximumvalidity(CA de raiz) = privatekeyusage(CA de raiz) + maximumvalidity(EA,AA);
·maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC);
·maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(CA).
(341)A validade dos certificados de ligação (de raiz e TLM) tem início no momento de utilização da chave privada correspondente e termina no período máximo de validade da CA de raiz ou do TLM.
(342)O
Table 8
mostra o período máximo de validade para os certificados de CA de STI-C (para os períodos de validade do CA, ver secção 7.2.1).
|
Entidade
|
Período máx. de utilização da chave privada
|
Período máximo de validade
|
|
CA de raiz
|
3 anos
|
8 anos
|
|
EA
|
2 anos
|
5 anos
|
|
AA
|
4 anos
|
5 anos
|
|
EC
|
3 anos
|
3 anos
|
|
TLM
|
3 anos
|
4 anos
|
Quadro 8: Períodos de validade dos certificados no modelo de confiança de STI-C
7.2.1.Certificados de pseudónimos
(343)Neste contexto, os pseudónimos são implementados por CA. Consequentemente, a presente secção refere-se a CA, e não a pseudónimos.
(344)Os requisitos estabelecidos na presente secção aplicam-se apenas a CA de estações móveis de STI-C que enviam mensagens CAM e DENM , em que o risco de privacidade de localização é aplicável. Não se aplicam requisitos específicos aos certificados de CA no caso de CA para estações de STI-C fixas e móveis utilizadas para funções especiais em que a privacidade de localização não é aplicável (por exemplo, veículos de emergência e veículos das forças de segurança).
(345)São aplicáveis as seguintes definições:
·«período de validade de CA»: o período durante o qual um CA é válido, ou seja, o período entre a data de início do CA e a sua data de termo;
·«período de pré-carregamento de CA»: o pré-carregamento é a possibilidade de as estações de STI-C obterem CA antes do início do período de validade.
O período de pré-carregamento é o período de tempo máximo permitido desde o pedido de CA até ao termo da validade de qualquer CA solicitado;
·«período de utilização de CA»: o período durante o qual um CA é efetivamente utilizado para assinar mensagens CAM/DENM;
·«número máximo de CA paralelos»: o número de CA a partir do qual uma estação de STI-C pode escolher a qualquer momento, ao assinar uma mensagem CAM/DENM, ou seja, o número de CA diferentes emitidos para uma estação de STI-C e válidos em simultâneo.
(346)São aplicáveis os seguintes requisitos:
·o período de pré-carregamento para os CA não deve exceder três meses;
·o período de validade dos CA não deve exceder uma semana;
·o número máximo de CA paralelos não deve exceder 100 por estação de STI-C;
·O período de utilização de um CA depende da estratégia de alteração do CA e da quantidade de tempo que um veículo está em funcionamento, mas é limitado pelo número máximo de CA paralelos e pelo período de validade. Mais especificamente, o período de utilização médio para uma estação de STI-C é de pelo menos o tempo de funcionamento do veículo durante um período de validade dividido pelo número máximo de CA paralelos.
7.2.2.Bilhetes de autorização para estações de STI-C fixas
(347)Aplicam-se as definições da secção 7.2.1 e os seguintes requisitos:
·o período de pré-carregamento para os CA não deve exceder três meses;
·o número máximo de CA paralelos não deve exceder dois por estação de STI-C.
7.3.Revogação de certificados
7.3.1.Revogação de certificados de CA, EA e AA
Os certificados da CA de raiz, da EA e da AA devem ser revogáveis. Os certificados revogados de CA de raiz, EA e AA devem ser publicados numa CRL assim que possível e sem demora injustificada. Essa CRL deve ser assinada pela sua CA de raiz correspondente e utilizar o perfil descrito na secção 7.4. Para revogar certificados da CA de raiz, a CA de raiz correspondente deve emitir uma CRL que a contenha. Além disso, em casos de comprometimento da segurança, aplica-se a secção 5.7.3. Adicionalmente, o TLM deve remover as CA de raiz revogadas da lista aprovada e emitir uma nova lista aprovada. Os certificados expirados devem ser removidos da CRL e da lista aprovada.
(348)Os certificados são revogados quando:
·as CA de raiz têm motivos para crer ou suspeitar fortemente que a chave privada correspondente foi comprometida;
·as CA de raiz foram notificadas de que o contrato com o subscritor foi rescindido;
·as informações (como o nome e associações entre a CA e o sujeito) no certificado estão incorretas ou foram alteradas;
·ocorre um incidente de segurança que afeta o titular do certificado;
·uma auditoria (ver secção 8) leva a um resultado negativo.
(349)O subscritor deve notificar de imediato a CA de um comprometimento conhecido ou presumível da sua chave privada. Deve-se garantir que apenas os pedidos autenticados resultam em certificados revogados.
7.3.2.Revogação de credenciais de inscrição
(350)A revogação das EC pode ser iniciada pelo subscritor da estação de STI-C (fluxo 34) e deve ser implementada através de uma lista negra interna numa base de dados de revogação com um selo temporal, que é gerado e mantido por cada EA. A lista negra nunca é publicada e deve permanecer confidencial, sendo utilizada apenas pela EA correspondente para verificar a validade das EC correspondentes no contexto de pedidos de CA e novas EC.
7.3.3.Revogação de bilhetes de autorização
(351)Uma vez que os CA não são revogados pelas CA correspondentes, devem ter um tempo de vida curto e não podem ser emitidas muito antes de passarem a ser válidos. Os valores dos parâmetros do ciclo de vida do certificado permitidos encontram-se definidos na secção 7.2.
7.4.Lista de revogação de certificados
(352)O formato e o conteúdo da CRL emitida pelas CA de raiz são os estabelecidos na norma [1].
7.5.Lista aprovada de certificados europeus
(353)O formato e o conteúdo da ECTL emitida pelo TLM são os estabelecidos na norma [1].
8.Auditoria de conformidade e outras avaliações
8.1.Aspetos abrangidos pela auditoria e base da auditoria
(354)O objetivo de uma auditoria de conformidade é verificar se o TLM, as CA de raiz, as EA e as AA operam de acordo com a presente CP. O TLM, as CA de raiz, as EA e as AA devem selecionar um auditor da PKI de acreditado e independente para auditar a sua CPS. A auditoria deve ser conjugada com uma avaliação das normas ISO/IEC 27001 e ISO/IEC 27002.
(355)A CA de raiz deve solicitar uma auditoria de conformidade a si mesma (fluxo 13) e uma EA/AA deve fazê-lo para respetiva CA subordinada.
(356)A CPA deve solicitar uma auditoria de conformidade para o TLM (fluxo 38).
(357)Quando solicitado, um auditor da PKI acreditado deve realizar uma auditoria de conformidade num dos seguintes níveis:
(1)conformidade da CPS do TLM, da CA de raiz, da EA ou da AA com a presente CP;
(2)conformidade das práticas previstas do TLM, da CA de raiz, da EA ou da AA com a respetiva CPS antes das operações;
(3)conformidade das práticas e atividades operacionais do TLM, da CA de raiz, da EA ou da AA com a respetiva CPS durante as operações.
(358)A auditoria deve abranger todos os requisitos da presente CP a serem cumpridos pelo TLM, as CA de raiz, as EA e as AA a serem auditados. Deve também abranger a operação da CA na PKI do STI-C, incluindo todos os processos referidos na respetiva CPS, as instalações e as pessoas responsáveis.
(359)O auditor da PKI acreditado deve apresentar um relatório detalhado da auditoria à CA de raiz (fluxo 36), à EA, à AA ou à CPA (fluxos 16 e 40), conforme aplicável.
8.2.Frequência das auditorias
(360)Uma CA de raiz, um TLM, uma EA ou uma AA deve pedir para ser objeto de uma auditoria de conformidade a um auditor independente e acreditado da PKI nos seguintes casos:
·na sua primeira configuração (conformidade com os níveis 1 e 2);
·a cada alteração da CP. A CPA deve definir o teor da alteração da CP e a calendarização de implantação e determinar as necessidades de auditorias (incluindo o nível de conformidade necessário) em conformidade;
·a cada mudança da sua CPS (níveis 1, 2 e 3 de conformidade). Uma vez que as entidades de gestão das CA de raiz, o TLM e as EA/AA decidem quais as alterações de implementação que seguem a atualização da sua CPS, devem solicitar uma auditoria de conformidade antes de implementar essas alterações. Nos casos de pequenas alterações da CPS (por exemplo, de caráter editorial), a entidade administradora pode enviar à CPA um pedido devidamente justificado, para que a sua aprovação possa prescindir das auditorias de conformidade de nível 1, 2 ou 3;
·regularmente, e pelo menos de três em três anos durante a sua operação (nível 3 de conformidade).
8.3.Identidade/qualificações do auditor
(361)A CA a ser auditada deve selecionar uma empresa/organização independente e acreditada («organismo auditor») ou auditores da PKI acreditados para a auditar de acordo com a presente CP. O organismo auditor deve ser acreditado e certificado por um membro da European Accreditation.
8.4.Relação do auditor com a entidade auditada
(362)O auditor da PKI acreditado deve ser independente da entidade auditada.
8.5.Medidas tomadas face a deficiência
(363)Caso um relatório de auditoria indique que o TLM não está em conformidade, a CPA deve solicitar ao TLM que tome medidas preventivas/corretivas imediatas.
(364)Quando uma CA de raiz com um relatório de auditoria não conforme efetua um novo pedido, a CPA deve rejeitar o pedido e enviar a rejeição correspondente à CA de raiz (fluxo 4). Nesses casos, a CA de raiz será suspensa. Deve tomar medidas corretivas, voltar a solicitar a auditoria e apresentar um novo pedido de aprovação à CPA. A CA raiz não deve poder emitir certificados durante a suspensão.
(365)No caso de a auditoria à CA de raiz ser regular ou em caso de alteração à CPS da CA de raiz, e dependendo da natureza da não conformidade descrita no relatório de auditoria, a CPA pode decidir revogar a CA de raiz e comunicar essa decisão ao TLM (fluxo 2), originando a exclusão do certificado da CA de raiz da ECTL e a inserção da CA de raiz na CRL. A CPA deve enviar a rejeição correspondente à CA de raiz (fluxo 4). A CA de raiz deve tomar medidas corretivas, voltar a solicitar uma auditoria completa (níveis 1 a 3) e efetuar um novo pedido de aprovação à CPA. Em alternativa, a CPA pode decidir não revogar a CA de raiz, mas conceder-lhe um período de carência em que a CA de raiz deve tomar medidas corretivas, voltar a solicitar uma auditoria e reenviar o relatório da auditoria à CPA. Nesse caso, a operação da CA de raiz deve ser suspensa, não lhe sendo permitido emitir certificados e CRL.
(366)No caso de uma auditoria da EA/AA, a CA de raiz deve decidir se aceita ou não o relatório. Dependendo do resultado da auditoria, a CA de raiz deve decidir se revoga o certificado da EA/AA de acordo com as regras da CPS da CA de raiz. A CA de raiz deve sempre garantir a conformidade da EA/AA com a presente CP.
8.6.Comunicação dos resultados
(367)A CA de raiz e o TLM devem enviar o relatório de auditoria à CPA (fluxo 16). A CA de raiz e o TLM devem armazenar todos os relatórios de auditoria que solicitaram. A CPA deve enviar a aprovação ou rejeição correspondente (fluxo 4) à CA de raiz e ao TLM.
(368)A CA de raiz deve enviar um certificado de conformidade à EA/AA correspondente.
9.Outras disposições
9.1.Taxas
(369)Constitui um princípio do modelo de confiança do STI-C da UE implementado o facto de as CA de raiz financiarem totalmente os custos recorrentes e regulares de funcionamento da CPA e os elementos centrais (TLM e CPOC) relacionados com as atividades definidas na presente CP.
(370)As CA de raiz (incluindo a CA de raiz da UE) podem cobrar taxas às suas subautoridades de certificação.
(371)Durante todo o período de funcionamento, cada participante do modelo de confiança de STI-C deve ter acesso a pelo menos uma CA de raiz, EA e AA numa base não discriminatória.
(372)Cada CA de raiz tem direito a aplicar as taxas que paga pela CPA e os elementos centrais (TLM e CPOC) aos participantes registados do modelo de confiança de STI-C, incluindo as estações de STI-C inscritas e autorizadas.
9.2.Responsabilidade financeira
(373)O estabelecimento inicial de uma CA de raiz deve abranger um período de pelo menos três anos de funcionamento, para que se torne membro do modelo de confiança do STI-C da UE. A CPS de um operador da CA de raiz também deve conter disposições detalhadas sobre a revogação ou o encerramento de da CA de raiz.
(374)Cada CA de raiz deve demonstrar a viabilidade financeira da entidade jurídica que a implementa por pelo menos três anos. Esse plano de viabilidade financeira faz parte do conjunto inicial de documentos para inscrição e deve ser atualizado a cada três anos e comunicado à CPA.
(375)Cada CA de raiz deve relatar a estrutura das taxas aplicadas às EA/AA e às estações de STI-C inscritas e autorizadas anualmente ao gestor de operações e à CPA, para demonstrar a sua sustentabilidade financeira.
(376)Todas as entidades financeiras e jurídicas responsáveis da CA de raiz, da EA, da AA e dos elementos centrais (CPOC e TLM) do modelo de confiança de STI-C devem cobrir as suas tarefas operacionais com níveis adequados de seguro para compensar erros operacionais e a recuperação financeira das suas tarefas no caso de um dos elementos técnicos falhar.
9.3.Confidencialidade das informações comerciais
(377)Os seguintes elementos devem permanecer confidenciais e privados:
·registos de pedidos de CA de raiz, EA e AA, aprovados ou rejeitados;
·relatórios de auditoria de CA de raiz, EA, AA e TLM;
·planos de recuperação em caso de catástrofe de CA de raiz, EA, AA, CPOC e TLM;
·chaves privadas dos elementos do modelo de confiança de STI-C (estações de STI-C, TLM, EA, AA, CA de raiz);
·qualquer outra informação identificada como confidencial pela CPA, CA de raiz, EA, AA, TLM e CPOC.
9.4.Plano de privacidade
(378)As CPS das CA de raiz e as EA/AA devem estabelecer o plano e os requisitos para o tratamento de informações pessoais e da privacidade com base no RGPD e noutros quadros legislativos aplicáveis (por exemplo, nacionais).
10.Referências
No presente anexo, utilizam-se as seguintes referências:
(1)ETSI TS 102 941 V1.2.1, «Intelligent transport systems (ITS) – security, trust and privacy management» [Sistemas de transporte inteligentes (STI) – Gestão da segurança, da confiança e da privacidade].
(2)ETSI TS 102 940 V1.3.1, «Intelligent transport systems (ITS) – security, ITS communications security architecture and security management» [Sistemas de transporte inteligentes (STI) – Segurança, arquitetura de segurança de comunicações de STI e gestão da segurança].
(3)«Certificate policy and certification practices framework» (Política de certificação e quadro de práticas de certificação) (RFC 3647, 1999).
(4)ETSI TS 102 042 V2.4.1 «Policy requirements for certification authorities issuing public key certificates» (Requisitos de política aplicáveis a autoridades de certificação que emitem certificados de chave pública).
(5)ETSI TS 103 097 V1.3.1, «Intelligent transport systems (ITS) – security, security header and certificate formats» [Sistemas de transporte inteligentes (STI) – Segurança, rubrica de segurança e formatos de certificado].
(6)Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide. Van Haren Publishing.
(7)ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – «Information technology, security techniques, information security risk management» (Tecnologia da informação, técnicas de segurança, gestão de riscos de segurança da informação). ISO.