|
36)
|
O apêndice 11 é alterado do seguinte modo:
|
a)
|
Na secção 8.2.3, o ponto CSM_49 passa a ter a seguinte redação:
|
«CSM_49
|
Unidades-veículo, cartões tacográficos e módulos GNSS externos aceitam os algoritmos SHA-256, SHA-384 e SHA-512 especificados em [SHS].»;
|
|
|
b)
|
Na secção 9.1.2, o primeiro parágrafo do ponto CSM_58 passa a ter a seguinte redação:
|
«CSM_58
|
Sempre que cria um novo par de chaves de raiz europeia, a ERCA cria um certificado de ligação para a nova chave pública europeia e assina-o com a chave privada europeia anterior. O período de validade do certificado de ligação é de 17 anos e 3 meses. (esquema 1, na secção 9.1.7).»;
|
|
|
c)
|
Na secção 9.1.4, o ponto CSM_72 passa a ter a seguinte redação:
|
«CSM_72
|
Para cada unidade-veículo, são criados dois pares de chaves ECC originais, denominados VU_MA e VU_Sign. Esta função é assegurada pelos fabricantes de VU. Sempre que for criado um par de chaves de VU, a parte que cria a chave envia a chave pública à MSCA do país de residência, a fim de obter o correspondente certificado de VU, assinado pela MSCA. Somente a unidade-veículo utiliza a chave privada.»;
|
|
|
d)
|
A secção 9.1.5 é alterado do seguinte modo:
|
i)
|
O ponto CSM_83 passa a ter a seguinte redação:
|
«CSM_83
|
Para cada cartão tacográfico é criado um par de chaves ECC original, denominado Card_MA. Para cada cartão de condutor e de oficina é criado adicionalmente um segundo par de chaves ECC original, denominado Card_Sign. Esta função pode ser assegurada pelos fabricantes ou personalizadores dos cartões. Sempre que for criado um par de chaves de cartão, a parte que cria a chave envia a chave pública à MSCA do país de residência, a fim de obter o correspondente certificado de cartão, assinado pela MSCA. A chave privada é utilizada somente pelo cartão tacográfico.»;
|
|
|
ii)
|
O ponto CSM_88 passa a ter a seguinte redação:
|
«CSM_88
|
O período de validade de um certificado Card_MA é o seguinte:
|
—
|
Para cartões de condutor: 5 anos,
|
|
—
|
Para cartões de empresa: 5 anos,
|
|
—
|
Para cartões de controlo: 2 anos,
|
|
—
|
Para cartões de oficina: 1 ano»;
|
|
|
|
iii)
|
Ao ponto CSM_91 são aditados os seguintes parágrafos:
|
«—
|
Além disso, para os cartões de controlo, os cartões de empresa e os cartões de oficina apenas, e apenas se tais cartões tiverem sido emitidos durante os primeiros três meses do período de validade de um novo certificado EUR: o certificado EUR de duas gerações, se existir.
Nota respeitante ao último travessão: Por exemplo, nos primeiros três meses do certificado ERCA(3) (ver Figura 1), os cartões referidos devem incluir o certificado ERCA(1). Tal é necessário para assegurar que esses cartões possam ser utilizados para descarregar dados das VU ERCA(1), cuja duração normal de 15 anos e período de 3 meses de descarregamento de dados expiram durante estes meses; Ver último travessão do requisito 13) do anexo IC.»;
|
|
|
|
e)
|
A secção 9.1.6 é alterada do seguinte modo:
|
i)
|
O ponto CSM_93 passa a ter a seguinte redação:
|
«CSM_93
|
Para cada módulo GNSS externo é criado um par de chaves ECC original, denominado EGF_MA. Esta função é assegurada pelos fabricantes de módulos GNSS externos. Sempre que for criado um par de chaves EGF_MA, a parte que cria a chave envia a chave pública à MSCA do país de residência, a fim de obter o correspondente certificado EGF_MA, assinado pela MSCA. A chave privada é utilizada somente pelo módulo GNSS externo.»;
|
|
|
ii)
|
O ponto CSM_95 passa a ter a seguinte redação:
|
«CSM_95
|
O módulo GNSS externo utiliza o seu par de chaves EGF_MA, que consiste na chave privada EGF_MA.SK e na chave pública EGF_MA.PK, exclusivamente para efetuar a autenticação mútua e a concordância de chave de sessão em relação às unidades-veículo, em conformidade com a secção 11.4 do presente apêndice.»;
|
|
|
|
f)
|
A secção 9.1.7 é alterada do seguinte modo:
|
i)
|
O esquema 1 é substituído pelo esquema seguinte:
Esquema 1
Emissão e utilização de certificados de raiz ERCA, certificados de ligação ERCA, certificados MSCA e certificados de equipamento ou aparelho de gerações diferentes
Texto de imagem
Legend
Private key usage period/Remaining certificate validity
Second generation ERCA certificate and certificates based on it
Third generation ERCA certificate and certificates based on it
First generation ERCA certificate and certificates based on it
anos
anos
anos
|
|
ii)
|
O ponto 6 das Notas ao esquema 1 passa a ter a seguinte redação:
|
«6.
|
Para poupar espaço, a diferença no período de validade entre os certificados Card_MA e Card_Sign é apresentada somente para a primeira geração.»;
|
|
|
|
g)
|
A secção 9.2.1.1 é alterada do seguinte modo:
|
i)
|
No ponto CSM_106, o primeiro travessão passa a ter a seguinte redação:
|
«—
|
Para chaves de segurança do sensor de movimentos de 128 bits: CV = ‘B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83’»;
|
|
|
ii)
|
No ponto CSM_107, o primeiro parágrafo passa a ter a seguinte redação:
«Cada fabricante de sensores de movimentos cria uma chave de emparelhamento KP aleatória e original para cada sensor de movimentos e envia cada chave de emparelhamento à respetiva autoridade de certificação do Estado-Membro. A MSCA encripta cada chave de emparelhamento individualmente com a chave de segurança do sensor de movimentos KM e devolve a chave encriptada ao fabricante do sensor de movimentos. Relativamente a cada chave encriptada, a MSCA comunica ao fabricante do sensor de movimentos o número de versão da chave KM associada.»;
|
|
iii)
|
O ponto CSM_108 passa a ter a seguinte redação:
|
«CSM_108
|
Cada fabricante de sensores de movimentos cria um número de série único para cada sensor de movimentos e envia todos os números de série à respetiva autoridade de certificação do Estado-Membro. A MSCA encripta cada número de série individualmente com a chave de identificação KID e devolve o número de série encriptado ao fabricante do sensor de movimentos. Relativamente a cada número de série encriptado, a MSCA comunica ao fabricante do sensor de movimentos o número de versão da chave KID associada.»;
|
|
|
|
h)
|
A secção 9.2.2.1 é alterada do seguinte modo:
|
i)
|
O ponto CSM_123 passa a ter a seguinte redação:
|
«CSM_123
|
Relativamente a todas as unidades-veículo: O fabricante de unidades-veículo cria um número de série de VU único e envia-o à autoridade de certificação do respetivo Estado-Membro, num pedido de obtenção de um conjunto de duas chaves DSRC específicas da VU. O número de série da VU tem o tipo de dados
.
Nota:
|
—
|
O referido número de série da VU deve ser idêntico ao elemento vuSerialNumber da VuIdentification, ver apêndice 1 e à referência do titular do certificado nos certificados da VU.
|
|
—
|
O número de série da VU pode não ser conhecido no momento em que um fabricante de unidades-veículo solicite as chaves DSRC específicas da VU. Nesse caso, o fabricante de VU envia, em vez disso, o ID de pedido de certificado único que utilizou quando solicitou os certificados da VU; Ver CSM_153. Esse ID de pedido de certificado deve, por conseguinte, ser igual à referência do titular do certificado nos certificados da VU.»;
|
|
|
|
ii)
|
No ponto CSM_124, o requisito de informação constante do passo 2 passa a ter a seguinte redação:
«info = número de série da VU, conforme especificado no CSM_123»;
|
|
iii)
|
O ponto CSM_128 passa a ter a seguinte redação:
|
«CSM_128
|
A MSCA mantém registos de todas as chaves DSRC específicas da VU que criou, os respetivos números de versão e o número de série da VU ou ID de pedido de certificado utilizado para os obter.»;
|
|
|
|
i)
|
Na secção 9.3.1, o primeiro parágrafo do ponto CSM_135 passa a ter a seguinte redação:
«De acordo com a norma ISO 8825-1, utilizar-se-ão as regras distintas de codificação para codificar os objetos de dados dentro dos certificados. O quadro 4 mostra a codificação de todo o certificado, incluindo marcadores e comprimento (bytes).»;
|
|
j)
|
Na secção 9.3.2.3, o ponto CSM_141 passa a ter a seguinte redação:
|
«CSM_141
|
Utiliza-se a autorização do titular do certificado para identificar o tipo de certificado. Consiste nos seis bytes mais significativos do ID da aplicação tacográfica, concatenados com o tipo de aparelho, que indica o tipo de aparelho ao qual se destina o certificado. No caso de um certificado de VU, um certificado de cartão de condutor ou um certificado de cartão de oficina, o tipo de aparelho também é utilizado para destrinçar um certificado de autenticação mútua de um certificado para criação de assinaturas digitais (ver secção 9.1 e apêndice 1, tipo de dados EquipmentType).»;
|
|
|
k)
|
Na secção 9.3.2.5, é aditado o seguinte parágrafo ao ponto CSM_146:
«Nota: Para um certificado do cartão, o valor do CHR deve ser igual ao valor do cardExtendedSerialNumber no EF_ICC; ver apêndice 2. Para um certificado EGF, o valor do CHR deve ser igual ao valor do sensorGNSSSerialNumber no EF_ICC; ver apêndice 14. Para um certificado de VU, o valor do CHR deve ser igual ao elemento vuSerialNumber da VuIdentification, ver apêndice 1, exceto se o fabricante não conhecer o número de série específico do fabricante no momento em que o certificado é pedido.»;
|
|
l)
|
Na secção 9.3.2.6, o ponto CSM_148 passa a ter a seguinte redação:
|
«CSM_148
|
A data de vigência do certificado indica a data e a hora de início do período de validade do certificado.»;
|
|
|
m)
|
A secção 9.3.3 é alterada do seguinte modo:
|
i)
|
No ponto CSM_151, o primeiro parágrafo passa a ter a seguinte redação:
«Ao pedir um certificado, a MSCA deve enviar à ERCA os seguintes dados:»;
|
|
ii)
|
O ponto CSM_153 passa a ter a seguinte redação:
|
«CSM_153
|
Num pedido de certificado a uma MSCA, para permitir que esta crie a referência do titular do novo certificado do equipamento, o fabricante do equipamento ou aparelho deve enviar os dados a seguir indicados:
|
—
|
Se for conhecido (ver CSM_154), número de série do equipamento, único para o fabricante, para o tipo do equipamento e para o mês de fabrico; caso contrário, um identificador de pedido de certificado único.
|
|
—
|
Mês e ano de fabrico do equipamento ou de pedido do certificado.
|
|
O fabricante assegura que estes dados estão corretos e que o certificado devolvido pela MSCA é inserido no equipamento a que se destina.»;
|
|
|
n)
|
A secção 10.2.1 é alterada do seguinte modo:
|
i)
|
No ponto CSM_157, o texto anterior às notas do esquema 4 passa a ter a seguinte redação:
«As unidades-veículo utilizam o protocolo descrito no esquema 4 para verificarem a cadeia de certificados dos cartões tacográficos. Para cada certificado lido a partir do cartão, a VU verifica se o campo relativo à autorização do titular do certificado (CHA) está correto:
|
—
|
O campo CHA do certificado do cartão deve indicar um certificado de cartão de autenticação mútua (ver apêndice 1, tipo de dados EquipmentType).
|
|
—
|
O CHA do certificado Card.CA deve indicar uma MSCA.
|
|
—
|
O CHA do certificado Card.Link deve indicar uma ERCA.»;
|
|
|
ii)
|
No ponto CSM_159, é aditada a seguinte frase:
«Enquanto a memorização de todos os outros tipos de certificado é facultativa, a VU deve obrigatoriamente memorizar um novo certificado de ligação apresentado por um cartão.»;
|
|
|
o)
|
A secção 10.2.2 é alterada do seguinte modo:
|
i)
|
No ponto CSM_161, o texto anterior ao esquema 5 passa a ter a seguinte redação:
«Os cartões tacográficos utilizam o protocolo descrito no esquema 5 para a verificação da cadeia de certificados da VU. Para cada certificado apresentado pela VU, o cartão verifica se o campo relativo à autorização do titular do certificado (CHA) está correto:
|
—
|
O CHA do certificado VU.Link deve indicar uma ERCA.
|
|
—
|
O CHA do certificado VU.CA deve indicar uma MSCA.
|
|
—
|
O campo CHA do certificado da VU deve indicar um certificado da VU de autenticação mútua (ver apêndice 1, tipo de dados EquipmentType).»;
|
|
|
ii)
|
O ponto CSM_165 passa a ter a seguinte redação:
|
«CSM_165
|
Se o comando MSE: Set AT tiver êxito, o cartão define o VU.PK indicado, para utilização posterior durante a autenticação do veículo, e memoriza temporariamente Comp(VU.PKeph). Caso dois ou mais comandos MSE: Set AT com êxito sejam enviados antes de ser efetuada a concordância de chave de sessão, o cartão memoriza apenas o último Comp(VU.PKeph) recebido. O cartão reinicializa Comp(VU.PKeph) após um comando GENERAL AUTHENTICATE bem-sucedido.»;
|
|
|
|
p)
|
A secção 10.3 é alterada do seguinte modo:
|
i)
|
O primeiro parágrafo do ponto CSM_170 passa a ter a seguinte redação:
«Ao lado do desafio do cartão, a VU inclui na assinatura a referência do titular do certificado retirada do certificado do cartão.»;
|
|
ii)
|
No ponto CSM_171, o esquema 6 passa a ter a seguinte redação:
Esquema 6
Protocolo de autenticação da VU
|
|
iii)
|
O ponto CSM_174 passa a ter a seguinte redação:
|
«CSM_174
|
Ao receber a assinatura da VU no comando EXTERNAL AUTHENTICATE, o cartão
|
—
|
Calcula o testemunho de autenticação mediante a concatenação Card.CHR, o desafio do cartão rcard e o identificador da chave pública efémera da VU Comp(VU.PKeph),
|
|
—
|
Verifica a assinatura da VU utilizando o algoritmo ECDSA, que utiliza o algoritmo de hash ligado ao tamanho da chave do par de chaves VU_MA da VU, em conformidade com o requisito CSM_50, em combinação com o VU.PK e o testemunho de autenticação calculado.»;
|
|
|
|
|
q)
|
Na secção 10.4, o ponto CSM_176 é alterado do seguinte modo:
|
i)
|
o ponto 2 passa a ter a seguinte redação:
|
«2.
|
A VU envia para o cartão o ponto público VU.PKeph do seu par de chaves efémeras. O ponto público deve ser convertido numa cadeia de octetos, em conformidade com a Orientação Técnica TR-03111. Deve utilizar-se o formato de codificação não compactado. Tal como explicado em CSM_164, a VU criou esse par de chaves efémeras antes da verificação da cadeia de certificado da VU. A VU enviou o identificador da chave pública efémera Comp(VU.PKeph) para o cartão, que o memorizou.»;
|
|
|
ii)
|
o ponto 6 passa a ter a seguinte redação:
|
«6.
|
Utilizando KMAC, o cartão calcula um testemunho de autenticação sobre o identificador de ponto público efémero da VU: TPICC = CMAC(KMAC, VU.PKeph). O ponto público deve revestir o formato utilizado pela VU (ver ponto 2 supra). O cartão envia NPICC e TPICC para a unidade-veículo.»;
|
|
|
|
r)
|
Na secção 10.5.2, o ponto CSM_191 passa a ter a seguinte redação:
|
«CSM_191
|
Qualquer objeto de dados a encriptar é preenchido de acordo com a norma ISO 7816-4, mediante a utilização do indicador de conteúdo de preenchimento “01”. Relativamente ao cálculo do MAC, os objetos de dados na APDU são preenchidos de acordo com a norma ISO 7816-4.
Nota: O preenchimento para envio seguro de mensagens é efetuado sempre pelo nível de envio seguro de mensagens e não pelos algoritmos CMAC ou CBC.
|
Síntese e exemplos
Uma APDU de comando com envio seguro de mensagens aplicado terá a estrutura seguinte, consoante a caixa do comando não seguro correspondente (DO é objeto de dados):
|
Caixa 1
|
:
|
CLA INS P1 P2 || Lc' || DO ‘8E’ || Le
|
|
Caixa 2
|
:
|
CLA INS P1 P2 || Lc' || DO ‘97’ || DO ‘8E’ || Le
|
|
Caixa 3 (byte INS par)
|
:
|
CLA INS P1 P2 || Lc' || DO ‘81’ || DO ‘8E’ || Le
|
|
Caixa 3 (byte INS ímpar)
|
:
|
CLA INS P1 P2 || Lc' || DO ‘B3’ || DO ‘8E’ || Le
|
|
Caixa 4 (byte INS par)
|
:
|
CLA INS P1 P2 || Lc' || DO ‘81’ || DO ‘97’ || DO ‘8E’ || Le
|
|
Caixa 4 (byte INS ímpar)
|
:
|
CLA INS P1 P2 || Lc' || DO ‘B3’ || DO ‘97’ || DO ‘8E’ || Le
|
onde Le = ‘00’ ou ‘00 00’, consoante se utilizem campos de comprimento curto ou campos de comprimento alargado; ver norma ISO 7816-4.
Uma APDU de resposta, com envio seguro de mensagens aplicado, tem a seguinte estrutura, consoante a caixa do comando não seguro correspondente (DO é objeto de dados):
|
Caixa 1 ou 3
|
:
|
DO ‘99’ || DO ‘8E’ || SW1SW2
|
|
Caixa 2 ou 4 (byte INS par) sem encriptação
|
:
|
DO ‘81’ || DO ‘99’ || DO ‘8E’ || SW1SW2
|
|
Caixa 2 ou 4 (byte INS par) com encriptação
|
:
|
DO ‘87’ || DO ‘99’ || DO ‘8E’ || SW1SW2
|
|
Caixa 2 ou 4 (byte INS ímpar) sem encriptação
|
:
|
DO ‘B3’ || DO ‘99’ || DO ‘8E’ || SW1SW2
|
Nota: A caixa 2 ou 4 (byte INS ímpar) com encriptação nunca é utilizada na comunicação entre uma VU e um cartão.
Seguem-se três exemplos de transformações da APDU para comandos com código INS par. O esquema 8 apresenta uma APDU de comando da caixa 4 autenticada, o esquema 9 apresenta uma APDU de resposta da caixa 1/caixa 3 autenticada e o esquema 10 apresenta uma APDU de resposta da caixa 2/caixa 4 encriptada e autenticada.
Esquema 8
Transformação de uma APDU de comando da caixa 4 autenticada
Esquema 9
Transformação de uma APDU de resposta da caixa 1/caixa 3 autenticada
Esquema 10
Transformação de uma APDU de resposta da caixa 2/caixa 4
 »
