СЪДЪРЖАНИЕ
ПРИЛОЖЕНИЕ III
10
1.Въведение10
1.1.Преглед и обхват на настоящата политика10
1.2.Определения и съкращения12
1.3.Участници в инфраструктурата на публичния ключ (PKI/ИПК)15
1.3.1.Въведение15
1.3.2.Орган за политиката за предоставяне на удостоверения в СИТС20
1.3.3.Администратор на доверителния списък20
1.3.4.Независим одитор на PKI (ИПК)21
1.3.5.Звено за контакт за СИТС (CPOC/ЗКС)21
1.3.6.Оперативни функции21
1.4.Ползване на удостоверенията23
1.4.1.Приложими области на употреба23
1.4.2.Граници на отговорността23
1.5.Административно управление на политиката за предоставяне на удостоверения23
1.5.1.Осъвременяване на CPS (ДПУ) на CA (УО), включени в ECTL (ДСЕУ)23
1.5.2.Процедури за одобряване на CPS (ДПУ)24
2.Публикуване и отговорности по отношение на хранилищата24
2.1.Методи за публикуване на информация за удостоверенията24
2.2.Време или честота на публикуване25
2.3.Хранилища26
2.4.Контрол на достъпа до хранилищата26
2.5.Публикуване на информация за удостоверенията27
2.5.1.Публикуване на информация за удостоверенията от страна на TLM (АДС)27
2.5.2.Публикуване на информация за удостоверенията от страна на CA (УО)27
3.Идентифициране и удостоверяване на идентичността28
3.1.Именуване28
3.1.1.Видове имена28
3.1.1.1.Имена на TLM (АДС), базови CA (УО), EA (ОВ), AA (РО)28
3.1.1.2.Имена на крайни субекти28
3.1.1.3.Идентификация на удостоверенията28
3.1.2.Изискване за съдържателност на имената28
3.1.3.Анонимност и псевдонимност на крайните субекти28
3.1.4.Правила за тълкуване на различни форми на имената29
3.1.5.Уникалност на имената29
3.2.Първоначално валидиране на идентичността29
3.2.1.Метод за доказване на притежаването на частен ключ29
3.2.2.Удостоверяване на организационна идентичност29
3.2.2.1.Удостоверяване на организационната идентичност на базови CA (УО)29
3.2.2.2.Удостоверяване на организационната идентичност на TLM (АДС)30
3.2.2.3.Удостоверяване на организационната идентичност на второстепенни CA (УО)31
3.2.2.4.Удостоверяване на идентичността на организации, абониращи крайни субекти31
3.2.3.Удостоверяване на идентичността на индивидуални субекти32
3.2.3.1.Удостоверяване на идентичността на индивидуални субекти на TLM (АДС)/CA (УО)32
3.2.3.2.Удостоверяване на идентичността на абонати на станции на СИТС33
3.2.3.3.Удостоверяване на идентичността на станции на СИТС33
3.2.4.Непроверена информация за абонатите33
3.2.5.Валидиране на органи33
3.2.5.1.Валидиране на TLM (АДС), базов CA (УО), EA (ОВ), AA (РО)33
3.2.5.2.Валидиране на абонати на станции на СИТС33
3.2.5.3.Валидиране на станции на СИТС33
3.2.6.Критерии за оперативна съвместимост34
3.3.Идентифициране и удостоверяване на идентичността при подаване на заявки за повторно въвеждане на ключ34
3.3.1.Идентифициране и удостоверяване на идентичността при подаване на заявки за рутинно повторно въвеждане на ключ34
3.3.1.1.Удостоверения на TLM (АДС)34
3.3.1.2.Удостоверения на базови CA (УО)34
3.3.1.3.Подновяване на удостоверения или повторно въвеждане на ключове на EA (ОВ)/AA (РО)35
3.3.1.4.Пълномощия за вписване на крайни субекти35
3.3.1.5.Талони за разрешение на крайни субекти35
3.3.2.Идентифициране и удостоверяване на идентичността при подаване на заявки за повторно въвеждане на ключ след отмяна35
3.3.2.1.Удостоверения на CA (УО)35
3.3.2.2.Пълномощия за вписване на крайни субекти36
3.3.2.3.Заявки за издаване на разрешение на крайни субекти36
3.4.Идентифициране и удостоверяване на идентичността при подаване на заявка за отмяна36
3.4.1.Удостоверения на базови CA (УО)/EA (ОВ)/AA (РО)36
3.4.2.Пълномощия за регистрация на станции на СИТС36
3.4.3.Талони за разрешение на станции на СИТС36
4.Оперативни изисквания за жизнения цикъл на удостоверенията37
4.1.Заявление за издаване на удостоверение37
4.1.1.Кой може да подаде заявление за издаване на удостоверение37
4.1.1.1.Базови CA (УО)37
4.1.1.2.TLM (АДС)37
4.1.1.3.EA (ОВ) и AA (РО)37
4.1.1.4.Станции на СИТС37
4.1.2.Процедура за вписване и отговорности38
4.1.2.1.Базови CA (УО)38
4.1.2.2.TLM (АДС)38
4.1.2.3.EA (ОВ) и AA (РО)39
4.1.2.4.Станции на СИТС39
4.2.Обработване на заявленията за издаване на удостоверение40
4.2.1.Изпълнение на функции по отношение на идентификация и удостоверяване на идентичността40
4.2.1.1.Идентификация и удостоверяване на идентичността на базови CA (УО)40
4.2.1.2.Идентификация и удостоверяване на идентичността на TLM (АДС)41
4.2.1.3.Идентификация и удостоверяване на идентичността на EA (ОВ) и AA (РО)41
4.2.1.4.Идентификация и удостоверяване на идентичността на абонати на EE (КС)41
4.2.1.5.Талони за разрешение41
4.2.2.Одобряване или отхвърляне на заявления за издаване на удостоверение41
4.2.2.1.Одобряване или отхвърляне на удостоверения на базови CA (УО)41
4.2.2.2.Одобряване или отхвърляне на удостоверения на TLM (АДС)42
4.2.2.3.Одобряване или отхвърляне на удостоверения на EA (ОВ) и AA (РО)42
4.2.2.4.Одобряване или отхвърляне на EC (ПВ)42
4.2.2.5.Одобряване или отхвърляне на AT (ТР)42
4.2.3.Срок за обработване на заявленията за издаване на удостоверение42
4.2.3.1.Заявление за издаване на удостоверение на базов CA (УО)42
4.2.3.2.Заявление за издаване на удостоверение на TLM (АДС)43
4.2.3.3.Заявления за издаване на удостоверение на EA (ОВ) и AA (РО)43
4.2.3.4.Заявление за EC (ПВ)43
4.2.3.5.Заявление за AT (ТР)43
4.3.Издаване на удостоверения43
4.3.1.Действия на CA (УО) при издаване на удостоверения43
4.3.1.1.Издаване на удостоверение на базов CA (УО)43
4.3.1.2.Издаване на удостоверение на TLM (АДС)43
4.3.1.3.Издаване на удостоверения на EA (ОВ) и AA (РО)43
4.3.1.4.Издаване на EC (ПВ)44
4.3.1.5.Издаване на AT (ТР)44
4.3.2.Уведомяване на абоната за издаването на удостоверението от страна на CA (УО)44
4.4.Приемане на удостоверения44
4.4.1.Процедура за приемане на удостоверения44
4.4.1.1.Базов CA (УО)44
4.4.1.2.TLM (АДС)44
4.4.1.3.EA (ОВ) и AA (РО)45
4.4.1.4.Станции на СИТС45
4.4.2.Публикуване на удостоверението45
4.4.3.Уведомление за издаване на удостоверение45
4.5.Ползване на двойки ключове и удостоверения45
4.5.1.Ползване на частни ключове и удостоверения45
4.5.1.1.Ползване на частни ключове и удостоверения от TLM (АДС)45
4.5.1.2.Ползване на частни ключове и удостоверения от базови CA (УО)45
4.5.1.3.Ползване на частни ключове и удостоверения от EA (ОВ) и AA (РО)45
4.5.1.4.Ползване на частни ключове и удостоверения от крайни субекти46
4.5.2.Ползване на частни ключове и удостоверения от доверяваща се страна46
4.6.Подновяване на удостоверения46
4.7.Повторно въвеждане на ключове за удостоверения46
4.7.1.Предпоставки за повторно въвеждане на ключове за удостоверения46
4.7.2.Кой може да поиска повторно въвеждане на ключове46
4.7.2.1.Базов CA (УО)46
4.7.2.2.TLM (АДС)47
4.7.2.3.EA (ОВ) и AA (РО)47
4.7.2.4.Станции на СИТС47
4.7.3.Процедура за повторно въвеждане на ключове47
4.7.3.1.Удостоверение на TLM (АДС)47
4.7.3.2.Удостоверение на базов CA (УО)47
4.7.3.3.Удостоверения на EA (ОВ) и AA (РО)47
4.7.3.4.Удостоверения на станции на СИТС48
4.8.Промяна на удостоверение48
4.9.Отмяна и временно преустановяване на действието на удостоверение48
4.10.Услуги, отнасящи се до статуса на удостоверението48
4.10.1.Оперативни характеристики48
4.10.2.Наличност на услугите48
4.10.3.Характеристики, подлежащи на избор49
4.11.Изтичане на абонамента49
4.12.Доверително съхранение и възстановяване на ключ49
4.12.1.Абонат49
4.12.1.1.Коя двойка ключове може да бъде дадена на доверително съхранение49
4.12.1.2.Кой може да подаде заявление за възстановяване49
4.12.1.3.Процедура за възстановяване и отговорности49
4.12.1.4.Идентифициране и удостоверяване на идентичността49
4.12.1.5.Одобряване или отхвърляне на заявления за възстановяване49
4.12.1.6.Действия на органа, отговорен за доверителното съхранение (KEA) и за възстановяването на ключове (KRA), при възстановяване на двойка ключове49
4.12.1.7.Наличност на орган, отговорен за доверителното съхранение (KEA) и за възстановяването на ключове (KRA)49
4.12.2.Политика и практика за капсулиране и възстановяване на сесийни ключове49
5.Структура, управление и оперативен контрол49
5.1.Физически контрол49
5.1.1.Местонахождение и устройство50
5.1.1.1.Базови CA (УО), CPOC (ЗКС), TLM (АДС)50
5.1.1.2.EA (ОВ)/AA (РО)51
5.1.2.Физически достъп51
5.1.2.1.Базови CA (УО), CPOC (ЗКС), TLM (АДС)51
5.1.2.2.EA (ОВ)/AA (РО)52
5.1.3.Електрозахранване и климатизация52
5.1.4.Изложеност на вода53
5.1.5.Предотвратяване на пожар и защита срещу пожар53
5.1.6.Управление на носителите53
5.1.7.Унищожаване на отпадъци54
5.1.8.Съхраняване на резервни данни в независима среда54
5.1.8.1.Базов CA (УО), CPOC (ЗКС) и TLM (АДС)54
5.1.8.2.EA (ОВ)/AA (РО)54
5.2.Контрол на процедурите54
5.2.1.Доверителни функции55
5.2.2.Брой лица, необходими за всяка задача55
5.2.3.Идентифициране и удостоверяване на идентичността при изпълнение на всяка функция56
5.2.4.Функции, за които се изисква разделение на задълженията56
5.3.Контрол на персонала57
5.3.1.Изисквания за квалификация, опит и ниво на достъп57
5.3.2.Процедури за проверка на личното досие57
5.3.3.Изисквания, свързани с обучението58
5.3.4.Последващо обучение: честота и изисквания58
5.3.5.Честота и последователност на ротацията на длъжности59
5.3.6.Санкции за неразрешени действия59
5.3.7.Изисквания към независими подизпълнители59
5.3.8.Документация, предоставяна на персонала59
5.4.Процедури за водене на контролен регистър59
5.4.1.Видове събития, подлежащи на регистриране и докладване от всеки CA (УО)59
5.4.2.Честота на обработване на регистъра61
5.4.3.Период на съхранение на контролния регистър61
5.4.4.Защита на контролния регистър61
5.4.5.Процедури за архивиране на контролния регистър62
5.4.6.Система за събиране на контролни данни (вътрешна или външна)62
5.4.7.Уведомяване на субекта, станал причина за събитието62
5.4.8.Оценка на уязвимостта62
5.5.Архивиране на записи63
5.5.1.Видове записи, подлежащи на архивиране63
5.5.2.Период на съхранение на архива64
5.5.3.Защита на архива65
5.5.4.Системен архив и съхранението му65
5.5.5.Изисквания за електронно вписване на часа и датата на записите65
5.5.6.Система за събиране на архивни данни (вътрешна или външна)65
5.5.7.Процедури за получаване и проверка на архивна информация65
5.6.Смяна на ключа за звена в модела на доверие на СИТС65
5.6.1.TLM (АДС)65
5.6.2.Базов CA (УО)66
5.6.3.Удостоверение на EA (ОВ)/AA (РО)66
5.6.4.Одитор66
5.7.Компрометиране и възстановяване в случай на бедствие66
5.7.1.Действия в случай на инцидент и компрометиране66
5.7.2.Увреждане на компютърна техника, софтуер и/или данни67
5.7.3.Процедури при компрометиране на частен ключ на субект67
5.7.4.Способности за продължаване на работата след бедствие68
5.8.Прекратяване и прехвърляне69
5.8.1.TLM (АДС)69
5.8.2.Базов CA (УО)69
5.8.3.EA (ОВ)/AA (РО)69
6.Технически средства за контрол на сигурността70
6.1.Генериране и инсталиране на двойки ключове70
6.1.1.TLM (АДС), базов CA (УО), EA (ОВ), AA (РО)70
6.1.2.EE (КС) — мобилна станция на СИТС71
6.1.3.EE (КС) — фиксирана станция на СИТС71
6.1.4.Изисквания за криптографиране71
6.1.4.1.Алгоритъм и дължина на ключа — алгоритми на подписа71
6.1.4.2.Алгоритъм и дължина на ключа — алгоритми на криптирането при вписване и разрешаване на достъпа73
6.1.4.3.Криптогъвкавост74
6.1.5.Защитено съхранение на частни ключове74
6.1.5.1.На ниво базов CA (УО), второстепенен CA (УО) и TLM (АДС)74
6.1.5.2.Краен субект75
6.1.6.Резервни копия на частни ключове76
6.1.7.Унищожаване на частни ключове76
6.2.Данни за активиране76
6.3.Контрол на компютърната сигурност77
6.4.Технически средства за контрол на жизнения цикъл77
6.5.Контрол на сигурността на мрежата77
7.Профил на удостоверенията, CRL (САУ) и CTL (ДСУ)77
7.1.Профил на удостоверенията77
7.2.Валидност на удостоверенията77
7.2.1.Псевдонимни удостоверения78
7.2.2.Талони за разрешение за фиксирани станции на СИТС79
7.3.Отмяна на удостоверения79
7.3.1.Отмяна на удостоверения на CA (УО), EA (ОВ) и AA (РО)79
7.3.2.Отмяна на пълномощия за вписване80
7.3.3.Отмяна на талони за разрешение80
7.4.Списък на отменените удостоверения80
7.5.Доверителен списък на европейските удостоверения80
8.Одит на съответствието и други оценки80
8.1.Въпроси в обхвата на одита и основа на одита80
8.2.Честота на одитите81
8.3.Самоличност/квалификация на одитора82
8.4.Взаимоотношения на одитора с одитирания субект82
8.5.Предприети действия в случай на недостатъци82
8.6.Съобщаване на резултатите83
9.Други разпоредби83
9.1.Такси83
9.2.Финансова отговорност83
9.3.Поверителност на търговската информация84
9.4.План за поверителност84
10.Препратки84
ПРИЛОЖЕНИЕ III
1.Въведение
1.1.Преглед и обхват на настоящата политика
В настоящата политика за предоставяне на удостоверения моделът на доверие на европейската СИТС е определен въз основа на инфраструктура на публичния ключ (PKI/ИПК) в обхвата на цялостната система на ЕС за управление на пълномощията за сигурност в СИТС (EU CCMS/СУПС на ЕС). В нея са конкретизирани изискванията за управление на удостоверенията за публични ключове за приложенията на СИТС от страна на издаващите институции и ползването на удостоверенията от крайните субекти в Европа. На най-високото йерархично ниво на PKI (ИПК) стоят определен брой базови CA (УО), „активирани“ от администратора на доверителния списък (TLM/АДС) чрез въвеждане на техните удостоверения в доверителния списък на европейските удостоверения (ECTL/ДСЕУ), който се съставя и публикува от централния TLM (АДС) (вж. раздели 1.2 и 1.3).
Тази политика е задължителна за всички субекти, участващи в доверителната система на СИТС в Европа. Тя помага да се оцени нивото на доверие в получаваната информация, което може да бъде изградено у всеки получател на електронно съобщение, чиято автентичност е потвърдена с удостоверение на краен субект в PKI (ИПК). За да може да се оцени степента на доверие в удостоверенията, предоставяни от EU CCMS (СУПС на ЕС), в настоящата политика е определен набор от задължителни изисквания за работата на централния TLM (АДС) и за съставянето и управлението на ECTL (ДСЕУ). За тази цел в настоящия документ са уредени следните аспекти, свързани с ECTL (ДСЕУ):
·идентификация и удостоверяване на идентичността на отговорните лица, на които са възложени функции на TLM (АДС) в PKI (ИПК), включително описание на правата, присъщи на всяка функция;
·минимални изисквания относно местните практики за гарантиране на сигурност в работата на TLM (АДС), включително физически контрол и контрол на персонала и на процедурите;
·минимални изисквания относно техническите средства за гарантиране на сигурност в работата на TLM (АДС), включително контрол на сигурността на компютрите, на мрежата и на архитектурата на криптографския модул;
·минимални изисквания относно оперативните практики на TLM (АДС), включително регистриране на нови удостоверения на базови CA (УО), временно или окончателно дерегистриране на съществуващи CA (УО) и публикуване и разпространение на актуализирани версии на ECTL (ДСЕУ);
·профил на ECTL (ДСЕУ), включващ всички задължителни и факултативни полета за данни в ECTL (ДСЕУ), криптографските алгоритми, които следва да се ползват, точния формат на ECTL (ДСЕУ) и препоръки за неговото обработване;
·управление на жизнения цикъл на удостоверенията в ECTL (ДСЕУ), включително предоставяне, активиране, изтичане на валидността и отмяна на удостоверения, вписани в ECTL (ДСЕУ);
·управление на оттеглянето на доверието от базови CA (УО), когато е необходимо.
Тъй като надеждността на ECTL (ДСЕУ) не зависи единствено от самия ECTL (ДСЕУ), а до голяма степен и от базовите CA (УО), които съставляват PKI (ИПК), както и от стоящите под тях второстепенни CA (УО), в настоящата политика са определени също минимални изисквания, които са задължителни за всички участващи CA (УО) (базови и второстепенни). Тези изисквания се отнасят до следните области:
·идентификация и удостоверяване на идентичността на отговорните лица, на които са възложени функции в PKI (ИПК) (напр. служител по сигурността, служител по поверителността, администратор на сигурността, администратор на директории и краен потребител), включително длъжностна характеристика, в която са описани задачите, задълженията, отговорностите и правата, присъщи на всяка функция;
·управление на ключове, включително приемливи и задължителни алгоритми за подписване на удостоверения и на данни, както и периоди на валидност на удостоверенията;
·минимални изисквания относно местните практики за гарантиране на сигурност, включително физически контрол и контрол на персонала и на процедурите;
·минимални изисквания относно техническите средства за гарантиране на сигурност, като например контрол на сигурността на компютрите, на мрежата и на архитектурата на криптографския модул;
·минимални изисквания относно оперативните практики на CA (УО), EA (ОВ), AA (РО) и крайните субекти, включително аспекти, свързани с регистрация, дерегистрация (напр. отписване), отмяна, компрометиране на ключове, отстраняване по обективни причини, актуализиране на удостоверения, както и практики по отношение на одита и неоповестявянето на лична информация;
·профил на удостоверението и на CRL (САУ), включително формат, приемливи алгоритми, задължителни и факултативни полета за данни и валиден обхват на съдържащите се в тях стойности, както и механизми за обработване на удостоверенията от страна на проверители;
·задачи на субектите в модела на доверие на СИТС, свързани с редовно наблюдение, докладване, сигнализиране и възстановяване на работата, с цел да се гарантира защитено функциониране на системата, включително в случай на неправомерни действия.
Наред с тези минимални изисквания субектите, които изпълняват функции на базови и второстепенни CA (УО), могат да въведат свои допълнителни изисквания и да ги изложат в съответни декларации за практиката на удостоверяване (CPS/ДПУ), при условие че не противоречат на изискванията, описани в политиката за предоставяне на удостоверения. За подробности относно проверката и публикуването на CPS (ДПУ) вж. раздел 1.5.
В CP (ППУ) са декларирани и целите, за които могат да бъдат ползвани базовите и второстепенните CA (УО) и издадените техни удостоверения. В нея са конкретизирани отговорностите на:
·TLM (АДС);
·всеки базов CA (УО), чиито удостоверения са включени в ECTL (ДСЕУ);
·второстепенните CA (УО) [EA (ОВ) и AA (РО)] на всеки базов CA (УО);
·всеки член или организация, които отговарят за субект в модела на доверие на СИТС или управляват такъв субект.
В CP (ППУ) са определени също изисквания за задълженията на:
·TLM (АДС);
·всеки базов CA (УО), чиито удостоверения са включени в ECTL (ДСЕУ);
·всеки второстепенен CA (УО), сертифициран от базов CA (УО);
·всички крайни субекти;
·всяка организация членка, която отговаря за субект в модела на доверие на СИТС или управлява такъв субект.
Накрая в CP (ППУ) са посочени изисквания за документиране на ограничения на отговорностите и задълженията в CPS (ДПУ) на всеки базов CA (УО), чиито удостоверения са включени в ECTL (ДСЕУ).
Настоящата CP (ППУ) е в съответствие с рамката на политиката за предоставяне на удостоверения и удостоверителните практики, приета от Работната група за интернет инженеринг (IETF) [3].
1.2.Определения и съкращения
Прилагат се определенията, дадени в [2], [3] и [4].
AA (РО)
|
authorisation authority (разрешаващ орган)
|
AT (ТР)
|
authorisation ticket (талон за разрешение)
|
CA
|
certification authority (удостоверяващ орган)
|
CP (ППУ)
|
certificate policy (политика за предоставяне на удостоверения)
|
CPA (ОПУ)
|
C-ITS certificate policy authority (орган за политиката за предоставяне на удостоверения в СИТС)
|
CPOC (ЗКС)
|
C-ITS point of contact (звено за контакт за СИТС)
|
CPS (ДПУ)
|
certificate practice statement (декларация за практиката на удостоверяване)
|
CRL (САУ)
|
certificate revocation list (списък на отменените удостоверения)
|
EA (ОВ)
|
enrolment authority (орган по вписването)
|
EC (ПВ)
|
enrolment credential (пълномощия за вписване)
|
ECIES
|
elliptic curve integrated encryption scheme (интегрирана схема за криптиране, основана на елиптична крива)
|
EE (КС)
|
end-entity (i.e. C-ITS station) (краен субект, т.е. станция на СИТС)
|
ECTL (ДСЕУ)
|
European certificate trust list (доверителен списък на европейските удостоверения)
|
EU CCMS (СУПС на ЕС)
|
EU C-ITS security credential management system (система на ЕС за управление на пълномощията за сигурност в СИТС)
|
GDPR (ОРЗД)
|
General Data Protection Regulation (Общ регламент относно защитата на данните)
|
HSM (ХМС)
|
hardware security module (хардуерен модул за сигурност)
|
PKI (ИПК)
|
public key infrastructure (инфраструктура на публичния ключ)
|
RA (РегО)
|
registration authority (регистриращ орган)
|
sub-CA (второстепенен УО)
|
EA (ОВ) и AA (РО)
|
TLM (АДС)
|
trust list manager (администратор на доверителния списък)
|
Терминологичен справочник
applicant (заявител)
|
Физическо или юридическо лице, което подава заявление за издаване (или подновяване) на удостоверение. След като първоначалното удостоверение е създадено (инициализация), заявителят се нарича абонат.
За удостоверения, издадени на крайни субекти, абонатът (заявител на удостоверението) е субектът, който контролира или управлява/поддържа крайния субект, на който е издадено удостоверението, дори ако самата заявка за издаване на удостоверението е изпратена от крайния субект.
|
authorisation authority (разрешаващ орган)
|
В този документ понятието „разрешаващ орган“ (AA/РО) обхваща не само конкретните функции, изпълнявани от AA (РО), но и юридическия и/или оперативен субект, който ги управлява.
|
certification authority (удостоверяващ орган)
|
Базовият удостоверяващ орган, органът по вписването и разрешаващият орган, взети заедно, се наричат удостоверяващ орган (CA/УО).
|
C-ITS trust model (модел на доверие на СИТС)
|
Моделът на доверие на СИТС има за цел да се изградят отношения на доверие между станциите на СИТС. Той се прилага чрез PKI (ИПК), съставена от базови CA (УО), CPOC (ЗКС), TLM (АДС), EA (ОВ), AA (РО) и защитена мрежа.
|
crypto-agility (криптогъвкавост)
|
Способността на субектите в модела на доверие на СИТС да адаптират CP (ППУ) към променяща се среда или към нови бъдещи изисквания, напр. чрез периодична промяна на криптографските алгоритми и дължината на ключа.
|
cryptographic module (криптографски модул)
|
Защитен компонент, базиран на хардуер, в който се генерират и/или съхраняват ключове, генерират се случайни числа и се подписват или криптират данни.
|
enrolment authority (орган по вписването)
|
В този документ понятието „орган по вписването“ (EA/ОВ) обхваща не само конкретните функции, изпълнявани от EA (ОВ), но и юридическия и/или оперативен субект, който ги управлява.
|
PKI participants (участници в инфраструктурата на публичния ключ (PKI/ИПК)
|
Субекти в модела на доверие на СИТС, напр. TLM (АДС), базови CA (УО), EA (ОВ), AA (РО) и станции на СИТС.
|
re-keying (повторно въвеждане на ключ)
|
|
repository (хранилище)
|
Хранилището, използвано за съхраняване на удостоверенията и на информация за удостоверенията, предоставени от субектите в модела на доверие на СИТС, както е определено в раздел 2.3.
|
root certification authority (базов удостоверяващ орган)
|
В този документ понятието „базов удостоверяващ орган“ (CA/УО) обхваща не само конкретните функции, изпълнявани от CA (УО), но и юридическия и/или оперативен субект, който ги управлява.
|
subject (субект)
|
Физическо лице, устройство, система, единица или юридическо лице, упоменати в удостоверението като субект, т.е. или самият абонат или устройство под контрола и управлението на абоната.
|
subscriber (абонат)
|
Физическо или юридическо лице, на което е издадено удостоверение и което е правно обвързано от абонаментен договор или от споразумение за условията за ползване.
|
subscriber agreement (абонаментен договор)
|
Договор между CA (УО) и заявителя/абоната, в който са определени правата и задълженията на страните.
|
1.3.Участници в инфраструктурата на публичния ключ (PKI/ИПК)
1.3.1.Въведение
Участниците в PKI (ИПК) изпълняват функция в PKI (ИПК), определена в настоящата политика. Освен ако е изрично забранено, един участник може да изпълнява няколко функции едновременно. На даден участник може да бъде забранено да изпълнява определени функции едновременно, за да се избегнат конфликти на интереси или да се осигури разделение на задълженията.
Участниците могат също да делегират част от своите функции на други субекти като част от договор за услуги. Например CRL (САУ), въз основа на който се предоставя информация дали дадено удостоверение е отменено, също се издава от CA (ОУ), но последният може да делегира отговорността за неговото издаване на друг субект.
Функциите в PKI (ИПК) обхващат:
·авторитетни (authoritative) функции, т.е. функции, които се създават (инстанцират) само веднъж;
·оперативни функции, т.е. функции, които могат да бъдат инстанцирани в един или повече субекти.
Например функциите на базов СА (УО) могат да бъдат изпълнявани от търговска организация, група с общ интерес, национална организация и/или европейска организация.
На фигура 1 е показана архитектурата на модела на доверие на СИТС въз основа на [2]. Тук архитектурата е описана накратко, но основните звена са разгледани по-подробно в раздели 1.3.2 до 1.3.6.
CPA (ОПУ) определя TLM (АДС), с което той става доверен субект за всички участници в PKI (ИПК). CPA (ОПУ) одобрява операциите на базовия(ите) CA (УО) и потвърждава, че TLM (АДС) може да им се довери. TLM (АДС) издава ECTL (ДСЕУ), с което уверява всички участници в PKI (ИПК), че могат да имат доверие на одобрения базов CA (УО). Базовият CA (УО) издава удостоверения на EA (ОВ) и AA (РО), с което потвърждава доверието в техните операции. EA (ОВ) издава удостоверения за вписване на изпращащите и препращащите станции на СИТС, с което потвърждава доверието в техните операции. Въз основа на доверието в EA (ОВ) AA (РО) издава AT (ТР) на станциите на СИТС.
Получаващата и препращащата станция на СИТС (като препращаща страна) може да има доверие на други станции на СИТС, тъй като AT (ТР) са издадени от AA (РО), на който базовият CA (УО) се доверява и който, от своя страна, се ползва с доверието на TLM (АДС) и на CPA (ОПУ).
Моля, отбележете, че на фигура 1 е описан моделът на доверие на СИТС само на ниво базов CA (УО). Подробности за по-ниските нива са дадени в следващите раздели на настоящата CP (ППУ) или в CPS (ДПУ) на конкретните базови CA (УО).
На фигура 2 са представени обобщено информационните потоци между участниците в PKI (ИПК). Със зелените точки са обозначени потоците, за които е необходима комуникация машина—машина. Информационните потоци, отбелязани с червено, подлежат на определени изисквания за сигурност.
Моделът на доверие на СИТС се основава на архитектура с множество базови CA (УО), при която удостоверенията на базовия CA (УО) се предават периодично (както е описано по-долу) към централното звено за контакт (CPOC/ЗКС) посредством защитен протокол (напр. свързани удостоверения), определен от CPOC (ЗКС).
Един базов CA (УО) може да бъде управляван от правителствена или от частна организация. В архитектурата на модела на доверие на СИТС е предвиден поне един базов CA (УО) (базовият CA (УО) на ЕС, намиращ се на същото йерархично ниво като останалите CA (УО). Базовият CA (УО) на ЕС е оправомощен от всички субекти, участващи в модела на доверие на СИТС, които не желаят да създадат свой собствен базов CA (УО). CPOC (ЗКС) предава получените удостоверения на базовия CA (УО) към TLM (АДС), който отговаря за съставянето и подписването на списъка на удостоверения на базовия CA (УО) и за изпращането им обратно на CPOC (ЗКС), което ги прави публично достъпни за всички (вж. по-долу).
Отношенията на доверие между субектите в модела на доверие на СИТС са описани в следващите фигури, таблици и раздели.
Фигура 1: Архитектура на модела на доверие на СИТС
Фигура 2: Информационни потоци в модела на доверие на СИТС
Идентификация на потока
|
От
|
Към
|
Съдържание
|
Препратка
|
(1).
|
CPA (ОПУ)
|
TLM (АДС)
|
одобряване на заявление на базов CA (УО)
|
8
|
(2).
|
CPA (ОПУ)
|
TLM (АДС)
|
информация за отмяна на базов CA (УО)
|
8.5
|
(3).
|
CPA (ОПУ)
|
базов CA (УО)
|
актуализация на CP (ППУ)
|
1.5
|
(4).
|
CPA (ОПУ)
|
базов CA (УО)
|
одобряване/отхвърляне на заявление на базов CA (УО) или на заявка за промени в CPS (ДПУ) или в процедурите за одит
|
8.5, 8.6
|
(5).
|
TLM (АДС)
|
CPA (ОПУ)
|
уведомление за промяна в ECTL (ДСЕУ)
|
4, 5.8.1
|
(6).
|
TLM (АДС)
|
CPOC (ЗКС)
|
Удостоверение на TLM (АДС)
|
4.4.2
|
(7).
|
TLM (АДС)
|
CPOC (ЗКС)
|
ECTL (ДСЕУ)
|
4.4.2
|
(8).
|
CPOC (ЗКС)
|
TLM (АДС)
|
информация за удостоверение на базов CA (УО)
|
4.3.1.1
|
(9).
|
CPOC (ЗКС)
|
TLM (АДС)
|
отмяна на удостоверение на базов CA (УО)
|
7.3
|
(10).
|
CPOC (ЗКС)
|
всички крайни субекти
|
Удостоверение на TLM (АДС)
|
4.4.2
|
(11).
|
базов CA (УО)
|
CPOC (ЗКС)
|
информация за удостоверение на базов CA (УО)
|
4.3.1.1
|
(12).
|
базов CA (УО)
|
CPOC (ЗКС)
|
отмяна на удостоверение на базов CA (УО)
|
7.3
|
(13).
|
базов CA (УО)
|
одитор
|
задание за одит
|
8
|
(14).
|
базов CA (УО)
|
CPA (ОПУ)
|
заявление на базов CA (УО) — първоначална заявка
|
4.1.2.1
|
(15).
|
базов CA (УО)
|
CPA (ОПУ)
|
заявление на базов CA (УО) — промени в CPS (ДПУ)
|
1.5.1
|
(16).
|
базов CA (УО)
|
CPA (ОПУ)
|
заявление на базов CA (УО) — одитен доклад
|
8.6
|
(17).
|
базов CA (УО)
|
CPA (ОПУ)
|
доклади на базов CA (УО) относно инциденти, включително отмяна на правомощия на второстепенни CA (УО) [EA (ОВ), AA (РО)]
|
Приложение III, точка 7.3.1
|
(18).
|
базов CA (УО)
|
EA (ОВ)
|
отговор на удостоверение от страна на EA (ОВ)
|
4.2.2.3
|
(19).
|
базов CA (УО)
|
AA (РО)
|
отговор на удостоверение от страна на AA (РО)
|
4.2.2.3
|
(20).
|
базов CA (УО)
|
Всички
|
Удостоверение на EA (ОВ)/AA (РО), CRL (САУ)
|
4.4.2
|
(21).
|
EA (ОВ)
|
базов CA (УО)
|
заявка за удостоверение на EA (ОВ)
|
4.2.2.3
|
(22).
|
EA (ОВ)
|
Станции на СИТС
|
отговор на пълномощия за вписване
|
4.3.1.4
|
(23).
|
EA (ОВ)
|
AA (РО)
|
отговор на разрешение
|
4.2.2.5
|
(24).
|
AA (РО)
|
базов CA (УО)
|
заявка за удостоверение на AA (РО)
|
4.2.2.3
|
(25).
|
AA (РО)
|
EA (ОВ)
|
заявка за издаване на разрешение
|
4.2.2.5
|
(26).
|
AA (РО)
|
Станции на СИТС
|
отговор на талон за разрешение
|
4.3.1.5
|
(27).
|
EA (ОВ)
|
базов CA (УО)
|
подаване на заявка
|
4.1.2.3
|
(28).
|
AA (РО)
|
базов CA (УО)
|
подаване на заявка
|
4.1.2.3
|
(29).
|
базов CA (УО)
|
EA (ОВ)
|
отговор
|
4.12 и 4.2.1
|
(30).
|
базов CA (УО)
|
AA (РО)
|
отговор
|
4.12 и 4.2.1
|
(31).
|
Станции на СИТС
|
EA (ОВ)
|
заявка за пълномощия за вписване
|
4.2.2.4
|
(32).
|
Станции на СИТС
|
AA (РО)
|
заявка за талон за разрешение
|
4.2.2.5
|
(33).
|
производител/оператор
|
EA (ОВ)
|
регистрация
|
4.2.1.4
|
(34).
|
производител/оператор
|
EA (ОВ)
|
деактивиране
|
7.3
|
(35).
|
EA (ОВ)
|
производител/оператор
|
отговор
|
4.2.1.4
|
(36).
|
одитор
|
базов CA (УО)
|
доклад
|
8.1
|
(37).
|
всички
|
CPA (ОПУ)
|
заявка за промяна в CP (ППУ)
|
1.5
|
(38).
|
TLM (АДС)
|
CPA (ОПУ)
|
формуляр за заявление
|
4.1.2.2
|
(39).
|
CPA (ОПУ)
|
TLM (АДС)
|
одобряване/отхвърляне
|
4.1.2.2
|
(40).
|
TLM (АДС)
|
CPA (ОПУ)
|
одитен доклад
|
4.1.2.2
|
Таблица 1:
Подробно описание на информационните потоци в модела на доверие на СИТС
1.3.2.Орган за политиката за предоставяне на удостоверения в СИТС
1)Органът за политиката за предоставяне на удостоверения в СИТС (CPA/ОПУ) включва представители на заинтересовани страни от публичния и от частния сектор (напр. държави членки, производители на превозни средства и т.н.), участващи в модела на доверие на СИТС. Той отговаря за две второстепенни функции:
1)управление на политиката за предоставяне на удостоверения, което включва:
·одобряване на съществуващата CP (ППУ) и на бъдещи искания за промени в нея;
·разглеждане на искания за промени в CP (ППУ) и на препоръки, внесени от други участници в PKI (ИПК) или субекти, и вземане на решения по тях;
·вземане на решение за издаване на нови версии на CP (ППУ);
2)управление на предоставянето на разрешения за PKI (ИПК), което включва:
·определяне, утвърждаване и публикуване на процедурите за одобрение на CPS (ДПУ) и за одит на CA (УО) (наричани общо „процедури за одобрение на CA (УО)“);
·упълномощаване на CPOC (ЗКС) да извършва дейност и да докладва редовно;
·упълномощаване на TLM (АДС) да извършва дейност и да докладва редовно;
·одобряване на CPS (ДПУ) на базовия CA (УО), ако съответства на действащата обща CP (ППУ);
·проверяване на докладите от одита на независимия одитор на PKI (ИПК) за всички базови CA (УО);
·уведомяване на TLM (АДС) за списъка на одобрените или неодобрените базови CA (УО) и за предоставените от тях удостоверения въз основа на получени доклади за одобрение от базовите CA (УО) и на редовни оперативни доклади.
2)Упълномощеният представител на CPA (ОПУ) отговаря за удостоверяване на идентичността на упълномощения представител на TLM (АДС) и за одобряване на формуляра за заявление за вписване, прилаган от TLM (АДС). CPA (ОПУ) упълномощава TLM (АДС) да работи, както е описано в този раздел.
1.3.3.Администратор на доверителния списък
3)TLM (АДС) е самостоятелен субект, назначен от CPA (ОПУ).
4)TLM (АДС) отговаря за:
·управлението на ECTL (ДСЕУ) в съответствие с действащата обща CP (ППУ) и редовното отчитане на дейностите пред CPA (ОПУ) с оглед на цялостното функциониране на модела на доверие на СИТС в защитена среда;
·получаване на удостоверения на базови CA (УО) от CPOC (ЗКС);
·включване/изключване на удостоверения на базови CA (УО) във/от ECTL (ДСЕУ) след уведомление от CPA (ОПУ);
·заверяване на ECTL (ДСЕУ);
·редовното и навременно предаване на ECTL (ДСЕУ) към CPOC (ЗКС).
1.3.4.Независим одитор на PKI (ИПК)
5)Независимият одитор на PKI (ИПК) отговаря за:
·извършване или организиране на одити на базови CA (УО), TLM (АДС) и второстепенни CA (УО);
·внасяне на одитен доклад (от първоначален или периодичен одит) в CPA (ОПУ) в съответствие с изискванията на раздел 8 по-долу. Одитният доклад следва да съдържа препоръки на независимия одитор на PKI (ИПК);
·уведомяване на субекта, който ръководи базовия CA (УО), за успешното или неуспешното приключване на първоначален или периодичен одит на второстепенни CA (УО);
·оценяване на съответствието на CPS (ДПУ) с настоящата CP (ППУ).
1.3.5.Звено за контакт за СИТС (CPOC/ЗКС)
6)CPOC (ЗКС) е самостоятелен субект, назначен от CPA (ОПУ). Упълномощеният представител на CPA (ОПУ) отговаря за удостоверяване на идентичността на упълномощения представител на CPOC (ЗКС) и за одобряване на формуляра за заявление за вписване, прилаган от CPOC (ЗКС). CPA (ОПУ) упълномощава CPOC (ЗКС) да работи, както е описано в този раздел.
7)CPOC (ЗКС) отговаря за:
·създаване и поддържане на условия за защитен обмен на информация между всички субекти в модела на доверие СИТС по ефективен и бърз начин;
·разглеждане на искания за промени в процедурите и на препоръки, внесени от други участници в модела на доверие (напр. базови CA (УО);
·предаване на удостоверения на базови CA (УО) към TLM (АДС);
·публикуване на общата общата котва на доверие (trust anchor) (настоящия публичен ключ или свързано удостоверение на TLM (АДС);
·публикуване на ECTL (ДСЕУ).
Пълна информация за ECTL (ДСЕУ) може да бъде намерена в раздел 7.
1.3.6.Оперативни функции
8)Следните субекти, определени в [2], изпълняват оперативни функции, както е описано в RFC 3647:
Функционален компонент
|
Функция в PKI (ИПК) ([3] и [4])
|
Подробно описание на функцията ([2])
|
базов удостоверяващ орган
|
CA (УО)/RA (РегО) (регистриращ орган)
|
Предоставя доказателство на EA (ОВ) и AA (РО), че могат да издадат EC (ПВ) или AT (ТР)
|
орган по вписването
|
абонат на базов CA (УО)/обект на удостоверение на EA (ОВ)
CA (УО)/RA (РегО)
|
Удостоверява идентичността на станция на СИТС и ѝ предоставя достъп до комуникацията в ИТС
|
разрешаващ орган
|
абонат на базов CA (УО)/обект на удостоверение на AA (РО)
CA (УО)/RA (РегО)
|
Предоставя на станция на СИТС неоспоримо доказателство, че може да ползва конкретни услуги на ИТС
|
изпращаща станция на СИТС
|
обект на удостоверение за краен субект (EE/КС) (EC/ПВ)
|
Получава права за достъп до комуникацията в ИТС от EA (ОВ)
Договаря получаването на права от AA (РО) за услуги на ИТС за достъп до други услуги
Изпраща преки съобщения между два възела (single-hop) и препраща съобщения чрез релейна връзка
|
релейна (препращаща) станция на СИТС
|
препращаща страна/обект на удостоверение за EE (КС)
|
Получава излъчени съобщения от изпращаща станция на СИТС и ги препраща към получаваща станция на СИТС, ако е необходимо
|
получаваща станция на СИТС
|
препращаща страна
|
Получава излъчени съобщения от изпращаща или препращаща станция на СИТС
|
производител
|
абонат на EA (ОВ)
|
Въвежда необходимата информация за управление на сигурността в станцията на СИТС по време на производството
|
оператор
|
абонат на EA (ОВ)/AA (РО)
|
Въвежда и актуализира необходимата информация за управление на сигурността в станцията на СИТС по време на експлоатацията
|
Таблица 2: Оперативни функции
Забележка: в съответствие с [4] в настоящата CP (ППУ) се използват различни понятия за „абоната“, който сключва договор с CA (УО) за издаването на удостоверение, и „обекта“, за който се отнася удостоверението. Абонатите са субекти, които имат договорни отношения с даден CA (УО). Обектите са физически или юридически лица, за които се отнася удостоверението. EA (ОВ)/AA (РО) са абонати и обекти на базовия CA (УО) и могат да искат удостоверения за EA (ОВ)/AA (РО). Станциите на СИТС са обекти и могат да искат удостоверения за крайни субекти.
9)Регистриращи органи:
EA (ОВ) изпълнява функциите на регистриращ орган по отношение на крайните субекти. Само абонат, чиято идентичност е удостоверена и който има съответното разрешение, може да регистрира нови крайни субекти (станции на СИТС) в EA (ОВ). По отношение на EA (ОВ) и AA (РО) функциите на регистриращ орган се изпълняват от базовия CA (УО).
1.4.Ползване на удостоверенията
1.4.1.Приложими области на употреба
10)Удостоверенията, издадени съгласно настоящата СР (ППУ), са предназначени да бъдат ползвани за валидиране на електронни подписи в комуникационния контекст на съвместната ИТС в съответствие с еталонната архитектура, представена в [2].
11)Възможната употреба на удостоверенията от страна на TLM (АДС), базовите CA (УО), EA (ОВ), AA (РО) и крайните субекти е описана в профилите на удостоверенията, определени в [5].
1.4.2.Граници на отговорността
12)Удостоверенията не са предназначени, нито могат да бъдат ползвани при:
·обстоятелства, които престъпват, нарушават или противоречат на който и да е приложим закон, регламент (напр. GDPR/ОРЗД), указ или правителствено постановление;
·обстоятелства, които престъпват, нарушават или накърняват правата на трети страни;
·нарушения на настоящата CP (ППУ) или на съответния абонаментен договор;
·всякакви обстоятелства, при които ползването им може да доведе до смърт, телесни повреди или сериозни щети за околната среда (напр. при неизправност в работата на ядрени съоръжения, системи за навигация или комуникация на въздухоплавателни средства или системи за контрол на оръжията);
·обстоятелства, които противоречат на общите цели за по-голяма безопасност на пътя и по-ефективен автомобилен транспорт в Европа.
1.5.Административно управление на политиката за предоставяне на удостоверения
1.5.1.Осъвременяване на CPS (ДПУ) на CA (УО), включени в ECTL (ДСЕУ)
13)Всеки базов CA (УО), включен в ECTL (ДСЕУ), публикува своя CPS (ДПУ), която трябва да бъде в съответствие с настоящата политика. Базовият CA (УО) може да добави допълнителни изисквания, но трябва да гарантира, че всички изисквания на тази CP (ППУ) са изпълнени във всеки един момент.
14)Всеки базов CA (УО), включен в ECTL (ДСЕУ), прилага подходяща процедура за внасяне на изменения в своята CPS (ДПУ). Ключовите характеристики на процедурата за внасяне на изменения се документират в публично достъпната част на CPS (ДПУ).
15)Процедурата за внасяне на изменения следва да гарантира, че всички промени в настоящата CP (ППУ) се подлагат на внимателен анализ и CPS (ДПУ) се актуализира, ако е необходимо за привеждането ѝ в съответствие с изменената CP (ППУ), в определения срок за прилагане на изменения в CP (ППУ). Процедурата за внасяне на изменения в CPS (ДПУ) включва по-специално механизми за въвеждане на спешни промени, които гарантират своевременното прилагане на изменения в CP (ППУ), отнасящи се до сигурността.
16)Процедурата за внасяне на изменения в CPS (ДПУ) включва подходящи мерки за проверка на съвместимостта на всички промени със CP (ППУ). Всички промени в CPS (ДПУ) се документират ясно. Преди въвеждането в сила на нова CPS (ДПУ) нейното съответствие със CP (ППУ) трябва да бъде потвърдено от независим одитор на PKI (ИПК).
17)Базовият CA (УО) уведомява CPA (ОПУ) за всяка промяна в CPS (ДПУ), като предоставя поне следната информация:
·точно описание на изменението;
·мотиви за изменението;
·доклад от независимия одитор на PKI (ИПК), потвърждаващ съответствието със CP (ППУ);
·данни за връзка с лицето, отговарящо за CPS (ДПУ);
·планиран график за прилагане.
1.5.2.Процедури за одобряване на CPS (ДПУ)
18)Преди да започне дейността си, бъдещият базов CA (УО) представя своята CPS (ДПУ) на независим одитор на PKI (ИПК) в рамките на задание за одит на съответствието (поток 13) и на CPA (ОПУ) за одобрение (поток 15).
19)Преди да въведе в сила промени в своята CPS (ДПУ), базовият CA (УО) ги представя на независим одитор на PKI (ИПК) в рамките на задание за одит на съответствието (поток 13) и на CPA (ОПУ) за одобрение (поток 15).
20)EA (ОВ)/AA (РО) представя своята CPS (ДПУ) или направените в нея промени на базовия CA (УО). Базовият CA (УО) може да поиска удостоверение за съответствие от националния орган или от частен субект, който отговаря за одобрението на EA (ОВ)/AA (РО), както е посочено в раздели 4.1.2 и 8.
21)Независимият одитор на PKI (ИПК) оценява CPS (ДПУ) в съответствие с раздел 8.
22)Независимият одитор на PKI (ИПК) съобщава резултатите от оценката на CPS (ДПУ) в одитния доклад, както е указано в раздел 8.1. CPS (ДПУ) се приема или отхвърля в рамките на процедурата за приемане на одитния доклад, упомената в раздели 8.5 и 8.6.
2.Публикуване и отговорности по отношение на хранилищата
2.1.Методи за публикуване на информация за удостоверенията
23)Информация за удостоверенията може да бъде публикувана съгласно раздел 2.5:
·редовно или периодично; или
·по искане на някой от участващите субекти.
В зависимост от случая степента на спешност при публикуване на информация е различна и следователно важат различни срокове, но субектите трябва да са в състояние да откликнат и на двата варианта.
24)Редовното публикуване на такава информация дава възможност да се определи максимален срок, в рамките на който информацията за удостоверенията да бъде актуализирана във всички възли на мрежата на СИТС. Честотата на публикуване на всички видове информация за удостоверенията е указана в раздел 2.2.
25)По искане на субекти, участващи в мрежата на СИТС, всеки от участниците може да започне да публикува информация за удостоверенията по всяко време и, в зависимост от нейния статус, да поиска актуализирана информация за удостоверенията, така че да стане напълно доверен възел на мрежата на СИТС. Основната цел на това публикуване е субектите да бъдат информирани за цялостното текущо състояние на удостоверенията в мрежата и да могат да комуникират на надеждна основа до следващото редовно публикуване на информация.
26)Един базов CA (УО) също може да инициира публикуването на информация за удостоверенията по всяко време, като изпрати актуализиран набор от удостоверения до всички „абонирани членове“ в мрежата на СИТС, които са редовни получатели на такава информация. Това подпомага работата на CA (УО) и им дава възможност да се обръщат към членовете между редовните и планираните дати за публикуване на удостоверенията.
27)Механизмът и всички процедури за публикуване на удостоверения на базови CA (УО) и на ECTL (ДСЕУ) са посочени в раздел 2.5.
28)CPOC (ЗКС) публикува удостоверенията на базови CA (УО) (които са включени ECTL (ДСЕУ) и са предназначени за публично ползване), удостоверението на TLM (АДС) и ECTL (ДСЕУ), които го издава.
29)Базовите CA (УО) публикуват удостоверенията на своите EA (ОВ)/AA (РО), както и списъците на отменените удостоверения (CRL/САУ), и са в състояние да поддържат и трите механизма, посочени тук, за изпращането им до техните абонирани членове и доверяващи се страни, като предприемат всички необходими мерки, за да осигурят защитено предаване на данните, както е посочено в раздел 4.
2.2.Време или честота на публикуване
30)Изискванията по отношение на графика за публикуване на удостоверения и CRL (САУ) трябва да бъдат определени с оглед на различните ограничаващи фактори на отделните възли на СИТС, като общата цел е да се работи в „доверена мрежа“ и актуализациите да достигат възможно най-бързо до всички участващи станциите на СИТС.
·За защитеното функциониране на мрежата на СИТС е необходимо редовното публикуване на актуализирана информация за удостоверенията (напр. промени в състава на ECTL (ДСЕУ) или CRL (САУ) да се извършва поне на всеки три месеца.
·Базовите CA (УО) публикуват своите удостоверения CRL (САУ) възможно най-бързо след издаването им.
·За публикуването на CRL (САУ) се ползва хранилището на съответния базов CA (УО).
Срокът за публикуване на удостоверение след неговото издаване от страна на CA (УО) се посочва в CPS (ДПУ) на всеки CA (УО).
В този раздел са определени само времето или честота на редовното публикуване. Средства за свързване със станциите на СИТС, които да гарантират изпращането на актуализирани ECTL (ДСЕУ) и CRL (САУ) в рамките на една седмица от публикуването им (при нормални условия на работа, напр. наличие на клетъчно покритие, превозно средство в действителна експлоатация и т.н.), се осигуряват в съответствие с изискванията, определени в настоящия документ.
2.3.Хранилища
31)Изискванията относно структурата на хранилището за съхранение на удостоверения и информацията, която се предоставя от отделните субекти в мрежата на СИТС, са следните:
·по принцип всеки базов CA (УО) трябва да съхранява информация за действащите удостоверения на своите EA (ОВ)/AA (РО) и CRL (САУ) в собствено хранилище, за да публикува удостоверения за останалите участници в PKI (ИПК) (например услуга, базирана на лек протокол за достъп до справочници — LDAP). Хранилището на всеки базов CA (УО) следва да поддържа всички необходими средства за контрол на достъпа (раздел 2.4) и времена на предаване (раздел 2.2) за всеки метод на разпространение на информация, свързана със СИТС;
·хранилището на TLM (АДС) — в което се съхраняват например ECTL (ДСЕУ) и удостоверенията на TLM (АДС), публикувани от CPOC (ЗКС) — трябва да се основава на механизъм за публикуване, който може да осигури времената на предаване, посочени в раздел 2.2 за всеки метод на разпространение.
Не се предвиждат конкретни изисквания по отношение на AA (РО), но те трябва да поддържат същите нива на сигурност като останалите субекти и механизмите за това трябва да бъдат посочени в техните CPS (ДПУ).
2.4.Контрол на достъпа до хранилищата
32)Изискванията за контрол на достъпа до хранилища на информация за удостоверения следва да съответстват поне на общите стандарти за сигурност при работа с информация, описани в ISO/IEC 27001, и на изискванията, определени в раздел 4. Наред с това те следва да съответстват на нивото на сигурност, което трябва да бъде установено за отделните етапи на процеса при публикуване на информация за удостоверенията.
·Това включва създаване на хранилище за удостоверения на TLM (АДС) и за ECTL (ДСЕУ) в TLM (АДС)/CPOC (ЗКС). Всеки CA (УО) или оператор на хранилище въвежда механизми за контрол на достъпа за всички субекти в СИТС и за външни лица с поне три различни нива на достъп (напр. публичен, ограничен до субекти в СИТС, ограничен до нивото на базови CA (УО) с цел да се предотврати добавянето, променянето или изтриването на записи в хранилището от страна на неупълномощени лица.
·Конкретните механизми за контрол на достъпа на всеки отделен субект трябва да бъдат описани в съответната CPS (ДПУ).
·Хранилищата на всеки базов CA (УО), EA (ОВ) и AA (РО) следва да отговарят на същите изисквания по отношение на процедурите за контрол на достъпа, независимо от мястото или договорната връзка с доставчика на услуги, управляващ хранилището.
Като начало всеки базов CA (УО) или оператор на хранилище трябва да осигури поне три различни нива на достъп (напр. публичен, ограничен до субекти в СИТС, ограничен до нивото на базови CA (УО).
2.5.Публикуване на информация за удостоверенията
2.5.1.Публикуване на информация за удостоверенията от страна на TLM (АДС)
33)TLM (АДС) в общото европейско пространство на доверие на СИТС публикува следната информация чрез CPOC (ЗКС):
·всички валидни към момента удостоверения на TLM (АДС) за следващия период на действие (текущо и свързано удостоверение, ако има такова);
·информация за точката за достъп до хранилището на CPOC (ЗКС), което предоставя подписания списък на базовите CA (УО) (ECTL/ДСЕУ);
·звеното за обща информация относно ECTL (ДСЕУ) и разгръщането на СИТС.
2.5.2.Публикуване на информация за удостоверенията от страна на CA (УО)
34)Базовите СА (УО) в общото европейско пространство на доверие на СИТС публикуват следната информация:
·издадени (валидни към момента) удостоверения на базови СА (УО) (текущи и удостоверения, за които е бил въведен повторно ключ съгласно изискванията, включително свързаните с тях удостоверения), съхранявани в хранилището, упоменато в раздел 2.3;
·всички валидни субекти, изпълняващи функциите на EA (ОВ) и AA (РО), със съответния идентификационен номер на оператор и планиран период на действие;
·издадени удостоверения на СА (УО), съхранявани в хранилището, упоменато в раздел 2.3;
·CRL (САУ) за всички отменени удостоверения на СА (УО), отнасящи се до подчинените им EA (ОВ) и AA (РО);
·информация относно точката за достъп на базовия CA (УО) до информация за CRL (САУ) и СА (УО).
Цялата информация за удостоверенията се категоризира в три нива на поверителност, а документите за широката общественост трябва да бъдат публично достъпни без ограничения.
3.Идентифициране и удостоверяване на идентичността
3.1.Именуване
3.1.1.Видове имена
3.1.1.1.Имена на TLM (АДС), базови CA (УО), EA (ОВ), AA (РО)
35)Името в удостоверението на TLM (АДС) се състои от един атрибут „субект_име“ (subject_name) със запазена стойност „EU_TLM“.
36)Името на базовите CA (УО) се състои от един атрибут „субект_име“ (subject_name) със стойност, която се предоставя от CPA (ОПУ). Уникалността на имената е отговорност единствено на CPA (ОПУ), а регистърът на имената на базовите CA (УО) се поддържа от TLM (АДС) след уведомяване от CPA (ОПУ) (за одобрението, отмяната/отстраняването на базов CA/УО). Имената на субектите в удостоверенията са ограничени до 32 бита. Всеки базов СА (УО) дава предложение за своето име в заявлението до CPA (ОПУ) (поток 14). CPA (ОПУ) отговаря за проверката на уникалността на името. Ако името не е уникално, заявлението се отхвърля (поток 4).
37)Името в удостоверението на всеки EA (ОВ)/AA (РО) може да се състои от един атрибут „субект_име“ (subject_name) със стойност, генерирана от издателя на удостоверението. Уникалността на имената е отговорност единствено на издаващия базов CA (УО).
38)В удостоверенията на EA (ОВ) и AA (РО) не трябва да се ползват имена, надвишаващи 32 бита, тъй като имената на субектите в удостоверенията (subject_name) са ограничени до 32 бита.
39)AT (ТР) не съдържат имена.
3.1.1.2.Имена на крайни субекти
40)На всяка станция на СИТС се дават два вида единни идентификатори:
·каноничен идентификатор, който се съхранява при първоначалната регистрация на станцията на СИТС и е отговорност на производителя. Той съдържа символен подниз, указващ производителя или оператора така, че идентификаторът да е уникален;
·име на субекта (subject_name), което може да бъде част от EC (ПВ) на станцията на СИТС и е отговорност на EA (ОВ).
3.1.1.3.Идентификация на удостоверенията
41)Удостоверения, които следват формата, посочен в [5], се идентифицират чрез изчисляването на стойност за HashedId8, както е описано в [5].
3.1.2.Изискване за съдържателност на имената
Не се предвижда.
3.1.3.Анонимност и псевдонимност на крайните субекти
42)AA (РО) гарантира псевдонимност на дадена станция на СИТС, като я снабдява с AT (ТР), които не съдържат никакви имена или информация, свързващи субекта с действителната му идентичност.
3.1.4.Правила за тълкуване на различни форми на имената
Не се предвиждат.
3.1.5.Уникалност на имената
43)Имената на TLM (АДС), базови CA (УО), EA (ОВ), AA (РО) и каноничните идентификатори на станции на СИТС са уникални.
44)В процеса на регистрация на даден базов CA (УО) в ECTL (ДСЕУ) TLM (АДС) гарантира, че идентификаторът на неговото удостоверение (HashedId8) е уникален. В процеса на издаване на удостоверения базовият CA (УО) гарантира, че идентификаторът (HashedId8) на удостоверението на всеки подчинен CA (УО) е уникален.
45)Идентификаторът (HashedId8) на EC (ПВ) е уникален в рамките на издаващия CA (УО). Идентификаторът (HashedId8) на AT (ТР) не е необходимо да бъде уникален.
3.2.Първоначално валидиране на идентичността
3.2.1.Метод за доказване на притежаването на частен ключ
46)Базовият СА (УО) представя доказателства за правото си да притежава частния ключ, съответстващ на публичния ключ в подписаното от него удостоверение. Тези доказателства се проверяват от CPOC (ЗКС).
47)EA (ОВ)/AA (РО) представя доказателства за правото си да притежава частния ключ, съответстващ на публичния ключ, упоменат в удостоверението. Тези доказателства се проверяват от базовия CA (УО).
48)Притежаването на нов частен ключ (при повторно въвеждане на ключ) се доказва чрез подписване на заявката с новия частен ключ (вътрешен подпис) и последващо генериране на външен подпис върху вече подписаната заявка с валидния към момента частен ключ (за да се гарантира автентичността на заявката). Заявителят изпраща подписаната заявка за удостоверение до издаващия CA (УО) чрез защитено съобщение. Издаващият CA (УО) проверява дали цифровият подпис на заявителя в съобщението със заявката е създаден с частния ключ, съответстващ на публичния ключ, свързан със заявката за удостоверение. Базовият CA (УО) уточнява поддържаните от него заявки за удостоверения и отговори в своята CPS (ДПУ).
3.2.2.Удостоверяване на организационна идентичност
3.2.2.1.Удостоверяване на организационната идентичност на базови CA (УО)
49)В заявлението към CPA (ОПУ) (т.е. поток 14), базовият CA (УО) предоставя информация относно идентичността и регистрацията на организацията, която включва:
·име на организацията;
·пощенски адрес;
·адрес на електронна поща;
·името на физическо лице за контакт в организацията;
·телефонен номер;
·цифров пръстов отпечатък (т.е. хеш стойност SHA 256) на удостоверението на базовия CA (УО) на хартиен носител;
·криптографска информация (т.е. криптографски алгоритми, дължина на ключовете) в удостоверението на базовия CA (УО);
·всички разрешения, които базовият CA (УО) може да ползва и да прехвърля на второстепенни CA (УО).
50)CPA (ОПУ) проверява идентичността на организацията и друга информация, свързана с нейната регистрация, предоставена от заявителя в заявлението за вписване на удостоверение на базов CA (УО) в ECTL (ДСЕУ)
51)CPA (ОПУ) събира преки доказателства или иска писмено потвърждение от подходящ компетентен източник относно идентичността (напр. име) и, ако е приложимо, относно конкретни атрибути на субекти, на които е издадено удостоверение. Доказателствата могат да бъдат представени на хартиен носител или в електронен формат.
52)Идентичността на субекта се проверява по време на регистрацията с подходящи средства и в съответствие с настоящата политика за предоставяне на удостоверения.
53)Всяко заявление за издаване на удостоверение се придружава от документи, доказващи:
·пълното наименование на организационния субект (частна организация, държавно образувание или нетърговска организация);
·национално признат документ за регистрация или други сведения, които могат да бъдат използвани, за да се разграничи, доколкото е възможно, организационният субект от други със същото име.
Посочените по-горе правила се основават на TS 102 042 [4]: CA (УО) гарантира, че доказателствата за идентичността на абонати и субекти, достоверността на техните имена и свързаните с тях данни се проверяват надлежно като част от конкретната услуга или, когато е приложимо, се потвърждават чрез проверка на документи от подходящи компетентни източници и че заявките за удостоверения са точни, валидни и пълни и съответстват на събраните доказателства или документи.
3.2.2.2.Удостоверяване на организационната идентичност на TLM (АДС)
54)Организацията, която изпълнява функциите на TLM (АДС), предоставя доказателства за своята идентичност, за достоверността на името си и за свързаните с тях данни, които да позволят те да бъдат проверени по подходящ начин при първоначалното създаване и повторното въвеждане на ключ за удостоверението на TLM (АДС).
55)Идентичността на субекта се проверява с подходящи средства при създаване на удостоверението или при повторно въвеждане на ключ в съответствие с настоящата CP (ППУ).
56)Предоставят се доказателства за организацията, както е посочено в раздел 3.2.2.1.
3.2.2.3.Удостоверяване на организационната идентичност на второстепенни CA (УО)
57)Базовият CA (УО) проверява идентичността на организацията и друга информация, свързана с нейната регистрация, предоставена от заявителя в заявлението за удостоверение на второстепенен CA (УО).
58)Базовият CA (УО) предприема най-малко следните действия:
·установява, че организацията съществува, ползвайки поне една независима услуга или база данни за удостоверяване на идентичността, поддържана от трета страна, или въз основа на документация, потвърждаваща съществуването на организацията, издадена от или внесена в компетентна държавна институция или признат орган;
·ползва традиционна пощенска услуга или съпоставима процедура, при която от вносителя на заявление за удостоверение се изисква да предостави определена информация за организацията и да потвърди, че тя е разрешила да бъде подадено заявление за издаване на удостоверение и е упълномощила съответното лице да го внесе от името на заявителя. Когато в удостоверението се вписва името на лице, което се явява упълномощен представител на организацията, трябва да бъде потвърдено също, че това лице е наето от организацията и е упълномощено да действа от нейно име.
59)Процедурите за проверка при издаването на удостоверения на CA (УО) се документират в CPS (ДПУ) на базовия CA (УО).
3.2.2.4.Удостоверяване на идентичността на организации, абониращи крайни субекти
60)Преди дадена организация, абонираща крайни субекти (производител/оператор), да може да се регистрира в доверен EA (ОВ), за да даде възможност на своите абонати да изпращат заявки за удостоверения на EA (ОВ), EA (ОВ) предприема следните действия:
·проверява идентичността на организацията, абонираща крайни субекти, и друга информация, свързана с нейната регистрация, предоставена от заявителя в заявлението за удостоверение;
·проверява дали типът на станцията на СИТС (т.е. конкретният продукт въз основа на марката, модела и версията на станцията на СИТС) отговаря на всички критерии за оценка на съответствието.
61)EA (ОВ) предприема най-малко следните действия:
·установява, че организацията съществува, ползвайки поне една независима услуга или база данни за удостоверяване на идентичността, поддържана от трета страна, или въз основа на документация, потвърждаваща съществуването на организацията, издадена от или внесена в компетентна държавна институция или признат орган;
·ползва традиционна пощенска услуга или съпоставима процедура, при която от вносителя на заявление за удостоверение се изисква да предостави определена информация за организацията и да потвърди, че тя е разрешила да бъде подадено заявление за издаване на удостоверение и е упълномощила съответното лице да го внесе от нейно име. Когато в удостоверението се вписва името на лице, което се явява упълномощен представител на организацията, трябва да бъде потвърдено също, че това лице е наето от организацията и е упълномощено да действа от нейно име.
62)Процедурите за проверка при регистрирането на станция на СИТС от страна на нейния абонат се документират в CPS (ДПУ) на EA (ОВ).
3.2.3.Удостоверяване на идентичността на индивидуални субекти
3.2.3.1.Удостоверяване на идентичността на индивидуални субекти на TLM (АДС)/CA (УО)
63)За удостоверяване на идентичността (самоличността) на индивидуален субект (физическо лице), свързан с юридическо лице или организация (напр. абонат), се представят доказателства за следното:
·пълно име на лицето (включително фамилия и лични имена в съответствие с приложимото право и националните практики за установяване на самоличността);
·дата на раждане и месторождение, данни от национално признат документ за самоличност или други сведения на абоната, които могат да бъдат използвани, за да се разграничи, доколкото е възможно, лицето от други със същото име.
·пълно наименование и правен статут на свързаното юридическо лице или организация (напр. абонат);
·сведения за регистрацията на свързаното юридическо лице или организация;
·доказателства, удостоверяващи връзката на физическото лице със съответното юридическо лице или организация.
Доказателствата могат да бъдат представени на хартиен носител или в електронен формат.
64)За да удостовери самоличността си, упълномощеният представител на базов СА (УО), ЕА (ОВ), AA (РО) или абонат представя документи, доказващи, че работи за съответната организация (пълномощно). Лицето представя също официален документ за самоличност.
65)При първоначално вписване (поток 31/32) представителят на ЕА (ОВ)/AA (РО) представя всички необходими сведения на базовия CA (УО) (вж. раздел 4.1.2).
66)Служителите на базовия CA (УО) проверяват самоличността на представителя на вносителя на заявление за удостоверение и всички свързани с него документи, като прилага изискванията за „доверен персонал“, описани в раздел 5.2.1. (Процедурата за валидиране на информацията, посочена в заявлението, и за генериране на удостоверението от базовия CA (УО) се изпълнява от „доверени лица“ на базовия CA (УО) с най-малко две нива на надзор, тъй като това са чувствителни операции по смисъла на раздел 5.2.2).
3.2.3.2.Удостоверяване на идентичността на абонати на станции на СИТС
67)Абонатите се представляват от упълномощени крайни потребители на организацията, които са регистрирани в издаващия ЕА (ОВ) и AA (РО). Крайните потребители, определени от организациите (производители или оператори), доказват своята идентичност (самоличност) и автентичност, преди:
·да регистрират EE (КС) в съответния ЕА (ОВ), включително неговия публичен ключ, каноничен идентификатор (единен идентификатор) и разрешения в зависимост от конкретния EE (КС);
·да се регистрират в AA (РО) и да осигурят документ, удостоверяващ наличието на абонаментен договор, който може да бъде изпратен на ЕА (ОВ).
3.2.3.3.Удостоверяване на идентичността на станции на СИТС
68)EE (КС), които подлежат на EC (ПВ), удостоверяват идентичността (самоличността) си, когато искат EC (ПВ) (поток 31), със своя каноничен частен ключ, ползван при първоначалното удостоверяване на идентичността. ЕА (ОВ) проверяват идентичността с каноничния публичен ключ, съответстващ на конкретния EE (КС). Каноничните публични ключове на EE (КС) се изпращат на ЕА (ОВ), преди да бъде изпълнена първоначалната заявка, по защитен канал за комуникация между производителя или оператора на съответната станция на СИТС и ЕА (ОВ) (поток 33).
69)EE (КС), които подлежат на AT (ТР), удостоверяват идентичността (самоличността) си, когато искат AT (ТР) (поток 32), със своя уникален частен ключ за вписване. AA (РО) изпращат подписа на ЕА (ОВ) (поток 25) за валидиране; ЕА (ОВ) го проверяват и потвърждават неговата валидност на AA (РО) (поток 23).
3.2.4.Непроверена информация за абонатите
Не се предвижда.
3.2.5.Валидиране на органи
3.2.5.1.Валидиране на TLM (АДС), базов CA (УО), EA (ОВ), AA (РО)
70)Всяка организация посочва в своята CPS (ДПУ) поне един представител (напр. служител по сигурността), който отговаря за изпращането на заявки за нови удостоверения и за подновяването на удостоверения. Прилагат се правилата за именуване, посочени в раздел 3.2.3.
3.2.5.2.Валидиране на абонати на станции на СИТС
71)Поне едно физическо лице, отговарящо за регистрирането на станции на СИТС в ЕА (ОВ) (напр. служител по сигурността), трябва да бъде съобщено на и одобрено от ЕА (ОВ) (вж. раздел 3.2.3).
3.2.5.3.Валидиране на станции на СИТС
72)Всеки абонат на станция на СИТС може да регистрира станции на СИТС в конкретен ЕА (ОВ) (поток 33), стига неговата идентичност да бъде удостоверена от съответния ЕА (ОВ).
Ако станцията на СИТС е регистрирана в ЕА (ОВ) с единен каноничен идентификатор и с каноничен публичен ключ, тя може да поиска EC (ПВ), като отправи заявка, подписана с каноничния частен ключ, свързан с вече регистрирания каноничен публичен ключ.
3.2.6.Критерии за оперативна съвместимост
73)За нуждите на комуникацията между станции на СИТС и ЕА (ОВ) (или AA/РО) станцията на СИТС трябва да е в състояние да установи защитен канал за комуникация с ЕА (ОВ) (или AA/РО), т.е. да осигури функции за удостоверяване на идентичността, поверителност и цялост, както е предвидено в [1]. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1]. Тази защитена комуникация се поддържа от ЕА (ОВ) и AA (РО).
74)ЕА (ОВ) и AA (РО) поддържат заявки за удостоверения и отговори, съответстващи на изискванията на [1], който предвижда наличието на защитен протокол за изпращане/отговор на заявки за AT (ТР), осигуряващ анонимност на подателя по отношение на AA (РО) и разделение на задълженията между AA (РО) и ЕА (ОВ). Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1]. За да се предотврати разкриването на дългосрочната идентичност на станции на СИТС, комуникацията между дадена мобилна станция на СИТС и ЕА (ОВ) е поверителна (напр. комуникационните данни се криптират от край до край).
75)AA (РО) изпраща искане за валидиране (поток 25) за всяка заявка за удостоверяване на идентичността, която получава от EE (КС), притежаващ удостоверение. ЕА (ОВ) валидира тази заявка по отношение на:
·статуса на EE (КС) в ЕА (ОВ);
·валидността на подписа;
·исканите идентификатори на приложението на ИТС (ITS-AID) и разрешения;
·статуса на услугата, предоставяна от AA (РО) на абоната.
3.3.Идентифициране и удостоверяване на идентичността при подаване на заявки за повторно въвеждане на ключ
3.3.1.Идентифициране и удостоверяване на идентичността при подаване на заявки за рутинно повторно въвеждане на ключ
3.3.1.1.Удостоверения на TLM (АДС)
76)TLM (АДС) генерира една двойка ключове и две удостоверения: едно подписано саморъчно и едно свързано, както е посочено в раздел 7.
3.3.1.2.Удостоверения на базови CA (УО)
Не е приложимо.
3.3.1.3.Подновяване на удостоверения или повторно въвеждане на ключове на EA (ОВ)/AA (РО)
77)Преди изтичането на удостоверение на ЕА (ОВ)/AA (РО), ЕА (ОВ)/AA (РО) изпраща заявка за ново удостоверение (поток 21/поток 24), за да се поддържа непрекъснатост в ползването на удостоверения. ЕА (ОВ)/AA (РО) генерира нова двойка ключове, която да замени изтичащата, и подписва заявката за повторно въвеждане на ключ, която съдържа новия публичен ключ, с валидния към момента частен ключ („повторно въвеждане на ключ“). ЕА (ОВ) или AA (РО) генерира нова двойка ключове и подписва заявката с новия частен ключ (вътрешен подпис), за да удостовери, че го притежава. Цялата заявка се подписва (преподписва) с валидния към момента частен ключ (външен подпис), за да се гарантира нейната цялост и автентичност. Ако се използва двойка ключове за криптиране и декриптиране, притежаването на частни ключове за декриптиране трябва да бъде доказано (за подробно описание на процедурата за повторно въвеждане на ключове, вж. раздел 4.7.3.3).
78)Методът за идентифициране и удостоверяване на идентичността при рутинно повторно въвеждане на ключове е същият като при първоначалното валидиране на удостоверение на базов CA (УО), описан в раздел 3.2.2.
3.3.1.4.Пълномощия за вписване на крайни субекти
79)Преди изтичането на съществуващи EC (ПВ), EE (КС) изпраща заявка за ново удостоверение (поток 31), за да се поддържа непрекъснатост в ползването на удостоверения. EE (КС) генерира нова двойка ключове, която да замени изтичащата, и изпраща заявка за ново удостоверение, което съдържа новия публичен ключ. заявката се подписва с валидния към момента частен ключ на EE (КС).
80)EE (КС) може да подпише заявката с новосъздадения частен ключ (вътрешен подпис), за да удостовери, че го притежава. След това цялата заявка се подписва (преподписва) с валидния към момента частен ключ (външен подпис) и се изпраща в криптиран вид до съответния EA (ОВ), както е посочено в [1], за да се гарантира нейната поверителност, цялост и автентичност. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1].
3.3.1.5.Талони за разрешение на крайни субекти
81)Повторното въвеждане на ключ за удостоверения за AT (ТР) се извършва по същата процедура както и първоначалното предоставяне на разрешение, която е описана в [1]. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1].
3.3.2.Идентифициране и удостоверяване на идентичността при подаване на заявки за повторно въвеждане на ключ след отмяна
3.3.2.1.Удостоверения на CA (УО)
82)Удостоверяването на идентичността на организация, която изпълнява функциите на CA (УО), при повторно въвеждане на ключ след отмяна на удостоверение на базов CA (УО), ЕА (ОВ) и AA (РО) се извършва по същия начин както и при първоначалното издаване на удостоверение на CA (УО), описано раздел 3.2.2.
3.3.2.2.Пълномощия за вписване на крайни субекти
83)Удостоверяването на идентичността на EE (КС) при повторно въвеждане на ключ след отмяна на удостоверение за EC (ПВ) се извършва по същия начин както и при първоначалното издаване на удостоверение на EE (КС), описано раздел 3.2.2.
3.3.2.3.Заявки за издаване на разрешение на крайни субекти
Не е приложимо, тъй като AT (ТР) не се отменят.
3.4.Идентифициране и удостоверяване на идентичността при подаване на заявка за отмяна
3.4.1.Удостоверения на базови CA (УО)/EA (ОВ)/AA (РО)
84)Идентичността на заявки за премахване на удостоверение на базов CA (УО) от ECTL (ДСЕУ) се удостоверява от базовия CA (УО), който изпраща потвърждение на TLM (АДС) (поток 12 и поток 9). Идентичността на заявки за отмяна на удостоверение на ЕА (ОВ)/AA (РО) се удостоверява от съответния базов CA (УО) и от самите второстепенни CA (УО).
85)Приемливите процедури за удостоверяване на идентичността на заявки за отмяна, изпратени от абонати, включват:
·писмено и подписано искане за отмяна, изложено на официална бланка на абоната, с данни за удостоверението, което трябва да бъде отменено;
·комуникация с абоната, която дава възможност да се получат разумни гаранции, че лицето или организацията, поискали отмяната, действително е абонатът. В зависимост от обстоятелствата тази комуникация може да бъде осъществена с някое от следните средства: електронна поща, традиционна поща или куриерска услуга.
3.4.2.Пълномощия за регистрация на станции на СИТС
86)Абонат на станция на СИТС може да отмени EC (ПВ) на станцията, регистрирани в ЕА (ОВ) (поток 34). За тази цел абонатът изпраща заявка за отмяна, която може да се отнася за една или за повече станции на СИТС. Преди да обработи заявката, ЕА (ОВ) удостоверява идентичността на подателя, след което потвърждава отмяната на станциите на СИТС и на техните EC (ПВ).
87)ЕА (ОВ) може да отмени EC (ПВ) на дадена станция на СИТС съгласно раздел 7.3.
3.4.3.Талони за разрешение на станции на СИТС
88)Тъй като AT (ТР) не подлежат на отмяна, тяхната валидност се ограничава до определен период. Приемливият обхват, в който може да се движи периодът на валидност, е определен в раздел 7 на настоящата политика за предоставяне на удостоверения.
4.Оперативни изисквания за жизнения цикъл на удостоверенията
4.1.Заявление за издаване на удостоверение
89)В този раздел са описани изискванията за подаване на първоначално заявление за издаване на удостоверение.
90)Понятието „заявление за издаване на удостоверение“ обхваща следните процедури:
·регистрация и изграждане на отношения на доверие между TLM (АДС) и CPA (ОПУ);
·регистрация и изграждане на отношения на доверие между базовия CA (УО) и CPA (ОПУ) и TLM (АДС), включително вписване на първото удостоверение на базовия CA (УО) в ECTL (ДСЕУ);
·регистрация и изграждане на отношения на доверие между ЕА (ОВ)/AA (РО) и базовия CA (УО), включително издаване на удостоверение на ЕА (ОВ)/AA (РО);
·регистрация на станцията на СИТС в ЕА (ОВ) от страна на производителя/оператора;
·заявка EC (ПВ)/AT (ТР) от страна на станцията на СИТС.
4.1.1.Кой може да подаде заявление за издаване на удостоверение
4.1.1.1.Базови CA (УО)
91)Базовите CA (УО) генерират своите двойки ключове и издават базовото си удостоверение сами. Базов CA (УО) може да подаде заявление за издаване на удостоверение чрез лицето, определено да го представлява (поток 14).
4.1.1.2.TLM (АДС)
92)TLM (АДС) генерира своите двойки ключове и издава удостоверението си сам. Първоначалното създаване на удостоверение на TLM (АДС) се обработва от представител на организацията на TLM (АДС) под контрола на CPA (ОПУ).
4.1.1.3.EA (ОВ) и AA (РО)
93)Заявление за издаване на удостоверение на второстепенен CA (УО) (ЕА/ОВ и/или AA/РО) може да бъде подадено от упълномощен представител на ЕА (ОВ) или на AA (РО) до упълномощения представител на съответния базов CA (УО) (поток 27/28).
4.1.1.4.Станции на СИТС
94)Абонатите регистрират всяка станция на СИТС в ЕА (ОВ) в съответствие с раздел 3.2.5.3.
95)Всяка станция на СИТС, регистрирана в ЕА (ОВ), може да изпраща заявки за EC (ПВ) (поток 31).
96)Всяка станция на СИТС може да изпраща заявки за AT (ТР) (поток 32), без да се изисква никакво действие от страна на абоната. Преди да изпрати заявка за AT (ТР), станцията на СИТС трябва да е получила EC (ПВ).
4.1.2.Процедура за вписване и отговорности
97)Разрешения на базови и второстепенни CA (УО), които издават удостоверения за специални (правителствени) цели (т.е. специални мобилни и фиксирани станции на СИТС), могат да бъдат дадени само от държавите членки, в които се намират съответните организации.
4.1.2.1.Базови CA (УО)
98)След като преминат през одит (поток 13 и поток 36, раздел 8), базовите CA (УО) могат да подадат заявление за вписване на техните удостоверения в ECTL (ДСЕУ) на CPA (ОПУ) (поток 14). Процедурата по вписване се задейства с внасянето на саморъчно подписано заявление, което се доставя на хартиен носител в CPA (ОПУ) от упълномощен представител на базовия CA (УО) и съдържа поне информацията, посочена в раздели 3.2.2.1, 3.2.3 и 3.2.5.1.
99)Заявлението на базовия CA (УО) се подписва от неговия упълномощен представител.
100)Освен заявлението упълномощеният представител на базовия CA (УО) внася в CPA (ОПУ) за одобрение копие от CPS (ДПУ) на базовия CA (УО) (поток 15) и доклад от извършен одит (поток 16). Ако документите бъдат одобрени, CPA (ОПУ) генерира и изпраща удостоверение за съответствие на CPOC (ЗКС)/TLM (АДС) и на самия базов CA (УО).
101)Едва тогава упълномощеният представител на базовия CA (УО) внася заявлението (съдържащо цифровия пръстов отпечатък на подписаното от него удостоверение) в CPOC (ЗКС)/TLM (АДС) заедно с официален документ за самоличност и доказателство за дадените му пълномощия. Саморъчно подписаното удостоверение се изпраща на CPOC (ЗКС)/TLM (АДС) по електронен път. CPOC (ЗКС)/TLM (АДС) проверява всички документи и саморъчно подписаното удостоверение.
102)Ако резултатът от проверката е положителен, TLM (АДС) вписва удостоверението на базовия CA (УО) в ECTL (ДСЕУ) след уведомление от CPA (ОПУ) (поток 1 и поток 2). Процедурата се описва подробно в CPS (ДПУ) на TLM (АДС).
103)Може да бъде предвидена и допълнителна процедура за одобряване на CPS (ДПУ) и на доклада от одита на базовия CA (УО) от национален орган в съответната държава.
4.1.2.2.TLM (АДС)
104)След като премине през одит, TLM (АДС) може да бъде вписан в CPA (ОПУ). Процедурата по вписване се задейства с внасянето на саморъчно подписано заявление, което се доставя на хартиен носител в CPA (ОПУ) (поток 38) от упълномощен представител на TLM (АДС) и съдържа поне информацията, посочена в раздели 3.2.2.2 и 3.2.3.
105)Заявлението на TLM (АДС) се подписва от неговия упълномощен представител.
106)Най-напред TLM (АДС) генерира подписаното от него удостоверение и го изпраща по защитен начин до CPA (ОПУ). След това TLM (АДС) внася заявлението (съдържащо цифровия пръстов отпечатък на подписаното от него удостоверение) в CPA (ОПУ) заедно с официален документ за самоличност и доказателство за дадените му пълномощия (поток 40). CPA (ОПУ) проверява всички документи и саморъчно подписаното удостоверение. Ако резултатът от проверката на всички документи, саморъчно подписаното удостоверение и цифровия пръстов отпечатък е положителен, CPA (ОПУ) потвърждава вписването, като изпраща своето одобрение на TLM (АДС) и на CPOC (ЗКС) (поток 39). CPA (ОПУ) съхранява изпратената от TLM (АДС) информация във връзка със заявлението. Удостоверението на TLM (АДС) се издава чрез CPOC (ЗКС).
4.1.2.3.EA (ОВ) и AA (РО)
107)По време на процедурата по вписване ЕА (ОВ)/AA (РО) представят необходимите документи (напр. CPS (ДПУ) и доклад от одит) на съответния базов CA (УО) за одобрение (поток 27/28). Ако резултатът от проверката на документите е положителен, базовият CA (УО) изпраща одобрение на съответните второстепенни CA (УО) (поток 29/30). След това второстепенните CA (УО) (ЕА/ОВ или AA/РО) изпращат подписаната си заявка по електронен път и представят своето заявление на хартиен носител (в съответствие с раздел 3.2.2.1) на съответния базов CA (УО) заедно с документ за правомощия и документ за самоличност. Базовият CA (УО) проверява заявката и получените документи (заявлението, съдържащо цифровия пръстов отпечатък, т.е. хеш стойността SHA 256 на заявката на второстепенния CA (УО), документа за правомощия и документа за самоличност). Ако резултатът от всички проверки е удовлетворителен, базовият CA (УО) издава удостоверение на съответния второстепенен CA (УО). Процедурата за подаване на първоначалната заявка се описва подробно в неговата CPS (ДПУ).
108)Освен заявлението упълномощеният представител на второстепенния CA (УО) представя на базовия CA (УО) копие на CPS (ДПУ).
109)На независимия одитор на PKI (ИПК) се предоставя информация за целите на одита в съответствие с раздел 8.
110)Ако собственикът на второстепенен CA (УО) е различен от собственика на базовия CA (УО), преди да подаде заявка за удостоверение на второстепенен CA (УО), субектът, притежаващ второстепенния CA (УО) подписва договор за услугите на базовия CA (УО).
4.1.2.4.Станции на СИТС
111)Първоначалната регистрация на звена на крайни субекти (станции на СИТС) се извършва в ЕА (ОВ) от отговорния абонат (производител/оператор) (поток 33 и поток 35) след удостоверяване на идентичността на организацията абонат и на самоличността на нейния представител съгласно раздели 3.2.2.4 и 3.2.5.2.
112)Една станция на СИТС може да генерира двойка ключове за EC (ПВ) (вж. раздел 6.1) и да създаде подписана заявка за EC (ПВ) в съответствие с [1]. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1].
113)При регистрацията на редова станция на СИТС (а не специална мобилна или фиксирана станция), ЕА (ОВ) трябва да се увери, че разрешенията, посочени в първоначалната заявка, не са за правителствени цели. Разрешения за правителствени цели се дават от съответните държави членки. Процедурата за регистрация и отговорите, изпращани от ЕА (ОВ) на производителя/оператора (поток 33 и поток 35) се описват подробно в CPS (ДПУ) на ЕА (ОВ).
114)Станция на СИТС се вписва в ЕА (ОВ) (раздел 3.2.5.3) след изпращане на първоначална заявка за EC (ПВ) в съответствие с [1].
115)След първоначалната регистрация, извършена от представител на абоната, чиято самоличност е удостоверена, ЕА (ОВ) одобрява AT (ТУ), които звеното на крайния субект (т.е. станцията на СИТС) може да получи. Освен това за всеки краен субект се определя ниво на надеждност в съответствие с удостоверението на крайния субект и категоризирането му в един от профилите за защита, изброени в раздел 6.1.5.2.
116)Обикновените превозни средства притежават само една станция на СИТС, регистрирана в един ЕА (ОВ). Превозни средства със специално предназначение (напр. полицейски автомобили и други превозни средства със специално предназначение, които се ползват с конкретни права) могат да бъдат регистрирани и в друг ЕА (ОВ) или да притежават една допълнителна станция на СИТС за разрешения в обхвата на тяхното специално предназначение. Превозните средства, за които се прилага такова изключение, се определят от отговорните държави членки. Разрешения за специални мобилни и фиксирани станции на СИТС се предоставят само от отговорните държави членки. Процедурата за издаване на удостоверения за такива превозни средства се определя в CPS (ДПУ) на базовите CA (УО) или на второстепенните CA (УО), които издават такива удостоверения в съответната държава членка.
117)Когато абонатът прехвърля дадена станция на СИТС от една ЕА (ОВ) към друга, докато трае процедурата по миграция станцията на СИТС може да бъде регистрирана в два (сходни) ЕА (ОВ).
118)Станция на СИТС генерира двойка ключове за AT (ТР) (вж. раздел 6.1) и създава заявка за AT (ТР) в съответствие с [1]. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1].
119)Станции на СИТС подават заявка за разрешение до унифицирания указател на ресурс (URL) на AA (РО) (поток 32 и поток 26), като изпращат поне информацията, която се изисква съгласно раздел 3.2.3.3). AA (РО) и ЕА (ОВ) валидират разрешението за всяка заявка в съответствие с раздели 3.2.6 и 4.2.2.5.
4.2.Обработване на заявленията за издаване на удостоверение
4.2.1.Изпълнение на функции по отношение на идентификация и удостоверяване на идентичността
4.2.1.1.Идентификация и удостоверяване на идентичността на базови CA (УО)
120)Упълномощеният представител на CPA (ОПУ) отговаря за удостоверяване на идентичността на упълномощения представител на базовия CA (УО) и за одобряване на прилаганата от него процедура за вписване съгласно раздел 3.
4.2.1.2.Идентификация и удостоверяване на идентичността на TLM (АДС)
121)Упълномощеният представител на CPA (ОПУ) отговаря за удостоверяване на идентичността на упълномощения представител на TLM (АДС) и за одобряване на прилагания от него формуляр за заявление за вписване съгласно раздел 3.
4.2.1.3.Идентификация и удостоверяване на идентичността на EA (ОВ) и AA (РО)
122)Съответният базов CA (УО) отговаря за удостоверяване на идентичността на упълномощения представител на ЕА (ОВ)/AA (РО) и за одобряване на прилагания от него формуляр за заявление за вписване съгласно раздел 3.
123)Базовият CA (УО) потвърждава на ЕА (ОВ)/AA (РО), че заявлението е валидирано успешно. След това ЕА (ОВ)/AA (РО) може да изпрати заявка за удостоверение на базовия CA (УО) (поток 21/24), който издава удостоверения на съответния ЕА (ОВ)/AA (РО) (поток 18/19).
4.2.1.4.Идентификация и удостоверяване на идентичността на абонати на EE (КС)
124)Дадена станция на СИТС може да подаде заявка за удостоверение за EC (ПВ) едва когато абонатът на EE (КС) изпрати информация за идентификатора на съответната станция на СИТС по защитен начин до ЕА (ОВ) (поток 33). ЕА (ОВ) проверява заявката и при положителен резултат от проверката регистрира информацията за станцията на СИТС в своята база данни и потвърждава това на абоната на EE (КС) (поток 35). Тази операция се извършва само веднъж за всяка станция на СИТС от нейния производител или оператор. След като бъде регистрирана от ЕА (ОВ), станцията на СИТС може да изпраща по една заявка за удостоверение за EC (ПВ) всеки път, когато има нужда (поток 31). ЕА (ОВ) удостоверява идентичността и проверява дали информацията, вписана в заявката за удостоверение за EC (ПВ), е валидна за станция на СИТС.
4.2.1.5.Талони за разрешение
125)В съответствие с [1] при подаване на заявки за разрешение (поток 32) AA (РО) трябва да удостовери идентичността на ЕА (ОВ), от който станцията на СИТС е получила своите EC (ПВ). Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1]. Ако AA (РО) не е в състояние да удостовери идентичността на ЕА (ОВ), заявката се отхвърля (поток 26). AA (РО) задължително трябва да притежава удостоверение на ЕА (ОВ), за да удостовери идентичността на ЕА (ОВ) и да провери неговия отговор (поток 25 и поток 23, раздел 3.2.5.3).
126)ЕА (ОВ) удостоверява идентичността на станцията на СИТС, която е подала заявка за AT (ТР), като проверява нейните EC (ПВ) (поток 25 и поток 23).
4.2.2.Одобряване или отхвърляне на заявления за издаване на удостоверение
4.2.2.1.Одобряване или отхвърляне на удостоверения на базови CA (УО)
127)TLM (АДС) въвежда/премахва удостоверения на базовия CA (УО) в/от ECTL (ДСЕУ) след одобрение от страна на CPA (ОПУ) (поток 1/2).
128)След получаване на одобрение от CPA (ОПУ) TLM (АДС) следва да провери подписа, информацията и кодирането на удостоверенията на базовия CA (УО) (поток 1). Ако резултатът от проверката е положителен и след одобрение от CPA (ОПУ), TLM (АДС) вписва съответното базово удостоверение в ECTL (ДСЕУ) и уведомява CPA (ОПУ) (поток 5).
4.2.2.2.Одобряване или отхвърляне на удостоверения на TLM (АДС)
129)За одобряването или отхвърлянето на удостоверения на TLM (АДС) отговаря CPA (ОПУ).
4.2.2.3.Одобряване или отхвърляне на удостоверения на EA (ОВ) и AA (РО)
130)Базовият CA (УО) проверява заявките за удостоверение на второстепенни CA (УО) (поток 21/24) и съответните доклади (издадени от независимия одитор на PKI/ИПК) при получаването им от съответния второстепенен CA (УО) (поток 36, раздел 8). Ако резултатът от проверката е положителен, базовият CA (УО) издава удостоверение на подалия заявката ЕА (ОВ)/AA (РО) (поток 18/19); в противен случая заявката се отхвърля и на ЕА (ОВ)/AA (РО) не се издава удостоверение.
4.2.2.4.Одобряване или отхвърляне на EC (ПВ)
131)ЕА (ОВ) проверява и валидира заявките за EC (ПВ) в съответствие с раздели 3.2.3.2 и 3.2.5.3.
132)Ако заявката за удостоверение в съответствие с [1] е правилна и валидна, ЕА (ОВ) генерира исканото удостоверение.
133)Ако заявката за удостоверение е невалидна, ЕА (ОВ) я отхвърля и изпраща отговор, в който посочва мотивите за отказа в съответствие с [1]. Ако дадена станция на СИТС все още иска да получи EC (ПВ), тя подава нова заявката за удостоверение. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1].
4.2.2.5.Одобряване или отхвърляне на AT (ТР)
134)Заявката за удостоверение се проверява от ЕА (ОВ). AA (РО) установява връзка с ЕА (ОВ), за да валидира заявката (поток 25). ЕА (ОВ) удостоверява идентичността на станцията на СИТС, подала заявката, и проверява дали тя има право да получи исканите AT (ТР), като следва CP (ППУ) (напр. проверява дали удостоверението не е отменено и потвърждава неговата валидност по отношение на период/регион, предвидените в него разрешения, нивото на надеждност и т.н.). ЕА (ОВ) изпраща отговор за резултата от проверката (поток 23) и ако той е положителен, AA (РО) генерира исканото удостоверение и го предава към станцията на СИТС. Ако заявката за AT (ТР) не е правилна или отговорът на ЕА (ОВ) относно проверката е отрицателен, AA (РО) отхвърля заявката. Ако дадена станция на СИТС все още иска да получи AT (ТР), тя подава нова заявката за разрешение.
4.2.3.Срок за обработване на заявленията за издаване на удостоверение
4.2.3.1.Заявление за издаване на удостоверение на базов CA (УО)
135)Времето за изпълнение на процедурата за идентифициране и удостоверяване на идентичността на заявление за издаване на удостоверение е в рамките на работния ден и е ограничено до максимален срок, определен в CPS (ДПУ) на базовия CA (УО).
4.2.3.2.Заявление за издаване на удостоверение на TLM (АДС)
136)Заявление за издаване на удостоверение на TLM (АДС) се обработва в максимален срок, определен в CPS (ДПУ) на TLM (АДС).
4.2.3.3.Заявления за издаване на удостоверение на EA (ОВ) и AA (РО)
137)Времето за изпълнение на процедурата за идентифициране и удостоверяване на идентичността на заявление за издаване на удостоверение е в рамките на работния ден в съответствие с постигнатото съгласие и договореностите базовия CA (УО) на държавата членка/частната организация и второстепенния CA (УО). Заявления за издаване на удостоверение на второстепенен CA (УО) се обработват в максимален срок, определен в CPS (ДПУ) на второстепенния CA (УО).
4.2.3.4.Заявление за EC (ПВ)
138)Заявления за EC (ПВ) се обработват в максимален срок, определен в CPS (ДПУ) на ЕА (ОВ).
4.2.3.5.Заявление за AT (ТР)
139)Заявления за AT (ТР) се обработват в максимален срок, определен в CPS (ДПУ) на AA (РО).
4.3.Издаване на удостоверения
4.3.1.Действия на CA (УО) при издаване на удостоверения
4.3.1.1.Издаване на удостоверение на базов CA (УО)
140)Базовите CA (УО) издават подписани от тях удостоверения на базов CA (УО), свързани удостоверения, удостоверения на второстепенен CA (УО) и CRL (САУ).
141)След одобрение от CPA (ОПУ) (поток 4) базовият CA (УО) изпраща своето удостоверение на TLM (АДС) чрез CPOC (ЗКС), за да бъде добавено в ECTL (ДСЕУ) (поток 11 и поток 8) (вж. раздел 4.1.2.1). TLM (АДС) проверява дали CPA (ОПУ) е проверил удостоверението (поток 1).
4.3.1.2.Издаване на удостоверение на TLM (АДС)
142)TLM (АДС) издава подписано от него удостоверение на TLM (АДС) и свързано удостоверение и го изпраща на CPOC (ЗКС) (поток 6).
4.3.1.3.Издаване на удостоверения на EA (ОВ) и AA (РО)
143)Второстепенните CA (УО) генерират подписана заявка за удостоверение и я изпращат на съответния базов CA (УО) (поток 21 и поток 24). Базовият CA (УО) проверява заявката и издава удостоверение на подалия я второстепенен CA (УО) в съответствие с [5] възможно най-бързо, както е предвидено в CPS (ДПУ) по отношение на обичайните оперативни практики, но не по-късно от пет работни дни от получаване на заявката.
144)Базовият CA (УО) актуализира хранилището, в което се съхраняват удостоверенията на второстепенните CA (УО).
4.3.1.4.Издаване на EC (ПВ)
145)Станцията на СИТС изпраща заявка за EC (ПВ) на ЕА (ОВ) в съответствие с [1]. ЕА (ОВ) удостоверява идентичността и проверява дали информацията, вписана в заявката за удостоверение, е валидна за станция на СИТС. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1].
146)Ако резултатът от проверката е положителен, ЕА (ОВ) издава удостоверение според регистрацията на станцията на СИТС (вж. 4.2.1.4) и ѝ го изпраща със съобщение за отговор относно EC (ПВ) в съответствие с [1]. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1].
147)При липса на регистрация ЕА (ОВ) генерира код за грешка и го изпраща на станцията на СИТС със съобщение за отговор относно EC (ПВ) в съответствие с [1]. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1].
148)Заявките за EC (ПВ) и отговорите на тях се криптират, за да се гарантира поверителност, и се подписват за удостоверяване на тяхната идентичност и цялост.
4.3.1.5.Издаване на AT (ТР)
149)Станцията на СИТС изпраща на AA (РО) съобщение със заявка за AT (ТР) в съответствие с [1]. AA (РО) изпраща на ЕА (ОВ) заявка за валидиране на AT (ТР) в съответствие с [1]. ЕА (ОВ) изпраща на AA (РО) отговор относно валидирането на AT (ТР). Ако отговорът е положителен, AA (РО) генерира AT (ТР) и го изпраща на станцията на СИТС със съобщение за отговор относно AT (ТР) в съответствие с [1]. Ако отговорът е отрицателен, AA (РО) генерира код за грешка и го изпраща на станцията на СИТС със съобщение за отговор относно AT (ТР) в съответствие с [1]. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1].
150)Заявките за AT (ТР) и отговорите на тях се криптират (само за мобилни станции на СИТС), за да се гарантира поверителност, и се подписват за удостоверяване на тяхната идентичност и цялост.
4.3.2.Уведомяване на абоната за издаването на удостоверението от страна на CA (УО)
Не е приложимо.
4.4.Приемане на удостоверения
4.4.1.Процедура за приемане на удостоверения
4.4.1.1.Базов CA (УО)
Не е приложимо.
4.4.1.2.TLM (АДС)
Не е приложимо.
4.4.1.3.EA (ОВ) и AA (РО)
151)ЕА (ОВ)/AA (РО) проверява типа на полученото удостоверение, подписа и вписаната в него информация. ЕА (ОВ)/AA (РО) отхвърля всички удостоверения на ЕА (ОВ)/AA (РО), чиято проверка не е дала положителен резултат, и издава нова заявка.
4.4.1.4.Станции на СИТС
152)Станцията на СИТС сверява отговора за EC (ПВ)/AT (ТР), получен от ЕА (ОВ)/AA (РО) с оригиналната заявка, включително подписа и удостоверителната верига. Всички отговори на EC (ПВ)/AT (ТР), чиято проверка не е дала положителен резултат, се отхвърлят. В такива случаи станцията на СИТС трябва да изпрати нова заявка за EC (ПВ)/AT (ТР).
4.4.2.Публикуване на удостоверението
153)Удостоверенията на TLM (АДС) и свързаните с тях удостоверения са достъпни за всички участници чрез CPOC (ЗКС).
154)Удостоверенията на базови CA (УО) се публикуват от CPOC (ЗКС) чрез ECTL (ДСЕУ), който се подписва от TLM (АДС).
155)Удостоверенията на второстепенни CA (УО) (ЕА/ОВ) и AA/РО) се публикуват от базовия CA (УО).
156)EC (ПВ) и AT (ТР) не се публикуват.
4.4.3.Уведомление за издаване на удостоверение
Не се предвиждат уведомления за издаване.
4.5.Ползване на двойки ключове и удостоверения
4.5.1.Ползване на частни ключове и удостоверения
4.5.1.1.Ползване на частни ключове и удостоверения от TLM (АДС)
157)TLM (АДС) ползват частния си ключ за подписване на своите удостоверения (на TLM (АДС) и свързани) и ECTL (ДСЕУ).
158)Участниците в PKI (ИПК) ползват удостоверенията на TLM (АДС) за проверка на ECTL (ДСЕУ) и за удостоверяване на идентичността TLM (АДС).
4.5.1.2.Ползване на частни ключове и удостоверения от базови CA (УО)
159)Базовите CA (УО) ползват частния си ключ за подписване на своите удостоверения, на CRL (САУ), на свързаните удостоверения и на удостоверенията на ЕА (ОВ)/AA (РО).
160)Участниците в PKI (ИПК) ползват удостоверенията на базовите CA (УО) за проверка на удостоверенията на подчинените им AA (РО) и ЕА (ОВ), на свързаните удостоверения и на CRL (САУ).
4.5.1.3.Ползване на частни ключове и удостоверения от EA (ОВ) и AA (РО)
161)ЕА (ОВ) ползват частния си ключ за подписване на EC (ПВ) и за декриптиране на заявки за вписване.
162)Удостоверенията на ЕА (ОВ) се ползват за проверка на подписа на свързаните с тях EC (ПВ) и за криптиране на заявки за EC (ПВ) и AT (ТР), подадени от EE (КС), както е описано в [1].
163)AA (РО) ползват частния си ключ за подписване на AT (ТР) и за декриптиране на заявки за AT (ТР).
164)Удостоверенията на AA (РО) се ползват от EE (КС) за проверка на свързаните с тях AT (ТР) и за криптиране на заявки за AT (ТР), както е описано в [1].
4.5.1.4.Ползване на частни ключове и удостоверения от крайни субекти
165)EE (КС) ползват частния ключ, съответстващ на валидни EC (ПВ), за подписване на нова заявка за вписване, както е определено в [1]. Новият частен ключ се ползва за създаване на вътрешен подпис върху заявката, с който се доказва притежаването на частен ключ, съответстващ на новия публичен ключ за EC (ПВ).
166)EE (КС) ползват частния ключ, съответстващ на валидни EC (ПВ), за подписване на заявка за разрешение, както е определено в [1]. Частният ключ следва да се ползва за създаване на вътрешен подпис върху заявката, с който се доказва притежаването на частен ключ, съответстващ на новия публичен ключ за AT (ТР).
167)EE (КС) ползват частния ключ, съответстващ на подходящ AT (ТР) за подписване на съобщения до СИТС, както е определено в [5].
4.5.2.Ползване на частни ключове и удостоверения от доверяваща се страна
168)Доверяващите се страни ползват удостоверителната йерархия и свързаните с нея публични ключове за целите, упоменати в удостоверенията, и за удостоверяване на доверената обща идентичност на EC (ПВ) и AT (ТР).
169)Удостоверенията на базови CA (УО), ЕА (ОВ) и AA (РО), EC (ПВ) и AT (ТР) не се ползват без предварителна проверка от доверяваща се страна.
4.6.Подновяване на удостоверения
Не се допуска.
4.7.Повторно въвеждане на ключове за удостоверения
4.7.1.Предпоставки за повторно въвеждане на ключове за удостоверения
170)Повторно въвеждане на ключ за удостоверение се извършва, когато изтече срокът на валидност на дадено удостоверение или срокът на ползване на частен ключ, но все още съществуват отношения на доверие със CA (УО). Във всички случаи се генерира и издава нова двойка ключове и съответстващо на нея удостоверение.
4.7.2.Кой може да поиска повторно въвеждане на ключове
4.7.2.1.Базов CA (УО)
171)Базовият CA (УО) не иска повторно въвеждане на ключ. Процедурата за повторно въвеждане на ключ е вътрешна за базовия CA (УО), тъй като неговото удостоверение се подписва от самия него. Базовият CA (УО) въвежда повторно ключ за свързани или за новоиздадени удостоверения (вж. раздел 4.3.1.1).
4.7.2.2.TLM (АДС)
172)TLM (АДС) не иска повторно въвеждане на ключ. Процедурата за повторно въвеждане на ключ е вътрешна за TLM (АДС), тъй като неговото удостоверение се подписва от самия него.
4.7.2.3.EA (ОВ) и AA (РО)
173)Заявката за удостоверение на второстепенен CA (УО) трябва да бъде подадена своевременно, за да може на второстепенния CA (УО) да бъде издадено ново удостоверение и нова оперативна двойка ключове, преди изтичането на валидността на неговия настоящ частен ключ. Датата на подаване трябва да бъде съобразена и с времето, необходимо за получаване на одобрение.
4.7.2.4.Станции на СИТС
Не е приложимо.
4.7.3.Процедура за повторно въвеждане на ключове
4.7.3.1.Удостоверение на TLM (АДС)
174)TLM (АДС) взема решение за повторно въвеждане на ключ съгласно изискванията на раздели 6.1 и 7.2. Процедурата се описва подробно в неговата CPS (ДПУ).
175)TLM (АДС) изпълнява процедурата за повторно въвеждане на ключ своевременно, за да може новото удостоверение на TLM (АДС) и свързаното с него удостоверение да бъдат разпространени до всички участници, преди изтичането на валидността на настоящото удостоверение на TLM (АДС).
176)TLM (АДС) използва свързаните удостоверения за повторно въвеждане на ключове и за да осигури връзка на доверие за новото удостоверение, подписано от него. Генерираното ново удостоверение на TLM (АДС) и свързаното с него удостоверение се изпраща на CPOC (ЗКС).
4.7.3.2.Удостоверение на базов CA (УО)
177)Базовият CA (УО) взема решение за повторно въвеждане на ключ съгласно изискванията на раздели 6.1.5 и 7.2. Процедурата следва да бъде описана подробно в неговата CPS (ДПУ).
178)Базовият CA (УО) изпълнява процедурата за повторно въвеждане на ключ своевременно (преди да изтече валидността на неговото удостоверение), за да може новото удостоверение да бъде вписано в ECTL (ДСЕУ) преди влизането му в сила (вж. раздел 5.6.2). Процедурата за повторно въвеждане на ключ се изпълнява чрез свързани удостоверения или като първоначална заявка.
4.7.3.3.Удостоверения на EA (ОВ) и AA (РО)
179)ЕА (ОВ) или AA (РО) подава заявка за ново удостоверение, както следва:
Стъпка
|
Означение
|
Заявка за повторно въвеждане на ключ
|
1
|
Генериране на двойка ключове
|
Второстепенните CA (УО) (ЕА/ОВ и AA/РО) генерират нови двойки ключове в съответствие с раздел 6.1.
|
2
|
Генериране на заявка за удостоверение и вътрешен подпис
|
Второстепенният CA (УО) генерира заявка за удостоверение с новия публичен ключ, като взема предвид модела за именуване (subject_info), посочен в раздел 3, алгоритъма за подписа, специфичните за услугата разрешения (SSP) и един допълнителен параметър по избор, и генерира вътрешен подпис със съответния нов частен ключ. Ако е необходим ключ за криптиране, второстепенният CA (УО) трябва също да докаже, че притежава съответния частен ключ за декриптиране.
|
3
|
Генериране на външен подпис
|
Заявката се подписва с валидния към момента частен ключ, за да се гарантира нейната автентичност.
|
4
|
Изпращане на заявката до базов CA (УО)
|
Подписаната заявка се изпраща до съответния базов CA (УО).
|
5
|
Проверка на заявката
|
Съответният базов CA (УО) проверява целостта и автентичността на заявката. Най-напред се проверява външният подпис. Ако резултатът е удовлетворителен, се проверява вътрешният подпис. Когато са представени доказателства за притежаване на частен ключ за декриптиране, те също се проверяват.
|
6
|
Одобряване или отхвърляне на заявката
|
Ако резултатът от всички проверки е удовлетворителен, базовият CA (УО) одобрява заявката; в противен случай я отхвърля.
|
7
|
Генериране и издаване на удостоверението
|
Базовият CA (УО) генерира ново удостоверение и го изпраща до второстепенния CA (УО), подал заявката.
|
8
|
Изпращане на отговор
|
Второстепенният CA (УО) изпраща на базовия CA (УО) съобщение за статуса (т.е. дали удостоверението е получено, или не).
|
Таблица 3: Процедура за повторно въвеждане на ключове, приложима за ЕА (ОВ) и AA (РО)
180)При автоматично повторно въвеждане на ключове за второстепенни CA (УО), базовият CA (УО) проверява дали подалият заявката действително притежава частен ключ. Прилагат се подходящи протоколи за доказване на притежанието на частни ключове за декриптиране, например в съответствие с RFC 4210 и 4211. За частни ключове за подпис се ползва вътрешният подпис.
4.7.3.4.Удостоверения на станции на СИТС
Не е приложимо за AT (ТР).
4.8.Промяна на удостоверение
Не се допуска.
4.9.Отмяна и временно преустановяване на действието на удостоверение
Вж. раздел 7.
4.10.Услуги, отнасящи се до статуса на удостоверението
4.10.1.Оперативни характеристики
Не е приложимо.
4.10.2.Наличност на услугите
Не е приложимо.
4.10.3.Характеристики, подлежащи на избор
Не е приложимо.
4.11.Изтичане на абонамента
Не е приложимо.
4.12.Доверително съхранение и възстановяване на ключ
4.12.1.Абонат
4.12.1.1.Коя двойка ключове може да бъде дадена на доверително съхранение
Не е приложимо.
4.12.1.2.Кой може да подаде заявление за възстановяване
Не е приложимо.
4.12.1.3.Процедура за възстановяване и отговорности
Не е приложимо.
4.12.1.4.Идентифициране и удостоверяване на идентичността
Не е приложимо.
4.12.1.5.Одобряване или отхвърляне на заявления за възстановяване
Не е приложимо.
4.12.1.6.Действия на органа, отговорен за доверителното съхранение (KEA) и за възстановяването на ключове (KRA), при възстановяване на двойка ключове
Не е приложимо.
4.12.1.7.Наличност на орган, отговорен за доверителното съхранение (KEA) и за възстановяването на ключове (KRA)
Не е приложимо.
4.12.2.Политика и практика за капсулиране и възстановяване на сесийни ключове
Не е приложимо.
5.Структура, управление и оперативен контрол
181)PKI (ИПК) се състои от базовия CA (УО), ЕА (ОВ)/AA (РО), CPOC (ЗКС) и TLM (АДС), включително компонентите на техните системи за ИКТ (напр. мрежи и сървъри).
182)В този раздел субектът, отговорен за дадено звено от PKI (ИПК), се определя от самото звено. С други думи изречението „CA (УО) отговаря за извършване на одита“ означава „субектът или персоналът, управляващи CA (УО), отговарят за извършване на …“.
183)Понятието „звена в модела на доверие на СИТС“ включва базовия CA (УО), TLM (АДС), ЕА (ОВ)/AA (РО), CPOC (ЗКС) и защитената мрежа.
5.1.Физически контрол
184)Всички операции в модела на доверие на СИТС се извършват във физически защитена среда, която възпира, предотвратява и открива неразрешено използване, достъп или разкриване на чувствителна информация и системи. Звената в модела на доверие на СИТС използват средства за физически контрол на сигурността в съответствие с ISO 27001 и ISO 27005.
185)Субектите, които управляват звена в модела за доверие на СИТС, описват средствата за физически контрол на сигурността, както и средствата за контрол на сигурността по отношение на процедурите и персонала, в своите CPS (ДПУ). В частност, в CPS (ДПУ) се предоставя информация за местонахождението на обекта, за устройството на сградите и за наличните в тях средства за физически контрол на сигурността, които се ползват в базата на субекта, включен в модела на доверие на СИТС, за гарантиране на контролиран достъп до всички помещения.
5.1.1.Местонахождение и устройство
5.1.1.1.Базови CA (УО), CPOC (ЗКС), TLM (АДС)
186)Местонахождението и устройството на обекта, в който се помещава оборудването и се съхраняват данните на базовия CA (УО), CPOC (ЗКС) и TLM (АДС) (HSM/ХМС, данни за активиране, резервно копие на двойки ключове, компютри, регистри, скрипт за генериране на ключове, заявки за удостоверение и т.н.), съответстват на тези на обекти, в които се съхранява ценна и чувствителна информация. Базовият CA (УО) се помещава в специален корпус, отделен физически от помещенията на другите звена в PKI (ИПК).
187)Базовият CA (УО), CPOC (ЗКС) и TLM (АДС) прилагат политики и процедури, които осигуряват поддържането на високо ниво на сигурност във физическата среда, в която е инсталирано оборудването на СА (УО), така че да се гарантира, че:
·тя е изолирана от мрежи извън модела на доверие;
·тя е разделена на няколко (поне два) физически периметъра, всеки с по-високо ниво на сигурност от предишния;
·чувствителни данни (HSM/ХМС, резервни копия на двойки ключове, данни за активиране и т.н.) се съхраняват в специален сейф, разположен в отделна физическа зона с многостепенен контрол на достъпа.
188)Използваните техники за сигурност са проектирани така, че да устояват на множество форми на атака в различни комбинации. Използваните средства включват поне:
·аларми за контрол на периметъра, затворени системи за видеонаблюдение, бронирани стени и детектори за движение;
·двустепенна система за удостоверяване на самоличността (напр. смарт карта и ПИН) за всеки служител и служебна карта за влизане и излизане от обекта на базовия CA (УО) и от защитената физическа зона.
189)Базовият CA (УО), CPOC (ЗКС) и TLM (АДС) ползва упълномощен персонал за постоянно наблюдение на сградата, в която се помещава оборудването, 24 часа на ден, 7 дни в седмицата, 365 дни в годината. Работната среда (напр. физическите съоръжения) не остават никога без надзор. В защитените зони на базови CA (УО) или второстепенни CA (УО) не се допуска неупълномощен персонал.
5.1.1.2.EA (ОВ)/AA (РО)
190)Прилагат се разпоредбите на раздел 5.1.1.1.
5.1.2.Физически достъп
5.1.2.1.Базови CA (УО), CPOC (ЗКС), TLM (АДС)
191)Оборудването и данните (HSM/ХМС, данни за активиране, резервно копие на двойки ключове, компютри, регистри, скрипт за генериране на ключове, заявки за удостоверение и т.н.) са защитени от неразрешен достъп по всяко време. Физическите средства за сигурност на оборудването гарантират най-малко, че:
·за неразрешено проникване се следи ръчно или по електронен път по всяко време;
·до хардуера и данните за активиране не се допуска достъп на неупълномощени лица;
·всички преносими електронни и хартиени носители, съдържащи некриптирана чувствителна информация, се съхраняват на сигурно място;
·нито едно лице без постоянни пълномощия, влизащо в защитени зони, не се оставя без надзор от упълномощени служители на базовия CA (УО), CPOC (ЗКС) и TLM (АДС);
·достъпът се регистрира и регистърът се проверява периодично;
·достъпът се контролира поне на две нива на сигурност, напр. на ниво периметър, сграда и работно помещение;
·за достъп до криптографските данни на HSM (ХМС) и до данните за активиране се изисква физически контрол от две лица, изпълняващи доверени функции.
192)Ако съоръженията, в които се помещава оборудването, останат без надзор, задължително се извършва проверка за сигурност. При проверката следва да бъде потвърдено най-малко, че:
·оборудването е в състояние, което е подходящо за настоящия режим на работа;
·оборудването за всички компоненти, които не са включени в мрежата, е изключено;
·всички защитени средства за съхранение (пликове, защитени от подправяне, сейфове и т.н.) са надлежно обезопасени;
·физическите системи за сигурност (напр. брави на вратите, капаци на вентилационни шахти, електроснабдяване) функционират правилно;
·зоната е защитена срещу неразрешен достъп.
193)Преносимите криптографски модули се деактивират преди съхранение. Когато не се използват, тези модули и данните за достъп до тях или за активирането им, се съхраняват в сейф. Данните за активиране се запаметяват или записват и се съхраняват по начин, съответстващ на нивото на сигурност, осигурено за криптографския модул. Те не се съхраняват заедно с криптографския модул, за да се избегне достъпът до частния ключ само от едно лице.
194)Отговорността за тези проверки се възлага на лице или на група от лица, изпълняващи доверени функции. Когато отговорността е възложена на група от лица, се води регистър, който позволява да бъде установено кое лице е извършило всяка проверка. Ако в обекта няма служители денонощно, последният човек, който го напуска, подписва формуляр за излизане, в който се посочва датата и часът и се потвърждава, че всички необходими механизми за физическа защита са налице и са активирани.
5.1.2.2.EA (ОВ)/AA (РО)
195)Прилагат се разпоредбите на раздел 5.1.2.1.
5.1.3.Електрозахранване и климатизация
196)На защитените обекти на звена в модела на доверие на СИТС — базов CA (УО), CPOC (ЗКС), TLM (АДС), ЕА (ОВ) и AA (РО) — се осигурява надежден достъп до електричество, който гарантира тяхното функциониране без или с минимални прекъсвания в захранването. Предвиждат се основни и резервни инсталации в случай на срив във външното електрозахранване и за безпроблемно изключване на оборудването в модела на доверие на СИТС при липса на електрозахранване. Обектите в модела на доверие на СИТС следва да бъдат снабдени с отоплителни/вентилационни/климатични системи за поддържане на температурата и относителната влажност на оборудването в нормалните експлоатационни граници. Планът и процедурите за изпълнение на тези изисквания се описват подробно в CPS (ДПУ) на съответното звено в модела на доверие на СИТС.
5.1.4.Изложеност на вода
197)Защитените обекти на звена в модела на доверие на СИТС — базов CA (УО), CPOC (ЗКС), TLM (АДС), ЕА (ОВ) и AA (РО) — следва да бъдат обезопасени по начин, който свежда до минимум въздействието от евентуална изложеност на вода. По тази причина водоснабдителни и отвеждащи тръби за отпадни води следва да се избягват. Планът и процедурите за изпълнение на тези изисквания се описват подробно в CPS (ДПУ) на съответното звено в модела на доверие на СИТС.
5.1.5.Предотвратяване на пожар и защита срещу пожар
198)За да се предотврати излагане на пламък или дим, което може да има пагубни последици, защитените съоръжения на елементите в модела на доверие на СИТС — базов CA (УО), CPOC (ЗКС), TLM (АДС), ЕА (ОВ) и AA (РО) — следва да бъдат изградени и оборудвани по подходящ начин и да се прилагат процедури за пожарна безопасност. Носителите се съхраняват в подходящи контейнери, защитени срещу пожар.
199)Всички звена в модела на доверие на СИТС вземат мерки за защита на физическите носители, които съдържат резервни копия на критични системни данни или друга чувствителна информация, от опасности, произтичащи от околната среда, неразрешено използване, достъп или разкриване на данни, съхранявани на такива носители. Планът и процедурите за изпълнение на тези изисквания се описват подробно в CPS (ДПУ) на съответното звено в модела на доверие на СИТС.
5.1.6.Управление на носителите
200)С носителите, ползвани от звена в модела на доверие на СИТС — базов CA (УО), CPOC (ЗКС), TLM (АДС), ЕА (ОВ) и AA (РО) — се борави в защитена среда, така че да бъдат обезопасени срещу повреда, кражба и неразрешен достъп. Прилагат се процедури за управление, които гарантират, че носителите са защитени от амортизация и влошаване на състоянието през задължителния период на съхранение на записите.
201)Вземат се мерки за предотвратяване на достъпа до чувствителни данни в резултат на повторно използване на обекти за съхранение (напр. изтрити файлове), чрез които чувствителната информация може да стане достояние на неупълномощени потребители.
202)Поддържа се опис на всички информационни активи и се определят изисквания за тяхната защита в съответствие с анализа на риска. Планът и процедурите за изпълнение на тези изисквания се описват подробно в CPS (ДПУ) на съответното звено в модела на доверие на СИТС.
5.1.7.Унищожаване на отпадъци
203)Звената в модела на доверие на СИТС — базов CA (УО), CPOC (ЗКС), TLM (АДС), ЕА (ОВ) и AA (РО) — прилагат процедури за безопасно и необратимо унищожаване на отпадъци (хартия, носители или други отпадъци) с цел предотвратяване на неразрешено използване, достъп или разкриване съдържащата се в тях поверителна/лична информация. Всички носители, ползвани за съхранение на чувствителна информация като ключове, данни за активиране или файлове, се унищожават, преди да бъдат изхвърлени. Планът и процедурите за изпълнение на тези изисквания се описват подробно в CPS (ДПУ) на съответното звено в модела на доверие на СИТС.
5.1.8.Съхраняване на резервни данни в независима среда
5.1.8.1.Базов CA (УО), CPOC (ЗКС) и TLM (АДС)
204)Пълни резервни копия на данни на базови CA (УО), CPOC (ЗКС) и TLM (АДС), достатъчни за възстановяване на системата след повреда, се правят при започване на дейността на базови CA (УО), CPOC (ЗКС) и TLM (АДС) и след всяко генериране на нова двойка ключове и се съхраняват в независима среда (офлайн). Резервни копия на съществена оперативна информация (двойка ключове и CRL/САУ) и на ползвания софтуер се правят редовно. Предвиждат се подходящи съоръжения за съхраняване на резервни копия, които да гарантират, че съществената оперативна информация и ползваният софтуер могат да бъдат възстановени след бедствие или повреда на носителите. Мерките за съхранение на резервни копия на отделните системи се изпитват редовно, за да се гарантира, че отговарят на изискванията на плана за непрекъснатост на работата. Поне едно пълно резервно копие се съхранява извън обекта (за възстановяване в случай на бедствие). Резервното копие се съхранява на място с физически средства и процедури за контрол, съизмерими с тези на оперативната система на PKI (ИПК).
205)За резервните данни се прилагат същите изисквания за достъп като оперативните данни. Резервните данни се криптират и се съхраняват извън обекта. В случай на пълна загуба на данни информацията, необходима за подновяване на работата на базовия CA (УО), CPOC (ЗКС) и TLM (АДС), се възстановява напълно от резервните данни.
206)Резервни копия на данни, свързани с частния ключ на базов CA (УО), CPOC (ЗКС) и TLM (АДС), не се правят съгласно стандартните механизми за съхраняване на резервни копия, а с функцията за архивиране на криптографския модул.
5.1.8.2.EA (ОВ)/AA (РО)
207)Прилага се процедурата, описана в раздел 5.1.8.1.
5.2.Контрол на процедурите
В този раздел са описани изискванията за функциите, задълженията и идентификацията на персонала.
5.2.1.Доверителни функции
208)Служителите, подизпълнителите и консултантите, на които са възложени доверителни функции, се считат за „доверени лица“. Кандидатите за доверителни длъжности, които се изпълняват от доверени лица, следва да отговарят на изискванията за предварителна проверка, определени в настоящата политика за предоставяне на удостоверения.
209)Доверените лица имат достъп до или контролират удостоверяването на идентичността при изпълнение на криптографски операции, които могат съществено да повлияят на:
·валидирането на информацията, посочена в заявления за издаване на удостоверение;
·приемането, отхвърлянето или обработването на заявления за издаване на удостоверение, отмяната или обновяването на заявки;
·издаването или отхвърлянето на удостоверения, включително достъп до части от хранилището с ограничен достъп или обработване на информация или заявки на абонати.
210)Лицата, изпълняващи доверителни функции включват, но не се ограничават до:
·служители, отговарящи за обслужването на клиенти;
·системни администратори;
·определени разработчици;
·ръководители, натоварени с управлението на надеждността на инфраструктурата.
211)CA (УО) описва ясно всички доверителни функции в своята CPS (ДПУ).
5.2.2.Брой лица, необходими за всяка задача
212)Звената в модела на доверие на СИТС създават, поддържат и прилагат стриктни процедури за контрол, за да осигурят разделение на задълженията, свързани с доверителни функции, и да гарантират, че чувствителни задачи се изпълняват от няколко доверени лица. Звената в модела на доверие на СИТС — TLM (АДС), CPOC (ЗКС), базови CA (УО), ЕА (ОВ) и AA (РО) — трябва да спазват изискванията на [4] и на следните параграфи.
213)Трябва да са налице политики и процедури за контрол, осигуряващи разделение на задълженията, свързани със служебни отговорности. За най-чувствителните задачи, като например достъп до и управление на криптографския хардуер на CA (УО) (HSM/ХМС) и данните, отнасящи се до ключове, трябва да се изисква разрешение от няколко доверени лица.
214)Процедурите за вътрешен контрол трябва да гарантират, че за физически или логически достъп до устройството се изисква разрешение най-малко от две доверени лица. Ограниченията за достъп до криптографския хардуер на CA (УО) трябва да се прилагат стриктно от няколко доверени лица през целия жизнен цикъл на модула — от проверката му при получаване до окончателното му логическо и/или физическо унищожаване. След активиране на модула с оперативни ключове трябва да бъдат задействани механизми за контрол на достъпа, които да осигуряват отделен контрол на физическия и логическия достъп до устройството.
5.2.3.Идентифициране и удостоверяване на идентичността при изпълнение на всяка функция
215)Всички лица, на които са възложени функции, описани в настоящата CP (ППУ), се идентифицират и тяхната идентичност се удостоверява, за да се гарантира, че заеманата от тях длъжност им позволява да изпълняват задълженията си в PKI (ИПК).
216)Звената в модела на доверие на СИТС проверяват и потвърждават самоличността и пълномощията на всички служители, които се явяват доверени лица, преди:
·да им бъдат издадени устройства за достъп и да им бъде даден достъп до съответните съоръжения;
·да им бъдат дадени електронни пълномощия за достъп и изпълнение на конкретни дейности в системи на CA (УО).
217)Механизмите за идентифициране и удостоверяване на идентичността на физически лица се описват в CPS (ДПУ).
5.2.4.Функции, за които се изисква разделение на задълженията
218)Функциите, за които се изисква разделение на задълженията, включват (но не се ограничават до):
·приемане, отхвърляне и отмяна на заявки или обработване на заявления за издаване на удостоверение на CA (УО);
·генериране, издаване и унищожаване на удостоверение на CA (УО).
219)Разделението на задълженията може да се осъществява чрез оборудване и/или процедури в PKI (ИПК). Никое лице не може да получи повече от една идентичност освен с одобрението на базовия CA (УО).
220)Звената на базовия и на второстепенните CA (УО), които управляват генерирането и отмяната на удостоверения, са независими от други структури при вземане на решения относно въвеждането, осигуряването, поддържането и прекратяването на услуги в съответствие с приложимите политики за предоставяне на удостоверения. По-специално на техните ръководители, старши служители и служители, изпълняващи доверителни функции, не се оказва какъвто и да било търговски, финансов и друг натиск, който би могъл да повлияе неблагоприятно на доверието в предоставяните от звеното услуги.
221)ЕА (ОВ) и AA (РО), които обслужват мобилни станции на СИТС, са отделни оперативни единици с отделна информационна инфраструктура и управленски екип. Съгласно GDPR (ОРЗД) ЕА (ОВ) и AA (РО) не обменят никакви лични данни с изключение на тези, свързани с одобряването на заявки за AT (ТР). Те прехвърлят данни, свързани с одобряването на заявки за AT (ТР), единствено прилагайки протокола за валидиране на разрешението, описан в [1], като ползват специален защитен интерфейс. Могат да бъдат ползвани и други протоколи, стига да се изпълнят изискванията на [1].
222)Регистрите, които се съхраняват от ЕА (ОВ) и AA (РО), могат да бъдат използвани единствено за отмяна на неправомерно прилагани EC (ПВ), установени въз основа на AT (ТР) в засечени злонамерени съобщения CAM и DENM. Когато дадено съобщение CAM/DENM бъде определено като злонамерено, AA (РО) открива ключа за проверка на AT (ТР) в своите регистри по издаването му и изпраща на ЕА (ОВ) заявка за отмяна, в която се съдържа криптираният подпис, съответстващ на частния ключ на EC (ПВ), ползван при издаването на AT (ТР). Всички регистри трябва да бъдат адекватно защитени срещу достъп от неупълномощени лица и не могат да бъдат споделяни с други субекти или органи.
Забележка: Към момента на разработване на настоящата версия на CP (ППУ) структурата на функцията за неправомерност все още не е определена. Планира се тя евентуално да бъде развита в бъдещи преработени версии на политиката.
5.3.Контрол на персонала
5.3.1.Изисквания за квалификация, опит и ниво на достъп
223)Звената в модела на доверие на СИТС назначават достатъчен брой служители с експертни знания, опит и квалификация, необходими за съответните функции и предлагани услуги. Персоналът на PKI (ИПК) отговаря на тези изисквания чрез официално обучение и удостоверения, действителен опит или комбинация от двете. Доверителните функции и отговорности, описани в CPS (ДПУ), се посочват ясно и се документират в длъжностните характеристики. Служителите на подизпълнители на PKI (ИПК) имат ясно определени длъжностни характеристики, които гарантират разделение на задълженията и правомощията, а чувствителността на всяка длъжност се определя въз основа на задълженията и нивата на достъп, предварителната проверка, обучението и степента на осведоменост на служителите.
5.3.2.Процедури за проверка на личното досие
224)Звената в модела на доверие на СИТС извършват проверка на личното досие на всички служители, които се явяват доверени лица. Личното досие на служителите, които изпълняват доверителни функции, се подлага на последваща проверка поне на всеки пет години.
225)Обстоятелствата, установени при проверка на личното досие, които могат да дадат основание за отхвърляне на кандидати за доверени позиции или за предприемане на действия срещу съществуващи доверени лица, включват (но не се ограничават до) следното:
·представяне на информация с невярно съдържание от страна на кандидата или довереното лице;
·крайно неблагоприятни или ненадеждни сведения за професионалните качества;
·постановени присъди за някои видове престъпления;
·индикации за липса на финансова отговорност.
226)Сигналите, съдържащи такава информация, се оценяват от служителите на отдел „Човешки ресурси“, които предприемат разумни действия с оглед на вида, степента и честотата на поведението, установено при проверката на личното досие. Такива действия могат да включват мерки като оттегляне на предложения за работа, направени на кандидати за доверени позиции, или прекратяване на трудовите правоотношения със съществуващи доверени лица. Информация, установена при проверка на личното досие, може да се използва като основание за предприемане на такива действия при спазване на приложимото законодателство.
227)Проучването на кандидати за доверени лица включва, но не се ограничава до:
·потвърждение на предишния опит и заемани длъжности;
·проверка на препоръки от предишни работодатели поне за последните пет години;
·потвърждение на най-високата или най-подходящата образователна степен, придобита от кандидата;
·проверка в регистрите за съдимост.
5.3.3.Изисквания, свързани с обучението
228)Звената в модела на доверие на СИТС осигуряват на своите служители необходимото обучение, за да могат да изпълняват компетентно и удовлетворително своите задължения, свързани с дейността на CA (УО).
229)Програмите за обучение се преразглеждат периодично и са насочени към въпроси, които са от значение за функциите, изпълнявани от служителите.
230)Програмите за обучение са насочени към въпроси, които са от значение за конкретната среда, в която работи обучаемия, включително:
·принципи и механизми за сигурност в звената в модела на доверие на СИТС;
·ползвани хардуерни и софтуерни версии;
·всички задължения, които се очаква да изпълнява лицето, както и вътрешни и външни процедури и последователност на докладване;
·оперативни процедури и работни процеси в PKI (ИПК);
·докладване и действия в случай на инцидент и компрометиране;
·процедури за възстановяване и продължаване на работата в случай на бедствие;
·достатъчни познания в областта на ИТ.
5.3.4.Последващо обучение: честота и изисквания
231)От лицата, на които се възлагат доверителни функции, се изисква да обновяват знанията, които са придобили от обучението постоянно, като участват в програми за последващо обучение. Обучението трябва да се повтаря всеки път, когато е необходимо, и най-малко на всеки две години.
232)Звената в модела на доверие на СИТС предоставят на своите служители опреснително и последващо обучение колкото и когато е необходимо, за да се гарантира, че те поддържат необходимото равнище на знания и умения, за да изпълняват компетентно и удовлетворително служебните си задължения.
233)Лицата, които изпълняват доверителни функции, следва да са наясно с промените в операциите в PKI (ИПК), както е уместно. Всяка значителна промяна в операциите се придружава от план за обучение (осведомяване) и изпълнението на този план се документира.
5.3.5.Честота и последователност на ротацията на длъжности
234)Не се предвиждат конкретни изисквания, стига да са осигурени необходимите технически умения, опит и права на достъп. Администраторите на звена в модела на доверие на СИТС гарантират, че промените в персонала не засягат сигурността на системата.
5.3.6.Санкции за неразрешени действия
235)Всяко звено в модела на доверие на СИТС трябва да разработи конкретни дисциплинарни процедури, които да гарантират, че непозволените действия се санкционират, както е уместно. При сериозни нарушения възложените функции и съответните права трябва да се отнемат.
5.3.7.Изисквания към независими подизпълнители
236)Звената в модела на доверие на СИТС могат да позволят на независими подизпълнители или консултанти да станат доверени лица само ако това е необходимо в рамките на ясно определени отношения на възлагане и при условие, че подизпълнителите или консултантите се ползват със същото доверие, с което и служителите на субекта, и отговарят на изискванията, приложими към служителите.
237)В противен случай независимите изпълнители и консултанти имат достъп до защитените съоръжения на PKI (ИПК) на СИТС само ако са придружавани и се наблюдават пряко от доверени лица.
5.3.8.Документация, предоставяна на персонала
238)Звената в модела на доверие на СИТС осигуряват на своите служители необходимото обучение и достъп до документация, от която имат нужда, за да изпълняват компетентно и удовлетворително своите служебни задължения.
5.4.Процедури за водене на контролен регистър
239)В този раздел са определени изискванията по отношение на видовете събития, които трябва да се записват, и управлението на контролния регистър.
5.4.1.Видове събития, подлежащи на регистриране и докладване от всеки CA (УО)
240)Представителят на CA (УО) редовно преглежда регистрите, събитията и процедурите на CA (УО).
241)Звената в модела на доверие на СИТС записват следните видове събития за целите на контрола (ако е приложимо):
·физически достъп до съоръженията — достъпът на физически лица до съоръженията се записва чрез съхраняване на заявките за достъп, подадени със смарткарти. За всеки запис се създава събитие;
·управление на доверителни функции — всяка промяна в определението и в нивото на достъп до различните функции се записва, включително промените в характеристиките на функциите. За всеки запис се създава събитие;
·логически достъп — създава се събитие, когато даден субект (напр. програма) получава достъп до чувствителни елементи (т.е. мрежи и сървъри);
·управление на архивирането — създава се събитие при всяко завършване на архивирането, успешно или неуспешно;
·управление на регистри — регистрите се съхраняват. Създава се събитие, когато регистърът надхвърли определен обем;
·данни от процедурата за удостоверяване на идентичността на абонати и звена в модела на доверие на СИТС — създава се събитие за всяка заявка за удостоверяване на идентичността, подадена от абонат или звено в модела на доверие на СИТС;
·приемане и отхвърляне на заявки за удостоверение, включително създаване и подновяване на удостоверения — създават се събития със списък на приетите и отхвърлени заявки за удостоверения през предходните седем дни;
·регистрация на производител — създава се събитие при всяка регистрация на производител;
·регистрация на станция на СИТС — създава се събитие при всяка регистрация на станция на СИТС;
·управление на HSM (ХМС) — създава се събитие, когато бъде регистриран пробив в сигурността на HSM (ХМС);
·управление на ИТ и мрежи, които имат отношение към системите на PKI (ИПК) — създава се събитие, когато сървър на PKI (ИПК) бъде изключен или рестартиран;
·управление на сигурността (успешни и неуспешни опити за достъп до система на PKI (ИПК), извършени действия от PKI (ИПК) и системата за сигурност, промени в профила за сигурност, сривове в системата, откази на хардуера и други аномалии, активност на защитната стена и рутера; и влизане във и излизане от обекти в PKI (ИПК);
·данните, свързани с събития, се съхраняват най-малко пет години, освен ако важат допълнителни национални правила.
242)Съгласно GDPR (ОРЗД) контролните регистри не позволяват достъп до поверителни данни за частните превозни средства на станция на СИТС.
243)Когато е възможно, контролните регистри на сигурността се водят автоматично. Когато това е невъзможно, се ползва регистрационен дневник, формуляр на хартия или друг физически носител. Всички контролни регистри на сигурността, електронни и неелектронни, се съхраняват и се предоставят по време на одити за съответствие.
244)Всяко събитие, свързано с жизнения цикъл на удостоверение, се регистрира по такъв начин, че да може да бъде отнесено до лицето, което го е извършило. Всички данни, свързани със самоличността, се криптират и защитават срещу неразрешен достъп.
245)Всеки контролен запис включва поне следната информация (регистрирана автоматично или ръчно за всяко събитие, подлежащо на контрол):
·тип на събитието (съгласно горния списък);
·надеждна дата и час на настъпване на събитието;
·резултат от събитието — успешно или неуспешно, където е уместно;
·идентичност на субекта и/или на оператора, предизвикал събитието, ако е приложимо;
·идентичност на субекта, към който е насочено събитието.
5.4.2.Честота на обработване на регистъра
246)Контролните регистри се преглеждат в отговор на сигнали за нередности и инциденти в системите на CA (УО) и периодично всяка година.
247)Обработката на контролните регистри се състои от преглед на тяхното съдържание и документиране на причината за всички значими събития в обобщен контролен регистър. Прегледът на контролните регистри включва проверка на достоверността/неприкосновеността на регистъра, проверка на всички записи в него и обследване на всички регистрирани сигнали или нередности. Предприетите действия въз основа на прегледа на контролни регистри се документират.
248)Контролните регистри се архивират поне веднъж седмично. Ако очакваният обем данни, вписани в контролния регистър през дадена седмица, е по-голям от свободното дисково пространство за съхраняване на контролни регистри, администраторът архивира регистрите ръчно.
5.4.3.Период на съхранение на контролния регистър
249)Записите в регистрите, отнасящи се до жизнения цикъл на удостоверения, се съхраняват поне пет години след изтичане на валидността на съответното удостоверение.
5.4.4.Защита на контролния регистър
250)Целостта и поверителността на контролния регистър се осигурява чрез механизъм за контрол на достъпа, съответстващ на функциите. Достъп до вътрешните контролни регистри могат да имат само администраторите; достъп до контролни регистри, отнасящи се до жизнения цикъл на удостоверения, могат да имат и потребители, притежаващи съответното разрешение, чрез интернет страница с потребителски код за достъп. Достъп трябва да се предоставя след въвеждане на код за достъп поне на двама потребители с поне двустепенен процес на удостоверяване на идентичността. Достъпът на потребителите до техните собствени регистри трябва да бъде ограничен с технически средства.
251)Всички записи в регистрите се подписват с ключ от HSM (ХМС).
252)Регистрите за събития, съдържащи информация, която може да доведе до разкриване на самоличността на физическо лице, например частен автомобил, се криптират по такъв начин, че да могат да бъдат четени само за упълномощени лица.
253)Събитията се регистрират така, че да не могат лесно да бъдат изтрити или унищожени (освен при пренос върху носител за трайно съхранение) в рамките на периода на съхранение на регистрите.
254)Регистрите на събития са защитени по такъв начин, че да могат да бъдат четени през целия период на съхранение.
5.4.5.Процедури за архивиране на контролния регистър
255)Пълните и обобщените контролни регистри се архивират със специализирани механизми за архивиране под контрола на упълномощени служители с доверителни функции, независими от звеното, което е генерирало записите. Архивираните контролни регистри се ползват със същото ниво на защита с каквото и оригиналните регистри.
5.4.6.Система за събиране на контролни данни (вътрешна или външна)
256)Оборудването на звената в модела на доверие на СИТС активира контролните процеси при стартиране на системата и ги деактивира само при изключване на системата. Ако контролните процеси не се изпълняват, звеното в модела на доверие на СИТС преустановява работата си.
257)Общият статус на оборудването следва да се докладва на оперативния ръководител и на оперативния ръководен орган на съответното звено в PKI (ИПК) в края на всеки период на действие и при повторно въвеждане на ключове за удостоверения.
5.4.7.Уведомяване на субекта, станал причина за събитието
258)При регистриране на събитие системата за събиране на контролни данни гарантира, че събитието е съотнесено към служител с доверителни функции.
5.4.8.Оценка на уязвимостта
259)Служителите, отговарящи за осъществяване на контрола, и служителите, отговарящи за изпълнение на операциите в системата на PKI (ИПК), поясняват всички значими събития в обобщен контролен регистър. Прегледът включва проверка на достоверността/неприкосновеността на регистъра, проверка на последователността и целостта на контролните данни, кратка инспекция на всички записи в регистрите и по-задълбочено обследване на всички регистрирани сигнали или нередности. Предприетите действия въз основа на прегледа се документират.
260)Звената в модела на доверие на СИТС:
·въвеждат управлявани от тях организационни и/или технически средства за контрол, откриване и предотвратяване на вируси и зловреден софтуер в системите на PKI (ИПК);
·въвеждат и следват документирани процедури за преодоляване на уязвимостта, които обхващат установяване, анализ, преглед, предприемане на мерки и отстраняване на уязвимости;
·преминават през или извършват проверка на уязвимостта:
·след всяка промяна в системата или в мрежата, определена от звената в модела на доверие на СИТС като значима за компонентите в PKI (ИПК); и
·поне веднъж месечно на публичните и частните IP адреси, разпознати от CA (УО) и CPOC (ЗКС) като съответстващи на системи на PKI (ИПК);
·извършват изпитване за пробив на системите на PKI (ИПК) поне веднъж годишно и след актуализации или промени в инфраструктурата или в приложенията, определени от звената в модела на доверие на СИТС като значими за компонентите в PKI (ИПК);
·за онлайн системи — записват сведения, доказващи, че всяка проверка на уязвимостта и всяко изпитване за пробив са извършени от лице или организация (или колектив) с необходимите умения, инструменти, познания, етичен кодекс и независимост за гарантиране на тяхната надеждност;
·проследяват и отстранят уязвимостите в съответствие с политиките за корпоративна киберсигурност и методологията за намаляване на риска.
5.5.Архивиране на записи
5.5.1.Видове записи, подлежащи на архивиране
261)Звената в модела на доверие на СИТС архивират достатъчно подробни записи, за да може да се установи валидността на подпис и правилното функциониране на PKI (ИПК). Архивират се записи поне за следните събития в PKI (ИПК) (ако е приложимо):
·записи за достъпа до физически съоръжения на звена в модела на доверие на СИТС (минимум една година);
·записи за управлението на доверителни функции в звена в модела на доверие на СИТС (минимум 10 години);
·записи за достъпа до ИТ в звена в модела на доверие на СИТС (минимум пет години);
·записи, свързани със създаване, ползване и унищожаване на ключове на CA (УО) (минимум пет години) — не се отнася за TLM (АДС) и CPOC (ЗКС);
·записи, свързани със създаване, ползване и унищожаване на удостоверения (минимум две години);
·записи, свързани със заявки на CPA (ОПУ) (минимум две години);
·записи, свързани с управлението на данни за активиране, в звена в модела на доверие на СИТС (минимум пет години);
·записи, свързани с ИТ и мрежи в звена в модела на доверие на СИТС (минимум пет години);
·документация в PKI (ИПК) за звена в модела на доверие на СИТС (минимум пет години);
·инциденти, свързани със сигурността, и контролни доклади за звена в модела на доверие на СИТС (минимум 10 години);
·оборудване, софтуер и конфигурация на системите (минимум пет години).
262)Звената в модела на доверие на СИТС съхраняват следната документация, свързана със заявки за удостоверения и тяхната проверка, всички удостоверения на TLM (АДС), базови CA (УО) и CA (УО) и всички CRL (САУ) поне седем години след изтичане на валидността на което и да е удостоверение, отразено в тази документация:
·контролна документация за PKI (ИПК), съхранявана от звена в модела на доверие на СИТС;
·документи на CPS (ДПУ), съхранявани от звена в модела на доверие на СИТС;
·договори между CPA (ОПУ) и други субекти, съхранявани от звена в модела на доверие на СИТС;
·удостоверения (или информация за отмяната им), съхранявани от CA (УО) и TLM (АДС);
·записи за заявки за удостоверения в системи на базови CA (УО) — не се отнася за TLM (АДС);
·други данни или приложения, достатъчни за проверка на съдържанието на архива;
·всички дейности на одитори на съответствието, отнасящи се до звена в модела на доверие на СИТС.
263)CA (УО) съхранява цялата документация, свързана със заявки за удостоверения и тяхната проверка, всички удостоверения и всички данни за отмяната им поне седем години след изтичане на валидността на което и да е удостоверение, отразено в тази документация.
5.5.2.Период на съхранение на архива
264)Без да се засягат разпоредбите, изискващи по-дълъг период на съхранение на архива, звената в модела на доверие на СИТС съхраняват всички записи най-малко пет години след изтичане на валидността на съответното удостоверение.
5.5.3.Защита на архива
265)Звената в модела на доверие на СИТС съхраняват архива на записите в безопасно и сигурно хранилище, отделно от оборудването на CA (УО), снабдено с физически средства и процедури за контрол на сигурността, съизмерими със или по-добри от тези на PKI (ИПК).
266)Архивът се съхранява в надеждна система, която не позволява той да бъде разглеждан от неупълномощени лица, променян, изтриван или подправян по друг начин.
267)Носителите, в които се съхраняват архивираните данни, и приложенията, необходими за тяхното обработване, се поддържат, за да се гарантира достъпът до тях в продължение на периода, определен в настоящата CP (ППУ).
5.5.4.Системен архив и съхранението му
268)Звената в модела на доверие на СИТС създават частични резервни копия на системни архиви, съдържащи такава информация, всеки ден и пълни резервни копия всяка седмица. Копия на архиви на хартиен носител се съхраняват на защитено място извън обекта.
5.5.5.Изисквания за електронно вписване на часа и датата на записите
269)Звената в модела на доверие на СИТС, които управляват база данни за отмяна, гарантират, че записите отразяват времето и датата, когато е извършена отмяната. Целостта на тази информация се осигурява с криптографски решения.
5.5.6.Система за събиране на архивни данни (вътрешна или външна)
270)Системата за събиране на архивни данни е вътрешна.
5.5.7.Процедури за получаване и проверка на архивна информация
271)Всички звена в модела на доверие на СИТС разрешават достъп до архива само на упълномощени лица. Базовите и второстепенните CA (УО) описват процедурите за създаване, проверка, пакетиране, предаване и съхраняване на архивна информация в CPS (ДПУ).
272)Оборудването на базовите и второстепенните CA (УО) проверява целостта на информацията преди нейното възстановяване.
5.6.Смяна на ключа за звена в модела на доверие на СИТС
273)Специфични изисквания за смяна на ключа се предвиждат за следните звена в модела на доверие на СИТС: удостоверения на TLM (АДС), базови CA (УО) и ЕА (ОВ)/AA (РО).
5.6.1.TLM (АДС)
274)TLM (АДС) изтрива своя частен ключ след изтичане на валидността на свързаното с него удостоверение. Той генерира нова двойка ключове и ново удостоверение на TLM (АДС) преди деактивирането на настоящия частен ключ. Взема мерки новото (свързано) удостоверение да бъде вписано в ECTL (ДСЕУ) своевременно, за да може да бъде разпространено до всички станции на СИТС, преди да влезе в сила. Свързаното удостоверение и новото удостоверение, подписано от TLM (АДС), се изпращат на CPOC (ЗКС).
5.6.2.Базов CA (УО)
275)Базовият CA (УО) деактивира и изтрива текущия частен ключ (включително резервните ключове), за да не може с него да бъдат издадени удостоверения на ЕА (ОВ)/AA (РО), чиято валидност надхвърля валидността на удостоверението на базовия CA (УО).
276)Базовият CA (УО) генерира нова двойка ключове и ново (свързано) удостоверение на базов CA (УО), преди деактивирането на настоящия частен ключ (включително резервните ключове) и го изпраща на TLM (АДС), за да бъде вписано в ECTL (ДСЕУ). Периодът на валидност на новото удостоверение на базов CA (УО) започва да тече от момента на планираното деактивиране на настоящия частен ключ. Базовият CA (УО) взема мерки новото удостоверение да бъде вписано в ECTL (ДСЕУ) своевременно, за да може да бъде разпространено до всички станции на СИТС, преди да влезе в сила.
277)Базовият CA (УО) активира новия частен ключ, когато съответстващото на него удостоверение на базов CA (УО) влезе в сила.
5.6.3.Удостоверение на EA (ОВ)/AA (РО)
278)ЕА (ОВ)/AA (РО) деактивира настоящия частен ключ, за да не може с него да бъдат издадени EC (ПВ)/AT (ТР), чиято валидност надхвърля валидността на удостоверението на ЕА (ОВ)/AA (РО).
279)ЕА (ОВ)/AA (РО) генерира нова двойка ключове и изпраща заявка за ново удостоверение на ЕА (ОВ)/AA (РО) преди деактивирането на настоящия частен ключ. Периодът на валидност на новото удостоверение на ЕА (ОВ)/AA (РО) започва да тече от момента на планираното деактивиране на настоящия частен ключ. ЕА (ОВ)/AA (РО) взема мерки новото удостоверение да бъде публикувано своевременно, за да може да бъде разпространено до всички станции на СИТС, преди да влезе в сила.
280)ЕА (ОВ)/AA (РО) активира новия частен ключ, когато съответстващото на него удостоверение на базов ЕА (ОВ)/AA (РО) влезе в сила.
5.6.4.Одитор
Не се предвиждат разпоредби.
5.7.Компрометиране и възстановяване в случай на бедствие
5.7.1.Действия в случай на инцидент и компрометиране
281)Звената в модела на доверие на СИТС наблюдават своето оборудване непрекъснато, за да откриват своевременно хакерски атаки и други форми на компрометиране. Във всеки такъв случай те провеждат разследване, за да определят естеството и степента на нанесените вреди.
282)Ако служителите, отговарящи за управлението на базовия CA (УО) или на TLM (АДС), установят потенциална хакерска атака или други форми на компрометиране, те провеждат разследване, за да определят естеството и степента на нанесените вреди. В случай на компрометиране на частен ключ удостоверението на базовия CA (УО) се отменя. Експертите по информационна сигурност на CPA (ОПУ) оценяват обхвата на потенциалните вреди, за да преценят дали е необходимо да бъде изградена наново цялата PKI (ИПК), дали трябва да се отменят само някои удостоверения и/или дали е компрометирана PKI (ИПК). Освен това въз основа на плана си за непрекъснатост на работата CPA (ОПУ) преценява кои услуги следва да продължат да се поддържат (информация за отмяна и статус на удостоверенията) и по какъв начин да става това.
283)Действията в случай на инцидент и компрометиране и мерките за осигуряване на непрекъснатост на работата се описват в CPS (ДПУ), за чието прилагане може се разчита и на други корпоративни ресурси и планове.
284)Ако служителите, отговарящи за управлението на ЕА (ОВ)/AA (РО)/CPOC (ЗКС), установят потенциална хакерска атака или други форми на компрометиране, те провеждат разследване, за да определят естеството и степента на нанесените вреди. Служителите, отговарящи за управлението на CA (УО), или CPOC (ЗКС) оценяват обхвата на потенциалните вреди, за да преценят дали е необходимо да бъде изграден наново съответният компонент на PKI (ИПК), дали трябва да се отменят само някои удостоверения и/или дали е компрометиран компонентът на PKI (ИПК). Освен това въз основа на плана си за непрекъснатост на работата второстепенният CA (УО) преценява кои услуги следва да продължат да се поддържат (информация за отмяна и статус на удостоверенията) и по какъв начин да става това. В случай на компрометиране на компонент на PKI (ИПК) CA (УО) уведомява своя базов CA (УО) и TLM (АДС) чрез CPOC (ЗКС).
285)Действията в случай на инцидент и компрометиране и мерките за осигуряване на непрекъснатост на работата се описват в CPS (ДПУ) на базовия CA (УО) или на TLM (АДС) или в подобни документи на CPOC (ЗКС), за чието прилагане може се разчита и на други корпоративни ресурси и планове.
286)Базовият и второстепенните CA (УО) уведомяват за инцидента — с конкретни сведения за последиците от него — представителите на всички държави членки и базови CA (УО), с които имат договорни отношения в контекста на СИТС, за да може те да приведат в действие своите планове за управление на инциденти.
5.7.2.Увреждане на компютърна техника, софтуер и/или данни
287)Ако настъпи бедствие, което възпрепятства правилното функциониране на звено в модела на доверие на СИТС, то преустановява своята работа и проверява дали не е компрометиран неговият частен ключ (не се отнася за CPOC/ЗКС). Повреденият хардуер се подменя колкото е възможно по-бързо и се прилагат процедурите, описани в раздели 5.7.3 и 5.7.4.
288)Увреждането на компютърна техника, софтуер и/или данни се докладва на базовия CA (УО) в рамките на 24 часа в случай на най-високо ниво на риск. Всички други събития трябва да бъдат включени в периодичния доклад на базовия CA (УО), ЕА (ОВ) и AA (РО).
5.7.3.Процедури при компрометиране на частен ключ на субект
289)Ако частният ключ на базов CA (УО) е компрометиран, изгубен, унищожен или съществуват съмнения за компрометирането му, базовият CA (УО):
·прекратява работа;
·привежда в действие плана за възстановяване в случай на бедствие и плана за миграция;
·отменя удостоверението си на базов CA (УО);
·обследва проблема, довел до компрометирането на ключа, и уведомява CPA (ОПУ), който отменя удостоверението на базовия CA (УО) чрез TLM (АДС) (вж. раздел 7);
·уведомява всички абонати, с които има споразумение.
290)Ако частният ключ на ЕА (ОВ)/AA (РО) е компрометиран, изгубен, унищожен или съществуват съмнения за компрометирането му, ЕА (ОВ)/AA (РО):
·прекратява работа;
·отменя удостоверението си;
·обследва проблема, довел до компрометирането на ключа, и уведомява базовия CA (УО);
·уведомява абонатите, с които има споразумение.
291)Ако частният ключ за EC (ПВ) или AT (ТР) на станция на СИТС е компрометиран, изгубен, унищожен или съществуват съмнения за компрометирането му, станцията на СИТС:
·отменя EC (ПВ) на засегнатата ИТС;
·обследва проблема, довел до компрометирането на ключа, и уведомява базовия CA (УО);
·уведомява абонатите, с които има споразумение.
292)Когато някой от алгоритмите или свързаните с него параметри, прилагани от базовия CA (УО), от второстепенни CA (УО) или от станции на СИТС, се окаже недостатъчен за остатъка от планирания срок на ползването му, CPA (ОПУ) (след препоръка от експертите по криптография) уведомява базовия CA (УО), с който има споразумение, и променя алгоритъма. (За подробности вж. раздел 6 и CPS (ДПУ) на базовия CA (УО) и на второстепенния CA (УО).
5.7.4.Способности за продължаване на работата след бедствие
293)Звената в модела на доверие на СИТС, които ползват защитени съоръжения за операциите на CA (УО), разработват, изпитват, поддържат и прилагат план за възстановяване при бедствия, който има за цел да се смекчат последиците от всяко природно или предизвикано от човека бедствие. В плана се описват мерки за възстановяването на услугите на информационните системи и ключовите функции.
294)След инцидент с определено ниво на риск компрометираният CA (УО) трябва да бъде проверен отново от независим одитор на PKI (ИПК) (вж. раздел 8).
295)Когато компрометираният CA (УО) не е в състояние да продължи да функционира (напр. след тежък инцидент), трябва да бъде разработен план за миграция, въз основа на който неговите функции да бъдат прехвърлени на друг базов CA (УО). Поне базовият CA (УО) на ЕС следва да е на разположение за изпълнение на плана за миграция. Компрометираният CA (УО) прекратява своята дейност.
296)Планът за възстановяване в случай на бедствие и планът за миграция се включват в CPS (ДПУ) на базовите CA (УО).
5.8.Прекратяване и прехвърляне
5.8.1.TLM (АДС)
297)TLM (АДС) не прекратява своята дейност, но неговото управление може да бъде поето от друг субект.
298)В случай на промяна на управляващия субект:
·TLM (АДС) иска от CPA (ОПУ) одобрение за прехвърлянето на управлението от стария на новия субект;
·CPA (ОПУ) одобрява промяната в управлението на TLM (АДС);
·всички контролни регистри и архивирани записи се прехвърлят от предишния на новия управляващ субект.
5.8.2.Базов CA (УО)
299)Базовият CA (УО) не започва/не прекратява дейност, без да има установен план за миграция (описан в CPS/ДПУ), който гарантира непрекъснатост на услугите за всички абонати.
300)В случай на прекратяване на услугите на базовия CA (УО) той:
·уведомява CPA (ОПУ);
·уведомява TLM (АДС), за да може да премахне удостоверението на базовия CA (УО) от ECTL (ДСЕУ);
·отменя съответното удостоверение на базов CA (УО), като издава CRL (САУ), съдържащ удостоверението;
·уведомява базовите CA (УО), с които има споразумение, с оглед подновяването на удостоверения на ЕА (ОВ)/AA (РО);
·унищожава частния си ключ;
·изпраща на доверяващата се страна сведения за статуса на отмяна (CRL/САУ), подписан от базовия CA/УО), като посочва ясно, че това е последната информация за отмяна;
·архивира всички контролни регистри и други записи преди прекратяване на функционирането на PKI (ИПК);
·прехвърля архивираните записи на подходящ орган.
301)TLM (АДС) премахва съответното удостоверение на базов CA (УО) от ECTL (ДСЕУ).
5.8.3.EA (ОВ)/AA (РО)
302)В случай на прекратяване на услугите на ЕА (ОВ)/AA (РО) съответният субект изпраща предизвестие за прекратяване. ЕА (ОВ)/AA (РО) не започва/не прекратява дейност, без да има установен план за миграция (описан в CPS/ДПУ), който гарантира непрекъснатост на услугите за всички абонати. ЕА (ОВ)/AA (РО):
·информира базовия CA (УО) с препоръчано писмо;
·унищожава частния си ключ;
·прехвърля базата си данни на субект, определен от базовия CA (УО);
·престава да издава удостоверения;
·по време на прехвърлянето на своята база данни и до пълното ѝ въвеждане в експлоатация в нов субект, поддържа способността си да разрешава искания, подадени от компетентния орган за поверителността;
·при компрометиране на второстепенен CA (УО) базовият CA (УО) отнема правомощията му да функционира като второстепенен CA (УО) и издава нов CRL (САУ), включващ второстепенни CA (УО) с отнети правомощия;
·архивира всички контролни регистри и други записи преди прекратяване на функционирането на PKI (ИПК);
·прехвърля архивираните записи на субект, определен от базовия CA (УО).
303)В случай на прекратяване на услугите на CA (УО) той носи отговорност за съхранението на всички архиви, отнасящи се до нуждите на CA (УО) и на компоненти в PKI (ИПК).
6.Технически средства за контрол на сигурността
6.1.Генериране и инсталиране на двойки ключове
6.1.1.TLM (АДС), базов CA (УО), EA (ОВ), AA (РО)
304)Процедурата за генериране на двойки ключове трябва да отговаря на следните изисквания:
·всеки участник може да генерира свои двойки ключове в съответствие с раздели 6.1.4 и 6.1.5;
·процедурата за извличане на симетрични ключове за криптиране и на ключ MAC за заявки за удостоверения (ECIES) се извършва съгласно [1] и [5];
·в процеса на генериране на ключове се ползват алгоритмити и дължините на ключовете, описани в раздели 6.1.4.1 и 6.1.4.2;
·процесът на генериране на ключове отговаря на изискванията за „защитено съхранение на частни ключове“ (вж. раздел 6.1.5);
·базовите CA (УО) и техните абонати (второстепенни CA/УО) гарантират, че целостта и достоверността на техните публични ключове и свързаните с тях параметри се запазват при разпространението до субекти, регистрирани от второстепенни CA (УО).
6.1.2.EE (КС) — мобилна станция на СИТС
305)Всяка мобилна станция на СИТС генерира свои двойки ключове в съответствие с раздели 6.1.4 и 6.1.5.
306)Процедурата за извличане на симетрични ключове за криптиране и на ключ MAC за заявки за удостоверения (ECIES) се извършва съгласно [1] и [5].
307)В процесите на генериране на ключове се ползват алгоритмите и дължините на ключовете, описани в раздели 6.1.4.1 и 6.1.4.2.
308)Процесите на генериране на ключове отговарят на изискванията за „защитено съхранение на частни ключове“ (вж. раздел 6.1.5).
6.1.3.EE (КС) — фиксирана станция на СИТС
309)Всяка фиксирана станция на СИТС генерира своя собствена двойка ключове в съответствие с раздели 6.1.4 и 6.1.5.
310)В процесите на генериране на ключове се ползват алгоритмите и дължините на ключовете, описани в раздели 6.1.4.1 и 6.1.4.2.
311)Процесите на генериране на ключове отговарят на изискванията за „защитено съхранение на частни ключове“ (вж. раздел 6.1.5).
6.1.4.Изисквания за криптографиране
312)Всички участници в PKI (ИПК) трябва да отговарят на криптографските изисквания, изложени в следващите параграфи, що се отнася до алгоритъма на подписа, дължината на ключа, генератора на случайни числа и свързаните удостоверения.
6.1.4.1.Алгоритъм и дължина на ключа — алгоритми на подписа
313)Всички участници в PKI (ИПК) — TLM (АДС), базов CA (УО), ЕА (ОВ), AA (РО) и станции на СИТС — следва да могат да генерират двойки ключове и да използват частния ключ за подписване на операции с избрани алгоритми най-късно две години след влизането в сила на настоящия регламент в съответствие с таблица 4.
314)Всички участници в PKI (ИПК), които трябва да проверяват целостта на ECTL (ДСЕУ), на удостоверения и/или на подписани съобщения в съответствие с функциите им, както е определено в раздел 1.3.6, поддържат съответните алгоритми за проверка, описани в таблица 5. По-специално станциите на СИТС следва да могат да проверяват целостта на ECTL (ДСЕУ).
|
TLM (АДС)
|
базов CA (УО)
|
EA (ОВ)
|
AA (РО)
|
Станции на СИТС
|
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, трябва задължително да се поддържат.
|
Таблица 4: Генериране на двойки ключове и ползване на частен ключ за операции, изискващи подпис
|
TLM (АДС)
|
базов CA (УО)
|
EA (ОВ)
|
AA (РО)
|
Станции на СИТС
|
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, трябва задължително да се поддържат.
|
Таблица 5: Преглед на проверката
315)Ако CPA (ОПУ) реши въз основа на новоустановени слабости в криптографията, всички станции на СИТС следва да могат да преминат към един от двата алгоритъма (ECDSA_nistP256_with_SHA 256 или ECDSA_brainpoolP256_with_SHA 256), колкото е възможно по-бързо. Действителният алгоритъм/действителните алгоритми, който/които се прилагат, се определят в CPS (ДПУ) на CA (УО), който издава удостоверението за съответния публичен ключ съгласно настоящата CP (ППУ).
6.1.4.2.Алгоритъм и дължина на ключа — алгоритми на криптирането при вписване и разрешаване на достъпа
316)Всички участници в PKI (ИПК) — ЕА (ОВ), AA (РО) и станции на СИТС — следва да могат да ползват публични ключове за криптиране на заявки за вписване и разрешение и на отговори на тях с избрани алгоритми най-късно две години след влизането в сила на настоящия регламент в съответствие с таблица 6. Действителният алгоритъм/действителните алгоритми, който/които се прилагат, се определят в CPS (ДПУ) на CA (УО), който издава удостоверението за съответния публичен ключ съгласно настоящата CP (ППУ).
317)Посочените алгоритми в таблица 6 показват дължината на ключа и дължината на алгоритъма за хеширане и се изпълняват в съответствие с [5].
|
TLM (АДС)
|
базов CA (УО)
|
EA (ОВ)
|
AA (РО)
|
Станции на СИТС
|
ECIES_nistP256_with_AES 128_CCM
|
—
|
—
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
—
|
—
|
X
|
X
|
X
|
Полетата, отбелязани с X, трябва задължително да се поддържат.
|
Таблица 6: Ползване на публични ключове за криптиране на заявки за вписване и разрешение и на отговори на тях
318)Всички участници в PKI (ИПК) — ЕА (ОВ), AA (РО) и станции на СИТС — следва да могат да генерират двойки ключове и да ползват частния ключ за декриптиране на заявки за вписване и разрешение и на отговори на тях с избрани алгоритми най-късно две години след влизането в сила на настоящия регламент в съответствие с таблица 7:
|
TLM (АДС)
|
базов CA (УО)
|
EA (ОВ)
|
AA (РО)
|
Станции на СИТС
|
ECIES_nistP256_with_AES 128_CCM
|
—
|
—
|
X
|
X
|
X
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
—
|
—
|
X
|
X
|
X
|
Полетата, отбелязани с X, трябва задължително да се поддържат.
|
Таблица 7: Генериране на двойки ключове и ползване на частен ключ за декриптиране на заявки за вписване и разрешение и на отговори на тях
6.1.4.3.Криптогъвкавост
319)Изискванията за дължина на ключовете и алгоритмите трябва да се променят от време на време, за да се поддържа подходящо ниво на сигурност. CPA (ОПУ) следи за необходимостта от такива промени с оглед на действителните уязвимости и на най-съвременните достижения в областта на криптографията. Той изготвя, одобрява и публикува актуализирана версия на настоящата политика за предоставяне на удостоверения, ако прецени, че криптографските алгоритми следва да бъдат актуализирани. Когато с нова версия на настоящата СР (ППУ) бъде обявена промяна на алгоритъм и/или на дължина на ключа, CPA (ОПУ) приема стратегия за миграция, предвиждаща преходни периоди, през които трябва да се поддържат досегашните алгоритми и дължини на ключове.
320)За да бъде възможно и да се улесни преминаването към нови алгоритми и/или дължини на ключове, препоръчително е всички участници в PKI (ИПК) да ползват хардуер и/или софтуер, който позволява смяната на дължини на ключове и алгоритми.
321)Трябва да се поддържат промени в базови удостоверения и удостоверения на TLM (АДС), извършвани посредством свързани удостоверения (вж. раздел 4.6), които покриват преходния период от старото към новото базово удостоверение („миграция на модела на доверие“).
6.1.5.Защитено съхранение на частни ключове
В този раздел са описани изискванията за защитено съхранение и генериране на двойки ключове и случайни числа за CA (УО) и крайни субекти. Тези изисквания са определени за криптографски модули и са описани в следващите подраздели.
6.1.5.1.На ниво базов CA (УО), второстепенен CA (УО) и TLM (АДС)
322)Криптографски модул се ползва за:
·генериране, ползване, управление и съхранение на частни ключове;
·генериране и ползване на случайни числа (оценката на функцията за генериране на случайни числа е част от процеса на оценка и удостоверяване на сигурността);
·създаване на резервни копия на частни ключове в съответствие с раздел 6.1.6;
·изтриване на частни ключове.
Криптографският модул се удостоверява с един от следните защитни профили с ниво на сигурност EAL–4 или по-високо:
·Защитни профили за HSM (ХМС)
·CEN EN 419 221-2: Защитни профили за TSP криптографски модули — Част 2: Криптографски модул за CSP операции за електронен подпис с архивиране;
·CEN EN 419 221-4: Защитни профили за TSP криптографски модули — Част 4: Криптографски модул за CSP операции за електронен подпис без архивиране;
·CEN EN 419 221-5: Защитни профили за TSP криптографски модули — Част 5: Криптографски модул за удостоверителни услуги;
·Защитни профили за смарткарти:
·CEN EN 419 211-2: Защитни профили за устройство за защитено създаване на подписи — Част 2: Устройство с генериране на ключове;
·CEN EN 419 211-3: Защитни профили за устройство за защитено създаване на подписи — Част 3: Устройство с внасяне на ключове.
За ръчен достъп до криптографския модул се изисква двустепенно удостоверяване на идентичността от страна на администратора. Освен това се изисква участието на две упълномощени лица.
Реализацията на криптографски модул гарантира, че ключовете не са достъпни извън него. Криптографският модул включва механизъм за контрол на достъпа за предотвратяване на неразрешено ползване на частни ключове.
6.1.5.2.Краен субект
323)Криптографски модул за EE (КС) се ползва за:
·генериране, ползване, управление и съхранение на частни ключове;
·генериране и ползване на случайни числа (оценката на функцията за генериране на случайни числа е част от процеса на оценка и удостоверяване на сигурността);
·защитено изтриване на частни ключове.
324)Криптографският модул има защита срещу неразрешено демонтиране, подмяна или модификация. Всички защитни профили и свързаните с тях документи, приложими за удостоверяване на сигурността на криптографския модул, се оценяват, заверяват и сертифицират в съответствие с ISO 15408, като се прилага Споразумението за взаимно признаване на удостоверенията за оценка на сигурността на информационните технологии на групата на висшите служители по информационната сигурност (SOG-IS) или равностойна европейска схема за удостоверяване на киберсигурността съгласно съответната европейска рамка в областта на киберсигурността.
325)Предвид важността на поддържането на възможно най-високо ниво на сигурност удостоверенията за сигурност на криптографския модул се издават съгласно схемата за удостоверяване (ISO 15408), основана на общи критерии, от орган за оценяване на съответствието, признат от управителния комитет в рамките на споразумението на SOG-IS, или се издават от орган за оценяване на съответствието, акредитиран национален удостоверяващ орган в областта на киберсигурността на държава членка. Този орган за оценяване на съответствието осигурява условия за оценяване на сигурността, които са поне равностойни на предвидените в споразумението за взаимно признаване (СВП) на Групата на висшите служители по сигурността на информационните системи (SOG-IS).
Забележка: връзката между криптографския модул и станцията на СИТС е защитена.
6.1.6.Резервни копия на частни ключове
326)Генерирането, съхранението и ползването на резервни копия на частни ключове отговаря поне на изискванията за ниво на сигурност, което се изисква за оригиналните ключове.
327)Резервни копия на частни ключове се правят от базови CA (УО), ЕА (ОВ) и AA (РО).
328)Резервни копия на частни ключове не се правят за EC (ПВ) и AT (ТР).
6.1.7.Унищожаване на частни ключове
329)Базовите CA (УО), ЕА (ОВ), AA (РО) и мобилните и фиксираните станции на СИТС унищожават своя частен ключ и всички негови резервни копия, ако е генерирана и успешно инсталирана нова двойка ключове и съответстващо на нея удостоверение и ако е изтекло времето на припокриване (ако има такова — само за СА/УО). Частният ключ се унищожава с механизма, предлаган от криптографския модул, използван за съхранението на ключа или както е описано в съответния защитен профил, упоменат в раздел 6.1.5.2.
6.2.Данни за активиране
330)Данните за активиране се отнасят до фактори, свързани с удостоверяването на идентичността, които се изискват при работа с криптографски модули с оглед предотвратяване на неразрешен достъп. При ползване на данни за активиране на криптографско устройство на CA (УО) се изисква действие от две упълномощени лица.
6.3.Контрол на компютърната сигурност
331)Средствата на CA (УО) за контрол на компютърната сигурност се разработват за високо ниво на сигурност, като се спазват изискванията на ISO/IEC 27002.
6.4.Технически средства за контрол на жизнения цикъл
332)Техническите средства за контрол обхващат целия жизнен цикъл на CA (УО). Това включва по-специално изискванията, описани в раздел 6.1.4.3 („Криптогъвкавост“).
6.5.Контрол на сигурността на мрежата
333)Мрежите на CA (УО) — базов CA (УО), ЕА (ОВ) и AA (РО) — са укрепени срещу атаки в съответствие с изискванията и насоките за прилагане на ISO/IEC 27001 и ISO/IEC 27002.
334)Капацитетът на мрежите на CA (УО) се проектира в съответствие с очаквания трафик.
7.Профил на удостоверенията, CRL (САУ) и CTL (ДСУ)
7.1.Профил на удостоверенията
335)Профилите на удостоверенията, описани в [5], се прилагат за удостоверения на TLM (АДС), базови удостоверения, удостоверения на ЕА (ОВ), удостоверения на AA (РО), AT (ТР) и EC (ПВ). Национални правителствени ЕА (ОВ) могат да ползват други профили на удостоверения за EC (ПВ).
336)В удостоверенията на базови CA (УО), ЕА (ОВ) и AA (РО) се посочват разрешенията, за които тези CA (УО) — базови CA (УО), ЕА (ОВ) и AA (РО) — имат право да издават удостоверения.
337)Въз основа на [5]:
·всеки базов CA (УО) използва свой собствен частен ключ за подпис при издаване на CRL (САУ);
·TLM (АДС) използва свой собствен частен ключ за подпис при издаване на ECTL (ДСЕУ).
7.2.Валидност на удостоверенията
338)Във всички профили на удостоверения в СИТС се посочва дата на издаване и срок на валидност, които представляват периода на валидност на удостоверенията. Удостоверенията на всяко ниво от PKI (ИПК) се генерират своевременно преди изтичане на тяхната валидност.
339)Периодът на валидност на удостоверения на CA (УО) и EC (ПВ) включва време на припокриване. Удостоверения на TLM (АДС) и базови CA (УО) се издават и въвеждат в ECTL (ДСЕУ) най-много три месеца и най-малко един месец преди началото на тяхната валидност, упоменато в удостоверението. Този период на предварително зареждане е необходим за своевременно разпространение на удостоверенията до всички доверяващи се страни в съответствие с раздел 2.2. По този начин се гарантира, че всички доверяващи се страни ще могат да проверяват съобщения, издадени с новото удостоверение, още от началото на времето на припокриване.
340)Последващите удостоверения на CA (УО), EC (ПВ) и AT (ТР) се издават (ако е приложимо), разпространяват и инсталират от съответните доверяващи се страни в началото на времето на припокриване. Докато трае времето на припокриване, настоящото удостоверение се използва само за проверка.
341)Тъй като периодите на валидност, посочени в таблица 8, не трябва да надвишават периода на валидност на по-висшето удостоверение, се прилагат следните ограничения:
·maximumvalidity(Root CA) = privatekeyusage(Root CA) + maximumvalidity(EA,AA);
·maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC);
·maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(AT).
342)Валидността на свързаните удостоверения — базови и на TLM (АДС) — започва да тече при въвеждане на съответния частен ключ и изтича в края на максималния период на валидност на базовия CA (УО) или TLM (АДС).
343)В таблица 8 е посочен максималният период на валидност на удостоверения на CA (ОУ) в СИТС (за периода на валидност на AT (ТР) вж. раздел 7.2.1).
Субект
|
Максимален период за ползване на частен ключ
|
Максимален период на валидност
|
Базов CA (УО)
|
3 години
|
8 години
|
EA (ОВ)
|
2 години
|
5 години
|
AA (РО)
|
4 години
|
5 години
|
EC (ПВ)
|
3 години
|
3 години
|
TLM (АДС)
|
3 години
|
4 години
|
Таблица 8: Период на валидност на удостоверенията в модела на доверие на СИТС
7.2.1.Псевдонимни удостоверения
344)В този контекст псевдоними се ползват в AT (ТР). Следователно настоящият раздел се отнася за AT (ТР), а не за псевдонимите.
345)Изискванията, посочени в този раздел, се отнасят само за AT (ТР) на мобилни станции на СИТС, изпращи съобщения CAM и DENM, при които съществува риск от компрометиране на поверителността на местоположението. Не се прилагат специфични изисквания по отношение на удостоверенията за AT (ТР) на фиксирани и мобилни станции на СИТС, използвани за превозни средства със специално предназначение, чието местоположение не е поверително (напр. маркирани превозни средства за спешна помощ и автомобили на правоприлагащи органи).
346)Прилагат се следните определения:
·„период на валидност на AT (ТР)“ — периодът, през който даден AT (ТР) е в сила, т.е. периодът между неговата начална дата и датата на изтичане на валидността му;
·„период на предварително зареждане AT (ТР)“ — предварителното зареждане дава възможност на станции на СИТС да получат AT (ТР), преди да започне да тече техният период на валидност. Периодът на предварително зареждане е максимално допустимият период от подаване на заявката за AT (ТР) до най-късната дата на изтичане на валидността на всеки заявен AT (ТР);
·„период на ползване на AT (ТР)“ — периодът, през който даден AT (ТР) действително се ползва за подписване на съобщения CAM/DENM;
·„максимален брой паралелни AT (ТР)“ — брой AT (ТР), от които дадена станция на СИТС може да избира във всеки момент, за да подписва съобщения CAM/DENM, т.е. брой различни AT (ТР), издадени на една станция на СИТС, които са валидни едновременно.
347)Прилагат се следните изисквания:
·периодът на предварително зареждане на AT (ТР) не надвишава три месеца;
·периодът на валидност на AT (ТР) не надвишава една седмица;
·максималният брой паралелни AT (ТР) не надвишава 100 на станция на СИТС;
·периодът на ползване на AT (ТР) зависи от стратегията за подмяна на AT (ТР) и от времето, през което превозното средство е в експлоатация, но е ограничен от максималния брой паралелни AT (ТР) и от периода на валидност. По-конкретно, средният период на ползване за дадена станция на СИТС е равен поне на времето на експлоатация на превозното средство в рамките на един период на валидност, разделено на максималния брой паралелни AT (ТР).
7.2.2.Талони за разрешение за фиксирани станции на СИТС
348)Прилагат се определенията в раздел 7.2.1 и следните изисквания:
·периодът на предварително зареждане на AT (ТР) не надвишава три месеца;
·максималният брой паралелни AT (ТР) не надвишава две на станция на СИТС;
7.3.Отмяна на удостоверения
7.3.1.Отмяна на удостоверения на CA (УО), EA (ОВ) и AA (РО)
Удостоверенията на базов CA (УО), ЕА (ОВ) и AA (РО) могат да бъдат отменяни. Отменени удостоверения на базови CA (УО), ЕА (ОВ) и AA (РО) се публикуват в CRL (САУ) възможно най-бързо и без неоправдано забавяне. Този CRL (САУ) се подписва от съответния базов CA (УО) и се съставя въз основа на профила, описан в раздел 7.4. При отмяна на удостоверения на базов CA (УО) съответният базов CA (УО) издава CRL (САУ), съдържащ удостоверението. В случай на компрометиране на сигурността се прилага раздел 5.7.3. Освен това TLM (АДС) премахва отменените базови CA (УО) от доверителния списък и издава нов доверителен списък. Изтеклите удостоверения се премахват от съответния CRL (САУ) и доверителен списък.
349)Удостоверения се отменят, когато:
·базовите CA (УО) имат основание да смятат или силно подозират, че съответният частен ключ е бил компрометиран;
·базовите CA (УО) са уведомени, че договорът с абоната е прекратен;
·информацията, посочена в удостоверението (напр. име и връзка между CA (УО) и субекта), е неправилна или се е променила;
·възниква инцидент, свързан със сигурността, който засяга притежателя на удостоверението;
·извършен одит (вж. раздел 8) е довел до отрицателен резултат.
350)Абонатът незабавно уведомява CA (УО), ако установи или подозира, че частният му ключ е компрометиран. Трябва да се гарантира, че удостоверения се отменят само въз основа на заявки, чиято идентичност е удостоверена.
7.3.2.Отмяна на пълномощия за вписване
351)EC (ПВ) могат да бъдат отменени по инициатива на абонат на станцията на СИТС (поток 34), а отмяната се извършва посредством вътрешен „черен списък“ в база данни за отмяна, с времеви печат, който се генерира и поддържа от всеки ЕА (ОВ). „Черният списък“ никога не се публикува, остава поверителен и се ползва само от съответния ЕА (ОВ) за проверка на валидността на EC (ПВ) при получаване на заявки за AT (ТР) и за нови EC (ПВ).
7.3.3.Отмяна на талони за разрешение
352)Тъй като АТ (ТР) не се отменят от съответните CA (УО), те трябва да имат кратък живот и не могат да се издават много по-рано преди началото на тяхната валидност. Допустимите стойности за жизнения цикъл на удостоверенията са посочени в раздел 7.2.
7.4.Списък на отменените удостоверения
353)Форматът и съдържанието на CRL (САУ), издавани от базови CA (УО), съответства на изискванията на [1].
7.5.Доверителен списък на европейските удостоверения
354)Форматът и съдържанието на ECTL (ДСЕУ), издаван от TLM (АДС), съответства на изискванията на [1].
8.Одит на съответствието и други оценки
8.1.Въпроси в обхвата на одита и основа на одита
355)Целта на одита на съответствието е да се потвърди, че TLM (АДС), базовите CA (УО), ЕА (ОВ) и AA (РО) работят в съответствие с настоящата CP (ППУ). TLM (АДС), базовите CA (УО), ЕА (ОВ) и AA (РО) избират независим и акредитиран одитор на PKI (ИПК), който да извърши одит на техните CPS (ДПУ). Одитът се съчетава с оценка съгласно ISO/IEC 27001 и ISO/IEC 27002.
356)Одитът на съответствието се възлага от базов CA (УО) (поток 13) за самия него и от второстепенен CA (УО) за подчинените му ЕА (ОВ)/AA (РО).
357)Одитът на съответствието на TLM (АДС) се възлага от CPA (ОПУ) (поток 38).
358)При поискване независимият одитор на PKI (ИПК) извършва одит на съответствието на едно от следните равнища:
1)съответствие на CPS (ДПУ) на TLM (АДС), базовия CA (УО), ЕА (ОВ) или AA (РО) с настоящата CP (ППУ);
2)съответствие на предвидените практики на TLM (АДС), базовия CA (УО), ЕА (ОВ) или AA (РО) с неговата CPS (ДПУ) преди започване на дейността;
3)съответствие на практиките и оперативните дейности на TLM (АДС), базовия CA (УО), ЕА (ОВ) или AA (РО) с неговата CPS (ДПУ) по време на работа.
359)Одитът обхваща всички изисквания на настоящата CP (ППУ), които следва да бъдат изпълнени от одитираните TLM (АДС), базови CA (УО), ЕА (ОВ) и AA (РО). Той обхваща също работата на CA (УО) в PKI (ИПК) на СИТС, включително всички процеси, упоменати в неговата CPS (ДПУ), материалната база и отговорните лица.
360)Независимият одитор на PKI (ИПК) представя подробен доклад от одита на базовия CA (УО) (поток 36), ЕА (ОВ), AA (РО) или CPA (ОПУ) (поток 16 и поток 40), както е уместно.
8.2.Честота на одитите
361)Базов CA (УО), TLM (АДС), ЕА (ОВ) или AA (РО) възлага одит на съответствието за самия себе си на независим и акредитиран одитор на PKI (ИПК) в следните случаи:
·при първоначалното си учредяване (нива на съответствие 1 и 2);
·при всяка промяна в CP (ППУ). CPA (ОПУ) определя естеството на промените в CP (ППУ) и графика за въвеждането им и преценява необходимостта от одит (включително необходимото ниво на съответствие), както е уместно;
·при всяка промяна в неговата CPS (ДПУ) (нива на съответствие 1, 2 и 3). Тъй като субектите, управляващи базови CA (УО), TLM (АДС) и ЕА (ОВ)/AA (РО), решават сами какви промени са необходими за прилагане на актуализираните версии на техните CPS (ДПУ), те възлагат одит на съответствието, преди да въведат тези промени. В случай на незначителни промени в CPS (ДПУ) (напр. от редакционен характер), управляващият субект може да изпрати на CPA (ОПУ) за одобрение надлежно обосновано искане да бъдат пропуснати одитите на съответствието на ниво 1, 2 или 3;
·редовно и поне на всеки три години от дейността (ниво на съответствие 3).
8.3.Самоличност/квалификация на одитора
362)Подлежащият на одит CA (УО) избира независима и акредитирана компания/организация („одитиращ орган“) или независими одитори на PKI (ИПК), които да извършат одита в съответствие с настоящата CP (ППУ). Одитиращият орган следва да бъде акредитиран и сертифициран от член на „Европейска акредитация“ (European Accreditation).
8.4.Взаимоотношения на одитора с одитирания субект
363)Независимият одитор на PKI (ИПК) е независим от одитирания субект.
8.5.Предприети действия в случай на недостатъци
364)Когато въз основа на одитния доклад бъде установено, че TLM (АДС) не отговаря на изискванията, CPA (ОПУ) нарежда на TLM (АДС) да предприеме незабавни превантивни/корективни действия.
365)Когато базов CA (УО), който съгласно одитния доклад не отговаря на изискванията, подаде ново заявление, CPA (ОПУ) го отхвърля и изпраща отказа на базовия CA (УО) (поток 4). В такива случаи базовият CA (УО) преустановява временно дейността си. Той трябва да предприеме корективни действия, да възложи повторен одит и да подаде нова заявка за одобрение до CPA (ОПУ). Докато трае периодът на временно преустановяване на дейността, базовият CA (УО) няма право да издава удостоверения.
366)При редовен одит на базов CA (УО) или при промяна в неговата CPS (ДПУ) и в зависимост от естеството на несъответствието, описано в одитния доклад, CPA (ОПУ) може да реши да отмени базовия CA (УО), като уведоми TLM (АДС) за своето решение (поток 2), с което удостоверението на базовия CA (УО) се премахва от ECTL (ДСЕУ) и базовият CA (УО) се вписва в CRL (САУ). CPA (ОПУ) изпраща съответния отказ на базовия CA (УО) (поток 4). Базовият CA (УО) трябва да предприеме корективни действия, да възложи повторен пълен одит (нива 1 до 3) и да подаде нова заявка за одобрение до CPA (ОПУ). CPA (ОПУ) може също да реши да не отменя базовия CA (УО), а да му даде гратисен период, през който базовият CA (УО) трябва да предприеме корективни действия, да възложи повторен одит и да внесе отново одитния доклад в CPA (ОПУ). В такъв случай дейността на базовия CA (УО) се преустановява временно и той няма право да издава удостоверения и CRL (САУ).
367)При одит на ЕА (ОВ)/AA (РО) базовият CA (УО) взема решение дали да приеме или да отхвърли доклада. В зависимост от резултата от одита базовият CA (УО) решава дали да отмени удостоверението на ЕА (ОВ)/AA (РО) в съответствие с правилата, описани в CPS (ДПУ) на базовия CA (УО). Базовият CA (УО) гарантира съответствието на ЕА (ОВ)/AA (РО) с настоящата CP (ППУ) по всяко време.
8.6.Съобщаване на резултатите
368)Базовият CA (УО) и TLM (АДС) изпращат одитния доклад на CPA (ОПУ) (поток 16). Базовият CA (УО) и TLM (АДС) съхраняват докладите от възложените от тях одити. CPA (ОПУ) изпраща съответно одобрение или отказ (поток 4) на базовия CA (УО) и на TLM (АДС).
369)Базовият CA (УО) изпраща удостоверение за съответствие на съответния ЕА (ОВ)/AA (РО).
9.Други разпоредби
9.1.Такси
370)Един от принципите на прилагания модел на доверие на СИТС на ЕС е, че базовите CA (УО) покриват съвместно всички редовни текущи разходи за дейността на CPA (ОПУ) и на централните звена (TLM/АДС) и CPOC/ЗКС), свързани с дейностите, описани в настоящата CP (ППУ).
371)Базовите CA (УО) (включително базовият CA (УО) на ЕС) имат право да събират такси от подчинените им второстепенни CA (УО).
372)През периода на функционирането си всеки участник в модела на доверие на СИТС следва да има достъп поне до един базов CA (УО), ЕА (ОВ) и AA (РО) при спазване на принципа за равнопоставеност.
373)Всеки базов CA (УО) има право да начисли таксите, които плаща на CPA (ОПУ) и на централните звена (TLM/АДС) и CPOC/ЗКС), на регистрираните участници в модела на доверие на СИТС, включително вписани и упълномощени станции на СИТС.
9.2.Финансова отговорност
374)След първоначалното си учредяване един базов CA (УО) трябва да работи поне три години, за да стане член на модела на доверие на СИТС на ЕС. В CPS (ДПУ) на базовия CA (УО) се предвиждат също подробни разпоредби относно отмяната или закриването на базов CA (УО).
375)Всяко юридическо лице, което действа като базов CA (УО), трябва да докаже финансовата си жизнеспособност поне за период от три години. Планът за финансова жизнеспособност е част от първоначалния набор от документи за вписване и трябва да бъде актуализиран на всеки три години и представян на CPA (ОПУ).
376)Всеки базов CA (УО) трябва да представя ежегодно структурата на събираните такси от ЕА (ОВ)/AA (РО) и от вписани и упълномощени станции на СИТС на оперативния ръководител и на CPA (ОПУ), за да докаже своята финансова устойчивост.
377)Всички субекти на базовия CA (УО), ЕА (ОВ), AA (РО) и на централните звена (CPOC/ЗКС) и TLM/АДС) в модела на доверие на СИТС, които носят финансова и правна отговорност, трябва да изпълняват своите оперативни задължения с необходимото равнище на застраховане, което да компенсира оперативни грешки и финансови разходи за възстановяване на дейността в случай на срив на някой от техническите компоненти.
9.3.Поверителност на търговската информация
378)Следната информация е поверителна и лична:
·документация, свързана със заявления на базови CA (УО), ЕА (ОВ), AA (РО), независимо дали са били одобрени, или отхвърлени;
·доклади от одити на базови CA (УО), ЕА (ОВ), AA (РО) и TLM (АДС);
·планове за възстановяване в случай на бедствие на базови CA (УО), ЕА (ОВ), AA (РО), CPOC (ЗКС) и TLM (АДС);
·частни ключове на звена в модела на доверие на СИТС — станции на СИТС, TLM (АДС), ЕА (ОВ), AA (РО), базови CA (УО);
·всяка друга информация, определена като поверителна от CPA (ОПУ), базови CA (УО), ЕА (ОВ), AA (РО), TLM (АДС) и CPOC (ЗКС).
9.4.План за поверителност
379)Планът и изискванията за третиране на личната информация и неприкосновеността на личния живот въз основа на GDPR (ОРЗД) и на други приложими законодателни рамки (напр. национални) се описват в CPS (ДПУ) на базовите CA (УО) и на ЕА (ОВ)/AA (РО).
10.Препратки
В настоящото приложение се правят препратки към следните документи:
[1]
|
ETSI TS 102 941 V1.2.1, Интелигентни транспортни системи (ИТС) — управление на сигурността, доверието и поверителността.
|
[2]
|
ETSI TS 102 940 V1.3.1, Интелигентни транспортни системи (ИТС) — сигурност, архитектура за сигурност на комуникациите в ИТС и управление на сигурността.
|
[3]
|
Рамка на политиката за предоставяне на удостоверения и удостоверителните практики (RFC 3647, 1999).
|
[4]
|
ETSI TS 102 042 V2.4.1 Изисквания към политиката на удостоверяващи органи, издаващи удостоверения за публични ключове.
|
[5]
|
ETSI TS 103 097 V1.3.1, Интелигентни транспортни системи (ИТС) — сигурност, формати на заглавен ред и удостоверения за сигурност.
|
[6]
|
Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide. [Сигурност на информацията въз основа на ISO 27001/ISO 1779: ръководство за управление] Van Haren Publishing.
|
[7]
|
ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) — Информационни технологии. Методи за сигурност. Управление на риска за сигурността на информацията. ISO.
|
|
|