CUPRINS
1.Introducere9
1.1.Prezentare generală și domeniul de aplicare al prezentei politici9
1.2.Definiții și acronime11
1.3.Participanții la PKI14
1.3.1.Introducere14
1.3.2.Autoritatea responsabilă cu politica de certificare a C-ITS17
1.3.3.Managerul listei de încredere18
1.3.4.Auditorul acreditat al PKI18
1.3.5.Punctul de contact pentru C-ITS (CPOC)18
1.3.6.Roluri operaționale19
1.4.Utilizarea certificatelor20
1.4.1.Domenii de utilizare aplicabile20
1.4.2.Limitele responsabilității20
1.5.Administrarea politicii de certificare20
1.5.1.Actualizarea CPS-urilor CA-urilor listate în ECTL20
1.5.2.Procedurile de aprobare a CPS21
2.Responsabilități legate de publicare și de registru21
2.1.Metode de publicare a informațiilor referitoare la certificate21
2.2.Termenul sau frecvența de publicare22
2.3.Registre23
2.4.Controale ale accesului la registre23
2.5.Publicarea informațiilor referitoare la certificate24
2.5.1.Publicarea informațiilor referitoare la certificate de către TLM24
2.5.2.Publicarea informațiilor referitoare la certificate de către CA-uri24
3.Identificarea și autentificarea24
3.1.Alegerea numelor24
3.1.1.Tipuri de nume24
3.1.1.1.Nume pentru TLM, CA-uri primare, EA-uri, AA-uri24
3.1.1.2.Nume pentru entitățile finale25
3.1.1.3.Identificarea certificatelor25
3.1.2.Necesitatea ca numele să aibă sens25
3.1.3.Caracterul anonim și pseudonim al entităților finale25
3.1.4.Reguli de interpretare a diverselor forme ale numelor25
3.1.5.Caracterul unic al numelor25
3.2.Validarea inițială a identității26
3.2.1.Metoda de dovedire a posesiei cheii private26
3.2.2.Autentificarea identității organizației26
3.2.2.1.Autentificarea identității organizației CA primare26
3.2.2.2.Autentificarea identității organizației TLM27
3.2.2.3.Autentificarea identității organizației CA-urilor subordonate27
3.2.2.4.Autentificarea organizației abonatului entităților finale28
3.2.3.Autentificarea entității individuale28
3.2.3.1.Autentificarea entității individuale TLM/CA28
3.2.3.2.Autentificarea identității abonaților stațiilor C-ITS29
3.2.3.3.Autentificarea identității stațiilor C-ITS29
3.2.4.Informații neverificate despre abonați29
3.2.5.Validarea autorității29
3.2.5.1.Validarea TLM, CA primare, EA, AA29
3.2.5.2.Validarea abonaților stațiilor C-ITS30
3.2.5.3.Validarea stațiilor C-ITS30
3.2.6.Criterii de interoperare30
3.3.Identificarea și autentificarea în cazul solicitărilor de regenerare a cheii30
3.3.1.Identificarea și autentificarea în cazul solicitărilor de regenerare a cheii de rutină30
3.3.1.1.Certificatele TLM30
3.3.1.2.Certificatele CA primare30
3.3.1.3.Reînnoirea sau regenerarea cheii certificatului EA/AA31
3.3.1.4.Acreditările de înscriere ale entităților finale31
3.3.1.5.Tichetele de autorizare ale entităților finale31
3.3.2.Identificarea și autentificarea în cazul solicitărilor de regenerare a cheii după revocare31
3.3.2.1.Certificatele CA31
3.3.2.2.Acreditările de înscriere ale entităților finale31
3.3.2.3.Solicitările de autorizare ale entităților finale31
3.4.Identificarea și autentificarea în cazul solicitării revocării32
3.4.1.Certificatele CA primare/EA/AA32
3.4.2.Acreditările de înscriere ale stației C-ITS32
3.4.3.Tichetele de autorizare ale stației C-ITS32
4.Cerințele operaționale privind ciclul de viață al certificatelor32
4.1.Cererea de certificat32
4.1.1.Cine poate transmite o cerere de certificat33
4.1.1.1.CA-urile primare33
4.1.1.2.TLM33
4.1.1.3.EA și AA33
4.1.1.4.Stația C-ITS33
4.1.2.Procesul de înscriere și responsabilitățile aferente33
4.1.2.1.CA-urile primare33
4.1.2.2.TLM34
4.1.2.3.EA și AA34
4.1.2.4.Stația C-ITS35
4.2.Prelucrarea cererilor de certificate36
4.2.1.Efectuarea funcțiilor de identificare și de autentificare36
4.2.1.1.Identificarea și autentificarea CA-urilor primare36
4.2.1.2.Identificarea și autentificarea TLM36
4.2.1.3.Identificarea și autentificarea EA și AA36
4.2.1.4.Identificarea și autentificarea abonatului EE36
4.2.1.5.Tichete de autorizare36
4.2.2.Aprobarea sau respingerea cererilor de certificate36
4.2.2.1.Aprobarea sau respingerea certificatelor CA primare36
4.2.2.2.Aprobarea sau respingerea certificatului TLM37
4.2.2.3.Aprobarea sau respingerea certificatelor EA și AA37
4.2.2.4.Aprobarea sau respingerea EC37
4.2.2.5.Aprobarea sau respingerea AT37
4.2.3.Termenul de prelucrare a cererii de certificat37
4.2.3.1.Cererea de certificat al CA primare37
4.2.3.2.Solicitarea certificatului TLM37
4.2.3.3.Solicitarea certificatului EA și AA38
4.2.3.4.Solicitarea EC38
4.2.3.5.Solicitarea AT38
4.3.Emiterea certificatelor38
4.3.1.Acțiunile CA în timpul emiterii certificatelor38
4.3.1.1.Emiterea certificatului CA primare38
4.3.1.2.Emiterea certificatului TLM38
4.3.1.3.Emiterea certificatului EA și AA38
4.3.1.4.Emiterea EC38
4.3.1.5.Emiterea AT39
4.3.2.Notificarea abonatului de către CA cu privire la emiterea certificatelor.39
4.4.Acceptarea certificatului39
4.4.1.Derularea procesului de acceptare a certificatului39
4.4.1.1.CA primară39
4.4.1.2.TLM39
4.4.1.3.EA și AA39
4.4.1.4.Stația C-ITS39
4.4.2.Publicarea certificatului39
4.4.3.Notificarea emiterii certificatului40
4.5.Utilizarea perechii de chei și a certificatelor40
4.5.1.Utilizarea cheii private și a certificatelor40
4.5.1.1.Utilizarea cheii private și a certificatelor în cazul TLM40
4.5.1.2.Utilizarea cheii private și a certificatelor în cazul CA-urilor primare40
4.5.1.3.Utilizarea cheii private și a certificatelor în cazul EA-urilor și al AA-urilor40
4.5.1.4.Utilizarea cheii private și a certificatelor în cazul entității finale40
4.5.2.Utilizarea cheilor publice și a certificatelor de către părțile de încredere40
4.6.Reînnoirea certificatului41
4.7.Regenerarea cheii certificatului41
4.7.1.Circumstanțele regenerării cheii certificatului41
4.7.2.Cine poate solicita regenerarea cheii41
4.7.2.1.CA primară41
4.7.2.2.TLM41
4.7.2.3.EA și AA41
4.7.2.4.Stația C-ITS41
4.7.3.Procesul de regenerare a cheii41
4.7.3.1.Certificatul TLM41
4.7.3.2.Certificatul CA primare41
4.7.3.3.Certificatele EA și AA42
4.7.3.4.Certificatele stației C-ITS42
4.8.Modificarea certificatelor42
4.9.Revocarea și suspendarea certificatelor42
4.10.Serviciile legate de statutul certificatelor43
4.10.1.Caracteristici operaționale43
4.10.2.Disponibilitatea serviciului43
4.10.3.Caracteristici opționale43
4.11.Încetarea abonamentului43
4.12.Custodia și recuperarea cheii43
4.12.1.Abonatul43
4.12.1.1.Ce pereche de chei poate fi dată în custodie43
4.12.1.2.Cine poate transmite o cerere de recuperare43
4.12.1.3.Procesul de recuperare și responsabilitățile aferente43
4.12.1.4.Identificarea și autentificarea43
4.12.1.5.Aprobarea sau respingerea cererilor de recuperare43
4.12.1.6.Acțiunile KEA și KRA în timpul recuperării perechii de chei43
4.12.1.7.Disponibilitatea KEA și KRA43
4.12.2.Încapsularea cheii de sesiune și politica și practicile de recuperare43
5.Unități, gestionare și controale operaționale43
5.1.Controale fizice44
5.1.1.Amplasamentul și construcția44
5.1.1.1.CA primară, CPOC, TLM44
5.1.1.2.EA/AA45
5.1.2.Accesul fizic45
5.1.2.1.CA primară, CPOC, TLM45
5.1.2.2.EA/AA46
5.1.3.Energie electrică și aer condiționat46
5.1.4.Expuneri la apă47
5.1.5.Prevenirea și protecția împotriva incendiilor47
5.1.6.Gestionarea suporturilor47
5.1.7.Eliminarea deșeurilor47
5.1.8.Copia de rezervă (backup-ul) în afara unității48
5.1.8.1.CA primară, CPOC și TLM48
5.1.8.2.EA/AA48
5.2.Controale procedurale48
5.2.1.Roluri de încredere48
5.2.2.Numărul de persoane necesar pentru fiecare sarcină49
5.2.3.Identificarea și autentificarea pentru fiecare rol49
5.2.4.Roluri care necesită separarea atribuțiilor49
5.3.Controalele personalului50
5.3.1.Cerințe privind calificările, experiența și autorizarea50
5.3.2.Procedurile de verificare a antecedentelor50
5.3.3.Cerințe de pregătire51
5.3.4.Frecvența și cerințele recalificării52
5.3.5.Frecvența și secvența rotației posturilor52
5.3.6.Sancțiuni pentru acțiunile neautorizate52
5.3.7.Cerințe privind contractanții independenți52
5.3.8.Documentația furnizată personalului52
5.4.Proceduri de înregistrare în jurnal a auditurilor52
5.4.1.Tipuri de evenimente care trebuie înregistrate și raportate de fiecare CA53
5.4.2.Frecvența prelucrării jurnalelor54
5.4.3.Perioada de păstrare a jurnalelor de audit54
5.4.4.Protejarea jurnalelor de audit54
5.4.5.Proceduri de creare de copii de rezervă ale jurnalelor de audit55
5.4.6.Sistemul de colectare a probelor de audit (intern sau extern)55
5.4.7.Notificarea subiectului care cauzează evenimentul55
5.4.8.Evaluarea vulnerabilităților55
5.5.Arhivarea înregistrărilor56
5.5.1.Tipuri de înregistrări arhivate56
5.5.2.Perioada de păstrare a arhivei57
5.5.3.Protejarea arhivei57
5.5.4.Arhivarea și stocarea sistemului58
5.5.5.Cerințe privind marcarea temporală al înregistrărilor58
5.5.6.Sistemul de colectare a arhivelor (intern sau extern)58
5.5.7.Proceduri de obținere și de verificare a informațiilor din arhivă58
5.6.Schimbarea cheilor pentru elementele modelului de încredere al C-ITS58
5.6.1.TLM58
5.6.2.CA primară58
5.6.3.Certificatul EA/AA59
5.6.4.Auditorul59
5.7.Recuperarea în caz de compromitere și de dezastru59
5.7.1.Tratarea situațiilor de compromitere și a incidentelor59
5.7.2.Coruperea resurselor informatice, a software-ului și/sau a datelor60
5.7.3.Proceduri în caz de compromitere a cheii private a entității60
5.7.4.Capacitățile de asigurare a continuității activității în urma unui dezastru61
5.8.Încetarea funcționării și transferul61
5.8.1.TLM61
5.8.2.CA primară61
5.8.3.EA/AA62
6.Controale tehnice de securitate62
6.1.Generarea și instalarea perechii de chei62
6.1.1.TLM, CA primară, EA, AA62
6.1.2.EE — stația C-ITS mobilă63
6.1.3.EE — stația C-ITS fixă63
6.1.4.Cerințe criptografice63
6.1.4.1.Algoritm și lungimea cheii – algoritmii semnăturii63
6.1.4.2.Algoritm și lungimea cheii – algoritmi de criptare pentru înscriere și pentru autorizare65
6.1.4.3.Agilitate criptografică66
6.1.5.Stocarea securizată a cheilor private66
6.1.5.1.Nivelul CA primară, CA subordonată și TLM66
6.1.5.2.Entitatea finală67
6.1.6.Copia de rezervă a cheilor private68
6.1.7.Distrugerea cheilor private68
6.2.Datele de activare68
6.3.Controalele de securitate a sistemelor informatice69
6.4.Controalele tehnice ale ciclului de viață69
6.5.Controalele de securitate a rețelelor69
7.Profiluri de certificate, CRL și CTL69
7.1.Profilul de certificat69
7.2.Valabilitatea certificatelor69
7.2.1.Certificatele cu pseudonim70
7.2.2.Tichete de autorizare pentru stațiile C-ITS fixe71
7.3.Revocarea certificatelor71
7.3.1.Revocarea certificatelor CA, EA și AA71
7.3.2.Revocarea acreditărilor de înscriere72
7.3.3.Revocarea tichetelor de autorizare72
7.4.Lista certificatelor revocate72
7.5.Lista europeană de certificate de încredere72
8.Auditul de conformitate și alte evaluări72
8.1.Subiectele acoperite de audit și baza de audit72
8.2.Frecvența auditurilor73
8.3.Identitatea/calificările auditorului73
8.4.Relația auditorului cu entitatea auditată73
8.5.Măsurile luate în urma constatării unor deficiențe73
8.6.Comunicarea rezultatelor74
9.Alte dispoziții74
9.1.Tarifele74
9.2.Responsabilitatea financiară74
9.3.Confidențialitatea informațiilor privind activitatea economică75
9.4.Planul de confidențialitate75
10.Trimiteri75
ANEXA III
1.Introducere
1.1.Prezentare generală și domeniul de aplicare al prezentei politici
Prezenta politică de certificare definește modelul european de încredere al C-ITS bazat pe infrastructură cu cheie publică (PKI) din cadrul sistemului global al UE de gestionare a acreditărilor de securitate pentru C-ITS (CCMS al UE). Aceasta definește cerințele privind gestionarea certificatelor cu cheie publică pentru aplicațiile C-ITS de către entitățile emitente și utilizarea acestora de către entitățile finale în Europa. La cel mai înalt nivel al său, PKI este compusă dintr-un set de autorități de certificare (CA-uri) primare „abilitate” ca urmare a introducerii de către managerul listei de încredere (TLM) a certificatelor acestora într-o listă europeană de certificate de încredere (ECTL), care este emisă și publicată de entitatea centrală TLM (a se vedea secțiunile 1.2 și 1.3).
Prezenta politică este obligatorie pentru toate entitățile care participă la sistemul de încredere C-ITS în Europa. Aceasta contribuie la evaluarea nivelului de încredere care poate fi stabilit cu privire la informațiile primite de orice destinatar al unui mesaj autentificat printr-un certificat al unei entități finale din cadrul PKI. Pentru a permite evaluarea încrederii în certificatele furnizate de CCMS al UE, prezenta politică stabilește un set de cerințe obligatorii pentru funcționarea entității centrale TLM și pentru compilarea și gestionarea ECTL. În consecință, prezentul document reglementează următoarele aspecte în legătură cu ECTL:
·identificarea și autentificarea entităților principale care obțin roluri PKI pentru TLM, inclusiv declarațiile privind privilegiile alocate fiecărui rol;
·cerințele minime referitoare la practicile de securitate locale pentru TLM, inclusiv controalele fizice, ale personalului și procedurale;
·cerințele minime referitoare la practicile tehnice de securitate pentru TLM, inclusiv securitatea sistemelor informatice, securitatea rețelei și controalele tehnice ale modulelor criptografice;
·cerințele minime referitoare la practicile operaționale pentru TLM, inclusiv înregistrarea noilor certificate ale CA primare, radierea temporară sau permanentă a CA-urilor primare incluse existente și publicarea și distribuirea actualizărilor ECTL;
·un profil ECTL, inclusiv toate câmpurile de date obligatorii și opționale din ECTL, algoritmii criptografici care urmează să fie utilizați, formatul exact al ECTL și recomandări pentru prelucrarea ECTL;
·gestionarea certificatelor ECTL pe parcursul ciclului de viață, inclusiv distribuirea, activarea, expirarea și revocarea certificatelor ECTL;
·gestionarea revocării încrederii în legătură cu CA-urile primare, când este necesar.
Deoarece credibilitatea ECTL nu depinde exclusiv de ECTL ca atare ci, într-o mare măsură, și de CA-urile primare care alcătuiesc PKI și de CA-urile subordonate acestora, prezenta politică prevede și cerințele minime care sunt obligatorii pentru toate CA-urile participante (CA-uri primare și CA-uri subordonate). Cerințele sunt următoarele:
·identificarea și autentificarea entităților principale care obțin roluri PKI (de exemplu, responsabil cu securitatea, responsabil cu confidențialitatea, administrator de securitate, administrator de director și utilizator final), inclusiv o declarație privind atribuțiile, responsabilitățile, obligațiile și privilegiile asociate fiecărui rol;
·gestionarea cheilor, inclusiv algoritmii acceptabili și obligatorii de semnare a certificatului și de semnare a datelor și perioadele de valabilitate ale certificatelor;
·cerințele minime referitoare la practicile de securitate locale, inclusiv controalele fizice, ale personalului și procedurale;
·cerințele minime referitoare la practicile tehnice de securitate, cum ar fi securitatea sistemelor informatice, securitatea rețelei și controalele tehnice ale modulelor criptografice;
·cerințele minime referitoare la practicile operaționale ale CA, EA, AA și ale entităților finale, inclusiv aspectele legate de înregistrarea, radierea (însemnând scoaterea de pe listă), revocarea, compromiterea cheii, respingerea justificată, actualizarea certificatelor, practicile de audit și nedivulgarea informațiilor confidențiale;
·certificatul și profilul CRL, inclusiv formatele, algoritmii acceptabili, câmpurile de date obligatorii și opționale și intervalele lor de valori valabile, și modul în care verificatorii trebuie să prelucreze certificatele;
·atribuțiile de monitorizare, raportare, alertare și restaurare periodice ale entităților modelului de încredere al C-ITS, pentru a asigura funcționarea securizată, inclusiv în caz de comportament inadecvat.
Pe lângă aceste cerințe minime, entitățile care gestionează CA-urile primare și CA-urile subordonate pot să își stabilească propriile cerințe suplimentare și le pot prevedea în declarațiile relevante de practici de certificare (CPS), cu condiția ca acestea să nu contravină cerințelor prevăzute în politica de certificare. A se vedea secțiunea 1.5 pentru mai multe detalii despre modul de auditare și publicare a CPS-urilor.
Politica privind certificatele (CP) prevede, de asemenea, scopurile în care pot fi utilizate CA-urile primare, CA-urile subordonate și certificatele emise de acestea. CP prevede obligațiile asumate de:
·TLM;
·fiecare CA primară ale cărei certificate sunt listate în ECTL;
·CA-urile subordonate CA-urilor primare (EA și AA);
·fiecare membru sau organizație care răspunde de una dintre entitățile modelului de încredere al C-ITS sau care exploatează o astfel de entitate.
De asemenea, CP definește obligații imperative aplicabile:
·TLM;
·fiecărei CA primare ale cărei certificate sunt listate în ECTL;
·fiecărei CA subordonate certificate de o CA primară;
·tuturor entităților finale;
·fiecărei organizații membre care răspunde de una dintre entitățile modelului de încredere al C-ITS sau exploatează o astfel de entitate.
În fine, CP prevede cerințe privind documentarea limitărilor responsabilităților și obligațiilor din CPS ale fiecărei CA primare ale cărei certificate sunt listate în ECTL.
Prezenta CP este conformă cu politica de certificare și cu cadrul de practici de certificare adoptat de Internet Engineering Task Force (IETF) [3].
1.2.Definiții și acronime
Se aplică definițiile din [2], [3] și [4].
AA
|
autoritate de autorizare
|
AT
|
tichet de autorizare
|
CA
|
autoritate de certificare
|
CP
|
politica de certificare
|
CPA
|
autoritatea responsabilă cu politica de certificare a C-ITS
|
CPOC
|
punct de contact pentru C-ITS
|
CPS
|
declarație de practici de certificare
|
CRL
|
lista certificatelor revocate
|
EA
|
autoritate de înscriere
|
EC
|
acreditare de înscriere
|
ECIES
|
sistem de criptare integrat bazat pe curbe eliptice
|
EE
|
entitate finală (și anume stația C-ITS)
|
ECTL
|
lista europeană de certificate de încredere
|
CCMS al UE
|
sistemul UE de gestionare a acreditărilor de securitate pentru C-ITS
|
RGPD
|
Regulamentul general privind protecția datelor
|
HSM
|
modul de securitate hardware
|
PKI
|
infrastructură cu cheie publică
|
RA
|
autoritate de înregistrare
|
CA subordonată
|
EA și AA
|
TLM
|
managerul listei de încredere
|
Glosar
solicitant
|
Persoana fizică sau entitatea juridică care solicită un certificat (sau reînnoirea acestuia). Odată ce certificatul inițial este creat (inițializare), solicitantul este denumit abonat.
Pentru certificatele emise entităților finale, abonatul (solicitantul certificatului) este entitatea care controlează sau exploatează/menține entitatea finală căreia îi este emis certificatul, chiar dacă entitatea finală este cea care transmite efectiv cererea de certificat.
|
autoritate de autorizare
|
În prezentul document, termenul „autoritate de autorizare” (AA) nu se referă numai la funcția specifică a AA, ci și la entitatea juridică și/sau operațională care o gestionează.
|
autoritate de certificare
|
Autoritatea de certificare primară, autoritatea de înscriere și autoritatea de autorizare sunt denumite împreună autoritate de certificare (CA).
|
model de încredere al C-ITS
|
Modelul de încredere al C-ITS are rolul de a stabili o relație de încredere între stațiile C-ITS. Este implementat prin utilizarea unei PKI compuse din CA-uri primare, CPOC, TLM, EA-uri, AA-uri și o rețea securizată.
|
agilitate criptografică
|
Capacitatea entităților modelului de încredere al C-ITS de a adapta CP la medii în schimbare sau la cerințe viitoare noi, de exemplu prin modificarea în timp a algoritmilor criptografici și a lungimii cheii.
|
modul criptografic
|
Un element securizat bazat pe hardware, în cadrul căruia se generează și/sau se stochează chei, se generează numere aleatorii și se semnează sau se criptează date.
|
autoritate de înscriere
|
În prezentul document, termenul „autoritate de înscriere” (EA) nu se referă numai la funcția specifică a EA, ci și la entitatea juridică și/sau operațională care o gestionează.
|
participanții la PKI
|
Entitățile modelului de încredere al C-ITS, și anume TLM, CA-urile primare, EA-urile, AA-urile și stațiile C-ITS.
|
regenerarea cheilor
|
|
registru
|
Registrul utilizat pentru stocarea certificatelor și a informațiilor despre certificate furnizate de entitățile modelului de încredere al C-ITS, astfel cum este definit în secțiunea 2.3.
|
autoritate de certificare primară
|
În prezentul document, termenul „autoritate de certificare primară” (CA) nu se referă numai la funcția specifică a CA, ci și la entitatea juridică și/sau operațională care o gestionează.
|
subiect
|
Persoana fizică, dispozitivul, sistemul, unitatea sau entitatea juridică identificată (identificat) într-un certificat ca subiect, și anume fie abonatul, fie un dispozitiv controlat și exploatat de abonat.
|
abonat
|
O persoană fizică sau o entitate juridică căreia i se emite un certificat și care are obligații juridice în temeiul unui acord de abonare sau a unui acord privind condițiile de utilizare.
|
acord de abonare
|
Un acord încheiat între CA și solicitant/abonat, care precizează drepturile și responsabilitățile părților.
|
1.3.Participanții la PKI
1.3.1.Introducere
Participanții la PKI joacă un rol în PKI definită prin prezenta politică. Cu excepția cazului în care se interzice în mod expres, un participant poate avea mai multe roluri concomitent. Se poate interzice unui participant să își asume concomitent roluri specifice pentru a evita conflictele de interese sau pentru a asigura separarea atribuțiilor.
De asemenea, participanții pot delega parțial rolurile lor altor entități în cadrul unui contract de servicii. De exemplu, atunci când se furnizează informații referitoare la statutul revocării utilizând CRL-urile, CA este și emitentul CRL, dar poate delega responsabilitatea emiterii CRL-urilor unei entități diferite.
Rolurile PKI constau în:
·roluri de autoritate, însemnând că fiecare rol este instanțiat o singură dată;
·roluri operaționale, și anume roluri care pot fi instanțiate de una sau mai multe entități.
De exemplu, o CA primară poate fi implementată de o entitate comercială, de un grup de interes comun, de o organizație națională și/sau de o organizație europeană.
În figura 1 se prezintă arhitectura modelului de încredere al C-ITS, bazată pe [2]. Arhitectura este descrisă pe scurt în prezenta secțiune, dar elementele principale sunt descrise mai detaliat în secțiunile 1.3.2 – 1.3.6.
CPA numește TLM, care este, prin urmare, o entitate de încredere pentru toți participanții la PKI. CPA aprobă funcționarea CA primare și confirmă că TLM poate avea încredere în CA(-urile) primară (primare). TLM emite ECTL care permite tuturor participanților la PKI să aibă încredere în CA-urile primare aprobate. CA primară emite certificate către EA și AA, asigurând astfel încrederea în funcționarea acestora. EA emite certificate de înscriere stațiilor C-ITS transmițătoare și retransmițătoare (ca entități finale), asigurând astfel încrederea în funcționarea acestora. AA emite AT-uri stațiilor C-ITS pe baza încrederii în EA.
Stația C-ITS receptoare și retransmițătoare (ca parte care retransmite) poate avea încredere în alte stații C-ITS deoarece AT-urile sunt emise de o AA care are încrederea unei CA primare care, la rândul său, are încrederea TLM și CPA.
Trebuie reținut că figura 1 descrie doar modelul de încredere al C-ITS la nivelul CA primare. Detalii despre nivelurile inferioare sunt prezentate în secțiunile următoare din prezenta CP sau în CPS a CA-urilor primare specifice.
Figura 2 prezintă o imagine de ansamblu a fluxurilor de informații dintre participanții la PKI. Punctele verzi indică fluxuri care necesită comunicații mașină-mașină. Fluxurile de informații reprezentate cu roșu au definite cerințele de securitate.
Modelul de încredere al C-ITS se bazează pe o arhitectură cu CA-uri primare multiple, în care certificatele CA primare sunt transmise periodic (așa cum se arată mai jos) către punctul de contact central (CPOC) printr-un protocol securizat (de exemplu, certificate de legătură) definit de CPOC.
O CA primară poate fi operată de o organizație guvernamentală sau privată. Arhitectura modelului de încredere al C-ITS conține cel puțin o CA primară (CA primară la nivelul UE, cu același nivel ca celelalte CA-uri primare). CA primară la nivelul UE este delegată de toate entitățile care participă la modelul de încredere al C-ITS, dar care nu doresc să își creeze propria CA primară. CPOC transmite certificatele CA primare primite către TLM, care răspunde de colectarea și semnarea listei certificatelor CA primare și de returnarea acestora către CPOC, care le pune la dispoziția publicului (a se vedea mai jos).
Relațiile de încredere dintre entitățile din cadrul modelului de încredere al C-ITS sunt descrise în figurile, tabelele și secțiunile următoare.
Figura 1: Arhitectura modelului de încredere al C-ITS
Figura 2: Fluxurile de informații ale modelului de încredere al C-ITS
Identificatorul fluxului
|
De la
|
Către
|
Conținutul
|
Referința
|
(1).
|
CPA
|
TLM
|
aprobarea cererii CA primare
|
8
|
(2).
|
CPA
|
TLM
|
informații cu privire la revocarea CA primare
|
8.5
|
(3).
|
CPA
|
CA primară
|
actualizări ale CP
|
1.5
|
(4).
|
CPA
|
CA primară
|
aprobarea/respingerea formularului de cerere al CA primare sau modificările solicitării CPS sau procesul de audit.
|
8.5, 8.6
|
(5).
|
TLM
|
CPA
|
notificarea modificării ECTL
|
4, 5.8.1
|
(6).
|
TLM
|
CPOC
|
certificat TLM
|
4.4.2
|
(7).
|
TLM
|
CPOC
|
ECTL
|
4.4.2
|
(8).
|
CPOC
|
TLM
|
informații despre certificatul CA primare
|
4.3.1.1
|
(9).
|
CPOC
|
TLM
|
revocarea certificatului CA primare
|
7.3
|
(10).
|
CPOC
|
toate entitățile finale
|
certificat TLM
|
4.4.2
|
(11).
|
CA primară
|
CPOC
|
informații despre certificatul CA primare
|
4.3.1.1
|
(12).
|
CA primară
|
CPOC
|
revocarea certificatului CA primare
|
7.3
|
(13).
|
CA primară
|
auditor
|
ordin de audit
|
8
|
(14).
|
CA primară
|
CPA
|
formular de cerere al CA primare — solicitare inițială
|
4.1.2.1
|
(15).
|
CA primară
|
CPA
|
formular de cerere al CA primare — modificări ale CPS
|
1.5.1
|
(16).
|
CA primară
|
CPA
|
formular de cerere al CA primare — raport de audit
|
8.6
|
(17).
|
CA primară
|
CPA
|
rapoarte ale CA primare referitoare la incidente, inclusiv revocarea unei CA subordonate (EA, AA)
|
anexa III, 7.3.1
|
(18).
|
CA primară
|
EA
|
răspuns referitor la certificatul EA
|
4.2.2.3
|
(19).
|
CA primară
|
AA
|
răspuns referitor la certificatul AA
|
4.2.2.3
|
(20).
|
CA primară
|
toți
|
certificat EA/AA, CRL
|
4.4.2
|
(21).
|
EA
|
CA primară
|
solicitare de certificat EA
|
4.2.2.3
|
(22).
|
EA
|
stația C-ITS
|
răspuns referitor la acreditarea de înscriere
|
4.3.1.4
|
(23).
|
EA
|
AA
|
răspuns referitor la autorizație
|
4.2.2.5
|
(24).
|
AA
|
CA primară
|
solicitare de certificat AA
|
4.2.2.3
|
(25).
|
AA
|
EA
|
solicitare de autorizare
|
4.2.2.5
|
(26).
|
AA
|
stația C-ITS
|
răspuns referitor la tichetul de autorizare
|
4.3.1.5
|
(27).
|
EA
|
CA primară
|
transmiterea solicitării
|
4.1.2.3
|
(28).
|
AA
|
CA primară
|
transmiterea solicitării
|
4.1.2.3
|
(29).
|
CA primară
|
EA
|
răspuns
|
4.12 și 4.2.1
|
(30).
|
CA primară
|
AA
|
răspuns
|
4.12 și 4.2.1
|
(31).
|
stația C-ITS
|
EA
|
solicitare de acreditare de înscriere
|
4.2.2.4
|
(32).
|
stația C-ITS
|
AA
|
solicitare de tichet de autorizare
|
4.2.2.5
|
(33).
|
producător / operator
|
EA
|
înregistrare
|
4.2.1.4
|
(34).
|
producător / operator
|
EA
|
dezactivare
|
7.3
|
(35).
|
EA
|
producător / operator
|
răspuns
|
4.2.1.4
|
(36).
|
auditor
|
CA primară
|
raport
|
8.1
|
(37).
|
toți
|
CPA
|
solicitări de modificare a CP
|
1.5
|
(38).
|
TLM
|
CPA
|
formular de cerere
|
4.1.2.2
|
(39).
|
CPA
|
TLM
|
aprobare/respingere
|
4.1.2.2
|
(40).
|
TLM
|
CPA
|
raport de audit
|
4.1.2.2
|
Tabelul 1:
Descrierea detaliată a fluxurilor de informații din modelul de încredere al C-ITS
1.3.2.Autoritatea responsabilă cu politica de certificare a C-ITS
(1)Autoritatea responsabilă cu politica de certificare a C-ITS (CPA) este alcătuită din reprezentanții părților interesate din sectorul public și privat (de exemplu, statele membre, producătorii de vehicule etc.) care participă la modelul de încredere al C-ITS. Aceasta îndeplinește două roluri subordonate:
(1)gestionarea politicii de certificare, inclusiv:
·aprobarea prezentei CP și a solicitărilor viitoare de modificare a CP;
·luarea deciziilor cu privire la analizarea solicitărilor și recomandărilor de modificare a CP transmise de alți participanți la PKI sau de alte entități;
·luarea deciziilor cu privire la publicarea noilor versiuni ale CP;
(2)gestionarea autorizațiilor PKI, inclusiv:
·definirea și luarea deciziilor cu privire la procedurile de aprobare a CPS și de auditare a CA și publicarea acestora (denumite împreună „proceduri de aprobare a CA”);
·autorizarea CPOC să funcționeze și să raporteze regulat;
·autorizarea TLM să funcționeze și să raporteze regulat;
·aprobarea CPS a CA-urilor primare, dacă este conformă cu CP comună valabilă;
·examinarea rapoartelor de audit ale auditorului acreditat al PKI pentru toate CA-urile primare;
·notificarea TLM cu privire la lista CA-urilor primare aprobate sau neaprobate și la certificatele acestora, pe baza rapoartelor de aprobare primite ale CA-urilor primare și a rapoartelor regulate privind operațiunile.
(2)Reprezentantul autorizat al CPA este responsabil cu autentificarea reprezentantului autorizat al TLM și cu aprobarea formularului de cerere al TLM pentru procesul de înscriere. CPA este responsabilă cu autorizarea TLM să funcționeze astfel cum se menționează în prezenta secțiune.
1.3.3.Managerul listei de încredere
(3)TLM este o entitate unică numită de CPA.
(4)TLM este responsabil cu:
·operarea ECTL în conformitate cu CP comună valabilă și raportarea regulată a activităților către CPA în vederea funcționării globale securizate a modelului de încredere C-ITS;
·primirea certificatelor CA primare de la CPOC;
·includerea/excluderea certificatelor CA primare în/din ECTL în urma notificării de către CPA;
·semnarea ECTL;
·transmiterea regulată și în timp util a ECTL către CPOC.
1.3.4.Auditorul acreditat al PKI
(5)Auditorul acreditat al PKI este responsabil cu:
·efectuarea sau organizarea auditurilor CA-urilor primare, ale TLM și ale CA-urilor subordonate;
·distribuirea raportului de audit (pe baza unui audit inițial sau periodic) către CPA în conformitate cu cerințele din secțiunea 8 de mai jos. Raportul de audit trebuie să includă recomandările formulate de auditorul acreditat al PKI;
·notificarea entității care gestionează CA primară cu privire la realizarea cu succes sau fără succes a unui audit inițial sau periodic al CA-urilor subordonate;
·evaluarea conformității CPS-urilor cu prezenta CP.
1.3.5.Punctul de contact pentru C-ITS (CPOC)
(6)CPOC este o entitate unică numită de CPA. Reprezentantul autorizat al CPA este responsabil cu autentificarea reprezentantului autorizat al CPOC și cu aprobarea formularului de cerere al CPOC pentru procesul de înscriere. CPA este responsabilă cu autorizarea CPOC să funcționeze astfel cum se prevede în prezenta secțiune.
(7)CPOC este responsabil cu:
·stabilirea comunicației securizate între toate entitățile modelului de încredere al C-ITS și contribuția la această comunicație, într-un mod eficient și rapid;
·analizarea solicitărilor și a recomandărilor de modificări procedurale transmise de alți participanți la modelul de încredere (de exemplu, CA-uri primare);
·transmiterea certificatelor CA primare către TLM;
·publicarea ancorei de încredere comune (cheia publică în vigoare și certificatul de legătură ale TLM);
·publicarea ECTL.
În secțiunea 7 se pot găsi detalii complete despre ECTL.
1.3.6.Roluri operaționale
(8)Entitățile următoare, definite în [2], au un rol operațional, astfel cum se definește în RFC 3647:
Element funcțional
|
Rol PKI ([3] și [4])
|
Rol detaliat ([2])
|
autoritate de certificare primară
|
CA/RA (autoritate de înregistrare)
|
Furnizează EA și AA dovada că poate emite EC-uri sau AT-uri
|
autoritate de înscriere
|
abonat la CA primară / subiect al certificatului EA
CA/RA
|
Autentifică o stație C-ITS și îi acordă acces la comunicațiile ITS
|
autoritate de autorizare
|
abonat la CA primară / subiect al certificatului AA
CA/RA
|
Furnizează unei stații C-ITS dovada certă că poate utiliza servicii ITS specifice
|
stația C-ITS transmițătoare
|
subiect al certificatului (EC) al entității finale (EE)
|
Dobândește de la EA drepturi de a accesa comunicațiile ITS
Negociază drepturi acordate de AA de a invoca serviciile ITS
Trimite mesaje prin conexiune cu un singur tronson și mesaje difuzate prin retransmitere
|
stație C-ITS retransmițătoare (care redirecționează)
|
parte retransmițătoare / subiect al certificatului EE
|
Primește mesaje difuzate de la stația C-ITS transmițătoare și le redirecționează către stația C-ITS receptoare dacă este necesar
|
stație C-ITS receptoare
|
parte retransmițătoare
|
Primește mesaje difuzate de la stația C-ITS transmițătoare sau retransmițătoare
|
producător
|
abonat la EA
|
Instalează informațiile necesare pentru gestionarea securității în stația C-ITS la nivelul de producție
|
operator
|
abonat la EA / AA
|
Instalează și actualizează informațiile necesare pentru gestionarea securității în stația C-ITS în timpul operării
|
Tabelul 2: Roluri operaționale
Observație: în conformitate cu [4], în prezenta CP se utilizează termeni diferiți pentru „abonatul” care încheie contractul cu CA în vederea emiterii certificatelor și pentru „subiectul” căruia i se aplică certificatul. Abonații sunt toate entitățile care au un raport juridic contractual cu o CA. Subiecții sunt entitățile cărora li se aplică certificatul. EA-urile/AA-urile sunt abonați și subiecți ai CA primare și pot solicita certificate EA/AA. Stațiile C-ITS sunt subiecți și pot solicita certificate de entitate finală.
(9)Autoritățile de înregistrare:
EA trebuie să îndeplinească rolul de autoritate de înregistrare pentru entitățile finale. Doar un abonat autentificat și autorizat poate înregistra entități finale noi (stații C-ITS) la o EA. CA-urile primare relevante trebuie să îndeplinească rolul de autorități de înregistrare pentru EA-uri și AA-uri.
1.4.Utilizarea certificatelor
1.4.1.Domenii de utilizare aplicabile
(10)Certificatele emise în temeiul prezentei CP sunt destinate să fie utilizate pentru a valida semnăturile digitale în contextul comunicației ITS cooperative, în conformitate cu arhitectura de referință din [2].
(11)Profilurile certificatelor din [5] determină utilizările certificatelor pentru TLM, CA-uri primare, EA-uri, AA-uri și entități finale.
1.4.2.Limitele responsabilității
(12)Certificatele nu sunt destinate și nici autorizate să fie utilizate în:
·circumstanțe care nu respectă, încalcă sau contravin oricăror legi, regulamente (cum ar fi RGPD), decrete sau ordine guvernamentale aplicabile;
·circumstanțe care nu respectă, contravin sau încalcă drepturile altora;
·încălcarea prezentei CP sau a acordului de abonare relevant;
·orice circumstanțe în care utilizarea lor ar putea duce în mod direct la decese, vătămări corporale sau daune grave aduse mediului (de exemplu, prin defecțiuni în funcționarea instalațiilor nucleare, în navigația sau comunicațiile aeronavelor sau în sistemele de control al armelor);
·circumstanțe care contravin obiectivelor globale de sporire a siguranței rutiere și a eficienței transporturilor rutiere din Europa.
1.5.Administrarea politicii de certificare
1.5.1.Actualizarea CPS-urilor CA-urilor listate în ECTL
(13)Fiecare CA primară listată în ECTL își publică propria CPS, care trebuie să respecte prezenta politică. O CA primară poate adăuga cerințe suplimentare, dar trebuie să se asigure că toate cerințele prezentei CP sunt îndeplinite în permanență.
(14)Fiecare CA primară listată în ECTL pune în aplicare un proces de modificare adecvat pentru documentul său CPS. Proprietățile principale ale procesului de modificare trebuie să fie documentate în partea publică a CPS.
(15)Procesul de modificare trebuie să asigure că toate modificările aduse prezentei CP sunt analizate cu atenție și, dacă este necesar în vederea asigurării conformității cu CP modificată, că CPS este actualizată în termenul prevăzut în etapa de implementare a procesului de modificare pentru CP. În special, procesul de modificare include proceduri de modificare în caz de urgență care să asigure implementarea în timp util a modificărilor CP relevante din punctul de vedere al securității.
(16)Procesul de modificare trebuie să conțină măsuri adecvate pentru a verifica conformitatea cu CP a tuturor modificărilor aduse CPS. Toate modificările aduse CPS trebuie să fie documentate în mod clar. Înainte de punerea în aplicare a unei noi versiuni a CPS, conformitatea acesteia cu CP trebuie să fie confirmată de un auditor acreditat al PKI.
(17)CA primară notifică CPA orice modificare adusă CPS, comunicând cel puțin următoarele informații:
·descrierea exactă a modificării;
·motivul modificării;
·un raport al auditorului acreditat al PKI care confirmă conformitatea cu CP;
·datele de contact ale persoanei responsabile cu CPS;
·calendarul de punere în aplicare planificat.
1.5.2.Procedurile de aprobare a CPS
(18)Înainte de a-și începe operațiunile, o CA primară potențială trebuie să își prezinte CPS unui auditor acreditat al PKI în cadrul unui ordin de audit de conformitate (fluxul 13), precum și CPA în vederea aprobării (fluxul 15).
(19)O CA primară trebuie să își prezinte modificările aduse CPS unui auditor acreditat al PKI în cadrul unui ordin de audit de conformitate (fluxul 13), precum și CPA în vederea aprobării (fluxul 15) înainte ca respectivele modificări să intre în vigoare.
(20)O EA/AA trebuie să își prezinte CA primare CPS sau modificările aduse CPS. CA primară poate dispune emiterea unui certificat de conformitate de către organismul național sau entitatea privată responsabilă cu aprobarea EA/AA, astfel cum se definește în secțiunile 4.1.2 și 8.
(21)Auditorul acreditat al PKI evaluează CPS în conformitate cu secțiunea 8.
(22)Auditorul acreditat al PKI comunică rezultatele evaluării CPS în cadrul raportului de audit, astfel cum se prevede în secțiunea 8.1. CPS este acceptată sau respinsă în cadrul procesului de acceptare a raportului de audit menționat în secțiunile 8.5 și 8.6.
2.Responsabilități legate de publicare și de registru
2.1.Metode de publicare a informațiilor referitoare la certificate
(23)În temeiul secțiunii 2.5, se pot publica informații referitoare la certificate:
·regulat sau periodic sau
·ca răspuns la o solicitare din partea uneia dintre entitățile participante.
În fiecare dintre cazuri, se aplică grade de urgență a publicării diferite și, în consecință, termene diferite, însă entitățile trebuie să fie pregătite pentru ambele situații.
(24)Publicarea regulată a informațiilor referitoare la certificate permite stabilirea unui termen maxim până la care se actualizează informațiile referitoare la certificate pentru toate nodurile din rețeaua C-ITS. Frecvența publicării tuturor informațiilor referitoare la certificate este prevăzută în secțiunea 2.2.
(25)La cererea entităților care participă la rețeaua C-ITS, oricare dintre participanți poate începe să publice în orice moment informații referitoare la certificate și, în funcție de statutul său, să solicite un set de informații la zi referitoare la certificate, astfel încât să devină un nod al rețelei C-ITS care beneficiază de încredere deplină. Scopul acestei publicări este, în principal, de a furniza entităților informații cu privire la statutul global actual al informațiilor referitoare la certificate din rețea și de a le permite acestora să comunice pe o bază de încredere până la următoarea publicare regulată a informațiilor.
(26)O singură CA primară poate iniția de asemenea publicarea informațiilor referitoare la certificate în orice moment, trimițând un set actualizat de certificate tuturor „membrilor abonați” ai rețelei C-ITS care sunt destinatari obișnuiți ai acestor informații. Aceasta sprijină funcționarea CA-urilor și le permite să se adreseze membrilor între datele regulate și planificate de publicare a certificatelor.
(27)Secțiunea 2.5 prevede mecanismul și toate procedurile de publicare a certificatelor CA primare și a ECTL.
(28)CPOC publică certificatele CA primare (astfel cum sunt incluse în ECTL și destinate publicului), certificatul TLM și ECTL pe care o emite.
(29)CA-urile primare își publică certificatele EA/AA și CRL-urile și sunt în măsură să sprijine toate cele trei mecanisme menționate anterior pentru publicarea acestora către membrii lor abonați și către părțile de încredere, luând toate măsurile necesare pentru a asigura transmiterea securizată, astfel cum se menționează în secțiunea 4.
2.2.Termenul sau frecvența de publicare
(30)Cerințele referitoare la calendarul de publicare a certificatelor și CRL-urilor trebuie stabilite având în vedere diverșii factori limitativi ai nodurilor C-ITS unice, cu obiectivul global de a opera o „rețea de încredere” și de a publica cât mai rapid posibil actualizări destinate tuturor stațiilor C-ITS implicate.
·Pentru publicarea regulată a informațiilor actualizate referitoare la certificate (de exemplu, modificări în alcătuirea ECTL sau CRL), este necesară o perioadă maximă de trei luni pentru funcționarea rețelei C-ITS în condiții de siguranță.
·CA-urile primare își publică certificatele CA și CRL-urile cât mai rapid posibil după emitere.
·Pentru publicarea CRL, se utilizează registrul CA primare.
În plus, CPS pentru fiecare CA trebuie să specifice termenul în care se publică un certificat după ce CA eliberează certificatul.
Prezenta secțiune precizează doar termenul sau frecvența aplicabile publicării regulate. Mijloacele de asigurare a conectivității pentru actualizarea stațiilor C-ITS cu informațiile din ECTL și din CRL-uri în termen de o săptămână de la publicarea lor (în condiții de funcționare normală, de exemplu cu acoperire celulară, cu vehiculul în funcționare efectivă etc.) sunt implementate în conformitate cu cerințele din prezentul document.
2.3.Registre
(31)Cerințele referitoare la structura registrului pentru stocarea certificatelor și la tipurile de informații furnizate de entitățile din rețeaua C-ITS sunt următoarele pentru entitățile unice:
·în general, fiecare CA primară ar trebui să utilizeze un registru al informațiilor referitoare la certificatele EA/AA și al CRL proprii curente active pentru a publica certificate pentru ceilalți participanți la PKI (de exemplu, un serviciu de director bazat pe LDAP). Este necesar ca registrul fiecărei CA primare să poată accepta toate controalele necesare ale accesului (secțiunea 2.4) și termenele de transmisie (secțiunea 2.2) pentru fiecare metodă de distribuire a informațiilor referitoare la C-ITS;
·registrul TLM (care stochează certificatele ECTL și TLM publicate de CPOC, de exemplu) ar trebui să fie bazat pe un mecanism de publicare în măsură să asigure termenele de transmisie prevăzute în secțiunea 2.2 pentru fiecare metodă de distribuire.
Cerințele AA-urilor nu sunt definite, dar este necesar ca ele să poată accepta aceleași niveluri de securitate ca celelalte entități, iar acestea trebuie să fie declarate în CPS-ul lor.
2.4.Controale ale accesului la registre
(32)Cerințele privind controlul accesului la registrele cu informații referitoare la certificate trebuie să respecte cel puțin standardele generale referitoare la managementul securității informațiilor prevăzute în ISO/IEC 27001 și cerințele din secțiunea 4. În plus, ele trebuie să reflecte necesitățile de securizare a procesului care urmează să fie stabilite pentru diferitele etape ale procesului de publicare a informațiilor referitoare la certificate.
·Aceste cerințe includ implementarea registrului pentru certificatele TLM și ECTL în TLM/CPOC. Fiecare CA sau operator de registru pune în aplicare controale ale accesului în legătură cu toate entitățile C-ITS și părțile externe pentru cel puțin trei niveluri (de exemplu, nivelul public, nivelul restricționat la entitățile C-ITS, nivelul CA primare) pentru a împiedica entitățile neautorizate să adauge, să modifice sau să șteargă înregistrări din registru.
·Mecanismele exacte de control al accesului ale entității unice ar trebui să facă parte din CPS respectivă.
·Pentru fiecare CA primară, registrele EA și AA trebuie să respecte aceleași cerințe privind procedurile de control al accesului, indiferent de loc sau de relația contractuală cu furnizorul de servicii care operează registrul.
Ca punct de pornire pentru nivelurile controlului accesului, fiecare CA primară sau operator de registru ar trebui să furnizeze cel puțin trei niveluri diferite (de exemplu, nivelul public, nivelul restricționat la entitățile C-ITS, nivelul CA primare).
2.5.Publicarea informațiilor referitoare la certificate
2.5.1.Publicarea informațiilor referitoare la certificate de către TLM
(33)TLM din domeniul european comun de încredere C-ITS publică următoarele informații prin intermediul CPOC:
·toate certificatele TLM valabile actualmente pentru următoarea perioadă de operare (certificatul în vigoare și certificatul de legătură, dacă sunt disponibile);
·informații privind punctul de acces pentru registrul CPOC, pentru a furniza lista semnată a CA-urilor primare (ECTL);
·punctul de informare generală în privința ECTL și a implementării C-ITS.
2.5.2.Publicarea informațiilor referitoare la certificate de către CA-uri
(34)CA-urile primare din domeniul european comun de încredere C-ITS publică următoarele informații:
·certificatele CA primare emise (valabile actualmente) (certificate în vigoare și cu chei regenerate corect, inclusiv un certificat de legătură) în registrul menționat în secțiunea 2.3;
·toate entitățile EA, AA valabile, cu identificatorul lor de operator și perioada lor planificată de operare;
·certificatele CA emise din registrele menționate în secțiunea 2.3;
·CRL-urile pentru toate certificatele CA revocate, acoperind EA-urile și AA-urile lor subordonate;
·informațiile privind punctul de acces al CA primare la CRL și la informațiile privind CA.
Toate informațiile referitoare la certificate sunt clasificate în funcție de trei niveluri de confidențialitate, iar documentele destinate publicului larg trebuie să fie făcute publice fără restricții.
3.Identificarea și autentificarea
3.1.Alegerea numelor
3.1.1.Tipuri de nume
3.1.1.1.Nume pentru TLM, CA-uri primare, EA-uri, AA-uri
(35)Numele din certificatul TLM constă într-un singur atribut subject_name cu valoarea rezervată „EU_TLM”.
(36)Numele pentru CA-urile primare constă într-un singur atribut subject_name cu o valoare alocată de CPA. Caracterul unic al numelor este responsabilitatea exclusivă a CPA, iar TLM menține registrul numelor CA primare în urma notificării de către CPA (aprobare, revocare/radiere a unei CA primare). Numele subiecților din certificate sunt limitate la 32 de octeți. Fiecare CA primară propune CPA numele său în formularul de cerere (fluxul 14). CPA răspunde de verificarea caracterului unic al numelui. Dacă numele nu este unic, formularul de cerere este respins (fluxul 4).
(37)Numele din fiecare certificat EA/AA poate consta într-un singur atribut subject_name, cu o valoare generată de emitentul certificatului. Caracterul unic al numelor este responsabilitatea exclusivă a CA primare emitente.
(38)Certificatele EA și AA nu trebuie să utilizeze nume de peste 32 de octeți deoarece atributul subject_name din certificate este limitat la 32 de octeți.
(39)AT-urile nu pot conține un nume.
3.1.1.2.Nume pentru entitățile finale
(40)Fiecărei stații C-ITS i se atribuie două tipuri de identificatori unici:
·un identificator canonic, care este stocat la înregistrarea inițială a stației C-ITS pe răspunderea producătorului. Acesta conține un subșir care identifică producătorul sau operatorul, astfel încât identificatorul să poată fi unic;
·un atribut subject_name, care poate face parte din EC a stației C-ITS, pe răspunderea EA.
3.1.1.3.Identificarea certificatelor
(41)Certificatele care respectă formatul din [5] sunt identificate prin calcularea unei valori HashedId8, astfel cum se definește în [5].
3.1.2.Necesitatea ca numele să aibă sens
Nicio dispoziție.
3.1.3.Caracterul anonim și pseudonim al entităților finale
(42)AA garantează că se asigură caracterul pseudonim al unei stații C-ITS furnizând stației C-ITS AT-uri care nu conțin nume sau informații care pot corela subiectul cu identitatea sa reală.
3.1.4.Reguli de interpretare a diverselor forme ale numelor
Nicio dispoziție.
3.1.5.Caracterul unic al numelor
(43)Numele TLM, CA-urilor primare, EA-urilor și AA-urilor și identificatorii canonici pentru stațiile C-ITS sunt unici.
(44)TLM se asigură, în cadrul procesului de înregistrare în ECTL a unei anumite CA primare, că identificatorul certificatului său (HashedId8) este unic. CA primară se asigură, în cadrul procesului de emitere, că identificatorul certificatului (HashedId8) al fiecărei CA subordonate este unic.
(45)HashedId8 al unei EC este unic în cadrul CA emitente. HashedId8 al unui AT nu trebuie să fie unic.
3.2.Validarea inițială a identității
3.2.1.Metoda de dovedire a posesiei cheii private
(46)CA primară trebuie să dovedească faptul că are dreptul să dețină cheia privată care corespunde cheii publice din certificatul autosemnat. CPOC trebuie să verifice această dovadă.
(47)EA/AA trebuie să dovedească faptul că are dreptul să dețină cheia privată care corespunde cheii publice care urmează să fie listată în certificat. CA primară trebuie să verifice această dovadă.
(48)Posesia unei chei private noi (pentru regenerarea cheii) se dovedește prin semnarea solicitării cu cheia privată nouă (semnătură internă), urmată de generarea unei semnături externe pentru ca solicitarea semnată să fie suprasemnată cu cheia privată valabilă actuală (pentru a garanta autenticitatea solicitării). Solicitantul transmite solicitarea de certificat semnată către CA emitentă prin comunicație securizată. CA emitentă verifică dacă semnătura digitală a solicitantului de pe mesajul de solicitare a fost creată utilizând cheia privată care corespunde cheii publice asociate solicitării de certificat. CA primară specifică care sunt solicitările de certificate și răspunsurile pe care le acceptă în CPS a sa.
3.2.2.Autentificarea identității organizației
3.2.2.1.Autentificarea identității organizației CA primare
(49)Într-un formular de cerere adresat CPA (și anume, fluxul 14), CA primară indică identitatea organizației și informațiile de înregistrare, compuse din:
·numele organizației;
·adresa poștală;
·adresa de e-mail;
·numele unei persoane fizice de contact din organizație;
·numărul de telefon;
·amprenta digitală (și anume, SHA 256 hashvalue) a certificatului CA primare în formă tipărită;
·informațiile criptografice (și anume, algoritmii criptografici, lungimile cheilor) din certificatul CA primare;
·toate permisiunile pe care CA primară are dreptul să le utilizeze și să le transmită CA-urilor subordonate.
(50)CPA verifică identitatea organizației și celelalte informații de înregistrare furnizate de solicitantul certificatului pentru introducerea unui certificat al CA primare în ECTL.
(51)CPA colectează fie dovezi directe, fie o certificare provenită dintr-o sursă corespunzătoare și autorizată, cu privire la identitatea (de exemplu, numele) și, dacă este cazul, orice atribute specifice ale subiecților cărora li se emite un certificat. Dovezile depuse pot fi pe suport de hârtie sau documentații electronice.
(52)Identitatea subiectului este verificată la momentul înregistrării prin mijloace adecvate și în conformitate cu prezenta politică de certificare.
(53)Pentru fiecare cerere de certificat, se furnizează dovezi privind:
·numele complet al entității organizaționale (organizație privată, entitate guvernamentală sau entitate necomercială);
·înregistrarea recunoscută la nivel național sau alte atribute care pot fi utilizate, în măsura posibilului, pentru a distinge entitatea organizațională de altele cu același nume.
Regulile de mai sus se bazează pe TS 102 042 [4]: CA se asigură că dovezile referitoare la identificarea abonatului și a subiectului și exactitatea numelor lor și a datelor asociate fie sunt examinate corespunzător în cadrul serviciului definit, fie, atunci când este cazul, sunt constatate prin examinarea atestărilor provenite din surse corespunzătoare și autorizate și că solicitările de certificate sunt exacte, autorizate și complete în conformitate cu dovezile colectate sau cu atestarea.
3.2.2.2.Autentificarea identității organizației TLM
(54)Organizația care operează TLM furnizează dovezi ale identificării și exactității numelor și datelor asociate pentru a permite verificarea adecvată la momentul creării inițiale și al regenerării cheii certificatului TLM.
(55)Identitatea subiectului este verificată la momentul creării certificatului sau al regenerării cheii, prin mijloace adecvate și în conformitate cu prezenta CP.
(56)Dovezile referitoare la organizație se furnizează astfel cum se precizează în secțiunea 3.2.2.1.
3.2.2.3.Autentificarea identității organizațiilor CA-urilor subordonate
(57)CA primară verifică identitatea organizației și alte informații de înregistrare furnizate de solicitanții de certificate în cazul certificatelor CA-urilor subordonate (EA/AA).
(58)CA primară trebuie cel puțin:
·să stabilească dacă organizația există utilizând cel puțin un serviciu terț sau o bază de date terță de control al identității sau, alternativ, documente organizaționale care confirmă existența organizației, emise de agenția guvernamentală relevantă sau de autoritatea recunoscută ori depuse la una dintre acestea;
·să utilizeze corespondența prin poștă sau o procedură comparabilă prin care să ceară solicitantului certificatului să confirme anumite informații despre organizație, că a autorizat cererea de certificat și că persoana care depune cererea în numele solicitantului este autorizată în acest scop. În cazul în care un certificat conține numele unei persoane în calitate de reprezentant autorizat al organizației, organizația trebuie să confirme, de asemenea, că a angajat acea persoană și că a autorizat-o să acționeze în numele ei.
(59)Procedurile de validare pentru emiterea certificatelor CA trebuie să fie documentate într-o CPS a CA primare.
3.2.2.4.Autentificarea organizației abonatului entităților finale
(60)Înainte ca abonatul entităților finale (producător/operator) să se poată înregistra la o EA de încredere pentru a permite entităților sale finale să transmită solicitări de certificate EC, EA trebuie:
·să verifice identitatea organizației abonatului și alte informații de înregistrare furnizate de solicitantul certificatului;
·să verifice dacă tipul stației C-ITS (și anume, produsul concret în funcție de marca, modelul și versiunea stației C-ITS) îndeplinește toate criteriile de evaluare a conformității.
(61)EA trebuie cel puțin:
·să stabilească dacă organizația există utilizând cel puțin un serviciu terț sau o bază de date terță de control al identității sau, alternativ, documente organizaționale care confirmă existența organizației, emise de agenția guvernamentală relevantă sau de autoritatea recunoscută ori depuse la una dintre acestea;
·să utilizeze corespondența prin poștă sau o procedură comparabilă prin care să ceară solicitantului certificatului să confirme anumite informații despre organizație, că a autorizat cererea de certificat și că persoana care depune cererea în numele său este autorizată în acest scop. În cazul în care un certificat conține numele unei persoane în calitate de reprezentant autorizat al organizației, organizația trebuie să confirme, de asemenea, că a angajat acea persoană și că a autorizat-o să acționeze în numele ei.
(62)Procedurile de validare pentru înregistrarea unei stații C-ITS de către abonatul său trebuie să fie documentate într-o CPS a EA.
3.2.3.Autentificarea entității individuale
3.2.3.1.Autentificarea entității individuale TLM/CA
(63)În vederea autentificării unei entități individuale (persoană fizică) identificată în asociere cu o persoană juridică sau cu o entitate organizațională (de exemplu, abonatul), trebuie să se furnizeze dovezi privind:
·numele complet al subiectului (inclusiv numele de familie și prenumele, în conformitate cu legislația aplicabilă și cu practicile de identificare naționale);
·data și locul nașterii și o trimitere la un document de identitate recunoscut la nivel național sau alte atribute ale abonatului care pot fi utilizate, în măsura posibilului, pentru a distinge persoana de altele cu același nume;
·numele complet și forma juridică a persoanei juridice sau ale altei entități organizaționale asociate (de exemplu, abonatul);
·orice informații de înregistrare relevante (de exemplu, înregistrarea societății) ale persoanei juridice sau ale altei entități organizaționale asociate;
·dovada că subiectul este asociat cu persoana juridică sau cu altă entitate organizațională.
Dovezile depuse pot fi pe suport de hârtie sau documentații electronice.
(64)Pentru a-și dovedi identitatea, reprezentantul autorizat al CA primare, al EA, al AA sau al abonatului trebuie să prezinte documentația care dovedește că lucrează pentru organizație (certificat de autorizare). Reprezentantul autorizat trebuie să prezinte și un act de identitate oficial.
(65)Pentru procesul de înscriere inițială (fluxul 31/32), un reprezentant al EA/AA trebuie să furnizeze CA primare corespunzătoare toate informațiile necesare (a se vedea secțiunea 4.1.2).
(66)Personalul din cadrul CA primare verifică identitatea reprezentantului solicitantului certificatului și toate documentele asociate, aplicând cerințele privind „personalul de încredere” prevăzute în secțiunea 5.2.1. (Procesul de validare a informațiilor din cerere și de generare a certificatului de către CA primară se efectuează de către „persoanele de încredere” din cadrul CA primare, cel puțin sub dublă supraveghere deoarece sunt operațiuni sensibile în sensul secțiunii 5.2.2).
3.2.3.2.Autentificarea identității abonaților stațiilor C-ITS
(67)Abonații sunt reprezentați de utilizatori finali autorizați din cadrul organizației, care sunt înregistrați la EA și AA emitente. Acești utilizatori finali desemnați de organizații (producători sau operatori) își dovedesc identitatea și autenticitatea:
·înainte de a înregistra EE la EA corespunzătoare, inclusiv cheia canonică publică a acesteia, identificatorul său canonic (identificator unic) și permisiunile în conformitate cu EE;
·înainte de a se înregistra la AA și de a obține dovada unui acord de abonare care poate fi trimisă EA.
3.2.3.3.Autentificarea identității stațiilor C-ITS
(68)Subiecții EE ai EC-urilor se autentifică atunci când solicită EC-uri (fluxul 31), utilizând cheia lor privată canonică pentru autentificarea inițială. EA verifică autentificarea utilizând cheia canonică publică ce corespunde EE. Cheile canonice publice ale EE-urilor sunt aduse la EA înainte de executarea solicitării inițiale, printr-un canal securizat între producătorul sau operatorul stației C-ITS și EA (fluxul 33).
(69)Subiecții EE ai AT-urilor se autentifică atunci când solicită AT-uri (fluxul 32), utilizând cheia lor privată unică de înscriere. AA redirecționează semnătura către EA (fluxul 25) în vederea validării; EA o validează și confirmă AA rezultatul (fluxul 23).
3.2.4.Informații neverificate despre abonați
Nicio dispoziție.
3.2.5.Validarea autorității
3.2.5.1.Validarea TLM, CA primare, EA, AA
(70)Fiecare organizație identifică în CPS cel puțin un reprezentant (de exemplu, un responsabil cu securitatea) care răspunde de solicitarea certificatelor noi și a reînnoirilor. Se aplică dispozițiile referitoare la nume din secțiunea 3.2.3.
3.2.5.2.Validarea abonaților stațiilor C-ITS
(71)Cel puțin o persoană fizică responsabilă cu înregistrarea stațiilor C-ITS la o EA (de exemplu, responsabilul cu securitatea) trebuie să fie cunoscută și aprobată de EA (a se vedea secțiunea 3.2.3).
3.2.5.3.Validarea stațiilor C-ITS
(72)Un abonat al unei stații C-ITS poate să înregistreze stații C-ITS la o anumită EA (fluxul 33) în măsura în care este autentificat la acea EA.
Atunci când stația C-ITS este înregistrată la o EA cu un identificator canonic unic și cu o cheie canonică publică, aceasta poate solicita o EC utilizând o solicitare semnată cu cheia canonică privată asociată cheii canonice publice înregistrate anterior.
3.2.6.Criterii de interoperare
(73)Pentru comunicația dintre stațiile C-ITS și EA-uri (sau AA-uri), stația C-ITS trebuie să fie în măsură să stabilească comunicații securizate cu EA-urile (sau AA-urile), și anume să implementeze funcții de autentificare, confidențialitate și integritate, astfel cum se precizează în [1]. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare. Este necesar ca EA și AA să poată stabili aceste comunicații securizate.
(74)Este necesar ca EA și AA să poată accepta solicitări de certificate și răspunsuri care respectă [1], ceea ce asigură un protocol securizat pentru solicitările/răspunsurile privind AT care permite anonimatul solicitantului față de AA și separarea atribuțiilor AA și EA. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare. Pentru a preveni divulgarea identității pe termen lung a stațiilor C-ITS, comunicația dintre o stație C-ITS mobilă și o EA trebuie să fie confidențială (de exemplu, datele care fac obiectul comunicației trebuie să fie criptate integral).
(75)AA transmite o solicitare de validare a autorizării (fluxul 25) pentru fiecare solicitare de autorizare pe care o primește de la un subiect al certificatului EE. EA validează respective solicitare în ceea ce privește:
·statutul EE în cadrul EA;
·valabilitatea semnăturii;
·identificatorii aplicațiilor ITS (ITS-AID-urile) și permisiunile solicitate;
·statutul furnizării serviciilor AA către abonat.
3.3.Identificarea și autentificarea în cazul solicitărilor de regenerare a cheii
3.3.1.Identificarea și autentificarea în cazul solicitărilor de regenerare a cheii de rutină
3.3.1.1.Certificatele TLM
(76)TLM generează o pereche de chei și două certificate: un certificat autosemnat și un certificat de legătură, astfel cum se menționează în secțiunea 7.
3.3.1.2.Certificatele CA primare
Nu se aplică.
3.3.1.3.Reînnoirea sau regenerarea cheii certificatului EA/AA
(77)Înainte de expirarea unui certificat EA/AA, EA/AA trebuie să solicite un certificat nou (fluxul 21/fluxul 24) pentru a asigura continuitatea utilizării certificatului. EA/AA generează o pereche de chei nouă care înlocuiește perechea de chei care expiră și semnează solicitarea de regenerare a cheii care conține cheia publică nouă cu cheia privată valabilă actuală („regenerarea cheii”). EA sau AA generează o pereche de chei nouă și semnează solicitarea cu cheia privată nouă (semnătură internă) pentru a dovedi că posedă cheia privată nouă. Întreaga solicitare este semnată (suprasemnată) cu cheia privată valabilă actuală (semnătură externă) pentru a se asigura integritatea și autenticitatea solicitării. Dacă se utilizează o pereche de chei de criptare și de decriptare, trebuie dovedită posesia cheilor de decriptare private (pentru descrierea detaliată a regenerării cheii a se vedea secțiunea 4.7.3.3).
(78)Metoda de identificare și de autentificare pentru regenerarea de rutină a cheii este identică cu cea utilizată la emiterea inițială a unei validări inițiale de certificat al CA primare, astfel cum se prevede în secțiunea 3.2.2.
3.3.1.4.Acreditările de înscriere ale entităților finale
(79)Înainte de expirarea unei EC existente, EE trebuie să solicite un certificat nou (fluxul 31) pentru a asigura continuitatea utilizării certificatului. EE generează o pereche de chei nouă, care înlocuiește perechea de chei care expiră, și solicită un certificat nou care conține cheia publică nouă; solicitarea se semnează cu cheia privată EC valabilă actuală.
(80)EE poate semna solicitarea cu cheia privată nou creată (semnătură internă) pentru a dovedi că posedă cheia privată nouă. Întreaga solicitare este apoi semnată (suprasemnată) cu cheia privată valabilă actuală (semnătură externă) și criptată față de EA destinatară, astfel cum se precizează în [1], pentru a se asigura confidențialitatea, integritatea și autenticitatea solicitării. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare.
3.3.1.5.Tichetele de autorizare ale entităților finale
(81)Regenerarea cheii certificatului pentru AT-uri se bazează pe același proces ca autorizarea inițială, astfel cum se definește în [1]. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare.
3.3.2.Identificarea și autentificarea în cazul solicitărilor de regenerare a cheii după revocare
3.3.2.1.Certificatele CA
(82)Autentificarea unei organizații CA pentru regenerarea cheilor certificatelor CA primare, EA și AA după revocare este tratată în același mod ca emiterea inițială a unui certificat al CA, astfel cum se prevede în secțiunea 3.2.2.
3.3.2.2.Acreditările de înscriere ale entităților finale
(83)Autentificarea unei EE pentru regenerarea cheii certificatului EC după revocare este tratată în același mod ca emiterea inițială a unui certificat EE, astfel cum se prevede în secțiunea 3.2.2.
3.3.2.3.Solicitările de autorizare ale entităților finale
Nu se aplică deoarece AT-urile nu sunt revocate.
3.4.Identificarea și autentificarea în cazul solicitării revocării
3.4.1.Certificatele CA primare/EA/AA
(84)Solicitările de ștergere a unui certificat al CA primare din ECTL sunt autentificate de către CA primară față de TLM (fluxurile 12 și 9). Solicitările de revocare a unui certificat EA/AA sunt autentificate de către CA primară relevantă și de către CA subordonată însăși.
(85)Procedurile admisibile pentru autentificarea solicitărilor de revocare ale unui abonat includ:
·un mesaj scris și semnat, pe hârtie cu antetul societății, din partea abonatului, prin care se solicită revocarea indicând certificatul care urmează să fie revocat;
·comunicarea cu abonatul prin care se furnizează asigurări rezonabile că persoana sau organizația care solicită revocarea este în realitate abonatul. În funcție de circumstanțe, această comunicare se poate face printr-una sau mai multe dintre modalitățile următoare: e-mail, corespondență prin poștă sau serviciu de curierat.
3.4.2.Acreditările de înscriere ale stației C-ITS
(86)Abonatul stației C-ITS poate revoca EC a unei stații C-ITS înregistrate anterior la o EA (fluxul 34). Abonatul solicitant creează o solicitare de revocare a unei anumite stații C-ITS sau a unei liste de stații C-ITS. EA autentifică solicitarea de revocare înainte de a o prelucra și confirmă revocarea stațiilor C-ITS și a EC-urilor lor.
(87)EA poate revoca EC a unei stații C-ITS în conformitate cu secțiunea 7.3.
3.4.3.Tichetele de autorizare ale stației C-ITS
(88)Deoarece AT-urile nu sunt revocate, valabilitatea lor este limitată la o anumită perioadă. Intervalul de perioade de valabilitate admisibile în cazul prezentei politici de certificare este prevăzut în secțiunea 7.
4.Cerințele operaționale privind ciclul de viață al certificatelor
4.1.Cererea de certificat
(89)Secțiunea de față prevede cerințele aplicabile cererii inițiale de emitere a certificatului.
(90)Termenul „cerere de certificat” se referă la procesele următoare:
·înregistrarea și stabilirea unei relații de încredere între TLM și CPA;
·înregistrarea și stabilirea unei relații de încredere între CA primară și CPA și TLM, inclusiv introducerea primului certificat al CA primare în ECTL;
·înregistrarea și stabilirea unei relații de încredere între EA/AA și CA primară, inclusiv emiterea unui certificat EA/AA nou;
·înregistrarea stației C-ITS la EA de către producător/operator;
·cererea de EC/AT a stației C-ITS.
4.1.1.Cine poate transmite o cerere de certificat
4.1.1.1.CA-urile primare
(91)CA-urile primare își generează propriile perechi de chei și își emit singure certificatele primare. O CA primară poate transmite o cerere de certificat prin reprezentantul său desemnat (fluxul 14).
4.1.1.2.TLM
(92)TLM își generează propriile perechi de chei și își emite singur certificatele. De crearea inițială a certificatului TLM se ocupă un reprezentant al organizației TLM, sub controlul CPA.
4.1.1.3.EA și AA
(93)Un reprezentant autorizat al EA sau AA poate transmite cererea de certificat pentru o CA subordonată (EA și/sau AA) reprezentantului autorizat al CA primare relevante (fluxul 27/28).
4.1.1.4.Stația C-ITS
(94)Abonații înregistrează fiecare stație C-ITS la EA în conformitate cu secțiunea 3.2.5.3.
(95)Fiecare stație C-ITS înregistrată la EA poate transmite solicitări de EC (fluxul 31).
(96)Fiecare stație C-ITS poate transmite solicitări de AT (fluxul 32) fără a necesita nicio interacțiune din partea abonatului. Înainte de a solicita un AT, o stație C-ITS trebuie să aibă o EC.
4.1.2.Procesul de înscriere și responsabilitățile aferente
(97)Permisiunile pentru emiterea certificatelor de către CA-uri primare și CA-uri subordonate în scopuri speciale (guvernamentale) (și anume, stații C-ITS speciale mobile și fixe) pot fi acordate doar de statele membre în care se află organizațiile respective.
4.1.2.1.CA-urile primare
(98)După ce au fost auditate (fluxurile 13 și 36, secțiunea 8), CA-urile primare pot solicita introducerea certificatului (certificatelor) lor în ECTL la CPA (fluxul 14). Procesul de înscriere se bazează pe un formular de cerere manual semnat care trebuie să fie depus fizic la CPA de către reprezentantul autorizat al CA primare și care trebuie să conțină cel puțin informațiile menționate în secțiunile 3.2.2.1, 3.2.3 și 3.2.5.1.
(99)Formularul de cerere al CA primare se semnează de către reprezentantul autorizat al acesteia.
(100)Pe lângă formularul de cerere, reprezentantul autorizat al CA primare trebuie să prezinte CPA o copie a CPS a CA primare (fluxul 15) și raportul său de audit, în vederea aprobării (fluxul 16). În cazul aprobării pozitive, CPA generează și trimite un certificat de conformitate către CPOC/TLM și către CA primară corespunzătoare.
(101)Apoi, reprezentantul autorizat al CA-urilor primare prezintă CPOC/TLM formularul său de cerere (conținând amprenta certificatului autosemnat), actul de identitate oficial și dovada autorizării. Certificatul autosemnat se transmite către CPOC/TLM prin mijloace electronice. CPOC/TLM verifică toate documentele și certificatul autosemnat.
(102)În cazul în care verificările au rezultate pozitive, TLM adaugă certificatul CA primare în ECTL pe baza notificării primite de la CPA (fluxurile 1 și 2). Procesul detaliat este descris în CPS a TLM.
(103)Ar trebui să fie posibilă o procedură suplimentară pentru obținerea aprobării CPS și a raportului de audit ale unei CA primare de către un organism național al anumitor țări.
4.1.2.2.TLM
(104)După ce este auditat, TLM se poate înscrie la CPA. Procesul de înscriere se bazează pe un formular de cerere manual semnat care trebuie să fie depus fizic la CPA (fluxul 38) de către reprezentantul autorizat al TLM și care trebuie să conțină cel puțin informațiile menționate în secțiunile 3.2.2.2 și 3.2.3.
(105)Formularul de cerere al TLM se semnează de către reprezentantul său autorizat.
(106)Mai întâi, TLM își generează certificatul autosemnat și îl transmite CPA în mod securizat. Apoi, TLM prezintă CPA formularul său de cerere (conținând amprenta certificatului autosemnat), o copie a CPS a sa, un act de identitate oficial, o dovadă a autorizării și raportul său de audit (fluxul 40). CPA verifică toate documentele și certificatul autosemnat. În cazul în care verificarea tuturor documentelor, a certificatului autosemnat și a amprentei are rezultate pozitive, CPA confirmă procesul de înscriere transmițând aprobarea sa către TLM și CPOC (fluxul 39). CPA stochează informațiile referitoare la cerere transmise de TLM. Apoi, certificatul TLM este emis prin intermediul CPOC.
4.1.2.3.EA și AA
(107)În timpul procesului de înscriere, EA/AA prezintă documentele relevante (de exemplu CPS și raportul de audit) către CA primară corespunzătoare în vederea aprobării (fluxul 27/28). În cazul în care verificările documentelor au rezultate pozitive, CA primară transmite o aprobare către CA-urile subordonate corespunzătoare (fluxul 29/30). Apoi, CA subordonată (EA sau AA) își transmite solicitarea semnată prin mijloace electronice și depune fizic la CA primară corespunzătoare formularul de cerere (în conformitate cu secțiunea 3.2.2.1), dovada autorizării și documentul de identificare. CA primară verifică solicitarea și documentele primite (formularul de cerere care conține amprenta, care este SHA 256 hashvalue a solicitării CA subordonate, dovada autorizării și documentul de identificare). Dacă toate verificările au un rezultat pozitiv, CA primară eliberează certificatul corespunzător al CA subordonate. Informațiile detaliate despre modalitatea de efectuare a unei solicitări inițiale sunt descrise în CPS specifică a sa.
(108)Pe lângă formularul de cerere al CA subordonate, reprezentantul autorizat al CA subordonate atașează o copie a CPS destinată CA primare.
(109)Auditorului acreditat al PKI i se furnizează informațiile necesare pentru auditare în conformitate cu secțiunea 8.
(110)În cazul în care o CA subordonată este deținută de o entitate diferită de cea care deține o CA primară, entitatea CA subordonată trebuie să semneze un contract privind serviciul CA primare înainte de emiterea unei solicitări de certificat pentru o CA subordonată.
4.1.2.4.Stația C-ITS
(111)Înregistrarea inițială a subiecților care sunt entități finale (stații C-ITS) se efectuează de către abonatul responsabil (producător/operator) la EA (fluxurile 33 și 35) după autentificarea cu succes a organizației abonatului și a unuia dintre reprezentanții acestuia, în conformitate cu secțiunile 3.2.2.4 și 3.2.5.2.
(112)O stație C-ITS poate să genereze o pereche de chei EC (a se vedea secțiunea 6.1) și să creeze o solicitare de EC semnată, în conformitate cu [1]. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare.
(113)În timpul înregistrării unei stații C-ITS normale (spre deosebire de o stație C-ITS specială mobilă sau fixă), EA trebuie să se asigure că permisiunile din solicitarea inițială nu sunt destinate utilizării guvernamentale. Permisiunile destinate utilizării guvernamentale sunt definite de statele membre corespunzătoare. Procedura detaliată de înregistrare și de răspuns al EA către producător/operator (fluxurile 33 și 35) trebuie prevăzută în CPS corespunzătoare a EA.
(114)O stație C-ITS se înregistrează la o EA (secțiunea 3.2.5.3) prin transmiterea solicitării sale inițiale de EC în conformitate cu [1].
(115)La momentul înregistrării inițiale de către reprezentantul unui abonat autentificat, EA aprobă AT-urile pe care le poate obține subiectul care este o entitate finală (și anume, stația C-ITS). În plus, fiecărei entități finale i se atribuie un nivel de asigurare a încrederii, care este corelat cu certificarea entității finale în conformitate cu unul dintre profilurile de protecție enumerate în secțiunea 6.1.5.2.
(116)Vehiculele obișnuite au o singură stație C-ITS care este înregistrată la o singură EA. Vehiculele cu destinație specială (cum ar fi autovehiculele de poliție și alte vehicule cu destinație specială și drepturi specifice) pot fi înregistrate la o EA suplimentară sau pot avea o stație C-ITS suplimentară pentru autorizațiile din sfera respectivei destinații speciale. Statele membre responsabile definesc căror vehicule li se aplică această exceptare. Permisiunile pentru stațiile C-ITS speciale mobile și fixe sunt acordate numai de statele membre responsabile. În CPS a CA-urilor primare sau a CA-urilor subordonate care emit certificate pentru astfel de vehicule în respectivele state membre trebuie să se determine modul în care se aplică acestor vehicule procesul de certificare.
(117)Atunci când abonatul are în curs de derulare o acțiune de migrare a unei stații C-ITS de la o EA la o altă EA, stația C-ITS poate să fie înregistrată la două EA-uri (similare).
(118)O stație C-ITS generează o pereche de chei AT (a se vedea secțiunea 6.1) și creează o solicitare de AT în conformitate cu [1]. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare.
(119)Stațiile C-ITS trimit o solicitare de autorizare la URL-ul AA (fluxurile 32 și 26), transmițând cel puțin informațiile necesare menționate în secțiunea 3.2.3.3. AA și EA validează autorizarea pentru fiecare solicitare în conformitate cu secțiunile 3.2.6 și 4.2.2.5.
4.2.Prelucrarea cererilor de certificate
4.2.1.Efectuarea funcțiilor de identificare și de autentificare
4.2.1.1.Identificarea și autentificarea CA-urilor primare
(120)Reprezentantul autorizat al CPA răspunde de autentificarea reprezentantului autorizat al CA primare și de aprobarea procesului de înscriere al acesteia în conformitate cu secțiunea 3.
4.2.1.2.Identificarea și autentificarea TLM
(121)Reprezentantul autorizat al CPA răspunde de autentificarea reprezentantului autorizat al TLM și de aprobarea formularului său de cerere pentru procesul de înscriere în conformitate cu secțiunea 3.
4.2.1.3.Identificarea și autentificarea EA și AA
(122)CA primară corespunzătoare răspunde de autentificarea reprezentantului autorizat al EA/AA și de aprobarea formularului său de cerere pentru procesul de înscriere în conformitate cu secțiunea 3.
(123)CA primară confirmă EA/AA validarea sa pozitivă a formularului de cerere. Apoi, EA/AA poate trimite către CA primară o solicitare de certificat (fluxul 21/24), iar aceasta din urmă va emite certificatele către EA/AA corespunzătoare (fluxul 18/19).
4.2.1.4.Identificarea și autentificarea abonatului EE
(124)Înainte ca o stație C-ITS să poată solicita un certificat EC, abonatul EE trebuie să transmită în mod securizat informațiile despre identificatorul stației C-ITS către EA (fluxul 33). EA verifică solicitarea și, în cazul în care verificarea are rezultate pozitive, înregistrează informațiile stației C-ITS în baza sa de date și confirmă acest lucru abonatului EE (fluxul 35). Această operațiune este efectuată o singură dată de către producător sau de către operator pentru fiecare stație C-ITS. Odată înregistrată de o EA, o stație C-ITS nu poate solicita decât, pe rând, câte un certificat EC de care are nevoie (fluxul 31). EA autentifică și verifică dacă informațiile din solicitarea de certificat EC sunt valabile pentru o stație C-ITS.
4.2.1.5.Tichete de autorizare
(125)În timpul solicitărilor de autorizare (fluxul 32), în conformitate cu [1], AA trebuie să autentifice EA de la care și-a primit stația C-ITS EC-ul. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare. Dacă AA nu este în măsură să autentifice EA, solicitarea este respinsă (fluxul 26). Se impune ca AA să posede certificatul EA pentru a autentifica EA și pentru a-i verifica răspunsul (fluxurile 25 și 23, secțiunea 3.2.5.3).
(126)EA autentifică stația C-ITS care solicită un AT prin verificarea EC a acesteia (fluxurile 25 și 23).
4.2.2.Aprobarea sau respingerea cererilor de certificate
4.2.2.1.Aprobarea sau respingerea certificatelor CA primare
(127)TLM introduce/șterge certificatele CA primare în/din ECTL în conformitate cu aprobarea primită de la CPA (fluxul 1/2).
(128)TLM ar trebui să verifice semnătura, informațiile și codificarea certificatelor CA primare după primirea unei aprobări din partea CPA (fluxul 1). După validarea pozitivă și aprobarea de către CPA, TLM introduce certificatul primar corespunzător în ECTL și notifică CPA (fluxul 5).
4.2.2.2.Aprobarea sau respingerea certificatului TLM
(129)CPA răspunde de aprobarea sau de respingerea certificatelor TLM.
4.2.2.3.Aprobarea sau respingerea certificatelor EA și AA
(130)CA primară verifică solicitările de certificate ale CA subordonate (fluxul 21/24) și rapoartele relevante (emise de auditorul acreditat al PKI) la primirea acestora (fluxul 36, secțiunea 8) de la CA subordonată corespunzătoare a CA primare. Dacă verificarea solicitării are un rezultat pozitiv, CA primară corespunzătoare eliberează un certificat EA/AA solicitante (fluxul 18/19); în caz contrar, solicitarea este respinsă și nu se eliberează certificatul către EA/AA.
4.2.2.4.Aprobarea sau respingerea EC
(131)EA verifică și validează solicitările de EC, în conformitate cu secțiunile 3.2.3.2 și 3.2.5.3.
(132)Dacă solicitarea de certificat conformă cu [1] este corectă și valabilă, EA generează certificatul solicitat.
(133)Dacă solicitarea de certificat nu este valabilă, EA o refuză și trimite un răspuns care indică motivul refuzului în conformitate cu [1]. Dacă dorește în continuare o EC, o stație C-ITS trebuie să facă o nouă solicitare de certificat. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare.
4.2.2.5.Aprobarea sau respingerea AT
(134)Solicitarea de certificat este verificată de EA. AA stabilește comunicația cu EA pentru a valida solicitarea (fluxul 25). EA autentifică stația C-ITS solicitantă și validează dacă aceasta are dreptul să primească AT-ul solicitat pe baza CP (de exemplu, prin verificarea statutului revocării și validarea orei certificatului/valabilității regiunii, a permisiunilor, a nivelului de asigurare etc.). EA trimite un răspuns de validare (fluxul 23) și, dacă răspunsul este pozitiv, AA generează certificatul solicitat și îl transmite stației C-ITS. Dacă solicitarea de AT nu este corectă sau răspunsul de validare al EA este negativ, AA refuză solicitarea. Dacă în continuare necesită un AT, o stație C-ITS trebuie să facă o nouă solicitare de autorizare.
4.2.3.Termenul de prelucrare a cererii de certificat
4.2.3.1.Cererea de certificat al CA primare
(135)Procesul de identificare și de autentificare a unei cereri de certificat are loc în zilele lucrătoare și face obiectul unui termen maxim prevăzut în CPS a CA primare.
4.2.3.2.Cererea de certificat al TLM
(136)Prelucrarea cererii de certificat al TLM face obiectul unui termen maxim prevăzut în CPS a TLM.
4.2.3.3.Cererea de certificat al EA și al AA
(137)Procesul de identificare și de autentificare a unei cereri de certificat are loc în zilele lucrătoare în conformitate cu acordul și cu contractul dintre CA primară a statului membru/organizației private și CA subordonată. Prelucrarea cererilor de certificat al CA subordonate face obiectul unui termen maxim prevăzut în CPS a CA subordonate.
4.2.3.4.Cererea de EC
(138)Prelucrarea cererilor de EC face obiectul unui termen maxim prevăzut în CPS a EA.
4.2.3.5.Cererea de AT
(139)Prelucrarea cererilor de AT face obiectul unui termen maxim prevăzut în CPS a AA.
4.3.Emiterea certificatelor
4.3.1.Acțiunile CA în timpul emiterii certificatelor
4.3.1.1.Emiterea certificatului CA primare
(140)CA-urile primare emit propriile certificate CA primare autosemnate, certificate de legătură, certificate CA subordonate și CRL-uri.
(141)După aprobarea de către CPA (fluxul 4), CA primară își trimite certificatul către TLM, prin intermediul CPOC, pentru a fi adăugat pe ECTL (fluxurile 11 și 8) (a se vedea secțiunea 4.1.2.1). TLM verifică dacă CPA a aprobat certificatul (fluxul 1).
4.3.1.2.Emiterea certificatului TLM
(142)TLM emite propriul certificat TLM și certificat de legătură autosemnate și le trimite către CPOC (fluxul 6).
4.3.1.3.Emiterea certificatului EA și AA
(143)CA-urile subordonate generează o solicitare de certificat semnată și o transmit către CA primară corespunzătoare (fluxurile 21 și 24). CA primară verifică solicitarea și emite un certificat către CA subordonată solicitantă în conformitate cu [5] cât mai curând posibil, astfel cum se prevede în CPS pentru practicile operaționale uzuale, dar nu mai târziu de cinci zile lucrătoare de la primirea solicitării.
(144)CA primară actualizează registrul care conține certificatele CA-urilor subordonate.
4.3.1.4.Emiterea EC
(145)Stația C-ITS trimite o solicitare de EC către EA în conformitate cu [1]. EA autentifică și verifică dacă informațiile din solicitarea de certificat sunt valabile pentru o stație C-ITS. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare.
(146)În cazurile în care validarea este pozitivă, EA emite un certificat pe baza înregistrării stației C-ITS (a se vedea 4.2.1.4) și îl trimite stației C-ITS utilizând un mesaj de răspuns referitor la EC în conformitate cu [1]. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare.
(147)Dacă înregistrarea nu există, EA generează un cod de eroare și îl trimite stației C-ITS utilizând un mesaj de răspuns referitor la EC în conformitate cu [1]. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare.
(148)Solicitările de EC și răspunsurile referitoare la EC sunt criptate pentru a asigura confidențialitatea și sunt semnate pentru a asigura autentificarea și integritatea.
4.3.1.5.Emiterea AT
(149)Stația C-ITS trimite un mesaj de solicitare de AT către EA, în conformitate cu [1]. AA trimite către EA o solicitare de validare a AT, în conformitate cu [1]. EA trimite către AA un mesaj de validare a AT. Dacă răspunsul este pozitiv, AA generează un AT și îl trimite stației C-ITS utilizând un mesaj de răspuns referitor la AT în conformitate cu [1]. Dacă răspunsul este negativ, AA generează un cod de eroare și îl trimite stației C-ITS utilizând un mesaj de răspuns referitor la AT în conformitate cu [1]. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare.
(150)Solicitările de AT și răspunsurile referitoare la AT sunt criptate (acest lucru este necesar doar pentru stațiile C-ITS mobile) pentru a asigura confidențialitatea și sunt semnate pentru a asigura autentificarea și integritatea.
4.3.2.Notificarea abonatului de către CA cu privire la emiterea certificatelor.
Nu se aplică.
4.4.Acceptarea certificatului
4.4.1.Derularea procesului de acceptare a certificatului
4.4.1.1.CA primară
Nu se aplică.
4.4.1.2.TLM
Nu se aplică.
4.4.1.3.EA și AA
(151)EA/AA verifică tipul certificatului, semnătura și informațiile din certificatul primit. EA/AA respinge toate certificatele care nu trec de verificare și emite o solicitare nouă.
4.4.1.4.Stația C-ITS
(152)Stația C-ITS verifică răspunsul referitor la EC/AT primit de la EA/AA în raport cu solicitarea sa inițială, inclusiv semnătura și lanțul de certificare. Aceasta respinge toate răspunsurile referitoare la EC/AT care nu sunt verificate corect. În astfel de cazuri, aceasta ar trebui să trimită o solicitare nouă de EC/AT.
4.4.2.Publicarea certificatului
(153)Certificatele TLM și certificatele de legătură ale acestora sunt puse la dispoziția tuturor participanților prin intermediul CPOC.
(154)Certificatele CA primare sunt publicate de CPOC prin intermediul ECTL, care este semnată de TLM.
(155)Certificatele CA-urilor subordonate (ale EA-urilor și ale AA-urilor) sunt publicate de CA primară.
(156)EC-urile și AT-urile nu se publică.
4.4.3.Notificarea emiterii certificatului
Nu se emit notificări cu privire la emitere.
4.5.Utilizarea perechii de chei și a certificatelor
4.5.1.Utilizarea cheii private și a certificatelor
4.5.1.1.Utilizarea cheii private și a certificatelor în cazul TLM
(157)TLM utilizează propriile chei private pentru a semna certificatele proprii (certificate TLM și certificate de legătură) și ECTL.
(158)Certificatul TLM este utilizat de participanții la PKI pentru a verifica ECTL și pentru a autentifica TLM.
4.5.1.2.Utilizarea cheii private și a certificatelor în cazul CA-urilor primare
(159)CA-urile primare utilizează cheile lor private pentru a semna certificatele proprii, CRL, certificatele de legătură și certificatele EA/AA.
(160)Certificatele CA primare sunt utilizate de participanții la PKI pentru a verifica certificatele AA și EA asociate, certificatele de legătură și CRL-urile.
4.5.1.3.Utilizarea cheii private și a certificatelor în cazul EA-urilor și al AA-urilor
(161)EA-urile utilizează cheile lor private pentru a semna EC-urile și pentru a decripta solicitările de înscriere.
(162)Certificatele EA se utilizează pentru a verifica semnătura EC-urilor asociate și pentru criptarea solicitărilor de EC și AT de către EE-uri, astfel cum se definește în [1].
(163)AA-urile utilizează cheile lor private pentru a semna AT-urile și pentru a decripta solicitarea de AT.
(164)Certificatele AA se utilizează de către EE-uri pentru a verifica AT-urile asociate și pentru a cripta solicitările de AT, astfel cum se definește în [1].
4.5.1.4.Utilizarea cheii private și a certificatelor în cazul entității finale
(165)EE-urile utilizează cheia privată care corespunde unei EC valabile pentru a semna o solicitare de înscriere nouă, astfel cum se definește în [1]. Cheia privată nouă se utilizează pentru a construi semnătura internă din solicitare, în scopul de a dovedi posesia cheii private ce corespunde noii chei publice EC.
(166)EE-urile utilizează cheia privată care corespunde unei EC valabile pentru a semna o solicitare de autorizare, astfel cum se definește în [1]. Cheia privată care corespunde noului AT ar trebui să se utilizeze pentru a construi semnătura internă din solicitare, în scopul de a dovedi posesia cheii private ce corespunde noii chei publice AT.
(167)EE utilizează cheia privată care corespunde unui AT adecvat pentru a semna mesajele C-ITS, astfel cum se definește în [5].
4.5.2.Utilizarea cheilor publice și a certificatelor de către părțile de încredere
(168)Părțile de încredere utilizează calea de certificare de încredere și cheile publice asociate în scopurile menționate în certificate și pentru a autentifica identitatea comună de încredere a EC-urilor și a AT-urilor.
(169)Certificatele CA primare, ale EA și ale AA, EC-urile și AT-urile trebuie să nu fie utilizate fără o verificare preliminară de către o parte de încredere.
4.6.Reînnoirea certificatului
Nu este permisă.
4.7.Regenerarea cheii certificatului
4.7.1.Circumstanțele regenerării cheii certificatului
(170)Regenerarea cheii certificatului este prelucrată atunci când un certificat ajunge la sfârșitul ciclului său de viață sau atunci când o cheie privată ajunge la sfârșitul utilizării operaționale, dar relația de încredere cu CA încă există. În toate cazurile se generează și se emite o pereche de chei nouă și certificatul corespunzător.
4.7.2.Cine poate solicita regenerarea cheii
4.7.2.1.CA primară
(171)CA primară nu solicită regenerarea cheii. Procesul de regenerare a cheii este un proces intern al CA primare deoarece certificatul său este autosemnat. CA primară regenerează cheia fie prin certificate de legătură, fie printr-o emitere nouă (a se vedea secțiunea 4.3.1.1).
4.7.2.2.TLM
(172)TLM nu solicită regenerarea cheii. Procesul de regenerare a cheii este un proces intern al TLM deoarece certificatul său este autosemnat.
4.7.2.3.EA și AA
(173)Solicitarea de certificat a CA subordonate trebuie să fie transmisă în timp util pentru a se asigura deținerea unui certificat nou al CA subordonate și a unei perechi operaționale de chei ale CA subordonate înainte de expirarea cheii private în vigoare a CA subordonate. Data transmiterii trebuie să țină cont și de timpul necesar pentru aprobare.
4.7.2.4.Stația C-ITS
Nu se aplică.
4.7.3.Procesul de regenerare a cheii
4.7.3.1.Certificatul TLM
(174)TLM decide regenerarea cheii pe baza cerințelor din secțiunile 6.1 și 7.2. Procesul detaliat este prevăzut în CPS a sa.
(175)TLM execută procesul de regenerare a cheii în timp util pentru a permite distribuirea certificatului TLM și a certificatului de legătură noi către toți participanții, înainte ca certificatul TLM în vigoare să expire.
(176)TLM utilizează certificate de legătură pentru a regenera cheia și pentru a garanta relația de încredere a noului certificat autosemnat. Certificatul TLM și certificatul de legătură nou generate sunt transferate către CPOC.
4.7.3.2.Certificatul CA primare
(177)CA primară decide regenerarea cheii pe baza cerințelor din secțiunile 6.1.5 și 7.2. Procesul detaliat ar trebui să fie definit în CPS a sa.
(178)CA primară execută procesul de regenerare a cheii în timp util (înainte ca certificatul CA primare să expire) pentru a permite introducerea noului certificat în ECTL înainte ca certificatul CA primare să devină valabil (a se vedea secțiunea 5.6.2). Procesul de regenerare a cheii se realizează fie prin certificate de legătură, fie ca o solicitare inițială.
4.7.3.3.Certificatele EA și AA
(179)EA sau AA solicită un certificat nou astfel:
Etapă
|
Indicație
|
Solicitare de regenerare a cheii
|
1
|
Generarea perechii de chei
|
CA-urile subordonate (EA-uri și AA-uri) generează perechi de chei noi în conformitate cu secțiunea 6.1.
|
2
|
Generarea solicitării de certificat și a semnăturii interne
|
CA subordonată generează o solicitare de certificat pe baza cheii publice nou generate având în vedere convenția de alegere a numelor (subject_info) din secțiunea 3, algoritmul semnăturii, permisiunile specifice serviciilor (SSP) și parametrul suplimentar opțional și generează semnătura internă cu cheia privată nouă corespunzătoare. Dacă este necesară o cheie de criptare, CA subordonată trebuie, de asemenea, să dovedească posesia cheii de decriptare private corespunzătoare.
|
3
|
Generarea semnăturii externe
|
Întreaga solicitare trebuie semnată cu cheia privată valabilă actuală pentru a garanta autenticitatea solicitării semnate.
|
4
|
Transmiterea solicitării către CA primară
|
Solicitarea semnată se transmite către CA primară corespunzătoare.
|
5
|
Verificarea solicitării
|
CA primară corespunzătoare verifică integritatea și autenticitatea solicitării. Mai întâi, aceasta verifică semnătura externă. Dacă rezultatul verificării este pozitiv, aceasta verifică semnătura internă. În cazul în care există dovada posesiei cheii de decriptare private, aceasta verifică și această dovadă.
|
6
|
Acceptarea sau respingerea solicitării
|
Dacă toate verificările au un rezultat pozitiv, CA primară acceptă solicitarea; în caz contrar, o respinge.
|
7
|
Generarea și emiterea certificatului
|
CA primară generează un certificat nou și îl distribuie către CA subordonată solicitantă.
|
8
|
Trimiterea răspunsului
|
CA subordonată trimite un mesaj referitor la statut (și anume, dacă s-a primit sau nu certificatul) către CA primară.
|
Tabelul 3: Procesul de regenerare a cheii pentru EA-uri și AA-uri
(180)În timpul regenerării automate a cheilor pentru CA-urile subordonate, CA primară se asigură că solicitantul are într-adevăr în posesie cheia sa privată. Se aplică protocoale adecvate pentru a dovedi posesia cheilor de decriptare private, de exemplu astfel cum se definește în RFC 4210 și 4211. Pentru cheile de semnătură private ar trebui să se utilizeze semnătura internă.
4.7.3.4.Certificatele stației C-ITS
Nu se aplică pentru AT.
4.8.Modificarea certificatelor
Nu este permisă.
4.9.Revocarea și suspendarea certificatelor
A se vedea secțiunea 7.
4.10.Serviciile legate de statutul certificatelor
4.10.1.Caracteristici operaționale
Nu se aplică.
4.10.2.Disponibilitatea serviciului
Nu se aplică.
4.10.3.Caracteristici opționale
Nu se aplică.
4.11.Încetarea abonamentului
Nu se aplică.
4.12.Custodia și recuperarea cheii
4.12.1.Abonatul
4.12.1.1.Ce pereche de chei poate fi dată în custodie
Nu se aplică.
4.12.1.2.Cine poate transmite o cerere de recuperare
Nu se aplică.
4.12.1.3.Procesul de recuperare și responsabilitățile aferente
Nu se aplică.
4.12.1.4.Identificarea și autentificarea
Nu se aplică.
4.12.1.5.Aprobarea sau respingerea cererilor de recuperare
Nu se aplică.
4.12.1.6.Acțiunile KEA și KRA în timpul recuperării perechii de chei
Nu se aplică.
4.12.1.7.Disponibilitatea KEA și KRA
Nu se aplică.
4.12.2.Încapsularea cheii de sesiune și politica și practicile de recuperare
Nu se aplică.
5.Unități, gestionare și controale operaționale
(181)PKI este compusă din CA primară, EA/AA, CPOC și TLM, inclusiv din componentele TIC ale acestora (de exemplu, rețele și servere).
(182)În prezenta secțiune, entitatea responsabilă cu un element al PKI este identificată de elementul însuși. Cu alte cuvinte, propoziția „CA este responsabilă cu efectuarea auditului” este echivalentă cu „entitatea sau personalul care gestionează CA este responsabil(ă) cu efectuarea …”.
(183)Termenul „elementele modelului de încredere al C-ITS” include CA primară, TLM, EA/AA, CPOC și rețeaua securizată.
5.1.Controale fizice
(184)Toate operațiunile modelului de încredere al C-ITS trebuie să se efectueze într-un mediu protejat fizic, care descurajează, previne și detectează utilizarea, accesarea sau divulgarea neautorizată a informațiilor și sistemelor sensibile. Elementele modelului de încredere al C-ITS trebuie să utilizeze controale de securitate fizice în conformitate cu ISO 27001 și ISO 27005.
(185)Entitățile care gestionează elementele modelului de încredere al C-ITS trebuie să descrie controalele de securitate fizice, procedurale și ale personalului în CPS-urile lor. Mai exact, CPS trebuie să cuprindă informații despre amplasament și construcția clădirilor și despre controalele de securitate fizice ale acestora care garantează accesul controlat la toate încăperile utilizate în unitatea entităților modelului de încredere al C-ITS.
5.1.1.Amplasamentul și construcția
5.1.1.1.CA primară, CPOC, TLM
(186)Amplasamentul și construcția unității care găzduiește echipamentele și datele CA primare, CPOC și TLM (HSM, date de activare, copia de rezervă a perechii de chei, computerul, jurnalul, scriptul ceremoniei cheilor, solicitarea de certificat etc.) trebuie să fie conforme cu unitățile utilizate pentru a găzdui informații de mare valoare și sensibile. CA primară trebuie să funcționeze într-o zonă fizică dedicată separată de alte zone fizice ale componentelor PKI.
(187)CA primară, CPOC și TLM trebuie să implementeze politici și proceduri care să asigure menținerea unui nivel înalt de securitate în mediul fizic în care este instalat echipamentul CA primare, astfel încât să se garanteze că:
·acesta este izolat de rețele din afara modelului de încredere;
·acesta este separat într-o serie de (cel puțin două) perimetre fizice din ce în ce mai securizate;
·datele sensibile (HSM, copia de rezervă a perechii de chei, datele de activare etc.) sunt stocate într-un seif dedicat, amplasat într-o zonă fizică dedicată care face obiectul unor controale multiple ale accesului.
(188)Tehnicile de securitate utilizate trebuie să fie proiectate astfel încât să reziste la un număr mare și la combinații de diferite forme de atacuri. Mecanismele utilizate trebuie să includă cel puțin:
·alarme pentru perimetru, televiziune cu circuit închis, pereți consolidați și senzori de mișcare;
·autentificarea prin doi factori (de exemplu, card inteligent și PIN) pentru fiecare persoană și o legitimație pentru intrarea și ieșirea în/din unitățile CA primare și zona fizică securizată.
(189)CA primară, CPOC și TLM utilizează personal autorizat pentru a monitoriza continuu unitatea care găzduiește echipamentele, și anume 7x24x365. Mediul operațional (de exemplu, unitatea fizică) nu trebuie să fie lăsat niciodată fără supraveghere. Personalul din mediul operațional trebuie să nu aibă niciodată acces la zonele securizate ale CA-urilor primare sau ale CA-urilor subordonate, cu excepția cazurilor în care este autorizat în acest scop.
5.1.1.2.EA/AA
(190)Se aplică aceleași dispoziții din secțiunea 5.1.1.1.
5.1.2.Accesul fizic
5.1.2.1.CA primară, CPOC, TLM
(191)Echipamentele și datele (HSM, datele de activare, copia de rezervă a perechii de chei, computerul, jurnalul, scriptul ceremoniei cheilor, solicitarea de certificat etc.) trebuie să fie protejate în permanență împotriva accesului neautorizat. Mecanismele de securitate fizică pentru echipamente trebuie, cel puțin:
·să monitorizeze în permanență, manual sau electronic, intruziunile neautorizate;
·să asigure că nu este permis accesul neautorizat la hardware și la datele de activare;
·să asigure că toate suporturile amovibile și documentele tipărite care conțin informații sensibile sub formă de text simplu sunt stocate într-un container securizat;
·să asigure că orice persoană care intră în zonele securizate și care nu este autorizată permanent în acest scop nu este lăsată fără supraveghere de către angajatul autorizat al unităților CA primare, CPOC și TLM;
·să asigure că se menține și se inspectează periodic un jurnal al accesului;
·să ofere cel puțin două straturi cu un nivel de securitate din ce în ce mai mare, de exemplu la nivelul perimetrului, al clădirii și al încăperii operaționale;
·să impună două controale ale accesului fizic cu rol de încredere pentru HSM criptografic și pentru datele de activare.
(192)Trebuie să se efectueze o verificare de securitate a unității care găzduiește echipamentele dacă acestea urmează să fie lăsate fără supraveghere. Această verificare trebuie să stabilească cel puțin:
·că echipamentele se află într-o stare adecvată pentru modul de operare curent;
·pentru componentele offline, că toate echipamentele sunt oprite;
·că orice containere de securitate (plicuri sigilate, seifuri etc.) sunt securizate corespunzător;
·că sistemele de securitate fizică (de exemplu, încuietorile ușilor, capacele gurilor de aerisire, sistemul electric) funcționează corect;
·că zona este securizată împotriva accesului neautorizat.
(193)Modulele cripotgrafice amovibile trebuie să fie dezactivate înainte de stocare. Atunci când nu sunt utilizate, aceste module și datele de activare utilizate pentru a le accesa sau pentru a le activa trebuie să fie puse într-un seif. Datele de activare sunt fie memorate, fie înregistrate și stocate într-un mod adecvat nivelului de securitate aplicat modulului criptografic. Acestea nu se stochează împreună cu modulul criptografic pentru a evita ca o singură persoană să aibă acces la cheia privată.
(194)Se va încredința expres unei persoane sau unui grup de roluri de încredere sarcina de a efectua aceste verificări. În cazul în care această răspundere îi revine unui grup de persoane, se ține un jurnal care identifică persoana care efectuează fiecare verificare. Dacă în unitate nu sunt prezente persoane în permanență, ultima persoană care pleacă își aplică inițialele pe o fișă de ieșire care indică data și ora și confirmă că toate mecanismele de protecție fizice sunt aplicate și activate.
5.1.2.2.EA/AA
(195)Se aplică aceleași dispoziții din secțiunea 5.1.2.1.
5.1.3.Energie electrică și aer condiționat
(196)Unitățile securizate ale elementelor modelului de încredere al C-ITS (CA primară, CPOC, TLM, EA și AA) trebuie să dispună de acces fiabil la energie electrică pentru a asigura funcționarea fără defecțiuni sau cu defecțiuni minore. Sunt necesare instalații principale și de rezervă în caz de pană de curent din exterior și de închidere corespunzătoare a echipamentelor modelului de încredere C-ITS în caz de lipsă de curent. Unitățile modelului de încredere al C-ITS trebuie să fie echipate cu sisteme de încălzire/ventilație/aer condiționat pentru a menține în intervalul operațional temperatura și umiditatea relativă ale echipamentelor modelului de încredere al C-ITS. CPS a elementului modelului de încredere al C-ITS va descrie în detaliu planul și procesele de punere în aplicare a acestor cerințe.
5.1.4.Expuneri la apă
(197)Unitățile securizate ale elementelor modelului de încredere al C-ITS (CA primară, CPOC, TLM, EA și AA) trebuie să fie protejate în așa încât să se reducă la minimum efectele expunerii la apă. Din acest motiv, se evită conductele de apă și de apă murdară. CPS a elementului modelului de încredere al C-ITS va descrie în detaliu planul și procesele de punere în aplicare a acestor cerințe.
5.1.5.Prevenirea și protecția împotriva incendiilor
(198)Pentru a preveni expunerea dăunătoare la flăcări sau la fum, unitățile securizate ale elementelor modelului de încredere C-ITS (CA primară, CPOC, TLM, EA și AA) trebuie să fie construite și echipate în consecință și trebuie să fie puse în aplicare proceduri care să combată amenințările asociate incendiilor. Suporturile ar trebui protejate de incendii prin stocarea în containere corespunzătoare.
(199)Elementele modelului de încredere al C-ITS trebuie să protejeze suporturile fizice care conțin copii de rezervă ale datelor de sistem critice sau orice alte informații sensibile împotriva pericolelor pentru mediu și împotriva utilizării, accesării sau divulgării neautorizate a acestor suporturi. CPS a elementului modelului de încredere al C-ITS va descrie în detaliu planul și procesele de punere în aplicare a acestor cerințe.
5.1.6.Gestionarea suporturilor
(200)Suporturile utilizate de elementele modelului de încredere al C-ITS (CA primară, CPOC, TLM, EA și AA) sunt manipulate în mod securizat pentru a fi protejate împotriva stricăciunilor, furtului și accesului neautorizat. Se pun în aplicare proceduri de gestionare a suporturilor pentru a le proteja de uzură și de deteriorare în perioada în care trebuie păstrate înregistrările.
(201)Datele sensibile trebuie să fie protejate împotriva accesării ca rezultat al reutilizării obiectelor de stocare (de exemplu, fișiere șterse), care poate face ca datele sensibile să fie accesibile utilizatorilor neautorizați.
(202)Trebuie să se țină un inventar al tuturor activelor informaționale și trebuie să se prevadă cerințe în vederea protejării acestor active care să fie conforme cu analiza riscurilor. CPS a elementului modelului de încredere al C-ITS va descrie în detaliu planul și procesele de punere în aplicare a acestor cerințe.
5.1.7.Eliminarea deșeurilor
(203)Elementele modelului de încredere al C-ITS (CA primară, CPOC, TLM, EA și AA) trebuie să pună în aplicare proceduri de eliminare securizată și ireversibilă a deșeurilor (hârtii, suporturi și orice alte deșeuri), pentru a preveni utilizarea, accesarea sau divulgarea neautorizată a deșeurilor care conțin informații confidențiale/private. Toate suporturile utilizate la stocarea informațiilor sensibile, cum ar fi cheile, datele de activare sau fișierele, trebuie să fie distruse înainte de a se dispune eliminarea lor. CPS a elementului modelului de încredere al C-ITS va descrie în detaliu planul și procesele de punere în aplicare a acestor cerințe.
5.1.8.Copia de rezervă (backup-ul) în afara unității
5.1.8.1.CA primară, CPOC și TLM
(204)După implementarea CA primare, CPOC și TLM și după fiecare generare de perechi de chei noi, se fac backup-uri offline complete ale componentelor CA primare, CPOC și TLM, suficiente pentru a asigura recuperarea în cazul defectării sistemelor. Se efectuează regulat copii de backup ale informațiilor esențiale privind activitatea (perechi de chei și CRL) și ale software-ului. Se furnizează dispozitive de backup adecvate pentru a se asigura că toate informațiile esențiale privind activitatea și software-ul pot fi recuperate în urma unui dezastru sau a defectării suporturilor. Măsurile de backup pentru sistemele individuale sunt testate regulat pentru a se asigura că îndeplinesc cerințele planului de continuitate a activității. Cel puțin o copie de rezervă completă este stocată într-un loc din afara unității (recuperarea în caz de dezastru). Copia de backup este stocată într-un loc care dispune de controale fizice și procedurale echivalente cu cele ale sistemului PKI operațional.
(205)Datele din copia de rezervă fac obiectul acelorași cerințe privind accesul ca datele operaționale. Datele din copia de rezervă trebuie să fie criptate și stocate în afara unității. În cazul pierderii complete a datelor, informațiile necesare pentru repunerea în funcțiune a CA primare, CPOC și TLM trebuie să fie recuperate complet din datele din copia de rezervă.
(206)Copiile de rezervă ale cheilor private ale CA primare, CPOC și TLM nu trebuie făcute utilizând mecanisme de backup standard, ci utilizând funcția de backup a modulului criptografic.
5.1.8.2.EA/AA
(207)Prezentei secțiuni i se aplică procesele descrise în secțiunea 5.1.8.1.
5.2.Controale procedurale
Prezenta secțiune descrie cerințele referitoare la rolurile, atribuțiile și identificarea personalului.
5.2.1.Roluri de încredere
(208)Angajații, contractanții și consultanții cărora li se atribuie roluri de încredere sunt considerați „persoane de încredere”. Persoanele care doresc să devină persoane de încredere pentru a obține un post de încredere trebuie să îndeplinească cerințele de selecție din prezenta politică de certificare.
(209)Persoanele de încredere pot să acceseze sau să controleze operațiunile de autentificare sau criptografice care pot afecta semnificativ:
·validarea informațiilor din cererile de certificate;
·acceptarea, respingerea sau alte prelucrări ale cererilor de certificate, cererilor de revocare sau cererilor de reînnoire;
·emiterea sau revocarea certificatelor, inclusiv personalul care are acces la porțiuni restricționate ale registrului sau tratarea informațiilor sau a solicitărilor abonaților.
(210)Rolurile de încredere includ, printre altele:
·serviciul oferit clienților;
·administrarea sistemului;
·activitățile inginerești desemnate;
·responsabilii cu gestionarea fiabilității infrastructurii.
(211)CA trebuie să descrie în mod clar toate rolurile de încredere în CPS a sa.
5.2.2.Numărul de persoane necesar pentru fiecare sarcină
(212)Elementele modelului de încredere al C-ITS trebuie să stabilească, să mențină și să aplice proceduri de control riguroase pentru a asigura separarea atribuțiilor pe baza rolurilor de încredere și pentru a garanta că sunt necesare mai multe persoane de încredere pentru executarea sarcinilor sensibile. Elementele modelului de încredere al C-ITS (TLM, CPOC, CA primară, EA și AA) ar trebui să respecte [4] și cerințele de la punctele următoare.
(213)Se aplică o politică și proceduri de control pentru a asigura separarea atribuțiilor pe baza responsabilităților postului. Cele mai sensibile sarcini, cum ar fi accesarea și gestionarea hardware-ului criptografic al CA (HSM) și a cheilor asociate, trebuie să necesite autorizarea mai multor persoane de încredere.
(214)Aceste proceduri de control intern trebuie să fie concepute astfel încât să se asigure că sunt necesare cel puțin două persoane de încredere pentru accesul fizic sau logic la dispozitiv. Restricțiile impuse accesului la hardware-ul criptografic al CA trebuie aplicate cu strictețe de mai multe persoane de încredere de-a lungul ciclului de viață al acestuia, de la recepția și inspecția la primire la distrugerea finală logică și/sau fizică. După ce un modul este activat cu chei operaționale, se invocă controale ale accesului suplimentare pentru a menține controlul divizat al accesului, atât fizic, cât și logic, la dispozitiv.
5.2.3.Identificarea și autentificarea pentru fiecare rol
(215)Toate persoanele cărora li s-a atribuit un rol, astfel cum se descrie în prezenta CP, sunt identificate și autentificate pentru a garanta că rolul le permite să își îndeplinească atribuțiile asociate PKI.
(216)Elementele modelului de încredere al C-ITS verifică și confirmă identitatea și autorizarea tuturor membrilor personalului care doresc să devină persoane de încredere înainte ca:
·acestora să li se elibereze dispozitivele de acces și să li se acorde accesul la instalațiile necesare;
·acestora să li se acorde acreditările electronice pentru a accesa și pentru a executa funcții specifice operate asupra sistemelor CA.
(217)CPS descrie mecanismele utilizate pentru a identifica și autentifica persoanele.
5.2.4.Roluri care necesită separarea atribuțiilor
(218)Rolurile care necesită separarea atribuțiilor includ (printre altele):
·acceptarea, respingerea și revocarea cererilor și alte prelucrări ale cererilor de certificate CA;
·generarea, emiterea și distrugerea unui certificat CA.
(219)Separarea atribuțiilor poate fi efectuată utilizând echipamentele, procedurile PKI sau ambele. Nu se atribuie mai multe identități unei singure persoane, cu excepția cazului în care CA primară aprobă acest lucru.
(220)Partea CA primare și CA responsabile cu gestionarea generării și a revocării certificatelor trebuie să fie independentă de alte organizații în ceea ce privește deciziile referitoare la stabilirea, furnizarea, menținerea și suspendarea serviciilor, în conformitate cu politicile de certificare aplicabile. Mai exact, directorul acesteia, personalul de conducere și personalul cu roluri de încredere trebuie să nu fie supuși niciunei presiuni de natură comercială, financiară sau de alt fel, care ar putea influența negativ încrederea în serviciile pe care le prestează.
(221)EA și AA care deservesc stațiile C-ITS mobile trebuie să fie entități operaționale separate, cu o infrastructură IT și echipe de gestionare în domeniul IT separate. În conformitate cu RGPD, EA și AA nu trebuie să facă schimb de niciun fel de date cu caracter personal, cu excepția autorizării solicitărilor de AT. Acestea transferă datele referitoare la aprobarea solicitărilor de AT doar prin utilizarea protocolului de validare a autorizării din [1] printr-o interfață dedicată securizată. Se pot utiliza și alte protocoale, cu condiția ca [1] să fie pus în aplicare.
(222)Fișierele jurnal stocate de EA și AA pot fi utilizate exclusiv pentru revocarea EC-urilor care nu se comportă corect, pe baza AT-urilor din mesajele CAM/DEMN rău intenționate interceptate. După ce un mesaj CAM/DENM a fost identificat ca fiind rău intenționat, AA va căuta cheia de verificare a AT în jurnalele sale de emitere și va transmite EA o solicitare de revocare conținând semnătura criptată sub cheia privată EC care a fost utilizată în timpul emiterii AT. Toate fișierele jurnal trebuie să fie protejate corespunzător împotriva accesului părților neautorizate și nu pot fi transmise altor entități sau autorități.
Observație: La data redactării prezentei versiuni a CP, nu este definit conceptul de funcție care nu se comportă corect. Se are în vedere o eventuală definire a conceptului de funcție care nu se comportă corect în viitoarele revizuiri ale politicii.
5.3.Controalele personalului
5.3.1.Cerințe privind calificările, experiența și autorizarea
(223)Elementele modelului de încredere al C-ITS utilizează angajați suficienți, cu cunoștințele de specialitate, experiența și calificările necesare pentru atribuțiile de serviciu și pentru serviciile oferite. Personalul PKI îndeplinește aceste cerințe prin pregătire oficială și acreditări, experiență efectivă sau o combinație a acestora. Rolurile și responsabilitățile de încredere, astfel cum sunt precizate în CPS, sunt documentate în fișele posturilor și sunt identificate în mod clar. Subcontractanții personalului PKI au fișe de post definite pentru a asigura separarea atribuțiilor și a privilegiilor, iar caracterul sensibil al postului este stabilit pe baza atribuțiilor și nivelurilor de acces, a evaluării antecedentelor și a pregătirii și sensibilizării angajaților.
5.3.2.Procedurile de verificare a antecedentelor
(224)Elementele modelului de încredere al C-ITS trebuie să efectueze verificări ale antecedentelor membrilor personalului care doresc să devină persoane de încredere. Verificările antecedentelor se repetă cel puțin din cinci în cinci ani în cazul personalului care deține posturi de încredere.
(225)Printre factorii evidențiați de verificarea antecedentelor care pot fi considerați temeiuri pentru a respinge candidații la posturi de încredere sau pentru a lua măsuri împotriva unei persoane de încredere existente se numără (printre altele):
·declarațiile false ale candidatului sau ale persoanei de încredere;
·referințele profesionale foarte nefavorabile sau care nu sunt de încredere;
·anumite condamnări penale;
·semnele unei lipse de responsabilitate financiară.
(226)Rapoartele care conțin astfel de informații sunt evaluate de personalul departamentului de resurse umane, care ia măsuri rezonabile pe baza tipului, amplorii și frecvenței comportamentelor depistate prin verificarea antecedentelor. Astfel de acțiuni pot include măsuri care merg inclusiv până la anularea ofertelor de angajare făcute candidaților la posturi de încredere sau desfacerea contractului de muncă al persoanelor de încredere existente. Utilizarea informațiilor obținute din verificarea antecedentelor ca temei pentru astfel de măsuri se supune legislației aplicabile.
(227)Investigarea antecedentelor persoanelor care doresc să devină persoane de încredere include, printre altele:
·confirmarea locului de muncă anterior;
·o verificare a referințelor profesionale corespunzătoare posturilor ocupate într-o perioadă de cel puțin cinci ani;
·confirmarea diplomei corespunzătoare celui mai înalt sau relevant grad de învățământ absolvit;
·căutarea în cazierele judiciare.
5.3.3.Cerințe de pregătire
(228)Elementele modelului de încredere al C-ITS oferă personalului lor pregătirea necesară pentru a-și îndeplini responsabilitățile aferente operațiunilor CA în mod competent și corespunzător.
(229)Programele de pregătire sunt revizuite periodic, iar pregătirea acestora abordează aspecte relevante pentru funcțiile îndeplinite de personalul lor.
(230)Programele de pregătire abordează aspecte relevante pentru mediul specific al persoanei pregătite, inclusiv:
·principiile și mecanismele de securitate ale elementelor modelului de încredere al C-ITS;
·versiunile hardware și software utilizate;
·toate atribuțiile pe care persoana trebuie să le îndeplinească și procesele și secvențele de raportare interne și externe;
·procesele operaționale și fluxurile de lucru ale PKI;
·raportarea și gestionarea incidentelor și a situațiilor de compromitere;
·proceduri de recuperare și de continuitate a activității în caz de dezastru;
·cunoștințe suficiente în domeniul IT.
5.3.4.Frecvența și cerințele recalificării
(231)Persoanele cărora li se atribuie roluri de încredere trebuie să își reîmprospăteze cunoștințele obținute prin pregătire în mod continuu, cu ajutorul unui mediu de pregătire. Pregătirea trebuie să fie repetată ori de câte ori se consideră necesar, dar cel puțin din doi ani în doi ani.
(232)Elementele modelului de încredere al C-ITS trebuie să ofere membrilor personalului lor pregătire de reîmprospătare a cunoștințelor și actualizări, în măsura și cu frecvența necesară pentru a se asigura că aceștia își mențin nivelul de competență cerut pentru a-și îndeplini atribuțiile de serviciu în mod competent și corespunzător.
(233)Persoanele cu roluri de încredere trebuie să cunoască modificările intervenite în operațiunile PKI, după caz. Orice modificare semnificativă a operațiunilor trebuie să fie însoțită de un plan de pregătire (sensibilizare), iar executarea planului respectiv trebuie să fie documentată.
5.3.5.Frecvența și secvența rotației posturilor
(234)Nu există nicio dispoziție în măsura în care sunt asigurate competențele tehnice, experiența și drepturile de acces. Administratorii elementelor modelului de încredere al C-ITS se asigură că modificările intervenite la nivelul personalului nu afectează securitatea sistemului.
5.3.6.Sancțiuni pentru acțiunile neautorizate
(235)Fiecare dintre elementele modelului de încredere al C-ITS trebuie să elaboreze un proces disciplinar oficial pentru a asigura că acțiunile neautorizate sunt sancționate corespunzător. În cazuri grave, trebuie retrase atribuirile de roluri și privilegiile corespunzătoare.
5.3.7.Cerințe privind contractanții independenți
(236)Elementele modelului de încredere al C-ITS pot permite contractanților sau consultanților independenți să devină persoane de încredere numai în măsura necesară pentru a face posibile relațiile de externalizare clar definite și cu condiția ca entitatea să aibă încredere în contractanții sau în consultanții respectivi ca și cum aceștia ar fi angajații săi și ca aceștia să îndeplinească cerințele aplicabile angajaților.
(237)În caz contrar, contractanții și consultanții independenți nu pot avea acces la instalațiile securizate ale PKI aferente C-ITS decât dacă sunt escortați și supravegheați direct de persoane de încredere.
5.3.8.Documentația furnizată personalului
(238)Elementele modelului de încredere al C-ITS trebuie să furnizeze personalului lor pregătirea necesară și accesul la documentația de care au nevoie pentru a-și îndeplini atribuțiile de serviciu în mod competent și corespunzător.
5.4.Proceduri de înregistrare în jurnal a auditurilor
(239)Prezenta secțiune prevede cerințele referitoare la tipurile de evenimente care trebuie înregistrate și la gestionarea jurnalelor de audit.
5.4.1.Tipuri de evenimente care trebuie înregistrate și raportate de fiecare CA
(240)Un reprezentant al CA analizează regulat jurnalele, evenimentele și procedurile CA.
(241)Elementele modelului de încredere al C-ITS înregistrează următoarele tipuri de evenimente de audit (dacă este cazul):
·accesul fizic la instalații – accesul persoanelor fizice la instalații va fi înregistrat prin stocarea solicitărilor de acces utilizând carduri inteligente. Se creează un eveniment de fiecare dată când se creează o înregistrare;
·gestionarea rolurilor de încredere – orice modificare a definiției și a nivelului de acces ale diferitelor roluri va fi înregistrată, inclusiv modificarea atributelor rolurilor. Se creează un eveniment de fiecare dată când se creează o înregistrare;
·accesul logic – se va genera un eveniment atunci când o entitate (de exemplu, un program) are acces la o zonă sensibilă (de exemplu, rețele și servere);
·gestionarea copiilor de rezervă – se creează un eveniment de fiecare dată când este finalizată crearea, cu sau fără succes, a unei copii de rezervă;
·gestionarea jurnalelor – jurnalele vor fi stocate. Se creează un eveniment atunci când dimensiunea jurnalului depășește o anumită valoare;
·datele provenite din procesul de autentificare pentru abonați și elementele modelului de încredere al C-ITS – se vor genera evenimente pentru fiecare solicitare de autentificare din partea abonaților și a elementelor modelului de încredere al C-ITS;
·acceptarea și respingerea solicitărilor de certificate, inclusiv crearea și reînnoirea certificatelor – se va genera periodic un eveniment, cu o listă a solicitărilor de certificate acceptate și respinse în cele șapte zile precedente;
·înregistrarea producătorului – se va crea un eveniment atunci când se înregistrează un producător;
·înregistrarea stației C-ITS – se va crea un eveniment atunci când se înregistrează o stație C-ITS;
·gestionarea HSM – se va crea un eveniment atunci când se înregistrează o încălcare a securității HSM;
·gestionarea IT și a rețelei, deoarece aparțin sistemelor PKI – se va crea un eveniment atunci când un server PKI este oprit sau repornit;
·gestionarea securității (încercări cu și fără succes de accesare a sistemului PKI, acțiuni efectuate la nivelul PKI și al sistemului de securitate, modificări ale profilului de securitate, căderi ale sistemului, defecțiuni hardware și alte anomalii, activități ale firewall-ului și ale routerului, precum și intrările și ieșirile din instalațiile PKI);
·datele referitoare la eveniment vor fi stocate timp de cel puțin cinci ani, cu excepția cazurilor în care se aplică norme naționale suplimentare.
(242)În conformitate cu RGPD, jurnalele de audit nu permit accesul la datele confidențiale privind vehiculele private ale stațiilor C-ITS.
(243)Atunci când este posibil, jurnalele de audit de securitate sunt colectate automat. Dacă acest lucru nu este posibil, se utilizează un jurnal, un formular pe suport de hârtie sau alt mecanism fizic. Toate jurnalele de audit de securitate, atât în format electronic, cât și în alte formate, trebuie să fie păstrate și puse la dispoziție în timpul auditurilor de conformitate.
(244)Fiecare eveniment legat de ciclul de viață al unui certificat este înregistrat în jurnal astfel încât să poată fi atribuit persoanei care l-a realizat. Toate datele referitoare la identitatea personală sunt criptate și protejate împotriva accesului neautorizat.
(245)Fiecare înregistrare de audit conține cel puțin următoarele informații (înregistrate automat sau manual pentru fiecare eveniment care poate face obiectul auditului):
·tipul evenimentului (potrivit listei de mai sus);
·data și ora demne de încredere la care a avut loc evenimentul;
·rezultatul evenimentului – succes sau eșec, când este cazul;
·identitatea entității și/sau a operatorului care a cauzat evenimentul, dacă este cazul;
·identitatea entității căreia i se adresează evenimentul.
5.4.2.Frecvența prelucrării jurnalelor
(246)Jurnalele de audit sunt analizate ca răspuns la alertele bazate pe neregulile și incidentele din sistemele CA și, în plus, periodic, în fiecare an.
(247)Prelucrarea jurnalelor de audit constă în analiza jurnalelor de audit și în documentarea motivelor tuturor evenimentelor semnificative în cadrul unui rezumat al jurnalului de audit. Analizele jurnalelor de audit includ verificarea faptului că jurnalul nu a fost modificat fraudulos, inspectarea tuturor înregistrărilor din jurnal și investigarea tuturor alertelor sau a neregulilor din jurnale. Acțiunile întreprinse pe baza analizelor jurnalelor de audit trebuie să fie documentate.
(248)Jurnalul de audit este arhivat cel puțin săptămânal. Un administrator îl arhivează manual dacă spațiul liber pe disc pentru jurnalul de audit este mai mic decât volumul anticipat al datelor jurnalului de audit produs în acea săptămână.
5.4.3.Perioada de păstrare a jurnalelor de audit
(249)Înregistrările din jurnale referitoare la ciclurile de viață ale certificatelor se păstrează cel puțin cinci ani de la expirarea certificatului corespunzător.
5.4.4.Protejarea jurnalelor de audit
(250)Integritatea și confidențialitatea jurnalelor de audit sunt garantate printr-un mecanism de control al accesului bazat pe roluri. Jurnalele de audit intern pot fi accesate numai de administratori; jurnalele de audit legate de ciclul de viață al certificatelor pot fi accesate și de utilizatorii care dețin autorizarea corespunzătoare, prin intermediul unei pagini web ce necesită autentificarea utilizatorului. Accesul trebuie să fie acordat cu o autentificare pentru utilizatori multipli (cel puțin doi utilizatori) și cu cel puțin două niveluri. Trebuie să se asigure din punct de vedere tehnic că utilizatorii nu își pot accesa propriile fișiere de jurnal.
(251)Fiecare înregistrare din jurnal este semnată utilizând cheile furnizate de HSM.
(252)Jurnalele de evenimente care conțin informații ce pot conduce la identificarea personală, de exemplu a unui vehicul privat, sunt criptate astfel încât să poată fi citite numai de persoanele autorizate.
(253)Evenimentele sunt înregistrate în jurnal astfel încât să nu poată fi șterse sau distruse cu ușurință (cu excepția transferului pe suporturi pe termen lung) pe perioada în care trebuie păstrate jurnalele.
(254)Jurnalele de evenimente sunt protejate astfel încât să rămână lizibile pe durata perioadei lor de stocare.
5.4.5.Proceduri de creare de copii de rezervă ale jurnalelor de audit
(255)Copiile de rezervă ale jurnalelor și ale rezumatelor de audit se realizează prin mecanisme de backup ale întreprinderii, sub controlul rolurilor de încredere autorizate, separate de generarea sursei componentelor lor. Copiile de rezervă ale jurnalelor de audit sunt protejate cu același nivel de încredere care se aplică și jurnalelor originale.
5.4.6.Sistemul de colectare a probelor de audit (intern sau extern)
(256)Echipamentele elementelor modelului de încredere al C-ITS activează procesele de audit la pornirea sistemului și le dezactivează doar la oprirea sistemului. Dacă nu sunt disponibile procesele de audit, elementul modelului de încredere al C-ITS își suspendă funcționarea.
(257)La sfârșitul fiecărei perioade de operare și la momentul regenerării cheilor certificatelor, statutul colectiv al echipamentelor ar trebui raportat directorului de operațiuni și organismului de coordonare a operațiunilor al respectivului element al PKI.
5.4.7.Notificarea subiectului care cauzează evenimentul
(258)Atunci când sistemul de colectare a probelor de audit înregistrează în jurnal un eveniment, acesta garantează că evenimentul este corelat cu un rol de încredere.
5.4.8.Evaluarea vulnerabilităților
(259)Rolul responsabil cu efectuarea auditului și rolurile responsabile cu realizarea operării sistemului PKI în cadrul elementelor modelului de încredere al C-ITS explică toate evenimentele semnificative într-un rezumat al jurnalului de audit. Aceste analize cuprind verificarea faptului că jurnalul nu a fost modificat fraudulos și că nu există discontinuitate sau alte pierderi de date de audit și, ulterior, inspectarea tuturor înregistrărilor din jurnal, realizându-se o investigație mai aprofundată a tuturor alertelor și neregulilor din jurnale. Acțiunile întreprinse în urma acestor analize trebuie documentate.
(260)Elementele modelului de încredere al C-ITS trebuie:
·să pună în aplicare controale organizaționale și/sau tehnice de detectare și de prevenire, sub controlul elementelor modelului de încredere al C-ITS, pentru a proteja sistemele PKI împotriva virușilor și a software-ului rău intenționat;
·să documenteze și să urmeze un proces de corectare a vulnerabilităților care să vizeze identificarea și analizarea vulnerabilităților, răspunsul la acestea și remedierea acestora;
·să se supună unei scanări a vulnerabilităților sau să realizeze o astfel de scanare:
·după orice modificare a sistemului sau a rețelei caracterizată de elementele modelului de încredere al C-ITS ca fiind semnificativă pentru componentele PKI și
·cel puțin o dată pe lună, pentru adresele IP publice și private identificate de CA, CPOC ca sisteme ale PKI;
·să se supună unui test de penetrare a sistemelor PKI cel puțin anual și după actualizările sau modificările infrastructurilor sau ale aplicațiilor, caracterizate de elementele modelului de încredere al C-ITS ca fiind semnificative pentru componenta PKI a CA;
·pentru sistemele online, să înregistreze dovezi că fiecare scanare a vulnerabilităților și fiecare test de penetrare au fost efectuate de o persoană sau de o entitate (sau de un grup colectiv ale acestora) pe baza abilităților, instrumentelor, competenței, deontologiei și independenței necesare pentru a asigura realizarea unui test al vulnerabilităților sau de penetrare fiabil;
·să urmărească și să remedieze vulnerabilitățile în conformitate cu politicile de securitate cibernetică și cu metodologia de reducere a riscurilor ale întreprinderii.
5.5.Arhivarea înregistrărilor
5.5.1.Tipuri de înregistrări arhivate
(261)Elementele modelului de încredere al C-ITS arhivează înregistrări suficient de detaliate pentru a se stabili valabilitatea unei semnături și a funcționării corespunzătoare a PKI. Se arhivează cel puțin următoarele înregistrări de evenimente PKI (dacă este cazul):
·jurnalul de acces fizic la instalații al elementelor modelului de încredere al C-ITS (minimum un an);
·jurnalul de gestionare a rolurilor de încredere pentru elementele modelului de încredere al C-ITS (minimum 10 ani);
·jurnalul de acces IT pentru elementele modelului de încredere al C-ITS (minimum cinci ani);
·jurnalul creării, utilizării și distrugerii cheilor CA (minimum cinci ani) (nu se aplică pentru TLM și CPOC);
·jurnalul creării, utilizării și distrugerii certificatelor (minimum doi ani);
·jurnalul solicitărilor CPA (minimum doi ani);
·jurnalul de gestionare a datelor de activare pentru elementele modelului de încredere al C-ITS (minimum cinci ani);
·jurnalul IT și al rețelei pentru elementele modelului de încredere al C-ITS (minimum cinci ani);
·documentația PKI pentru elementele modelului de încredere al C-ITS (minimum cinci ani);
·raportul incidentelor de securitate și de audit pentru elementele modelului de încredere al C-ITS (minimum 10 ani);
·echipamentele, software-ul și configurația sistemelor (minimum cinci ani).
(262)Elementele modelului de încredere al C-ITS păstrează următoarea documentație legată de solicitările de certificate și verificarea acestora și toate certificatele TLM, ale CA-urilor primare și ale CA-urilor și CRL a acestora timp de cel puțin șapte ani de la data la care expiră valabilitatea oricărui certificat bazat pe respectiva documentație:
·documentația auditului PKI păstrată de elementele modelului de securitate C-ITS;
·documentele CPS păstrate de elementele modelului de securitate C-ITS;
·contractul dintre CPA și alte entități păstrat de elementele modelului de securitate C-ITS;
·certificatele (sau alte informații referitoare la revocare) păstrate de CA și de TLM;
·înregistrările solicitărilor de certificate din sistemul CA primare (nu se aplică în cazul TLM);
·alte date sau aplicații suficiente pentru a verifica conținutul arhivei;
·toate lucrările care sunt legate de elementele modelului de securitate C-ITS și de auditorii conformității sau care provin de la aceștia.
(263)Entitatea CA păstrează toată documentația legată de solicitările de certificate și de verificarea acestora și toate certificatele și revocările aferente timp de cel puțin șapte ani de la data la care expiră valabilitatea oricărui certificat bazat pe respectiva documentație.
5.5.2.Perioada de păstrare a arhivei
(264)Fără a aduce atingere reglementărilor care impun o perioadă de arhivare mai lungă, elementele modelului de securitate C-ITS trebuie să păstreze înregistrările timp de cel puțin cinci ani de la data la care a expirat certificatul corespunzător.
5.5.3.Protejarea arhivei
(265)Elementele modelului de securitate C-ITS trebuie să stocheze arhiva înregistrărilor într-o unitate de stocare sigură și securizată, separată de echipamentele CA, care dispune de controale de securitate fizice și procedurale echivalente celor ale PKI sau superioare acestora.
(266)Arhiva trebuie să fie protejată împotriva vizualizării, modificării sau ștergerii neautorizate sau a altor modificări frauduloase prin stocarea într-un sistem de încredere.
(267)Suporturile pe care se află datele arhivei și aplicațiile necesare pentru prelucrarea acestora trebuie să fie întreținute pentru a se asigura că pot fi accesate pe perioada prevăzută în prezenta CP.
5.5.4.Arhivarea și stocarea sistemului
(268)Elementele modelului de încredere al C-ITS trebuie să realizeze zilnic un backup treptat al arhivelor sistemului care conțin astfel de informații și să efectueze săptămânal copii de rezervă complete. Copiile înregistrărilor pe suport de hârtie trebuie păstrate într-un loc securizat din afara unității.
5.5.5.Cerințe privind marcarea temporală al înregistrărilor
(269)Elementele modelului de încredere al C-ITS care gestionează o bază de date de revocări trebuie să se asigure că înregistrările conțin informații despre data și ora la care sunt create înregistrările de revocare. Integritatea acestor informații va fi asigurată prin soluții bazate pe criptografie.
5.5.6.Sistemul de colectare a arhivelor (intern sau extern)
(270)Sistemul de colectare a arhivelor este intern.
5.5.7.Proceduri de obținere și de verificare a informațiilor din arhivă
(271)Toate elementele modelului de încredere al C-ITS permit doar persoanelor de încredere autorizate să acceseze arhiva. CA-urile primare și CA-urile descriu în CPS procedurile de creare, verificare, împachetare, transmitere și stocare a informațiilor din arhivă.
(272)Echipamentele CA primare și CA trebuie să verifice integritatea informațiilor înainte ca acestea să fie restaurate.
5.6.Schimbarea cheilor pentru elementele modelului de încredere al C-ITS
(273)Următoarele elemente ale modelului de încredere al C-ITS au cerințe specifice pentru schimbarea cheilor lor: certificatele TLM, ale CA primare și ale EA/AA.
5.6.1.TLM
(274)TLM își șterge cheia privată la expirarea certificatului corespunzător. Acesta generează o pereche de chei nouă și certificatul TLM corespunzător înainte de dezactivarea cheii private valabile actuale. Acesta se asigură că certificatul (de legătură) nou este introdus în ECTL la timp pentru a putea fi distribuit tuturor stațiilor C-ITS înainte să devină valabil. Certificatul de legătură și certificatul autosemnat nou sunt transferate către CPOC.
5.6.2.CA primară
(275)CA primară dezactivează și șterge cheia privată în vigoare (inclusiv cheile de rezervă) pentru a nu emite certificate EA/AA cu o valabilitate care depășește valabilitatea certificatului CA primare.
(276)CA primară generează o pereche de chei nouă, precum și certificatul CA primare și certificatul de legătură corespunzătoare înainte de dezactivarea cheii private în vigoare (inclusiv a cheilor de rezervă) și le trimite către TLM în vederea introducerii în ECTL. Perioada de valabilitate a noului certificat al CA primare începe la data de dezactivare planificată a cheii private în vigoare. CA primară se asigură că certificatul nou este introdus în ECTL la timp pentru a putea fi distribuit tuturor stațiilor C-ITS înainte să devină valabil.
(277)CA primară activează cheia privată nouă atunci când certificatul CA primare corespunzător devine valabil.
5.6.3.Certificatul EA/AA
(278)EA/AA dezactivează cheia privată în vigoare pentru a nu emite EC-uri/AT-uri cu o valabilitate care depășește valabilitatea certificatului EA/AA.
(279)EA/AA generează o pereche de chei nouă și solicită un certificat EA/AA corespunzător înainte de dezactivarea cheii private în vigoare. Perioada de valabilitate a noului certificat EA/AA începe la data de dezactivare planificată a cheii private în vigoare. EA/AA se asigură că certificatul nou poate fi publicat la timp pentru a putea fi distribuit tuturor stațiilor C-ITS înainte să devină valabil.
(280)EA/AA activează cheia privată nouă atunci când certificatul EA/AA corespunzător devine valabil.
5.6.4.Auditorul
Nu există dispoziții.
5.7.Recuperarea în caz de compromitere și de dezastru
5.7.1.Tratarea situațiilor de compromitere și a incidentelor
(281)Elementele modelului de încredere al C-ITS trebuie să își monitorizeze permanent echipamentele pentru a detecta tentativele potențiale de piratare sau alte forme de compromitere. În astfel de cazuri, ele trebuie să investigheze pentru a determina natura și amploarea prejudiciului.
(282)Dacă detectează o tentativă potențială de piratare sau o altă formă de compromitere, personalul responsabil cu gestionarea CA primare sau TLM trebuie să facă investigații pentru a determina natura și amploarea prejudiciului. Dacă cheia privată este compromisă, certificatul CA primare trebuie revocat. Experții în securitate IT ai CPA evaluează amploarea prejudiciului potențial pentru a stabili dacă PKI trebuie să fie reconstruită, dacă trebuie să fie revocate doar unele certificate și/sau dacă PKI a fost compromisă. În plus, CPA stabilește care sunt serviciile care urmează să fie menținute (informații referitoare la statutul revocării și al certificatelor) și în ce mod, în conformitate cu planul CPA de continuitate a activității.
(283)Incidentele, situațiile de compromitere și continuitatea activității sunt cuprinse în CPS, care se poate baza și pe alte resurse și planuri ale întreprinderii în vederea punerii sale în aplicare.
(284)Dacă detectează o tentativă potențială de piratare sau o altă formă de compromitere, personalul responsabil cu gestionarea EA/AA/CPOC trebuie să facă investigații pentru a determina natura și amploarea prejudiciului. Personalul responsabil cu gestionarea entității CA sau CPOC evaluează amploarea prejudiciului potențial pentru a stabili dacă componenta PKI trebuie să fie reconstruită, dacă trebuie să fie revocate doar unele certificate și/sau dacă componenta PKI a fost compromisă. În plus, entitatea CA subordonate stabilește care sunt serviciile care urmează să fie menținute și în ce mod, în conformitate cu planul de continuitate a activității al entității CA subordonate. În cazul în care o componentă a PKI este compromisă, entitatea CA alertează propria CA primară și TLM prin intermediul CPOC.
(285)Incidentele, situațiile de compromitere și continuitatea activității sunt cuprinse în CPS a CA primare sau a TLM sau în alte documente relevante în cazul CPOC, care se pot baza și pe alte resurse și planuri ale întreprinderii în vederea punerii lor în aplicare.
(286)CA primară și CA trebuie să alerteze, comunicând informații precise despre consecințele incidentului, fiecare reprezentant al statelor membre și fiecare CA primară cu care au încheiat un acord în contextul C-ITS, pentru a le permite acestora să își activeze propriul plan de gestionare a incidentelor.
5.7.2.Coruperea resurselor informatice, a software-ului și/sau a datelor
(287)Dacă se descoperă un dezastru care împiedică funcționarea corespunzătoare a unui element al modelului de încredere al C-ITS, acel element își suspendă funcționarea și investighează dacă cheia privată a fost compromisă (cu excepția CPOC). Hardware-ul defect trebuie înlocuit cât mai rapid posibil și trebuie să se aplice procedurile descrise în secțiunile 5.7.3 și 5.7.4.
(288)Coruperea resurselor informatice, a software-ului și/sau a datelor se raportează către CA primară în termen de 24 de ore pentru cele mai înalte niveluri de risc. Toate celelalte evenimente trebuie incluse în raportul periodic al CA primare, al EA-urilor și al AA-urilor.
5.7.3.Proceduri în caz de compromitere a cheii private a entității
(289)În cazul în care cheia privată a unei CA primare este compromisă, pierdută, distrusă sau se suspectează că a fost compromisă, CA primară trebuie:
·să își suspende funcționarea;
·să inițieze planul de recuperare și de migrare în caz de dezastru;
·să își revoce certificatul de CA primară;
·să investigheze „problema cheii” care a generat compromiterea și să notifice CPA, care va revoca certificatul CA primare prin intermediul TLM (a se vedea secțiunea 7);
·să alerteze toți abonații cu care a încheiat un acord.
(290)În cazul în care cheia unei EA/AA este compromisă, pierdută, distrusă sau se suspectează că a fost compromisă, EA/AA trebuie:
·să își suspende funcționarea;
·să își revoce propriul certificat;
·să investigheze „problema cheii” și să notifice CA primară;
·să alerteze abonații cu care există un acord.
(291)Dacă cheia EC sau AT a unei stații C-ITS este compromisă, pierdută, distrusă sau se suspectează că a fost compromisă, EA/AA la care este abonată stația C-ITS trebuie:
·să revoce EC a ITS afectat;
·să investigheze „problema cheii” și să notifice CA primară;
·să alerteze abonații cu care a încheiat un acord.
(292)Atunci când oricare dintre algoritmii sau parametrii asociați utilizați de CA primară și/sau de CA sau de stațiile C-ITS devine insuficient pentru utilizarea sa intenționată rămasă, CPA (cu recomandarea experților criptografici) informează entitatea CA primară cu care are un acord și modifică algoritmii utilizați. (Pentru detalii, a se vedea secțiunea 6 și CPS-urile CA primare și CA subordonate).
5.7.4.Capacitățile de asigurare a continuității activității în urma unui dezastru
(293)Elementele modelului de încredere al C-ITS care exploatează unități securizate pentru operațiunile CA trebuie să elaboreze, să testeze, să mențină și să pună în aplicare un plan de recuperare în caz de dezastru, conceput astfel încât să atenueze efectele oricărui dezastru natural sau cauzat de om. Aceste planuri au ca scop restaurarea serviciilor sistemelor informatice și a funcțiilor cheie ale activității.
(294)După un incident cu un anumit nivel de risc, CA compromisă trebuie să fie auditată din nou de un auditor acreditat al PKI (a se vedea secțiunea 8).
(295)În cazul în care CA compromisă nu mai poate funcționa (de exemplu, în urma unui incident grav), trebuie să fie elaborat un plan de migrare pentru transferul funcțiilor sale către altă CA primară. Trebuie să fie disponibilă cel puțin CA primară la nivelul UE pentru a sprijini planul de migrare. CA compromisă își încetează funcțiile.
(296)CA-urile primare includ în CPS planul de recuperare în caz de dezastru și planul de migrare.
5.8.Încetarea funcționării și transferul
5.8.1.TLM
(297)TLM nu își încetează funcționarea, dar o entitate care gestionează TLM poate să preia o altă entitate.
(298)În cazul schimbării entității de gestionare:
·aceasta solicită aprobarea CPA pentru trecerea gestionării TLM de la entitatea anterioară la entitatea nouă;
·CPA aprobă modificarea în gestionarea TLM;
·toate jurnalele de audit și înregistrările arhivate se transferă de la entitatea de gestionare anterioară la entitatea nouă.
5.8.2.CA primară
(299)CA primară nu își încetează/începe funcționarea fără a stabili un plan de migrare (prevăzut în CPS relevantă) care să garanteze funcționarea continuă pentru toți abonații.
(300)În cazul încetării serviciului CA primare, CA primară:
·notifică CPA;
·notifică TLM pentru ca acesta să poată șterge certificatul CA primare din ECTL;
·revocă CA primară corespunzătoare prin emiterea unei CRL în care este ea însăși;
·alertează CA-urile primare cu care a încheiat un acord în vederea reînnoirii certificatelor EA/AA;
·distruge cheia privată a CA primare;
·comunică cele mai recente informații referitoare la statutul revocării (CRL semnată de CA primară) către partea de încredere, indicând clar că acestea sunt cele mai recente informații referitoare la revocare;
·arhivează toate jurnalele de audit și alte înregistrări înainte de încetarea activității PKI;
·transferă înregistrările arhivate către o autoritate adecvată.
(301)TLM șterge certificatul CA primare corespunzător din ECTL.
5.8.3.EA/AA
(302)În cazul încetării serviciului EA/AA, entitatea EA/AA notifică acest lucru înainte de încetare. O EA/AA nu își încetează/începe funcționarea fără a stabili un plan de migrare (prevăzut în CPS relevantă) care să garanteze funcționarea continuă pentru toți abonații. EA/AA:
·informează CA primară prin scrisoare recomandată;
·distruge cheia privată a CA;
·își transferă baza de date către entitatea numită de CA primară;
·încetează emiterea certificatelor;
·în timpul transferului bazei sale de date și până când baza de date este complet operațională în cadrul unei entități noi, menține capacitatea de a autoriza solicitările de la autoritatea de resort în materie de confidențialitate;
·în cazul în care o CA subordonată a fost compromisă, CA primară revocă CA subordonată și emite o CRL nouă cu lista CA-urilor subordonate revocate;
·arhivează toate jurnalele de audit și alte înregistrări înainte de încetarea activității PKI;
·transferă înregistrările arhivate către o entitate desemnată de CA primară.
(303)În cazul încetării serviciilor CA, CA răspunde de păstrarea tuturor înregistrărilor relevante legate de necesitățile componentelor CA și PKI.
6.Controale tehnice de securitate
6.1.Generarea și instalarea perechii de chei
6.1.1.TLM, CA primară, EA, AA
(304)Procesul de generare a perechii de chei trebuie să îndeplinească cerințele următoare:
·fiecare participant trebuie să fie în măsură să își genereze propriile perechi de chei în conformitate cu secțiunile 6.1.4 și 6.1.5;
·procesul de derivare a cheilor de criptare simetrică și a unei chei MAC pentru solicitările de certificate (ECIES) trebuie să se efectueze în conformitate cu [1] și [5];
·procesul de generare a cheilor trebuie să utilizeze algoritmii și lungimile cheilor descrise în secțiunile 6.1.4.1 și 6.1.4.2;
·procesul de generare a cheilor trebuie să se supună cerințelor de „stocare securizată a cheilor private” (a se vedea secțiunea 6.1.5);
·CA-urile primare și abonații lor (CA-urile subordonate) trebuie să se asigure că integritatea și autenticitatea cheilor lor publice și ale oricăror parametri asociați sunt menținute în timpul distribuirii către entitățile CA subordonate înregistrate.
6.1.2.EE — stația C-ITS mobilă
(305)Fiecare stație C-ITS mobilă își generează propriile perechi de chei în conformitate cu secțiunile 6.1.4 și 6.1.5.
(306)Procesul de derivare a cheilor de criptare simetrică și a unei chei MAC pentru solicitările de certificate (ECIES) trebuie să se efectueze în conformitate cu [1] și [5].
(307)Procesele de generare a cheilor trebuie să utilizeze algoritmii și lungimile cheilor descrise în secțiunile 6.1.4.1 și 6.1.4.2.
(308)Procesele de generare a cheilor trebuie să se supună cerințelor de „stocare securizată a cheilor private” (a se vedea secțiunea 6.1.5).
6.1.3.EE — stația C-ITS fixă
(309)Fiecare stație C-ITS fixă își generează propria pereche de chei în conformitate cu secțiunile 6.1.4 și 6.1.5.
(310)Procesele de generare a cheilor trebuie să utilizeze algoritmii și lungimile cheilor descrise în secțiunile 6.1.4.1 și 6.1.4.2.
(311)Procesele de generare a cheilor trebuie să se supună cerințelor de „stocare securizată a cheilor private” (a se vedea secțiunea 6.1.5).
6.1.4.Cerințe criptografice
(312)Toți participanții la PKI trebuie să îndeplinească cerințele criptografice prevăzute la punctele următoare în ceea ce privește algoritmul semnăturii, lungimea cheii, generatorul numărului aleatoriu și certificatele de legătură.
6.1.4.1.Algoritm și lungimea cheii – algoritmii semnăturii
(313)Toți participanții la PKI (TLM, CA primară, EA, AA și stațiile C-ITS) trebuie să fie în măsură să genereze perechi de chei și să utilizeze cheia privată pentru operațiunile de semnare cu algoritmii selectați în termen de cel mult doi ani de la intrarea în vigoare a prezentului regulament, în conformitate cu tabelul 4.
(314)Este necesar ca toți participanții la PKI care trebuie să verifice integritatea ECTL, a certificatelor și/sau a mesajelor semnate potrivit rolurilor lor, astfel cum se definește în secțiunea 1.3.6, să poată accepta algoritmii corespunzători enumerați în tabelul 5 în vederea verificării. În special, stațiile C-ITS trebuie să fie în măsură să verifice integritatea ECTL.
|
TLM
|
CA primară
|
EA
|
AA
|
stația 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 indică acceptarea obligatorie
|
Tabelul 4: Generarea perechilor de chei și utilizarea cheii private pentru operațiunile de semnare
|
TLM
|
CA primară
|
EA
|
AA
|
stația 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 indică acceptarea obligatorie
|
Tabelul 5: Prezentarea generală a verificării
(315)Dacă CPA decide astfel pe baza vulnerabilităților criptografice nou constatate, toate stațiile C-ITS trebuie să fie în măsură să treacă la unul dintre cei doi algoritmi (ECDSA_nistP256_with_SHA 256 sau ECDSA_brainpoolP256_with_SHA 256) cât mai curând posibil. Algoritmul sau algoritmii efectivi care sunt utilizați trebuie să fie stabiliți în CPS a CA care emite certificatul pentru cheia publică corespunzătoare, în conformitate cu prezenta CP.
6.1.4.2.Algoritm și lungimea cheii – algoritmi de criptare pentru înscriere și pentru autorizare
(316)Toți participanții la PKI (EA, AA și stațiile C-ITS) trebuie să fie în măsură să utilizeze chei publice pentru criptarea solicitărilor de înscriere și de autorizare și a răspunsurilor la acestea cu algoritmii selectați, în termen de cel mult doi ani de la intrarea în vigoare a prezentului regulament, în conformitate cu tabelul 6. Algoritmul sau algoritmii efectivi care sunt utilizați trebuie să fie stabiliți în CPS a CA care emite certificatul pentru cheia publică corespunzătoare, în conformitate cu prezenta CP.
(317)Algoritmii menționați în tabelul 6 indică lungimea cheii și lungimea algoritmului hash și sunt implementați în conformitate cu [5].
|
TLM
|
CA primară
|
EA
|
AA
|
stația C-ITS
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X indică acceptarea obligatorie
|
Tabelul 6: Utilizarea cheilor publice pentru criptarea solicitărilor de înscriere și de autorizare și a răspunsurilor la acestea
(318)Toți participanții la PKI (EA, AA și stațiile C-ITS) trebuie să fie în măsură să utilizeze perechi de chei și să utilizeze cheia privată pentru decriptarea solicitărilor de înscriere și de autorizare și a răspunsurilor la acestea cu algoritmii selectați, în termen de cel mult doi ani de la intrarea în vigoare a prezentului regulament, în conformitate cu tabelul 7:
|
TLM
|
CA primară
|
EA
|
AA
|
stația C-ITS
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X indică acceptarea obligatorie
|
Tabelul 7: Generarea perechilor de chei și utilizarea cheii private pentru decriptarea solicitărilor de înscriere și de autorizare și a răspunsurilor la acestea
6.1.4.3.Agilitate criptografică
(319)Cerințele referitoare la lungimile cheilor și la algoritmi trebuie modificate de-a lungul timpului pentru a menține un nivel de securitate adecvat. CPA monitorizează necesitatea modificărilor de acest tip ținând cont de vulnerabilitățile efective și de ultimele evoluții în domeniul criptografiei. Aceasta redactează, aprobă și publică o actualizare a prezentei politici de certificare în cazul în care decide că algoritmii criptografici ar trebui să fie actualizați. Atunci când într-o nouă ediție a prezentei CP se semnalează o modificare a algoritmului și/sau a lungimii cheii, CPA va adopta o strategie de migrare care cuprinde perioadele de tranziție în decursul cărora este necesar să poată fi acceptați algoritmii și lungimile cheilor anterioare.
(320)Pentru a permite și pentru a facilita transferul la algoritmi și/sau lungimi ale cheilor noi, se recomandă ca toți participanții la PKI să implementeze echipamente hardware și/sau produse software capabile să accepte schimbarea lungimilor cheilor și a algoritmilor.
(321)Este necesar ca modificările certificatelor primare și ale certificatelor TLM să poată fi acceptate și executate cu ajutorul certificatelor de legătură (a se vedea secțiunea 4.6) care sunt utilizate pentru a acoperi perioada de tranziție de la certificatele primare anterioare și la cele noi („migrarea modelului de încredere”).
6.1.5.Stocarea securizată a cheilor private
Prezenta secțiune descrie cerințele aplicabile stocării securizate și generării perechilor de chei și numerelor aleatorii pentru CA-uri și entități finale. Aceste cerințe sunt definite pentru modulele criptografice și sunt descrise în subsecțiunile următoare.
6.1.5.1.Nivelul CA primară, CA subordonată și TLM
(322)Se utilizează un modul criptografic pentru:
·generarea, utilizarea, administrarea și stocarea cheilor private;
·generarea și utilizarea numerelor aleatorii (evaluarea funcției de generare a numerelor aleatorii face parte din evaluarea și certificarea de securitate);
·crearea de copii de rezervă ale cheilor private, în conformitate cu secțiunea 6.1.6;
·ștergerea cheilor private.
Modulul criptografic trebuie să fie certificat cu unul dintre profilurile de protecție (PP-uri) următoare, cu nivelul de asigurare EAL-4 sau un nivel superior:
·PP-uri pentru HSM-uri:
·CEN EN 419 221-2: Profiluri de protecție pentru module criptografice TSP – Partea 2: Modul criptografic pentru operațiunile de semnare a CSP fără copie de rezervă (Protection profiles for TSP cryptographic modules – Part 2: Cryptographic module for CSP signing operations without backup);
·CEN EN 419 221-4: Profiluri de protecție pentru module criptografice TSP – Partea 4: Modul criptografic pentru operațiunile de semnare a CSP fără copie de rezervă (Protection profiles for TSP cryptographic modules – Part 4: Cryptographic module for CSP signing operations without backup);
·CEN EN 419 221-5: Profiluri de protecție pentru module criptografice TSP – Partea 5: Modul criptografic pentru servicii de încredere (Protection profiles for TSP cryptographic modules – Part 5: Cryptographic module for trust services);
·PP-uri pentru carduri inteligente:
·CEN EN 419 211-2: Profiluri de protecție pentru dispozitivul de creare a semnăturii securizate – Partea 2: Dispozitiv cu generare de cheie (Protection profiles for secure signature creation device – Part 2: Device with key generation);
·CEN EN 419 211-3: Profiluri de protecție pentru dispozitivul de creare a semnăturii securizate – Partea 3: Dispozitiv cu import de cheie (Protection profiles for secure signature creation device — Part 3: Device with key import).
Accesul manual la modulul criptografic necesită o autentificare cu doi factori din partea administratorului. În plus, va necesita implicarea a două persoane autorizate.
Implementarea unui modul criptografic trebuie să asigure că cheile nu sunt accesibile în afara respectivului modul criptografic. Modulul criptografic trebuie să conțină un mecanism de control al accesului care să prevină utilizarea neautorizată a cheilor private.
6.1.5.2.Entitatea finală
(323)Se utilizează un modul criptografic pentru EE-uri pentru:
·generarea, utilizarea, administrarea și stocarea cheilor private;
·generarea și utilizarea numerelor aleatorii (evaluarea funcției de generare a numerelor aleatorii face parte din evaluarea și certificarea de securitate);
·ștergerea securizată a unei chei private.
(324)Modulul criptografic trebuie să fie protejat împotriva îndepărtării, înlocuirii și modificării neautorizate. Toate PP-urile și documentele aferente aplicabile în vederea certificării de securitate a modulului criptografic trebuie să fie evaluate, validate și certificate în conformitate cu ISO 15408, aplicând Acordul de recunoaștere reciprocă a certificatelor de evaluare a securității informatice al Grupului înalților funcționari pentru securitatea sistemelor informatice (SOG-IS) sau un sistem european de certificare de securitate cibernetică echivalent prevăzut în cadrul european relevant în materie de certificare de securitate.
(325)Dată fiind importanța menținerii celui mai înalt nivel de securitate posibil, certificatele de securitate pentru modulul criptografic se emit în temeiul sistemului de certificare bazat pe criterii comune (ISO 15408) de către un organism de evaluare a conformității recunoscut de comitetul de gestionare din cadrul Acordului SOG-IS sau se emit de către un organism de evaluare a conformității acreditat de o autoritate națională de certificare de securitate cibernetică a unui stat membru. Un astfel de organism de evaluare a conformității trebuie să ofere condiții de evaluare a securității cel puțin echivalente cu cele prevăzute în Acordul de recunoaștere reciprocă SOG-IS.
Observație: legătura dintre modulul criptografic și stația C-ITS trebuie să fie protejată.
6.1.6.Copia de rezervă a cheilor private
(326)Generarea, stocarea și utilizarea copiilor de rezervă ale cheilor private trebuie să îndeplinească cel puțin cerințele nivelului de securitate impus pentru cheile originale.
(327)Copiile de rezervă ale cheilor private sunt realizate de CA-urile primare, EA-uri și AA-uri.
(328)Nu se realizează copii de rezervă ale cheilor private pentru EC-uri și AT-uri.
6.1.7.Distrugerea cheilor private
(329)CA-urile primare, EA-urile, AA-urile și stațiile C-ITS mobile și fixe își distrug cheia privată și orice copii de rezervă corespunzătoare dacă s-au generat și au fost instalate cu succes o pereche de chei nouă și un certificat corespunzător, iar perioada de suprapunere (dacă există — doar pentru CA) a expirat. Cheia privată este distrusă utilizând mecanismul oferit de modulul criptografic utilizat pentru stocarea cheii sau așa cum se descrie în PP-ul corespunzător, după cum se menționează în secțiunea 6.1.5.2.
6.2.Datele de activare
(330)Datele de activare se referă la factorii de autentificare necesari pentru a opera modulele criptografice, pentru a preveni accesul neautorizat. Utilizarea datelor de activare ale unui dispozitiv criptografic al unei CA necesită acțiunea a două persoane autorizate.
6.3.Controalele de securitate a sistemelor informatice
(331)Controalele de securitate a sistemelor informatice ale CA-urilor trebuie să fie concepute în conformitate cu cel mai înalt nivel de securitate, respectând cerințele ISO/IEC 27002.
6.4.Controalele tehnice ale ciclului de viață
(332)Controalele tehnice ale CA trebuie să acopere întregul ciclu de viață al CA. Este vorba, în special, de cerințele din secțiunea 6.1.4.3 („Agilitate criptografică”).
6.5.Controalele de securitate a rețelelor
(333)Rețelele CA-urilor (CA primară, EA și AA) trebuie să fie consolidate pentru a face față atacurilor, în conformitate cu cerințele și cu îndrumările de implementare ale ISO/IEC 27001 și ISO/IEC 27002.
(334)Disponibilitatea rețelelor CA-urilor trebuie să fie concepută în funcție de traficul estimat.
7.Profiluri de certificate, CRL și CTL
7.1.Profilul de certificat
(335)Profilurile de certificate definite în [5] se utilizează pentru TLM, certificatele primare, certificatele EA, certificatele AA, AT-uri și EC-uri. EA-urile guvernamentale naționale pot utiliza alte profiluri de certificate pentru EC-uri.
(336)Certificatele CA primare, EA și AA trebuie să indice permisiunile pentru care aceste CA-uri (CA-uri primare, EA și AA) pot emite certificate.
(337)Pe baza [5]:
·fiecare CA primară își utilizează propria cheie privată de semnare pentru a emite CRL-uri;
·TLM își utilizează propria cheie privată de semnare pentru a emite ECTL.
7.2.Valabilitatea certificatelor
(338)Toate profilurile de certificate C-ITS trebuie să includă o dată de emitere și o dată de expirare, care reprezintă perioada de valabilitate a certificatului. La fiecare nivel al PKI, certificatele se generează cu suficient timp înainte de expirare.
(339)Perioada de valabilitate a certificatelor CA și EC include o perioadă de suprapunere. Certificatele TLM și ale CA primare sunt emise și incluse în ECTL cu maximum trei luni și minimum o lună înainte de începutul valabilității lor, pe baza datei de începere a valabilității din certificat. Această etapă de preîncărcare este necesară pentru a distribui în condiții de siguranță certificatele tuturor părților de încredere corespunzătoare, în conformitate cu secțiunea 2.2. Astfel se asigură că, de la începutul perioadei de suprapunere, toate părțile de încredere sunt deja în măsură să verifice mesajele emise cu un certificat nou.
(340)La începutul perioadei de suprapunere, certificatele CA, EC și AT succesive se emit (dacă este cazul), se distribuie și se instalează de către părțile de încredere corespunzătoare. În timpul perioadei de suprapunere, certificatul în vigoare se utilizează numai pentru verificare.
(341)Deoarece perioadele de valabilitate indicate în tabelul 8 trebuie să nu depășească perioada de valabilitate a certificatului superior, se aplică următoarele restricții:
·maximumvalidity(Root CA) = privatekeyusage(Root CA) + maximumvalidity(EA,AA);
·maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC);
·maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(AT).
(342)Valabilitatea certificatelor de legătură (primare și TLM) începe cu utilizarea cheii private corespunzătoare și se încheie odată cu perioada de valabilitate maximă a CA primare sau TLM.
(343)Tabelul 8 prezintă perioada de valabilitate maximă pentru certificatele CA C-ITS (pentru perioadele de valabilitate ale AT, a se vedea secțiunea 7.2.1).
Entitate
|
Perioada maximă de utilizare a cheii private
|
Perioada de valabilitate maximă
|
CA primară
|
3 ani
|
8 ani
|
EA
|
2 ani
|
5 ani
|
AA
|
4 ani
|
5 ani
|
EC
|
3 ani
|
3 ani
|
TLM
|
3 ani
|
4 ani
|
Tabelul 8: Perioadele de valabilitate ale certificatelor din modelul de încredere al C-ITS
7.2.1.Certificatele cu pseudonim
(344)În acest context, pseudonimele sunt implementate prin AT-uri. În consecință, prezenta secțiune se referă la AT-uri mai degrabă decât la pseudonime.
(345)Cerințele prevăzute în prezenta secțiune se aplică doar AT-urilor stațiilor C-ITS mobile care trimit mesaje CAM și DENM, atunci când riscul referitor la confidențialitatea amplasamentului este aplicabil. Nu se aplică cerințe specifice privind certificatele AT pentru AT-urile destinate stațiilor C-ITS fixe și stațiilor C-ITS mobile utilizate pentru funcții speciale atunci când confidențialitatea amplasamentului nu este aplicabilă (de exemplu, vehicule de urgență și vehiculele forțelor de ordine marcate).
(346)Se aplică definițiile următoare:
·„perioadă de valabilitate pentru AT-uri” – perioada în care un AT este valabil, și anume perioada dintre data la care AT devine valabil și data sa de expirare;
·„perioadă de preîncărcare pentru AT-uri” – preîncărcare înseamnă posibilitatea stațiilor C-ITS de a obține AT-uri înainte să înceapă perioada de valabilitate. Perioada de preîncărcare este perioada maximă permisă de la solicitarea AT-urilor până la ultima dată de valabilitate a oricărui AT solicitat;
·„perioada de utilizare pentru AT-uri” – perioada în care un AT este utilizat efectiv pentru semnarea mesajelor CAM/DENM;
·„numărul maxim de AT-uri paralele” – numărul de AT-uri dintre care o stație C-ITS poate alege în orice moment atunci când semnează un mesaj CAM/DENM, și anume numărul de AT-uri diferite emise unei singure stații C-ITS care sunt valabile în același timp.
(347)Se aplică cerințele următoare:
·perioada de preîncărcare pentru AT-uri nu trebuie să depășească trei luni;
·perioada de valabilitate pentru AT-uri nu trebuie să depășească o săptămână;
·numărul maxim de AT-uri paralele nu trebuie să depășească 100 pentru fiecare stație C-ITS;
·perioada de utilizare a unui AT depinde de strategia de schimbare a AT și de intervalul de timp în care este în funcțiune un vehicul, însă este limitată de numărul maxim de AT-uri paralele și de perioada de valabilitate. Mai precis, perioada de utilizare medie pentru o stație C-ITS este reprezentată cel puțin de perioada operațională a vehiculului în timpul unei singure perioade de valabilitate, împărțită la numărul maxim de AT-uri paralele.
7.2.2.Tichete de autorizare pentru stațiile C-ITS fixe
(348)Se aplică definițiile din secțiunea 7.2.1 și cerințele următoare:
·perioada de preîncărcare pentru AT-uri nu trebuie să depășească trei luni;
·numărul maxim de AT-uri paralele nu trebuie să depășească două pentru fiecare stație C-ITS.
7.3.Revocarea certificatelor
7.3.1.Revocarea certificatelor CA, EA și AA
Certificatele CA primare, EA și AA sunt revocabile. Certificatele revocate ale CA-urilor primare, EA-urilor și AA-urilor se publică într-o CRL cât mai curând posibil și fără întârzieri nejustificate. Respectiva CRL trebuie să fie semnată de CA primară corespunzătoare și trebuie să utilizeze profilul descris în secțiunea 7.4. Pentru revocarea certificatelor CA primare, CA primară corespunzătoare emite o CRL în care este ea însăși. În plus, în cazul compromiterii securității, se aplică secțiunea 5.7.3. De asemenea, TLM scoate de pe lista de încredere CA-urile primare revocate și emite o listă de încredere nouă. Certificatele expirate sunt scoase de pe CRL corespunzătoare și de pe lista de încredere.
(349)Certificatele sunt revocate în cazul în care:
·CA-urile primare au motive să considere sau există suspiciuni puternice că cheia privată corespunzătoare a fost compromisă;
·CA-urile primare au fost notificate că a încetat contractul cu abonatul;
·informațiile (cum ar fi numele și asocierile dintre CA și subiect) din certificat sunt incorecte sau s-au modificat;
·are loc un incident de securitate care afectează titularul certificatului;
·se obține un rezultat negativ în urma unui audit (a se vedea secțiunea 8).
(350)Abonatul trebuie să notifice imediat CA orice compromitere cunoscută sau suspectată a cheii sale private. Trebuie să se asigure că doar solicitările autentificate au ca rezultat certificate revocate.
7.3.2.Revocarea acreditărilor de înscriere
(351)Revocarea EC-urilor poate fi inițiată de abonatul stației C-ITS (fluxul 34) și este pusă în aplicare printr-o listă neagră internă într-o bază de date de revocări cu marcaj temporal, care este generată și menținută de fiecare EA. Lista neagră nu se publică niciodată, este confidențială și este utilizată doar de EA corespunzătoare, pentru a verifica valabilitatea EC-urilor corespunzătoare în contextul solicitărilor de AT-uri și noi EC-uri.
7.3.3.Revocarea tichetelor de autorizare
(352)AT-urile nu sunt revocate de CA-urile corespunzătoare; ele au o durată de viață scurtă și nu pot fi emise cu prea mult timp înainte de a deveni valabile. Valorile permisibile ale parametrilor ciclului de viață al certificatului sunt prevăzute în secțiunea 7.2.
7.4.Lista certificatelor revocate
(353)Formatul și conținutul CRL emise de CA-urile primare sunt cele prevăzute în [1].
7.5.Lista europeană de certificate de încredere
(354)Formatul și conținutul ECTL emise de TLM sunt cele prevăzute în [1].
8.Auditul de conformitate și alte evaluări
8.1.Subiectele acoperite de audit și baza de audit
(355)Scopul unui audit de conformitate este să verifice dacă TLM, CA-urile primare, EA-urile și AA-urile funcționează în conformitate cu prezenta CP. TLM, CA-urile primare, EA-urile și AA-urile selectează un auditor al PKI acreditat, care acționează independent, pentru a audita CPS-urile lor. Auditul este combinat cu o evaluare bazată pe ISO/IEC 27001 și ISO/IEC 27002.
(356)Auditul de conformitate pentru o CA primară este dispus de către însăși CA primară (fluxul 13), iar pentru o CA subordonată de către EA/AA subordonată acesteia.
(357)Auditul de conformitate pentru TLM este dispus de CPA (fluxul 38).
(358)La cerere, auditorul acreditat al PKI efectuează un audit de conformitate la unul dintre următoarele niveluri:
(1)conformitatea cu prezenta CP a CPS-urilor TLM, CA primare, EA sau AA;
(2)conformitatea practicilor intenționate ale TLM, CA primare, EA sau AA cu CPS-urile lor înaintea operării;
(3)conformitatea practicilor și a activităților operaționale ale TLM, CA primare, EA sau AA cu CPS-urile lor în timpul operării.
(359)Auditul acoperă toate cerințele prezentei CP care trebuie îndeplinite de TLM, CA-urile primare, EA-urile și AA-urile care urmează să fie auditate. Auditul acoperă de asemenea funcționarea CA în PKI a C-ITS, inclusiv toate procesele menționate în CPS a sa, spațiile în care funcționează și persoanele responsabile.
(360)Auditorul acreditat al PKI prezintă un raport detaliat al auditului către CA primară (fluxul 36), EA, AA sau CPA (fluxurile 16 și 40), după caz.
8.2.Frecvența auditurilor
(361)CA primară, TLM, EA sau AA dispune un audit de conformitate asupra propriei organizații efectuat de către un auditor al PKI independent și acreditat în următoarele situații:
·la prima sa înființare (conformitatea de nivel 1 și 2);
·la fiecare modificare a CP. CPA definește conținutul modificării CP și calendarul implementării acesteia și determină necesitățile de audit (inclusiv nivelul de conformitate necesar) în consecință;
·la fiecare modificare a CPS a sa (conformitatea de nivel 1, 2 și 3). Deoarece entitățile de gestionare ale CA-urilor primare, TLM și EA-urilor/AA-urilor decid care sunt modificările în implementare rezultate din actualizarea CPS a lor, acestea dispun auditul de conformitate înainte de a implementa aceste modificări. În cazul în care modificările CPS sunt doar minore (de exemplu, modificări de redactare), entitatea de gestionare poate trimite CPA o solicitare temeinic justificată de aprobare a omiterii auditurilor de conformitate de nivel 1, 2 sau 3;
·regulat, cel puțin din trei în trei ani în timpul funcționării sale (conformitatea de nivel 3).
8.3.Identitatea/calificările auditorului
(362)CA care urmează să fie auditată selectează o societate/organizație independentă și acreditată („organismul de audit”) sau auditori acreditați ai PKI pentru a o audita în conformitate cu prezenta CP. Organismul de audit trebuie să fie acreditat și certificat de un membru al Organismului european de acreditare.
8.4.Relația auditorului cu entitatea auditată
(363)Auditorul acreditat al PKI trebuie să fie independent de entitatea auditată.
8.5.Măsurile luate în urma constatării unor deficiențe
(364)În cazul în care raportul de audit constată că TLM nu este conform, CPA ordonă TLM să ia imediat măsuri preventive/corective.
(365)În cazul în care o CA primară cu un raport de audit neconform face o cerere nouă, CPA respinge cererea și transmite o respingere corespunzătoare către CA primară (fluxul 4). În astfel de cazuri, CA primară va fi suspendată. Aceasta trebuie să ia măsuri corective, să dispună un audit nou și să solicite din nou aprobarea CPA. În timpul suspendării, nu se permite CA primare să emită certificate.
(366)În cazul unui audit regulat al CA primare sau al modificării CPS a CA primare și în funcție de natura neconformității descrise în raportul de audit, CPA poate decide să revoce CA primară și comunică această decizie către TLM (fluxul 2), cu rezultatul ștergerii certificatului CA primare de pe ECTL și al introducerii CA primare în CRL. CPA transmite o respingere corespunzătoare către CA primară (fluxul 4). CA primară trebuie să ia măsuri corective, să dispună din nou un audit complet (de nivel 1-3) și să solicite din nou aprobarea CPA. Alternativ, CPA poate decide să nu revoce CA primară, ci să îi acorde un termen de grație în care CA primară trebuie să ia măsuri corective, să dispună efectuarea unui audit nou și să transmită din nou către CPA raportul de audit. În acest caz, funcționarea CA primare trebuie să fie suspendată și acesteia nu i se permite să elibereze certificate și CRL-uri.
(367)În cazul auditării EA/AA, CA primară decide dacă să accepte sau nu raportul. În funcție de rezultatul auditului, CA primară decide dacă să revoce sau nu certificatul EA/AA în conformitate cu regulile din CPS a CA primare. CA primară asigură în permanență conformitatea EA/AA cu prezenta CP.
8.6.Comunicarea rezultatelor
(368)CA primară și TLM transmit către CPA raportul de audit (fluxul 16). CA primară și TLM stochează toate rapoartele de audit pe care le-au dispus. CPA transmite aprobarea sau respingerea corespunzătoare (fluxul 4) către CA primară și TLM.
(369)CA primară transmite un certificat de conformitate către EA/AA corespunzătoare.
9.Alte dispoziții
9.1.Tarifele
(370)Un principiu al modelului UE de încredere al C-ITS implementat este acela că CA-urile primare finanțează împreună, integral, costurile regulate recurente de funcționare a CPA și elementele centrale (TLM și CPOC) în legătură cu activitățile prevăzute în prezenta CP.
(371)CA-urile primare (inclusiv CA primară la nivelul UE) au dreptul să perceapă tarife CA-urilor lor subordonate.
(372)Pe tot parcursul perioadei sale de funcționare, fiecare participant la modelul de încredere al C-ITS trebuie să aibă acces, fără discriminare, la cel puțin o CA primară, EA și AA.
(373)Fiecare CA primară are dreptul să transfere tarifele pe care le plătește pentru CPA și elementele centrale (TLM și CPOC) către participanții înregistrați ai modelului de încredere al C-ITS, inclusiv către stațiile C-ITS înscrise și autorizate.
9.2.Responsabilitatea financiară
(374)Înființarea inițială a unei CA primare trebuie să acopere o perioadă de cel puțin trei ani de funcționare pentru ca aceasta să devină membră a modelului UE de încredere al C-ITS. De asemenea, CPS a unui operator al CA primare trebuie să conțină dispoziții detaliate privind revocarea sau închiderea CA primare.
(375)Fiecare CA primară trebuie să demonstreze viabilitatea financiară a entității care o implementează, timp de cel puțin trei ani. Acest plan privind viabilitatea financiară face parte din setul inițial de documente necesare pentru înscriere și trebuie să fie actualizat din trei în trei ani și raportat către CPA.
(376)Fiecare CA primară trebuie să raporteze directorului de operațiuni și CPA structura tarifelor aplicate EA-urilor/AA-urilor și stațiilor C-ITS înscrise și autorizate, în fiecare an, pentru a-și demonstra sustenabilitatea financiară.
(377)Toate entitățile responsabile din punct de vedere financiar și juridic ale CA primare, EA, AA și ale elementelor centrale (CPOC și TLM) ale modelului de încredere al C-ITS trebuie să își protejeze atribuțiile operaționale prin niveluri de asigurare adecvate, pentru a compensa erorile operaționale și recuperarea atribuțiilor lor din punct de vedere financiar în cazul în care unul dintre elementele tehnice se defectează.
9.3.Confidențialitatea informațiilor privind activitatea economică
(378)Următoarele informații sunt confidențiale și private:
·înregistrările referitoare la cererile CA primare, EA, AA, indiferent dacă sunt aprobate sau respinse;
·rapoartele de audit ale CA primare, EA, AA și TLM;
·planurile de recuperare în caz de dezastru ale CA-urilor primare, EA-urilor, AA-urilor, CPOC-urilor și TLM;
·cheile private ale elementelor modelului de încredere al C-ITS (stații C-ITS, TLM, EA, AA, CA-uri primare);
·orice alte informații identificate drept confidențiale de CPA, CA-uri primare, EA, AA, TLM și CPOC.
9.4.Planul de confidențialitate
(379)CPS-urile CA-urilor primare și ale EA-urilor/AA-urilor trebuie să prevadă planul și cerințele privind tratarea informațiilor cu caracter personal și confidențialitatea, pe baza RGPD și a altor cadre legislative (de exemplu, naționale) aplicabile.
10.Trimiteri
În prezenta anexă se utilizează următoarele trimiteri.
[1]
|
ETSI TS 102 941 V1.2.1, Sisteme de transport inteligente (ITS). Securitate. Gestionarea încrederii și a confidențialității [Intelligent Transport Systems (ITS) – Security, Trust and Privacy Management].
|
[2]
|
ETSI TS 102 940 V1.3.1, Sisteme de transport inteligente (ITS). Securitate. Arhitectura securității comunicațiilor ITS și managementul securității [Intelligent Transport Systems (ITS); Security; ITS communications security architecture and security management].
|
[3]
|
Cadrul politicii de certificare și al practicilor de certificare (Certificate policy and certification practices framework, RFC 3647, 1999).
|
[4]
|
ETSI TS 102 042 V2.4.1 Cerințe de politică pentru autoritățile de certificare care emit certificate cu cheie publică (Policy requirements for certification authorities issuing public key certificates).
|
[5]
|
ETSI TS 103 097 V1.3.1, Sisteme de transport inteligente (ITS). Securitate, antetul de securitate și formatele certificatelor [Intelligent Transport Systems (ITS); security; security header and certificate formats].
|
[6]
|
Calder, A. (2006). Securitatea informațiilor pe baza ISO 27001/ISO 1779: ghid de gestionare (Information security based on ISO 27001/ISO 1779:a management guide). Van Haren Publishing.
|
[7]
|
ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – Tehnologia informației. Tehnici de securitate. Managementul riscului de securitate a informației. ISO.
|
|
|