|
|
s)
|
Na secção 10.5.3, o ponto CSM_193 passa a ter a seguinte redação:
|
«CSM_193
|
O cartão tacográfico interrompe uma sessão de envio seguro de mensagens contínua se e só se ocorrer uma das seguintes condições:
|
—
|
recebe uma APDU de comando simples,
|
|
—
|
deteta um erro de envio seguro de mensagens numa APDU de comando:
|
—
|
está ausente um (esperado) objeto de dados do envio seguro de mensagens, está incorreta a ordem dos objetos de dados ou está incluído um objeto de dados desconhecido,
|
|
—
|
está incorreto um objeto de dados do envio seguro de mensagens: por exemplo, o valor MAC está incorreto ou a estrutura TLV está incorreta,
|
|
|
—
|
é desligado da energia elétrica ou reinicializado,
|
|
—
|
a VU inicia o processo da sua autenticação,
|
|
—
|
é atingido o limite para o número de comandos e respostas associados na sessão atual. Em relação a um determinado cartão, esse limite é definido pelo fabricante, tendo em conta os requisitos de segurança do equipamento informático utilizado, com um valor máximo de 240 comandos SM e respostas associadas por sessão»;
|
|
|
|
t)
|
A secção 11.3.2 é alterada do seguinte modo:
|
i)
|
O primeiro parágrafo do ponto CSM_208 passa a ter a seguinte redação:
Não diz respeito à versão portuguesa.
|
|
ii)
|
O ponto CSM_210 passa a ter a seguinte redação:
Não diz respeito à versão portuguesa.
|
|
|
u)
|
Na secção 11.3.3, o primeiro parágrafo do ponto CSM_211 passa a ter a seguinte redação:
«Durante o funcionamento normal, uma unidade-veículo e um EGF utilizam o protocolo descrito no esquema 11 para verificar a validade temporal do certificado EGF_MA memorizado e para definir a chave pública VU_MA para autenticação subsequente da VU. Durante o funcionamento normal, não têm lugar verificações mútuas adicionais do certificado.»;
|
|
v)
|
Na secção 12.3, o quadro 6 passa a ter a seguinte redação:
«Quadro 6
Número de bytes de dados de texto simples e encriptados por instrução definida na norma ISO 16844-3
|
Instruções
|
Pedido / resposta
|
Descrição dos dados
|
N.o de bytes de dados de texto simples, de acordo com
a norma ISO 16844-3
|
N.o de bytes de dados de texto simples que utilizam chaves AES
|
N.o de bytes de dados encriptados ao utilizar chaves AES com comprimento em bits
|
|
128
|
192
|
256
|
|
10
|
Pedido
|
Dados de autenticação + número de ficheiro
|
8
|
8
|
16
|
16
|
16
|
|
11
|
Resposta
|
Dados de autenticação + conteúdo do ficheiro
|
16 ou 32, consoante o ficheiro
|
16 or32 consoante o ficheiro
|
32 / 48
|
32 / 48
|
32 / 48
|
|
41
|
Pedido
|
Número de série MoS
|
8
|
8
|
16
|
16
|
16
|
|
41
|
Resposta
|
Chave de emparelhamento
|
16
|
16 / 24 / 32
|
16
|
32
|
32
|
|
42
|
Pedido
|
Chave de sessão
|
16
|
16 / 24 / 32
|
16
|
32
|
32
|
|
43
|
Pedido
|
Informações do emparelhamento
|
24
|
24
|
32
|
32
|
32
|
|
50
|
Resposta
|
Informações do emparelhamento
|
24
|
24
|
32
|
32
|
32
|
|
70
|
Pedido
|
Dados de autenticação
|
8
|
8
|
16
|
16
|
16
|
|
80
|
Resposta
|
Valor do contador MoS + dados autenticados
|
8
|
8
|
16
|
16
|
16»
|
|
|
w)
|
Na secção 13.1, o requisito relativo ao número de série da VU constante do ponto CSM_224 passa a ter a seguinte redação:
|
«Número de série da VU
|
número de série da VU ou ID de pedido de certificado (tipo de dados VuSerialNumber ou CertificateRequestID) – ver CSM_123»;
|
|
|
x)
|
Na secção 13.3, o segundo travessão do ponto CSM_228 passa a ter a seguinte redação:
|
«2.
|
O cartão de controlo utiliza a chave de segurança DSRC indicada em combinação com o número de série da VU ou com o ID de pedido de certificado nos dados de segurança DSRC, para derivar as chaves DSRC específicas da VU K_VUDSRC_ENC e K_VUDSRC_MAC, em conformidade com o requisito CSM_124.»;
|
|
|
y)
|
A secção 14.3 é alterada do seguinte modo:
|
i)
|
No ponto CSM_234, o texto anterior às notas do esquema 13 passa a ter a seguinte redação:
«Um IDE pode executar a verificação de uma assinatura em dados descarregados por si próprio ou utilizar um cartão de controlo para esse efeito. Caso utilize um cartão de controlo, a verificação da assinatura ocorre como mostra o esquema 13. Para verificar a validade temporal de um certificado apresentado pelo IDE, o cartão de controlo utiliza o seu relógio interno, em conformidade com o requisito CSM_167. O cartão de controlo atualiza a sua hora se a data de vigência de um certificado «fonte de tempo válida» autêntico for mais recente do que a hora atual do cartão. Como fonte de tempo válida, o cartão aceita apenas os seguintes certificados:
|
—
|
Certificados de ligação ERCA da segunda geração
|
|
—
|
Certificados MSCA da segunda geração
|
|
—
|
Certificados VU_Sign ou Card_Sign da segunda geração emitidos pelo mesmo país do próprio certificado dos cartões do cartão de controlo.
|
Caso realize a verificação da própria assinatura, o IDE verifica a autenticidade e a validade de todos os certificados, na cadeia de certificado no ficheiro de dados e verifica a assinatura na sequência de dados do esquema de assinatura definido em DSS. Em ambos os casos, para cada certificado lido a partir do ficheiro de dados, é necessário verificar se o campo da autorização do titular do certificado (CHA) está correto:
|
—
|
O campo CHA do certificado de EQT deve indicar um certificado da VU ou de cartão (consoante o que for aplicável) para assinatura (ver apêndice 1, tipo de dados EquipmentType).
|
|
—
|
O CHA do certificado EQT.CA deve indicar uma MSCA.
|
|
—
|
O CHA do certificado EQT.Link deve indicar uma ERCA.»;
|
|
|
ii)
|
O esquema 13 é substituído pelo esquema seguinte:
«Esquema 13
Protocolo de verificação da assinatura num ficheiro de dados descarregados
 »
|
|
|
In force
Texto de imagem
»
»
Posição após três horas de tempo de condução acumulado»;
Conflito de tempos ou ajustamento do tempo (pela oficina)»;
Ausência de informações sobre a posição do recetor GNSS ou Erro de comunicação com o módulo GNSS externo;
Erro de comunicação com o módulo de comunicação à distância»;
).»;
e
. Esta informação é opcional e não é securizada com uma assinatura digital.
:
e do
dos EF. Esta informação não é securizada com uma assinatura digital.
) com exceção do EF
. Esta informação é securizada com uma assinatura digital, utilizando os Mecanismos comuns de segurança, Parte A do apêndice 11.
e a
dos EF para cada sessão de descarregamento.
DF:
DF) exceto EF
. Esta informação é securizada com uma assinatura digital, utilizando os Mecanismos comuns de segurança, Parte B do apêndice 11.
e a
dos EF para cada sessão de descarregamento.
no EF
, no
e, quando aplicável, nos DF
.
no
e, quando aplicável, nos DF
.
no
e, quando aplicável, nos DF
não devem ser descarregados.»;
»
