INDICE
1.Introduzione9
1.1.Panoramica e ambito di applicazione della presente politica9
1.2.Definizioni e acronimi11
1.3.Partecipanti alla PKI13
1.3.1.Introduzione13
1.3.2.Autorità per la politica dei certificati dei C-ITS16
1.3.3.Gestore dell'elenco di fiducia17
1.3.4.Auditor accreditato della PKI17
1.3.5.Punto di contatto C-ITS (CPOC)17
1.3.6.Ruoli operativi18
1.4.Uso dei certificati18
1.4.1.Domini d'uso applicabili18
1.4.2.Limiti di responsabilità19
1.5.Amministrazione della politica dei certificati19
1.5.1.Aggiornamento dei CPS di CA figuranti nell'ECTL19
1.5.2.Procedure di approvazione del CPS20
2.Responsabilità delle pubblicazioni e del repository20
2.1.Metodi per la pubblicazione delle informazioni sui certificati20
2.2.Tempo o frequenza di pubblicazione21
2.3.Repository21
2.4.Controlli degli accessi ai repository21
2.5.Pubblicazione delle informazioni sui certificati22
2.5.1.Pubblicazione delle informazioni sui certificati da parte del TLM22
2.5.2.Pubblicazione delle informazioni sui certificati da parte delle CA22
3.Identificazione e autenticazione23
3.1.Assegnazione dei nomi23
3.1.1.Tipi di nome23
3.1.1.1.Nomi per TLM, CA radice, EA e AA23
3.1.1.2.Nomi per le entità finali23
3.1.1.3.Identificazione dei certificati23
3.1.2.Necessità di nomi significativi23
3.1.3.Anonimità e uso di pseudonimi delle entità finali23
3.1.4.Regole per l'interpretazione di varie forme di nomi23
3.1.5.Unicità dei nomi24
3.2.Convalida dell'identità iniziale24
3.2.1.Metodo per dimostrare il possesso di una chiave privata24
3.2.2.Autenticazione dell'identità dell'organizzazione24
3.2.2.1.Autenticazione dell'identità dell'organizzazione della CA radice24
3.2.2.2.Autenticazione dell'identità dell'organizzazione del TLM25
3.2.2.3.Autenticazione dell'identità dell'organizzazione delle sub-CA25
3.2.2.4.Autenticazione dell'organizzazione del sottoscrittore delle entità finali26
3.2.3.Autenticazione di un'entità individuale26
3.2.3.1.Autenticazione di un'entità individuale TLM/CA26
3.2.3.2.Autenticazione dell'identità dei sottoscrittori delle stazioni C-ITS27
3.2.3.3.Autenticazione dell'identità delle stazioni C-ITS27
3.2.4.Informazioni non verificate relative al sottoscrittore27
3.2.5.Convalida dell'autorità27
3.2.5.1.Convalida di TLM, CA radice, EA e AA27
3.2.5.2.Convalida dei sottoscrittori di stazioni C-ITS28
3.2.5.3.Convalida delle stazioni C-ITS28
3.2.6.Criteri per l'interoperabilità28
3.3.Identificazione e autenticazione per le richieste di re-keying28
3.3.1.Identificazione e autenticazione per le richieste di re-keying di routine28
3.3.1.1.Certificati del TLM28
3.3.1.2.Certificati della CA radice28
3.3.1.3.Rinnovo o re-keying del certificato della EA/AA28
3.3.1.4.Credenziali di registrazione delle entità finali29
3.3.1.5.Ticket di autorizzazione delle entità finali29
3.3.2.Identificazione e autenticazione per le richieste di re-keying dopo la revoca29
3.3.2.1.Certificati della CA29
3.3.2.2.Credenziali di registrazione delle entità finali29
3.3.2.3.Richieste di autorizzazione delle entità finali29
3.4.Identificazione e autenticazione per le richieste di revoca29
3.4.1.Certificati di CA radice/EA/AA29
3.4.2.Credenziali di registrazione della stazione C-ITS30
3.4.3.Ticket di autorizzazione della stazione C-ITS30
4.Requisiti operativi per il ciclo di vita dei certificati30
4.1.Domanda di certificato30
4.1.1.Chi può presentare la domanda di certificato30
4.1.1.1.CA radice30
4.1.1.2.TLM31
4.1.1.3.EA e AA31
4.1.1.4.Stazione C-ITS31
4.1.2.Processo di registrazione e responsabilità31
4.1.2.1.CA radice31
4.1.2.2.TLM32
4.1.2.3.EA e AA32
4.1.2.4.Stazione C-ITS32
4.2.Trattamento della domanda di certificato33
4.2.1.Esecuzione delle funzioni di identificazione e di autenticazione33
4.2.1.1.Identificazione e autenticazione delle CA radice33
4.2.1.2.Identificazione e autenticazione del TLM33
4.2.1.3.Identificazione e autenticazione di EA e AA33
4.2.1.4.Identificazione e autenticazione del sottoscrittore della EE34
4.2.1.5.Ticket di autorizzazione34
4.2.2.Approvazione o rifiuto delle domande di certificato34
4.2.2.1.Approvazione o rifiuto dei certificati della CA radice34
4.2.2.2.Approvazione o rifiuto del certificato del TLM34
4.2.2.3.Approvazione o rifiuto dei certificati delle EA e AA34
4.2.2.4.Approvazione o rifiuto delle EC34
4.2.2.5.Approvazione o rifiuto di AT35
4.2.3.Tempi di trattamento della domanda di certificato35
4.2.3.1.Domanda di certificato della CA radice35
4.2.3.2.Domanda di certificato del TLM35
4.2.3.3.Domanda di certificato delle EA e AA35
4.2.3.4.Domanda di EC35
4.2.3.5.Domanda di AT35
4.3.Rilascio del certificato35
4.3.1.Azioni della CA durante il rilascio del certificato35
4.3.1.1.Rilascio del certificato della CA radice35
4.3.1.2.Rilascio del certificato del TLM36
4.3.1.3.Rilascio del certificato delle EA e AA36
4.3.1.4.Rilascio delle EC36
4.3.1.5.Rilascio dell'AT36
4.3.2.Notifica della CA al sottoscrittore relativa al rilascio dei certificati36
4.4.Accettazione di certificati37
4.4.1.Procedura di accettazione di certificati37
4.4.1.1.CA radice37
4.4.1.2.TLM37
4.4.1.3.EA e AA37
4.4.1.4.Stazione C-ITS37
4.4.2.Pubblicazione dei certificati37
4.4.3.Notifica del rilascio di certificati37
4.5.Coppia di chiavi e uso dei certificati37
4.5.1.Chiave privata e uso dei certificati37
4.5.1.1.Chiave privata e uso dei certificati per il TLM37
4.5.1.2.Chiave privata e uso dei certificati per le CA radice37
4.5.1.3.Chiave privata e uso dei certificati per le EA e AA37
4.5.1.4.Chiave privata e uso dei certificati per le entità finali38
4.5.2.Chiave pubblica e uso dei certificati delle relying parties38
4.6.Rinnovo dei certificati38
4.7.Re-keying dei certificati38
4.7.1.Circostanze in cui si verifica il re-keying38
4.7.2.Chi può chiedere il re-keying38
4.7.2.1.CA radice38
4.7.2.2.TLM38
4.7.2.3.EA e AA38
4.7.2.4.Stazione C-ITS39
4.7.3.Processo di re-keying39
4.7.3.1.Certificato del TLM39
4.7.3.2.Certificato della CA radice39
4.7.3.3.Certificati delle EA e AA39
4.7.3.4.Certificati della stazione C-ITS40
4.8.Modifica del certificato40
4.9.Sospensione e revoca del certificato40
4.10.Servizi relativi allo status del certificato40
4.10.1.Caratteristiche operative40
4.10.2.Disponibilità del servizio40
4.10.3.Caratteristiche facoltative40
4.11.Fine della sottoscrizione40
4.12.Key escrow (deposito della chiave) e key recovery (recupero della chiave)40
4.12.1.Sottoscrittore40
4.12.1.1.Coppie di chiavi che possono essere depositate presso terzi (key escrow)40
4.12.1.2.Chi può presentare una domanda di recupero40
4.12.1.3.Processo di recovery e responsabilità40
4.12.1.4.Identificazione e autenticazione40
4.12.1.5.Approvazione o rifiuto delle domande di recovery40
4.12.1.6.Azioni KEA e KRA durante il recupero della coppia di chiavi41
4.12.1.7.Disponibilità KEA e KRA41
4.12.2.Incapsulamento della chiave di sessione e politica e pratiche di recupero41
5.Controlli operativi, di gestione e degli impianti41
5.1.Controlli fisici41
5.1.1.Ubicazione e costruzione del sito41
5.1.1.1.CA radice, CPOC, TLM41
5.1.1.2.EA/AA42
5.1.2.Accesso fisico42
5.1.2.1.CA radice, CPOC, TLM42
5.1.2.2.EA/AA43
5.1.3.Energia elettrica e aria condizionata43
5.1.4.Esposizione all'acqua43
5.1.5.Prevenzione e protezione antincendio44
5.1.6.Gestione dei supporti di dati44
5.1.7.Smaltimento dei rifiuti44
5.1.8.Backup esterno al sito44
5.1.8.1.CA radice, CPOC e TLM44
5.1.8.2.EA/AA45
5.2.Controlli procedurali45
5.2.1.Ruoli di fiducia45
5.2.2.Numero di persone necessarie per compito45
5.2.3.Identificazione e autenticazione per ciascun ruolo46
5.2.4.Ruoli che richiedono la separazione delle funzioni46
5.3.Controlli del personale47
5.3.1.Qualifiche, esperienza e requisiti per il nulla osta47
5.3.2.Procedure di controllo dei precedenti personali47
5.3.3.Requisiti di formazione48
5.3.4.Frequenza e requisiti di aggiornamento della formazione48
5.3.5.Frequenza e sequenza di rotazione del lavoro48
5.3.6.Sanzioni per le azioni non autorizzate48
5.3.7.Requisiti per i contraenti indipendenti49
5.3.8.Documentazione fornita al personale49
5.4.Procedure di logging per gli audit49
5.4.1.Tipi di eventi da registrare e segnalare per ciascuna CA49
5.4.2.Frequenza di trattamento dei log50
5.4.3.Periodo di conservazione dei log di audit50
5.4.4.Protezione dei log di audit51
5.4.5.Procedure di backup dei log di audit51
5.4.6.Sistema di raccolta degli audit (interno o esterno)51
5.4.7.Notifica al soggetto che provoca l'evento51
5.4.8.Valutazione delle vulnerabilità51
5.5.Archiviazione delle registrazioni52
5.5.1.Tipi di registrazioni archiviate52
5.5.2.Periodo di conservazione degli archivi53
5.5.3.Protezione degli archivi53
5.5.4.Archivio di sistema e conservazione53
5.5.5.Requisiti per la marcatura temporale delle registrazioni54
5.5.6.Sistema di raccolta degli archivi (interno o esterno)54
5.5.7.Procedure per l'acquisizione e la verifica delle informazioni di archivio54
5.6.Sostituzione della chiave per gli elementi del modello di fiducia C-ITS54
5.6.1.TLM54
5.6.2.CA radice54
5.6.3.Certificato della EA/AA54
5.6.4.Auditor55
5.7.Ripristino in caso di disastro e compromissione55
5.7.1.Gestione degli incidenti e delle compromissioni55
5.7.2.Risorse di calcolo, software e/o dati corrotti56
5.7.3.Procedure in caso di compromissione della chiave privata dell'entità56
5.7.4.Capacità di continuità operativa dopo un disastro56
5.8.Cessazione e trasferimento57
5.8.1.TLM57
5.8.2.CA radice57
5.8.3.EA/AA58
6.Controlli tecnici di sicurezza58
6.1.Generazione e installazione della coppia di chiavi58
6.1.1.TLM, CA radice, EA e AA58
6.1.2.EE - stazione C-ITS mobile58
6.1.3.EE - stazione C-ITS fissa59
6.1.4.Requisiti crittografici59
6.1.4.1.Algoritmo e lunghezza della chiave - algoritmi di firma59
6.1.4.2.Algoritmo e lunghezza della chiave - algoritmi di cifratura per la registrazione e l'autorizzazione60
6.1.4.3.Crypto-agility (agilità crittografica)61
6.1.5.Conservazione sicura delle chiavi private61
6.1.5.1.Livello della CA radice, della sub-CA e del TLM61
6.1.5.2.Entità finale62
6.1.6.Backup delle chiavi private63
6.1.7.Distruzione delle chiavi private63
6.2.Dati di attivazione63
6.3.Controlli di sicurezza del computer63
6.4.Controlli tecnici del ciclo di vita63
6.5.Controlli di sicurezza della rete63
7.Profili dei certificati, CRL e CTL63
7.1.Profilo dei certificati63
7.2.Validità dei certificati64
7.2.1.Certificati pseudonimi65
7.2.2.Ticket di autorizzazione per le stazioni C-ITS fisse65
7.3.Revoca dei certificati65
7.3.1.Revoca dei certificati della CA, della EA e della AA65
7.3.2.Revoca delle credenziali di registrazione66
7.3.3.Revoca dei ticket di autorizzazione66
7.4.Lista dei certificati revocati66
7.5.Elenco di fiducia europeo dei certificati66
8.Audit di conformità e altre valutazioni66
8.1.Tematiche oggetto dell'audit e base dell'audit66
8.2.Frequenza degli audit67
8.3.Identità/qualifiche dell'auditor67
8.4.Relazione tra auditor e entità sottoposta a audit67
8.5.Misure adottate in caso di carenze68
8.6.Comunicazione dei risultati68
9.Altre disposizioni68
9.1.Tariffe68
9.2.Responsabilità finanziaria69
9.3.Riservatezza delle informazioni aziendali69
9.4.Piano per la tutela della privacy69
10.Riferimenti69
ALLEGATO III
1.Introduzione
1.1.Panoramica e ambito di applicazione della presente politica
La presente politica dei certificati definisce il modello di fiducia C-ITS europeo basato sull'infrastruttura a chiave pubblica (PKI) nell'ambito del sistema dell'UE di gestione delle credenziali di sicurezza C-ITS (EU CCMS) nel suo complesso. Essa definisce i requisiti per la gestione dei certificati a chiave pubblica per applicazioni C-ITS da parte delle entità di rilascio e per il loro utilizzo da parte delle entità finali in Europa. Al livello più alto la PKI è costituita da un insieme di autorità di certificazione (CA) radice "abilitate" a seguito dell'inserimento, da parte del gestore degli elenchi di fiducia (TLM), dei loro certificati in un elenco di fiducia europeo dei certificati (ECTL), rilasciato e pubblicato dal TLM dell'entità centrale (cfr. le sezioni 1.2 e 1.3).
La presente politica è vincolante per tutte le entità che partecipano al sistema fidato C-ITS in Europa e contribuisce alla valutazione del livello di fiducia che può essere stabilito nelle informazioni ricevute da qualsiasi destinatario di un messaggio autenticato da un certificato dell'entità finale della PKI. Per consentire la valutazione della fiducia nei certificati forniti dall'EU CCMS, la presente politica stabilisce un insieme di requisiti vincolanti per il funzionamento del TLM dell'entità centrale e per la compilazione e la gestione dell'ECTL. Di conseguenza il presente documento disciplina i seguenti aspetti relativi all'ECTL:
·l'identificazione e l'autenticazione dei protagonisti che ottengono ruoli di PKI per il TLM, comprese le dichiarazioni dei privilegi assegnati a ciascun ruolo;
·i requisiti minimi per le pratiche di sicurezza locale per il TLM, compresi i controlli fisici, procedurali e del personale;
·i requisiti minimi per le pratiche di sicurezza tecnica per il TLM, compresi i controlli relativi alla sicurezza informatica, alla sicurezza della rete e i controlli ingegneristici del modulo crittografico;
·i requisiti minimi per le pratiche operative per il TLM, compresa la registrazione dei nuovi certificati delle CA radice, l'annullamento temporaneo o permanente della registrazione di CA radice esistenti e incluse, e la pubblicazione e la distribuzione degli aggiornamenti dell'ECTL;
·un profilo dell'ECTL, compresi tutti i campi dati obbligatori e facoltativi dell'ECTL, gli algoritmi crittografici da utilizzare, il formato esatto dell'ECTL e le raccomandazioni per l'elaborazione dell'ECTL;
·la gestione del ciclo di vita del certificato dell'ECTL, compresa la distribuzione dei certificati dell'ECTL e la loro attivazione, scadenza e revoca;
·la gestione della revoca della fiducia delle CA radice ove necessario.
Poiché l'affidabilità dell'ECTL non dipende esclusivamente dall'ECTL stesso, ma in larga parte anche dalle CA radice, e dalle loro subCA, che costituiscono la PKI, la presente politica stabilisce inoltre requisiti minimi obbligatori per tutte le CA partecipanti (CA radice e subCA). Gli ambiti di tali requisiti sono i seguenti:
·identificazione e autenticazione dei protagonisti che ottengono ruoli di PKI (ad esempio responsabile della sicurezza, responsabile della privacy, amministratore della sicurezza, amministratore di directory e utente finale), compresa una dichiarazione delle funzioni, delle responsabilità, degli obblighi e dei privilegi associati a ciascun ruolo;
·gestione delle chiavi, compresi gli algoritmi accettabili e obbligatori per la firma dei dati e dei certificati e i periodi di validità dei certificati;
·requisiti minimi per le pratiche di sicurezza locale, compresi i controlli fisici, procedurali e del personale;
·requisiti minimi per le pratiche di sicurezza tecnica, compresi i controlli relativi alla sicurezza informatica, alla sicurezza della rete e al modulo crittografico;
·requisiti minimi per le pratiche operative delle CA, EA, AA e delle entità finali, compresi gli aspetti relativi a registrazione, annullamento della registrazione (cancellazione dall'elenco), revoca, compromissione della chiave, licenziamento per giusta causa, aggiornamento del certificato, pratiche di audit e non divulgazione delle informazioni relative alla privacy;
·profilo dei certificati e della CRL, compresi formati, algoritmi accettabili, campi dati obbligatori e facoltativi e i relativi intervalli di valori validi e le modalità di elaborazione dei certificati da parte dei verificatori;
·monitoraggio regolare, segnalazioni, messaggi di allerta e ripristino delle funzioni delle entità del modello di fiducia C-ITS al fine di determinare un funzionamento sicuro, soprattutto in caso di comportamenti scorretti.
Oltre a questi requisiti minimi le entità che gestiscono le CA radice e le subCA possono stabilire i loro requisiti aggiuntivi e definirli nei pertinenti Certificate Practice Statements (CPS - manuale operativo delle procedure di certificazione), a condizione che non contraddicano i requisiti stabiliti nella politica dei certificati. Cfr. la sezione 1.5 per informazioni dettagliate relative alle modalità di audit e pubblicazione dei CPS.
La CP indica anche gli scopi per cui le CA radice, le subCA e i certificati da esse rilasciati possono essere utilizzati e stabilisce le responsabilità assunte:
·dal TLM;
·da ciascuna CA radice i cui certificati sono elencati nell'ECTL;
·dalle subCA delle CA radice (EA e AA);
·da ciascun membro o organizzazione che gestisce una delle entità del modello di fiducia C-ITS o che ne è responsabile.
La CP definisce inoltre obblighi vincolanti applicabili:
·ai TLM;
·a ciascuna CA radice i cui certificati sono elencati nell'ECTL;
·a ciascuna subCA certificata da una CA radice;
·a tutte le entità finali;
·a ciascun membro o organizzazione che gestisce una delle entità del modello di fiducia C-ITS o che ne è responsabile.
Infine la CP stabilisce i requisiti per quanto riguarda la documentazione nei CPS delle limitazioni delle responsabilità e degli obblighi di ciascuna CA radice i cui certificati sono elencati nell'ECTL.
La presente CP è in linea con la politica dei certificati e il quadro di pratiche di certificazione adottato dall'Internet Engineering Task Force (IETF) [3].
1.2.Definizioni e acronimi
Si applicano le definizioni di cui ai riferimenti [2], [3] e [4].
AA
|
autorità di autorizzazione
|
AT
|
ticket di autorizzazione (authorisation ticket)
|
CA
|
autorità di certificazione
|
CP
|
politica dei certificati
|
CPA
|
autorità per la politica dei certificati dei C-ITS
|
CPOC
|
punto di contatto C-ITS
|
CPS
|
Certificate Practice Statements (manuale operativo delle procedure di certificazione)
|
CRL
|
lista dei certificati revocati
|
EA
|
autorità per le registrazioni
|
EC
|
credenziali di registrazione
|
ECIES
|
schema di cifratura integrato basato su curve ellittiche
|
EE
|
entità finale (la stazione C-ITS)
|
ECTL
|
elenco di fiducia europeo dei certificati
|
EU CCMS
|
sistema dell'UE di gestione delle credenziali di sicurezza C-ITS
|
GDPR
|
regolamento generale sulla protezione dei dati
|
HSM
|
modulo di sicurezza hardware (hardware security module)
|
PKI
|
infrastruttura a chiave pubblica
|
RA
|
autorità di registrazione
|
subCA
|
EA e AA
|
TLM
|
gestore dell'elenco di fiducia
|
Glossario
richiedente
|
Persona fisica o giuridica che richiede (o chiede il rinnovo di) un certificato. Una volta creato il certificato iniziale (inizializzazione), il richiedente è indicato come sottoscrittore.
Per i certificati rilasciati a entità finali, il sottoscrittore (richiedente del certificato) è l'entità che controlla o gestisce l'entità finale a cui è stato rilasciato il certificato, anche se è l'entità finale che richiede effettivamente il certificato.
|
autorità di autorizzazione
|
Nel presente documento per "autorità di autorizzazione" (AA) si intende non solo la funzione specifica dell'AA, ma anche la persona giuridica e/o l'entità operativa che la gestisce.
|
autorità di certificazione
|
Per autorità di certificazione (CA) si intende, cumulativamente, l'autorità di certificazione radice, l'autorità per le registrazioni e l'autorità di autorizzazione.
|
modello di fiducia C-ITS
|
La funzione del modello di fiducia C-ITS è stabilire una relazione di fiducia tra le stazioni C-ITS. Esso viene implementato mediante l'uso di una PKI composta da CA radice, CPOC, TLM, EA, AA e una rete sicura.
|
crypto-agility (agilità crittografica)
|
La capacità delle entità dei modelli di fiducia C-ITS di adattare le CP a contesti in continuo mutamento o a nuovi requisiti futuri, ad esempio modificando nel tempo gli algoritmi crittografici e la lunghezza della chiave.
|
modulo crittografico
|
Un elemento hardware sicuro in cui vengono generate e/o conservate le chiavi, generati numeri casuali e firmati o cifrati i dati.
|
autorità per le registrazioni
|
Nel presente documento per "autorità per le registrazioni" (EA) si intende non solo la funzione specifica dell'EA, ma anche la persona giuridica e/o l'entità operativa che la gestisce.
|
partecipanti alla PKI
|
Entità del modello di fiducia C-ITS, vale a dire TLM, CA radice, EA, AA e stazioni C-ITS.
|
re-keying (riassegnazione delle chiavi)
|
|
repository
|
Il repository usato per conservare i certificati e le informazioni sui certificati forniti dalle entità del modello di fiducia C-ITS come definito nella sezione 2.3.
|
autorità di certificazione radice
|
Nel presente documento per "autorità di certificazione radice" (CA) si intende non solo la funzione specifica della CA, ma anche la persona giuridica e/o l'entità operativa che la gestisce.
|
soggetto
|
La persona fisica, il dispositivo, il sistema, l'unità o la persona giuridica identificati nel certificato come soggetto, vale a dire il sottoscrittore o il dispositivo controllato e gestito dal sottoscrittore.
|
sottoscrittore
|
La persona fisica o giuridica alla quale è stato rilasciato un certificato e che è giuridicamente vincolata dai termini di utilizzo o da un accordo di sottoscrizione.
|
accordo di sottoscrizione
|
Un accordo tra la CA e il richiedente/sottoscrittore che specifica i diritti e le responsabilità delle parti
|
1.3.Partecipanti alla PKI
1.3.1.Introduzione
I partecipanti alla PKI svolgono un ruolo nella PKI definito dalla presente politica. A meno che non sia esplicitamente vietato, i partecipanti possono svolgere molteplici ruoli contemporaneamente. Lo svolgimento contemporaneo di ruoli specifici può essere vietato al fine di evitare conflitti di interessi e garantire la separazione delle funzioni.
I partecipanti possono inoltre delegare parte del loro ruolo ad altre entità nell'ambito di un contratto di servizio. Ad esempio, per quanto riguarda la fornitura di informazioni sullo stato di revoca usando la CRL, la CA è anche l'entità che rilascia la CRL, ma può delegare la responsabilità del rilascio a un'altra entità.
I ruoli della PKI sono costituiti da:
·ruoli autoritativi, cioè ruoli che possono essere svolti da una sola entità;
·ruoli operativi, cioè ruoli che possono essere svolti da una o più entità.
Ad esempio il ruolo di CA radice può essere svolto da un'entità commerciale, da un gruppo di interesse comune, da un'organizzazione nazionale e/o da un'organizzazione europea.
La figura 1 mostra l'architettura del modello di fiducia C-ITS basato sul riferimento [2]. Questa architettura è qui descritta brevemente, ma gli elementi principali sono descritti in modo più dettagliato nelle sezioni da 1.3.2 a 1.3.6.
La CPA nomina il TLM che è quindi un'entità fidata per tutti i partecipanti alla PKI. La CPA approva il funzionamento della CA radice e conferma che il TLM può considerare fidate le CA radice. Il TLM rilascia l'ECTL, in base al quale tutti i partecipanti alla PKI possono considerare fidate le CA radice approvate. La CA radice rilascia certificati all'EA e all'AA, in base ai quali il loro funzionamento viene considerato fidato. L'EA rilascia certificati di registrazione alle stazioni C-ITS di invio o di ritrasmissione (come entità finali), in base ai quali il loro funzionamento viene considerato fidato. L'AA rilascia AT alle stazioni C-ITS in base alla fiducia nell'EA.
Le stazioni C-ITS di invio o di ritrasmissione (in quanto parte di ritrasmissione) possono considerare fidate le altre stazioni C-ITS, poiché gli AT sono stati rilasciati da un'AA considerata fidata da una CA radice, la quale è considerata fidata dal TLM e dalla CPA.
Si noti che la figura 1 descrive solo il livello delle CA radice del modello di fiducia C-ITS. I dettagli dei livelli inferiori sono forniti nelle sezioni successive della presente CP o del CPS delle specifiche CA radice.
La figura 2 fornisce una panoramica dei flussi di informazioni tra i partecipanti alla PKI. I punti verdi indicano i flussi che richiedono comunicazioni macchina-macchina. I flussi di informazioni in rosso presentano requisiti di sicurezza definiti.
Il modello di fiducia C-ITS è basato su un'architettura comprendente molteplici CA radice, in cui i certificati delle CA radice sono trasmessi periodicamente (come indicato di seguito) al punto di contatto centrale (CPOC) mediante un protocollo sicuro (ad esempio certificati di collegamento) definiti dal CPOC.
Una CA radice può essere gestita da un'organizzazione governativa o privata. L'architettura dei modelli di fiducia C-ITS comprende almeno una CA radice (la CA radice dell'UE allo stesso livello delle altre CA radice). Le entità che partecipano al modello di fiducia C-ITS e che non vogliono istituire una propria CA radice delegano la CA radice dell'UE. Il CPOC trasmette i certificati della CA radice ricevuti al TLM, il quale è responsabile della raccolta e della firma dell'elenco dei certificati della CA radice e della loro ritrasmissione al CPOC che li rende pubblicamente disponibili a tutti (cfr. di seguito).
Le relazioni di fiducia tra le entità nel modello di fiducia C-ITS sono descritte nelle seguenti figure, tabelle e sezioni.
Figura 1: architettura del modello di fiducia C-ITS
Figura 2: flusso delle informazioni del modello di fiducia C-ITS
ID flusso
|
Da
|
A
|
Contenuto
|
Riferimento
|
(1).
|
CPA
|
TLM
|
approvazione della domanda della CA radice
|
8
|
(2).
|
CPA
|
TLM
|
informazioni sulla revoca della CA radice
|
8.5
|
(3).
|
CPA
|
CA radice
|
aggiornamenti della CP
|
1.5
|
(4).
|
CPA
|
CA radice
|
approvazione/rifiuto del modulo di domanda della CA radice o delle modifiche della richiesta di CPS o del processo di audit
|
8.5, 8.6
|
(5).
|
TLM
|
CPA
|
notifica della modifica dell'ECTL
|
4, 5.8.1
|
(6).
|
TLM
|
CPOC
|
certificato del TLM
|
4.4.2
|
(7).
|
TLM
|
CPOC
|
ECTL
|
4.4.2
|
(8).
|
CPOC
|
TLM
|
informazioni sul certificato della CA radice
|
4.3.1.1
|
(9).
|
CPOC
|
TLM
|
revoca del certificato della CA radice
|
7.3
|
(10).
|
CPOC
|
tutte le entità finali
|
certificato del TLM
|
4.4.2
|
(11).
|
CA radice
|
CPOC
|
informazioni sul certificato della CA radice
|
4.3.1.1
|
(12).
|
CA radice
|
CPOC
|
revoca del certificato della CA radice
|
7.3
|
(13).
|
CA radice
|
auditor
|
ordine di audit
|
8
|
(14).
|
CA radice
|
CPA
|
modulo di domanda della CA radice - richiesta iniziale
|
4.1.2.1
|
(15).
|
CA radice
|
CPA
|
modulo di domanda della CA radice - modifiche del CPS
|
1.5.1
|
(16).
|
CA radice
|
CPA
|
modulo di domanda della CA radice - relazione di audit
|
8.6
|
(17).
|
CA radice
|
CPA
|
relazioni sugli incidenti delle CA radice, compresa la revoca di una subCA (EA, AA)
|
allegato III, punto 7.3.1
|
(18).
|
CA radice
|
EA
|
risposta del certificato della EA
|
4.2.2.3
|
(19).
|
CA radice
|
AA
|
risposta del certificato della AA
|
4.2.2.3
|
(20).
|
CA radice
|
Tutti
|
certificato della EA/AA, CRL
|
4.4.2
|
(21).
|
EA
|
CA radice
|
richiesta di certificato della EA
|
4.2.2.3
|
(22).
|
EA
|
stazione C-ITS
|
risposta delle credenziali di registrazione
|
4.3.1.4
|
(23).
|
EA
|
AA
|
risposta di autorizzazione
|
4.2.2.5
|
(24).
|
AA
|
CA radice
|
richiesta di certificato della AA
|
4.2.2.3
|
(25).
|
AA
|
EA
|
richiesta di autorizzazione
|
4.2.2.5
|
(26).
|
AA
|
stazione C-ITS
|
risposta del ticket di autorizzazione
|
4.3.1.5
|
(27).
|
EA
|
CA radice
|
presentazione della richiesta
|
4.1.2.3
|
(28).
|
AA
|
CA radice
|
presentazione della richiesta
|
4.1.2.3
|
(29).
|
CA radice
|
EA
|
risposta
|
4.12 e 4.2.1
|
(30).
|
CA radice
|
AA
|
risposta
|
4.12 e 4.2.1
|
(31).
|
stazione C-ITS
|
EA
|
richiesta di credenziali di registrazione
|
4.2.2.4
|
(32).
|
stazione C-ITS
|
AA
|
richiesta di ticket di autorizzazione
|
4.2.2.5
|
(33).
|
fabbricante / operatore
|
EA
|
registrazione
|
4.2.1.4
|
(34).
|
fabbricante / operatore
|
EA
|
disattivazione
|
7.3
|
(35).
|
EA
|
fabbricante / operatore
|
risposta
|
4.2.1.4
|
(36).
|
auditor
|
CA radice
|
relazione
|
8.1
|
(37).
|
tutti
|
CPA
|
richieste di modifica della CP
|
1.5
|
(38).
|
TLM
|
CPA
|
modulo di domanda
|
4.1.2.2
|
(39).
|
CPA
|
TLM
|
approvazione/rifiuto
|
4.1.2.2
|
(40).
|
TLM
|
CPA
|
relazione di audit
|
4.1.2.2
|
Tabella 1:
descrizione dettagliata dei flussi di informazioni in un modello di fiducia C-ITS
1.3.2.Autorità per la politica dei certificati dei C-ITS
(1)L'autorità per la politica dei certificati dei C-ITS (CPA) è costituita dai rappresentanti dei portatori di interessi pubblici e privati (ad esempio gli Stati membri, i costruttori di veicoli, ecc.) che partecipano al modello di fiducia C-ITS. Essa è responsabile di due sottoruoli:
(1)gestione della politica dei certificati, comprendente:
·approvazione della CP attuale e delle future richieste di modifica della CP;
·decisione in merito alla revisione delle richieste di modifica della CP e alle raccomandazioni presentate da altri partecipanti o entità della PKI;
·decisione in merito al rilascio di nuove versioni della CP;
(2)gestione delle autorizzazioni della PKI, comprendente:
·definizione, decisione e pubblicazione delle approvazioni dei CPS e delle procedure di audit della CA (denominate collettivamente "procedure di approvazione CA");
·autorizzazione dei CPOC a svolgere le loro funzioni e riferire regolarmente;
·autorizzazione dei TLM a svolgere le loro funzioni e riferire regolarmente;
·approvazione dei CPS delle CA radice, se in linea con una CP valida e comune;
·esame delle relazioni di audit redatte dall'auditor accreditato della PKI per tutte le CA radice;
·comunicazione ai TLM in merito all'elenco di CA radice approvate o non approvate e dei relativi certificati, in base alle relazioni di approvazione delle CA radice e alle regolari relazioni sulle operazioni ricevute.
(2)Il rappresentante autorizzato della CPA è responsabile dell'autenticazione del rappresentante autorizzato del TLM e dell'approvazione del modulo di domanda per il processo di registrazione dei TLM. La CPA è responsabile dell'autorizzazione dei TLM a svolgere le loro funzioni come indicato nella presente sezione.
1.3.3.Gestore dell'elenco di fiducia
(3)Il TLM è un'entità unica nominata dalla CPA.
(4)Il TLM è responsabile:
·del funzionamento dell'ECTL conformemente a una CP valida comune e delle comunicazioni regolari alla CPA al fine di garantire un funzionamento complessivamente sicuro del modello di fiducia CITS;
·di ricevere i certificati della CA radice dal CPOC;
·di includere i certificati della CA radice nell'ECTL o di escluderli dallo stesso previa notifica della CPA;
·di firmare l'ECTL;
·della trasmissione regolare e tempestiva dell'ECTL al CPOC.
1.3.4.Auditor accreditato della PKI
(5)L'auditor accreditato della PKI è responsabile:
·dell'esecuzione e dell'organizzazione degli audit delle CA radice, dei TLM e delle subCA;
·della distribuzione delle relazione di audit (risultante da audit iniziali o periodici) alla CPA in linea con i requisiti di cui alla successiva sezione 8. La relazione di audit deve includere le raccomandazioni dell'auditor accreditato della PKI;
·della notifica all'entità che gestisce la CA radice dell'esecuzione, andata a buon fine o no, dell'audit iniziale o periodico delle subCA;
·della valutazione della conformità dei CPS alla presente CP.
1.3.5.Punto di contatto C-ITS (CPOC)
(6)Il CPOC è un'entità unica nominata dalla CPA. Il rappresentante autorizzato della CPA è responsabile dell'autenticazione del rappresentante autorizzato del CPOC e dell'approvazione del modulo di domanda per il processo di registrazione del CPOC. La CPA è responsabile dell'autorizzazione dei CPOC a svolgere le loro funzioni come indicato nella presente sezione.
(7)Il CPOC è responsabile:
·di istituire uno scambio di comunicazioni sicuro tra tutte le entità del modello di fiducia C-ITS, e di contribuire allo stesso, in modo efficiente e veloce;
·di rivedere le richieste di modifica della procedura e le raccomandazioni presentate da altri partecipanti al modello di fiducia (ad es. le CA radice);
·di trasmettere i certificati della CA radice al TLM;
·di pubblicare il trust anchor comune (chiave pubblica attuale e certificato di collegamento del TLM);
·di pubblicare l'ECTL.
Informazioni dettagliate complete relative all'ECTL sono reperibili nella sezione 7.
1.3.6.Ruoli operativi
(8)Le seguenti entità definite al riferimento [2] svolgono un ruolo operativo, come definito nella norma RFC 3647.
Elemento funzionale
|
Ruolo della PKI (riferimenti [3] e [4])
|
Ruolo dettagliato (riferimento [2])
|
autorità di certificazione radice
|
CA/RA (autorità di registrazione)
|
Fornire a EA e AA la prova della loro facoltà di rilascio di EC o AT
|
autorità per le registrazioni
|
sottoscrittore della CA radice / soggetto a certificato della EA
CA/RA
|
Autenticare la stazione C-ITS e consentire l'accesso alle sue comunicazioni ITS
|
autorità di autorizzazione
|
sottoscrittore della CA radice / soggetto a certificato della AA
CA/RA
|
Fornire alla stazione C-ITS la prova autorevole della sua facoltà di utilizzare servizi ITS specifici
|
stazione C-ITS emittente
|
soggetta al certificato (EC) di un'entità finale (EE)
|
Acquisire i diritti dall'EA per accedere alle comunicazioni ITS.
Negoziare i diritti ottenuti dall'AA per invocare i servizi ITS.
Inviare messaggi di broadcast single-hop e ritrasmessi
|
stazione C-ITS di ritrasmissione (inoltro)
|
parte incaricata della ritrasmissione / soggetta al certificato dell'EE
|
Ricevere messaggi di broadcast dalle stazioni C-ITS emittenti e inoltrarli alle stazioni C-ITS riceventi se necessario
|
stazione C-ITS ricevente
|
parte di ritrasmissione
|
Ricevere messaggi di broadcast dalle stazioni C-ITS emittenti o di ritrasmissione
|
fabbricante
|
sottoscrittore dell'EA
|
Installare in fase di produzione le informazioni necessarie per la gestione della sicurezza nella stazione C-ITS
|
operatore
|
sottoscrittore dell'EA/AA
|
Installare e aggiornare durante il funzionamento le informazioni necessarie per la gestione della sicurezza nella stazione C-ITS
|
Tabella 2: ruoli operativi
Nota: conformemente al riferimento [4], nella presente CP sono usati diversi termini per "sottoscrittore", il quale stipula un contratto con la CA per il rilascio di certificati, e "soggetto", cui si applica il certificato. I sottoscrittori sono tutte le entità che hanno un rapporto contrattuale con una CA. I soggetti sono entità cui si applica il certificato. Le EA/AA sono sottoscrittori e soggetti della CA radice e possono richiedere certificati delle EA/AA. Le stazioni CITS sono soggetti e possono richiedere certificati delle entità finali.
(9)Autorità di registrazione
La EA deve svolgere il ruolo di autorità di registrazione per le entità finali. Solo un sottoscrittore autorizzato e autenticato può registrare nuove entità finali (stazioni C-ITS) nella EA. Le CA radice pertinenti devono svolgere il ruolo di autorità di registrazione per le EA e le AA.
1.4.Uso dei certificati
1.4.1.Domini d'uso applicabili
(10)I certificati rilasciati nell'ambito della presente CP sono destinati a essere utilizzati per convalidare le firme digitali nel contesto della comunicazione ITS cooperativa in conformità all'architettura di riferimento di cui al riferimento [2].
(11)I profili dei certificati di cui al riferimento [5] determinano l'uso dei certificati per TLM, CA radice, EA, AA e entità finali.
1.4.2.Limiti di responsabilità
(12)I certificati non sono destinati, né autorizzati, all'uso:
·in circostanze che violano qualsiasi legislazione, regolamento (ad es. il GDPR), decreto o ordinanza governativa applicabile o contravvengono agli stessi;
·in circostanze che calpestano i diritti degli altri o contravvengono agli stessi;
·in violazione della presente CP o dell'accordo di sottoscrizione pertinente;
·in circostanze in cui il loro uso potrebbe portare direttamente alla morte, a lesioni personali o a gravi danni ambientali (ad esempio guasti al funzionamento di impianti nucleari, alla comunicazione o alla navigazione aerea, o ai sistemi di controllo delle armi);
·in circostanze che contravvengono agli obiettivi complessivi di maggiore sicurezza stradale e di trasporto su strada più efficiente in Europa.
1.5.Amministrazione della politica dei certificati
1.5.1.Aggiornamento dei CPS di CA figuranti nell'ECTL
(13)Ciascuna CA radice figurante nell'ECTL deve pubblicare il proprio CPS che deve essere conforme alla presente politica. Una CA radice può aggiungere requisiti supplementari, ma deve garantire che tutti i requisiti della presente CP siano rispettati in ogni momento.
(14)Ciascuna CA radice figurante nell'ECTL deve attuare un adeguato processo di modifica del suo documento CPS. Le proprietà principali del processo di modifica devono essere documentate nella parte pubblica del CPS.
(15)Il processo di modifica deve garantire che tutte le modifiche della presente CP siano analizzate attentamente e, se necessario per la conformità alla CP modificata, che il CPS sia aggiornato entro il periodo di tempo stabilito nella fase di attuazione del processo di modifica della CP. In particolare il processo di modifica deve comprendere procedure di modifica di emergenza che garantiscano una tempestiva attuazione delle modifiche della CP pertinenti per la sicurezza.
(16)Il processo di modifica deve comprendere misure appropriate per verificare la conformità alla CP di tutte le modifiche del CPS. Qualsiasi modifica del CPS deve essere chiaramente documentata. Prima dell'implementazione di una nuova versione del CPS, un auditor accreditato della PKI deve confermarne la conformità alla CP.
(17)La CA radice deve notificare alla CPA qualsiasi modifica apportata al CPS indicando almeno le seguenti informazioni:
·una descrizione esatta della modifica;
·la logica alla base della modifica;
·una relazione dell'auditor accreditato della PKI che ne confermi la conformità alla CP;
·i dati di contatto della persona responsabile del CPS;
·il calendario previsto per l'attuazione.
1.5.2.Procedure di approvazione del CPS
(18)Prima dell'avvio delle sue operazioni, la futura CA radice deve presentare il proprio CPS a un auditor accreditato della PKI nell'ambito di un ordine di audit della conformità (flow 13) e alla CPA per approvazione (flusso 15).
(19)Una CA radice deve presentare le modifiche del proprio CPS a un auditor accreditato della PKI nell'ambito di un ordine di audit della conformità (flow 13) e alla CPA per approvazione (flusso 15) prima che tali modifiche diventino effettive.
(20)Una EA/AA deve presentare il proprio CPS o le modifiche dello stesso alla CA radice. La CA radice può ordinare un certificato di conformità all'organismo nazionale o all'entità privata responsabile dell'approvazione dell'EA/AA, come definito nelle sezioni 4.1.2 e 8.
(21)L'auditor accreditato della PKI deve valutare il CPS conformemente alla sezione 8.
(22)L'auditor accreditato della PKI deve comunicare i risultati della valutazione del CPS nell'ambito della relazione di audit, di cui alla sezione 8.1. Il CPS deve essere accettato o rifiutato nell'ambito dell'accettazione della relazione di audit di cui alle sezioni 8.5 e 8.6.
2.Responsabilità delle pubblicazioni e del repository
2.1.Metodi per la pubblicazione delle informazioni sui certificati
(23)A norma della sezione 2.5 le informazioni sui certificati possono essere pubblicate:
·in modo regolare o periodico; o
·in seguito a una richiesta da parte delle entità partecipanti.
In ogni caso alla pubblicazione sono assegnati diversi gradi di urgenza e quindi si applicano tempistiche diverse, ma le entità devono essere pronte per entrambe le modalità.
(24)La pubblicazione regolare delle informazioni sui certificati consente di stabilire un termine massimo entro il quale tali informazioni devono essere aggiornate per tutti i nodi della rete C-ITS. La frequenza di pubblicazione di tutte le informazioni sui certificati è stabilita nella sezione 2.2.
(25)Su richiesta delle entità partecipanti alla rete C-ITS, ogni partecipante può cominciare a pubblicare informazioni sui certificati in qualsiasi momento e, a seconda del suo status, richiedere la serie attuale di informazioni sui certificati, in modo da diventare un nodo completamente fidato della rete C-ITS. Lo scopo di tale pubblicazione è principalmente di aggiornare le entità sullo stato attuale delle informazioni sui certificati nella rete e consentire loro di comunicare in modo fidato fino alla successiva pubblicazione regolare di informazioni.
(26)Anche una sola CA radice può avviare la pubblicazione delle informazioni sui certificati in qualsiasi momento inviando una serie di certificati aggiornata a tutti i "membri iscritti" della rete C-ITS, che sono destinatari regolari di tali informazioni. Ciò sostiene il funzionamento delle CA e consente loro di rivolgersi ai membri della rete nei periodi che intercorrono tra le date regolari o programmate di pubblicazione dei certificati.
(27)La sezione 2.5 stabilisce il meccanismo e tutte le procedure per la pubblicazione dei certificati della CA radice e dell'ECTL.
(28)Il CPOC deve pubblicare i certificati della CA radice (come inclusi nell'ECTL e destinati all'uso pubblico), il certificato del TLM e l'ECTL da esso stesso rilasciata.
(29)Le CA radice devono pubblicare i certificati delle loro EA/AA e le CRL, ed essere in grado di supportare tutti e tre i meccanismi qui indicati per la loro pubblicazione indirizzata ai membri sottoscrittori e alle relying parties, adottando tutte le misure necessarie per garantire una trasmissione sicura, come indicato nella sezione 4.
2.2.Tempo o frequenza di pubblicazione
(30)I requisiti riguardanti la tempistica della pubblicazione dei certificati e delle CRL devono essere determinati alla luce di diversi fattori di limitazione dei singoli nodi C-ITS, con l'obiettivo generale di gestire una "rete fidata" e pubblicare gli aggiornamenti il più rapidamente possibile in tutte le stazioni C-ITS coinvolte.
·Per la pubblicazione regolare di informazioni aggiornate sui certificati (ad esempio le modifiche della composizione dell'ECTL o della CRL), è necessario un periodo massimo di tre mesi per il funzionamento sicuro della rete C-ITS.
·Le CA radice devono pubblicare i loro certificati e le CRL nel più breve tempo possibile successivo al rilascio.
·Per la pubblicazione della CRL deve essere usato il repository della CA radice.
Inoltre il CPS di ciascuna CA deve specificare entro quanto tempo un certificato sarà pubblicato in seguito al suo rilascio da parte della CA.
La presente sezione specifica unicamente il tempo o la frequenza della pubblicazione regolare. Devono essere implementati mezzi di connettività in conformità ai requisiti del presente del documento al fine di aggiornare le stazioni C-ITS coi più recenti ECTL e CRL entro una settimana dalla pubblicazione di questi ultimi (in normali condizioni di funzionamento, ad esempio in presenza di copertura della rete cellulare, col veicolo effettivamente in funzione, ecc.)
2.3.Repository
(31)Per le singole entità i requisiti relativi alla struttura del repository per la conservazione dei certificati e alle informazioni da fornire alle entità della rete C-ITS sono i seguenti:
·al fine di pubblicare i certificati per gli altri partecipanti alla PKI (ad esempio un servizio di directory basato su LDAP) ciascuna CA radice dovrebbe in generale utilizzare un repository delle proprie informazioni sui certificati della EA/AA e della CRL attualmente attivi. Il repository di ciascuna CA radice deve supportare tutti i necessari controlli degli accessi (sezione 2.4) e i tempi di trasmissione (sezione 2.2) per tutti i metodi di distribuzione delle informazioni relative ai C-ITS;
·il repository del TLM (in cui ad esempio sono conservati i certificati dell'ECTL e del TLM pubblicati dal CPOC) dovrebbe basarsi su un meccanismo di pubblicazione in grado di garantire i tempi di trasmissione di cui alla sezione 2.2 per ogni metodo di distribuzione.
Non sono definiti i requisiti delle AA, ma questi devono supportare gli stessi livelli di sicurezza delle altre entità, che devono essere dichiarati nel loro CPS.
2.4.Controlli degli accessi ai repository
(32)I requisiti relativi al controllo degli accessi ai repository delle informazioni sui certificati devono essere conformi almeno alle norme generali sul trattamento sicuro delle informazioni, di cui alla norma ISO/IEC 27001, e ai requisiti di cui alla sezione 4. Inoltre devono rispecchiare le esigenze di sicurezza del processo da stabilire per le singole fasi del processo nella pubblicazione delle informazioni sui certificati.
·Ciò comprende l'implementazione presso il TLM/CPOC del repository per i certificati del TLM e l'ECTL. Ciascuna CA o operatore del repository deve implementare i controlli degli accessi relativi a tutte le entità del C-ITS e alle parti esterne per almeno tre diversi livelli (ad esempio livello pubblico, livello limitato alle entità del C-ITS, livello della CA radice) al fine di evitare che entità non autorizzate possano aggiungere, modificare o cancellare delle voci del repository.
·I meccanismi esatti di controllo degli accessi della singola entità devono essere inclusi nei rispettivi CPS.
·Per ciascuna CA radice, i repository dell'EA e dell'AA devono essere conformi agli stessi requisiti per le procedure di controllo degli accessi, indipendentemente dal luogo o dal legame contrattuale con il prestatore di servizi che gestisce il repository.
Ciascuna CA radice o operatore del repository dovrebbe fornire almeno tre livelli diversi come punto di partenza per i livelli di controllo degli accessi (ad esempio livello pubblico, livello limitato alle entità del C-ITS, livello della CA radice).
2.5.Pubblicazione delle informazioni sui certificati
2.5.1.Pubblicazione delle informazioni sui certificati da parte del TLM
(33)Il TLM del dominio di fiducia comune europeo dei C-ITS deve pubblicare le seguenti informazioni attraverso il CPOC:
·tutti i certificati del TLM attualmente validi per il successivo periodo di funzionamento (il certificato attuale e il certificato di collegamento, se disponibile);
·le informazioni sul punto di accesso per il repository del CPOC al fine di fornire l'elenco firmato delle CA radice (ECTL);
·il punto di informazione generale per l'ECTL e la diffusione dei sistemi C-ITS.
2.5.2.Pubblicazione delle informazioni sui certificati da parte delle CA
(34)Le CA radice del dominio di fiducia comune europeo dei C-ITS devono pubblicare le seguenti informazioni:
·i certificati rilasciati (attualmente validi) delle CA radice (certificati attuali e sottoposti correttamente a re-keying, compresi i certificati di collegamento) contenuti nel repository di cui alla sezione 2.3;
·tutte le entità valide di EA e AA, con i rispettivo ID operatore e periodo di funzionamento previsto;
·i certificati delle CA rilasciati e contenuti nei repository di cui alla sezione 2.3;
·le CRL per tutti i certificati revocati delle CA riguardanti le rispettive EA e AA subordinate;
·le informazioni riguardanti il punto di accesso della CA radice alla CRL e alle informazioni sulle CA.
Tutte le informazioni sui certificati devono essere suddivise in categorie in conformità ai tre livelli di riservatezza e i documenti per il pubblico devono essere accessibili senza restrizioni.
3.Identificazione e autenticazione
3.1.Assegnazione dei nomi
3.1.1.Tipi di nome
3.1.1.1.Nomi per TLM, CA radice, EA e AA
(35)Il nome nel certificato del TLM deve essere costituito da un unico attributo subject_name col valore riservato "EU_TLM".
(36)Il nome delle CA radice deve essere costituito da un unico attributo subject_name con un valore assegnato dalla CPA. L'unicità dei nomi è di esclusiva responsabilità della CPA e il TLM deve aggiornare il registro dei nomi delle CA radice in seguito a notifica da parte della CPA (approvazione, revoca o cancellazione di una CA radice). La dimensione dei subject_name dei certificati è limitata a 32 bytes. Ciascuna CA radice propone il proprio nome alla CPA nel modulo di domanda (flusso 14). La CPA è responsabile della verifica dell'unicità dei nomi. Se il nome non è unico, il modulo di domanda viene rifiutato (flusso 4).
(37)Il nome in ciascun certificato della EA/AA può essere costituito da un unico attributo subject_name con un valore generato da chi rilascia il certificato. L'unicità dei nomi è di esclusiva responsabilità della CA radice che rilascia il certificato.
(38)La dimensione dei subject_name dei certificati è limitata a 32 bytes, per cui i certificati delle EA e AA non possono utilizzare nomi di lunghezza superiore a 32 byte.
(39)Gli AT non devono contenere nomi.
3.1.1.2.Nomi per le entità finali
(40)A ciascuna stazione C-ITS devono essere assegnati due tipi di identificativi unici:
·un ID canonico memorizzato nel corso della registrazione iniziale della stazione C-ITS sotto la responsabilità del fabbricante, che deve contenere una sottostringa che identifichi il fabbricante o l'operatore in modo che tale identificativo possa essere unico;
·un subject_name, che può essere contenuto nelle EC della stazione C-ITS, sotto la responsabilità dell'EA.
3.1.1.3.Identificazione dei certificati
(41)I certificati basati sul formato di cui al riferimento [5] devono essere identificati calcolando un valore HashedId8 come definito al riferimento [5].
3.1.2.Necessità di nomi significativi
Nessuna disposizione.
3.1.3.Anonimato e uso di pseudonimi delle entità finali
(42)La AA deve garantire che la stazione C-ITS possa usare uno pseudonimo fornendole AT che non contengono nomi o informazioni che possano collegare il soggetto alla sua reale identità.
3.1.4.Regole per l'interpretazione di varie forme di nomi
Nessuna disposizione.
3.1.5.Unicità dei nomi
(43)I nomi di TLM, CA radice, EA, AA e gli ID canonici delle stazioni C-ITS devono essere unici.
(44)Nel processo di registrazione di una determinata CA radice nell'ECTL, il TLM deve garantire che l'identificativo del certificato (HashedId8) sia unico. Nel processo di rilascio del certificato, la CA radice deve garantire che l'identificativo del certificato (HashedaId8) di ciascuna CA subordinata sia unico.
(45)Nell'ambito della CA di rilascio, il valore HashedId8 delle EC deve essere unico. Non è necessario che il valore HashedId8 di un AT sia unico.
3.2.Convalida dell'identità iniziale
3.2.1.Metodo per dimostrare il possesso di una chiave privata
(46)La CA radice deve dimostrare di detenere legittimamente la chiave privata corrispondente alla chiave pubblica del certificato autofirmato. Il CPOC deve verificare questa dimostrazione.
(47)La EA/AA deve dimostrare di detenere legittimamente la chiave privata corrispondente alla chiave pubblica da indicare nel certificato. La CA radice deve verificare questa dimostrazione.
(48)Il possesso di una nuova chiave privata (ai fini del re-keying) deve essere dimostrato mediante la firma della richiesta di una nuova chiave privata (firma interna), seguita dalla generazione di una firma esterna sulla richiesta firmata con la chiave privata attualmente valida (al fine di garantire l'autenticità della richiesta). La richiesta di certificato firmata deve essere presentata dal richiedente alla CA di rilascio mediante una comunicazione sicura. La CA di rilascio deve verificare che la firma digitale del richiedente sul messaggio di richiesta sia stata creata usando la chiave privata corrispondente alla chiave pubblica allegata alla richiesta di certificato. La CA radice deve specificare nel proprio CPS quale richiesta di certificato e quali risposte sono supportate.
3.2.2.Autenticazione dell'identità dell'organizzazione
3.2.2.1.Autenticazione dell'identità dell'organizzazione della CA radice
(49)In un modulo di domanda destinato alla CPA (vale a dire il flusso 14), la CA radice deve fornire l'identità dell'organizzazione e le informazioni di registrazione, costituite da:
·nome dell'organizzazione;
·indirizzo postale;
·indirizzo e-mail;
·nome di una persona fisica di contatto all'interno dell'organizzazione;
·numero di telefono;
·impronta digitale (vale a dire il valore hash SHA 256) del certificato della CA radice in forma stampata;
·informazioni crittografiche (cioè algoritmi crittografici, lunghezza delle chiavi) contenute nel certificato della CA radice;
·tutti i permessi che la CA radice può usare e passare alle subCA.
(50)La CPA deve verificare l'identità dell'organizzazione e altre informazioni di registrazione fornite dal richiedente del certificato per l'inserimento di un certificato della CA radice nell'ECTL.
(51)La CPA deve raccogliere una prova diretta, o un'attestazione proveniente da una fonte adeguata e autorizzata, relativa all'identità (ad esempio il nome) e, se del caso, a qualsiasi attributo specifico dei soggetti cui è rilasciato un certificato. Le prove presentate possono essere costituite da documentazione elettronica o cartacea.
(52)L'identità del soggetto deve essere verificata al momento della registrazione mediante mezzi appropriati e conformemente alla presente politica dei certificati.
(53)Per ciascuna domanda di certificato devono essere fornite prove relative:
·al nome completo dell'entità organizzativa (organizzazione privata, entità governativa o entità non-commerciale);
·alla registrazione riconosciuta a livello nazionale o ad altri attributi che possono essere utilizzati, per quanto possibile, per distinguere l'entità organizzativa da altre con lo stesso nome.
Le regole di cui sopra si basano sulla norma TS 102 042 [4], che stabilisce che la CA deve garantire che le prove relative all'identificazione del sottoscrittore e del soggetto e l'accuratezza dei loro nomi e dei dati associati siano adeguatamente esaminate nell'ambito del servizio definito o, se del caso, definite mediante l'esame di attestazioni provenienti da fonti adeguate e autorizzate, e che le richieste di certificati siano accurate, autorizzate e complete, in conformità alle prove o alle attestazioni raccolte.
3.2.2.2.Autenticazione dell'identità dell'organizzazione del TLM
(54)L'organizzazione che gestisce il TLM deve fornire prove dell'identificazione e dell'accuratezza del nome e dei dati associati al fine di consentire un'adeguata verifica in fase di creazione iniziale o di re-keying del certificato del TLM.
(55)L'identità del soggetto deve essere verificata al momento della creazione o del rekeying del certificato mediante mezzi appropriati e conformemente alla presente CP.
(56)Le prove relative all'organizzazione devono essere fornite come specificato nella sezione 3.2.2.1.
3.2.2.3.Autenticazione dell'identità dell'organizzazione delle subCA
(57)La CA radice deve verificare l'identità dell'organizzazione e le altre informazioni di registrazione fornite dai richiedenti dei certificati delle subCA (EA/AA).
(58)La CA radice deve almeno:
·accertare l'esistenza dell'organizzazione utilizzando almeno una banca dati o un servizio comprovante l'identità gestito da terzi o, in alternativa, la documentazione dell'organizzazione rilasciata o presentata dalla pertinente agenzia governativa o autorità riconosciuta che confermi l'esistenza dell'organizzazione;
·utilizzare il servizio postale o una procedura analoga in cui si richieda al richiedente del certificato di confermare determinate informazioni relative all'organizzazione, di aver autorizzato la domanda di certificato e di aver autorizzato la persona che ha presentato la domanda a suo nome ad agire in tal senso. Qualora il certificato includa il nome di una persona fisica in quanto rappresentante autorizzato dell'organizzazione, il richiedente del certificato deve inoltre confermare di aver autorizzato tale persona fisica ad agire a suo nome e che tale persona è impiegata all'interno dell'organizzazione.
(59)Le procedure di convalida per il rilascio dei certificati delle CA devono essere documentate in un CPS della CA radice.
3.2.2.4.Autenticazione dell'organizzazione del sottoscrittore delle entità finali
(60)Prima che il sottoscrittore delle entità finali (il fabbricante o l'operatore) possa registrarsi con una EA fidata per abilitare le sue entità finali all'invio di richieste di certificati delle EC, la EA deve:
·verificare l'identità dell'organizzazione del sottoscrittore e le altre informazioni di registrazione fornite dal richiedente del certificato;
·verificare che il tipo di stazione C-ITS (vale a dire il prodotto concreto individuato in base alla marca, al modello e alla versione della stazione C-ITS) soddisfi tutti i criteri di valutazione della conformità.
(61)La EA deve almeno:
·accertare l'esistenza dell'organizzazione utilizzando almeno una banca dati o un servizio comprovante l'identità gestito da terzi o, in alternativa, la documentazione dell'organizzazione rilasciata o presentata dalla pertinente agenzia governativa o autorità riconosciuta che confermi l'esistenza dell'organizzazione;
·utilizzare il servizio postale o una procedura analoga in cui si richieda al richiedente del certificato di confermare determinate informazioni relative all'organizzazione, di aver autorizzato la domanda di certificato e di aver autorizzato la persona che ha presentato la domanda a suo nome. Qualora il certificato includa il nome di una persona fisica in quanto rappresentante autorizzato dell'organizzazione, il richiedente del certificato deve inoltre confermare di aver autorizzato tale persona fisica ad agire a suo nome e che tale persona è impiegata all'interno dell'organizzazione.
(62)Le procedure di convalida per la registrazione di una stazione C-ITS da parte del suo sottoscrittore devono essere documentate in un CPS dell'EA.
3.2.3.Autenticazione di un'entità individuale
3.2.3.1.Autenticazione di un'entità individuale TLM/CA
(63)Per l'autenticazione di un'entità individuale (persona fisica) identificata in associazione con una persona giuridica o entità organizzativa (ad esempio il sottoscrittore) devono essere fornite prove relative:
·al nome completo del soggetto (comprendente nome/i e cognome, in linea con il diritto applicabile e le pratiche nazionali di identificazione);
·alla data e al luogo di nascita, con riferimento a un documento di identità riconosciuto a livello nazionale o ad altri attributi del sottoscrittore che possono essere utilizzati, per quanto possibile, per distinguere la persona da altre con lo stesso nome;
·al nome completo e allo status giuridico della persona giuridica associata o altra entità organizzativa associata (ad esempio il sottoscrittore);
·a qualsiasi pertinente informazione di registrazione (ad esempio la registrazione della società) della persona giuridica o altra entità organizzativa associata;
·all'associazione del soggetto alla persona giuridica o altra entità organizzativa associata.
Le prove presentate possono essere costituite da documentazione elettronica o cartacea.
(64)Ai fini della verifica della propria identità, il rappresentante autorizzato di una CA radice, una EA, una AA o un sottoscrittore deve presentare documenti che attestino il suo impiego presso l'organizzazione (certificato di autorizzazione) e deve inoltre presentare un documento d'identità ufficiale.
(65)Per il processo iniziale di registrazione (flusso 31/32), il rappresentante della EA/AA deve fornire alla CA radice corrispondente tutte le informazioni necessarie (cfr. la sezione 4.1.2).
(66)Il personale della CA radice deve verificare l'identità del rappresentante del richiedente del certificato e tutti i documenti associati, applicando i requisiti relativi al "personale di fiducia" di cui alla sezione 5.2.1. (Il processo di convalida delle informazioni della domanda e il processo di generazione del certificato da parte della CA radice devono essere eseguiti da "persone di fiducia" della CA radice, con almeno una doppia supervisione, poiché si tratta di operazioni sensibili ai sensi della sezione 5.2.2).
3.2.3.2.Autenticazione dell'identità dei sottoscrittori delle stazioni C-ITS
(67)I sottoscrittori sono rappresentati da utenti finali autorizzati appartenenti all'organizzazione e registrati presso le EA e AA di rilascio. Tali utenti finali designati dalle organizzazioni (fabbricanti o operatori) devono dimostrare la loro identità e autenticità prima di:
·registrare la EE presso la sua corrispondente EA, compresa la sua chiave pubblica canonica, il suo ID canonico (identificativo unico) e i permessi in conformità alla EE;
·registrarsi presso la AA e rendere sicura la prova di un accordo di sottoscrizione che può essere inviato all'EA.
3.2.3.3.Autenticazione dell'identità delle stazioni C-ITS
(68)I soggetti EE delle EC devono autenticarsi al momento della richiesta delle EC (flusso 31) usando la chiave privata canonica per l'autenticazione iniziale. La EA deve verificare l'autenticazione utilizzando la chiave pubblica canonica corrispondente alla EE. Le chiavi pubbliche canoniche della EE sono fatte pervenire all'EA prima dell'esecuzione della richiesta iniziale mediante un canale sicuro tra il fabbricante o l'operatore della stazione C-ITS e l'EA (flusso 33).
(69)I soggetti EE degli AT devono autenticarsi al momento della richiesta degli AT (flusso 32) usando la chiave privata unica di registrazione. La AA deve inoltrare la firma alla EA (flusso 25) per la convalida; la EA deve convalidarla e confermarne il risultato alla AA (flusso 23).
3.2.4.Informazioni non verificate relative al sottoscrittore
Nessuna disposizione.
3.2.5.Convalida dell'autorità
3.2.5.1.Convalida di TLM, CA radice, EA e AA
(70)Ogni organizzazione deve indicare nel CPS almeno un rappresentante (ad esempio un responsabile della sicurezza) incaricato di richiedere nuovi certificati e rinnovi. Si applicano le regole in materia di assegnazione dei nomi di cui alla sezione 3.2.3.
3.2.5.2.Convalida dei sottoscrittori di stazioni C-ITS
(71)Almeno una persona fisica responsabile per la registrazione delle stazioni C-ITS presso una EA (ad esempio il responsabile della sicurezza) deve essere noto alla EA e approvato dalla stessa (cfr. sezione 3.2.3).
3.2.5.3.Convalida delle stazioni C-ITS
(72)Un sottoscrittore di una stazione C-ITS può registrare le stazioni C-ITS presso una EA specifica (flusso 33) a condizione che sia autenticato presso tale EA.
Qualora la stazione C-ITS sia registrata presso una EA con un ID canonico unico e una chiave pubblica canonica, il sottoscrittore può richiedere le EC mediante una richiesta firmata con la chiave privata canonica relativa alla chiave pubblica canonica precedentemente registrata.
3.2.6.Criteri per l'interoperabilità
(73)Per la comunicazione tra le stazioni C-ITS e le EA (o AA), le stazioni C-ITS devono essere in grado di stabilire comunicazioni sicure con le EA (o AA), vale a dire di implementare funzioni di autenticazione, riservatezza e integrità, come specificato al riferimento [1]. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1]. EA e AA devono supportare tale comunicazione sicura.
(74)EA e AA devono supportare richieste e risposte di certificati che sono conformi al riferimento [1], che prevede un protocollo sicuro di richiesta/risposta di AT che supporti l'anonimato del richiedente rispetto alla AA e la separazione delle funzioni tra la AA e la EA. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1]. Per evitare di divulgare le identità di lungo termine delle stazioni C-ITS, la comunicazione tra una stazione mobile C-ITS e una EA deve essere riservata (ad esempio i dati di comunicazione devono essere cifrati end-to-end).
(75)La AA deve presentare una richiesta di convalida dell'autorizzazione (flusso 25) per ciascuna richiesta di autorizzazione che riceve da un soggetto del certificato dell'EE. La EA deve convalidare tale richiesta per quanto riguarda:
·lo status della EE presso la EA;
·la validità della firma;
·i permessi e gli ID delle domande ITS (ITS-AID) richiesti;
·lo status di prestazione del servizio della AA al sottoscrittore.
3.3.Identificazione e autenticazione per le richieste di re-keying
3.3.1.Identificazione e autenticazione per le richieste di re-keying di routine
3.3.1.1.Certificati del TLM
(76)Il TLM genera una coppia di chiavi e due certificati: uno autofirmato e un certificato di collegamento di cui alla sezione 7.
3.3.1.2.Certificati della CA radice
Non pertinente.
3.3.1.3.Rinnovo o re-keying del certificato della EA/AA
(77)Prima della scadenza di un certificato della EA/AA, quest'ultima deve richiedere un nuovo certificato (flusso 21/flusso 24) per mantenere la continuità di utilizzo dei certificati. La EA/AA deve generare una nuova coppia di chiavi per sostituire quella in scadenza e firmare la richiesta di riassegnazione contenente la nuova chiave pubblica con la chiave privata attualmente valida ("rekeying"). La EA o AA genera una nuova coppia di chiavi e firma la richiesta con la nuova chiave privata (firma interna) per dimostrare il possesso della stessa. L'intera richiesta è firmata (oversigned) con la chiave privata attualmente valida (firma esterna) al fine di garantire l'integrità e l'autenticità della richiesta. Qualora venga usata una coppia di chiavi di cifratura e decifratura, il possesso delle chiavi private di decifratura deve essere dimostrato (per una descrizione dettagliata del re-keying cfr. la sezione 4.7.3.3)
(78)Il metodo di identificazione e di autenticazione per il re-keying di routine è lo stesso di quello utilizzato nel rilascio iniziale della convalida iniziale del certificato della CA radice, come indicato nella sezione 3.2.2.
3.3.1.4.Credenziali di registrazione delle entità finali
(79)Prima della scadenza delle EC esistenti, la EE deve richiedere un nuovo certificato (flusso 31) per mantenere la continuità di utilizzo dei certificati. La EE deve generare una nuova coppia di chiavi per sostituire quella in scadenza e richiedere un nuovo certificato contenente la nuova chiave pubblica; la richiesta deve essere firmata con la chiave privata delle EC attualmente valida.
(80)La EE può firmare la richiesta con la chiave privata appena creata (firma interna) per dimostrare il possesso della nuova chiave privata. L'intera richiesta è quindi firmata (oversigned) con la chiave privata attualmente valida (firma esterna) e cifrata per l'EA ricevente come specificato al riferimento [1], al fine di garantire la riservatezza, l'integrità e l'autenticità della richiesta. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1].
3.3.1.5.Ticket di autorizzazione delle entità finali
(81)Il re-keying dei certificati degli AT si basa sullo stesso processo dell'autorizzazione iniziale, come definito al riferimento [1]. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1].
3.3.2.Identificazione e autenticazione per le richieste di re-keying dopo la revoca
3.3.2.1.Certificati della CA
(82)L'autenticazione di un'organizzazione della CA per il rekeying dei certificati della CA radice, della EA e della AA dopo la revoca è gestita nello stesso modo del rilascio iniziale di un certificato della CA, come indicato nella sezione 3.2.2.
3.3.2.2.Credenziali di registrazione delle entità finali
(83)L'autenticazione di un re-keying dei certificati delle CE per la EE dopo la revoca è gestita nello stesso modo del rilascio iniziale di un certificato della EE, come indicato nella sezione 3.2.2.
3.3.2.3.Richieste di autorizzazione delle entità finali
Non pertinente, poiché gli AT non sono revocati.
3.4.Identificazione e autenticazione per le richieste di revoca
3.4.1.Certificati di CA radice/EA/AA
(84)Le richieste di cancellazione di un certificato della CA radice da un ECTL devono essere autenticate dalla CA radice al TLM (flussi 12 e 9). Le richieste di revoca di un certificato della EA/AA devono essere autenticate dalla CA radice pertinente e dalla subCA stessa.
(85)Le procedure accettabili per l'autenticazione delle richieste di revoca di un sottoscrittore includono:
·un messaggio scritto e firmato su carta intestata del sottoscrittore che richiede la revoca, con riferimento al certificato da revocare;
·una comunicazione del sottoscrittore che fornisce garanzie ragionevoli che la persona o l'organizzazione che richiede la revoca è realmente il sottoscrittore. A seconda delle circostanze tale comunicazione può essere effettuata tramite uno o più dei seguenti servizi: e-mail, servizi postali, corriere.
3.4.2.Credenziali di registrazione della stazione C-ITS
(86)Il sottoscrittore della stazione C-ITS può revocare le EC di una stazione CITS precedentemente registrata presso una EA (flusso 34). Il sottoscrittore richiedente deve creare una richiesta di revoca per una data stazione C-ITS o un elenco di stazioni C-ITS. La EA deve autenticare la richiesta di revoca prima di trattarla e confermare la revoca delle stazioni C-ITS e delle loro EC.
(87)La EA può revocare le EC di una stazione C-ITS conformemente alla sezione 7.3.
3.4.3.Ticket di autorizzazione della stazione C-ITS
(88)Poiché gli AT non vengono revocati, la loro validità deve essere limitata a un periodo specifico. L'intervallo di periodi di validità accettabili nella presente politica dei certificati è specificato nella sezione 7.
4.Requisiti operativi per il ciclo di vita dei certificati
4.1.Domanda di certificato
(89)La presente sezione stabilisce i requisiti per la domanda iniziale di rilascio di un certificato.
(90)Il termine "domanda di certificato" si riferisce ai seguenti processi:
·registrazione e istituzione di un rapporto di fiducia tra il TLM e la CPA;
·registrazione e istituzione di un rapporto di fiducia tra la CA radice, la CPA e il TLM, compreso l'inserimento del primo certificato della CA radice nell'ECTL;
·registrazione e istituzione di un rapporto di fiducia tra la AA/EA e la CA radice, compreso il rilascio di un nuovo certificato della EA/AA;
·registrazione della stazione C-ITS presso la EA da parte del fabbricante/operatore;
·richiesta della stazione C-ITS di EC/AT.
4.1.1.Chi può presentare la domanda di certificato
4.1.1.1.CA radice
(91)Le CA radice generano la proprie coppie di chiavi e rilasciano i loro stessi certificati radice. Una CA radice può presentare una domanda di certificato mediante il suo rappresentante designato (flusso 14).
4.1.1.2.TLM
(92)Il TLM genera la propria coppia di chiavi e rilascia i suoi stessi certificati. La creazione iniziale del certificato del TLM deve essere trattata da un rappresentante dell'organizzazione del TLM sotto il controllo della CPA.
4.1.1.3.EA e AA
(93)Un rappresentante autorizzato della EA o della AA può presentare la richiesta di certificato di una subCA (EA e/o AA) al rappresentante autorizzato della CA radice pertinente (flusso 27/28).
4.1.1.4.Stazione C-ITS
(94)I sottoscrittori devono registrare ciascuna stazione C-ITS presso la EA conformemente a quanto indicato nella sezione 3.2.5.3.
(95)Ciascuna stazione C-ITS registrata presso la EA può inviare richieste di EC (flusso 31).
(96)Ciascuna stazione C-ITS può inviare richieste di AT (flusso 32) senza richiedere una qualsiasi interazione con il sottoscrittore. Prima di richiedere un AT, la stazione C-ITS deve essere in possesso di EC.
4.1.2.Processo di registrazione e responsabilità
(97)I permessi per le CA radice e le sub-CA che rilasciano certificati a fini speciali (governativi) (vale a dire stazioni C-ITS fisse o mobili speciali) possono essere concessi solo agli Stati membri in cui le organizzazioni hanno la loro sede.
4.1.2.1.CA radice
(98)Dopo essere state sottoposte ad audit (flusso 13 e 36, sezione 8), le CA radice possono presentare alla CPA domanda di inserimento del/i loro certificato/i nell'ECTL (flusso 14). Il processo di registrazione si basa su un modulo di domanda manuale firmato che deve essere consegnato fisicamente alla CPA dal rappresentante autorizzato della CA radice e che contiene almeno le informazioni di cui alle sezioni 3.2.2.1, 3.2.3 e 3.2.5.1.
(99)Il modulo di domanda della CA radice deve essere firmato dal suo rappresentante autorizzato.
(100)In aggiunta al modulo di domanda, il rappresentante autorizzato della CA radice deve presentare per approvazione alla CPA una copia del CPS della CA radice (flusso 15) e della relazione di audit (flusso 16). Se l'approvazione ha esito positivo, la CPA genera e invia un certificato di conformità al CPOC/TLM e alla CA radice corrispondente.
(101)Il rappresentante autorizzato della CA radice deve quindi presentare al CPOC/TLM il modulo di domanda (contenente l'impronta digitale del certificato autofirmato), l'ID ufficiale e una prova dell'autorizzazione. Il certificato autofirmato deve essere consegnato elettronicamente al CPOC/TLM, che deve sottoporre a verifica il certificato autofirmato stesso e tutti i documenti.
(102)Se le verifiche hanno esito positivo, il TLM deve aggiungere il certificato della CA radice all'ECTL in base alla notifica ricevuta dalla CPA (flussi 1 e 2). Il processo dettagliato è descritto nel CPS del TLM.
(103)Dovrebbe essere prevista una procedura aggiuntiva per ottenere l'approvazione del CPS e la relazione di audit di una CA radice presso organismi nazionali di paesi specifici
4.1.2.2.TLM
(104)Dopo essere stato sottoposto ad audit, il TLM può iscriversi presso la CPA. Il processo di registrazione si basa su un modulo di domanda manuale firmato che deve essere consegnato fisicamente alla CPA (flusso 38) dal rappresentante autorizzato della TLM e che contiene almeno le informazioni di cui alle sezioni 3.2.2.2 e 3.2.3.
(105)Il modulo di domanda della TLM deve essere firmato dal suo rappresentante autorizzato.
(106)In primo luogo il TLM genera il suo certificato autofirmato e lo trasmette in modo sicuro alla CPA. Il TLM presenta quindi alla CPA il modulo di domanda (contenente l'impronta digitale del certificato autofirmato), una copia del suo CPS, un ID ufficiale, una prova dell'autorizzazione e la sua relazione di audit (flusso 40). La CPA deve sottoporre a verifica tutti i documenti e il certificato autofirmato. Se la verifica di tutti i documenti, del certificato autofirmato e dell'impronta digitale ha esito positivo, la CPA deve confermare il processo di registrazione inviando l'approvazione al TLM e al CPOC (flusso 39). Il CPA deve conservare le informazioni della domanda inviate dal TLM. Il certificato del TLM viene quindi rilasciato tramite il CPOC.
4.1.2.3.EA e AA
(107)Nel processo di registrazione, la EA/AA deve presentare i documenti pertinenti (ad esempio il CPS e la relazione di audit) alla corrispondente CA radice per approvazione (flusso 27/28). Se le verifiche dei documenti hanno esito positivo, la CA radice invia un'approvazione alle corrispondenti sub-CA radice (flusso 29/30). La sub-CA (EA o AA) deve quindi trasmettere elettronicamente la sua richiesta firmata e consegnare fisicamente alla corrispondente CA radice il suo modulo di domanda (conformemente alla sezione 3.2.2.1), la prova dell'autorizzazione e un documento di identità. La CA radice verifica la richiesta e i documenti ricevuti (il modulo di domanda contenente l'impronta digitale, vale a dire il valore hash SHA 256 della richiesta della sub-CA, la prova dell'autorizzazione e il documento di identità). Se tutte le verifiche hanno esito positivo, la CA radice rilascia il corrispondente certificato della sub-CA. Informazioni dettagliate sul modo in cui viene effettuata la richiesta iniziale sono descritte nel suo specifico CPS.
(108)In aggiunta al modulo di domanda della sub-CA, il rappresentante autorizzato della sub-CA deve allegare una copia del CPS alla CA radice.
(109)Le informazioni devono essere fornite a un auditor accreditato della PKI per gli audit in conformità alla sezione 8.
(110)Se la sub-CA è di proprietà di un'entità diversa da quella che possiede la CA radice, prima di richiedere il certificato della sub-CA, l'entità della sub-CA deve firmare un contratto relativo al servizio della CA radice.
4.1.2.4.Stazione C-ITS
(111)La registrazione iniziale dei soggetti entità finali (le stazioni C-ITS) deve essere effettuata presso la EA dal sottoscrittore responsabile (fabbricante/operatore) (flussi 33 e 35), dopo l'autenticazione con esito positivo dell'organizzazione del sottoscrittore e di uno dei suoi rappresentanti, in linea con le sezioni 3.2.2.4 e 3.2.5.2.
(112)Una stazione C-ITS può generare una coppia di chiavi delle EC (cfr. la sezione 6.1) e creare una richiesta di EC firmata conformemente al riferimento [1]. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1].
(113)Durante la registrazione di una stazione C-ITS normale (a differenza di una stazione C-ITS fissa o mobile speciale), la EA deve verificare che i permessi nella richiesta iniziale non siano per uso governativo. I permessi per uso governativo sono definiti dai corrispondenti Stati membri. La procedura dettagliata per la registrazione e la risposta dell'EA al fabbricante/operatore (flussi 33 e 35) deve essere stabilita nel corrispondente CPS dell'EA.
(114)Una stazione C-ITS deve essere iscritta presso una EA (sezione 3.2.5.3) inviando la sua richiesta iniziale di EC conformemente al riferimento [1].
(115)A seguito della registrazione iniziale da parte di un rappresentante del sottoscrittore autenticato, la EA definisce quale AT può essere ottenuto dal soggetto entità finale (vale a dire la stazione C-ITS). Inoltre a ciascuna entità finale viene assegnato un livello di garanzia della fiducia (trust assurance level), relativo alla certificazione dell'entità finale conformemente a uno dei profili di protezione di cui alla sezione 6.1.5.2.
(116)I veicoli normali devono disporre di una sola stazione C-ITS registrata presso una EA. I veicoli per uso speciale (quali le automobili della polizia e altri veicoli per uso speciale con diritti specifici) possono essere registrati presso un'ulteriore EA o disporre di una stazione C-ITS aggiuntiva per le autorizzazioni nell'ambito dello scopo speciale. I veicoli cui si applica tale deroga devono essere definiti dallo Stato membro responsabile. I permessi per le stazioni C-ITS fisse o mobili speciali devono essere concessi solo dagli Stati membri responsabili. Il CPS delle CA radice o delle subCA che rilasciano i certificati per tali veicoli in tali Stati membri devono determinare in che modo il processo di certificazione si applica a tali veicoli.
(117)Qualora il sottoscrittore stia facendo migrare la stazione C-ITS da una EA ad un'altra EA, la stazione C-ITS può essere registrata presso due EA (simili).
(118)La stazione C-ITS genera una coppia di chiavi dell'AT (cfr. la sezione 6.1) e creare una richiesta di AT conformemente al riferimento [1]. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1].
(119)Le stazioni C-ITS inviano una richiesta di autorizzazione alla URL della AA (flussi 32 e 26) inviando almeno le informazioni richieste di cui alla sezione 3.2.3.3. La EA e la AA convalidano l'autorizzazione per ciascuna richiesta conformemente alle sezioni 3.2.6 e 4.2.2.5.
4.2.Trattamento della domanda di certificato
4.2.1.Esecuzione delle funzioni di identificazione e di autenticazione
4.2.1.1.Identificazione e autenticazione delle CA radice
(120)Il rappresentante autorizzato della CPA è responsabile dell'autenticazione del rappresentante autorizzato della CA radice e dell'approvazione del suo processo di registrazione conformemente alla sezione 3.
4.2.1.2.Identificazione e autenticazione del TLM
(121)Il rappresentante autorizzato della CPA è responsabile dell'autenticazione del rappresentante autorizzato del TLM e dell'approvazione del suo modulo di domanda per il processo di registrazione conformemente alla sezione 3.
4.2.1.3.Identificazione e autenticazione di EA e AA
(122)La corrispondente CA radice è responsabile dell'autenticazione del rappresentante autorizzato della EA/AA e dell'approvazione del suo modulo di domanda per il processo di registrazione conformemente alla sezione 3.
(123)La CA radice deve confermare la sua convalida con esito positivo del modulo di domanda della EA/AA. Quest'ultima può quindi inviare una richiesta di certificato alla CA radice (flusso 21/24), che deve rilasciare i certificati alla corrispondente EA/AA (flusso 18/19).
4.2.1.4.Identificazione e autenticazione del sottoscrittore della EE
(124)Prima che la stazione C-ITS possa richiedere un certificato delle EC, il sottoscrittore della EE deve trasmettere in modo sicuro alla EA le informazioni di identificazione della stazione C-ITS (flusso 33). La EA deve verificare la richiesta e, se la verifica ha esito positivo, deve registrare le informazioni della stazione C-ITS nella sua banca dati e darne conferma al sottoscrittore dell'EE (flusso 35). Questa operazione viene effettuata solo una volta dal fabbricante o dall'operatore per ciascuna stazione C-ITS. Una volta registrata da una EA, la stazione C-ITS può richiedere un solo certificato delle EC (flusso 31) alla volta. La EA effettua l'autenticazione e verifica che le informazioni nella richiesta del certificato delle EC siano valide per una stazione C-ITS.
4.2.1.5.Ticket di autorizzazione
(125)Durante le richieste di autorizzazione (flusso 32), conformemente al riferimento [1], la AA deve autenticare la EA da cui la stazione C-ITS ha ricevuto le sue EC. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1]. Se la AA non è in grado di autenticare la EA, la richiesta viene rifiutata (flusso 26). Come requisito la AA deve essere in possesso del certificato della EA per autenticarla e verificarne la risposta (flussi 25 e 23, sezione 3.2.5.3).
(126)La EA autentica la stazione C-ITS che richiede l'AT verificandone le EC (flussi 25 e 23).
4.2.2.Approvazione o rifiuto delle domande di certificato
4.2.2.1.Approvazione o rifiuto dei certificati della CA radice
(127)Il TLM inserisce i certificati della CA radice nell'ECTL o li cancella dallo stesso in conformità all'approvazione della CPA (flusso 1/2).
(128)Il sistema TLM dovrebbe verificare la firma, le informazioni e la codifica dei certificati della CA radice dopo aver ricevuto l'approvazione dalla CPA (flusso 1). Dopo la convalida con esito positivo e l'approvazione della CPA, il TLM deve inserire il corrispondente certificato radice nell'ECTL e notificare la CPA (flusso 5).
4.2.2.2.Approvazione o rifiuto del certificato del TLM
(129)La CPA è responsabile dell'approvazione o del rifiuto dei certificati del TLM.
4.2.2.3.Approvazione o rifiuto dei certificati delle EA e AA
(130)La CA radice verifica le richieste di certificati della sub-CA (flusso 21/24) e le relative relazioni (emesse dall'auditor accreditato della PKI) nel momento in cui li riceve (flusso 36, sezione 8) dalla corrispondente sub-CA della CA radice. Se la verifica della richiesta ha esito positivo, la corrispondente CA radice rilascia un certificato alla EA/AA richiedente (flusso 18/19); in caso contrario la richiesta viene rifiutata e non vengono rilasciati certificati alla EA/AA.
4.2.2.4.Approvazione o rifiuto delle EC
(131)La EA deve verificare e convalidare le richieste di EC in conformità alle sezioni 3.2.3.2 e 3.2.5.3.
(132)Se la richiesta di certificato in conformità al riferimento [1] è corretta e valida, la EA deve generare il certificato richiesto.
(133)Se la richiesta di certificato non è valida, la EA la rifiuta e invia una risposta che indichi il motivo del rifiuto in conformità al riferimento [1]. Se la stazione C-ITS ha ancora bisogno di EC, deve effettuare una nuova richiesta di certificato. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1].
4.2.2.5.Approvazione o rifiuto di AT
(134)La EA verifica la richiesta di certificato. La AA deve stabilire una comunicazione con la EA per convalidare la richiesta (flusso 25). La EA deve autenticare la stazione C-ITS richiedente e convalidarne il diritto a ricevere l'AT richiesto in base alla CP (ad esempio verificando lo status della revoca e convalidando la validità dell'ora/del luogo del certificato, i permessi, il livello di garanzia, ecc.). La EA deve restituire una risposta di convalida (flusso 23) e, se la risposta è positiva, la AA deve generare il certificato richiesto e trasmetterlo alla stazione C-ITS. Se la richiesta dell'AT non è corretta o la risposta di convalida della EA è negativa, la AA rifiuta la richiesta. Se la stazione C-ITS ha ancora bisogno di un AT, deve effettuare una nuova richiesta di autorizzazione.
4.2.3.Tempi di trattamento della domanda di certificato
4.2.3.1.Domanda di certificato della CA radice
(135)Il trattamento del processo di identificazione e autenticazione di una domanda di certificato deve essere effettuato nei giorni lavorativi e deve essere soggetto a un limite di tempo massimo stabilito nel CPS della CA radice.
4.2.3.2.Domanda di certificato del TLM
(136)Il trattamento della domanda di certificato del TLM deve essere soggetto al limite di tempo massimo stabilito nel CPS del TLM.
4.2.3.3.Domanda di certificato delle EA e AA
(137)Il trattamento del processo di identificazione e autenticazione di una domanda di certificato deve essere effettuato nei giorni lavorativi, in conformità all'accordo e al contratto tra la CA radice dello Stato membro/dell'organizzazione privata e la subCA. Il tempo di trattamento delle domande di certificati della sub-CA deve essere soggetto al limite di tempo massimo stabilito nel CPS della sub-CA.
4.2.3.4.Domanda di EC
(138)Il trattamento delle domande di EC deve essere soggetto al limite di tempo massimo stabilito nel CPS della EA.
4.2.3.5.Domanda di AT
(139)Il trattamento delle domande di AT deve essere soggetto al limite di tempo massimo stabilito nel CPS della AA.
4.3.Rilascio del certificato
4.3.1.Azioni della CA durante il rilascio del certificato
4.3.1.1.Rilascio del certificato della CA radice
(140)La CA radice rilascia i propri certificati autofirmati della CA radice, i certificati di collegamento, i certificati delle sub-CA e le CRL.
(141)Dopo l'approvazione della CPA (flusso 4), la CA radice invia il suo certificato al TLM attraverso il CPOC affinché venga aggiunto all'ECTL (flussi 11 e 8) (cfr. sezione 4.1.2.1). Il TLM verifica se la CPA ha approvato il certificato (flusso 1).
4.3.1.2.Rilascio del certificato del TLM
(142)Il TLM rilascia il proprio certificato autofirmato del TLM e il certificato di collegamento e li invia al CPOC (flusso 6).
4.3.1.3.Rilascio del certificato delle EA e AA
(143)Le sub-CA generano una richiesta di certificato firmata e la trasmettono alla corrispondente CA radice (flussi 21 e 24). La CA radice verifica la richiesta e rilascia un certificato alla sub-CA richiedente in conformità al riferimento [5], come stabilito nel CPS per le pratiche operative abituali, appena possibile e comunque non più tardi di cinque giorni lavorativi dalla ricezione della richiesta.
(144)La CA radice deve aggiornare il repository contenente i certificati delle subCA.
4.3.1.4.Rilascio delle EC
(145)La stazione C-ITS deve inviare una richiesta di EC alla EA in conformità al riferimento [1]. La EA deve autenticare e verificare che le informazioni nella richiesta di certificato siano valide per una stazione C-ITS. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1].
(146)Se la convalida ha esito positivo, la EA deve rilasciare un certificato in conformità alla registrazione della stazione C-ITS (cfr. 4.2.1.4) e inviarlo alla stazione C-ITS usando un messaggio di risposta delle EC in conformità al riferimento [1]. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1].
(147)Se non vi è alcuna registrazione, la EA deve generare un codice di errore e inviarlo alla stazione C-ITS utilizzando un messaggio di risposta delle EC in conformità al riferimento [1]. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1].
(148)Le richieste di EC e le risposte delle EC devono essere cifrate per garantirne la riservatezza e firmate per garantire l'autenticazione e l'integrità.
4.3.1.5.Rilascio dell'AT
(149)La stazione C-ITS deve inviare un messaggio di richiesta di AT alla AA in conformità al riferimento [1]. La AA deve inviare alla EA una richiesta di convalida dell'AT in conformità al riferimento [1]. La EA deve inviare alla AA una risposta di convalida dell'AT. Se la risposta è positiva, la AA deve generare un AT e inviarlo alla stazione C-ITS utilizzando un messaggio di risposta dell'AT in conformità al riferimento [1]. Se la risposta è negativa, la AA deve generare un codice di errore e inviarlo alla stazione C-ITS utilizzando un messaggio di risposta dell'AT in conformità al riferimento [1]. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1].
(150)Le richieste di AT e le risposte di AT devono essere cifrate (solo per le stazioni CITS mobili) per garantirne la riservatezza e firmate per garantire l'autenticazione e l'integrità.
4.3.2.Notifica della CA al sottoscrittore relativa al rilascio dei certificati
Non pertinente.
4.4.Accettazione di certificati
4.4.1.Procedura di accettazione di certificati
4.4.1.1.CA radice
Non pertinente.
4.4.1.2.TLM
Non pertinente.
4.4.1.3.EA e AA
(151)La EA/AA deve verificare il tipo di certificato, la firma e le informazioni del certificato ricevuto. La EA/AA deve scartare tutti i certificati della EA/AA che non sono verificati correttamente ed emettere una nuova richiesta.
4.4.1.4.Stazione C-ITS
(152)La stazione C-ITS deve verificare che la risposta di EC/AT ricevuta dalla EA/AA a seguito della richiesta iniziale includa la firma e la catena di certificati e deve scartare tutte le risposte di EC/AT che non sono verificate correttamente. In tali casi essa deve inviare una nuova richiesta di EC/AT.
4.4.2.Pubblicazione dei certificati
(153)I certificati del TLM e i relativi certificati di collegamento devono essere messi a disposizione di tutti i partecipanti attraverso il CPOC.
(154)I certificati della CA radice sono pubblicati dal CPOC mediante l'ECTL, che è firmato dal TLM.
(155)I certificati delle sub-CA (EA e AA) sono pubblicati dalla CA radice.
(156)Le EC e gli AT non sono pubblicati.
4.4.3.Notifica del rilascio di certificati
Non vi sono notifiche di rilascio.
4.5.Coppia di chiavi e uso dei certificati
4.5.1.Chiave privata e uso dei certificati
4.5.1.1.Chiave privata e uso dei certificati per il TLM
(157)Il TLM deve utilizzare le sue chiavi private per firmare i propri certificati (di collegamento e del TLM) e l'ECTL.
(158)Il certificato del TLM deve essere utilizzato dai partecipanti alla PKI per verificare l'ECTL e autenticare il TLM.
4.5.1.2.Chiave privata e uso dei certificati per le CA radice
(159)Le CA radice devono usare le loro chiavi private per firmare i propri certificati, CRL, certificati di collegamento e i certificati delle EA/AA.
(160)I certificati della CA radice devono essere usati dai partecipanti alla PKI per verificare i certificati associati delle EA e AA, i certificati di collegamento e le CRL.
4.5.1.3.Chiave privata e uso dei certificati per le EA e AA
(161)Le EA devono usare le loro chiavi private per firmare le EC e per decifrare le richieste di registrazione.
(162)I certificati delle EA devono essere usati per verificare la firma delle EC associate e per la cifratura delle richieste di EC e AT da parte delle EE, come definito al riferimento [1].
(163)Le AA devono usare le loro chiavi private per firmare gli AT e per decifrare le richieste di AT.
(164)I certificati della AA devono essere usati dalle EE per verificare gli AT associati e per la cifratura delle richieste di AT, come definito al riferimento [1].
4.5.1.4.Chiave privata e uso dei certificati per le entità finali
(165)Le EE devono usare la chiave privata corrispondente alle EC valide per firmare una nuova richiesta di registrazione come definito al riferimento [1]. La nuova chiave privata deve essere usata per generare la firma interna nella richiesta, al fine di provare il possesso della chiave privata corrispondente alla chiave pubblica delle nuove EC.
(166)Le EE devono usare la chiave privata corrispondente alle EC valide per firmare una richiesta di registrazione come definito al riferimento [1]. La chiave privata corrispondente al nuovo AT dovrebbe essere usata per generare la firma interna nella richiesta, al fine di provare il possesso della chiave privata corrispondente alla chiave pubblica del nuovo AT.
(167)Le EE devono usare la chiave privata corrispondente all'AT appropriato per i messaggi C-ITS come definito al riferimento [5].
4.5.2.Chiave pubblica e uso dei certificati delle relying parties
(168)Le relying parties usano il percorso di certificazione fidato e le chiavi pubbliche associate per gli scopi indicati nei certificati e per autenticare l'identità comune fidata delle EC e degli AT.
(169)I certificati della CA radice, della EA e della AA, le EC e gli AT non devono essere utilizzati senza un controllo preliminare da parte di una relying party.
4.6.Rinnovo dei certificati
Non consentito.
4.7.Re-keying dei certificati
4.7.1.Circostanze in cui si verifica il re-keying
(170)Il re-keying di un certificato deve essere effettuato quando quest'ultimo raggiunge la fine del suo ciclo di vita o la chiave privata raggiunge la fine dell'utilizzo operativo, ma la relazione di fiducia con la CA esiste ancora. In tutti i casi devono essere generati e rilasciati una nuova coppia di chiavi e il corrispondente certificato.
4.7.2.Chi può chiedere il re-keying
4.7.2.1.CA radice
(171)La CA radice non chiede il re-keying. Il processo di re-keying è un processo interno alla CA radice, poiché il suo certificato è autofirmato. La CA radice deve effettuare il re-keying con i certificati di collegamento o i nuovi rilasci (cfr. sezione 4.3.1.1).
4.7.2.2.TLM
(172)Il TLM non chiede il re-keying. Per il TLM il processo di re-keying è un processo interno, poiché il suo certificato è autofirmato.
4.7.2.3.EA e AA
(173)La richiesta di certificato della sub-CA deve essere presentata in tempo utile per avere la certezza di disporre di un nuovo certificato della sub-CA e di una coppia di chiavi della sub-CA operative prima della scadenza dell'attuale chiave privata della sub-CA. La data di presentazione deve inoltre tener conto del tempo necessario per l'approvazione.
4.7.2.4.Stazione C-ITS
Non pertinente.
4.7.3.Processo di re-keying
4.7.3.1.Certificato del TLM
(174)Il TLM decide di effettuare il re-keying sulla base dei requisiti di cui alle sezioni 6.1 e 7.2. Il processo dettagliato è stabilito nel suo CPS.
(175)Il TLM deve eseguire il processo di re-keying in tempo utile per consentire la distribuzione del nuovo certificato del TLM e del certificato di collegamento a tutti i partecipanti prima della scadenza dell'attuale certificato del TLM.
(176)Il TLM deve utilizzare i certificati di collegamento per il re-keying, al fine di garantire la relazione di fiducia con il nuovo certificato autofirmato. Il certificato del TLM e il certificato di collegamento di nuova generazione sono trasferiti al CPOC.
4.7.3.2.Certificato della CA radice
(177)La CA radice decide di effettuare il re-keying sulla base dei requisiti di cui alle sezioni 6.1.5 e 7.2. Il processo dettagliato dovrebbe essere definito nel suo CPS.
(178)La CA radice deve eseguire il processo di re-keying in tempo utile (prima della scadenza del certificato della CA radice) per consentire l'inserimento del nuovo certificato nell'ECTL prima che il certificato della CA radice diventi valido (cfr. la sezione 5.6.2). Il processo di re-keying deve essere effettuato mediante i certificati di collegamento o allo stesso modo di una richiesta iniziale.
4.7.3.3.Certificati delle EA e AA
(179)La EA o la AA devono richiedere un nuovo certificato nel modo seguente:
Fase
|
Indicazione
|
Richiesta di re-keying
|
1
|
Generazione della coppia di chiavi
|
Le sub-CA (EA e AA) devono generare una nuova coppia di chiavi in conformità alla sezione 6.1.
|
2
|
Generazione della richiesta di certificato e firma interna
|
La sub-CA genera una richiesta di certificato da una chiave pubblica di nuova generazione tenendo conto delle regole in materia di assegnazione dei nomi (subject_info) di cui alla sezione 3, dell'algoritmo di firma, di permessi specifici del servizio (SSP) e del parametro supplementare facoltativo, e genera la firma interna con la nuova chiave privata corrispondente. Se è necessaria una chiave di cifratura la sub-CA deve anche dimostrare il possesso della corrispondente chiave di decifratura privata.
|
3
|
Generazione della firma esterna
|
L'intera richiesta deve essere firmata con la chiave privata attualmente valida al fine di garantire l'autenticità della richiesta firmata.
|
4
|
Invio della richiesta alla CA radice
|
La richiesta firmata deve essere presentata alla CA radice corrispondente.
|
5
|
Verifica della richiesta
|
La CA radice corrispondente deve verificare l'integrità e l'autenticità della richiesta. In primo luogo deve provvedere alla verifica della firma esterna. Se la verifica ha esito positivo deve provvedere alla verifica della firma interna. Qualora vi sia una prova del possesso della chiave di decifratura, la CA radice deve inoltre verificare tale prova.
|
6
|
Accettazione o rifiuto della richiesta
|
Se tutte le verifiche hanno esito positivo, la CA radice accetta la richiesta; in caso contrario la rifiuta.
|
7
|
Generazione e rilascio del certificato
|
La CA radice genera un nuovo certificato e lo distribuisce alla sub-CA richiedente.
|
8
|
Invio della risposta
|
La sub-CA deve inviare un messaggio di status (che indichi se il certificato è stato ricevuto o no) alla CA radice.
|
Tabella 3: processo di re-keying per EA e AA
(180)Durante il re-keying automatico per le sub-CA, la CA radice deve garantire che il richiedente sia effettivamente in possesso della sua chiave privata. Devono essere applicati protocolli adeguati per la prova del possesso delle chiavi di decifratura private, ad esempio come definito nelle norme RFC 4210 e 4211. Per le chiavi di firma private dovrebbe essere usata la firma interna.
4.7.3.4.Certificati della stazione C-ITS
Non pertinente per gli AT.
4.8.Modifica del certificato
Non consentita.
4.9.Sospensione e revoca del certificato
Cfr. sezione 7.
4.10.Servizi relativi allo status del certificato
4.10.1.Caratteristiche operative
Non pertinente
4.10.2.Disponibilità del servizio
Non pertinente
4.10.3.Caratteristiche facoltative
Non pertinente
4.11.Fine della sottoscrizione
Non pertinente
4.12.Key escrow (deposito della chiave) e key recovery (recupero della chiave)
4.12.1.Sottoscrittore
4.12.1.1.Coppie di chiavi che possono essere depositate presso terzi (key escrow)
Non pertinente.
4.12.1.2.Chi può presentare una domanda di recupero
Non pertinente.
4.12.1.3.Processo di recupero e responsabilità
Non pertinente.
4.12.1.4.Identificazione e autenticazione
Non pertinente.
4.12.1.5.Approvazione o rifiuto delle domande di recupero
Non pertinente.
4.12.1.6.Azioni KEA e KRA durante il recupero della coppia di chiavi
Non pertinente.
4.12.1.7.Disponibilità KEA e KRA
Non pertinente.
4.12.2.Incapsulamento della chiave di sessione e politica e pratiche di recupero
Non pertinente.
5.Controlli operativi, di gestione e degli impianti
(181)La PKI è costituita da CA radice, EA/AA, CPOC e TLM, compresi i loro componenti TIC (ad esempio reti e server).
(182)Nella presente sezione l'entità responsabile di un elemento della PKI è identificata con l'elemento stesso. Pertanto la frase "la CA è responsabile dell'esecuzione dell'audit" è equivalente a "l'entità o il personale che gestisce la CA è responsabile dell'esecuzione...".
(183)L'espressione "elementi del modello di fiducia C-ITS" comprende la CA radice, il TLM, la EA/AA, il CPOC e la rete sicura.
5.1.Controlli fisici
(184)Tutte le operazioni del modello di fiducia C-ITS devono essere effettuate in un ambiente fisicamente protetto che scoraggi, impedisca e rilevi l'uso non autorizzato o la divulgazione di informazioni e sistemi sensibili o l'accesso agli stessi. Gli elementi del modello di fiducia C-ITS devono utilizzare i controlli fisici di sicurezza conformemente alle norme ISO 27001 e ISO 27005.
(185)Le entità che gestiscono gli elementi del modello di fiducia C-ITS devono descrivere i controlli di sicurezza fisici, procedurali e del personale nei loro CPS. In particolare il CPS deve comprendere informazioni relative all'ubicazione del sito, alla costruzione degli edifici e ai loro controlli fisici di sicurezza che garantiscano un accesso controllato a tutte le sale utilizzate negli impianti delle entità dei modelli di fiducia C-ITS.
5.1.1.Ubicazione e costruzione del sito
5.1.1.1.CA radice, CPOC, TLM
(186)L'ubicazione e la costruzione dell'impianto che ospita i dati e le apparecchiature della CA radice, del CPOC e del TLM (HSM, dati di attivazione, backup della coppia di chiavi, computer, log, script per la cerimonia delle chiavi, richieste di certificato, ecc.) devono essere conformi agli impianti usati per ospitare informazioni sensibili o di alto valore. Le operazioni della CA radice devono avvenire in un'area fisica specifica separata dalle aree fisiche degli altri componenti della PKI.
(187)La CA radice, il CPOC e il TLM devono attuare politiche e procedure volte ad assicurare il mantenimento di un elevato livello di sicurezza nell'ambiente fisico in cui sono installate le apparecchiature della CA radice, in modo da garantire che:
·l'ambiente sia isolato dalle reti esterne al modello di fiducia;
·l'ambiente sia diviso in una serie di (almeno due) perimetri fisici progressivamente più sicuri;
·i dati sensibili (HSM, backup della coppia di chiavi, dati di attivazione, ecc.) siano conservati in una apposita cassaforte posta in un'area fisica specifica sottoposta a controlli multipli degli accessi.
(188)Le tecniche di sicurezza utilizzate devono essere progettate per resistere a un numero elevato di forme e combinazioni di attacco diverse. I meccanismi utilizzati devono comprendere almeno:
·allarmi perimetrali, telecamere a circuito chiuso, pareti rinforzate e sensori di movimento;
·autenticazione a due fattori (ad esempio smart card e PIN) per tutte le persone e badge per entrare e uscire dagli impianti della CA radice e dall'area fisica sicura.
(189)La CA radice, il CPOC e il TLM si servono di personale autorizzato al fine di monitorare l'impianto che ospita le apparecchiature in modo continuo, 24 ore al giorno, 7 giorni su 7, per 365 giorni l'anno. L'ambiente operativo (ad esempio l'impianto fisico) non deve mai essere lasciato incustodito. Il personale dell'ambiente operativo non deve mai accedere alle aree sicure della CA radice o delle sub-CA se non autorizzato.
5.1.1.2.EA/AA
(190)Si applicano le stesse disposizioni della sezione 5.1.1.1.
5.1.2.Accesso fisico
5.1.2.1.CA radice, CPOC, TLM
(191)Le apparecchiature e i dati (HSM, dati di attivazione, backup della coppia di chiavi, computer, log, script per la cerimonia delle chiavi, richieste di certificato, ecc.) devono sempre essere protetti dall'accesso non autorizzato. I meccanismi fisici di sicurezza delle apparecchiature devono almeno:
·monitorare in ogni momento, manualmente o elettronicamente, l'intrusione non autorizzata;
·garantire che non sia consentito l'accesso non autorizzato all'hardware e ai dati di attivazione;
·garantire che tutti i supporti elettronici o cartacei che contengono informazioni testuali sensibili siano conservati in un contenitore sicuro;
·garantire che coloro che hanno accesso ad aree sicure senza essere autorizzati in via permanente non siano mai lasciati senza la supervisione di un dipendente autorizzato dell'impianto della CA radice, del CPOC o del TLM;
·garantire l'aggiornamento e la verifica periodica del log degli accessi;
·prevedere almeno due livelli di sicurezza progressiva, ad esempio a livello di perimetro, di edificio e di sala operativa;
·richiedere due controlli degli accessi fisici dei ruoli di fiducia per l'HSM crittografico e i dati di attivazione.
(192)Deve essere effettuato un controllo di sicurezza dell'impianto che ospita le apparecchiature, qualora quest'ultimo debba essere lasciato incustodito. Il controllo deve verificare almeno:
·che le apparecchiature si trovino in uno stato idoneo alla modalità operativa attuale;
·per i componenti off-line, che le apparecchiature siano spente;
·che tutti i contenitori di sicurezza (involucro a prova di manomissione, cassaforte, ecc.) siano chiusi;
·che i sistemi di sicurezza fisici (ad esempio le serrature delle porte, le griglie di aerazione, l'elettricità) funzionino correttamente;
·che l'accesso non autorizzato all'area non sia consentito.
(193)I moduli crittografici rimuovibili devono essere disattivati prima di essere conservati. Quando non sono in uso, tali moduli e i dati di attivazione utilizzati per accedervi o abilitarli devono essere posti in cassaforte. I dati di attivazione devono essere memorizzati o registrati e conservati in modo commisurato alla sicurezza del modulo crittografico. Essi non devono essere conservati insieme al modulo crittografico, in modo da evitare che una sola persona abbia accesso alla chiave privata.
(194)Una persona o un gruppo di ruoli di fiducia devono essere esplicitamente incaricati di effettuare tali controlli. Qualora venga incaricato un gruppo di persone, deve essere creato e mantenuto aggiornato un log che identifichi la persona che effettua ciascun controllo. Se non è prevista una presenza continua presso l'impianto, l'ultima persona che si allontana deve siglare una scheda di uscita in cui sono indicate data e ora insieme a una conferma della presenza e dell'attivazione di tutti i necessari meccanismi di protezione fisici.
5.1.2.2.EA/AA
(195)Si applicano le stesse disposizioni della sezione 5.1.2.1.
5.1.3.Energia elettrica e aria condizionata
(196)Gli impianti sicuri degli elementi del modello di fiducia C-ITS (CA radice, CPOC, TLM, EA e AA) devono essere dotati di un accesso affidabile all'energia elettrica per garantire che non si verifichino guasti o che l'entità di quelli che si verificano sia ridotta. Sono necessarie installazioni primarie e di backup nel caso si verifichino interruzioni dell'alimentazione esterna e deve essere previsto un arresto senza intoppi delle apparecchiature del modello di fiducia CITS in caso di mancanza di energia. Gli impianti del modello di fiducia C-ITS devono essere dotati di sistemi di riscaldamento/ventilazione/condizionamento dell'aria al fine di mantenere la temperatura e l'umidità relativa delle apparecchiature del modello di fiducia C-ITS all'interno dell'intervallo operativo. Il CPS dell'elemento del modello di fiducia C-ITS descriverà in dettaglio il piano e i processi per l'attuazione di tali requisiti.
5.1.4.Esposizione all'acqua
(197)Gli impianti sicuri degli elementi del modello di fiducia C-ITS (CA radice, CPOC, TLM, EA e AA) dovrebbero essere protetti in modo da ridurre al minimo gli effetti dell'esposizione all'acqua. Per questo motivo devono essere evitati i tubi di scarico e dell'acqua. Il CPS dell'elemento del modello di fiducia C-ITS descriverà in dettaglio il piano e i processi per l'attuazione di tali requisiti.
5.1.5.Prevenzione e protezione antincendio
(198)Per prevenire i danni derivanti dall'esposizione a fiamme o fumo, gli impianti sicuri degli elementi del modello di fiducia CITS (CA radice, CPOC, TLM, EA e AA) devono essere opportunamente costruiti e equipaggiati e devono essere attuate procedure per rispondere alle minacce derivanti dagli incendi. I supporti dei dati dovrebbero essere posti in appositi contenitori per la protezione dagli incendi.
(199)Gli elementi del modello di fiducia C-ITS devono proteggere i supporti fisici che contengono i backup di dati critici di sistema o qualsiasi altra informazione sensibile dai rischi ambientali e dall'uso, dall'accesso o dalla divulgazione non autorizzati dei dati in essi contenuti. Il CPS dell'elemento del modello di fiducia C-ITS descriverà in dettaglio il piano e i processi per l'attuazione di tali requisiti.
5.1.6.Gestione dei supporti di dati
(200)I supporti di dati usati negli elementi del modello di fiducia C-ITS (CA radice, CPOC, TLM, EA e AA) sono gestiti in modo sicuro per proteggerli da danni, furti e accessi non autorizzati. Le procedure di gestione dei supporti di dati sono attuate al fine di proteggerli dal deterioramento o dall'obsolescenza nel periodo in cui le registrazioni devono essere conservate.
(201)In caso di riutilizzo dei supporti di dati (che preveda ad esempio la cancellazione dei file) i dati sensibili devono essere resi inaccessibili agli utenti non autorizzati.
(202)Deve essere mantenuto aggiornato un inventario del patrimonio di informazioni e devono essere stabiliti requisiti per la protezione di tale patrimonio in conformità all'analisi dei rischi. Il CPS dell'elemento del modello di fiducia C-ITS descriverà in dettaglio il piano e i processi per l'attuazione di tali requisiti.
5.1.7.Smaltimento dei rifiuti
(203)Gli elementi del modello di fiducia C-ITS (CA radice, CPOC, TLM, EA e AA) devono attuare procedure per lo smaltimento sicuro e irreversibile dei rifiuti (supporti elettronici, cartacei o altri rifiuti) al fine di impedire l'uso, l'accesso o la divulgazione non autorizzati di informazioni riservate/private contenute in tali rifiuti. Tutti i supporti usati per la conservazione di informazioni sensibili, quali chiavi, dati o file di attivazione, devono essere distrutti prima di essere inviati allo smaltimento. Il CPS dell'elemento del modello di fiducia C-ITS descriverà in dettaglio il piano e i processi per l'attuazione di tali requisiti.
5.1.8.Backup esterno al sito
5.1.8.1.CA radice, CPOC e TLM
(204)Un backup completo dei componenti di CA radice, CPOC e TLM, sufficiente per il ripristino dopo un guasto del sistema, viene effettuato online dopo l'installazione di CA radice, CPOC e del TLM e dopo la generazione di ogni nuova coppia di chiavi. Vengono effettuate regolarmente copie di backup del software e delle informazioni aziendali essenziali (coppia di chiavi e CRL). Sono previste strutture di backup adeguate per garantire che il software e le informazioni aziendali essenziali possano essere ripristinati a seguito di disastro o di guasto del supporto. Le disposizioni relative al backup dei singoli sistemi vengono testate regolarmente per garantire che soddisfino i requisiti del piano di continuità operativa. Almeno una copia del backup completo è conservata esternamente al sito (ripristino in caso di disastro). La copia di back-up è conservata in un sito con controlli fisici e procedurali commisurati a quelli dei sistemi PKI operativi.
(205)I dati di backup sono soggetti agli stessi requisiti di accesso dei dati operativi. I dati di backup devono essere cifrati e conservati esternamente al sito. Del caso di perdita totale dei dati, le informazioni necessarie per ripristinare il funzionamento di CA radice, CPOC e TLM devono essere recuperate dai dati di backup.
(206)Il backup del materiale relativo alla chiave privata di CA radice, CPOC e TLM non deve essere effettuato usando i meccanismi standard di backup, ma usando la funzione di backup del modulo crittografico.
5.1.8.2.EA/AA
(207)I processi di cui alla sezione 5.1.8.1 si applicano alla presente sezione.
5.2.Controlli procedurali
La presente sezione descrive i requisiti per i ruoli, le funzioni e l'identificazione del personale.
5.2.1.Ruoli di fiducia
(208)Devono essere considerate "persone di fiducia" i dipendenti, i contraenti e i consulenti cui sono assegnati ruoli di fiducia. Coloro che intendano diventare persone di fiducia al fine di ottenere un incarico di fiducia devono soddisfare i requisiti di screening della presente politica dei certificati.
(209)Le persone di fiducia controllano le operazioni crittografiche o di autenticazione, o hanno accesso alle stesse, che possono materialmente incidere:
·sulla convalida delle informazioni contenute nelle domande di certificati;
·sull'accettazione, sul rifiuto o su un altro trattamento delle domande di certificato, delle richieste di revoca o di quelle di rinnovo;
·sul rilascio o sulla revoca di certificati, compreso il personale che ha accesso a parti riservate del repository o che gestisce le informazioni o le richieste del sottoscrittore.
(210)I ruoli di fiducia comprendono, tra l'altro:
·il servizio clienti;
·l'amministrazione di sistema;
·l'ingegneria designata;
·i ruoli esecutivi incaricati della gestione dell'affidabilità dell'infrastruttura.
(211)La CA deve fornire descrizioni chiare di tutti i ruoli di fiducia nel suo CPS.
5.2.2.Numero di persone necessarie per compito
(212)Gli elementi del modello di fiducia C-ITS devono stabilire, tenere aggiornate e applicare procedure di controllo rigorose per garantire la separazione delle funzioni in base ai ruoli di fiducia e per garantire che per svolgere compiti sensibili siano necessarie più persone di fiducia. Gli elementi del modello di fiducia C-ITS (CA radice, CPOC, TLM, EA e AA) dovrebbero essere conformi al riferimento [4] e ai requisiti di cui ai seguenti riferimenti.
(213)Politiche e procedure di controllo sono poste in essere al fine di garantire la separazione delle funzioni in base alle responsabilità professionali. Per compiti più sensibili, quali l'accesso all'hardware crittografico della CA (HSM) e al materiale della chiave associata e la gestione degli stessi, deve essere necessaria l'autorizzazione di più persone di fiducia.
(214)Tali procedure di controllo interne devono essere progettate in modo che per avere accesso fisico o logico al dispositivo siano necessarie almeno due persone di fiducia . Le restrizioni relative all'accesso all'hardware crittografico della CA devono essere applicate in modo rigoroso da più persone di fiducia durante tutto il suo ciclo di vita, dalla ricevuta e dall'ispezione di arrivo alla distruzione fisica e/o logica finale. Una volta che un modulo viene attivato con le chiavi operative, vengono invocati ulteriori controlli di accesso per mantenere un controllo separato sull'accesso fisico e logico al dispositivo.
5.2.3.Identificazione e autenticazione per ciascun ruolo
(215)Tutte le persone cui è assegnato un ruolo, come descritto nella presente CP, sono identificate e autenticate in modo da garantire che il ruolo consenta loro di svolgere le rispettive funzioni nell'ambito della PKI.
(216)Gli elementi del modello di fiducia C-ITS devono verificare e confermare l'identità e l'autorizzazione di tutti i membri del personale che intendano diventare persone di fiducia prima che:
·tali elementi vengano rilasciati insieme ai rispettivi dispositivi di accesso e venga loro consentito l'accesso agli impianti richiesti;
·vengano loro fornite credenziali elettroniche per accedere e svolgere funzioni specifiche sui sistemi CA.
(217)Il CPS descrive i meccanismi utilizzati per identificare e autenticare gli individui.
5.2.4.Ruoli che richiedono la separazione delle funzioni
(218)I ruoli che richiedono la separazione delle funzioni comprendono tra l'altro:
·l'accettazione, il rifiuto e la revoca delle richieste e altre operazioni di trattamento delle domande di certificati della CA;
·la generazione, il rilascio e la distruzione dei certificati della CA.
(219)La separazione delle funzioni può essere applicata mediante apparecchiature e/o procedure della PKI. A nessun individuo deve essere assegnata più di un'identità salvo approvazione della CA radice.
(220)La parte della CA radice e della CA interessata dalla gestione della generazione e della revoca dei certificati deve essere indipendente dalle altre organizzazioni per le sue decisioni relative alla definizione, fornitura, mantenimento e sospensione dei servizi, in linea con le politiche di certificazione applicabili. In particolare i dirigenti, il personale di grado più elevato e il personale con ruoli di fiducia devono essere liberi da pressioni commerciali, finanziarie o di altro tipo che possono influire negativamente sulla fiducia nei servizi da essi forniti.
(221)La EA e la AA che servono le stazioni C-ITS mobili devono essere entità operative separate, con un'infrastruttura informatica e un team di gestione dell'IT separati. In conformità al GDPR, la EA e la AA non devono scambiarsi dati personali, se non per l'autorizzazione delle richieste di AT. Esse devono trasferire dati relativi all'approvazione delle richieste di AT solo usando il protocollo di convalida dell'autorizzazione di cui al riferimento [1] mediante un'interfaccia dedicata e sicura. Possono essere utilizzati anche altri protocolli, a condizione che venga implementato quanto previsto al riferimento [1].
(222)I file dei log conservati dalla EA e dalla AA possono essere usati esclusivamente allo scopo di revocare EC che presentano un comportamento scorretto in base agli AT di messaggi CAM/DENM malevoli intercettati. Dopo che un messaggio di CAM/DENM è stato identificato come malevolo, la AA cercherà la chiave di verifica dell'AT nei suoi log di rilascio e presenterà una richiesta di revoca alla EA contenente la firma cifrata con la chiave privata delle EC usata al momento del rilascio dell'AT. Tutti i file dei log devono essere adeguatamente protetti dall'accesso non autorizzato e non devono essere condivisi con altre entità o autorità.
Nota: al momento della stesura della presente versione della CP, la progettazione della funzione che verifica un comportamento scorretto non è definita. Si prevede di definire la potenziale progettazione della funzione che verifica un comportamento scorretto nelle future revisioni della politica.
5.3.Controlli del personale
5.3.1.Qualifiche, esperienza e requisiti per il nulla osta
(223)Gli elementi del modello di fiducia C-ITS utilizzano sufficiente personale con qualifiche, esperienza e conoscenze specialistiche necessarie per le funzioni e i servizi professionali offerti. Il personale della PKI soddisfa tali requisiti mediante formazione e credenziali formali, effettiva esperienza o una combinazione di entrambe. Le responsabilità e i ruoli di fiducia, come specificato nel CPS, sono chiaramente individuati e documentati nella descrizioni delle mansioni. È definita una descrizione delle mansioni dei subcontraenti del personale della PKI al fine di garantire la separazione di funzioni e privilegi, ed è determinato il grado di sensibilità del posto di lavoro in base alle funzioni e ai livelli di accesso, alle indagini sui precedenti personali e alla formazione e alla preparazione dei dipendenti.
5.3.2.Procedure di controllo dei precedenti personali
(224)Gli elementi del modello di fiducia C-ITS devono effettuare controlli sui precedenti personali degli impiegati che intendono diventare persone di fiducia. I controlli dei precedenti personali devono essere ripetuti almeno ogni cinque anni per il personale che ricopre incarichi di fiducia.
(225)I fattori emersi da un controllo dei precedenti personali che possono essere considerati motivi validi per respingere candidati a incarichi di fiducia o per prendere provvedimenti nei confronti di una persona che occupa già un posto di fiducia comprendono tra l'altro i seguenti elementi:
·dichiarazioni false fatte dal candidato o dalla persona di fiducia;
·referenze professionali molto sfavorevoli o inattendibili;
·determinate condanne penali;
·indicazioni relative a mancanza di responsabilità finanziaria.
(226)Le relazioni contenenti tali informazioni devono essere valutate da personale addetto alle risorse umane, che deve prendere provvedimenti ragionevoli in considerazione del tipo, dell'importanza e della frequenza del comportamento rilevato dal controllo dei precedenti personali. Tali provvedimenti possono includere misure che possono arrivare alla cancellazione di offerte di lavoro fatte ai candidati a incarichi di fiducia o alla cessazione del rapporto di lavoro con le persone che occupano già un posto di fiducia. L'uso delle informazioni emerse da un controllo dei precedenti personali come base per tali provvedimenti deve essere soggetto alla legislazione applicabile.
(227)Le indagini sui precedenti personali di persone che intendono diventare persone di fiducia includono, tra l'altro:
·la conferma dell'occupazione precedente;
·la verifica delle referenze professionali relative alla loro occupazione per un periodo di almeno cinque anni;
·la conferma del livello di istruzione più elevato o più pertinente ottenuto;
·la ricerca nei casellari giudiziari.
5.3.3.Requisiti di formazione
(228)Gli elementi del modello di fiducia C-ITS devono fornire al loro personale la formazione necessaria per adempiere le loro responsabilità relative alle operazioni delle CA con competenza e in modo soddisfacente.
(229)I programmi di formazione devono essere rivisti periodicamente e devono riguardare questioni pertinenti per le funzioni svolte dal personale.
(230)I programmi di formazione devono riguardare questioni pertinenti per l'ambiente specifico di chi riceve la formazione, compresi:
·i principi e meccanismi di sicurezza degli elementi del modello di fiducia C-ITS;
·le versioni dell'hardware e del software in uso;
·tutti i compiti che la persona dovrà svolgere, i processi per le segnalazioni interne ed esterne e le relative sequenze;
·i flussi di lavoro e processi aziendali della PKI;
·le segnalazioni e gestione degli incidenti e delle compromissioni;
·le procedure per il ripristino in caso di disastro e la continuità del servizio;
·sufficienti conoscenze informatiche.
5.3.4.Frequenza e requisiti di aggiornamento della formazione
(231)Le persone cui vengono assegnati ruoli di fiducia sono tenute ad aggiornare le conoscenze acquisite durante la formazione su base continuativa utilizzando un ambiente di formazione. La formazione deve essere ripetuta ogni qualvolta lo si ritenga necessario e almeno ogni due anni.
(232)Gli elementi del modello di fiducia C-ITS devono fornire al loro personale corsi di aggiornamento con i contenuti e la frequenza necessari a garantire il mantenimento del livello di professionalità necessario per adempiere alle loro responsabilità professionali con competenza e in modo soddisfacente.
(233)Gli individui che hanno ruoli di fiducia devono, se del caso, essere a conoscenza di cambiamenti delle operazioni della PKI. Ogni modifica significativa delle operazioni deve essere accompagnata da un piano di formazione (preparazione), la cui esecuzione deve essere documentata.
5.3.5.Frequenza e sequenza di rotazione del lavoro
(234)Nessuna disposizione, purché siano garantiti esperienza, competenze tecniche e diritti di accesso. Gli amministratori degli elementi del modello di fiducia C-ITS devono garantire che le modifiche del personale non compromettano la sicurezza del sistema.
5.3.6.Sanzioni per le azioni non autorizzate
(235)Gli elementi del modello di fiducia C-ITS devono elaborare un processo disciplinare formale per garantire che le azioni non autorizzate siano adeguatamente sanzionate. Nei casi gravi deve essere prevista la revoca dei ruoli assegnati e dei privilegi corrispondenti.
5.3.7.Requisiti per i contraenti indipendenti
(236)Gli elementi del modello di fiducia C-ITS possono consentire a consulenti o contraenti indipendenti di diventare persone di fiducia solo nella misura necessaria a realizzare relazioni di esternalizzazione chiaramente definite e a condizione che l'entità consideri i contraenti o consulenti affidabili quanto i dipendenti e che i contraenti o consulenti soddisfino i requisiti applicabili ai dipendenti.
(237)In caso contrario i contraenti e i consulenti indipendenti devono avere accesso agli impianti di sicurezza C-ITS della PKI solo se accompagnati e supervisionati direttamente da persone di fiducia.
5.3.8.Documentazione fornita al personale
(238)Gli elementi del modello di fiducia C-ITS devono fornire al personale la formazione necessaria e l'accesso alla documentazione di cui hanno bisogno per adempiere alle loro responsabilità professionali con competenza e in modo soddisfacente.
5.4.Procedure di logging per gli audit
(239)La presente sezione stabilisce i requisiti relativi ai tipi di eventi da registrare e alla gestione dei log degli audit.
5.4.1.Tipi di eventi da registrare e segnalare per ciascuna CA
(240)Una CA rappresentativa deve rivedere regolarmente i log, gli eventi e le procedure della CA.
(241)Gli elementi del modello di fiducia C-ITS devono registrare i seguenti tipi di eventi di audit (se del caso):
·accesso fisico agli impianti - l'accesso delle persone fisiche agli impianti sarà registrato mediante la memorizzazione delle richieste di accesso tramite smart card. Sarà creato un evento ogni volta che si crea una registrazione;
·gestione dei ruoli di fiducia - qualsiasi modifica della definizione e del livello di accesso dei diversi ruoli sarà registrato, compresa la modifica degli attributi dei ruoli. Sarà creato un evento ogni volta che si crea una registrazione;
·accesso logico - quando un'entità (ad esempio un programma) ha accesso a aree sensibili (vale a dire reti e server) sarà generato un evento;
·gestione dei backup - sarà creato un evento ogni volta che viene completato un backup, anche quando quest'ultimo non va a buon fine;
·gestione dei log - i log saranno conservati. Si crea un evento quando il log supera una dimensione specifica;
·dati del processo di autenticazione dei sottoscrittori e degli elementi del modello di fiducia C-ITS - sarà generato un evento per ogni richiesta di autenticazione da parte dei sottoscrittori e degli elementi del modello di fiducia C-ITS;
·accettazione e rifiuto delle richieste di certificati, compresa la creazione e il rinnovo dei certificati - sarà generato periodicamente un evento comprendente l'elenco delle richieste di certificati accettate e rifiutate nei sette giorni precedenti;
·registrazione del fabbricante - sarà creato un evento al momento della registrazione del fabbricante;
·registrazione della stazione C-ITS - sarà creato un evento al momento della registrazione della stazione C-ITS;
·gestione dell'HSM - sarà creato un evento al momento della registrazione di una violazione della sicurezza dell'HSM;
·gestione IT e della rete di pertinenza dei sistemi della PKI - sarà creato un evento allo spegnimento o al riavvio del server della PKI;
·gestione della sicurezza (tentativi di accesso al sistema della PKI, anche non riusciti, azioni eseguite dal sistema di sicurezza e dalla PKI, modifiche del profilo di sicurezza, interruzioni nel funzionamento del sistema, guasti dell'hardware e altre anomalie, attività del router e del firewall; entrate e uscite dagli impianti della PKI);
·i dati relativi agli eventi saranno conservati per almeno cinque anni a meno che non si applichino ulteriori norme nazionali.
(242)In conformità al GDPR i log degli audit non devono consentire l'accesso a dati relativi alla vita privata concernenti i veicoli privati delle stazioni C-ITS.
(243)Ove possibile i log degli audit di sicurezza devono essere raccolti automaticamente. Ove ciò non sia possibile deve essere usato un registro dei log, un modulo cartaceo o un altro meccanismo fisico. Tutti i log degli audit di sicurezza, sia elettronici che non elettronici, devono essere conservati e messi a disposizione durante gli audit di conformità.
(244)Ciascun evento relativo al ciclo di vita dei certificati è registrato nel log in modo tale da poter essere attribuito alla persona che lo ha eseguito. Tutti i dati relativi alle identità personali sono cifrati e protetti da accessi non autorizzati.
(245)Ciascuna registrazione dell'audit deve includere almeno i seguenti elementi (registrati automaticamente o manualmente per ciascun evento da sottoporre ad audit):
·tipo di evento (come da elenco di cui sopra);
·data e ora affidabili in cui l'evento si è verificato;
·risultato dell'evento - riuscito o fallito, a seconda dei casi;
·identità dell'entità e/o dell'operatore che ha causato l'evento, se del caso;
·identità dell'entità destinataria dell'evento.
5.4.2.Frequenza di trattamento dei log
(246)I log degli audit devono essere rivisti in seguito a messaggi di allerta basati su irregolarità e incidenti nei sistemi della CA, oltre che periodicamente ogni anno.
(247)Il trattamento dei log di audit deve essere costituito da una revisione dei log di audit e dalla documentazione delle motivazioni di ogni evento significativo in una sintesi dei log di audit. Nella revisione dei log di audit si deve verificare che il log non sia stato manomesso, si devono ispezionare tutte le voci del log e si devono condurre indagini su tutti i messaggi di allerta o sulle irregolarità in esso riportati. Le misure adottate sulla base della revisione dei log di audit devono essere documentate.
(248)I log di audit sono archiviati almeno settimanalmente. Essi devono essere archiviati manualmente da un amministratore se lo spazio libero su disco per il log di audit è inferiore ai dati contenuti nel log di audit che si prevede di produrre in quella settimana.
5.4.3.Periodo di conservazione dei log di audit
(249)I log relativi ai cicli di vita dei certificati vengono conservati per almeno cinque anni dopo la scadenza del certificato corrispondente.
5.4.4.Protezione dei log di audit
(250)L'integrità e la riservatezza dei log di audit sono garantite da un meccanismo di controllo degli accessi basato su ruolo. I log di audit interni sono accessibili solo agli amministratori; i log di audit relativi al ciclo di vita dei certificati sono accessibili anche agli utenti opportunamente autorizzati mediante una pagina web con login utente. Deve essere consentito l'accesso multi-utente (almeno due utenti) con almeno un'autenticazione a due livelli. Deve essere tecnicamente impossibile per gli utenti accedere ai propri file di log.
(251)Ciascuna voce del log deve essere firmata utilizzando il materiale della chiave dell'HSM.
(252)I log degli eventi contenenti informazioni che possono portare all'identificazione personale, quali i dati di un veicolo privato, sono cifrati in modo tale che solo le persone autorizzate possano leggerli.
(253)Gli eventi sono registrati nel log in modo tale da non poter essere facilmente cancellati o distrutti (se non per il trasferimento su un supporto dati a lungo termine) nel periodo in cui devono essere conservati.
(254)I log degli eventi sono protetti in modo da rimanere leggibili per la durata del loro periodo di conservazione.
5.4.5.Procedure di backup dei log di audit
(255)Il backup dei log di audit e delle rispettive sintesi avviene mediante i meccanismi di backup dell'impresa, sotto il controllo dei ruoli di fiducia autorizzati, separatamente rispetto ai componenti che li hanno generati. I backup dei log di audit sono protetti con lo stesso livello di fiducia che si applica ai log originali.
5.4.6.Sistema di raccolta degli audit (interno o esterno)
(256)Le apparecchiature degli elementi del modello di fiducia C-ITS devono attivare i processi di audit all'avvio del sistema e disattivarli solo quando il sistema viene spento. Se i processi di audit non sono disponibili, l'elemento del modello di fiducia C-ITS deve sospendere il suo funzionamento.
(257)Alla fine di ciascun periodo di funzionamento e del re-keying dei certificati, lo status complessivo delle apparecchiature deve essere comunicato al gestore delle operazioni e all'organismo che disciplina le operazioni del rispettivo elemento della PKI.
5.4.7.Notifica al soggetto che provoca l'evento
(258)Il fatto che un evento sia registrato dal sistema di raccolta degli audit garantisce che l'evento è collegato a un ruolo di fiducia.
5.4.8.Valutazione delle vulnerabilità
(259)Il ruolo incaricato di effettuare l'audit e i ruoli incaricati di effettuare le operazioni di sistema della PKI negli elementi del modello di fiducia C-ITS spiegano tutti gli eventi significativi in una sintesi del log di audit. Tali revisioni implicano la verifica che il log non sia stato manomesso e che non vi siano discontinuità o altre perdite di dati di audit. Successivamente vengono ispezionate brevemente tutte le voci del log, conducendo indagini più accurate per tutti i messaggi di allerta o le irregolarità nei log. Le misure adottate in seguito ai risultati di tali revisioni sono documentate.
(260)Gli elementi del modello di fiducia C-ITS devono:
·implementare il rilevamento tecnico e/o dell'organizzazione e i controlli di prevenzione sotto il controllo degli elementi del modello di fiducia C-ITS per proteggere i sistemi della PKI da virus e software malevoli;
·documentare e seguire un processo di correzione delle vulnerabilità volto a rispondere alle stesse nonché alla loro identificazione, revisione e riparazione;
·sottoporsi o effettuare una scansione delle vulnerabilità:
·dopo ogni modifica della rete e del sistema considerata dagli elementi del modello di fiducia C-ITS come significativa per i componenti della PKI; e
·almeno una volta al mese, sugli indirizzi IP pubblici e privati identificati da CA e CPOC come sistemi della PKI,
·sottoporsi a una prova di penetrazione relativa ai sistemi della PKI almeno su base annuale e dopo modifiche o aggiornamenti dell'applicazione o dell'infrastruttura considerati dagli elementi del modello di fiducia C-ITS come significativi per i componenti PKI della CA;
·per i sistemi online, registrare prove che dimostrino che ciascuna scansione delle vulnerabilità e prova di penetrazione è stata effettuata da una persona o entità (o rispettivo gruppo collettivo) dotata di abilità, strumenti, competenze, etica e indipendenza necessari per fornire una prova di penetrazione o delle vulnerabilità affidabile;
·tracciare le vulnerabilità e porvi rimedio, in linea con le politiche in materia di cibersicurezza e con la metodologia di attenuazione dei rischi dell'impresa.
5.5.Archiviazione delle registrazioni
5.5.1.Tipi di registrazioni archiviate
(261)Le registrazioni archiviate dagli elementi del modello di fiducia C-ITS devono essere sufficientemente dettagliate in modo che si possa stabilire la validità della firma e che la PKI funzioni correttamente. Come minimo devono essere archiviate le seguenti registrazioni di eventi della PKI (se del caso):
·log degli accessi fisici agli impianti degli elementi del modello di fiducia C-ITS (minimo un anno);
·log della gestione dei ruoli di fiducia degli elementi del modello di fiducia C-ITS (minimo 10 anni);
·log degli accessi IT per gli elementi del modello di fiducia C-ITS (minimo cinque anni);
·log relativo alla creazione, all'uso e alla distruzione delle chiavi della CA (minimo cinque anni) (non per TLM e CPOC);
·log relativo alla creazione, all'uso e alla distruzione dei certificati (minimo due anni);
·log delle richieste della CPA (minimo due anni);
·log della gestione dei dati di attivazione degli elementi del modello di fiducia C-ITS (minimo cinque anni);
·log della rete e dell'IT per gli elementi del modello di fiducia C-ITS (minimo cinque anni);
·documentazione della PKI per gli elementi del modello di fiducia C-ITS (minimo cinque anni);
·relazione relativa all'audit e agli incidenti di sicurezza per gli elementi del modello di fiducia C-ITS (minimo 10 anni);
·apparecchiature, software e configurazione di sistema (minimo cinque anni).
(262)Gli elementi del modello di fiducia C-ITS devono conservare la seguente documentazione relativa alle richieste di certificati e alla verifica degli stessi, e a tutti i certificati del TLM, della CA radice e della CA, e alle relative CRL per almeno sette anni dopo il termine della validità di qualsiasi certificato basato su tale documentazione:
·documentazione relativa agli audit della PKI conservata dagli elementi del modello di fiducia C-ITS;
·documenti del CPS conservati dagli elementi del modello di fiducia C-ITS;
·contratto tra CPA e altre entità conservato dagli elementi del modello di fiducia C-ITS;
·certificati (o altre informazioni di revoca) conservate dalla CA e dal TLM;
·registrazioni delle richieste di certificati nel sistema della CA radice (non applicabile al TLM);
·altri dati o applicazioni sufficienti per verificare i contenuti dell'archivio;
·tutto il lavoro degli auditor della conformità e degli elementi del modello di fiducia C-ITS o relativo agli stessi.
(263)L'entità della CA deve conservare tutta la documentazione relativa alle richieste di certificati e alla verifica degli stessi, e a tutti i certificati e le revoche per almeno sette anni dopo il termine della validità di qualsiasi certificato basato su tale documentazione.
5.5.2.Periodo di conservazione degli archivi
(264)Fatti salvi i regolamenti che richiedono un periodo di archiviazione più lungo, gli elementi del modello di fiducia C-ITS devono conservare tutte le registrazioni per almeno cinque anni dalla scadenza del certificato corrispondente.
5.5.3.Protezione degli archivi
(265)Gli elementi del modello di fiducia C-ITS devono conservare l'archivio delle registrazioni in un deposito sicuro separato dalle apparecchiature della CA, con controlli di sicurezza fisici e procedurali pari o superiori a quelli della PKI.
(266)L'archivio deve essere protetto da visualizzazioni, modifiche o cancellazioni non autorizzate o da qualsiasi altra manomissione mediante la conservazione in un sistema affidabile.
(267)I supporti dei dati di archivio e le applicazioni necessarie a trattarli devono essere sottoposti a manutenzione al fine di garantire che siano accessibili per il periodo stabilito nella presente CP.
5.5.4.Archivio di sistema e conservazione
(268)Gli elementi del modello di fiducia C-ITS devono effettuare quotidianamente backup incrementali degli archivi di sistema di tali informazioni e settimanalmente backup completi. Le copie delle registrazioni cartacee devono essere mantenute in una struttura sicura esternamente al sito.
5.5.5.Requisiti per la marcatura temporale delle registrazioni
(269)Gli elementi del modello di fiducia C-ITS che gestiscono una banca dati delle revoche deve garantire che le registrazioni contengano informazioni relative alla data e all'ora di creazione delle registrazioni di revoca. L'integrità di tali informazioni sarà implementata mediante soluzioni su base crittografica.
5.5.6.Sistema di raccolta degli archivi (interno o esterno)
(270)Il sistema di raccolta degli archivi è interno.
5.5.7.Procedure per l'acquisizione e la verifica delle informazioni di archivio
(271)Tutti gli elementi del modello di fiducia C-ITS devono consentire solo alle persone di fiducia autorizzate di accedere all'archivio. La CA radice e le CA devono descrivere nel CPS le procedure per creare, verificare, confezionare, trasmettere e conservare informazioni di archivio.
(272)La CA radice e le apparecchiature della CA devono verificare l'integrità delle informazioni prima del loro ripristino.
5.6.Sostituzione della chiave per gli elementi del modello di fiducia C-ITS
(273)I seguenti elementi del modello di fiducia C-ITS hanno requisiti specifici per la sostituzione della chiave: certificati di TLM, CA radice e EA/AA.
5.6.1.TLM
(274)Il TLM deve cancellare la sua chiave privata alla scadenza del certificato corrispondente. Prima della disattivazione della attuale chiave privata valida deve generare una nuova coppia di chiavi e il corrispondente certificato del TLM. Deve inoltre assicurarsi che il nuovo certificato (di collegamento) sia inserito nell'ECTL in tempo per essere distribuito a tutte le stazioni C-ITS prima che diventi valido. Il certificato di collegamento e il nuovo certificato autofirmato sono trasferiti al CPOC.
5.6.2.CA radice
(275)La CA radice deve disattivare e cancellare la chiave privata attuale (comprese le chiavi di backup), in modo da non rilasciare certificati della EA/AA con una validità che vada oltre la validità del certificato della CA radice.
(276)La CA radice deve generare una nuova coppia di chiavi e il corrispondente certificato di collegamento e della CA radice prima della disattivazione della chiave privata attuale (comprese le chiavi di backup) e inviarla al TLM per l'inserimento nell'ECTL. Il periodo di validità del nuovo certificato della CA radice deve iniziare al momento della disattivazione pianificata della attuale chiave privata. La CA radice deve assicurarsi che il nuovo certificato sia inserito nell'ECTL in tempo per essere distribuito a tutte le stazioni C-ITS prima che diventi valido.
(277)La CA radice deve attivare la nuova chiave privata nel momento in cui il corrispondente certificato della CA radice diventa valido.
5.6.3.Certificato della EA/AA
(278)La EA/AA deve disattivare la chiave privata attuale, in modo da non rilasciare EC e AT con una validità che vada oltre la validità del certificato della EA/AA.
(279)Prima della disattivazione della attuale chiave privata la EA/AA deve generare una nuova coppia di chiavi e il corrispondente certificato della EA/AA. Il periodo di validità del nuovo certificato della EA/AA deve iniziare al momento della disattivazione pianificata della attuale chiave privata. La EA/AA deve assicurarsi che il nuovo certificato possa essere pubblicato in tempo per essere distribuito a tutte le stazioni C-ITS prima che diventi valido.
(280)La EA/AA deve attivare la nuova chiave privata nel momento in cui il corrispondente certificato della EA/AA diventa valido.
5.6.4.Auditor
Nessuna disposizione.
5.7.Ripristino in caso di disastro e compromissione
5.7.1.Gestione degli incidenti e delle compromissioni
(281)Gli elementi del modello di fiducia C-ITS devono monitorare costantemente le loro apparecchiature, al fine di rilevare potenziali tentativi di hackeraggio o altre forme di compromissione. In tal caso devono svolgere indagini al fine di determinare la natura e il grado del danno.
(282)Se rileva un potenziale tentativo di hackeraggio o altre forme di compromissione, il personale responsabile della gestione della CA radice o del TLM deve svolgere indagini al fine di determinare la natura e il grado del danno. Nel caso di compromissione della chiave privata, il certificato della CA radice deve essere revocato. Gli esperti in materia di sicurezza informatica devono valutare la portata del danno potenziale al fine di determinare se è necessario ricostruire la PKI, se devono essere revocati solo alcuni certificati e/o se la PKI è stata compromessa. La CPA stabilisce inoltre quali servizi devono essere sottoposti a manutenzione (revoca e informazioni sullo status dei certificati) e in che modo questa deve avvenire, conformemente al piano di continuità operativa della CPA.
(283)Gli incidenti, le compromissioni e la continuità operativa sono compresi nel CPS, che può inoltre basarsi su altri piani o risorse aziendali per la sua attuazione.
(284)Se rileva un potenziale tentativo di hackeraggio o altre forme di compromissione, il personale responsabile della gestione di EA/AA/CPOC deve svolgere indagini al fine di determinare la natura e il grado del danno. Il personale responsabile della gestione dell'entità della CA o del CPOC deve valutare la portata del danno potenziale al fine di determinare se è necessario ricostruire il componente della PKI, se devono essere revocati solo alcuni certificati e/o se il componente della PKI è stato compromesso. L'entità della sub-CA stabilisce inoltre quali servizi devono essere sottoposti a manutenzione e in che modo questa deve avvenire, conformemente al piano di continuità operativa dell'entità della sub-CA. In caso di compromissione di un componente della PKI, l'entità della CA deve allertare la propria CA radice e il TLM mediante il CPOC.
(285)Gli incidenti, le compromissioni e la continuità operativa sono compresi nel CPS della CA radice o del TLM o in altri documenti pertinenti nel caso del CPOC, che può inoltre basarsi su altri piani o risorse dell'impresa per la loro attuazione.
(286)La CA radice e la CA devono allertare, inviando informazioni precise sulle conseguenze dell'incidente, ciascun rappresentante degli Stati membri e le CA radice con cui hanno concluso un accordo nel contesto dei C-ITS, al fine di consentire loro di attivare il proprio piano di gestione degli incidenti.
5.7.2.Risorse di calcolo, software e/o dati corrotti
(287)Se è stato rilevato un disastro che impedisce il funzionamento corretto di un elementi del modello di fiducia C-ITS, tale elemento deve sospendere il suo funzionamento e verificare se la chiave privata è stata compromessa (ad eccezione del CPOC). L'hardware difettoso deve essere sostituito il più rapidamente possibile e si applicano le procedure descritte nelle sezioni 5.7.3 e 5.7.4.
(288)La corruzione delle risorse di calcolo, del software o dei dati deve essere segnalata alla CA radice entro 24 ore per i livelli di rischio più elevati. Tutti gli altri eventi devono essere inclusi nella relazione periodica della CA radice, delle EA e delle AA.
5.7.3.Procedure in caso di compromissione della chiave privata dell'entità
(289)Se la chiave privata di una CA radice è stata compromessa, smarrita, distrutta o si sospetta che sia compromessa, la CA radice deve:
·sospenderne il funzionamento;
·avviare il piano di ripristino in caso di disastro e di migrazione;
·revocare il proprio certificato della CA radice;
·svolgere indagini in merito alla "questione chiave" che ha generato la compromissione e informare la CPA che revocherà il certificato della CA radice attraverso il TLM (cfr. la sezione 7);
·allertare tutti i sottoscrittori con i quali ha concluso un accordo.
(290)Se la chiave di una EA/AA è stata compromessa, smarrita, distrutta o si sospetta che sia compromessa, la EA/AA deve:
·sospenderne il funzionamento;
·revocare il proprio certificato;
·svolgere indagini in merito alla "questione chiave" e informare la CA radice;
·allertare i sottoscrittori con i quali ha concluso un accordo.
(291)Se la chiave delle EC o dell'AT di una stazione C-ITS è stata compromessa, smarrita, distrutta o si sospetta che sia compromessa, la EA/AA cui è iscritta la stazione C-ITS deve:
·revocare le EC dell'ITS interessato;
·svolgere indagini in merito alla "questione chiave" e informare la CA radice;
·allertare i sottoscrittori con i quali ha concluso un accordo.
(292)Qualora uno qualsiasi degli algoritmi o dei parametri associati usato dalla CA radice e/o dalla CA o dalle stazioni C-ITS diventi insufficiente per il restante utilizzo previsto, la CPA (con una raccomandazione degli esperti di crittografia) deve informare l'entità della CA radice con cui ha concluso un accordo e cambiare gli algoritmi utilizzati. (Per maggiori dettagli, cfr. la sezione 6 e i CPS di CA radice e sub-CA).
5.7.4.Capacità di continuità operativa dopo un disastro
(293)Gli elementi del modello di fiducia C-ITS che si servono di impianti sicuri per le operazioni di CA devono sviluppare, testare, tenere aggiornato e implementare un piano di ripristino in caso di disastro al fine di attenuare gli effetti di qualsiasi disastro naturale o provocato dall'uomo. Tale piano riguarda il ripristino dei servizi dei sistemi di informazione e le funzioni operative chiave.
(294)Dopo un incidente di un certo livello di rischio, la CA compromessa deve essere nuovamente sottoposta a audit da un auditor accreditato della PKI (cfr. sezione 8).
(295)Qualora la CA compromessa non sia più in grado di funzionare (ad esempio a seguito di un incidente grave), deve essere istituito un piano di migrazione per il trasferimento delle sue funzioni ad un'altra CA radice. Almeno la CA radice dell'UE deve essere disponibile a sostenere il piano di migrazione. La CA compromessa deve interrompere le proprie funzioni.
(296)La CA radice deve includere nel CPS il piano di ripristino in caso di disastro e il piano di migrazione.
5.8.Cessazione e trasferimento
5.8.1.TLM
(297)Il TLM non deve cessare le proprie attività, ma un'entità che gestisce il TLM può subentrare a un'altra entità.
(298)Nel caso in cui l'entità che lo gestisce cambi:
·deve essere richiesta l'approvazione della CPA per il cambiamento della gestione del TLM dalla vecchia entità alla nuova;
·la CPA deve approvare il cambiamento di gestione del TLM;
·tutti i log di audit e le registrazioni archiviate devono essere trasferiti dalla vecchia entità di gestione alla nuova.
5.8.2.CA radice
(299)La CA radice non deve cessare/iniziare la propria attività senza stabilire un piano di migrazione (definito nel pertinente CPS) che garantisca le operazioni in corso per tutti i sottoscrittori.
(300)Nel caso di cessazione del servizio della CA radice, essa deve:
·informare la CPA;
·informare il TLM in modo che questi possa cancellare il certificato della CA radice dall'ECTL;
·revocare la corrispondente CA radice rilasciando una CRL che contiene se stessa;
·allertare le CA radice con le quali ha concluso un accordo per il rinnovo dei certificati della EA/AA;
·distruggere la chiave privata della CA radice;
·comunicare le informazioni più recenti sullo stato della revoca (CRL firmato dalla CA radice) alla relying party, indicando chiaramente che si tratta delle informazioni di revoca più recenti;
·archiviare tutti i log di audit e le altre registrazioni prima della cessazione del funzionamento della PKI;
·trasferire gli accordi archiviati a un'autorità opportuna.
(301)Il TLM deve cancellare il corrispondente certificato della CA radice dall'ECTL.
5.8.3.EA/AA
(302)In caso di cessazione del servizio della EA/AA, l'entità della EA/AA deve comunicarlo prima della cessazione. La EA o la AA non deve cessare/iniziare la propria attività senza stabilire un piano di migrazione (definito nel pertinente CPS) che garantisca le operazioni in corso per tutti i sottoscrittori. La EA/AA deve:
·informare la CA radice mediante lettera raccomandata;
·distruggere la chiave privata della CA;
·trasferire la sua banca dati all'entità designata dalla CA radice;
·interrompere il rilascio di certificati;
·durante il trasferimento della sua banca dati e fino a che quest'ultima non sia pienamente operativa in una nuova entità, mantenere la capacità di autorizzare le richieste dell'autorità responsabile per la tutela della vita privata;
·qualora una sub-CA sia stata compromessa, la CA radice deve revocare la sub-CA e rilasciare una nuova CRL con un elenco delle sub-CA revocate;
·archiviare tutti i log di audit e le altre registrazioni prima della cessazione del funzionamento della PKI;
·trasferire le registrazioni archiviate all'entità designata dalla CA radice.
(303)In caso di cessazione dei servizi della CA, quest'ultima deve essere responsabile per il mantenimento di tutte le registrazioni pertinenti relative alle necessità dei componenti della CA e della PKI.
6.Controlli tecnici di sicurezza
6.1.Generazione e installazione della coppia di chiavi
6.1.1.TLM, CA radice, EA e AA
(304)Il processo di generazione della coppia di chiavi deve soddisfare i seguenti requisiti:
·ciascun partecipante deve essere in grado di generare le proprie coppie di chiavi in conformità alle sezioni 6.1.4 e 6.1.5;
·il processo di derivazione di chiavi di cifratura simmetriche e di una chiave MAC per le richieste di certificati (ECIES) deve essere effettuato in linea con i riferimenti [1] e [5];
·il processo di generazione della chiave deve utilizzare gli algoritmi e le lunghezze delle chiavi descritti nelle sezioni 6.1.4.1 e 6.1.4.2;
·il processo di generazione della coppia di chiavi deve essere soggetto ai requisiti di "conservazione sicura delle chiavi private" (cfr. la sezione 6.1.5);
·le CA radice e i loro sottoscrittori (le sub-CA) devono garantire il mantenimento dell'integrità e dell'autenticità delle loro chiavi pubbliche e di qualsiasi parametro associato durante la distribuzione alle entità registrate presso le sub-CA.
6.1.2.EE - stazione C-ITS mobile
(305)Ciascuna stazione C-ITS mobile deve generare le proprie coppie di chiavi in conformità alle sezioni 6.1.4 e 6.1.5.
(306)Il processo di derivazione di chiavi di cifratura simmetriche e di una chiave MAC per le richieste di certificati (ECIES) deve essere effettuato in linea con i riferimenti [1] e [5].
(307)I processi di generazione delle chiavi devono utilizzare gli algoritmi e le lunghezze delle chiavi descritti nelle sezioni 6.1.4.1 e 6.1.4.2.
(308)I processi di generazione delle coppie di chiavi devono essere soggetti ai requisiti di "conservazione sicura delle chiavi private" (cfr. la sezione 6.1.5).
6.1.3.EE - stazione C-ITS fissa
(309)Ciascuna stazione C-ITS fissa deve generare la propria coppia di chiavi in conformità alle sezioni 6.1.4 e 6.1.5.
(310)I processi di generazione delle chiavi devono utilizzare gli algoritmi e le lunghezze delle chiavi descritti nelle sezioni 6.1.4.1 e 6.1.4.2.
(311)I processi di generazione delle coppie di chiavi devono essere soggetti ai requisiti di "conservazione sicura delle chiavi private" (cfr. la sezione 6.1.5).
6.1.4.Requisiti crittografici
(312)Tutti i partecipanti alla PKI devono soddisfare i requisiti crittografici di cui ai seguenti paragrafi per quanto riguarda l'algoritmo di firma, la lunghezza della chiave, il generatore di numeri casuali e i certificati di collegamento.
6.1.4.1.Algoritmo e lunghezza della chiave - algoritmi di firma
(313)Tutti i partecipanti alla PKI (TLM, CA radice, EA, AA e stazioni C-ITS) devono essere in grado di generare coppie di chiavi e di usare la chiave privata per operazioni di firma con algoritmi selezionati entro due anni dall'entrata in vigore del presente regolamento in conformità alla tabella 4.
(314)Tutti i partecipanti alla PKI che devono verificare l'integrità dell'ECTL, dei certificati e/o dei messaggi firmati conformemente al loro ruolo, come definito nella sezione 1.3.6, devono supportare i corrispondenti algoritmi elencati nella tabella 5 a fini di verifica. In particolare le stazioni C-ITS devono essere in grado di verificare l'integrità dell'ECTL.
|
TLM
|
CA radice
|
EA
|
AA
|
stazione C-ITS
|
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 che devono essere supportati obbligatoriamente
|
Tabella 4: generazione delle coppie di chiavi e uso della chiave privata per le operazioni di firma
|
TLM
|
CA radice
|
EA
|
AA
|
stazione C-ITS
|
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 che devono essere supportati obbligatoriamente
|
Tabella 5: panoramica della verifica
(315)Tutte le stazioni C-ITS devono essere in grado di passare a uno dei due algoritmi (ECDSA_nistP256_with_SHA 256 o ECDSA_brainpoolP256_with_SHA 256) quanto prima, se la CPA ha preso una decisione in tal senso sulla base di debolezze crittografiche recentemente riscontrate. Gli algoritmi che vengono effettivamente utilizzati devono essere stabiliti nel CPS della CA che rilascia il certificato con la corrispondente chiave pubblica, conformemente alla presente CP.
6.1.4.2.Algoritmo e lunghezza della chiave - algoritmi di cifratura per le registrazione e l'autorizzazione
(316)Tutti i partecipanti alla PKI (EA, AA e stazioni C-ITS) devono essere in grado di usare le chiavi pubbliche per la cifratura delle richieste/risposte di registrazione e autorizzazione con algoritmi selezionati entro due anni dall'entrata in vigore del presente regolamento in conformità alla tabella 6. Gli algoritmi che vengono effettivamente utilizzati devono essere stabiliti nel CPS della CA che rilascia il certificato con la corrispondente chiave pubblica, conformemente alla presente CP.
(317)Gli algoritmi riportati nella tabella 6 indicano la lunghezza della chiave e la lunghezza dell'algoritmo di hash e devono essere implementati in conformità al riferimento [5].
|
TLM
|
CA radice
|
EA
|
AA
|
stazione C-ITS
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X indica che devono essere supportati obbligatoriamente
|
Tabella 6: uso delle chiavi pubbliche per la cifratura delle richieste/risposte di registrazione e autorizzazione
(318)Tutti i partecipanti alla PKI (EA, AA e stazioni C-ITS) devono essere in grado di generare coppie di chiavi e usare la chiave privata per la decifratura delle richieste/risposte di registrazione e autorizzazione con algoritmi selezionati entro due anni dall'entrata in vigore del presente regolamento in conformità alla tabella 7.
|
TLM
|
CA radice
|
EA
|
AA
|
stazione C-ITS
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X indica che devono essere supportati obbligatoriamente
|
Tabella 7: generazione di coppie di chiavi e uso della chiave privata per la decifratura delle richieste/risposte di registrazione e autorizzazione
6.1.4.3.Crypto-agility (agilità crittografica)
(319)I requisiti relativi alle lunghezze delle chiavi e agli algoritmi devono essere modificati nel tempo per mantenere un livello di sicurezza adeguato. La CPA deve monitorare la necessità di tali modifiche alla luce delle effettive vulnerabilità e dello stato dell'arte della crittografia. La CPA redigerà, approverà e pubblicherà un aggiornamento della politica dei certificati se decide che gli algoritmi crittografici dovrebbero essere aggiornati. Qualora un nuovo rilascio della presente CP segnali una modifica dell'algoritmo e/o della lunghezza della chiave, la CPA adotterà una strategia di migrazione, che includa periodi di transizione durante i quali devono essere supportati gli algoritmi e le lunghezze delle chiavi precedenti.
(320)Al fine di consentire e facilitare il trasferimento a nuovi algoritmi e/o a nuove lunghezze delle chiavi, si raccomanda che tutti i partecipanti alla PKI implementino hardware e/o software che consentano di sostituire gli algoritmi e/o le lunghezze delle chiavi.
(321)Le modifiche dei certificati del TLM e radice devono essere supportate ed eseguite con l'ausilio di certificati di collegamento (cfr. sezione 4.6) usati nel periodo di transizione tra i vecchi e i nuovi certificati radice ("migrazione del modello di fiducia").
6.1.5.Conservazione sicura delle chiavi private
La presente sezione descrive i requisiti per la conservazione e la generazione sicure di coppie di chiavi e numeri casuali per CA e entità finali. Tali requisiti sono definiti per i moduli crittografici e descritti nelle sottosezioni seguenti.
6.1.5.1.Livello della CA radice, della sub-CA e del TLM
(322)Un modulo crittografico deve essere usato per:
·generare, usare, amministrare e conservare le chiavi private;
·generare e usare numeri casuali (la valutazione della funzione di generazione dei numeri casuali deve far parte della valutazione e della certificazione di sicurezza);
·creare backup di chiavi private conformemente alla sezione 6.1.6;
·cancellare chiavi private.
Il modulo crittografico deve essere certificato con uno dei seguenti profili di protezione (PP), con un livello di garanzia EAL-4 o superiore:
·PP per gli HSM:
·CEN EN 419 221-2: Protection profiles for TSP cryptographic modules – Part 2: Cryptographic module for CSP signing operations with backup (Profili di protezione per i moduli crittografici TSP - Parte 2: modulo crittografico per le operazioni di firma dei CSP con backup);
·CEN EN 419 221-4: Protection profiles for TSP cryptographic modules – Part 4: Cryptographic module for CSP signing operations without backup (Profili di protezione per i moduli crittografici TSP - Parte 4: modulo crittografico per le operazioni di firma dei CSP senza backup);
·CEN EN 419 221-5: Protection profiles for TSP cryptographic modules – Part 5: Cryptographic module for trust services (Profili di protezione per i moduli crittografici TSP - Parte 5: modulo crittografico per i servizi di fiducia);
·PP per smart card:
·CEN EN 419 211-2: Protection profiles for secure signature creation device – Part 2: Device with key generation (Profili di protezione per dispositivi di creazione della firma sicuri - Parte 2: dispositivo con generazione della chiave);
·CEN EN 419 211-3: Protection profiles for secure signature creation device – Part 3: Device with key import (Profili di protezione per dispositivi di creazione della firma sicuri - Parte 3: dispositivo con importazione della chiave).
L'accesso manuale al modulo crittografico deve richiedere all'amministratore un'autenticazione a due fattori. Inoltre deve richiedere il coinvolgimento di due persone autorizzate.
L'implementazione di un modulo crittografico deve garantire che le chiavi non siano accessibili al di fuori del modulo crittografico. Il modulo crittografico deve includere un meccanismo di controllo degli accessi per impedire l'uso non autorizzato di chiavi private.
6.1.5.2.Entità finale
(323)Un modulo crittografico per le EE deve essere usato per:
·generare, usare, amministrare e conservare le chiavi private;
·generare e usare numeri casuali (la valutazione della funzione di generazione dei numeri casuali deve far parte della valutazione e della certificazione di sicurezza);
·cancellare una chiave privata in modo sicuro.
(324)Il modulo crittografico deve essere protetto da rimozione, sostituzione e modifica non autorizzate. Tutti i PP e i relativi documenti applicabili per la certificazione di sicurezza del modulo crittografico devono essere valutati, convalidati e certificati in conformità alla norma ISO 15408, applicando l'Accordo sul reciproco riconoscimento dei certificati di valutazione della sicurezza delle tecnologie dell'informazione del gruppo di alti funzionari competente in materia di sicurezza dei sistemi d'informazione (SOG-IS), o un sistema europeo di certificazione della cibersicurezza equivalente nell'ambito del pertinente quadro europeo della cibersicurezza.
(325)Data l'importanza di mantenere il massimo livello di sicurezza possibile, i certificati di sicurezza per il modulo crittografico devono essere rilasciati nell'ambito del sistema di certificazione Common Criteria (ISO 15408) da un organismo di valutazione della conformità riconosciuto dal comitato di gestione nel quadro dell'Accordo SOG-IS, oppure rilasciato da un organismo di valutazione della conformità accreditato da un'autorità nazionale di certificazione della cibersicurezza di uno Stato membro. Tale organismo di valutazione della conformità deve fornire condizioni almeno equivalenti alla valutazione della sicurezza prevista dall'Accordo sul reciproco riconoscimento SOG-IS.
Nota: il collegamento tra il modulo crittografico e la stazione C-ITS deve essere protetto.
6.1.6.Backup delle chiavi private
(326)La generazione, la conservazione e l'uso dei backup delle chiavi private devono soddisfare almeno i requisiti del livello di sicurezza richiesto per le chiavi originali.
(327)I backup delle chiavi private devono essere effettuati dalle CA radice, dalle EA e dalle AA.
(328)I backup delle chiavi private non devono essere effettuati per le EC e gli AT.
6.1.7.Distruzione delle chiavi private
(329)Le CA radice, EA, AA e le stazioni C-ITS fisse e mobili devono distruggere le loro chiavi private e qualsiasi backup corrispondente se una nuova coppia di chiavi e un certificato corrispondente sono stati generati e successivamente installati e se il periodo di sovrapposizione (se del caso, solo per le CA) tra le nuove e le vecchie chiavi è terminato. La chiave privata deve essere distrutta mediante il meccanismo offerto dal modulo crittografico usato per la conservazione della chiave o nel modo descritto nel corrispondente PP di cui alla sezione 6.1.5.2.
6.2.Dati di attivazione
(330)I dati di attivazione si riferiscono ai fattori di autenticazione richiesti per l'utilizzo dei moduli crittografici, al fine di impedire l'accesso non autorizzato. L'uso di dati di attivazione di un dispositivo crittografico della CA deve richiedere un'azione da parte di due persone autorizzate.
6.3.Controlli di sicurezza del computer
(331)I controlli di sicurezza dei computer delle CA devono essere progettati in conformità al livello di sicurezza elevato rispettando i requisiti di cui alla norma ISO/IEC 27002.
6.4.Controlli tecnici del ciclo di vita
(332)I controlli tecnici della CA devono riguardare l'intero ciclo di vita della CA. In particolare ciò include i requisiti della sezione 6.1.4.3 ["Crypto-agility (agilità crittografica)"].
6.5.Controlli di sicurezza della rete
(333)Le reti delle CA (CA radice, EA e AA) devono essere resistenti agli attacchi, in linea con i requisiti e gli orientamenti in materia di implementazione delle norme ISO/IEC 27001 e ISO/IEC 27002.
(334)La disponibilità delle reti della CA deve essere progettata in funzione del traffico stimato.
7.Profili dei certificati, CRL e CTL
7.1.Profilo dei certificati
(335)I profili dei certificati di cui al riferimento [5] devono essere utilizzati per il TLM, i certificati radice, i certificati della EA, i certificati della AA, gli AT e le EC. Le EA nazionali governative possono utilizzare altri profili dei certificati per le EC.
(336)I certificati della CA radice, della EA e della AA devono indicare i permessi per i quali queste CA (CA radice, EA e AA) sono autorizzate a rilasciare certificati.
(337)In base al riferimento [5]:
·ciascuna CA radice deve usare la propria chiave privata di firma per rilasciare le CRL;
·il TLM deve usare la propria chiave privata di firma per rilasciare le l'ECTL.
7.2.Validità dei certificati
(338)Tutti i profili dei certificati C-ITS devono includere una data di rilascio e una data di scadenza, che delimitano il periodo di validità del certificato. A ciascun livello della PKI, i certificati devono essere generati per tempo prima della scadenza.
(339)Il periodo di validità dei certificati della CA e delle EC deve comprendere un periodo di sovrapposizione. I certificati del TLM e della CA radice devono essere rilasciati e inseriti nell'ECTL da un minimo di un mese a un massimo di tre mesi prima dell'inizio della loro validità in base al momento di inizio indicato nei certificati. Questa fase di pre-caricamento è necessaria per distribuire in sicurezza i certificati a tutte le corrispondenti relying parties, in conformità alla sezione 2.2. Ciò garantisce che, a partire dall'inizio del periodo di sovrapposizione, tutte le relying parties siano già in grado di verificare i messaggi rilasciati con un nuovo certificato.
(340)All'inizio del periodo di sovrapposizione, i successivi certificati della CA, delle EC e dell'AT devono essere rilasciati (se del caso) e distribuiti alle corrispondenti relying parties e installati dalle stesse. Durante il periodo di sovrapposizione, l'attuale certificato deve essere utilizzato solo a scopo di verifica.
(341)Poiché i periodi di validità di cui alla tabella 8 non devono superare il periodo di validità del certificato di livello superiore, si applicano le seguenti restrizioni:
·maximumvalidity(Root CA) = privatekeyusage(Root CA) + maximumvalidity(EA,AA);
·maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC);
·maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(AT).
(342)La validità dei certificati di collegamento (radice e del TLM) inizia nel momento in cui viene usata la corrispondente chiave privata e termina allo scadere del periodo massimo di validità della CA radice o del TLM.
(343)La tabella 8 riporta il periodo massimo di validità per i certificati C-ITS della CA (per i periodi di validità dell'AT, cfr. la sezione 7.2.1).
Entità
|
Periodo massimo di uso della chiave privata
|
Periodo massimo di validità
|
CA radice
|
3 anni
|
8 anni
|
EA
|
2 anni
|
5 anni
|
AA
|
4 anni
|
5 anni
|
EC
|
3 anni
|
3 anni
|
TLM
|
3 anni
|
4 anni
|
Tabella 8: periodi di validità dei certificati nel modello di fiducia C-ITS
7.2.1.Certificati pseudonimi
(344)In questo contesto gli pseudonimi sono implementati dagli AT. Pertanto la presente sezione si riferisce agli AT piuttosto che agli pseudonimi.
(345)I requisiti di cui alla presente sezione si applicano solo agli AT di stazioni C-ITS mobili che inviano messaggi CAM e DENM, in cui sia presente un rischio per la privacy della posizione. Non si applicano requisiti specifici ai certificati degli AT delle stazioni C-ITS fisse e delle stazioni C-ITS mobili usate per funzioni speciali in cui la privacy della posizione non è rilevante (ad esempio in caso di emergenza o per i veicoli delle forze dell'ordine).
(346)Si applicano le seguenti definizioni:
·"periodo di validità per gli AT": il periodo in cui un AT è valido, vale a dire il periodo compreso tra la data di inizio e la data di scadenza dell'AT;
·"periodo di pre-caricamento per gli AT": per pre-caricamento si intende la possibilità per le stazioni C-ITS di ottenere gli AT prima dell'inizio del periodo di validità. Il periodo di pre-caricamento è il massimo periodo di tempo consentito che intercorre dalla richiesta degli AT al termine ultimo del periodo di validità di qualsiasi AT richiesto;
·"periodo di uso per gli AT": il periodo in cui un AT viene effettivamente usato per firmare i messaggi CAM/DENM;
·"numero massimo di AT paralleli": il numero di AT che possono essere scelti da una stazione C-ITS in un dato momento per firmare un messaggio CAM/DENM, vale a dire il numero di AT diversi rilasciati a una stazione C-ITS che sono validi nello stesso momento.
(347)Si applicano i seguenti requisiti:
·il periodo di pre-caricamento dell'AT non deve essere superiore a tre mesi;
·il periodo di validità dell'AT non deve essere superiore a una settimana;
·il numero massimo di AT paralleli non essere superiore a 100 per stazione C-ITS;
·il periodo di uso di un AT dipende dalla strategia di modifica dell'AT e da quanto tempo il veicolo è in funzione, ma è limitato dal numero massimo di AT paralleli e dal periodo di validità. In particolare, il periodo di uso medio di una stazione C-ITS corrisponde almeno al tempo di funzionamento del veicolo durante un periodo di validità diviso per il numero massimo di AT paralleli.
7.2.2.Ticket di autorizzazione per le stazioni C-ITS fisse
(348)Si applicano le definizioni di cui alla sezione 7.2.1 e i seguenti requisiti:
·il periodo di pre-caricamento dell'AT non deve essere superiore a tre mesi;
·il numero massimo di AT paralleli non essere superiore a due per stazione C-ITS.
7.3.Revoca dei certificati
7.3.1.Revoca dei certificati della CA, della EA e della AA
I certificati della CA radice, della EA e della AA devono essere revocabili. I certificati revocati delle CA radice, delle EA e delle AA devono essere pubblicati appena possibile e senza indebito ritardo in un CRL. Tale CRL deve essere firmato dalla corrispondente CA radice e usare il profilo descritto nella sezione 7.4. Per la revoca dei certificati della CA radice, la corrispondente CA radice rilascia un CRL che contiene sé stessa. In caso di compromissione della sicurezza si applica inoltre la sezione 5.7.3. Il TLM deve cancellare le CA radice revocate dall'elenco di fiducia e rilasciare un nuovo elenco di fiducia. I certificati scaduti devono essere eliminati dall'elenco di fiducia e dalla CRL corrispondenti.
(349)I certificati sono revocati se:
·la CA radice ha ragione di credere o di nutrire forti sospetti che la corrispondente chiave privata sia stata compromessa;
·le CA radice sono state informate che il contratto con il sottoscrittore è stato rescisso;
·le informazioni (quali nome e associazioni tra CA e soggetto) nel certificato non sono corrette o sono cambiate;
·si è verificato un incidente di sicurezza che interessa il titolare del certificato;
·un audit (cfr. la sezione 8) ha dato esito negativo.
(350)Il sottoscrittore deve informare immediatamente la CA delle compromissioni note o sospette della sua chiave privata. Deve essere garantito che solo le richieste autenticate provochino la revoca dei certificati.
7.3.2.Revoca delle credenziali di registrazione
(351)La revoca delle EC può essere avviata dal sottoscrittore della stazione C-ITS (flusso 34) e deve essere implementata mediante una blacklist interna in una banca dati di revoca con una marcatura temporale, generata e tenuta aggiornata da ciascuna EA. La blacklist non viene mai pubblicata e deve essere mantenuta riservata e utilizzata solo dalla corrispondente EA per verificare la validità delle corrispondenti EC nel contesto delle richieste di AT e di nuove EC.
7.3.3.Revoca dei ticket di autorizzazione
(352)Poiché non sono revocati dalle CA corrispondenti, gli AT hanno una durata di vita breve e non possono essere rilasciati con eccessivo anticipo prima di diventare validi. I valori ammissibili dei parametri del ciclo di vita del certificato sono indicati nella sezione 7.2.
7.4.Lista dei certificati revocati
(353)Il formato e il contenuto della CRL rilasciata dalle CA radice devono corrispondere a quanto stabilito al riferimento [1].
7.5.Elenco di fiducia europeo dei certificati
(354)Il formato e il contenuto dell'ECTL rilasciato dal TLM devono corrispondere a quanto stabilito al riferimento [1].
8.Audit di conformità e altre valutazioni
8.1.Tematiche oggetto dell'audit e base dell'audit
(355)Lo scopo di un audit di conformità è verificare che il TLM, la CA radice, le EA e le AA operino conformemente alla presente CP. Per sottoporre a audit il loro CPS, il TLM, le CA radice, le EA e le AA devono scegliere un auditor accreditato della PKI che agisca in modo indipendente. L'audit deve essere combinato con una valutazione ISO/IEC 27001 e ISO/IEC 27002.
(356)L'audit di conformità è ordinato da una CA radice (flusso 13) per la CA radice stessa e dalle EA/AA subordinate per la sub-CA.
(357)Un audit di conformità per il TLM è ordinato dalla CPA (flusso 38).
(358)Su richiesta l'auditor accreditato della PKI deve effettuare un audit di conformità su uno dei seguenti livelli:
(1)conformità di TLM, CA radice, EA e AA alla presente CP;
(2)conformità delle pratiche future di TLM, CA radice, EA e AA al rispettivo CPS prima del funzionamento;
(3)conformità delle pratiche e delle attività operative di TLM, CA radice, EA e AA al rispettivo CPS durante il funzionamento.
(359)L'audit deve riguardare tutti i requisiti della presente CP che devono essere soddisfatti da TLM, CA radice, EA e AA da sottoporre ad audit. Esso deve inoltre riguardare il funzionamento della CA nella PKI dei C-ITS, compresi tutti i processi menzionati nel suo CPS, le sedi e le persone responsabili.
(360)L'auditor accreditato della PKI deve fornire una relazione dettagliata dell'audit alla CA radice (flusso 36), alla EA, alla AA o alla CPA (flusso 16 e 40), a seconda dei casi.
8.2.Frequenza degli audit
(361)Una CA radice, un TLM, una EA o una AA deve ordinare un audit di conformità di se stesso/a da un auditor accreditato della PKI nei seguenti casi:
·alla prima installazione (livelli di conformità 1 e 2);
·a ogni modifica della CP. La CPA deve conseguentemente definire il contenuto della modifica della CP e il calendario per la sua attuazione e deve determinare gli audit necessari (compreso il necessario livello di conformità);
·a ogni modifica del CPS (livelli 1, 2 e 3 di conformità). Poiché decidono quali modifiche di implementazione seguono l'aggiornamento dei rispettivi CPS, le entità di gestione delle CA radice, del TLM e delle EA/AA devono ordinare un audit di conformità prima di implementare tali modifiche. Nel caso in cui al CPS vengano apportate esclusivamente modifiche minori (ad esempio di natura redazionale), l'entità di gestione può inviare alla CPA una richiesta debitamente giustificata per l'approvazione del CPS, al fine di tralasciare gli audit di conformità del livello 1, 2 o 3;
·regolarmente e almeno ogni tre anni nel corso del suo funzionamento (livello di conformità 3).
8.3.Identità/qualifiche dell'auditor
(362)La CA deve scegliere una organizzazione/una società indipendente ed accreditata ("organismo di audit") o un auditor accreditato della PKI che provveda al suo audit in conformità alla presente CP. L'organismo di audit deve essere accreditato e certificato da un membro dell'accreditamento europeo.
8.4.Relazione tra auditor e entità sottoposta a audit
(363)L'auditor accreditato della PKI deve essere indipendente dall'entità sottoposta a audit.
8.5.Misure adottate in caso di carenze
(364)Qualora dalla relazione di audit risulti che il TLM non è conforme, la CPA deve ordinare al TLM di adottare immediatamente azioni preventive/correttive.
(365)Qualora una CA radice oggetto di una relazione di audit in cui è risultata non conforme presenti una nuova domanda, la CPA deve rifiutare tale domanda e inviare un rifiuto corrispondente alla CA radice (flusso 4). In tal caso la CA radice è sospesa e deve adottare misure correttive, ordinare nuovamente l'audit e presentare una nuova richiesta di approvazione alla CPA. Alla CA radice non deve essere consentito di rilasciare certificati durante la sospensione.
(366)In occasione di un audit regolare della CA radice o di una modifica del CPS della CA radice e a seconda della natura della non conformità descritta nella relazione di audit, la CPA può decidere di revocare la CA radice e comunicare tale decisione al TLM (flusso 2), causando la cancellazione del certificato della CA radice dall'ECTL e l'inserimento della CA radice nel CRL. La CPA deve inviare un corrispondente rifiuto alla CA radice (flusso 4). La CA radice deve adottare misure correttive, ordinare nuovamente un audit completo (livelli da 1 a 3) e presentare una nuova richiesta di approvazione alla CPA. In alternativa la CPA può decidere di non revocare la CA radice, ma di accordarle un periodo di tolleranza in cui la CA radice deve adottare misure correttive, ordinare nuovamente un audit e ripresentare la relazione di audit alla CPA. In tal caso il funzionamento della CA radice deve essere sospesa e non deve esserle consentito il rilascio di certificati e CRL.
(367)Nel caso di un audit di una EA/AA, la CA radice deve decidere se accettare o no la relazione. A seconda del risultato dell'audit, la CA radice deve decidere se revocare il certificato della EA/AA in conformità alle norme contenute nei CPS della CA radice. La CA radice deve garantire in ogni momento il rispetto della presente CP da parte della EA/AA.
8.6.Comunicazione dei risultati
(368)La CA radice e il TLM devono inviare la relazione di audit al CPA (flusso 16). La CA radice e il TLM devono conservare tutte le relazioni di audit che hanno ordinato. La CPA deve inviare alla CA radice e al TLM un'approvazione o un rifiuto corrispondente (flusso 4).
(369)La CA radice deve inviare un certificato di conformità alle corrispondenti EA/AA.
9.Altre disposizioni
9.1.Tariffe
(370)Un principio del modello di fiducia C-ITS dell'UE implementato è che l'insieme delle CA radice finanziano integralmente i regolari costi di funzionamento ricorrenti della CPA e gli elementi centrali (TLM e CPOC) relativi alle attività di cui alla presente CP.
(371)Le CA radice (compresa la CA radice dell'UE) hanno il diritto di esigere tariffe dalle loro sub-CA.
(372)Durante tutto il periodo di funzionamento, ogni partecipante al modello di fiducia C-ITS deve avere accesso ad almeno una CA radice, EA e AA su base non discriminatoria.
(373)Ciascuna CA radice è autorizzata a trasferire le tariffe corrisposte per la CPA e gli elementi centrali (TLM e CPOC) ai partecipanti registrati del modello di fiducia C-ITS, comprese le stazioni C-ITS iscritte e autorizzate.
9.2.Responsabilità finanziaria
(374)Dall'istituzione iniziale di una CA radice deve trascorrere un periodo di almeno tre anni di attività affinché essa possa diventare un membro del modello di fiducia C-ITS dell'UE. Il CPS dell'operatore della CA radice deve inoltre contenere disposizioni dettagliate relative alla revoca e alla chiusura della CA radice.
(375)Ciascuna CA radice deve dimostrare per almeno tre anni la sostenibilità finanziaria della persona giuridica che la implementa. Tale piano di sostenibilità finanziaria fa parte della serie iniziale di documenti di registrazione e deve essere aggiornato ogni tre anni e comunicato alla CPA.
(376)Ciascuna CA radice deve comunicare al gestore delle operazioni e alla CPA la struttura delle tariffe imposte annualmente alle EA/AA e alle stazioni C-ITS iscritte e autorizzate, al fine di dimostrare la propria sostenibilità finanziaria.
(377)Tutte le entità responsabili finanziariamente e giuridicamente di CA radice, EA, AA e degli elementi centrali (CPOC e TLM) del modello di fiducia C-ITS devono essere munirsi di un'adeguata copertura assicurativa nello svolgimento dei propri compiti operativi, per la compensazione degli errori operativi o per il recupero finanziario dei loro compiti in caso di guasto di uno degli elementi tecnici.
9.3.Riservatezza delle informazioni aziendali
(378)Le seguenti informazioni devono essere mantenute private e riservate:
·registrazioni di domande di CA radice, EA, AA, sia approvate sia rifiutate;
·relazioni di audit di CA radice, EA, AA e TLM;
·piani di ripristino in caso di disastro di CA radice, EA, AA, CPOC e TLM;
·chiavi private degli elementi del modello di fiducia C-ITS (stazioni C-ITS, TLM, EA, AA, CA radice);
·qualsiasi altra informazione considerata riservata da CPA, CA radice, EA, AA, TLM e CPOC.
9.4.Piano per la tutela della privacy
(379)I CPS delle CA radice e delle EA/AA devono istituire il piano e stabilire i requisiti per il trattamento delle informazioni personali e della privacy sulla base del GDPR e di altri quadri legislativi (ad esempio nazionali) applicabili.
10.Riferimenti
Nel presente allegato si rimanda ai seguenti riferimenti.
[1]
|
ETSI TS 102 941 V1.2.1, Intelligent transport systems (ITS) – security, trust and privacy management [Sistemi di trasporto intelligenti (ITS) – sicurezza, fiducia e gestione della privacy].
|
[2]
|
ETSI TS 102 940 V1.3.1, Intelligent transport systems (ITS) – security, ITS communications security architecture and security management [Sistemi di trasporto intelligenti (ITS) – sicurezza, architettura della sicurezza delle comunicazioni e gestione della sicurezza].
|
[3]
|
Certificate policy and certification practices framework (Politica dei certificati e quadro delle pratiche di certificazione) (RFC 3647, 1999).
|
[4]
|
ETSI TS 102 042 V2.4.1 Policy requirements for certification authorities issuing public key certificates (Requisiti strategici per le autorità di certificazione che rilasciano certificati a chiave pubblica).
|
[5]
|
ETSI TS 103 097 V1.3.1, Intelligent transport systems (ITS) – security, security header and certificate formats [Sistemi di trasporto intelligenti (ITS) – sicurezza; formati dell'intestazione e del certificato di sicurezza].
|
[6]
|
Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide. (Sicurezza delle informazioni basata sulla norma ISO 27001/ISO 1779: guida alla gestione). Van Haren Publishing.
|
[7]
|
ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – information technology, security techniques, information security risk management (tecnologie dell'informazione, tecniche di sicurezza, gestione dei rischi per la sicurezza delle informazioni). ISO.
|
|
|