OBSAH
1.Úvod9
1.1Přehled a oblast působnosti této politiky9
1.2Definice a zkratky11
1.3Účastníci PKI13
1.3.1Úvod13
1.3.2Orgán pro certifikační politiku C-ITS16
1.3.3Správce seznamu důvěryhodných subjektů17
1.3.4Akreditovaný auditor PKI17
1.3.5Kontaktní místo C-ITS (CPOC)17
1.3.6Provozní role18
1.4Použití certifikátu18
1.4.1Příslušné oblasti použití18
1.4.2Rozsah odpovědnosti19
1.5Správa certifikační politiky19
1.5.1Aktualizace CPS certifikačních autorit uvedených v ECTL19
1.5.2Schvalovací postupy CPS20
2.Povinnosti v oblasti zveřejňování a úložišť20
2.1Metody zveřejňování informací o certifikátech20
2.2Čas nebo četnost zveřejňování21
2.3Úložiště21
2.4Kontroly přístupu do úložišť21
2.5Zveřejňování informací o certifikátu22
2.5.1Zveřejňování informací o certifikátu správcem seznamu důvěryhodných subjektů22
2.5.2Zveřejňování informací o certifikátu certifikačními autoritami22
3.Identifikace a autentizace23
3.1Pojmenovávání23
3.1.1Druhy názvu23
3.1.1.1Názvy TLM, kořenových CA, EA, AA23
3.1.1.2Názvy koncových subjektů23
3.1.1.3Identifikace certifikátů23
3.1.2Požadavek na smysluplnost názvů23
3.1.3Anonymita a pseudonymita koncových subjektů23
3.1.4Pravidla pro výklad různých forem názvů23
3.1.5Jedinečnost názvů24
3.2Počáteční potvrzení totožnosti24
3.2.1Metoda prokazování vlastnictví soukromého klíče24
3.2.2Autentizace totožnosti organizace24
3.2.2.1Autentizace totožnosti organizace kořenových CA24
3.2.2.2Autentizace totožnosti organizace TLM25
3.2.2.3Autentizace totožnosti organizace podřízených CA25
3.2.2.4Autentizace účastnické organizace koncových subjektů26
3.2.3Autentizace jednotlivého subjektu26
3.2.3.1Autentizace jednotlivého subjektu TLM / CA26
3.2.3.2Autentizace totožnosti účastníka stanic C-ITS27
3.2.3.3Autentizace totožnosti stanice C-ITS27
3.2.4Neověřené informace o účastníkovi27
3.2.5Validace autority27
3.2.5.1Validace TLM, kořenové CA, EA, AA27
3.2.5.2Validace účastníků stanice C-ITS28
3.2.5.3Validace stanice C-ITS28
3.2.6Kritéria pro interoperabilitu28
3.3Identifikace a autentizace žádostí o změnu klíče28
3.3.1Identifikace a autentizace žádostí o rutinní změnu klíče28
3.3.1.1Certifikáty TLM28
3.3.1.2Certifikáty kořenové CA28
3.3.1.3Obnova certifikátu nebo změna klíče EA/AA28
3.3.1.4Oprávnění koncových subjektů k registraci29
3.3.1.5Autorizační potvrzení koncových subjektů29
3.3.2Identifikace a autentizace žádostí o změnu klíče po odvolání29
3.3.2.1Certifikáty CA29
3.3.2.2Oprávnění koncových subjektů k registraci29
3.3.2.3Žádosti koncových subjektů o autorizaci29
3.4Identifikace a autentizace pro žádost o odvolání29
3.4.1Certifikáty kořenové CA/EA/AA29
3.4.2Oprávnění stanice C-ITS k registraci30
3.4.3Potvrzení o autorizaci stanice C-ITS30
4.Provozní požadavky na životní cyklus certifikátu30
4.1Žádost o certifikát30
4.1.1Kdo může podat žádost o certifikát30
4.1.1.1Kořenové CA30
4.1.1.2TLM31
4.1.1.3EA a AA31
4.1.1.4Stanice C-ITS31
4.1.2Proces a povinnosti registrace31
4.1.2.1Kořenové CA31
4.1.2.2TLM32
4.1.2.3EA a AA32
4.1.2.4Stanice C-ITS32
4.2Zpracování žádosti o certifikát33
4.2.1Vykonávání funkcí identifikace a autentizace33
4.2.1.1Identifikace a autentizace kořenových CA33
4.2.1.2Identifikace a autentizace správce seznamu důvěryhodných subjektů33
4.2.1.3Identifikace a autentizace EA a AA33
4.2.1.4Identifikace a autentizace účastníka EE34
4.2.1.5Potvrzení o autorizaci34
4.2.2Schválení nebo zamítnutí žádostí o certifikát34
4.2.2.1Schválení nebo zamítnutí certifikátů kořenové CA34
4.2.2.2Schválení nebo zamítnutí certifikátu správce seznamu důvěryhodných subjektů34
4.2.2.3Schválení nebo zamítnutí certifikátů EA a AA34
4.2.2.4Schválení nebo zamítnutí oprávnění34
4.2.2.5Schválení nebo zamítnutí potvrzení o autorizaci35
4.2.3Doba pro zpracování žádosti o certifikát35
4.2.3.1Žádost o certifikát kořenové CA35
4.2.3.2Žádost o certifikát TLM35
4.2.3.3Žádost o certifikát EA a AA35
4.2.3.4Žádost o EC35
4.2.3.5Žádost o AT35
4.3Vydávání certifikátu35
4.3.1Úkony CA v průběhu vydávání certifikátu35
4.3.1.1Vydávání certifikátu kořenové CA35
4.3.1.2Vydávání certifikátu TLM36
4.3.1.3Vydávání certifikátu EA a AA36
4.3.1.4Vydávání oprávnění36
4.3.1.5Vydávání potvrzení o autorizaci36
4.3.2Oznámení CA účastníkovi o vydání certifikátů36
4.4Přijetí certifikátu37
4.4.1Převzetí certifikátu37
4.4.1.1Kořenová CA37
4.4.1.2TLM37
4.4.1.3EA a AA37
4.4.1.4Stanice C-ITS37
4.4.2Zveřejnění certifikátu37
4.4.3Oznámení o vydání certifikátu37
4.5Použití páru klíčů a certifikátu37
4.5.1Použití soukromého klíče a certifikátu37
4.5.1.1Použití soukromého klíče a certifikátu pro TLM37
4.5.1.2Použití soukromého klíče a certifikátů pro kořenové CA37
4.5.1.3Použití soukromého klíče a certifikátu registrující a autorizační autoritou37
4.5.1.4Použití soukromého klíče a certifikátu koncovým subjektem38
4.5.2Použití veřejného klíče a certifikátu spoléhající se stranou38
4.6Obnova certifikátu38
4.7Změna klíče certifikátu38
4.7.1Okolnosti pro změnu klíče certifikátu38
4.7.2Kdo může požádat o změnu klíče38
4.7.2.1Kořenová CA38
4.7.2.2TLM38
4.7.2.3EA a AA38
4.7.2.4Stanice C-ITS39
4.7.3Proces změny klíče39
4.7.3.1Certifikát TLM39
4.7.3.2Certifikát kořenové CA39
4.7.3.3Certifikáty EA a AA39
4.7.3.4Certifikáty stanice C-ITS40
4.8Změna v certifikátu40
4.9Odvolání a pozastavení platnosti certifikátu40
4.10Služby ověřování stavu certifikátu40
4.10.1Provozní charakteristiky40
4.10.2Dostupnost služby40
4.10.3Volitelné prvky40
4.11Ukončení účasti40
4.12Úschova klíče u třetí strany a jeho obnova40
4.12.1Účastník40
4.12.1.1Jaký pár klíčů lze uschovat u třetí strany40
4.12.1.2Kdo může podat žádost o obnovu40
4.12.1.3Proces a povinnosti obnovy40
4.12.1.4Identifikace a autentizace40
4.12.1.5Schválení nebo zamítnutí žádostí o obnovu40
4.12.1.6Akce KEA a KRA v průběhu obnovy páru klíčů41
4.12.1.7Dostupnost akcí KEA a KRA41
4.12.2Politika a postupy enkapsulace a obnovy klíče relace41
5.Kontroly zařízení, kontroly řízení a provozní kontroly41
5.1Fyzické kontroly41
5.1.1Umístění a konstrukce41
5.1.1.1Kořenová CA, CPOC, TLM41
5.1.1.2EA/AA42
5.2.1Fyzický přístup42
5.1.2.1Kořenová CA, CPOC, TLM42
5.1.2.2EA/AA43
5.1.3Napájení a klimatizace43
5.1.4Vystavení vodě43
5.1.5Protipožární opatření a ochrana44
5.1.6Správa médií44
5.1.7Likvidace odpadu44
5.1.8Záloha mimo pracoviště44
5.1.8.1Kořenová CA, CPOC a TLM44
5.1.8.2EA/AA45
5.2Procedurální kontroly45
5.2.1Důvěryhodné role45
5.2.2Počet osob požadovaný pro každý úkol45
5.3.2Identifikace a autentizace pro každou roli46
5.4.2Role vyžadující oddělení povinností46
5.3Kontroly pracovníků47
5.3.1Požadavky na kvalifikace, zkušenosti a ověření spolehlivosti47
5.3.2Postupy ověření spolehlivosti47
5.3.3Požadavky na výcvik48
5.4.3Četnost rekvalifikace a požadavky na ni48
5.5.3Četnost rotace pracovních míst a jejich pořadí48
5.3.6Sankce za neautorizované činnosti48
5.3.7Požadavky na nezávislé dodavatele49
5.3.8Dokumentace poskytovaná pracovníkům49
5.4Postupy protokolování auditu49
5.4.1Typy událostí, které mají být zaznamenávány a oznamovány každou CA49
5.4.2Četnost zpracování protokolu50
5.4.3Doba uchovávání auditního protokolu50
5.4.4Ochrana auditního protokolu51
5.5.4Postupy zálohování auditního protokolu51
5.4.6Auditní systém sběru údajů (interní nebo externí)51
5.4.7Oznámení subjektu, který událost způsobil51
5.4.8Hodnocení zranitelnosti51
5.5Archivace záznamů52
5.5.1Typy archivovaných záznamů52
5.5.2Doba uchovávání v archivu53
5.5.3Ochrana archivu53
5.5.4Systémový archiv a uchovávání53
5.5.5Požadavky na časová razítka záznamů54
5.5.6Systém archivace (interní nebo externí)54
5.5.7Postupy získávání a ověřování archivních informací54
5.6Změna klíčů pro prvky C-ITS modelu služeb vytvářejících důvěru54
5.6.1TLM54
5.6.2Kořenová CA54
5.6.3Certifikát EA/AA54
5.6.4Auditor55
5.7Obnova po ohrožení a havárii55
5.7.1Řešení incidentů a ohrožení55
5.7.2Porušení výpočetních zdrojů, softwaru a/nebo dat56
5.7.3Postupy při ohrožení soukromého klíče subjektu56
5.7.4Schopnosti kontinuity činnosti po havárii56
5.8Ukončení a převod57
5.8.1TLM57
5.8.2Kořenová CA57
5.8.3EA/AA58
6.Technické bezpečnostní kontroly58
6.1Generování a instalace páru klíčů58
6.1.1TLM, kořenová CA, EA, AA58
6.1.2Koncový subjekt – mobilní stanice C-ITS58
6.1.3Koncový subjekt – pevné stanice C-ITS59
6.1.4Kryptografické požadavky59
6.1.4.1Algoritmus a délka klíče – algoritmy podpisu59
6.1.4.2Algoritmus a délka klíče – šifrovací algoritmy pro registraci a autorizaci60
6.1.4.3Kryptoagilita61
6.1.5Bezpečné uchovávání soukromých klíčů61
6.1.5.1Úroveň kořenové CA, podřízené CA a TLM61
6.1.5.2Koncový subjekt62
6.1.6Zálohování soukromých klíčů63
6.1.7Likvidace soukromých klíčů63
6.2Aktivační údaje63
6.3Počítačové bezpečnostní kontroly63
6.4Technické kontroly životního cyklu63
6.5Bezpečnostní kontroly sítě63
7.Profily certifikátů, CRL a CTL63
7.1Profil certifikátu63
7.2Platnost certifikátu64
7.2.1Certifikáty pseudonymu65
7.2.2Autorizační potvrzení pro pevné stanice C-ITS65
7.3Odvolání certifikátů65
7.3.1Odvolání certifikátů CA, EA a AA65
7.3.2Odvolání oprávnění k registraci66
7.3.3Odvolání potvrzení o autorizaci66
7.4Seznam odvolaných certifikátů66
7.5Evropský seznam důvěryhodných certifikátů66
8.Audit souladu a další posouzení66
8.1Témata auditu a základ auditu66
8.2Četnost auditů67
8.3Totožnost/kvalifikace auditora67
8.4Vztah auditora k auditovanému subjektu67
8.5Opatření přijatá v důsledku nedostatku68
8.6Sdělování výsledků68
9.Jiná ustanovení68
9.1Poplatky68
9.2Finanční odpovědnost69
9.3Důvěrnost obchodních informací69
9.4Plán ochrany soukromí69
10.Odkazy69
PŘÍLOHA III
1.Úvod
1.1.Přehled a oblast působnosti této politiky
Tato certifikační politika definuje evropský C-ITS model C-ITS služeb vytvářejících důvěru založený na infrastruktuře veřejných klíčů (PKI) v rámci celkového systému správy bezpečnostních oprávnění pro EU C-ITS (EU CCMS). Definuje rovněž požadavky na správu certifikátů veřejných klíčů pro aplikace C-ITS vydávajícími subjekty a jejich využívání koncovými subjekty v Evropě. Na nejvyšší úrovni se PKI skládá ze souboru kořenových certifikačních autorit „umožněných“ tím, že správce seznamu důvěryhodných subjektů (TLM) vložil jejich certifikáty do evropského seznamu důvěryhodných certifikátů (ECTL), který vydává a zveřejňuje centrální subjekt TLM (viz oddíly 1.2 a 1.3).
Tato politika je závazná pro všechny subjekty zapojené do C-ITS systému služeb vytvářejících důvěru v Evropě. Pomáhá při posuzování úrovně důvěry, kterou může u obdržených informací stanovit kterýkoli příjemce zprávy ověřené certifikátem koncového subjektu PKI. Aby bylo možné posoudit důvěru v certifikáty poskytnuté EU CCMS, stanoví závazný soubor požadavků pro provoz centrálního subjektu TLM a pro sestavování a správu ECTL. V důsledku toho tímto dokumentem řídí následující aspekty ECTL:
·identifikace a autentizace hlavních účastníků, kteří získávají role PKI pro TLM, včetně popisu privilegií přidělených každé roli,
·minimální požadavky na místní bezpečnostní postupy TLM, včetně fyzických kontrol, kontrol pracovníků a procedurálních kontrol,
·minimální požadavky na postupy technické bezpečnosti TLM, včetně počítačových bezpečnostních kontrol, kontrol bezpečnosti sítě a technických kontrol kryptografického modulu,
·minimální požadavky na provozní postupy TLM, včetně registrace nových certifikátů kořenových CA, dočasné nebo trvalé deregistrace stávajících zařazených kořenových CA a zveřejňování a distribuce aktualizací ECTL,
·profil ECTL včetně všech povinných a nepovinných datových polí v ECTL, kryptografických algoritmů, které mají být použity, přesného formátu ECTL a doporučení pro zpracování ECTL,
·správa životního cyklu certifikátu ECTL, včetně distribuce certifikátů ECTL, jejich aktivace, konec platnosti a odvolání;
·v případě potřeby správa odvolání důvěry kořenových CA.
Vzhledem k tomu, že důvěryhodnost ECTL nezávisí pouze na ECTL samotném, ale do značné míry také na kořenových CA, z nichž se skládá PKI, a jejich podřízených CA, stanoví tato politika rovněž minimální požadavky, které jsou povinné pro všechny zúčastněné CA (kořenové CA a podřízené CA). Jedná se o tyto požadavky:
·identifikace a autentizace hlavních účastníků, kteří získávají role PKI (např. bezpečnostní referent, referent pro ochranu soukromí, bezpečnostní správce, správce adresáře a konečný uživatel), včetně popisu povinností, odpovědností, závazků a privilegií spojených s každou rolí,
·správa klíčů, včetně přijatelných a povinných algoritmů pro podepisování certifikátů a dat a dob platnosti certifikátů,
·minimální požadavky na místní bezpečnostní postupy, včetně fyzických kontrol, kontrol pracovníků a procedurálních kontrol,
·minimální požadavky na postupy technické bezpečnosti, jako jsou kontroly bezpečnosti počítačů, kontroly bezpečnosti sítě a technické kontroly kryptografického modulu,
·minimální požadavky na provozní postupy CA, EA, AA a koncových subjektů, včetně aspektů registrace, deregistrace (tj. vyřazení ze seznamu), odvolání, ohrožení klíče, důvodného odmítnutí, aktualizace certifikátu, auditních postupů a nezveřejnění soukromých informací,
·profil certifikátu a CRL, včetně formátů, přijatelných algoritmů, povinných a nepovinných datových polí a jejich platných rozsahů hodnot a toho, jak mají ověřovatelé certifikáty zpracovávat,
·pravidelné sledování, hlášení, varování a obnovení povinností subjektů C-ITS modelu služeb vytvářejících důvěru za účelem zřízení bezpečného provozu, a to i v případech pochybení.
Kromě těchto minimálních požadavků mohou subjekty, které provozují kořenové CA a podřízené CA, rozhodovat o svých vlastních dodatečných požadavcích a stanovovat je v příslušných prohlášeních o certifikačním postupu (CPS) za předpokladu, že nejsou v rozporu s požadavky stanovenými v certifikační politice. Podrobnosti o auditu a zveřejňování CPS viz oddíl 1.5.
Certifikační politika stanoví rovněž účely, pro které mohou být kořenové CA, podřízené CA a jimi vydané certifikáty použity. Stanoví odpovědnosti, které na sebe bere:
·správce seznamu důvěryhodných subjektů (TLM),
·každá kořenová CA, jejíž certifikáty jsou uvedeny v ECTL,
·podřízené CA kořenové CA (EA a AA),
·každý člen nebo organizace odpovědná za jeden ze subjektů C-ITS modelu služeb vytvářejících důvěru nebo jej provozující.
Certifikační politika (CP) definuje rovněž závazné povinnosti vztahující se na:
·správce seznamu důvěryhodných subjektů (TLM),
·každou kořenovou CA, jejíž certifikáty jsou uvedeny v ECTL,
·každou podřízenou CA certifikovanou kořenovou CA,
·všechny koncové subjekty,
·každou členskou organizaci odpovědnou za jeden ze subjektů C-ITS modelu služeb vytvářejících důvěru nebo jej provozující.
CP také stanoví požadavky, pokud jde o dokumentaci omezení odpovědností a povinností v prohlášení o certifikačním postupu (CPS) každé kořenové CA, jejíž certifikáty jsou uvedeny v ECTL.
Tato CP je v souladu s certifikační politikou a rámcem certifikačních postupů přijatými Komisí pro technickou stránku internetu (IETF) [3].
1.2.Definice a zkratky
Platí definice uvedené v [2], [3] a [4].
AA
|
autorizační autorita (authorisation authority)
|
AT
|
potvrzení o autorizaci (authorisation ticket)
|
CA
|
certifikační autorita (certification authority)
|
CP
|
certifikační politika (certificate policy)
|
CPA
|
orgán pro certifikační politiku C-ITS (C-ITS certificate policy authority)
|
CPOC
|
kontaktní místo C-ITS (C-ITS point of contact)
|
CPS
|
prohlášení o certifikačním postupu (certificate practice statement)
|
CRL
|
seznam odvolaných certifikátů (certificate revocation list)
|
EA
|
registrující autorita (enrolment authority)
|
EC
|
oprávnění k registraci (enrolment credential)
|
ECIES
|
integrovaný šifrovací systém pomocí eliptických křivek (elliptic curve integrated encryption scheme)
|
EE
|
koncový subjekt (tj. stanice C-ITS) (end-entity (i.e. C-ITS station))
|
ECTL
|
evropský seznam důvěryhodných certifikátů (European certificate trust list)
|
EU CCMS
|
systém správy bezpečnostních oprávnění pro EU C-ITS (EU C-ITS security credential management systém)
|
GDPR
|
obecné nařízení o ochraně údajů (General Data Protection Regulation)
|
HSM
|
hardwarový bezpečnostní modul (Hardware security module)
|
PKI
|
infrastruktura veřejných klíčů (public key infrastructure)
|
RA
|
registrační autorita (registration authority)
|
podřízená CA
|
EA a AA
|
TLM
|
správce seznamu důvěryhodných entit (trust list manager)
|
Glosář
žadatel
|
Fyzická nebo právnická osoba žádající o certifikát (příp. jeho obnovení). Po vytvoření iniciačního certifikátu (inicializaci) se žadatel označuje jako účastník.
U certifikátů vydaných koncovým subjektům je účastníkem (žadatelem o certifikát) osoba, která ovládá nebo provozuje/udržuje koncový subjekt, pro který je certifikát vydán, a to i v případě, že vlastní žádost o certifikát odesílá koncový subjekt.
|
autorizační autorita
|
Pojem „autorizační autorita“ (AA) odkazuje v tomto dokumentu nejen na konkrétní funkci AA, ale také na právní a/nebo provozní subjekt, který ji spravuje.
|
certifikační autorita
|
Kořenová certifikační autorita, registrující autorita a autorizační autorita jsou souhrnně označovány jako certifikační autorita (CA).
|
C-ITS model služeb vytvářejících důvěru
|
C-ITS model služeb vytvářejících důvěru slouží k navázání důvěryhodného vztahu mezi stanicemi C-ITS. Je implementován za použití PKI, která se skládá z CA, CPOC, TLM, EA, AA a zabezpečené sítě.
|
kryptoagilita
|
Schopnost subjektů C-ITS modelu služeb vytvářejících důvěru přizpůsobit CP měnícím se prostředím nebo novým budoucím požadavkům, např. změnou kryptografických algoritmů a délkou klíčů v průběhu času.
|
kryptografický modul
|
Zabezpečený hardwarový prvek, v němž jsou generovány a/nebo uloženy kryptografické klíče, generována náhodná čísla a podepisována nebo šifrována data.
|
registrující autorita
|
Pojem „registrující autorita“ (EA) odkazuje v tomto dokumentu nejen na konkrétní funkci EA, ale také na právní a/nebo provozní subjekt, který ji spravuje.
|
účastníci PKI
|
Subjekty C-ITS modelu služeb vytvářejících důvěru, tj. TLM, kořenové CA, EA, AA a stanice C-ITS.
|
změna klíče
|
|
úložiště
|
Úložiště používané k ukládání certifikátů poskytnutých subjekty C-ITS modelu služeb vytvářejících důvěru a informací o těchto certifikátech, jak je definováno v oddíle 2.3.
|
kořenová certifikační autorita
|
Pojem „kořenová certifikační autorita“ (CA) odkazuje v tomto dokumentu nejen na konkrétní funkci CA, ale také na právní a/nebo provozní subjekt, který ji spravuje.
|
subjekt
|
Fyzická osoba, zařízení, systém, jednotka nebo právnická osoba identifikovaná v certifikátu jako subjekt, tj. buď účastník, nebo zařízení účastníkem ovládané a provozované.
|
účastník
|
Fyzická nebo právnická osoba, které je vydán certifikát a která je právně vázána smlouvou o účastnictví nebo všeobecnými podmínkami použití.
|
účastnická smlouva
|
Smlouva mezi CA a žadatelem/účastníkem, která specifikuje práva a povinnosti smluvních stran.
|
1.3.Účastníci PKI
1.3.1.Úvod
Účastníci PKI hrají v PKI roli definovanou touto politikou. Není-li to výslovně zakázáno, může účastník převzít současně několik rolí. Může mu být zakázáno převzít ve stejném čase konkrétní role, aby nedocházelo ke střetům zájmů nebo aby bylo zajištěno oddělení funkcí.
Účastníci mohou části své role rovněž přenést na jiné subjekty v rámci smlouvy o poskytování služeb. Pokud se například informace o stavu odvolání poskytují pomocí CRL, CA je rovněž vydavatelem CRL, odpovědnost za vydání CRL však může přenést na jiný subjekt.
Role PKI sestávají z:
·autoritativních rolí, tj. každá role je jedinečně vytvořená instance;
·provozních rolí, tj. rolí, jejichž instanci lze vytvořit v jednom nebo více subjektech.
Například kořenová CA může být implementována podnikatelským subjektem, zájmovou skupinou, národní organizací a/nebo evropskou organizací.
Obrázek 1 znázorňuje architekturu C-ITS modelu služeb vytvářejících důvěru založenou na [2]. Architektura je stručně popsána zde, hlavní prvky jsou však podrobněji popsány v oddílech 1.3.2 až 1.3.6.
CPA jmenuje TLM, což je tudíž důvěryhodný subjekt pro všechny účastníky PKI. CPA schvaluje fungování kořenové CA a potvrzuje, že TLM může důvěřovat kořenové CA (kořenovým CA). TLM vydává ECTL, jenž poskytuje všem účastníkům PKI důvěru ve schválené kořenové CA. Kořenová CA vydává certifikáty autoritám EA a AA, čímž zajišťuje důvěru v jejich fungování. EA vydává certifikáty o registraci vysílajícím a předávajícím stanicím C-ITS (jako koncovým subjektům), čímž zajišťuje důvěru v jejich fungování. AA vydává potvrzení o autorizaci (AT) stanicím C-ITS na základě důvěry v EA.
Přijímající a předávající stanice C-ITS (jako předávající strana) může důvěřovat ostatním stanicím C-ITS, protože AT jsou vydávána autoritou AA, které důvěřuje kořenová CA, které důvěřují TLM a CPA.
Obrázek 1 popisuje pouze úroveň kořenové CA C-ITS modelu služeb vytvářejících důvěru. Podrobnosti o nižších vrstvách jsou uvedeny v následujících oddílech této CP nebo v CPS konkrétních kořenových CA.
Obrázek 2 znázorňuje přehled informačních toků mezi účastníky PKI. Zelené tečky označují toky, které vyžadují komunikace stroj-stroj. Informační toky v červené barvě mají definované bezpečnostní požadavky.
C-ITS model služeb vytvářejících důvěru je založen na architektuře několika kořenových CA, kde jsou certifikáty kořenové CA předávány pravidelně (jak je stanoveno níže) do centrálního kontaktního místa (CPOC) prostřednictvím zabezpečeného protokolu (např. spojovacích certifikátů) definovaného CPOC.
Kořenovou CA může provozovat státní nebo soukromá organizace. Architektura C-ITS modelu služeb vytvářejících důvěru obsahuje alespoň jednu kořenovou CA (kořenová CA EU se stejnou úrovní jako ostatní kořenové CA). Na kořenovou CA EU delegují všechny subjekty, které se účastní C-ITS modelu služeb vytvářejících důvěru a které nechtějí zřídit svou vlastní kořenovou CA. CPOC přenáší přijaté certifikáty kořenové CA na TLM, který odpovídá za shromažďování a podepisování seznamu certifikátů kořenových CA a za jejich zaslání zpět do CPOC, které je zpřístupní veřejnosti (viz níže).
Vztahy důvěry mezi subjekty v C-ITS modelu služeb vytvářejících důvěru jsou popsány na následujících obrázcích, tabulkách a oddílech.
Obrázek 1: Architektura C-ITS modelu služeb vytvářejících důvěru
Obrázek 2: Toky informací v C-ITS modelu služeb vytvářejících důvěru
ID toku
|
Od
|
K
|
Obsah
|
Odkaz
|
(1).
|
CPA
|
TLM
|
schválení žádosti kořenové CA
|
8
|
(2).
|
CPA
|
TLM
|
informace o odvolání kořenové CA
|
8.5
|
(3).
|
CPA
|
kořenová CA
|
aktualizace CP
|
1.5
|
(4).
|
CPA
|
kořenová CA
|
schválení/zamítnutí formuláře žádosti kořenové CA nebo změn žádosti CPS nebo auditního procesu
|
8.5, 8.6
|
(5).
|
TLM
|
CPA
|
oznámení o změně ECTL
|
4, 5.8.1
|
(6).
|
TLM
|
CPOC
|
certifikát TLM
|
4.4.2
|
(7).
|
TLM
|
CPOC
|
ECTL
|
4.4.2
|
(8).
|
CPOC
|
TLM
|
informace o certifikátu kořenové CA
|
4.3.1.1
|
(9).
|
CPOC
|
TLM
|
odvolání certifikátu kořenové CA
|
7.3
|
(10).
|
CPOC
|
všechny koncové subjekty
|
certifikát TLM
|
4.4.2
|
(11).
|
kořenová CA
|
CPOC
|
informace o certifikátu kořenové CA
|
4.3.1.1
|
(12).
|
kořenová CA
|
CPOC
|
odvolání certifikátu kořenové CA
|
7.3
|
(13).
|
kořenová CA
|
auditor
|
pokyn k auditu
|
8
|
(14).
|
kořenová CA
|
CPA
|
formulář žádosti kořenové CA – počáteční žádost
|
4.1.2.1
|
(15).
|
kořenová CA
|
CPA
|
formulář žádosti kořenové CA – změny CPS
|
1.5.1
|
(16).
|
kořenová CA
|
CPA
|
formulář žádosti kořenové CA – zpráva o auditu
|
8.6
|
(17).
|
kořenová CA
|
CPA
|
zprávy o incidentu kořenové CA, včetně odvolání podřízené CA (EA, AA)
|
příloha III, 7.3.1
|
(18).
|
kořenová CA
|
EA
|
odpověď na certifikát EA
|
4.2.2.3
|
(19).
|
kořenová CA
|
AA
|
odpověď na certifikát AA
|
4.2.2.3
|
(20).
|
kořenová CA
|
vše
|
certifikát EA/AA, CRL
|
4.4.2
|
(21).
|
EA
|
kořenová CA
|
žádost o certifikát EA
|
4.2.2.3
|
(22).
|
EA
|
stanice C-ITS
|
odpověď na oprávnění k registraci
|
4.3.1.4
|
(23).
|
EA
|
AA
|
odpověď na autorizaci
|
4.2.2.5
|
(24).
|
AA
|
kořenová CA
|
žádost o certifikát AA
|
4.2.2.3
|
(25).
|
AA
|
EA
|
žádost o autorizaci
|
4.2.2.5
|
(26).
|
AA
|
stanice C-ITS
|
odpověď na potvrzení o autorizaci
|
4.3.1.5
|
(27).
|
EA
|
kořenová CA
|
předložení žádosti
|
4.1.2.3
|
(28).
|
AA
|
kořenová CA
|
předložení žádosti
|
4.1.2.3
|
(29).
|
kořenová CA
|
EA
|
odpověď
|
4.12 a 4.2.1
|
(30).
|
kořenová CA
|
AA
|
odpověď
|
4.12 a 4.2.1
|
(31).
|
stanice C-ITS
|
EA
|
žádost o oprávnění k registraci
|
4.2.2.4
|
(32).
|
stanice C-ITS
|
AA
|
žádost o potvrzení o autorizaci
|
4.2.2.5
|
(33).
|
výrobce / provozovatel
|
EA
|
registrace
|
4.2.1.4
|
(34).
|
výrobce / provozovatel
|
EA
|
deaktivace
|
7.3
|
(35).
|
EA
|
výrobce / provozovatel
|
odpověď
|
4.2.1.4
|
(36).
|
auditor
|
kořenová CA
|
zpráva
|
8.1
|
(37).
|
vše
|
CPA
|
žádosti o změnu CP
|
1.5
|
(38).
|
TLM
|
CPA
|
formulář žádosti
|
4.1.2.2
|
(39).
|
CPA
|
TLM
|
schválení/zamítnutí
|
4.1.2.2
|
(40).
|
TLM
|
CPA
|
zpráva o auditu
|
4.1.2.2
|
Tabulka 1:
Podrobný popis toků informací v C-ITS modelu služeb vytvářejících důvěru
1.3.2.Orgán pro certifikační politiku C-ITS
1)Orgán pro certifikační politiku C-ITS (CPA) se skládá ze zástupců veřejných a soukromých zúčastněných stran (např. členských států, výrobců vozidel atd.), které se účastní C-ITS modelu služeb vytvářejících důvěru. Je odpovědný za dvě dílčí role:
1)řízení certifikační politiky, včetně:
·schvalování stávající CP a budoucích žádostí o změnu CP;
·rozhodování o přezkumu žádostí o změnu CP a o doporučeních předložených jinými účastníky nebo subjekty PKI;
·rozhodování o vydání nových verzí CP;
2)správu autorizací PKI, včetně:
·definování schvalovacích postupů CPS a auditu CA (společně označovaných jako „schvalovací postupy CA“), rozhodování o nich a jejich zveřejňování;
·autorizace provozu a pravidelného podávání zpráv CPOC;
·autorizace provozu a pravidelného podávání zpráv TLM;
·schvalování CPS kořenové CA, je-li v souladu se společnou a platnou CP;
·kontrola zpráv o auditu akreditovaných auditorů PKI pro všechny kořenové CA;
·informování TLM o seznamu schválených nebo neschválených kořenových CA a jejich certifikátů na základě obdržených zpráv o schválení kořenových CA a pravidelných zpráv o činnosti.
2)Autorizovaný zástupce CPA odpovídá za autentizaci autorizovaného zástupce TLM a za schválení formuláře žádosti procesu registrace TLM. CPA odpovídá za autorizaci provozu TLM, jak je uvedeno v tomto oddíle.
1.3.3.Správce seznamu důvěryhodných subjektů
3)Správce seznamu důvěryhodných subjektů (TLM) je jediný subjekt jmenovaný CPA.
4)TLM odpovídá za:
·fungování ECTL v souladu se společnou platnou CP a pravidelnou zprávou o činnosti CPA, pokud jde o celkové bezpečné fungování CITS modelu služeb vytvářejících důvěru,
·přijetí certifikátů kořenových CA od CPOC,
·zahrnutí certifikátů kořenových CA do ECTL či jejich vyloučení na základě oznámení CPA,
·podepisování ECTL,
·pravidelný a včasný přenos ECTL na CPOC.
1.3.4.Akreditovaný auditor PKI
5)Akreditovaný auditor PKI odpovídá za:
·provádění nebo organizování auditů kořenových CA, TLM a podřízených CA;
·distribuci zprávy o auditu (z počátečního nebo pravidelného auditu) CPA v souladu s požadavky v oddíle 8. Zpráva o auditu musí zahrnovat doporučení akreditovaných auditorů PKI,
·oznámení subjektu řídícímu kořenovou CA o úspěšném nebo neúspěšném provedení počátečního nebo pravidelného auditu podřízených CA;
·posouzení souladu CPS s touto CP.
1.3.5.Kontaktní místo C-ITS (CPOC)
6)Kontaktní místo C-ITS (CPOC) je jediný subjekt jmenovaný CPA. Autorizovaný zástupce CPA odpovídá za autentizaci autorizovaného zástupce CPOC a za schválení formuláře žádosti procesu registrace CPOC. CPA odpovídá za autorizaci provozu CPOC, jak je uvedeno v tomto oddíle.
7)CPOC odpovídá za:
·zřízení účinné a rychlé bezpečné komunikační výměny mezi všemi subjekty C-ITS modelu služeb vytvářejících důvěru a přispívání do ní;
·přezkum žádostí o procedurální změnu a doporučení předložených ostatními účastníky modelu služeb vytvářejících důvěru (např. kořenovými CA);
·předávání certifikátů kořenových CA do TLM;
·zveřejňování společného „trust anchor“ (aktuální veřejný klíč a spojovací certifikát TLM);
·zveřejnění ECTL.
Úplné údaje o ECTL jsou uvedeny v oddíle 7.
1.3.6.Provozní role
8)Provozní roli, jak je definována v RFC 3647, hrají tyto subjekty vymezené v [2]:
Funkční prvek
|
Role PKI ([3] a [4])
|
Podrobná role ([2])
|
kořenová certifikační autorita
|
CA/RA (registrační autorita)
|
Poskytuje EA a AA doklad, že může vydávat EC nebo AT.
|
registrující autorita
|
účastník kořenové CA / subjekt certifikátu EA
CA/RA
|
Autentizuje stanici C-ITS a uděluje jí přístup ke komunikacím ITS
|
autorizační autorita
|
účastník kořenové CA / subjekt certifikátu AA
CA/RA
|
Poskytuje stanici C-ITS autoritativní doklad, že může používat konkrétní služby ITS.
|
zasílající stanice C-ITS
|
subjekt certifikátu koncového subjektu (EE) (EC)
|
Získává od EA práva k přístupu ke komunikacím ITS.
Vyjednává s AA práva na používání služeb ITS.
Vysílá zprávy jednoduchým přeposláním a předáváním.
|
předávající (přeposílající) stanice C-ITS
|
předávací strana / subjekt certifikátu EE
|
Přijímá vysílanou zprávu od zasílající stanice C-ITS a předává ji dle potřeby přijímající stanici C-ITS
|
přijímající stanice C-ITS
|
předávající strana
|
Přijímá vysílanou zprávu od zasílající nebo předávající stanice C-ITS
|
výrobce
|
účastník EA
|
Instaluje do stanice C-ITS během výroby informace nezbytné pro řízení bezpečnosti
|
provozovatel
|
účastník EA / AA
|
Instaluje a aktualizuje ve stanici C-ITS během provozu nezbytné informace pro řízení bezpečnosti
|
Tabulka 2: Provozní role
Pozn.: V souladu s [4] se v této CP používají odlišné pojmy pro „účastníka“, který uzavírá smlouvu s CA na vydání certifikátů, a „subjekt“, na který se certifikát vztahuje. „Účastníky“ jsou všechny subjekty, které mají smluvní vztah s CA. „Subjekty“ jsou subjekty, na něž se certifikát vztahuje. EA/AA jsou účastníky a subjekty kořenové CA a mohou žádat o certifikáty EA/AA. Stanice C-ITS jsou subjekty a mohou žádat o certifikáty koncového subjektu.
9)Registrační autority:
EA má plnit úlohu registrační autority pro koncové subjekty. Registrovat nové koncové subjekty (stanice C-ITS) v EA může pouze autentizovaný a autorizovaný účastník. Příslušné kořenové CA mají plnit úlohu registračních autorit pro EA a AA.
1.4.Použití certifikátu
1.4.1.Příslušné oblasti použití
10)Certifikáty vydané podle aktuální CP jsou určeny k validaci digitálních podpisů v oblasti komunikace kooperativních ITS v souladu s referenční architekturou v [2].
11)Profily certifikátů v [5] určují použití certifikátů pro TLM, kořenové CA, EA, AA a koncové subjekty.
1.4.2.Rozsah odpovědnosti
12)Certifikáty nejsou určeny ani povoleny k použití:
·za okolností, které porušují nebo narušují platný zákon, předpis (např. GDPR), vyhlášku nebo nařízení vlády,
·za okolností, které porušují nebo narušují práva jiných osob,
·v rozporu s touto CP nebo příslušnou účastnickou smlouvou,
·za všech okolností, za kterých by jejich použití mohlo přímo vést k úmrtí, ke zranění osob nebo k závažným škodám na životním prostředí (např. při provozu jaderných zařízení, letecké navigace nebo komunikace či systémů kontroly zbraní),
·za okolností, které jsou v rozporu s celkovými cíli větší bezpečnosti silničního provozu a efektivnější silniční dopravy v Evropě.
1.5.Správa certifikační politiky
1.5.1.Aktualizace CPS certifikačních autorit uvedených v ECTL
13)Každá kořenová CA uvedená v ECTL zveřejní svou vlastní CPS, která musí být v souladu s touto politikou. Kořenová CA může doplnit další požadavky, musí však zajistit, aby byly vždy splněny všechny požadavky této CP.
14)Každá kořenová CA uvedená v ECTL zavede pro svůj dokument CPS vhodný postup změn. Klíčové vlastnosti postupu změn musí být zdokumentovány ve veřejné části CPS.
15)Postup změn musí zajistit, aby všechny změny této CP byly pečlivě zanalyzovány, a pokud to bude potřeba pro soulad se změněnou CP, aby CPS bylo aktualizováno v časovém rámci stanoveném v kroku implementace postupu změny CP. Proces změny musí zejména zahrnovat postupy změny v nouzi, který zajistí včasnou implementaci změn CP souvisejících s bezpečností.
16)Postup změn zahrnuje pro všechny změny CPS vhodná opatření k ověření souladu s CP. Veškeré změny CPS musí být jasně zdokumentovány. Před implementací nové verze CPS musí být její soulad s CP potvrzen akreditovaným auditorem PKI.
17)Kořenová CA oznámí CPA každou změnu provedenou v CPS spolu s alespoň těmito informacemi:
·přesný popis změny,
·odůvodnění změny,
·zpráva akreditovaného auditora PKI, která potvrzuje soulad s CP,
·kontaktní údaje osoby odpovědné za CPS,
·plánovaný časový rámec provádění.
1.5.2.Schvalovací postupy CPS
18)Před zahájením činnosti předloží potenciální kořenová CA svou CPS akreditovanému auditorovi PKI jako součást pokynu k auditu souladu (tok 13) a CPA ke schválení (tok 15).
19)Kořenová CA předloží změny ve své CPS akreditovanému auditorovi PKI jako součást pokynu k auditu souladu (tok 13) a CPA ke schválení (tok 15) před tím, než tyto změny nabudou účinku.
20)EA/AA předloží svůj CPS nebo změny CPS kořenové CA. Kořenová CA může od vnitrostátního orgánu nebo soukromého subjektu odpovědného za schvalování EA/AA, jak je definováno v oddíle 4.1.2 a 8, objednat certifikát o shodě.
21)Akreditovaný auditor PKI posoudí CPS v souladu s oddílem 8.
22)Akreditovaný auditor PKI sdělí výsledky posouzení CPS v rámci zprávy o auditu, jak je stanoveno v oddíle 8.1. CPS bude přijato nebo zamítnuto v rámci přijetí zprávy o auditu, jak je uvedeno v oddílech 8.5 a 8.6.
2.Povinnosti v oblasti zveřejňování a úložišť
2.1.Metody zveřejňování informací o certifikátech
23)Informace o certifikátu lze podle oddílu 2.5 zveřejňovat:
·pravidelně čili periodicky, nebo
·jako odpověď na žádost jednoho z účastnících se subjektů.
V každém z případů platí různé stupně naléhavosti zveřejnění, a tudíž i různé harmonogramy, ale subjekty musí být připraveny na obě metody.
24)Pravidelné zveřejňování informací o certifikátu umožňuje určit maximální lhůtu, v níž jsou informace o certifikátu aktualizovány pro všechny uzly sítě C-ITS. Frekvence zveřejňování všech informací o certifikátu je stanovena v oddíle 2.2.
25)Na žádost subjektů účastnících se sítě C-ITS může kterýkoliv z účastníků kdykoli začít zveřejňovat informace z certifikátu a – v závislosti na svém stavu – požádat o aktuální soubor informací o certifikátu, aby se z něj stal plně důvěryhodný uzel sítě C-ITS. Účelem takového zveřejnění je především podat subjektům aktuální informace o celkovém aktuálním stavu informací o certifikátu v síti a umožnit jim, aby do příštího pravidelného zveřejnění informací mohly spolu komunikovat na základě důvěry.
26)Jedna kořenová CA může rovněž kdykoli zahájit zveřejňování informací o certifikátech tím, že zašle aktualizovaný soubor certifikátů všem „zapsaným členům“ sítě C-ITS, kteří jsou pravidelnými příjemci těchto informací. To podporuje fungování certifikačních autorit a umožňuje jim, aby oslovovaly členy mezi pravidelnými a plánovanými daty zveřejňování certifikátů.
27)Oddíl 2.5 stanoví mechanismus a všechny postupy pro zveřejňování certifikátů kořenových CA a ECTL.
28)CPOC zveřejní certifikáty kořenových CA (uvedené v ECTL a určené pro veřejnou potřebu), certifikát TLM a ECTL, které vydává.
29)Kořenové CA zveřejní své certifikáty EA/AA a CRL jsou schopny podporovat všechny tři zde uvedené mechanismy pro jejich zveřejňování svým zapsaným členům a spoléhajícím se stranám a přijmou veškerá nezbytná opatření k zajištění bezpečného přenosu, jak je uvedeno v oddíle 4.
2.2.Čas nebo četnost zveřejňování
30)Požadavky na harmonogram zveřejňování pro certifikáty a CRL musí být stanoveny s ohledem na různé omezující faktory jednotných uzlů C-ITS, přičemž celkovým cílem je provozování „důvěryhodné sítě“ a zveřejňování aktualizací pro všechny zapojené stanice C-ITS co nejrychleji.
·Pro pravidelné zveřejňování aktualizovaných informací o certifikátech (např. změn ve složení ECTL nebo CRL) se pro bezpečné fungování sítě C-ITS požaduje maximální doba tří měsíců.
·Kořenové CA zveřejní své certifikáty CA a CRL co nejdříve po jejich vydání.
·Pro zveřejnění CRL se použije úložiště kořenové CA.
CPS kromě toho stanoví pro každou CA dobu, během které bude certifikát zveřejněn poté, co jej CA vydá.
Tento oddíl stanoví pouze čas nebo četnost pravidelného zveřejňování. V souladu s požadavky v tomto dokumentu musí být implementovány prostředky propojitelnosti pro aktualizaci stanice C-ITS o ECTL a CRL během jednoho týdne po jejich zveřejnění (za normálních provozních podmínek, např. s celulárním pokrytím, vozidlo za skutečného provozu atd.).
2.3.Úložiště
31)Požadavky na strukturu úložiště pro ukládání certifikátů a na to, jaké informace subjekty sítě C-ITS poskytují, jsou pro jednotlivé subjekty tyto:
·obecně by každá kořenová CA měla používat úložiště svých vlastních v současnosti aktivních informací o certifikátech EA/AA a CRL s cílem zveřejňovat certifikáty pro ostatní účastníky PKI (např. adresářové služby založené na LDAP). Úložiště každé kořenové CA podporuje všechny požadované kontroly přístupu (oddíl 2.4) a časy přenosu (oddíl 2.2) pro každou metodu distribuce informací týkajících se C-ITS,
·úložiště TLM (kam se ukládají například ECTL a certifikáty TLM zveřejněné CPOC) by mělo být založeno na mechanismu zveřejňování, který dokáže zajistit časy přenosu stanovené v oddíle 2.2 pro každou metodu distribuce.
Požadavky AA nejsou definovány, ale musí podporovat stejné úrovně bezpečnosti jako ostatní subjekty a tyto úrovně musí být deklarovány v jejich CPS.
2.4.Kontroly přístupu do úložišť
32)Požadavky na kontrolu přístupu informací o certifikátech do úložišť musí splňovat alespoň obecné normy pro bezpečné nakládání s informacemi stanovené v normě ISO/IEC 27001 a požadavky v oddíle 4. Kromě toho musí odrážet procesní potřeby bezpečnosti, jež mají být stanoveny pro jednotlivé kroky procesu při zveřejňování informací o certifikátu.
·To zahrnuje implementaci úložiště certifikátů TLM a ECTL v TLM/CPOC. Každá CA nebo provozovatel úložiště implementuje u všech subjektů C-ITS a externích stran kontroly přístupu pro nejméně tři různé úrovně (např. veřejnou, omezenou na subjekty C-ITS, úroveň kořenové CA), aby neoprávněným subjektům zabránil přidávat záznamy do úložiště, měnit je nebo mazat.
·Přesné mechanismy kontroly přístupu jednotlivého subjektu by měly být součástí příslušného CPS.
·Pro každou kořenovou CA musí úložiště EA a AA splňovat stejné požadavky na postupy kontroly přístupu bez ohledu na místo nebo smluvní vztah k poskytovateli služeb, který úložiště provozuje.
Jako výchozí bod pro úroveň kontroly přístupu by každá kořenová CA nebo provozovatel úložiště měl poskytnout alespoň tři různé úrovně (např. veřejnou, omezenou na subjekty C-ITS, úroveň kořenových CA).
2.5.Zveřejňování informací o certifikátu
2.5.1.Zveřejňování informací o certifikátu správcem seznamu důvěryhodných subjektů
33)Správce seznamu důvěryhodných subjektů (TLM) v evropské společné oblasti důvěry C-ITS zveřejní prostřednictvím CPOC tyto informace:
·všechny aktuálně platné certifikáty TLM pro další provozní období (aktuální a spojovací certifikát, jsou-li k dispozici),
·informace o přístupovém bodu k úložišti CPOC s cílem poskytnout podepsaný seznam kořenových CA (ECTL),
·obecné informační místo pro ECTL a zavádění C-ITS.
2.5.2.Zveřejňování informací o certifikátu certifikačními autoritami
34)Kořenové CA v evropské společné oblasti důvěry C-ITS zveřejňují tyto informace:
·vydané (v současnosti platné) certifikáty kořenových CA (aktuální a správně překlíčované certifikáty, včetně spojovacího certifikátu) v úložišti uvedeném v oddíle 2.3,
·všechny platné subjekty EA/AA s identifikačním kódem jejich provozovatele a plánovanou dobou provozu,
·vydané certifikáty CA v úložištích uvedených v oddíle 2.3,
·CRL pro všechny odvolané certifikáty CA, které se vztahují na jejich podřízené EA a AA,
·informace o přístupu k CRL a informacím o CA konkrétní kořenové CA.
Veškeré informace o certifikátech musí být kategorizovány v souladu se třemi úrovněmi důvěrnosti a dokumenty pro širokou veřejnost musí být bez omezení veřejně dostupné.
3.Identifikace a autentizace
3.1.Pojmenovávání
3.1.1.Druhy názvu
3.1.1.1.Názvy TLM, kořenových CA, EA, AA
35)Název v certifikátu TLM obsahuje jediný atribut názvu subjektu (subject_name) s vyhrazenou hodnotou „EU_TLM“.
36)Název kořenových CA se skládá z jediného atributu subject_name, jehož hodnotu přiděluje CPA. Jedinečnost názvů je výlučnou odpovědností CPA a TLM vede rejstřík názvů kořenových CA na základě oznámení CPA (schválení, odvolání/odstranění kořenové CA). Názvy subjektů v certifikátech jsou omezeny na 32 bajtů. Každá kořenová CA navrhuje svůj název CPA ve formuláři žádosti (tok 14). Za kontrolu jedinečnosti názvu odpovídá CPA. Není-li název jedinečný, žádost se zamítne (tok 4).
37)Název v každém certifikátu EA/AA může sestávat z jediného atributu subject_name s hodnotou vygenerovanou vydavatelem certifikátu. Jedinečnost názvů je výhradní odpovědností vydávající kořenové CA.
38)Certifikáty EA a AA nesmějí používat název větší než 32 bajtů, protože atribut subject_name v certifikátech je omezen na 32 bajtů.
39)Potvrzení o autorizaci (AT) nesmí obsahovat název.
3.1.1.2.Názvy koncových subjektů
40)Každé stanici C-ITS se přidělí dva druhy jedinečného identifikátoru:
·kanonický identifikátor, který je uložen při původní registraci stanice C-ITS na odpovědnost výrobce. Obsahuje dílčí řetězec, který identifikuje výrobce nebo provozovatele, aby tento identifikátor mohl být jedinečný,
·atribut „subject_name“, jenž může být součástí oprávnění (EC) stanice C-ITS, v odpovědnosti EA.
3.1.1.3.Identifikace certifikátů
41)Certifikáty řídící se formátem v [5] se identifikují výpočtem hodnoty HashedI8, jak je definováno v [5].
3.1.2.Požadavek na smysluplnost názvů
Není stanoveno.
3.1.3.Anonymita a pseudonymita koncových subjektů
42)AA zajistí, aby byla zřízena pseudonymita stanice C-ITS tím, že stanice C-ITS poskytne AT, které neobsahují žádné názvy ani informace, které by subjekt mohly spojovat s jeho skutečnou identitou.
3.1.4.Pravidla pro výklad různých forem názvů
Není stanoveno.
3.1.5.Jedinečnost názvů
43)Názvy TLM, kořenových CA, EA, AA a kanonické identifikátory stanic C-ITS musí být jedinečné.
44)TLM zajistí v registračním procesu dané kořenové CA v ECTL, aby jeho identifikátor certifikátu (HashedI8) byl jedinečný. Kořenová CA zajistí v procesu vydávání, aby identifikátor certifikátu (HashedI8) každé podřízené CA byl jedinečný.
45)HashedI8 v oprávnění (EC) musí být v rámci vydávající CA jedinečný. HashedId8 v potvrzení o autorizaci (AT) nemusí být jedinečný.
3.2.Počáteční potvrzení totožnosti
3.2.1.Metoda prokazování vlastnictví soukromého klíče
46)Kořenová CA prokáže, že oprávněně drží soukromý klíč odpovídající veřejnému klíči v samopodepsaném certifikátu. CPOC tento důkaz zkontroluje.
47)EA/AA prokáže, že oprávněně drží soukromý klíč odpovídající veřejnému klíči, který má být uveden v certifikátu. Kořenová CA tento důkaz zkontroluje.
48)Vlastnictví nového soukromého klíče (pro změnu klíče) se prokazuje podpisem žádosti s novým soukromým klíčem (vnitřním podpisem), načež následuje generování vnějšího podpisu podepsané žádosti se současným platným soukromým klíčem (aby byla zaručena autenticita žádosti). Žadatel předloží podepsanou žádost o certifikát vydávající CA prostřednictvím zabezpečené komunikace. Vydávající CA ověří, že žadatelův digitální podpis ve zprávě o žádosti byl vytvořen s použitím soukromého klíče odpovídajícího veřejnému klíči připojenému k žádosti o certifikát. Kořenová CA ve svém CPS upřesní, kterou žádost o certifikát a odpovědi podporuje.
3.2.2.Autentizace totožnosti organizace
3.2.2.1.Autentizace totožnosti organizace kořenových CA
49)Ve formuláři žádosti pro CPA (tj. tok 14) uvede kořenová CA totožnost organizace a informace o registraci složené z:
·názvu organizace,
·poštovní adresy,
·e-mailové adresy,
·jména fyzické kontaktní osoby v organizaci,
·telefonního čísla,
·digitální otisk (tj. SHA 256 hashvalue) certifikátu kořenové CA v tištěné podobě,
·kryptografických informací (tj. kryptografických algoritmů, délek klíčů) v certifikátu kořenové CA,
·všech povolení, která kořenová CA smí používat a předávat podřízeným CA.
50)CPA zkontroluje totožnost organizace a jiné informace o registraci poskytnuté žadatelem o certifikát pro vložení nového certifikátu kořenové CA do ECTL.
51)CPA shromažďuje přímé důkazy nebo osvědčení o totožnosti z vhodného a oprávněného zdroje (např. název) a případně veškeré specifické atributy subjektů, kterým se certifikát vydává. Předložené důkazy mohou mít formu tištěné nebo elektronické dokumentace.
52)Totožnost subjektu se v okamžiku registrace ověřuje vhodnými prostředky a v souladu s aktuální certifikační politikou.
53)Při každé žádosti o certifikát se předkládají důkazy o:
·úplném názvu organizačního subjektu (soukromá organizace, vládní subjekt nebo nekomerční subjekt);
·vnitrostátně uznané registraci nebo jiných atributech, které mohou být případně použity k odlišení organizačního subjektu od jiných subjektů se stejným názvem.
Výše uvedená pravidla vycházejí z TS 102 042 [2]: CA zajistí, aby důkazy o identifikaci a přesnosti názvů a souvisejících údajů účastníka a subjektu byly řádně přezkoumány v rámci definované služby, nebo případně vyvozeny prostřednictvím přezkoumání osvědčení z vhodných a oprávněných zdrojů, a aby žádosti o certifikát byly přesné, schválené a úplné v souladu se shromážděnými důkazy nebo osvědčeními.
3.2.2.2.Autentizace totožnosti organizace TLM
54)Organizace provozující TLM doloží identifikaci a přesnost názvu a souvisejících údajů, aby umožnila vhodné ověření při původním vytvoření a změně klíče certifikátu TLM.
55)Totožnost subjektu musí být v době vytváření certifikátu nebo změny klíče ověřena vhodnými prostředky a v souladu s aktuální CP.
56)Důkazy organizace se poskytnou tak, jak je uvedeno v oddíle 3.2.2.1.
3.2.2.3.Autentizace totožnosti organizace podřízených CA
57)Kořenová CA kontroluje totožnost organizace a další informace o registraci poskytnuté žadateli o certifikát pro certifikáty podřízených CA (EA/AA).
58)Kořenová CA musí přinejmenším:
·určit, zda organizace existuje, a to s použitím alespoň jedné služby nebo databáze třetí strany pro prokazování totožnosti nebo alternativně organizační dokumentace vydané příslušnou vládní agenturou nebo uznávaným orgánem nebo u nich podanou, která potvrzuje existenci organizace,
·použít poštovní službu nebo jiný srovnatelný postup, který vyžaduje, aby žadatel o certifikát potvrdil některé informace o organizaci, to, že autorizoval žádost o certifikát, a to, že osoba podávající žádost jménem žadatele je k tomu oprávněna. Pokud certifikát obsahuje jméno osoby jako autorizovaného zástupce organizace, musí rovněž potvrdit, že tuto osobu zaměstnává a že jej pověřila, aby jednal jejím jménem.
59)Postupy validace pro vydávání certifikátů CA musí být zdokumentovány v CPS kořenové CA.
3.2.2.4.Autentizace účastnické organizace koncových subjektů
60)Nežli se účastník koncových subjektů (výrobce/provozovatel) může zaregistrovat u důvěryhodné EA, aby jeho koncové subjekty mohly zasílat žádosti o certifikát EC, EA musí:
·zkontrolovat totožnost účastnické organizace a další informace o registraci poskytnuté žadatelem o certifikát,
·zkontrolovat, že typ stanice C-ITS (tj. konkrétní výrobek založený na značce, modelu a verzi stanice C-ITS) splňuje všechna kritéria pro posouzení souladu.
61)EA musí minimálně:
·určit, zda organizace existuje, a to s použitím alespoň jedné služby nebo databáze třetí strany pro prokazování totožnosti nebo alternativně organizační dokumentace vydané příslušnou vládní agenturou nebo uznávaným orgánem nebo u nich podanou, která potvrzuje existenci organizace,
·použít poštovní službu nebo jiný srovnatelný postup, který vyžaduje, aby žadatel o certifikát potvrdil některé informace o organizaci, to, že autorizoval žádost o certifikát, a to, že osoba podávající žádost jeho jménem je k tomu oprávněna. Pokud certifikát obsahuje jméno osoby jako autorizovaného zástupce organizace, musí rovněž potvrdit, že tuto osobu zaměstnává a že jej pověřila, aby jednal jejím jménem.
62)Postupy validace pro registraci stanice C-ITS jejím účastníkem musí být zdokumentovány v CPS EA.
3.2.3.Autentizace jednotlivého subjektu
3.2.3.1.Autentizace jednotlivého subjektu TLM / CA
63)Pro autentizaci jednotlivého subjektu (fyzické osoby) identifikovaného ve spojení s právnickou osobou nebo organizačním subjektem (např. účastníkem) musí být předloženy doklady o:
·úplném jménu subjektu (včetně příjmení a jména, v souladu s platnými právními předpisy a vnitrostátními identifikačními postupy),
·datu a místu narození, odkazu na vnitrostátně uznávaný průkaz totožnosti nebo jiné atributy účastníka, které mohou být případně použity k odlišení osoby od jiných se stejným jménem,
·úplném názvu a právním postavení přidružené právnické osoby nebo jiného organizačního subjektu (např. účastníka),
·všech příslušných informacích o registraci (např. registrace společnosti) přidružené právnické osoby nebo jiného organizačního subjektu,
·dokladech o tom, že je subjekt spojen s právnickou osobou nebo jiným organizačním subjektem.
Předložené důkazy mohou mít formu tištěné nebo elektronické dokumentace.
64)K ověření své totožnosti předloží autorizovaný zástupce kořenové CA, EA, AA nebo účastníka dokumentaci prokazující, že pro organizaci pracuje (osvědčení o autorizaci). Musí rovněž předložit úřední průkaz totožnosti.
65)Pro prvotní proces registrace (tok 31/32) poskytne zástupce EA/AA příslušné kořenové CA veškeré potřebné informace (viz oddíl 4.1.2).
66)Pracovníci kořenové CA ověří totožnost zástupce žadatele o certifikát a všechny související dokumenty s použitím požadavků na „důvěryhodné pracovníky“ stanovených v oddíle 5.2.1. (Proces validování informací o žádosti a generování certifikátu kořenovou CA provádějí „důvěryhodné osoby“ u kořenové CA, a to alespoň pod dvojím dohledem, neboť se jedná o citlivé operace ve smyslu oddílu 5.2.2).
3.2.3.2.Autentizace totožnosti účastníka stanic C-ITS
67)Účastníci jsou zastoupeni autorizovanými konečnými uživateli v organizaci, kteří jsou registrováni u vydávající EA a AA. Tito koneční uživatelé určení organizacemi (výrobci nebo provozovateli) musí prokázat svou totožnost a autenticitu před:
·registrací EE v její příslušné EA, včetně jeho kanonického veřejného klíče, kanonického ID (jedinečného identifikátoru) a povolení v souladu s EE,
·registrací v AA a prokázáním účastnické smlouvy, která může být zaslána EA.
3.2.3.3.Autentizace totožnosti stanice C-ITS
68)subjekty EE, na které se vztahují oprávnění (EC), musí při žádosti o EC (tok 31) prokázat svou totožnost za použití svého kanonického soukromého klíče pro prvotní autentizaci. EA zkontroluje autentizaci pomocí kanonického veřejného klíče, který odpovídá EE. Kanonické veřejné klíče EE jsou předány EA před provedením prvotní žádosti zabezpečeným kanálem mezi výrobcem nebo provozovatelem stanice C-ITS a EA (tok 33).
69)EE, na které se vztahují potvrzení o autorizaci (AT), musí při žádosti o AT (tok 32) prokázat svou totožnost za použití svého jedinečného soukromého klíče pro registraci. AA předá podpis k validaci EA (tok 25); EA jej validuje a potvrdí výsledek AA (tok 23).
3.2.4.Neověřené informace o účastníkovi
Není stanoveno.
3.2.5.Validace autority
3.2.5.1.Validace TLM, kořenové CA, EA, AA
70)V CPS musí každá organizace určit alespoň jednoho zástupce (např. úředníka pro bezpečnost) odpovědného za vyžádání nových certifikátů a obnovení. Použijí se pravidla pro pojmenovávání v oddíle 3.2.3.
3.2.5.2.Validace účastníků stanice C-ITS
71)Musí být známa a EA schválena alespoň jedna fyzická osoba odpovědná za registraci stanice C-ITS u EA (např. úředník pro bezpečnost) (viz oddíl 3.2.3).
3.2.5.3.Validace stanice C-ITS
72)Účastník stanice C-ITS může registrovat stanici C-ITS u konkrétní EA (tok 33), je-li u této EA autentizován.
Je-li stanice C-ITS registrována u EA jedinečným kanonickým ID a kanonickým veřejným klíčem, může požádat o oprávnění k registraci (EC) pomocí žádosti podepsané kanonickým soukromým klíčem souvisejícím s dříve registrovaným kanonickým veřejným klíčem.
3.2.6.Kritéria pro interoperabilitu
73)Pro komunikaci mezi stanicemi C-ITS a EA (nebo AA) musí být stanice C-ITS schopna zajistit bezpečnou komunikaci s EA (nebo AA), tj. provádět funkce autentizace, důvěrnosti a integrity, jak je upřesněno v [1]. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly. EA a AA musí tuto bezpečnou komunikaci podporovat.
74)EA a AA musí podporovat žádosti o certifikát a odpovědi, které jsou v souladu s [1], což poskytuje bezpečný AT protokol žádosti/odpovědi, jenž podporuje anonymitu žadatele vůči AA a oddělení povinností mezi AA a EA. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly. Aby se zabránilo zpřístupnění dlouhodobé totožnosti stanice C-ITS, musí být komunikace mezi mobilní stanicí C-ITS a EA důvěrná (např. komunikační data musí být šifrována mezi koncovými body).
75)Pro každou žádost o autorizaci, kterou obdrží od subjektu certifikátu EE, předloží AA žádost o validaci autorizace (tok 25). EA tuto žádost validuje s ohledem na:
·stav EE v EA,
·platnost podpisu,
·požadované aplikační ID ITS (ITS-AID) a povolení,
·stav poskytování služby AA účastníkovi.
3.3.Identifikace a autentizace žádostí o změnu klíče
3.3.1.Identifikace a autentizace žádostí o rutinní změnu klíče
3.3.1.1.Certifikáty TLM
76)TLM generuje pár klíčů a dva certifikáty: jeden samopodepsaný a jeden spojovací certifikát uvedený v oddíle 7.
3.3.1.2.Certifikáty kořenové CA
Nepoužije se.
3.3.1.3.Obnova certifikátu nebo změna klíče EA/AA
77)Aby byla zachována kontinuita používání certifikátu, požádá EA/AA před uplynutím platnosti certifikátu EA/AA o nový certifikát (tok 21 / tok 24). EA/AA generuje nový pár klíčů s cílem nahradit pár klíčů pozbývající platnosti a podepsat žádost o změnu klíče obsahující nový veřejný klíč spolu aktuálním platným soukromým klíčem („změna klíče“). EA nebo AA generuje nový pár klíčů a podepisuje žádost novým soukromým klíčem (vnitřní podpis), aby prokázal vlastnictví nového soukromého klíče. Celá žádost je přepodepsána aktuálním platným soukromým klíčem (vnějším podpisem), aby byla zajištěna integrita a autenticita žádosti. Je-li použit pár klíčů pro šifrování a dešifrování, musí se prokázat vlastnictví soukromých klíčů dešifrování (podrobný popis změny klíče viz oddíl 4.7.3.3).
78)Metoda identifikace a autentizace pro rutinní změnu klíče je stejná jako metoda pro původní vydání prvotního certifikátu kořenové CA, jak je stanovena v oddíle 3.2.2.
3.3.1.4.Oprávnění koncových subjektů k registraci
79)Aby byla zachována kontinuita používání certifikátu, požádá EE před uplynutím platnosti stávajícího EC o nový certifikát (tok 31). EE generuje nový pár klíčů s cílem nahradit pár klíčů pozbývající platnosti a požádat o nový certifikát obsahující nový veřejný klíč; žádost musí být podepsána aktuálním platným soukromým klíčem EC.
80)EE může žádost podepsat nově vytvořeným soukromým klíčem (vnitřní podpis), aby prokázal vlastnictví nového soukromého klíče. Celá žádost je poté přepodepsána aktuálním platným soukromým klíčem (vnějším podpisem) a zašifrována pro přijímající EA tak, jak je upřesněno v [1], s cílem zajistit důvěrnost, integritu a autenticitu žádosti. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
3.3.1.5.Autorizační potvrzení koncových subjektů
81)Změna klíče certifikátu pro AT je založena na stejném postupu jako původní autorizace, jak je definováno v [1]. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
3.3.2.Identifikace a autentizace žádostí o změnu klíče po odvolání
3.3.2.1.Certifikáty CA
82)Autentizace organizace CA pro změnu klíče certifikátu kořenové CA, EA a AA po odvolání se provádí stejným způsobem jako původní vydání certifikátu CA, jak je stanoveno v oddíle 3.2.2.
3.3.2.2.Oprávnění koncových subjektů k registraci
83)Autentizace EE pro změnu klíče certifikátu EC po odvolání se provádí stejným způsobem jako původní vydání certifikátu EE, jak je stanoveno v oddíle 3.2.2.
3.3.2.3.Žádosti koncových subjektů o autorizaci
Není použitelné, protože potvrzení o autorizaci (AT) se neodvolávají.
3.4.Identifikace a autentizace pro žádost o odvolání
3.4.1.Certifikáty kořenové CA/EA/AA
84)Žádosti o vymazání certifikátu kořenové CA z ECTL musí být autentizovány kořenovou CA vůči TLM (toky 12 a 9). Žádosti o odvolání certifikátu EA/AA musí být autentizovány příslušnou kořenovou CA a samotnou podřízenou CA.
85)Přijatelné postupy pro autentizaci žádostí účastníka o odvolání zahrnují:
·písemná a podepsaná zpráva účastníka na podnikovém dopisním papíru požadující odvolání s odkazem na certifikát, který má být odvolán,
·komunikace s účastníkem poskytující přiměřená ujištění, že osoba nebo organizace, která žádá o odvolání, je opravdu účastník. V závislosti na okolnostech může taková komunikace zahrnovat jeden nebo více z těchto prvků: e-mail, poštovní zásilku nebo kurýrní službu.
3.4.2.Oprávnění stanice C-ITS k registraci
86)Účastník stanice C-ITS může odvolat oprávnění (EC) dříve registrované stanice C-ITS u EA (tok 34). Žádající účastník vypracuje žádost o odvolání dané stanice C-ITS nebo seznamu stanic C-ITS. EA před zpracováním žádosti žádost o odvolání autentizuje a potvrdí odvolání stanice C-ITS a jejích EC.
87)EA může odvolat EC stanice C-ITS v souladu s oddílem 7.3.
3.4.3.Potvrzení o autorizaci stanice C-ITS
88)Jelikož AT nejsou odvolávána, jejich platnost se omezí na určité období. Rozsah přijatelných dob platnosti v této certifikační politice je upřesněn v oddíle 7.
4.Provozní požadavky na životní cyklus certifikátu
4.1.Žádost o certifikát
89)Tento oddíl stanoví požadavky na prvotní žádost o vydání certifikátu.
90)Termínem „žádost o certifikát“ se rozumí tyto procesy:
·registrace a zřízení vztahu důvěry mezi TLM a CPA,
·registrace a zřízení vztahu důvěry mezi kořenovou CA, CPA a TLM, včetně vložení prvního certifikátu kořenové CA do ECTL,
·registrace a zřízení vztahu důvěry mezi EA/AA a kořenovou CA, včetně vydání nového certifikátu EA/AA,
·registrace stanice C-ITS u EA výrobcem/provozovatelem,
·žádost stanice C-ITS o EC/AT.
4.1.1.Kdo může podat žádost o certifikát
4.1.1.1.Kořenové CA
91)Kořenové CA generují své vlastní páry klíčů a samy vydávají svůj kořenový certifikát. Kořenová CA může podat žádost o certifikát prostřednictvím svého pověřeného zástupce (tok 14).
4.1.1.2.TLM
92)TLM generuje své vlastní páry klíčů a sám vydává svůj certifikát. Původní vytvoření certifikátu TLM zpracovává zástupce organizace TLM pod dohledem CPA.
4.1.1.3.EA a AA
93)Autorizovaný zástupce EA nebo AA může předložit žádost o certifikát podřízené CA (EA a/nebo AA) autorizovanému zástupci příslušné kořenové CA (toky 27/28).
4.1.1.4.Stanice C-ITS
94)Účastníci registrují každou stanici C-ITS u EA v souladu s oddílem 3.2.5.3.
95)Každá stanice C-ITS registrovaná u EA může zasílat žádosti o EC (tok 31).
96)Každá stanice C-ITS může zasílat žádosti o AT (tok 32), aniž by vyžadovala jakoukoli interakci účastníků. Před podáním žádosti o AT musí mít stanice C-ITS oprávnění (EC).
4.1.2.Proces a povinnosti registrace
97)Povolení pro kořenové CA a podřízené CA vydávající certifikáty pro zvláštní (vládní) účely (tj. zvláštní mobilní a pevné stanice C-ITS) mohou udělovat pouze členské státy, ve kterých se tyto organizace nacházejí.
4.1.2.1.Kořenové CA
98)Po absolvování auditu (tok 13 a 36, oddíl 8) mohou kořenové CA požádat o vložení svých certifikátů do ECTL v CPA (tok 14). Proces registrace je založen na ručně podepsaném formuláři žádosti, který je fyzicky dodán CPA autorizovaným zástupcem kořenové CA a který obsahuje alespoň informace uvedené v oddílech 3.2.2.1, 3.2.3 a 3.2.5.1.
99)Formulář žádosti kořenové CA musí být podepsán autorizovaným zástupcem CA.
100)Kromě formuláře žádosti poskytne autorizovaný zástupce kořenové CA orgánu CPA ke schválení (tok 16) kopii CPS kořenové CA (tok 15) a jeho zprávu o auditu. V případech pozitivního schválení CPA generuje a zasílá CPOC/TLM a odpovídající kořenové CA certifikát o shodě.
101)Autorizovaný zástupce kořenové CA pak přinese formulář žádosti (obsahující otisk samopodepsaného certifikátu), úřední průkaz totožnosti a doklad o autorizaci CPOC/TLM. Samopodepsaný certifikát musí být CPOC/TLM doručen elektronicky. CPOC/TLM ověří veškeré dokumenty a samopodepsaný certifikát.
102)V případě pozitivních ověření doplní TLM na základě oznámení CPA (toky 1 a 2) certifikát kořenové CA do ECTL. Podrobný postup je popsán v CPS TLM.
103)Měl by být možný dodatečný postup pro získání schválení CPS a zprávy o auditu kořenové CA u vnitrostátního orgánu konkrétních zemí.
4.1.2.2.TLM
104)Po absolvování auditu se TLM může zapsat u CPA. Proces registrace je založen na podepsaném manuálním formuláři žádosti, který je autorizovaným zástupcem TLM fyzicky doručen CPA (tok 38) a obsahuje alespoň informace uvedené v oddílech 3.2.2.2 a 3.2.3.
105)Formulář žádosti TLM musí být podepsán jeho autorizovaným zástupcem.
106)TLM nejprve generuje svůj samopodepsaný certifikát a zasílá jej bezpečně CPA. Poté TLM předloží CPA svůj formulář žádosti (obsahující otisk samopodepsaného certifikátu), kopii svého CPS, úřední průkaz totožnosti, doklad o autorizaci a zprávu o auditu (tok 40). CPA ověří veškeré dokumenty a samopodepsaný certifikát. V případech pozitivního ověření všech dokumentů, samopodepsaného certifikátu a otisku potvrdí CPA proces registrace zasláním svého souhlasu TLM a CPOC (tok 39). CPA uchovává informace o žádosti zaslané TLM. Certifikát TLM je pak vydán prostřednictvím CPOC.
4.1.2.3.EA a AA
107)Během procesu registrace přinese EA/AA příslušné kořenové CA ke schválení příslušné dokumenty (např. CPS a zprávu o auditu) (tok 27/28). V případech pozitivních kontrol dokumentů zašle kořenová CA odpovídajícím podřízeným CA schválení (toky 29/30). Podřízená CA (EA nebo AA) poté zašle svou podepsanou žádost elektronicky a fyzicky dodá odpovídající kořenové CA svůj formulář žádosti (v souladu s oddílem 3.2.2.1), doklad o autorizaci a doklad totožnosti. Kořenová CA ověřuje žádost a obdržené dokumenty (formulář žádosti obsahující otisk, což je SHA 256 hashvalue žádosti podřízené CA, doklad o autorizaci a doklad totožnosti). Vedou-li všechny kontroly k pozitivnímu výsledku, vydá kořenová CA odpovídající certifikát podřízené CA. Podrobné informace, jak provést prvotní žádost, jsou popsány v jejím konkrétním CPS.
108)Kromě formuláře žádosti podřízené CA přiloží autorizovaný zástupce podřízené CA kopii CPS kořenové CA.
109)Informace se poskytují akreditovanému auditorovi PKI pro audit v souladu s oddílem 8.
110)Je-li podřízená CA ve vlastnictví jiného subjektu než subjektu, který vlastní kořenovou CA, musí před tím, než vydá žádost o certifikát podřízené CA, podepsat smlouvu ohledně služby kořenové CA.
4.1.2.4.Stanice C-ITS
111)Původní registraci subjektů koncových subjektů (stanice C-ITS) provádí odpovědný účastník (výrobce/provozovatel) s EA (toky 33 a 35) po úspěšné autentizaci organizace účastníka a jednoho z jejích zástupců v souladu s oddíly 3.2.2.4 a 3.2.5.2.
112)Stanice C-ITS může generovat pár klíčů EC (viz oddíl 6.1) a vytvořit podepsanou žádost o EC v souladu s [1]. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
113)Během registrace běžné stanice C-ITS (oproti zvláštní mobilní nebo pevné stanici C-ITS) musí EA ověřit, zda povolení v původní žádosti nejsou pro vládní použití. Povolení pro vládní použití jsou definována příslušnými členskými státy. Podrobný postup registrace a odpovědi EA výrobci/provozovateli (toky 33 a 35) se stanoví v příslušném CPS EA.
114)Stanice C-ITS se zapíše u EA (oddíl 3.2.5.3) zasláním své původní žádosti o EC v souladu s [1].
115)Po původní registraci autentizovaným zástupcem účastníka EA schválí, která potvrzení o autorizaci (AT) může subjekt koncového subjektu (tj. stanice C-ITS) získat. Každému koncovému subjektu je dále přidělena úroveň důvěryhodnosti, která se vztahuje k certifikaci koncového subjektu v souladu s jedním z profilů ochrany uvedených v oddíle 6.1.5.2.
116)Běžná vozidla mají pouze jednu stanici C-ITS, která je registrována u jedné EA. Vozidla zvláštního určení (jako jsou policejní vozy a jiná speciální vozidla se zvláštními právy) mohou být registrována u další EA nebo mohou mít v rámci zvláštního určení další stanici C-ITS pro autorizace. Vozidla, na něž se tato výjimka vztahuje, jsou vymezena odpovědnými členskými státy. Povolení pro zvláštní mobilní a pevné stanice C-ITS udělují pouze odpovědné členské státy. Jakým způsobem se proces certifikace vztahuje na tato vozidla, určí CPS kořenových CA nebo podřízených CA, které vydávají certifikáty pro tato vozidla v uvedených členských státech.
117)Je-li účastník v procesu migrace stanice C-ITS z jedné EA do jiné EA, může být stanice C-ITS zaregistrována u dvou (podobných) EA.
118)Stanice C-ITS generuje pár klíčů AT (viz oddíl 6.1) a vytvoří žádost o AT v souladu s [1]. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
119)Stanice C-ITS zašlou žádost o autorizaci na adresu URL AA (toky 32 a 26) tak, že zašlou alespoň požadované informace uvedené v oddíle 3.2.3.3. AA a EA validují autorizaci každé žádosti v souladu s oddíly 3.2.6 a 4.2.2.5.
4.2.Zpracování žádosti o certifikát
4.2.1.Vykonávání funkcí identifikace a autentizace
4.2.1.1.Identifikace a autentizace kořenových CA
120)Autorizovaný zástupce CPA odpovídá za autentizaci autorizovaného zástupce kořenové CA a za schválení procesu registrace v souladu s oddílem 3.
4.2.1.2.Identifikace a autentizace správce seznamu důvěryhodných subjektů
121)Autorizovaný zástupce CPA odpovídá za autentizaci autorizovaného zástupce TLM a za schválení jeho formuláře žádosti pro proces registrace v souladu s oddílem 3.
4.2.1.3.Identifikace a autentizace EA a AA
122)Odpovídající kořenová CA je odpovědná za autentizaci autorizovaného zástupce EA/AA a za schválení jeho formuláře žádosti pro proces registrace v souladu s oddílem 3.
123)Kořenová CA potvrdí kladnou validaci formuláře žádosti pro EA/AA. EA/AA pak mohou zaslat žádost o certifikát kořenové CA (tok 21/24), který vydává certifikáty odpovídající EA/AA (tok 18/19).
4.2.1.4.Identifikace a autentizace účastníka EE
124)Před tím než může stanice C-ITS požádat o certifikát EC, musí účastník EE bezpečně přenést informace o ID stanice C-ITS na EA (tok 33). EA žádost ověří a v případě pozitivního ověření zaregistruje informace o stanici C-ITS do své databáze a potvrdí to účastníkovi EE (tok 35). Tuto operaci provádí výrobce nebo provozovatel pro každou stanici C-ITS pouze jednou. Jakmile je stanice C-ITS zaregistrována EA, může si vyžádat jediný certifikát EC, který v daném čase potřebuje (tok 31). EA autentizuje a ověří, že informace v žádosti o certifikát EC jsou pro stanici C-ITS platné.
4.2.1.5.Potvrzení o autorizaci
125)Během žádostí o autorizaci (tok 32) musí AA v souladu s [1] autentizovat EA, od které stanice C-ITS obdržela své oprávnění (EC). Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly. Není-li AA schopna autentizovat EA, žádost se zamítne (tok 26). Je nutné, aby AA vlastnila certifikát EA pro autentizaci EA a ověření jeho odpovědi (toky 25 a 23, oddíl 3.2.5.3).
126)EA autentizuje stanici C-ITS, která žádá o AT tím, že ověří její EC (toky 25 a 23).
4.2.2.Schválení nebo zamítnutí žádostí o certifikát
4.2.2.1.Schválení nebo zamítnutí certifikátů kořenové CA
127)TLM vkládá do ECTL / maže v ECTL certifikáty kořenové CA v souladu se schválením CPA (tok 1/2).
128)TLM by měl po obdržení schválení CPA (tok 1) ověřit podpis, informace a kódování certifikátů kořenové CA. Po pozitivní validaci a schválení CPA vloží TLM odpovídající kořenový certifikát do ECTL a oznámí to CPA (tok 5).
4.2.2.2.Schválení nebo zamítnutí certifikátu TLM
129)CPA odpovídá za schvalování nebo zamítání certifikátů TLM.
4.2.2.3.Schválení nebo zamítnutí certifikátů EA a AA
130)Kořenová CA ověřuje žádosti o certifikát podřízené CA (toky 21/24) a příslušné zprávy (vydané akreditovaným auditorem PKI) o jejich přijetí (tok 36, oddíl 8) od odpovídající podřízené CA kořenové CA. Jestliže kontrola žádosti vede k pozitivnímu výsledku, příslušná kořenová CA vydá certifikát žádající EA/AA (tok 18/19); v opačném případě je žádost zamítnuta a EA/AA není vydán žádný certifikát.
4.2.2.4.Schválení nebo zamítnutí oprávnění
131)EA ověří a validuje žádosti o EC podle oddílů 3.2.3.2 a 3.2.5.3.
132)Je-li žádost o certifikát v souladu s [1] správná a platná, EA generuje požadovaný certifikát.
133)Je-li žádost o certifikát neplatná, EA ji zamítne a zašle odpověď uvádějící důvod zamítnutí v souladu s [1]. Pokud si stanice C-ITS stále přeje EC, musí podat novou žádost o certifikát. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
4.2.2.5.Schválení nebo zamítnutí potvrzení o autorizaci
134)Žádost o certifikát kontroluje EA. AA zřídí komunikaci s EA s cílem validovat žádost (tok 25). EA autentizuje žádající stanici C-ITS a validuje, zda má právo obdržet požadované AT na základě CP (např. kontrolou stavu odvolání a validací platnosti certifikátu pro dobu/region, povolení, úroveň zabezpečení atd.). EA vrátí odpověď validace (tok 23), a je-li odpověď kladná, AA vygeneruje požadovaný certifikát a předá jej stanici C-ITS. Není-li žádost o AT správná nebo je odpověď validace EA záporná, AA žádost zamítne. Pokud stanice C-ITS nadále požaduje AT, musí podat novou žádost o autorizaci.
4.2.3.Doba pro zpracování žádosti o certifikát
4.2.3.1.Žádost o certifikát kořenové CA
135)Doba pro zpracování procesu identifikace a autentizace žádosti o certifikát je během pracovního dne a vztahuje se na ni maximální lhůta stanovená v CPS kořenové CA.
4.2.3.2.Žádost o certifikát TLM
136)Na zpracování žádosti o certifikát TLM se vztahuje maximální lhůta stanovená v CPS TLM.
4.2.3.3.Žádost o certifikát EA a AA
137)Doba pro zpracování procesu identifikace a autentizace žádosti o certifikát je během pracovního dne v souladu s dohodou a smlouvou mezi členským státem / soukromou organizací kořenové CA a podřízené CA. Na dobu pro zpracování žádosti o certifikát podřízené CA se vztahuje maximální lhůta stanovená v CPS podřízené CA.
4.2.3.4.Žádost o EC
138)Na zpracování žádostí o EC se vztahuje maximální lhůta stanovená v CPS EA.
4.2.3.5.Žádost o AT
139)Na zpracování žádostí o AT se vztahuje maximální lhůta stanovená v CPS AA.
4.3.Vydávání certifikátu
4.3.1.Úkony CA v průběhu vydávání certifikátu
4.3.1.1.Vydávání certifikátu kořenové CA
140)Kořenové CA vydávají své vlastní samopodepsané certifikáty kořenové CA, spojovací certifikáty, certifikáty podřízené CA a CRL.
141)Po schválení CPA (tok 4) zašle kořenová CA certifikát prostřednictvím CPOC správci seznamu důvěryhodných subjektů (TLM), aby byl přidán do ECTL (toky 11 a 8) (viz oddíl 4.1.2.1). TLM zkontroluje, zda CPA certifikát schválil (tok 1).
4.3.1.2.Vydávání certifikátu TLM
142)TLM vydává svůj vlastní samopodepsaný certifikát TLM a spojovací certifikát a posílá jej na CPOC (tok 6).
4.3.1.3.Vydávání certifikátu EA a AA
143)Podřízené CA generují podepsanou žádost o certifikát a předají ji odpovídající kořenové CA (toky 21 a 24). Kořenová CA ověří žádost a vydá certifikát žádající podřízené CA v souladu s [5] co nejdříve, jak stanoví CPS pro obvyklé provozní postupy, avšak nejpozději pět pracovních dnů po obdržení žádosti.
144)Kořenová CA aktualizuje úložiště obsahující certifikáty podřízených CA.
4.3.1.4.Vydávání oprávnění
145)Stanice C-ITS zašle EA žádost o EC v souladu s [1]. EA autentizuje a ověří, že informace v žádosti o certifikát jsou pro stanici C-ITS platné. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
146)V případě kladné validace vydá EA certifikát v souladu s registrací stanice C-ITS (viz 4.2.1.4) a zašle jej stanici C-ITS pomocí zprávy odpovědi na EC v souladu s [1]. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
147)Neexistuje-li registrace, EA vygeneruje kód chyby a zašle jej pomocí zprávy odpovědi na EC stanici C-ITS v souladu s [1]. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
148)Žádosti o EC a odpovědi na EC musí být šifrovány, aby se zajistila důvěrnost, a podepsány, aby se zajistila autentizace a integrita.
4.3.1.5.Vydávání potvrzení o autorizaci
149)Stanice C-ITS zašle zprávu o žádosti o potvrzení o autorizaci (AT) v souladu s [1]. AA zašle EA žádost o validaci AT v souladu s [1]. EA zašle AA odpověď validace AT. V případech kladné odpovědi AA generuje AT a zašle jej stanici C-ITS zprávou odpovědi AT v souladu s [1]. V případech záporné odpovědi vygeneruje AA kód chyby a zašle jej stanici C-ITS zprávou odpovědi AT v souladu s [1]. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
150)Žádosti o AT a odpovědi AT musí být šifrovány (nezbytné pouze pro mobilní stanice C-ITS), aby se zajistila důvěrnost, a podepsány, aby se zajistila autentizace a integrita.
4.3.2.Oznámení CA účastníkovi o vydání certifikátů
Nepoužije se.
4.4.Přijetí certifikátu
4.4.1.Převzetí certifikátu
4.4.1.1.Kořenová CA
Nepoužije se.
4.4.1.2.TLM
Nepoužije se.
4.4.1.3.EA a AA
151)EA/AA ověří druh certifikátu, podpis a informace v přijatém certifikátu. EA/AA odstraní všechny certifikáty EA/AA, které nejsou správně ověřeny, a vydá novou žádost.
4.4.1.4.Stanice C-ITS
152)Stanice C-ITS ověří odpověď EC/AT od EA/AA oproti původní žádostí, včetně podpisu a řetězce certifikátů. Odstraní veškeré odpovědi EC/AT, které nejsou správně ověřeny. V takových případech by měla zaslat novou žádost o EC/AT.
4.4.2.Zveřejnění certifikátu
153)Certifikáty TLM a jejich spojovací certifikáty jsou prostřednictvím CPOC zpřístupněny všem účastníkům.
154)Certifikáty kořenové CA jsou zveřejňovány CPOC prostřednictvím ECTL, který je podepsán TLM.
155)Certifikáty podřízených CA (EA a AA) zveřejňuje kořenová CA.
156)EC a AT se nezveřejňují.
4.4.3.Oznámení o vydání certifikátu
Neexistují žádná oznámení o vydání.
4.5.Použití páru klíčů a certifikátu
4.5.1.Použití soukromého klíče a certifikátu
4.5.1.1.Použití soukromého klíče a certifikátu pro TLM
157)TLM používá své soukromé klíče k podpisu svých vlastních (TLM a spojovacích) certifikátů a ECTL.
158)Certifikát TLM používají účastníci PKI k ověření ECTL a autentizaci TLM.
4.5.1.2.Použití soukromého klíče a certifikátů pro kořenové CA
159)Kořenové CA používají své soukromé klíče k podpisu svých vlastních certifikátů, CRL, spojovacích certifikátů a certifikátů EA/AA.
160)Účastníci PKI používají certifikáty kořenových CA k ověření souvisejících certifikátů AA a EA, spojovacích certifikátů a CRL.
4.5.1.3.Použití soukromého klíče a certifikátu registrující a autorizační autoritou
161)EA používají své soukromé klíče k podpisu EC a k dešifrování žádosti o registraci.
162)Certifikáty EA se použijí k ověření podpisu souvisejících EC a AT a k šifrování žádostí o EC a AT, jak je definováno v [1].
163)AA využijí své soukromé klíče k podpisu AT a k dešifrování žádosti o AT.
164)Certifikáty AA se použijí k ověření souvisejících AT a k šifrování žádostí o AT, jak je definováno v [1].
4.5.1.4.Použití soukromého klíče a certifikátu koncovým subjektem
165)EE použijí soukromý klíč odpovídající platnému EC k podpisu nové žádosti o registraci definované v [1]. Nový soukromý klíč se použije k vybudování vnitřního podpisu pro prokázání vlastnictví soukromého klíče, který odpovídá novému veřejnému klíči EC.
166)EE použijí soukromý klíč odpovídající platnému EC k podpisu žádosti o autorizaci, jak je definováno v [1]. Soukromý klíč odpovídající novému AT by se měl použít k vybudování vnitřního podpisu pro prokázání vlastnictví soukromého klíče, který odpovídá novému veřejnému klíči AT.
167)EE použije soukromý klíč odpovídající vhodnému AT k podpisu zpráv C-ITS, jak je definováno v [5].
4.5.2.Použití veřejného klíče a certifikátu spoléhající se stranou
168)Spoléhající se strany používají cestu důvěryhodné certifikace a související veřejné klíče pro účely uvedené v certifikátech a pro autentizaci důvěryhodné společné totožnosti EC a AT.
169)Certifikáty kořenové CA, EA a AA, EC a AT se nepoužijí bez předběžné kontroly spoléhající se strany.
4.6.Obnova certifikátu
Není povoleno.
4.7.Změna klíče certifikátu
4.7.1.Okolnosti pro změnu klíče certifikátu
170)Změna klíče certifikátu se zpracuje, když certifikát dosáhne konce své životnosti nebo když soukromý klíč dosáhne konce provozního použití, avšak stále existuje vztah důvěry s CA. Ve všech případech musí být generován a vydán nový pár klíčů a odpovídající certifikát.
4.7.2.Kdo může požádat o změnu klíče
4.7.2.1.Kořenová CA
171)Kořenová CA nepožaduje změnu klíče. Proces změny klíče je pro kořenovou CA interním procesem, protože jeho certifikát je samopodepsaný. Kořenová CA překlíčuje klíče buď na spojovací certifikáty, nebo na nové vydání (viz oddíl 4.3.1.1).
4.7.2.2.TLM
172)TLM nepožaduje změnu klíče. Proces změny klíče je pro TLM interním procesem, protože certifikát TLM je samopodepsaný.
4.7.2.3.EA a AA
173)Žádost o certifikát podřízené CA musí být předložena včas, aby bylo jisté, že bude dostupný nový certifikát podřízené CA a funkční pár klíčů před ztrátou platnosti stávajícího soukromého klíče podřízené CA. Datum předložení musí zohlednit také dobu potřebnou ke schválení.
4.7.2.4.Stanice C-ITS
Nepoužije se.
4.7.3.Proces změny klíče
4.7.3.1.Certifikát TLM
174)TLM rozhoduje o změně klíče na základě požadavků uvedených v oddílech 6.1 a 7.2. Podrobný postup je stanoven v jeho CPS.
175)TLM provede včas proces změny klíče, aby umožnil distribuci nového certifikátu TLM a spojovacího certifikátu všem účastníkům před skončením platnosti stávajícího certifikátu TLM.
176)TLM použije spojovací certifikáty pro změnu klíče a pro zaručení vztahu důvěry k novému samopodepsanému certifikátu. Nově generovaný certifikát TLM a spojovací certifikát se přenese na CPOC.
4.7.3.2.Certifikát kořenové CA
177)Kořenová CA rozhoduje o změně klíče na základě požadavků oddílů 6.1.5 a 7.2. Podrobný postup by měl být vymezen v její CPS.
178)V zájmu umožnění vložení nového certifikátu do ECTL před vstupem certifikátu kořenové CA v platnost (viz oddíl 5.6.2) provádí kořenová CA proces změny klíče včas (před uplynutím platnosti certifikátu kořenového CA). Proces změny klíče se provádí buď pomocí spojovacích certifikátů, nebo jako prvotní žádost.
4.7.3.3.Certifikáty EA a AA
179)EA nebo AA požádají o nový certifikát takto:
Krok
|
Označení
|
Žádost o změnu klíče
|
1
|
Generování párů klíčů
|
Podřízené CA (EA a AA) generují nové páry klíčů v souladu s oddílem 6.1.
|
2
|
Generování žádosti o certifikát a vnitřního podpisu
|
Podřízená CA generuje žádost o certifikát z nově generovaného veřejného klíče s ohledem na pravidla pojmenovávání (subject_info) podle oddílu 3, algoritmus podpisu, povolení specifické pro službu (SSP) a volitelný dodatečný parametr a generuje vnitřní podpis s odpovídajícím novým soukromým klíčem. Je-li požadován šifrovací klíč, musí podřízená CA rovněž prokázat vlastnictví odpovídajícího soukromého dešifrovacího klíče.
|
3
|
Generování vnějšího podpisu
|
Celá žádost musí být podepsána aktuálním platným soukromým klíčem, aby byla zaručena autenticita podepsané žádosti.
|
4
|
Odeslání žádosti kořenové CA
|
Podepsaná žádost se předkládá odpovídající kořenové CA.
|
5
|
Ověření žádosti
|
Odpovídající kořenová CA ověří integritu a autenticitu žádosti. Nejprve zkontroluje vnější podpis. Pokud je ověření pozitivní, zkontroluje vnitřní podpis. Existuje-li důkaz o držení soukromého dešifrovacího klíče, zkontroluje rovněž tento důkaz.
|
6
|
Přijetí nebo zamítnutí žádosti
|
Vedou-li všechny kontroly k pozitivnímu výsledku, kořenová CA žádost přijímá; v opačném případě ji zamítne.
|
7
|
Generování a vydání certifikátu
|
Kořenová CA generuje nový certifikát a distribuuje jej žádající podřízené CA.
|
8
|
Odeslání odpovědi
|
Podřízená CA zašle kořenové CA zprávu o stavu (zda certifikát obdržela, či nikoli).
|
Tabulka 3: Proces změny klíče pro EA a AA
180)Během automatické změny klíče pro podřízené CA zajistí kořenová CA, aby žadatel skutečně vlastnil svůj soukromý klíč. Použijí se vhodné protokoly pro důkaz vlastnictví soukromých dešifrovacích klíčů, například podle definice v RFC 4210 a 4211. U soukromých podpisových klíčů by měl být použit vnitřní podpis.
4.7.3.4.Certifikáty stanice C-ITS
Nepoužije se pro AT.
4.8.Změna v certifikátu
Není povoleno.
4.9.Odvolání a pozastavení platnosti certifikátu
Viz oddíl 7.
4.10.Služby ověřování stavu certifikátu
4.10.1.Provozní charakteristiky
Nepoužije se.
4.10.2.Dostupnost služby
Nepoužije se.
4.10.3.Volitelné prvky
Nepoužije se.
4.11.Ukončení účasti
Nepoužije se.
4.12.Úschova klíče u třetí strany a jeho obnova
4.12.1.Účastník
4.12.1.1.Jaký pár klíčů lze uschovat u třetí strany
Nepoužije se.
4.12.1.2.Kdo může podat žádost o obnovu
Nepoužije se.
4.12.1.3.Proces a povinnosti obnovy
Nepoužije se.
4.12.1.4.Identifikace a autentizace
Nepoužije se.
4.12.1.5.Schválení nebo zamítnutí žádostí o obnovu
Nepoužije se.
4.12.1.6.Akce KEA a KRA v průběhu obnovy páru klíčů
Nepoužije se.
4.12.1.7.Dostupnost akcí KEA a KRA
Nepoužije se.
4.12.2.Politika a postupy enkapsulace a obnovy klíče relace
Nepoužije se.
5.Kontroly zařízení, kontroly řízení a provozní kontroly
181)PKI se skládá z kořenové CA, EA/AA, CPOC a TLM, včetně jejich komponent informačních a komunikačních technologií (např. sítí a serverů).
182)V tomto oddíle je subjekt odpovědný za prvek PKI označen samotným prvkem. Jinými slovy, věta „CA odpovídá za provedení auditu“ se rovná větě „subjekt nebo pracovníci spravující CA odpovídají za provedení...“.
183)Termín „prvky C-ITS modelu služeb vytvářejících důvěru“ zahrnuje kořenovou CA, TLM, EA/AA, CPOC a zabezpečenou síť.
5.1.Fyzické kontroly
184)Všechny operace C-ITS modelu služeb vytvářejících důvěru musí být prováděny ve fyzicky chráněném prostředí, které odrazuje od neoprávněného používání citlivých informací nebo systémů, přístupu k nim a jejich zpřístupnění, brání mu a detekuje jej. Prvky C-ITS modelu služeb vytvářejících důvěru používají fyzické bezpečnostní kontroly v souladu s ISO 27001 a ISO 27005.
185)Subjekty, které spravují prvky C-ITS modelu služeb vytvářejících důvěru, popíší ve svých CPS fyzické, procedurální a bezpečnostní kontroly. CPS zahrnuje zejména informace o umístění a konstrukci budov a jejich fyzických bezpečnostních kontrolách, které zaručují řízený přístup do všech místností používaných v zařízení subjektů C-ITS modelu služeb vytvářejících důvěru.
5.1.1.Umístění a konstrukce
5.1.1.1.Kořenová CA, CPOC, TLM
186)Umístění a konstrukce zařízení pro umístění vybavení a dat kořenové CA, CPOC a TLM (HSM, aktivační údaje, zálohování páru klíčů, počítač, protokol, skript klíčové ceremonie, žádost o certifikát atd.) musí být v souladu se zařízeními používanými k umístění citlivých informací s vysokou hodnotou. Kořenová CA se provozuje ve vyhrazené fyzické oblasti oddělené od jiných fyzických prostor komponent PKI.
187)Kořenová CA, CPOC a TLM implementují politiky a postupy s cílem zajistit, že ve fyzickém prostředí, v němž je nainstalováno zařízení kořenové CA, bude udržována vysoká úroveň bezpečnosti, aby bylo zaručeno, že:
·je izolováno od sítí mimo model služeb vytvářejících důvěru;
·je rozděleno do řad (alespoň dvou) postupně bezpečnějších fyzických obvodů;
·citlivé údaje (HSM, záloha párů klíčů, aktivační údaje atd.) se uchovávají ve vyhrazeném bezpečném fyzickém prostoru pod vícenásobnou kontrolou přístupu.
188)Používané bezpečnostní techniky musí být navrženy tak, aby odolaly vysokému počtu a kombinaci různých forem útoků. Používané mechanismy musí zahrnovat alespoň:
·obvodová poplašná zařízení, uzavřené televizní okruhy, zesílené stěny a detektory pohybu,
·dvoufaktorovou autentizaci (např. čipová karta a PIN) pro každou osobu a průkaz pro vstup a opuštění zařízení kořenové CA a bezpečné fyzické zabezpečené oblasti.
189)Kořenová CA, CPOC a TLM používají pověřené pracovníky k nepřetržitému průběžnému sledování zařízení, kde je umístěno vybavení, i mimo obvyklé pracovní doby po celý rok. Provozní prostředí (např. fyzické zařízení) není nikdy ponecháno bez dozoru. Pracovníci provozního prostředí nemají nikdy přístup do zabezpečených oblastí kořenových CA nebo podřízených CA, pokud nejsou pověřeni.
5.1.1.2.EA/AA
190)Použijí se stejná ustanovení oddílu 5.1.1.1.
5.1.2.Fyzický přístup
5.1.2.1.Kořenová CA, CPOC, TLM
191)Zařízení a data (HSM, aktivační údaje, záloha páru klíčů, počítač, protokol, skript klíčové ceremonie, žádost o certifikát atd.) musí být vždy chráněny před neoprávněným přístupem. Fyzické bezpečnostní mechanismy musí přinejmenším:
·neustále manuálně nebo elektronicky sledovat neoprávněné vniknutí,
·zajistit, aby nebyl povolen žádný neoprávněný přístup k hardwarovým a aktivačním údajům,
·zajistit, aby všechna přenosná média a papír obsahující citlivé informace prostým textem byly uloženy v zabezpečeném kontejneru,
·zajistit, aby žádná osoba vstupující do bezpečných oblastí, která není trvale pověřena, nebyla ponechána bez dohledu pověřeného zaměstnance zařízení kořenové CA, CPOC a TLM,
·zajistit, aby byl pravidelně udržován a kontrolován přístupový protokol,
·poskytovat alespoň dvě vrstvy postupně se zvyšující bezpečnosti, např. na úrovni obvodu, budovy a operační místnosti,
·vyžadovat dvě kontroly fyzického přístupu ke kryptografickým, HSM a aktivačním datům prováděné důvěryhodnými rolemi.
192)Má-li být vybavení pro umístění zařízení ponecháno bez dozoru, musí být provedena jeho bezpečnostní kontrola. Tato kontrola musí minimálně ověřit, zda:
·je vybavení ve stavu vhodném pro aktuální provozní režim,
·jsou v případě off-line komponent všechna zařízení vypnuta,
·jsou veškeré bezpečnostní kontejnery (obálka odolná proti nedovolené manipulaci, trezor atd.) řádně zajištěny,
·fyzické bezpečnostní systémy (např. zámky dveří, kryty ventilace, elektrická energie) fungují správně,
·je tato oblast zabezpečena proti neoprávněnému přístupu.
193)Odnímatelné kryptografické moduly se před uskladněním deaktivují. Pokud se nepoužívají, musí být tyto moduly a aktivační údaje používané pro přístup k nim nebo jejich aktivaci umístěny v trezoru. Aktivační údaje se buď memorizují, nebo zaznamenají a uloží způsobem odpovídajícím zabezpečení, které se poskytuje kryptografickému modulu. Nesmějí být uloženy spolu s kryptografickým modulem, aby se zabránilo tomu, že přístup k soukromému klíči bude mít pouze jedna osoba.
194)Za provedení těchto kontrol musí být výslovně odpovědná osoba nebo skupina důvěryhodných rolí. Je-li odpovědná skupina osob, vede se protokol, který identifikuje osobu, jež provádí každou kontrolu. Není-li zařízení nepřetržitě dozorováno, musí poslední osoba, která odchází, parafovat odhlašovací list, který uvádí datum a čas, a potvrdí, že byly zavedeny a aktivovány všechny nezbytné mechanismy fyzické ochrany.
5.1.2.2.EA/AA
195)Použijí se stejná ustanovení oddílu 5.1.2.1.
5.1.3.Napájení a klimatizace
196)Zabezpečená zařízení prvků C-ITS modelu služeb vytvářejících důvěru (kořenovou CA, CPOC, TLM, EA a AA) musí být vybavena spolehlivým přístupem k elektrické energii pro zajištění provozu bez poruch či s drobnými poruchami. Jsou nutná primární a záložní zařízení pro případ výpadku vnější energie a hladkého odstavení vybavení C-ITS modelu služeb vytvářejících důvěru v případě nedostatku energie. Zařízení C-ITS modelu služeb vytvářejících důvěru musí být vybavena topným, ventilačním a klimatizačním systémem, aby byla zachována teplota a relativní vlhkost vybavení C-ITS modelu služeb vytvářejících důvěru v provozním rozsahu. CPS prvků C-ITS modelu služeb vytvářejících důvěru budou podrobně popisovat plán a postupy pro provádění těchto požadavků.
5.1.4.Vystavení vodě
197)Zabezpečená zařízení prvků C-ITS modelu služeb vytvářejících důvěru (kořenová CA, CPOC, TLM, EA a AA) by měla být chráněna způsobem, který minimalizuje vliv vystavení vodě. Z tohoto důvodu je třeba se vyhnout potrubí na vodu a odpadnímu potrubí. CPS prvků C-ITS modelu služeb vytvářejících důvěru budou podrobně popisovat plán a postupy pro provádění těchto požadavků.
5.1.5.Protipožární opatření a ochrana
198)Aby se předešlo ničivému vlivu plamenů nebo kouře, musí být zabezpečená zařízení prvků C-ITS modelu služeb vytvářejících důvěru (kořenová CA, CPOC, TLM, EA a AA) konstruována a vybavena odpovídajícím způsobem a musí být prováděny postupy pro řešení hrozeb souvisejících s požáry. Paměťová média by měla být chráněna před požárem ve vhodných kontejnerech.
199)Prvky C-ITS modelu služeb vytvářejících důvěru chrání fyzická média obsahující zálohu kritických systémových dat nebo jakékoli jiné citlivé informace před přírodními nebezpečími a neoprávněným použitím, přístupem k nim nebo jejich zveřejněním. CPS prvků C-ITS modelu služeb vytvářejících důvěru budou podrobně popisovat plán a postupy pro provádění těchto požadavků.
5.1.6.Správa médií
200)S médii používanými v prvcích C-ITS modelu služeb vytvářejících důvěru (kořenové CA, CPOC, TLM, EA a AA) se nakládá bezpečně, aby byla chráněna před poškozením, krádeží a neoprávněným přístupem. Implementují se postupy pro správu médií pro ochranu proti zastarávání a zhoršování stavu médií po dobu, po kterou je nutné uchovávat záznamy.
201)Citlivé údaje se chrání proti přístupu v důsledku opětovného použití dočasných pamětí (např. vymazaných souborů), které mohou zpřístupnit citlivé údaje neoprávněným uživatelům.
202)Udržuje se soupis všech informačních aktiv a musí být stanoveny požadavky na ochranu těchto aktiv, které jsou v souladu s analýzou rizik. CPS prvků C-ITS modelu služeb vytvářejících důvěru budou podrobně popisovat plán a postupy pro provádění těchto požadavků.
5.1.7.Likvidace odpadu
203)Prvky C-ITS modelu služeb vytvářejících důvěru (kořenová CA, CPOC, TLM, EA a AA) implementují postupy pro bezpečnou a nevratnou likvidaci odpadu (papíru, médií nebo jakéhokoli jiného odpadu), aby se zabránilo neoprávněnému použití odpadů obsahujících důvěrné/soukromé informace, přístupu k nim nebo jejich zveřejnění. Všechna média používaná k uchovávání citlivých informací, jako jsou klíče, aktivační údaje nebo soubory, se před uvolněním k likvidaci zničí. CPS prvků C-ITS modelu služeb vytvářejících důvěru budou podrobně popisovat plán a postupy pro provádění těchto požadavků.
5.1.8.Záloha mimo pracoviště
5.1.8.1.Kořenová CA, CPOC a TLM
204)Plné zálohy komponent kořenových CA, CPOC a TLM, které jsou dostatečné pro zotavení po selhání systému, se provádí off-line po zavedení kořenových CA, CPOC a TLM a po každém novém generování páru klíčů. Pravidelně se provádějí záložní kopie důležitých obchodních informací (pár klíčů a CRL) a programového vybavení. Jsou k dispozici odpovídající záložní zařízení, aby se zajistilo, že po havárii nebo selhání médií lze obnovit veškeré důležité obchodní informace a programové vybavení. Pravidelně se testují zálohovací režimy pro jednotlivé systémy, aby se zajistilo, že splňují požadavky plánu kontinuity provozu. Alespoň jedna úplná záložní kopie je uložena mimo pracoviště (obnova po haváriích). Záložní kopie je uložena v místě, kde fyzické a procedurální kontroly odpovídají kontrolám provozního systému PKI.
205)Zálohované údaje podléhají stejným požadavkům na přístup jako provozní údaje. Zálohované údaje musí být šifrovány a uloženy mimo pracoviště. V případě úplné ztráty dat musí být informace potřebné pro uvedení kořenové CA, CPOC a TLM zpět do provozu plně obnoveny ze zálohovaných dat.
206)Materiál soukromých klíčů kořenové CA, CPOC a TLM se nesmí zálohovat pomocí standardních záložních mechanismů, ale pomocí záložní funkce kryptografického modulu.
5.1.8.2.EA/AA
207)Pro tento oddíl platí postupy popsané v oddíle 5.1.8.1.
5.2.Procedurální kontroly
Tento oddíl popisuje požadavky na role, povinnosti a identifikaci pracovníků.
5.2.1.Důvěryhodné role
208)Zaměstnanci, externí dodavatelé a konzultanti, kterým jsou přiděleny důvěryhodné role, se považují za „důvěryhodné osoby“. Osoby, které se chtějí stát se důvěryhodnými, aby získaly důvěryhodné postavení, musí splňovat požadavky této certifikační politiky na prověřování.
209)Důvěryhodné osoby mají přístup k autentizačním či kryptografickým operacím (nebo je kontrolují), které mohou podstatně ovlivnit:
·validaci informací v žádostech o certifikát,
·přijetí, zamítnutí nebo jiné zpracování žádostí o certifikát, žádostí o odvolání nebo žádostí o obnovu,
·vydávání nebo odvolávání certifikátů, včetně pracovníků, kteří mají přístup k omezeným částem jejich úložiště, nebo nakládání s informacemi o účastníkovi či žádostmi účastníka.
210)Důvěryhodné role zahrnují mimo jiné:
·zákaznické služby,
·správu systému,
·pověřené inženýrství,
·vedoucí pracovníky, kteří jsou pověřeni řízením důvěryhodnosti infrastruktury.
211)Certifikační autorita poskytne jasné popisy všech důvěryhodných rolí ve své CPS.
5.2.2.Počet osob požadovaný pro každý úkol
212)Prvky C-ITS modelu služeb vytvářejících důvěru musí zřídit, udržovat a prosazovat přísné postupy kontroly, aby bylo zajištěno oddělení povinností na základě důvěryhodných rolí a to, že k provádění citlivých úkolů je zapotřebí několika důvěryhodných osob. Prvky C-ITS modelu služeb vytvářejících důvěru (TLM, CPOC, kořenová CA, EA a AA) by měly splňovat [4] a požadavky následujících odstavců.
213)Jsou zavedeny postupy politiky a kontroly, které zajišťují oddělení povinností na základě z pracovní odpovědnosti. Nejcitlivější úkoly, jako je přístup ke kryptografickému hardwaru CA (hardwarový bezpečnostní modul – HSM) a jeho souvisejícímu klíčovému materiálu a jejich řízení, musí vyžadovat zmocnění několika důvěryhodných osob.
214)Tyto postupy vnitřní kontroly jsou navrženy tak, aby zajistily, že jsou pro fyzický nebo logický přístup k zařízení vyžadovány alespoň dvě důvěryhodné osoby. Omezení přístupu ke kryptografickému hardwaru CA musí být přísně prosazováno několika důvěryhodnými osobami po celou dobu jeho životního cyklu, a to od vstupního převzetí a inspekce až po konečnou logickou a/nebo fyzickou likvidaci. Jakmile je modul aktivován provozními klíči, jsou zavedeny další kontroly přístupu s cílem zachovat rozdělenou kontrolu nad fyzickým a logickým přístupem k zařízení.
5.2.3.Identifikace a autentizace pro každou roli
215)Všechny osoby, kterým byla přidělena role, jak je popsáno v této CP, jsou identifikovány a autentizovány, aby bylo zaručeno, že jim tato role umožní plnění jejich povinností v rámci PKI.
216)Prvky C-ITS modelu služeb vytvářejících důvěru musí ověřit a potvrdit totožnost a zmocnění všech pracovníků, kteří se chtějí stát důvěryhodnými osobami, dříve než jsou jim:
·vydána jejich zařízení pro přístup a poskytnut přístup k požadovaným zařízením,
·přidělena elektronická oprávnění pro přístup a vykonávání specifických funkcí v systémech CA.
217)CPS popisuje mechanismy používané k identifikaci a autentizaci jednotlivců.
5.2.4.Role vyžadující oddělení povinností
218)Role vyžadující oddělení povinností zahrnují (mimo jiné):
·přijetí, zamítnutí a odvolání žádostí a jiné zpracování žádostí o certifikát CA,
·generování, vydávání a likvidaci certifikátu CA.
219)Oddělení povinností může být prosazováno s použitím vybavení PKI, postupů nebo obojího. Žádnému jednotlivci nesmí být přidělena více než jedna totožnost, není-li to schváleno kořenovou CA.
220)Část kořenové CA a CA, která se zabývá generováním certifikátů a správou odvolávání, musí být při svém rozhodování týkajícím se zřizování, poskytování, udržování a pozastavování služeb v souladu s platnou certifikační politikou nezávislá na jiných organizacích. Zejména její vyšší vedoucí pracovník, vedoucí pracovníci a pracovníci v důvěryhodných úlohách nesmí podléhat žádným komerčním, finančním nebo jiným tlakům, které by mohly nepříznivě ovlivnit důvěru ve služby, které poskytuje.
221)EA a AA, které slouží mobilním stanicím C-ITS, jsou samostatné provozní subjekty se samostatnými týmy infrastruktury IT a řízení IT. V souladu s GDPR si EA a AA nesmějí vyměňovat žádné osobní údaje s výjimkou povolování žádostí o AT. Údaje týkající se schvalování žádostí o AT si předávají pouze s použitím protokolu pro validaci autorizace dle [1] přes vyhrazené bezpečné rozhraní. Za předpokladu, že bude implementováno [1], mohou být použity jiné protokoly.
222)Protokolové soubory uložené EA a AA mohou být použity výhradně pro účel odvolání EC porušujících pravidla na základě AT v zachycených zlovolných zprávách CAM/DENM. Poté, co byla zpráva CAM/DENM identifikována jako zlovolná, vyhledá AA ve svých protokolech o vydávání klíč pro ověřování AT a předloží EA žádost o odvolání obsahující zašifrovaný podpis pro soukromý klíč EC, který byl použit při vydání AT. Všechny protokolové soubory musí být odpovídajícím způsobem chráněny před přístupem neoprávněných stran a nesmí být sdíleny s jinými subjekty nebo orgány.
Pozn.: V době sepsání této verze CP není koncepce funkce porušení pravidel / pochybení definována. V budoucích revizích této politiky je plánováno případně koncipovat funkci porušení pravidel / pochybení.
5.3.Kontroly pracovníků
5.3.1.Požadavky na kvalifikace, zkušenosti a ověření spolehlivosti
223)Prvky C-ITS modelu služeb vytvářejících důvěru zaměstnávají dostatečný počet pracovníků s odbornými znalostmi, zkušenostmi a kvalifikacemi potřebnými pro pracovní funkce a nabízené služby. Pracovníci PKI splňují tyto požadavky prostřednictvím oficiálního výcviku a oprávnění, vlastních zkušeností nebo kombinací obojího. Důvěryhodné role a povinnosti, jak jsou upřesněny v CPS, jsou zdokumentovány v popisech práce a jasně stanoveny. Pracovníci PKI, kteří jsou subdodavateli, mají popisy práce definovány tak, aby zajistily oddělení povinností a výsad, a citlivost postavení se určuje na základě povinností a úrovní přístupu, ověření spolehlivosti a školení a povědomí zaměstnanců.
5.3.2.Postupy ověření spolehlivosti
224)Prvky C-ITS modelu služeb vytvářejících důvěru provádí ověření spolehlivosti pracovníků, kteří se chtějí stát důvěryhodnými osobami. U pracovníků, kteří zastávají důvěryhodné funkce, se ověření spolehlivosti opakují nejméně jednou za pět let.
225)Faktory zjištěné při ověření spolehlivosti, které mohou být považovány za důvody pro odmítnutí kandidátů na důvěryhodné pozice nebo pro přijetí opatření vůči stávající důvěryhodné osobě, zahrnují (mimo jiné):
·poskytnutí nesprávných informací kandidátem nebo důvěryhodnou osobou,
·velmi nepříznivá nebo nespolehlivá pracovní doporučení,
·některé rozsudky v trestních věcech,
·známky nedostatečné finanční odpovědnosti.
226)Zprávy obsahující tyto informace vyhodnotí pracovníci v oblasti lidských zdrojů, kteří přijmou přiměřená opatření s ohledem na druh, rozsah a četnost chování zjištěného ověřením spolehlivosti. Může jít o opatření až po a včetně odvolání nabídek zaměstnání učiněných kandidátům na důvěryhodné pozice nebo ukončení pracovního poměru stávajících důvěryhodných osob. Použití informací zjištěných při ověření spolehlivosti jako základu pro takové opatření podléhá platným právním předpisům.
227)Osobní prověrka osob, které se chtějí stát důvěryhodnými, zahrnuje mimo jiné:
·potvrzení předchozího zaměstnání,
·kontrolu pracovních doporučení vztahujících se na jejich zaměstnání po dobu nejméně pěti let,
·potvrzení nejvyššího nebo nejvýznamnějšího stupně dosaženého vzdělání,
·výpis z rejstříku trestů.
5.3.3.Požadavky na výcvik
228)Prvky C-ITS modelu služeb vytvářejících důvěru poskytnou svým pracovníkům potřebnou odbornou přípravu, aby mohli kvalifikovaně a uspokojivě plnit své povinnosti související s činnostmi CA.
229)Programy odborné přípravy jsou pravidelně přezkoumávány a jejich výcvik se zabývá otázkami, které se týkají funkcí vykonávaných zúčastněnými pracovníky.
230)Programy odborné přípravy se týkají záležitostí důležitých pro konkrétní prostředí školené osoby, včetně:
·bezpečnostních zásad a mechanismů prvků C-ITS modelu služeb vytvářejících důvěru,
·používaných verzí hardwaru a softwaru,
·všech povinností, které má osoba plnit, a interních a externích procesů a sekvencí podávání zpráv,
·obchodních procesů a postupů PKI,
·hlášení incidentů a ohrožení a nakládání s nimi,
·postupů pro obnovu po haváriích a kontinuitu provozu,
·dostatečných znalostí v oblasti IT.
5.3.4.Četnost rekvalifikace a požadavky na ni
231)Osoby, kterým jsou přiděleny důvěryhodné úlohy, jsou povinny si ve vzdělávacím prostředí průběžně osvěžovat znalosti, které získali v rámci odborné přípravy. Odborná příprava se musí opakovat, kdykoli je to považováno za potřebné, a alespoň každé dva roky.
232)Prvky C-ITS modelu služeb vytvářejících důvěru poskytnou svým pracovníkům opakovací školení a aktualizace v rozsahu a frekvenci potřebné k tomu, aby se zajistilo, že si udržují požadovanou úroveň odborné způsobilosti, aby své pracovní povinnosti mohli plnit kvalifikovaně a uspokojivě.
233)Osoby v důvěryhodných úlohách musí být dle potřeby informovány o změnách v činnostech PKI. Každou významnou změnu činností musí doprovázet plán odborné přípravy (informovanosti) a provedení tohoto plánu musí být zdokumentováno.
5.3.5.Četnost rotace pracovních míst a jejich pořadí
234)Není stanoveno, pokud jsou zajištěny technické dovednosti, zkušenosti a přístupová práva. Správci prvků C-ITS modelu služeb vytvářejících důvěru zajistí, aby personální změny neměly vliv na bezpečnost systému.
5.3.6.Sankce za neautorizované činnosti
235)Každý z prvků C-ITS modelu služeb vytvářejících důvěru musí vyvinout formální disciplinární řízení s cílem zajistit, aby neoprávněné činnosti byly odpovídajícím způsobem postihovány. V závažných případech je třeba odejmout přidělení rolí a odpovídající výsady.
5.3.7.Požadavky na nezávislé dodavatele
236)Prvky C-ITS modelu služeb vytvářejících důvěru mohou nezávislým dodavatelům nebo konzultantům povolit, aby se stali důvěryhodnými osobami, pouze v rozsahu nezbytném pro jasně definované vztahy externího poskytování služeb a pod podmínkou, že daný subjekt dodavatelům nebo konzultantům důvěřuje ve stejném rozsahu, jako kdyby byli zaměstnanci, a že oni splňují požadavky vztahující se na zaměstnance.
237)V opačném případě mají nezávislí dodavatelé a konzultanti do zabezpečených zařízení C-ITS PKI přístup, pouze pokud jsou doprovázeni důvěryhodnými osobami a jsou pod jejich přímým dozorem.
5.3.8.Dokumentace poskytovaná pracovníkům
238)Prvky C-ITS modelu služeb vytvářejících důvěru poskytnou svým pracovníkům nezbytnou odbornou přípravu a přístup k dokumentaci, kterou potřebují, aby kvalifikovaně a uspokojivě plnili své pracovní povinnosti.
5.4.Postupy protokolování auditu
239)Tento oddíl stanoví požadavky týkající se typů událostí, které mají být zaznamenávány, a správy auditních protokolů.
5.4.1.Typy událostí, které mají být zaznamenávány a oznamovány každou CA
240)Zástupce CA pravidelně přezkoumává protokoly, události a postupy CA.
241)Prvky C-ITS modelu služeb vytvářejících důvěru zaznamenávají následující typy kontrolních událostí (je-li to relevantní):
·fyzický přístup k zařízením – přístup fyzických osob k zařízením se zaznamená ukládáním žádostí o přístup pomocí čipových karet. Událost bude vytvořena pokaždé, když dojde k vytvoření záznamu,
·správa důvěryhodných úloh – bude zaznamenána každá změna v definici a úrovni přístupu různých rolí, včetně úpravy atributů úloh. Událost bude vytvořena pokaždé, když dojde k vytvoření záznamu,
·logický přístup – událost bude generována, když má subjekt (např. program) přístup k citlivým oblastem (tj. sítím a serverům),
·správa záloh – událost se vytvoří pokaždé, když je dokončena záloha, a to buď úspěšně, nebo neúspěšně,
·správa protokolů – protokoly budou uloženy. Událost se vytvoří, když protokol překročí určitou velikost,
·údaje z procesu autentizace účastníků a prvků C-ITS modelu služeb vytvářejících důvěru – budou generovány události pro každou žádost o autentizaci účastníků a prvků C-ITS modelu služeb vytvářejících důvěru,
·přijetí a zamítnutí žádostí o certifikát, včetně vytvoření a obnovy certifikátu – událost bude pravidelně generována se seznamem přijatých a zamítnutých žádostí o certifikát v předchozích sedmi dnech,
·registrace výrobce – událost se vytvoří v okamžiku registrace výrobce,
·registrace stanice C-ITS – událost se vytvoří v okamžiku registrace stanice C-ITS,
·správa HSM – událost se vytvoří v okamžiku, kdy je zaznamenáno narušení zabezpečení hardwarového bezpečnostního modulu,
·správa IT a sítě, pokud náleží k systémům PKI – událost se vytvoří v okamžiku, kdy je server PKI odstaven nebo znovu nastartován,
·řízení bezpečnosti (úspěšné a neúspěšné pokusy o přístup k PKI, provedené činnosti PKI a bezpečnostního systému, změny bezpečnostního profilu, zhroucení systému, selhání hardwaru a jiné anomálie, činnosti firewallu a routeru a vstupy do zařízení PKI a odchody z nich),
·údaje týkající se událostí budou uchovávány po dobu nejméně pěti let, pokud se neuplatní další vnitrostátní pravidla.
242)V souladu s GDPR neumožňují auditní protokoly přístup k údajům týkajícím se soukromí ohledně soukromých vozidel stanic C-ITS.
243)Je-li to možné, jsou protokoly bezpečnostních auditů shromažďovány automaticky. Kde to možné není, použije se protokolový deník, papírový formulář nebo jiný fyzický mechanismus. Uchovávají se všechny protokoly bezpečnostních auditů, elektronické i neelektronické, a zpřístupňují se během auditů souladu.
244)Každá událost spojená s životním cyklem certifikátu je zaznamenána tak, aby bylo možné ji přičíst osobě, která ji provedla. Všechny údaje týkající se osobní totožnosti jsou šifrovány a chráněny před neoprávněným přístupem.
245)Každý kontrolní záznam obsahuje přinejmenším tyto údaje (které jsou pro každou událost podléhající auditu automaticky nebo ručně zaznamenány):
·druh události (podle seznamu uvedeného výše),
·důvěryhodné datum a čas, kdy k události došlo,
·výsledek události – úspěch či případně neúspěch,
·případně totožnost subjektu a/nebo provozovatele, který událost způsobil,
·totožnost subjektu, jehož se událost týká.
5.4.2.Četnost zpracování protokolu
246)Auditní protokoly se přezkoumávají v reakci na upozornění založená na nesrovnalostech a incidentech v rámci systémů CA a navíc pravidelně každý rok.
247)Zpracování auditních protokolů sestává z jejich přezkumu a dokumentování důvodu všech významných událostí ve shrnutí auditního protokolu. Přezkumy auditních protokolů zahrnují ověření, že s protokolem nebylo nedovoleně manipulováno, kontrolu všech položek protokolu a šetření veškerých upozornění nebo nesrovnalostí v protokolech. Opatření přijatá na základě přezkumů kontrolních záznamů musí být zdokumentována.
248)Auditní protokol je nejméně jednou týdně archivován. Je-li volný diskový prostor pro auditní protokol menší než očekávaný objem údajů auditního protokolu vytvořený v daném týdnu, správce jej archivuje manuálně.
5.4.3.Doba uchovávání auditního protokolu
249)Kontrolní záznamy týkající se životních cyklů certifikátů se uchovávají po dobu nejméně pěti let od skončení platnosti příslušného certifikátu.
5.4.4.Ochrana auditního protokolu
250)Integrita a důvěrnost auditního protokolu je zaručena kontrolním mechanismem přístupu na základě role. Přístup k interním auditním protokolům mají pouze správci; k auditním protokolům týkajícím se životního cyklu certifikátů mohou mít přístup také uživatelé s příslušnou autorizací prostřednictvím webové stránky s uživatelským přihlášením. Musí být zajištěn přístup více uživatelů (alespoň 2 uživatelé) a nejméně dvouúrovňová autentizace. Je nutné technicky zajistit, aby uživatelé neměli přístup ke svým vlastním protokolovým souborům.
251)Každá položka protokolu se podepíše pomocí klíčového materiálu z HSM.
252)Protokoly o událostech obsahující informace, které mohou vést k osobní identifikaci, například soukromého vozidla, jsou šifrovány tak, že je mohou přečíst pouze oprávněné osoby.
253)Události jsou zaprotokolovány tak, aby je nebylo možné snadno vymazat nebo zlikvidovat (s výjimkou přenosu na dlouhodobá média) během období, po které se protokoly musí uchovávat.
254)Protokoly o událostech jsou chráněny tak, aby byly čitelné po dobu svého uložení.
5.4.5.Postupy zálohování auditního protokolu
255)Auditní protokoly a shrnutí jsou zálohovány pomocí podnikových zálohovacích mechanismů, které jsou pod kontrolou oprávněných důvěryhodných rolí oddělených od jejich generování zdrojů komponent. Zálohy auditního protokolu jsou chráněny se stejnou úrovní důvěry, jaká platí pro původní protokoly.
5.4.6.Auditní systém sběru údajů (interní nebo externí)
256)Vybavení prvků C-ITS modelu služeb vytvářejících důvěru aktivuje auditní procesy při spuštění systému a deaktivuje je pouze při odstávce systému. Nejsou-li auditní procesy k dispozici, prvek C-ITS modelu služeb vytvářejících důvěru přeruší svou činnost.
257)Na konci každého provozního období a při změně klíčů certifikátů by měl být provoznímu manažerovi a řídicímu orgánu příslušného prvku PKI vykázán společný stav zařízení.
5.4.7.Oznámení subjektu, který událost způsobil
258)Je-li událost zaznamenána systémem auditního sběru, zaručuje to, že je událost spojena s důvěryhodnou rolí.
5.4.8.Hodnocení zranitelnosti
259)Role odpovědná za provádění auditu a role odpovědné za realizaci provozu systému PKI v prvcích C-ITS modelu služeb vytvářejících důvěru vysvětlují všechny významné události ve shrnutí auditních protokolů. Součástí těchto přezkumů je ověření, zda s protokolem nebylo nedovoleně manipulováno a zda nedošlo k narušení kontinuity nebo jiné ztrátě auditních údajů, a poté stručná kontrola všech položek protokolů a důkladnější prošetření jakýchkoli upozornění či nesrovnalostí v protokolech. Opatření přijatá v důsledku těchto přezkumů jsou zdokumentována.
260)Prvky C-ITS modelu služeb vytvářejících důvěru musí:
·provádět organizační a/nebo technické detekční a preventivní kontroly pod kontrolou prvků C-ITS modelu služeb vytvářejících důvěru za účelem ochrany systémů PKI proti virům a škodlivému softwaru,
·dokumentovat proces nápravy zranitelnosti, který se zabývá identifikací a přezkumem zranitelných míst, reakcí na ně a jejich nápravou, a řídit se jím,
·podstoupit nebo provést kontrolu zranitelnosti,
·po všech změnách systému nebo sítě, které prvky C-ITS modelu služeb vytvářejících důvěru určí jako významné pro komponenty PKI, a
·alespoň jednou měsíčně na veřejných a soukromých IP adresách určených CA a CPOC jako systémy PKI,
·podstoupit zkoušku průrazem systémů PKI alespoň jednou ročně a po modernizaci nebo úpravách infrastruktury nebo aplikace určených prvky C-ITS modelu služeb vytvářejících důvěru jako významné pro komponenty PKI CA,
·u on-line systémů zaznamenávat důkazy o tom, že každá kontrola zranitelnosti a zkouška průrazem byla provedena osobou nebo subjektem (či jejich kolektivní skupinou) s dovednostmi, nástroji, odbornou způsobilostí, etickým kodexem a nezávislostí, jež jsou nezbytné pro zajištění spolehlivé kontroly zranitelnosti či zkoušky průrazem,
·sledovat a napravit zranitelná místa v souladu s podnikovou politikou v oblasti kybernetické bezpečnosti a s metodikou snižování rizika.
5.5.Archivace záznamů
5.5.1.Typy archivovaných záznamů
261)Prvky C-ITS modelu služeb vytvářejících důvěru archivují záznamy dostatečně podrobné pro stanovení platnosti podpisu a řádného provozu PKI. Archivují se minimálně tyto záznamy událostí PKI (jsou-li příslušné):
·protokol fyzického přístupu k prvkům C-ITS modelu služeb vytvářejících důvěru (nejméně jeden rok),
·protokol řízení důvěryhodných rolí pro prvky C-ITS modelu služeb vytvářejících důvěru (nejméně 10 let),
·protokol přístupu k IT pro prvky C-ITS modelu služeb vytvářejících důvěru (nejméně pět let),
·protokol vytvoření, používání a likvidace klíče CA (minimálně pět let) (ne pro TLM a CPOC),
·protokol vytvoření, používání a likvidace certifikátu (nejméně dva roky),
·protokol žádosti CPA (nejméně dva roky),
·protokol správy aktivačních údajů pro prvky C-ITS modelu služeb vytvářejících důvěru (nejméně pět let),
·protokol IT a sítě pro prvky C-ITS modelu služeb vytvářejících důvěru (nejméně pět let),
·dokumentace PKI pro prvky C-ITS modelu služeb vytvářejících důvěru (nejméně pět let),
·zpráva o bezpečnostních incidentech a auditu pro prvky C-ITS modelu služeb vytvářejících důvěru (nejméně 10 let),
·systémové vybavení, software a konfigurace (nejméně pět let).
262)Prvky C-ITS modelu služeb vytvářejících důvěru uchovávají tuto dokumentaci týkající se žádostí o certifikát a jejich ověřování a všech certifikátů TLM, kořenových CA a CA a jejich CRL po dobu nejméně sedmi let po ukončení platnosti jakéhokoli certifikátu založeného na této dokumentaci:
·dokumentace k auditu PKI vedená prvky C-ITS modelu služeb vytvářejících důvěru,
·dokumenty CPS vedené prvky C-ITS modelu služeb vytvářejících důvěru,
·smlouva mezi CPA a jinými subjekty uchovávaná prvky C-ITS modelu služeb vytvářejících důvěru,
·certifikáty (nebo jiné informace o odvolání) vedené CA a TLM,
·záznamy žádostí o certifikát v systému kořenové CA (nevztahuje se na TLM),
·jiné údaje nebo žádosti dostatečné k ověření obsahu archivu,
·veškerá práce související s prvky C-ITS modelu služeb vytvářejících důvěru a auditory souladu, nebo jimi prováděná.
263)Subjekt CA uchovává veškerou dokumentaci týkající se žádostí o certifikát a jejich ověřování a všech certifikátů a jejich odvolání po dobu nejméně sedmi let po ukončení platnosti jakéhokoli certifikátu založeného na této dokumentaci.
5.5.2.Doba uchovávání v archivu
264)Aniž jsou dotčeny předpisy, které vyžadují delší dobu archivace, prvky C-ITS modelu služeb vytvářejících důvěru uchovávají všechny záznamy po dobu nejméně pěti let po uplynutí doby platnosti příslušného certifikátu.
5.5.3.Ochrana archivu
265)Prvky C-ITS modelu služeb vytvářejících důvěru uchovávají archiv záznamů v bezpečném a zabezpečeném skladovacím zařízení, které je oddělené od vybavení CA, s fyzickými a procedurálními bezpečnostními kontrolami, které jsou rovnocenné nebo lepší než kontroly PKI.
266)Archiv musí být chráněn proti neoprávněnému prohlížení, pozměňování, mazání nebo jiné nedovolené manipulaci uložením v důvěryhodném systému.
267)Média, na kterých se archivní údaje nachází, a aplikace nutné k jejich zpracování se uchovávají, aby se zajistilo, že k nim bude možný přístup po dobu stanovenou v této CP.
5.5.4.Systémový archiv a uchovávání
268)Prvky C-ITS modelu služeb vytvářejících důvěru každodenně inkrementálně zálohují systémové archivy těchto informací a každý týden provádí úplné zálohy. Kopie záznamů v listinné podobě se uchovávají v zabezpečeném zařízení mimo pracoviště.
5.5.5.Požadavky na časová razítka záznamů
269)Prvky C-ITS modelu služeb vytvářejících důvěru, které spravují databázi odvolání, zajistí, aby záznamy obsahovaly informace o času a datu, kdy byly záznamy o odvolání vytvořeny. Integrita těchto informací bude provedena pomocí řešení založených na šifrování.
5.5.6.Systém archivace (interní nebo externí)
270)Systém archivace je interní.
5.5.7.Postupy získávání a ověřování archivních informací
271)Všechny prvky C-ITS modelu služeb vytvářejících důvěru umožní přístup do archivu pouze oprávněným důvěryhodným osobám. Kořenové CA a CA popíší postupy vytváření, ověřování, balení, předávání a ukládání archivních informací v CPS.
272)Vybavení kořenových CA a CA ověří integritu informací před jejich obnovením.
5.6.Změna klíčů pro prvky C-ITS modelu služeb vytvářejících důvěru
273)Uvedené prvky C-ITS modelu služeb vytvářejících důvěru mají specifické požadavky na změnu svých klíčů: certifikáty TLM, kořenové CA a EA/AA.
5.6.1.TLM
274)TLM smaže svůj soukromý klíč po uplynutí platnosti odpovídajícího certifikátu. Před deaktivací stávajícího platného soukromého klíče generuje nový pár klíčů a odpovídající certifikát TLM. Dbá na to, aby nový (spojovací) certifikát byl včas vložen do ECTL, aby byl distribuován všem stanicím C-ITS před tím, než se stane platným. Spojovací certifikát a nový samopodepsaný certifikát se převádí do CPOC.
5.6.2.Kořenová CA
275)Kořenová CA deaktivuje a vymaže stávající soukromý klíč (včetně záložních klíčů), aby nevydávala certifikáty EA/AA s platností, která přesahuje platnost certifikátu kořenové CA.
276)Kořenová CA generuje před deaktivací stávajícího soukromého klíče (včetně záložních klíčů) nový pár klíčů a odpovídající certifikát kořenové CA a spojovací certifikát a zašle je TLM k vložení do ECTL. Doba platnosti nového certifikátu kořenové CA začíná běžet od plánované deaktivace stávajícího soukromého klíče. Kořenová CA dbá na to, aby byl nový certifikát včas vložen do ECTL, aby byl distribuován všem zařízením C-ITS před tím, než se stane platným.
277)Kořenová CA aktivuje nový soukromý klíč, jakmile se odpovídající základní certifikát kořenové CA stane platným.
5.6.3.Certifikát EA/AA
278)EA/AA deaktivuje stávající soukromý klíč, aby nevydával certifikáty EC/AT s platností, která přesahuje platnost certifikátu EA/AA.
279)EA/AA generuje nový pár klíčů a před deaktivací stávajícího soukromého klíče si vyžádá odpovídající certifikát EA/AA. Doba platnosti nového certifikátu EA/AA začíná běžet od plánované deaktivace stávajícího soukromého klíče. EA/AA dbá na to, aby mohl být nový certifikát včas zveřejněn, aby byl distribuován všem stanicím C-ITS před tím, než se stane platným.
280)Když se odpovídající certifikát EA/AA stane platným, EA/AA aktivuje nový soukromý klíč.
5.6.4.Auditor
Žádná ustanovení.
5.7.Obnova po ohrožení a havárii
5.7.1.Řešení incidentů a ohrožení
281)Prvky C-ITS modelu služeb vytvářejících důvěru monitorují průběžně své vybavení, aby odhalily možné hackerské pokusy nebo jiné formy ohrožení. V takovém případě provedou šetření s cílem určit povahu a stupeň poškození.
282)Odhalí-li pracovníci odpovědní za řízení kořenové CA nebo TLM možný hackerský pokus nebo jinou formu ohrožení, provedou šetření s cílem určit povahu a stupeň poškození. Je-li ohrožen soukromý klíč, odvolá se certifikát kořenové CA. Odborníci na bezpečnost IT v CPA posoudí rozsah možných škod, aby určili, zda musí být PKI přestavěna, zda musí být pouze odvolány některé certifikáty a/nebo zda došlo k ohrožení PKI. CPA dále v souladu s plánem zachování provozu CPA určí, které služby mají být zachovány (informace o odvolání a stavu certifikátů), a jak.
283)Na incident, ohrožení a zachování provozu se vztahuje CPS, které pro svou implementaci může spoléhat také na jiné zdroje podniku a plány.
284)Odhalí-li pracovníci odpovědní za řízení EA/AA/CPOC možný hackerský pokus nebo jinou formu ohrožení, provedou šetření s cílem určit povahu a stupeň poškození. Pracovníci odpovědní za řízení subjektu CA nebo CPOC posoudí rozsah možných škod s cílem určit, zda musí být komponenta PKI přestavěna, zda musí být pouze odvolány některé certifikáty a/nebo zda byla ohrožena komponenta PKI. Subjekt podřízené CA navíc určí, které služby mají být v souladu s plánem zachování provozu subjektu podřízené CA zachovány, a jak. Je-li ohrožena komponenta PKI, subjekt CA upozorní svou vlastní kořenovou CA a TLM prostřednictvím CPOC.
285)Na incident, ohrožení a zachování provozu se vztahuje CPS kořenové CA nebo TLM či jiné příslušné dokumenty v případě CPOC, které se může rovněž spoléhat na jiné zdroje podniku a plány svého provádění.
286)Kořenová CA a CA upozorní s přesnými informacemi o důsledcích incidentu zástupce každého členského státu a kořenovou CA, s nímž mají dohodu v kontextu C-ITS, aby jim umožnil aktivovat jejich vlastní plán pro řešení incidentů.
5.7.2.Porušení výpočetních zdrojů, softwaru a/nebo dat
287)Je-li zjištěna havárie, která brání řádnému fungování prvku C-ITS modelu služeb vytvářejících důvěru, zastaví tento prvek svou činnost a prošetří, zda došlo k ohrožení soukromého klíče (s výjimkou CPOC). Vadný hardware se co nejrychleji vymění a použijí se postupy popsané v oddílech 5.7.3 a 5.7.4.
288)Porušení výpočetních zdrojů, softwaru a/nebo dat se kořenové CA hlásí do 24 hodin v případě nejvyšší úrovně rizika. Všechny ostatní události musí být zahrnuty do pravidelné zprávy kořenové CA, EA a AA.
5.7.3.Postupy při ohrožení soukromého klíče subjektu
289)Je-li soukromý klíč kořenové CA ohrožen, ztracen, zničen nebo existuje podezření na jeho ohrožení, musí kořenová CA:
·pozastavit svůj provoz,
·zahájit plán obnovy po havárii a migrace,
·odvolat svůj certifikát kořenové CA,
·prošetřit „klíčovou otázku“, která vedla k ohrožení, a upozornit CPA, který certifikát kořenového CA odvolá prostřednictvím TLM (viz oddíl 7),
·upozornit všechny účastníky, s nimiž má dohodu.
290)Je-li klíč EA/AA ohrožen, ztracen, zničen nebo existuje-li podezření, že je ohrožen, musí EA/AA:
·pozastavit svůj provoz,
·odvolat svůj vlastní certifikát,
·vyšetřit „klíčovou otázku“ a uvědomit o ní kořenovou CA,
·upozornit účastníky, s nimiž existuje dohoda.
291)Je-li klíč EC nebo AT stanice C-ITS ohrožen, ztracen, zničen nebo existuje-li podezření na jeho ohrožení, musí EA/AA, u které je stanice C-ITS zapsána:
·odvolat EC dotčeného ITS,
·vyšetřit „klíčovou otázku“ a uvědomit o ní kořenovou CA,
·upozornit účastníky, s nimiž má dohodu.
292)Pokud se některý z algoritmů nebo souvisejících parametrů používaných kořenovou CA a/nebo CA či stanicemi C-ITS stane pro zbývající zamýšlené použití nedostatečným, musí CPA (s doporučením odborníků na šifrování) informovat subjekt kořenové CA, s nímž má dohodu, a změnit použité algoritmy. (Podrobnosti viz oddíl 6 a CPS kořenové CA a podřízené CA).
5.7.4.Schopnosti kontinuity činnosti po havárii
293)Prvky C-ITS modelu služeb vytvářejících důvěru, které provozují zabezpečené zařízení pro provoz CA, vypracují, přezkouší, udržují a provádí plán obnovy po havárii určený ke zmírnění následků jakýchkoli přírodních nebo člověkem způsobených katastrof. Tyto plány řeší obnovu služeb informačních systémů a klíčových obchodních funkcí.
294)Po incidentu s určitou úrovní rizika musí být ohrožená CA podrobena opakovanému auditu akreditovaným auditorem PKI (viz oddíl 8).
295)V případě, že ohrožená CA nemůže dále fungovat (např. po vážném incidentu), musí být vypracován plán migrace pro převedení jejích funkcí na jinou kořenovou CA. Na podporu plánu migrace musí být k dispozici alespoň kořenová CA EU. Ohrožená CA musí své funkce ukončit.
296)Kořenová CA zahrne plán obnovy po havárii a plán migrace do CPS.
5.8.Ukončení a převod
5.8.1.TLM
297)TLM nesmí ukončit svůj provoz, ale subjekt, který TLM řídí, může převzít jiný subjekt.
298)V případě změny řídícího subjektu:
·požádá CPA o schválení změny řízení TLM ze starého subjektu na nový subjekt,
·CPA schválí změnu řízení TLM,
·všechny auditní protokoly a archivované záznamy se převedou ze starého řídícího subjektu na nový.
5.8.2.Kořenová CA
299)Kořenová CA nesmí ukončit/zahájit svůj provoz, aniž by připravila plán migrace (stanovený v příslušné CPS), který zaručuje nepřetržitý provoz pro všechny účastníky.
300)V případě ukončení služby kořenové CA musí kořenová CA:
·uvědomit CPA,
·uvědomit TLM, aby mohl vymazat certifikát kořenové CA z ECTL,
·odvolat odpovídající kořenovou CA tím, že vydá CRL, který obsahuje ji samou,
·upozornit kořenové CA, s nimiž má dohodu o obnově certifikátů EA/AA,
·zlikvidovat soukromý klíč kořenové CA,
·sdělit spoléhající se straně poslední informace o stavu odvolání (CRL podepsaný kořenovou CA), přičemž jasně uvede, že se jedná o nejnovější informace o odvolání,
·archivovat veškeré auditní protokoly a jiné záznamy před ukončením PKI,
·předat archivované záznamy příslušnému orgánu.
301)TLM vymaže odpovídající certifikát kořenové CA z ECTL.
5.8.3.EA/AA
302)V případě ukončení služby EA/AA poskytne subjekt EA/AA oznámení před ukončením. EA nebo AA nesmí ukončit/zahájit svůj provoz, aniž by zřídila plán migrace (stanovený v příslušném CPS), který zaručuje průběžný provoz pro všechny účastníky. EA/AA musí:
·informovat kořenovou CA doporučeným dopisem,
·zlikvidovat soukromý klíč CA,
·přenést svou databázi do subjektu jmenovaného kořenovou CA,
·přestat vydávat certifikáty,
·během předávání své databáze a až do doby, kdy je databáze plně funkční v novém subjektu, zachovat schopnost autorizovat žádosti orgánu odpovědného za ochranu soukromí,
·pokud byla ohrožena podřízená CA, kořenová CA podřízenou CA odvolá a vydá nový CRL se seznamem odvolaných podřízených CA,
·archivovat veškeré auditní protokoly a jiné záznamy před ukončením PKI,
·přenést archivované záznamy do subjektu jmenovaného kořenovou CA.
303)V případě ukončení služeb CA je CA odpovědná za vedení veškerých příslušných záznamů týkajících se potřeb CA a komponent PKI.
6.Technické bezpečnostní kontroly
6.1.Generování a instalace páru klíčů
6.1.1.TLM, kořenová CA, EA, AA
304)Proces generování páru klíčů musí splňovat tyto požadavky:
·každý účastník je schopen generovat vlastní páry klíčů v souladu s oddíly 6.1.4 a 6.1.5,
·proces odvozování symetrických šifrovacích klíčů a klíče MAC pro žádosti o certifikát (ECIES) se provádí v souladu s [1] a [5],
·proces generování klíčů používá algoritmy a délky klíčů popsané v oddílech 6.1.4.1 a 6.1.4.2,
·na proces generování párů klíčů se vztahují požadavky na „bezpečné uchovávání soukromých klíčů“ (viz oddíl 6.1.5),
·kořenové CA a jejich účastníci (podřízené CA) zajistí, aby byly integrita a autenticita jejich veřejných klíčů a s nimi související parametry zachovány v průběhu distribuce subjektům registrovaným podřízeným CA.
6.1.2.Koncový subjekt – mobilní stanice C-ITS
305)Každá mobilní stanice C-ITS generuje své vlastní páry klíčů v souladu s oddíly 6.1.4 a 6.1.5.
306)Proces odvozování symetrických šifrovacích klíčů a klíče MAC pro žádosti o certifikát (ECIES) se provádí v souladu s [1] a [5].
307)Proces generování klíčů používá algoritmy a délky klíčů popsané v oddílech 6.1.4.1 a 6.1.4.2.
308)Na procesy generování párů klíčů se vztahují požadavky na „bezpečné uchovávání soukromých klíčů“ (viz oddíl 6.1.5).
6.1.3.Koncový subjekt – pevné stanice C-ITS
309)Každá pevná stanice C-ITS generuje své vlastní páry klíčů v souladu s oddíly 6.1.4 a 6.1.5.
310)Proces generování klíčů používá algoritmy a délky klíčů popsané v oddílech 6.1.4.1 a 6.1.4.2.
311)Na procesy generování párů klíčů se vztahují požadavky na „bezpečné uchovávání soukromých klíčů“ (viz oddíl 6.1.5).
6.1.4.Kryptografické požadavky
312)Účastníci PKI musí splňovat kryptografické požadavky stanovené v následujících odstavcích, pokud jde o algoritmus podpisu, délku klíče, generátor náhodných čísel a spojovací certifikáty.
6.1.4.1.Algoritmus a délka klíče – algoritmy podpisu
313)Všichni účastníci PKI (TLM, kořenový CA, EA, AA a stanice C-ITS) musí být schopni generovat páry klíčů a používat soukromý klíč pro podepisování operací s vybranými algoritmy nejpozději dva roky po vstupu tohoto nařízení v platnost v souladu s tabulkou 4.
314)Všichni účastníci PKI, kteří musí kontrolovat integritu ECTL, certifikátů a/nebo podepsaných zpráv v souladu s jejich rolí, jak je definována v oddíle 1.3.6, podpoří odpovídající algoritmy uvedené v tabulce 5 pro ověření. Zejména stanice C-ITS musí být schopny ověřit integritu ECTL.
|
TLM
|
kořenová CA
|
EA
|
AA
|
Stanice 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 označuje povinnou podporu
|
Tabulka 4: Generování párů klíčů a využití soukromého klíče pro podepisování operací
|
TLM
|
kořenová CA
|
EA
|
AA
|
Stanice 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 označuje povinnou podporu
|
Tabulka 5: Přehled ověření
315)Pokud tak CPA rozhodne na základě nově zjištěných nedostatků v oblasti šifrování, musí být všechna zařízení C-ITS schopna přejít co nejdříve na jeden ze dvou algoritmů (ECDSA_nistP256_s_SHA 256 nebo ECDSA_brainpoolP256_s_SHA 256). Skutečný algoritmus (algoritmy), který (které) je (jsou) použit(y), se určí v CPS CA, která vydává certifikát pro odpovídající veřejný klíč v souladu s touto CP.
6.1.4.2.Algoritmus a délka klíče – šifrovací algoritmy pro registraci a autorizaci
316)Všichni účastníci PKI (EA, AO a stanice C-ITS) musí být schopni používat veřejné klíče k šifrování žádostí o / odpovědí na registraci a autorizaci s vybranými algoritmy nejpozději dva roky po vstupu tohoto nařízení v platnost v souladu s tabulkou 6. Skutečný algoritmus (algoritmy), který (které) je (jsou) použit(y), se určí v CPS CA, která vydává certifikát pro odpovídající veřejný klíč v souladu s touto CP.
317)Jmenovitě uvedené algoritmy v tabulce 6 uvádějí délku klíče a délku algoritmu hash a provádějí se v souladu s [5].
|
TLM
|
kořenová CA
|
EA
|
AA
|
Stanice C-ITS
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X označuje povinnou podporu
|
Tabulka 6: Používání veřejných klíčů pro šifrování žádostí o / odpovědí na registraci a autorizaci
318)Všichni účastníci PKI (EA, AA a stanice C-ITS) musí mít možnost generovat klíčové páry a používat soukromý klíč k dekódování žádostí o / odpovědí na registraci a autorizaci s vybranými algoritmy nejpozději dva roky po vstupu tohoto nařízení v platnost v souladu s tabulkou 7:
|
TLM
|
kořenová CA
|
EA
|
AA
|
Stanice C-ITS
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
X označuje povinnou podporu
|
Tabulka 7: Generování párů klíčů a používání soukromého klíče pro dekódování žádostí o / odpovědí na registraci a autorizaci
6.1.4.3.Kryptoagilita
319)Požadavky týkající se délek klíčů a algoritmů se musí v průběhu času měnit tak, aby byla zachována přiměřená úroveň bezpečnosti. CPA sleduje potřebu těchto změn s ohledem na skutečnou zranitelnost a současnou kryptografii. Pokud se rozhodne, že kryptografické algoritmy by měly být aktualizovány, vypracuje, schválí a zveřejní aktualizaci této certifikační politiky. Pokud nové vydání této CP signalizuje změnu algoritmu a/nebo délky klíče, CPA přijme strategii migrace, která zahrnuje přechodná období, během nichž musí být podporovány staré algoritmy a klíčové délky.
320)S cílem umožnit a usnadnit přechod na nové algoritmy a/nebo délky klíčů se doporučuje, aby všichni účastníci PKI zavedli hardware a/nebo software umožňující přepínání délek klíčů a algoritmů.
321)Změny kořenových certifikátů a certifikátů TLM jsou podporovány a prováděny za pomoci spojovacích certifikátů (viz oddíl 4.6), které se používají k pokrytí přechodného období mezi starými a novými kořenovými certifikáty („migrace modelu služeb vytvářejících důvěru“).
6.1.5.Bezpečné uchovávání soukromých klíčů
Tento oddíl popisuje požadavky na bezpečné uchovávání a generování párů klíčů a náhodných čísel pro CA a koncové subjekty. Tyto požadavky jsou definovány pro kryptografické moduly a popsány v následujících pododdílech.
6.1.5.1.Úroveň kořenové CA, podřízené CA a TLM
322)Kryptografický modul se použije pro:
·generování, používání, správu a ukládání soukromých klíčů,
·generování a používání náhodných čísel (posouzení funkce generování náhodných čísel je součástí hodnocení a certifikace bezpečnosti),
·zálohování soukromých klíčů v souladu s oddílem 6.1.6,
·mazání soukromých klíčů.
Kryptografický modul musí být certifikován jedním z těchto profilů ochrany (PP) s úrovní záruky EAL-4 nebo vyšší:
·PP pro HSM:
·CEN EN 419 221-2: Profily ochrany pro TSP kryptografické moduly – Část 2: Kryptografický modul pro podepisování operací CSP se zálohou,
·CEN EN 419 221-4: Profily ochrany pro TSP kryptografické moduly – Část 4: Kryptografický modul pro podepisování operací CSP bez zálohy,
·CEN EN 419 221-5: Profily ochrany pro TSP kryptografické moduly – Část 5: Kryptografický modul pro důvěryhodné služby,
·PP pro čipové karty:
·CEN EN 419 211-2: Profil ochrany pro zařízení vytvářející bezpečný podpis – Část 2: Přístroje na generování klíče,
·CEN EN 419 211-3: Profil ochrany pro zařízení vytvářející bezpečný podpis – Část 3: Přístroje na přenos klíče.
Manuální přístup ke kryptografickým modulům vyžaduje dvoufaktorovou autentizaci od správce. Dále vyžaduje zapojení dvou autorizovaných osob.
Implementace kryptografického modulu zajistí, aby klíče nebyly přístupné mimo kryptografický modul. Kryptografický modul musí zahrnovat mechanismus kontroly přístupu, aby se zabránilo neoprávněnému používání soukromých klíčů.
6.1.5.2.Koncový subjekt
323)Kryptografický modul pro koncové subjekty se použije pro:
·generování, používání, správu a ukládání soukromých klíčů,
·generování a používání náhodných čísel (posouzení funkce generování náhodných čísel je součástí hodnocení a certifikace bezpečnosti),
·bezpečné mazání soukromého klíče.
324)Kryptografický modul je chráněn proti neoprávněnému odstranění, nahrazení a změnám. Všechny profily ochrany a související dokumenty použitelné pro certifikaci bezpečnosti stanic C-ITS musí být vyhodnoceny, validovány a certifikovány v souladu s normou ISO 15408 za použití dohody o vzájemném uznávání certifikátů hodnocení bezpečnosti informačních technologií skupiny vyšších úředníků pro bezpečnost informačních systémů (SOG-IS) nebo rovnocenného evropského systému certifikace kybernetické bezpečnosti v rámci příslušného evropského rámce kybernetické bezpečnosti.
325)Jelikož je důležité zachovat co nejvyšší možnou úroveň bezpečnosti, vydává bezpečnostní certifikáty kryptografickým modulům v rámci certifikace podle společných kritérií (ISO 15408) subjekt posuzování shody uznaný řídicím výborem v rámci dohody SOG-IS, nebo subjekt posuzování shody akreditovaný vnitrostátním orgánem členského státu pro certifikaci kybernetické bezpečnosti. Tento subjekt posuzování shody zajišťuje alespoň rovnocenné podmínky hodnocení bezpečnosti jako podmínky podle dohody SOG-IS o vzájemném uznávání.
Pozn.: Spojení mezi kryptografickým modulem a stanicí C-ITS musí být chráněno.
6.1.6.Zálohování soukromých klíčů
326)Generování, ukládání a využívání záloh soukromých klíčů musí splňovat požadavky alespoň na úrovni bezpečnosti, která je vyžadována pro původní klíče.
327)Zálohy soukromých klíčů musí provádět kořenové CA, EA a AA.
328)Zálohy soukromých klíčů se neprovádí pro EC a AT.
6.1.7.Likvidace soukromých klíčů
329)Kořenové CA, EA, AA a mobilní a pevné stanice C-ITS zlikvidují svůj soukromý klíč a všechny odpovídající zálohy, pokud byl generován a úspěšně instalován nový pár klíčů a odpovídající certifikát a pokud čas překrytí (pokud existuje – pouze CA) již uplynul. Soukromý klíč se likviduje pomocí mechanismu, který nabízí kryptografický modul použitý pro uchovávání klíčů, nebo jak je popsáno v odpovídajícím PP uvedeném v oddíle 6.1.5.2.
6.2.Aktivační údaje
330)Aktivační údaje odkazují na autentizační faktory, které jsou požadovány pro provoz kryptografických modulů, aby se zabránilo neoprávněnému přístupu. Použití aktivačních údajů pro kryptografické zařízení CA vyžaduje akci dvou autorizovaných osob.
6.3.Počítačové bezpečnostní kontroly
331)Počítačové bezpečnostní kontroly CA jsou navrženy v souladu s vysokou úrovní bezpečnosti a dodržují požadavky normy ISO/IEC 27002.
6.4.Technické kontroly životního cyklu
332)Technické kontroly CA zahrnují celý životní cyklus CA. Patří sem zejména požadavky oddílu 6.1.4.3 („Kryptoagilita“).
6.5.Bezpečnostní kontroly sítě
333)Sítě CA (kořenových CA, EA a AA) musí být odolné proti útokům v souladu s požadavky a prováděcími pokyny norem ISO/IEC 27001 a ISO/IEC 27002.
334)Dostupnost sítí CA musí být navržena s ohledem na odhadovaný provoz.
7.Profily certifikátů, CRL a CTL
7.1.Profil certifikátu
335)Profily certifikátů definované v [5] se použijí pro certifikáty TLM, kořenové certifikáty, certifikáty EA, certifikáty AA, AT a EC. Vnitrostátní vládní EA mohou pro EC použít i jiné profily certifikátů.
336)Certifikáty kořenové CA, EA a AA uvedou povolení, pro která jsou tyto certifikační autority (kořenové CA, EA a AA) oprávněny vydávat certifikáty.
337)Na základě [5]:
·každá kořenová CA použije k vydávání CRL svůj vlastní podpisový soukromý klíč,
·TLM použije k vydání ECTL svůj vlastní podpisový soukromý klíč.
7.2.Platnost certifikátu
338)Všechny profily certifikátu C-ITS musí zahrnovat datum vydání a datum ukončení platnosti, jež představují dobu platnosti certifikátu. Certifikáty budou na každé úrovni PKI generovány s dostatečným předstihem před uplynutím platnosti.
339)Doba platnosti certifikátů CA a EC zahrnuje dobu překrytí. Certifikáty TLM a certifikáty kořenové CA se vydávají a vkládají do ECTL nejvýše tři měsíce a nejméně jeden měsíc před začátkem platnosti certifikátu na základě doby zahájení uvedené v certifikátu. Tato fáze zavádění je nutná pro bezpečnou distribuci certifikátů všem odpovídajícím spoléhajícím se stranám v souladu s oddílem 2.2. Tím je zajištěno, že od začátku doby překrývání jsou všechny spoléhající se strany již schopny ověřit zprávy vydané s novým certifikátem.
340)Na začátku období, ve kterém se překrývají, se vydávají následné certifikáty CA, ES a AT (v příslušných případech), které jsou distribuovány spoléhajícím se stranám a které tyto strany instalují. Během doby překrývání se aktuální certifikát použije pouze pro ověření.
341)Vzhledem k tomu, že doba platnosti uvedená v tabulce 8 nesmí přesáhnout dobu platnosti nadřízeného certifikátu, platí tato omezení:
·maximumvalidity(Root CA) = privatekeyusage(Root CA) + maximumvalidity(EA,AA),
·maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC),
·maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(AT).
342)Platnost spojovacích certifikátů (kořenových a TLM) začíná použitím odpovídajícího soukromého klíče a končí maximální dobou platnosti kořenové CA nebo TLM.
343)Tabulka 8 uvádí maximální dobu platnosti certifikátů CA C-ITS (doby platnosti AT, viz oddíl 7.2.1).
Subjekt
|
Max. doba použití soukromého klíče
|
Maximální doba platnosti
|
Kořenová CA
|
3 roky
|
8 let
|
EA
|
2 roky
|
5 let
|
AA
|
4 roky
|
5 let
|
EC
|
3 roky
|
3 roky
|
TLM
|
3 roky
|
4 roky
|
Tabulka 8: Doby platnosti certifikátů v C-ITS modelu služeb vytvářejících důvěru
7.2.1.Certifikáty pseudonymu
344)V tomto kontextu se pseudonymy implementují pomocí AT. Proto tento oddíl odkazuje na AT, nikoli na pseudonymy.
345)Požadavky stanovené v tomto oddíle se vztahují pouze na AT mobilních stanicích C-ITS, které zasílají zprávy CAM a DENM, pro které platí riziko soukromí lokality. Pro AT neplatí žádné zvláštní požadavky na certifikáty AT pro pevné stanice C-ITS a mobilní stanice C-ITS používané pro zvláštní funkce, kde soukromí lokality není použitelné (např. u vozidel s označením „pohotovost“ a „policie“).
346)Použijí se tyto definice:
·„doba platnosti AT“ – doba, po kterou je AT platné, tj. doba mezi počátečním datem AT a datem skončení jeho platnosti,
·„fáze nahrávání AT“ – nahrávání (preload) je možnost, aby stanice C-ITS získaly AT před tím, než začíná jeho doba platnosti. Fáze nahrávání je maximální povolenou dobou od žádosti o AT do nejzazšího konce platnosti jakéhokoli vyžádaného AT,
·„doba používání AT“ – doba, během které se AT používá k podpisu zpráv CAM/DENM,
·„maximální počet paralelních AT“ – počet AT, z nichž si stanice C-ITS může kdykoli vybrat, když podepisuje zprávu CAM/DENM, tj. počet různých AT vydaných jedné stanici C-ITS, které jsou platné současně.
347)Platí tyto požadavky:
·fáze nahrávání AT nesmí překročit tři měsíce,
·doba platnosti AT nesmí překročit jeden týden,
·maximální počet paralelních AT nesmí na stanici C-ITS překročit 100,
·doba používání AT závisí na strategii změny AT a na době, kdy je vozidlo v provozu, ale je omezeno maximálním počtem paralelních AT a dobou platnosti. Konkrétně průměrná doba používání jedné stanice C-ITS je alespoň provozní doba vozidla v jednom období platnosti vydělená maximálním počtem paralelních AT.
7.2.2.Autorizační potvrzení pro pevné stanice C-ITS
348)Použijí se definice uvedené v oddíle 7.2.1 a tyto požadavky:
·fáze nahrávání AT nesmí překročit tři měsíce,
·maximální počet paralelních AT nesmí překročit dvě na jednu stanici C-ITS.
7.3.Odvolání certifikátů
7.3.1.Odvolání certifikátů CA, EA a AA
Certifikáty kořenové CA, EA a AA jsou odvolatelné. Odvolané certifikáty kořenových CA, EA a AA se zveřejňují v CRL co nejdříve a bez zbytečného odkladu. Tento CRL podepisuje odpovídající kořenový CA a používá profil popsaný v oddíle 7.4. Pro odvolání certifikátů kořenových CA vydá odpovídající kořenová CA CRL, který jej obsahuje. Kromě toho se v případě bezpečnostního ohrožení použije oddíl 5.7.3. TLM musí navíc odstranit odvolané kořenové CA ze seznamu důvěryhodných subjektů a vydat nový seznam důvěryhodných subjektů. Certifikáty s prošlým datem platnosti se odstraní z příslušného CRL a seznamu důvěryhodných subjektů.
349)Certifikáty se odvolají, pokud:
·kořenové CA mají důvod domnívat se nebo mít silné podezření, že příslušný soukromý klíč byl ohrožen,
·kořenovým CA bylo oznámeno, že smlouva s účastníkem byla ukončena,
·informace v certifikátu (jako název a spojení mezi CA a subjektem) jsou nesprávné nebo se změnily,
·dojde k bezpečnostnímu incidentu, který má vliv na majitele certifikátu,
·výsledek auditu (viz oddíl 8) je negativní.
350)Účastník neprodleně uvědomí CA o známém nebo domnělém ohrožení svého soukromého klíče. Musí být zaručeno, že pouze autentizované žádosti budou mít za následek odvolání certifikátů.
7.3.2.Odvolání oprávnění k registraci
351)Odvolání EC může být iniciováno účastníkem stanice C-ITS (tok 34) a provádí se formou vnitřní černé listiny v databázi odvolání s časovým razítkem, kterou generuje a udržuje každá EA. Černá listina není nikdy zveřejněna a je důvěrná a použije ji pouze příslušná EA, aby ověřil platnost odpovídajících EC v souvislosti s žádostmi o AT a nové EC.
7.3.3.Odvolání potvrzení o autorizaci
352)Jelikož AT nejsou příslušnými CA odvolávána, mají krátkou životnost a nemohou být vydávána příliš dlouho před tím, než se stanou platnými. Přípustné hodnoty parametrů životního cyklu certifikátu jsou stanoveny v oddíle 7.2.
7.4.Seznam odvolaných certifikátů
353)Formát a obsah CRL vydaného kořenovou CA jsou stanoveny v [1].
7.5.Evropský seznam důvěryhodných certifikátů
354)Formát a obsah ECTL vydaného TLM jsou stanoveny v [1].
8.Audit souladu a další posouzení
8.1.Témata auditu a základ auditu
355)Účelem auditu souladu je ověřit, že TLM, kořenové CA, EA a AA fungují v souladu s CP. TLM, kořenové CA, EA a AA vyberou nezávisle jednajícího a akreditovaného auditora PKI k provedení auditu jejich CPS. Audit je kombinován s posouzením podle norem ISO/IEC 27001 a ISO/IEC 27002.
356)Audit souladu zadává kořenová CA (tok 13) pro sebe a podřízená EA/AA pro podřízenou CA.
357)Audit souladu pro TLM zadává CPA (tok 38).
358)Akreditovaný auditor PKI musí v případě, že je o to požádán, provést audit souladu na jedné z těchto úrovní:
1)soulad CPS TLM, kořenové CA, EA nebo AA s touto CP,
2)soulad plánované praxe TLM, kořenové CA, EA nebo AA s CPS před uvedením do provozu,
3)soulad praxe a provozních činností TLM, kořenové CA, EA nebo AA s CPS během provozu.
359)Audit musí pokrývat všechny požadavky této CP, které musí splňovat TLM, kořenové CA, EA a AA, u nichž má být proveden audit. Zahrnuje rovněž fungování CA v PKI C-ITS, včetně všech procesů uvedených v její CPS, prostor a odpovědných osob.
360)Akreditovaný auditor PKI poskytne podrobnou zprávu o auditu dle potřeby kořenové CA (tok 36), EA, AA nebo CPA (tok 16 a 40).
8.2.Četnost auditů
361)Kořenová CA, TLM, EA nebo AA zadává audit svého souladu u nezávislého a akreditovaného auditora PKI v těchto případech:
·při svém prvním zřízení (úrovně souladu 1 a 2),
·při každé změně CP. CPA definuje obsah změny CP a časový plán zavedení a odpovídajícím způsobem určuje potřeby auditů (včetně nezbytné úrovně souladu),
·při každé změně své CPS (úrovně souladu 1, 2 a 3). Jelikož řídicí subjekty kořenových CA, TLM a EA/AA rozhodují, jaké změny implementace následují po aktualizaci jejich CPS, objednají audit souladu před provedením těchto změn. V případech pouze drobných změn CPS (např. změn redakčního charakteru) může řídicí subjekt zaslat CPA řádně odůvodněnou žádost o jeho souhlas s vynecháním auditů souladu úrovně 1, 2 nebo 3,
·pravidelně a nejméně jednou za tři roky v průběhu fungování (úroveň souladu úrovně 3).
8.3.Totožnost/kvalifikace auditora
362)CA, která má být předmětem auditu, vybere pro audit v souladu s touto certifikační politikou nezávisle působící a akreditovanou společnost/organizaci (dále jen „auditní subjekt“) nebo akreditované auditory PKI.
8.4.Vztah auditora k auditovanému subjektu
363)Akreditovaný auditor PKI musí být nezávislý na auditovaném subjektu.
8.5.Opatření přijatá v důsledku nedostatku
364)Zjistí-li zpráva o auditu, že TLM není v souladu, přikáže CPA TLM, aby okamžitě přijal preventivní/nápravná opatření.
365)Podá-li kořenová CA s nevyhovující zprávou o auditu novou žádost, CPA žádost zamítne a zašle odpovídající zamítnutí kořenové CA (tok 4). V takových případech bude kořenová CA pozastavena. Musí přijmout nápravná opatření, znovu objednat audit a podat novou žádost o schválení CPA. Kořenová CA nesmí během pozastavení vydávat certifikáty.
366)V případech pravidelného auditu kořenové CA nebo změny CPS CA a v závislosti na povaze nesouladu popsaného ve zprávě o auditu může CPA rozhodnout o odvolání kořenové CA a toto rozhodnutí sdělit TLM (tok 2), což povede k vymazání certifikátu kořenové CA z ECTL a vložení kořenové CA do CRL. CPA zašle kořenové CA odpovídající zamítnutí (tok 4). Kořenová CA musí přijmout nápravná opatření, znovu zadat úplný audit (úroveň 1 až 3) a podat novou žádost o schválení CPA. Alternativně může CPA rozhodnout, že kořenovou CA neodvolá, ale poskytne jí odklad, během kterého musí kořenová CA přijmout nápravná opatření, znovu zadat audit a předložit CPA zprávu o auditu. V tomto případě musí být provoz kořenové CA pozastaven a není povoleno vydávat certifikáty a CRL.
367)V případě auditu EA/AA rozhodne kořenová CA, zda zprávu přijme, či nikoli. V závislosti na výsledku auditu musí kořenová CA rozhodnout, zda zruší certifikát EA/AA v souladu s pravidly v CPS kořenové CA. Kořenová CA vždy zajistí soulad EA/AA s touto CP.
8.6.Sdělování výsledků
368)Kořenová CA a TLM zasílají zprávu o auditu CPA (tok 16). Kořenová CA a TLM uloží všechny zprávy o auditu, které objednaly. CPA zašle kořenové CA a TLM odpovídající schválení nebo zamítnutí (tok 4).
369)Kořenová CA zašle odpovídající EA/AA certifikát o shodě.
9.Jiná ustanovení
9.1.Poplatky
370)Jednou ze zásad implementovaného EU C-ITS modelu služeb vytvářejících důvěru je to, že kořenové CA společně plně financují pravidelné běžné náklady na provoz CPA a centrálních prvků (TLM a CPOC) souvisejících s činnostmi stanovenými v této CP.
371)Kořenové CA (včetně kořenové CA EU) jsou oprávněny vybírat poplatky od svých podřízených CA.
372)Během celé své doby provozování musí mít každý účastník C-ITS modelu služeb vytvářejících důvěru přístup na nediskriminačním základě k alespoň jedné kořenové CA, EA a AA.
373)Každá kořenová CA má právo přenést poplatky, které platí za CPA a centrální prvky (TLM a CPOC), na registrované účastníky C-ITS modelu služeb vytvářejících důvěru, včetně zapsaných a schválených stanic C-ITS.
9.2.Finanční odpovědnost
374)Prvotní zřízení kořenové CA pokrývá období nejméně tří let provozu, aby se mohla stát členem EU C-ITS modelu služeb vytvářejících důvěru. CPS provozovatele kořenové CA musí rovněž obsahovat podrobná ustanovení týkající se odvolání nebo uzavření kořenové CA.
375)Každá kořenová CA musí prokázat finanční životaschopnost právního subjektu, který ji implementuje, po dobu nejméně tří let. Tento plán finanční životaschopnosti je součástí základního souboru dokumentů k registraci a musí být každé tři roky aktualizován a oznámen CPA.
376)Aby prokázala svou finanční udržitelnost, musí každá kořenová CA každý rok provoznímu řediteli a CPA hlásit strukturu poplatků, které uplatňuje na EA/AA a registrované a schválené stanice C-ITS.
377)Všechny finanční a právně odpovědné subjekty kořenové CA, EA, AA a centrálních prvků (CPOC a TLM) C-ITS modelu služeb vytvářejících důvěru musí přiměřeně pojistit své provozní činnosti, aby byly vykompenzovány provozní chyby a finanční náklady na zotavení takové provozní činnosti, pokud jeden z technických prvků selže.
9.3.Důvěrnost obchodních informací
378)Níže uvedené položky se považují za důvěrné a soukromé:
·záznamy žádostí kořenové CA, EA a AA bez ohledu na to, zda byly schváleny nebo zamítnuty,
·zprávy o auditu kořenové CA, EA, AA a TLM,
·plány obnovy po havárii kořenové CA, EA, AA, CPOC a TLM,
·soukromé klíče prvků C-ITS modelu služeb vytvářejících důvěru (stanice C-ITS, TLM, EA, AA, kořenové CA),
·jakékoli další informace označené jako důvěrné CPA, kořenovými CA, EA, AA, TLM a CPOC.
9.4.Plán ochrany soukromí
379)CPS kořenových CA a EA/AA stanoví plán a požadavky týkající se zacházení s osobními informacemi a soukromí na základě GDPR a jiných platných právních rámců (např. vnitrostátních).
10.Odkazy
V této příloze jsou použity následující odkazy.
[1]
|
ETSI TS 102 941 V1.2.1, Intelligent transport systems (ITS) – security, trust and privacy management [Inteligentní dopravní systémy (ITS) – bezpečnost, důvěra a správa soukromí]
|
[2]
|
ETSI TS 102 940 V1.3.1, Intelligent transport systems (ITS) – security, ITS communications security architecture and security management [Inteligentní dopravní systémy (ITS) – bezpečnost, architektura bezpečnosti komunikací ITS a správa bezpečnosti]
|
[3]
|
Certificate policy and certification practices framework [Certifikační politika a rámec certifikačního postupu] (RFC 3647, 1999)
|
[4]
|
ETSI TS 102 042 V2.4.1 Policy requirements for certification authorities issuing public key certificates [Požadavky na politiku certifikačních autorit vydávajících certifikáty veřejných klíčů]
|
[5]
|
ETSI TS 103 097 V1.3.1, Intelligent transport systems (ITS) – security, security header and certificate formats [Inteligentní dopravní systémy (ITS) – bezpečnost, bezpečnostní záhlaví a formáty certifikátů]
|
[6]
|
Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide [Bezpečnost informací na základě normy ISO 27001/ISO 1779: průvodce pro vedení organizace]. Van Haren Publishing.
|
[7]
|
ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – Informační technologie – Bezpečnostní techniky – Řízení rizik bezpečnosti informací. ISO.
|
|
|