ГОСТ Р 58123-2018 Транспорт дорожный. Интерфейс связи автомобиль-электрическая сеть. Часть 2. Требования к протоколу сетевого и прикладного уровней

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

58123—

2018

(ИСО 15118-2: 2014)

ТРАНСПОРТ ДОРОЖНЫЙ Интерфейс связи

автомобиль — электрическая сеть

Часть 2

Требования к протоколу сетевого и прикладного уровней

(ISO 15118-2:2014, MOO)

Издание официальное

Москва

Стандартимформ

2018

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием «Центральный ор-дена Трудового Красного Знамени научно-исследовательский автомобильный и автомоторный институт» (ФГУП «НАМИ») на основе собственного перевода на русский язык англоязычной версии стандарта. указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 56 «Дорожный транспорт»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 2 октября 2018 г. № 688-ст

4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО 15118-2:2014 «Дорожные транспортные средства. Интерфейс связи транспортного средства и электросети. Часть 2. Требования к информационной сети и прикладному протоколу» (ISO 15118-2:2014 «Road vehicles — Vehicle-to-Grid Communication Interface — Part 2: Network and application protocol requirements», MOD) путем изменения отдельных фраз. слов, ссыпок, которые выделены в тексте курсивим, а также путем изменения его структуры для приведения в соответствие с правилами, приведенными в ГОСТ 1.5—2001 (пункт 3.12).

Внесение указанных технических отклонений направлено на учет особенностей объекта стандартизации. характерных для Российской Федерации, и целесообразности использования ссылочных национальных стандартов вместо ссылочных международных стандартов.

Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте, приведены в Дополнительном приложении ДА.

Сопоставление структуры настоящего стандарта со структурой примененного в нем международного стандарта приведено в дополнительном приложении ДБ

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N9 162-ФЗ «О стандартизации е Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — е ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано е ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© ISO, 2014 — Все права сохраняются © Стацдартинформ, оформление. 2018

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

Содержание

1 Область применения…………………………………………………………1

2 Нормативные ссылки…………………………………………………………1

3 Термины и определения………………………………………………………..2

4 Обозначения и сокращения……………………………………………………4

5 Понятия………………………………………………………………….5

5.1 Определение сервисов на базе стандарта взаимодействия открытых систем (OSI)………..5

5.2 Структура требований…………………………………………………….5

5.3 Использование RFC-ссылок………………………………………………..5

5.4 Представление, используемое для диаграмм XML-схем……………………………5

6 Обзор документов…………………………………………………………..6

7 Базовые требования к связи V2G………………………………………………..t

7.1 Общая информация………………………………………………………7

7.2 Концепция сервисного примитива уровневой архитектуры OSI……………………….7

7.3 Концепция безопасности…………………………………………………..8

7.4 Состояния связи V2G и работа с каналом данных……………………………….15

7.5 Канальный уровень……………………………………………………..20

7.6 Сетевой уровень………………………………………………………..20

7.7 Транспортный уровень……………………………………………………21

7.8 Коммуникационный протокол V2G…………………………………………..25

7.9 Представительский уровень……………………………………………….28

7.10 Уровень приложения……………………………………………………37

8 Сообщения прикладного уровня……………………………………………….43

8.1 Общая информация и определения………………………………………….43

8.2 Определение подтверждения протокола………………………………………44

8.3 Определение сообщения V2G………………………………………………47

8.4 Определения сеанса связи V2G и элементов тела сообщения………………………49

8.5 Комплексные типы данных………………………………………………..86

8.6 Идентификационные режимы и определения наборов сообщений…………………..119

8.7 Хронирование связи V2G…………………………………………………156

8.8 Задание последовательности сообщений и обработка ошибок……………………..168

8.9 Примеры последовательностей сообщений запрос-ответ…………………………189

Приложение А (справочное) Сводная таблица требований…………………………….197

Приложение В (обязательное) Профили сертификатов……………………………….203

Приложение С (справочное) Применение сертификатов………………………………213

Приложение D (справочное) Шифрование для распределения секретных ключей……………224

Приложение Е (справочное) Обзор XML-подписей…………………………………..226

Приложение F (рекомендуемое) Определения схем………………………………….230

Приложение G (обязательное) Требования к идентификаторам…………………………258

Приложение Н (справочное) Задание последовательности сообщений для пересогласования …. 260 Приложение I (справочное) Привязка имен элементов сообщений ISO 15118 к терминам

SAE J2847/2 …………………………………………………… 264

Приложение J (справочное) Примеры сообщений…………………………………..268

Приложение К (справочное) Привязка элементов случаев использования части 1……………291

Приложение ДА (справочное) Сведения о соответствии ссылочных национальных стандартов

международным стандартам, испольэиванным в качестве ссылочных в примененном международном стандарте……………………………331

Приложение ДБ (справочное) Сопоставление структуры настоящего стандарта со структурой

примененного в нем международного стандарта………………………..332

Библиография……………………………………………………………..333

Введение

Международная организация по стандартизации (ИСО) объединяет национальные организации по стандартизации (комитет — член ИСО). Разработка международных стандартов осуществляется, как правило, техническими комитетами ИСО. Каждый комитет — член ИСО. заинтересованный в участии в проектах по тематике, для которой был создан технический комитет, имеет право быть представленным в этом комитете. Международные правительственные и неправительственные организации, связанные с ИСО. также принимают участие в работе объединения. ИСО непосредственно сотрудничает с Международной электротехнической комиссией (МЭК) по всем вопросам стандартизации электротехнических изделий.

Методики, использованные для разработки настоящего стандарта и для его дальнейшего применения. содержатся в директивах ИСО/МЭК. часть 1. В частности, следует отметить различные критерии. используемые для утверждения разных типов документов ИСО. Настоящий стандарт составлен в соответствии с редакторскими правилами части 2 директив ИСО/МЭК (www.iso.org/directives).

Следует иметь в виду, что некоторые положения настоящего стандарта могут быть объектом патентных прав. ИСО не несет ответственности за идентификацию какого-либо одного или всех патентных прав. Детали любого патентного права, выявленного при разработке стандарта, должны находиться в введении и/или в перечне полученных патентных заявок ИСО (www.iso.org/patents).

Любое оригинальное наименование, используемое в настоящем стандарте, является информацией для удобства пользователей.

Толкование значений специфических терминов ИСО и выражений, относящихся к оценке соответствия. а также информация о строгом соблюдении ИСО принципов Всемирной торговой организации (ВТО) в отношении технических барьеров в торговле (ТБТ) содержатся по URL-адресу: www.iso.org/ foreword.html.

Настоящий стандарт курирует Технический комитет ISO 22 «Дорожные транспортные средства». подкомитет SC 3 «Электрическое и электронное оборудование».

Настоящий стандарт разработан при сотрудничестве с Техническим комитетом МЭК/ТК 69 «Электромобили и грузовые электрокары промышленного назначения».

ИСО 15118 под общим названием «Транспорт дорожный. Интерфейс связи автомобиль — электрическая сеть» состоит из следующих частей:

– часть 1: Общая информация и определение случаев использования;

– часть 2: Требования к протоколу сетевого и прикладного уровней:

– часть 3: Требования к физическому и канальному уровням.

Продолжающийся энергетический кризис, а также необходимость снижения выброса загрязняющих веществ, вызывающих парниковый эффект, заставили производителей предпринять серьезные усилия по снижению энергопотребления выпускаемых транспортных средств. В настоящее время производители заняты разработкой транспортных средств, передвигающихся частично или полностью на электрической тяге. Такие транспортные средства уменьшат зависимость транспорта от ископаемых источников энергии, улучшат глобальную энергоэффективность экономики и сократят выброс в атмосферу двуокиси углерода от дорожного транспорта в случае, если электроэнергия будет получена из возобновляемых источников. Для заряда аккумуляторных батарей, установленных на борту подобных транспортных средств, потребуются специальные инфраструктурные объекты.

Большая часть работы по стандартизации размеров и спецификации электрического оснащения инфраструктурных объектов зарядных станций, а также интерфейсов транспортных средств уже реализована в соответствующих стандартах или группах МЭК. Однако вопрос, касающийся передачи информации от транспортного средства на местный объект и в сеть, пока не проработан на должном уровне.

Связь «автомобиль — электрическая сеты» дает преимущества для оптимизации энергоресурсов сети и системы выработки электроэнергии. Это объясняется возможностью подзаряжать транспортные средства в оптимальный, с точки зрения энергосбережения, промежуток времени. Следует разработать эффективную и удобную систему оплаты. Необходимый канал связи может использоваться в будущем для стабилизации электрической сети, а также для предоставления дополнительных информационных услуг, необходимых для эффективной эксплуатации электромобилей.

ГОСТ Р 58123—2018 (ИСО 15118-2:2014)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ТРАНСПОРТ ДОРОЖНЫЙ Интерфейс связи автомобиль — электрическая сеть

Часть 2

Требования к протоколу сетевого и прикладного уровней Road vehicles. Vehide-to-Grid Communication Interface. Part 2. Network and application protocol requirements

Дата введения —2019—06—01

1 Область применения

Настоящий стандарт определяет связь между аккумуляторными электромобилями (BEV). гибрид* ными автомобилями с подзарядкой от электросети (PHEV) и оборудованием электроснабжения электромобиля (EVSE). Набор команд для приложения, требования к которому устанавливает настоящий стандарт, служит для поддержки передачи энергии от EVSE к электроавтомобилю (EV). ГОСТ Р 58122 (ИСО 15118-1:2013) содержит дополнительные элементы случаев использования (часть 1. идентификаторы элементов случаев использования: F4 и F5), описывающие двунаправленную передачу энергии. Реализация указанных случаев использования требует оптимизации набора команд для приложения, описываемого в настоящем стандарте.

Настоящий стандарт распространяется на сети между EV (BEV или PHEV) и EVSE и устанавливает требования к особенностям обнаружения EV в коммуникационной сети и подключения по интернет-протоколу (IP) между EVCC и SECC (си. рисунок 1).

1 — прмимг иаетоаже ялиещла;

2 — определение сообщений учитывает случаи использования, которые определены для связи между SECC и SA

Рисунок 1 — Коммуникационные отношения между EVCC, SECC и вторичным субъектом

В настоящем стандарте описаны сообщения, модель данных, формат представления данных на базе XML/EXI, использующих протоколы связи V2GTP. безопасности транспортного уровня TLS. управления передачей TCP и IPv6. Также в нем описан доступ к сервисам канального уровня с точки зрения уровня 3. Функциональность канального уровня и физического уровня описана в [1].

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 58122—2018 (ИСО 15118*1:2013) Транспорт дорожный. Интерфейс связи автомобиль — электрическая сеть. Часть 1. Общая информация и определение случаев использования

Издание официальное

ГОСТ Р МЭК 61851-1—2013 Система токопроводящей зарядки электромобилей. Часть 1. Общие требования

ГОСТ Р МЭК 62196*1—2013 Вилки, штепсельные розетки, соединители и вводы для транспортных средств. Кондуктивная зарядка для электромобилей. Часть 1. Общие требования

ГОСТ Р МЭК 62196*2—2013 Вилки, штепсельные розетки, соединители и вводы для транспортных средств. Кондуктивная зарядка для электромобилей. Часть 2. Требования размерной совместимости и взаимозаменяемости для штыревых разъемов и арматуры сети переменного тока

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на хоторый дана датированная осылка. то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения {принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная осылка. внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение. в котором дана ссылка на него, рекомендуется применять е части, на затрагивающей эту осыпку.

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ 58122 (ИСО 15118-1), а также следующие термины с соответствующими определениями:

3.1 базовая зарядка; ВС: Этап зарядки во время сеанса зарядки, управляемый в соответствии с ГОСТ Р МЭК 61851-1.

3.2 предельные параметры зарядки: Набор физических ограничений (например, напряжение, сила тока, энергия, мощность), которые согласуются во время сеанса связи транспортного средства и электросети для сеанса зарядки.

3.3 таймер установления связи: Таймер, отслеживающий время от подключения до сообщения об установлении сеанса.

3.4 сертификат контракта: Сертификат, выдаваемый EVCC либо корневым удостоверяющим органом (СА) коммуникации транспортного средства и электросети или подчиненным удостоверяющим органом (Sub-CA), который используется в XML-подписях на уровне приложения для того, чтобы SECC или вторичный субъект мог проверить контракт, выданный EVCC, и подписи, выданные EVCC.

3.5 состояние линии управления: Состояние EV. передаваемое по линии управления е соответствии с ГОСТ Р МЭК 61851-1.

3.6 удостоверение: Что-либо, обеспечивающее основу для уверенности, доверия, кредита и т. д.

Пример — Сертификаты, пароли, имена пользователя и т. д.

3.7 установление канала связи: Этап установления канала обмена данными.

Примечание 1 — Условие входа: тобой действительный сигнал линии управления 8 соответствии с ГОСТ Р МЭК 61851-1: условие выхода: D-LINK_READY.irxJication{DLINKSTATUS=LinkEstablisbed).

3.8 особые правила кодирования а правило кодирования ASN-1; DER: Метод кодирования объекта данных, например сертификата Х.509. подлежащего подписанию цифровой подписью или проверке подписи.

3.9 глобальный адрес: IP-адрес с неограниченным охватом.

3.10 зарядка со связью по протоколу высокого уровня; HLC-C: Один из этапов зарядки в соответствии с настоящим стандартом.

3.11 локальный адрес канала: IP-адрвс, действующий только для данной линии связи, который может быть использован для доступа к смежным интерфейсам, подключенным к той же линии связи.

3.12 идентификационный режим: Обязательные и факультативные сообщения и параметры для идентификации, относящиеся к сценариям зарядки, которые используют внешние средства идентификации (EIM). и к сценариям зарядки, использующим режим «Plug and Charge» (РпС).

Примечание 1 — Идентификационный режим охватывает набор схожих сценариев зарядки для конкретного средства идентификации.

3.13 IP-адрес: Идентификатор межсетевого уровня для интерфейса или набора интерфейсов.

3.14 максимальная единица передачи; MTU: Максимальный размер (в байтах) наибольшего блока протокольных данных, который канальный уровень может передать.

3.15 набор сообщений: Набор обязательных сообщений при взаимодействии транспортного средства и электросети (V2G) и параметров для EVCC или SECC. охватывающий один или несколько элементов случаев использования.

3.16 таймер сообщений: Таймер, осуществляющий мониторинг пары запрос-ответ.

3.17 сетевой сегмент: Совокупность устройств, которые могут обмениваться данными на канальном уровне непосредственно через канальные адреса.

Пример — Локальная сеть Ethernet: все устройства, которые могут видеть друг друга посредством МАС-адресов.

3.18 узел: Устройство, которое реализует IPv6.

3.19 сертификат изготовителя: Сертификат, выдаваемый EVCC для того, чтобы сертификат контракта мог быть надежно запрошен и получен от вторичного субъекта.

3.20 время исполнения: Нефункциональное временное требование, определяющее время, которое не должно быть превышено объектом V2G при исполнении или обработке определенного задания.

Примечание 1 — Это фиксированное значение времени.

3.21 частная среда: Зона с ограниченным (физическим) доступом для небольшого числа транспортных средств (EV). Данная зона может быть частным парковочным гаражом или гаражом/парковоч-ной стоянкой компании, владеющей собственным парком EV. вместо общественных зарядных станций EVSE могут использоваться один или несколько частных настенных зарядных блоков. Для того чтобы частный настенный зарядный блок был простым и дешевым в производстве и эксплуатации, ему разрешается постоянно оставаться в режиме офлайн. Это позволяет частному настенному зарядному блоку использовать листовые сертификаты с более длительным максимальным сроком действия, чем разрешаемый для публичных зарядных станций, а также использовать личный корневой сертификат, который отличается от корневых сертификатов V2G и который должен быть установлен на каждое EV. Если зарядка EV разрешена в данной конкретной частной зоне, то результатом будет ограничение числа EV. принадлежащих котдельной частной среде. При этом отличие от «надежной среды» заключается в том. что в частной (собственно частной, а не обладающей дополнительной «надежностью») среде TLS. где соответствующее шифрование данных на уровне соединения всегда используется, обработка сертификатов упрощена для частного настенного зарядного модуля (EVSE). поскольку он может находиться в режиме офлайн постоянно, обеспечивая неограниченные сроки действия сертификатов, более короткую длину цепочки сертификатов, исключение OCSP и дополнительного «режима сопряжения».

3.22 идентификационный режим: Группа обязательных и факультативных наборов сообщений, охватывающая набор схожих сценариев зарядки для конкретного средства идентификации.

3.23 пересогласование: Обмен сообщениями для актуализации графика зарядки, согласованного между EV и EVSE во время сеанса связи V2G. путем повторной передачи параметров SASchedule и Charging Profile.

3.24 пара сообщений запрос-ответ: Сообщение-запрос и соответствующее сообщение-ответ.

3.25 последовательность сообщений запрос-ответ: Предопределенная последовательность пар сообщений запрос-ответ.

3.26 клиент SOP: Субъект V2G. который использует сервер SDP, чтобы получить информацию о конфигурации SECC для обеспечения возможности доступа к SECC.

3.27 сервер SDP: Субъект V2G. предоставляющий информацию о конфигурации для доступа к SECC.

3.28 сертификат SECC: Сертификат, выдаваемый SECC либо корневым СА V2G. либо Sub-CA. который используется в TLS для того, чтобы EVCC мог проверить аутентичность SECC.

3.29 таймер последовательности: Таймер, осуществляющий мониторинг последовательности сообщений запрос-ответ.

3.30 Sub-CA: Подчиненный удостоверяющий орган, который выдает сертификаты SECC и/или сертификаты контракта от имени корневого СА V2G.

Примечание 1 — Полномочие на выдачу сертификатов делегируется корневым СА V2G. и он может отозвать сетрификаты Sub-CA в побое время.

3.31 сертификат Sub-CA: Сертификат, выдаваемый органом Sub-CA.

3.32 TCP.DATA: Порт/интерфейс для передачи данных на базе ТСР-соединения.

3.33 тайм-аут: Требование, определяющее время, в течение которого объект V2G осуществляет мониторинг системы связи до наступления определенного события.

Примечание 1 —Если заданное время превышено, соответствующий объект V2G инициирует обработку связанной с этим ошибки. Это фиксированное значение времени.

3.34 таймер: Устройство или элемент программного обеспечения, используемый для измерения времени.

Примечание 1 — В зависимости от конкретного случая использования таймер применяется для запуска определенных системных элементов.

3.35 безопасная зона: Закрытая пользовательская группа (например, участники системы по совместному пользованию транспортными средствами) с некоторым предварительно распределенным средством доступа к зарядному сервису SECC (например, ключ от домашнего гаража, радиочастотный брелок для совместного пользования транспортными средствами), т. е. группа, за которую кто-то отвечает. например владелец гаража, оператор системы совместного пользования транспортными средствами или оператор такси.

3.36 цикл V2G: Этап обмена сообщениями V2G для управления процессом зарядки в соответствии с настоящим стандартом.

3.37 сеанс связи V2G: Ассоциация двух конкретных субъектов V2G для обмена сообщениями V2G.

3.38 субъект V2G: Первичный субъект, участвующий в связи V2G с помощью обязательного или дополнительного коммуникационного протокола, требования к которому установлены в настоящем стандарте

3.39 сообщение V2G: Сообщение, обмен которым происходит на уровне приложения.

Примечание 1 — См. раздел 8 «Сообщения прикладного уровня».

3.40 установление V2G: Этап установления обмена сообщениями V2G.

Примечание 1 — Условие входа: D-LlNK_READY.tndicat>or*{DLINKSTATUS=LinkEstablished); условие выхода: PowerOeiiveryReq с ChargeProgress равен Start или Stop.

3.41 коммуникационный протокол V2G: Коммуникационный протокол для передачи сообщений V2G между двумя субъектами V2GTP.

3.42 субъект V2GTP: Субъект V2G. поддерживающий коммуникационный протокол V2G.

3.43 корневой СА V2G: Удостоверяющий орган (СА), который выдает сертификаты контракта и/или сертификаты SECC либо делегирует полномочие на выдачу таких сертификатов Sub-CA.

3.44 корневой сертификат V2G: Сертификат, выдаваемый корневому СА V2G.

4 Обозначения и сокращения

В настоящем стандарте применены следующие обозначения и сокращения:

BEV — аккумуляторное электрическое транспортное средство;

СА — удостоверяющий орган;

CRL — перечень аннулированных сертификатов:

DH — криптографический протокол Диффи — Хеллмана;

DER — особые правила кодирования;

ECDSA — алгоритм цифровой подписи на основе эллиптических кривых;

EMAIO — идентификатор аккаунта EVEV;

ЕМОСН — центр обработки данных оператора услуг для EV [см. также ГОСТР58122(15118-1:2013)}; EV — электрическое транспортное средство;

EVCC — контроллер связи электрического транспортного средства;

EVSE — оборудование электропитания электрических транспортных средств;

EXI — эффективный XML-обмен;

OCSP — протокол статуса онлайнового сертификата:

OEM — изготовитель транспортных средств;

NACK — отрицательное квитирование;

PDU — блок протокольных данных:

PHEV — подзаряжаемое гибридное электрическое транспортное средство;

PKI — инфраструктура открытых ключей;

PLC — связь по силовой линии электропередачи;

РпС — «Plug and Charge» («Подключай и заряжай»);

SA — вторичный субъект;

SDP — протокол обнаружения SECC;

SOU — блок сервисных данных:

SECC — контроллер связи оборудования электропитания:

TLC — безопасность транспортного уровня;

TCP — протокол управления передачей;

V2G — взаимодействие транспортных средств и электросети;

V2G Ci — интерфейс связи взаимодействия транспортных средств и электросети;

V2GTP — коммуникационный протокол V2G;

UDP — протокол пользовательских дейтаграмм;

XML — extensible Markup Language (расширяемый язык разметки).

5 Понятия

5.1 Определение сервисов на базе стандарта взаимодействия открытых систем (OSI)

Настоящий стандарт базируется на понятиях сервисов OSI (см. [2)) применительно к отдельным уровням, описанным в настоящем стандарте.

Настоящий стандарт описывает требования, применяющиеся к уровням 3—7 в соответствии с уровневой архитектурой OSI.

5.2 Структура требований

В настоящем стандарте используется определенная структура требований, а именно каждое ин* дивидуалькое требование, включенное в настоящий стандарт, идентифицируется уникальным номером. Данная структура требований облегчает отслеживание требований и установление требований к тестовым сценариям. Применяется следующий формат:

«(V2G”Y”-“XXXn» — текст требования, где:

> «V2G» характеризует объект требований настоящего стандарта,

• V идентифицирует номер части настоящего стандарта,

• XXX представляет собой номер индивидуального требования и

– «текст требования» включает фактический текст требования.

Пример — [V2G2-000]— это пример требования.

5.3 Использование RFC-ссылок

При использовании RFC-ссылок все требования «должен/не должен» являются обязательными.

Примечание — Номера требований описаны е приложении А.

(V2G2-001) В настоящем стандарте, если RFC-ссылка была обновлена одним или несколькими RFC, то изменение применяется полностью.

(V2G2-002) Если изменение или часть изменения, применяющаяся к RFC-ссылке, не совместима с исходным RFC или реализацией, описываемой настоящим стандартом, то обновление не действует.

(V2G2-003) Все опубликованные списки ошибок для RFC-ссылок полностью действительны для настоящего стандарта.

5.4 Представление, используемое для диаграмм XML-схем

В настоящем стандарте в качестве формата для описания сообщений V2G используется XML. Подробности относительно обозначений XML-схем. используемых в настоящем стандарте, приведены в руководстве Р).

Для облегчения различения типов определений, используемых в XML-схемах, в настоящем стандарте для имен приняты следующие правила:

– у комплексных типов первые буквы прописные;

– у простых типов первые буквы строчные.

б Обзор документов

На рисунке 2 показаны требования, содержащиеся е настоящем стандарте, ГОСТ Р 58122 (ИСО 15118*1:2013) и[1}. и их распределение в соответствии с уровневой архитектурой OSI.

Полужирными рамками выделены требования, применяющиеся к уровням 3—7 в соответствии с уровневой архитектурой OSI, светлыми рамками — требования уровней 1 и 2. включая стандартизованный интерфейс сервисных примитивов V2G. данные в (1).

/-\

ХМИН»2

Ов)

Ямлынв

К_>

□ —уровни ОЯ и лрмпямьв трнОомыии, опмаиныи в нвствацан етацдотв;

I Ч — урони03 клриимиммвтробоиимя огжакнь»» РОСТР№122(И001W.-JWS? иff} Рисунок 2 — Обзор связи документов V2G

7 Базовые требования к связи V2G

7.1 Общая информация

В настоящем стандарте описана реализация элементов случаев использования V2G. определения которых даны в ГОСТ Р 58122 (ИСО 15118-1:2013).

7.2 Концепция сервисного примитива уровневой архитектуры OSI

7.2.1 Обзор

В данном пункте описана уровневая архитектура OSI. применяемая в настоящем стандарте. Она призвана служить простым средством описания интерфейсов между отдельными уровнями протокола связи, требуемыми настоящим стандартом, а также позволяет более точно определить требования синхронизации.

Требования к сервисам устанавливаются путем описания сервисных примитивов и параметров, характеризующих сервис. Это абстрактное определение сервисов, не требующее конкретной реали* зации.

На рисунке 3 показан упрощенный вид взаимодействия уровней OSI. достаточный для понимания принципов уровневой архитектуры OSI в контексте настоящего стандарта.

Сущность V2G m Сущность V2G m+1

POU — блок протокольных ванных сетевого объекта; PCI — информация управления протоколом:

SOU — блок сервисных ванных сетевого объекта

Рисунок 3 — Принципы уровневой архитектуры OSI

Когда экземпляр пт субъекта V2G уровня i+1 обменивается данными с экземпляром гп+1 субъекта V2G уровня i+1. каждый экземпляр использует сервисы экземпляра уровня i. Сервис определяется как набор сервисных примитивов.

7.2.2 Синтаксис сервисных примитивов

Сервисные примитивы описываются следующим синтаксисом:

(Инициал уровня]-[ИМЯ].[тип примитива}(список параметров), где

• (инициал уровня} один из следующих семи: (Физический, Канальный. Сетевой. Транспортный. Сеансный. Представительский. Приложение}:

– (ИМЯ] есть имя примитива.

Пример— Типичными примерами для поля (ИМЯ] являются СОЕДИНИТЬ. РАЗЪЕДИНИТЬ, ДАННЫЕ. В настоящем стандарте и в [1] используются также другие имена:

■ [тип примитива] один из следующих четырех: (запрос, индикация, ответ, подтверждение];

♦ (список параметров) включает список отделяемых запятой параметров, которые пользователь сервиса должен предоставлять при использовании соответствующего сервисного примитива; факультативные параметры отмечены скобками «[..}».

Примечание — В настояцем стандарте тип примитива «indication» (индикация) всегда указывает на событие асинхронно по отношению к верхнему уровню.

7.3 Концепция безопасности

7.3.1 Потоки вызовов (блок-схемы)

На рисунках 4 и 5 проиллюстрированы примеры связи в полуонлайновом и онлайновом режимах с точки зрения безопасности и показаны необходимые применяемые сервисы безопасности, а также абстрактный вид различных данных, необходимых для работы.

Полные схемы потока данных/последоеательности приведены е подразделе 8.8 настоящего стандарта. На данных обзорных рисунках следует выделять только информацию, относящуюся к безопасности.

Концепция безопасности обеспечивает базовый защитный механизм для осуществления связи в сети таким образом, чтобы предотвратить несанкционированный доступ. Для определенных сценариев требуется применение безопасности транспортного уровня (TLS) для связи между EVCC и SECC. Для некоторых других сценариев использование TLS является факультативным. Конкретные сообщения защищаются на уровне приложения (XML-сообщения). если данные необходимо защитить на пути от вторичного субъекта или к нему или если защита должна существовать дольше, чем существует TLS. Кроме того, концепция не зависит от дополнительных защитных механизмов на уровнях ниже уровня 3 уровневой модели OSI.

На рисунке 4 показан пример использования дежурного соединения для режима РпС.

В режиме идентификации РпС вся связь на базе TCP/IP защищается с помощью аутентифицируемого е одностороннем порядке канала TLS между двумя одноранговыми субъектами (TLS не обязательна для некоторых режимов, кроме режима идентификации РпС).

Конечным пунктом всей связи является SECC. Показания прибора учета периодически подписываются транспортным средством для поддержки процесса расчета (см. 8.4.3.13.1). Эта информация может быть использована для расчета, если местные правила это разрешают. EVSE предоставляет учетные данные о зарядке, содержащие подписанные показания прибора учета для дальнейшей обработки.

Примечание 1 — Связь между SECC и SA на рисунке 4 показана только с целью информации и не служит для установления конкретной последовательности сообщений.

На рисунке 5 показан пример в онлайновой режиме связи для случая использования РлС.

Как и в полуонлайновом режиме, в данном примере в режиме РпС вся связь на базе TCP/IP защищается с помощью аутентифицируемого в одностороннем порядке канала TLS между двумя одноранговыми сущностями (TLS не обязательна для некоторых режимов, кроме режима РпС).

Может потребоваться передача вторичному субъекту для дальнейшей обработки части информации. предоставляемой транспортным средством, например удостоверений транспортного средства, чтобы обеспечить возможность подписания информации о тарифе. EVCC рассчитывает профиль зарядки (см. 8.4.3.9.2) и посылает его SECC. который может направить его системам SA. Дальнейший процесс аналогичен полуонлайновому режиму, за исключением того, что окончательные данные о зарядке могут быть предоставлены SA напрямую. Предполагается, что SECC будут также использовать безопасное транспортное соединение с SA. хотя безопасность связи транспортного средства с SA обеспечивается на прикладном уровне.

Примечание 2 — Связь между SECC и SA на рисунке 5 показана только с цепью информации и не служит для установления конкретной последовательности сообщений.

twee

Нечапо Процессе середке

L

Установке сакм

на

Ф*

Зеб»

втсриюмй субиел ISA)

мый (полу-)

еидейяоеыа овтеои

упоеттерепиами боюпосиести. янрчор ответы 06СР. пергой еииулиревмям а

серпфиаетоа. сертяфмвты

(не ездит а объем иестоааей одеиифмкеиии)

I

1

1

1

1

7

Установи«овне» TLS

(lexMleO

lanwMrtoIl

предеясеение в соответствии

с а. Т.7 J

SwSTSmo

Нтйтлпн

сертификат (VM Дна ироае реи сортифиеето TLS

см оероервУЭв

саряо>м<МгрДсеесо*ее1)

ырсоА«иерет«еес<*п|)

. продвлвевнив в соответствии cc.it

Идентификация. аутеитифмсмамивоторитаиииУ

Необеадем сертнфиат юатрмтас овочом аяепочеоЯ

Pevneni&cceMcaM

т

Намедиие мелея и форчшрпоичю плене

Цикл еонтролн и•

Pav>*«*tOvu<*iMO

AwlhertUlioMeil)

_ продетвкие ■ coereerci СС 84

ими имл»

Неовмчми есриееоа сертнфике* V2O

Т

<—

Оилртц&ИмЯт|)

W 4

и

Опция учета

Нео&юви!

еоитректа с ключом

МстептмаекврМиц)

Зеаерменме процессе аеридси /

■ « п.4.8

… маерцмимо в ооответст

Отпря

■ |галыее

дпяРпС|У’

СГ

(полу) сипим мои» обмен подпиеи«»1ми кветморееи приборе учете яре профиля мрядеи а режиме (ио ресометраммтсж о местоацем стендерте)

ь,

Необседяи яормевой сертифиеет еои треста

Рисунок 4 — Пример связи в полуонлайновом режиме

I I I

Рисунок 5 — Пример связи в онлайновом режиме

Имеются случаи дополнительного использования связей, в которых механизмы безопасности не* обходимы на уровне приложения. Речь идет о начальной регистрации контрактных ключей и сертификата, а также об обновлении сертификата. В этих случаях используются ключи изготовителя для кон* кретного транспортного средства. Обзор всех необходимых сертификатов содержится в приложении В.

7.3.2 Управление сертификатами и ключами

Потоки вызовов, описанные в 7.3.1. требуют наличия нескольких сертификатов, применяемых для разных уровней безопасности. Используют сертификаты SECC, применяемые на уровне TLS для их аутентификации EVCC. сертификаты контрактов, применяемые на уровне приложения для аутентификации SECC и/или вторичного субъекта, корневые сертификаты V2G и сертификаты Sub-CA. которые удостоверяют сертификаты SECC и сертификаты контрактов.

Кроме вышеуказанных сертификатов, могут испогъэоеатъся корневые сертификаты изготовителя и сервисные сертификаты изготовителя, применяемые для установки и обновления сертификатов контрактов.

Обзор всех возможных профилей приведен в приложении В.

[V2G2-004J Каждый субъект V2G должен использовать сертификаты X.509v3 вследствие необхо* ди мости расширений для хранения параметров криптосистемы на основе эллиптиче* ских кривых. Дополнительные сведения см. в [4).

В таблице 1 показано, из каких полей состоит сертификат X.509v3.

Таблица 1 — Базовые поля сертификата

Поле сертификата

Описание

Версия

Версия сертификата (для настоящего стандарта должна быть v3 = 0x2)

Серийный номер

Уникальный номер сертификата (е домене эмитента)

Алгоритм подписи

Используемый алгоритм подписи

Эмитент

Субъект, которьм выпустил и подписал сертификат

Срок действия

Период времени. в течение которого сертификат действителен

Субъект

Субъект, которому выдан сертификат

Открытый ключ

Открытый ключ, соответствующий закрытому ключу

Уникальный идентификатор эмитента

Факультативный уникальный идентификатор эмитента

Уникальный идентификатор субъекта

Факультативный уникальный идентификатор субъекта

Расширения

Дополнительно (см. таблицу 2)

Подпись

Подпись сертификата, генерируемая эмитентом

Примечание 1 — Информацию о полях сертификата см. в/4/.

В зависимости от случая использования сертификата X.509v3 в него может быть включена до* полнительная информация о так называемых расширениях сертификатов. В таблице 2 обобщены рас* пространенные расширения сертификатов.

Таблица 2 — Примеры расширений сертификатов

Расширения

сертификатов

Описание

Применение ключей

Использование соответствующего закрытого ключа (например, цифровая подпись, невозможность отказа, шифрование ключей)

Расширенное применение ключей

Дальнейшее описание применения ключей с использованием идентификаторов объекта. например:

аутентификация сервера (1.3.6.1.5.5.7.3.1), аутентификация клиента (1.3.6.1.5.5.7.3.2).

Примечание — Иногда также кодируются следующие значения:

Netscape SGC (1.3.6.1.4.1.311.10.3.3).

Окончание таблицы 2

Расширения

сертификатов

Описание

Расширенное применение ключей

Microsoft SGC (2.16.840.1.113730.4.1).

SGC расшифровывается как Server Gated Crypto (управляемая сервером криптография) и показывает, что сервер может также использовать криптографию для связи с браузером клиента. Это расширение использовалось во времена строгого криптографического экспортного контроля для обеспечения надлежащей защиты передачи данных финансовым веб-сайтом

Точка рассылки CRL

Место получения списков отозванных сертификатов

OCSP

Место получения ответа OCSP (существует только для сертификатов Sub-CA). См. подробности а (5)

Авторизационная

информация

Дополнительная авторизационная информация

Альтернативное имя субъекта

Альтернативные имена субъекта

Базовое ограничение = СА

При условии, что сертификат является корневым сертификатом V2G или сертификатом Sub-CA

Примечание 2 — Информация об идентификаторах объектов, например 1.3.6.1.5.5.7.3.1, приведена в /б/.

[V2G2-005] Каждый субъект должен поддерживать хэш-функцию SHA-256 (процесс подписания) в соответствии с [7} [для идентификатора в случае использования по ГОСТ Р 58122 (ИСО 15118-1:2013): F1J.

[V2G2-006J Для каждого субъекта V2G процесс подписания должен быть на базе криптографии с использованием эллиптических кривых (эвср256И[представление SECG]) с алгоритмом подписи ECDSA [для идентификатора в случае использования по ГОСТР 58122 (ИСО 15118-1:2013): F1J.

[V2G2-0071 Длина ключа для асимметричной криптографии на основе эллиптических кривых, используемой каждой сущностью V2G. должна быть 256 бит.

(V2G2-885) Все валидации сертификатов должны осуществляться в соответствии с (4). EVCC и SECC могут помещать в кэш результаты валидации сертификатов во время одного сеанса зарядки.

[V2G2-926] Должны поддерживаться расширения сертификатов, указанные в приложении В. Отклонения указаны, где это необходимо.

[V2G2-9251 Листовой сертификат должен рассматриваться как недействительный, если якорь доверия в конце цепочки не соответствует конкретному корневому сертификату, необходимому для определенного использования, или если необходимое значение компонента домена отсутствует.

[V2G2-910] EVCC должен реализовывать механизм проверки сроков действия сертификатов и ответов OCSP.

(V2G2-886) EVCC может выбирать точность своего источника времени по своему усмотрению, но он должен соблюдать выбранную точность при использовании этого источника времени. Точность должна быть по крайней мере равна одному дню.

Примечание 3 — Эго требование теоретически даже позволяет применять точность, например до одного года. Реализующий должен тщательно взвесить последствия в отношении безопасности такого решения.

Примечание 4 — Если соединение TLS успешно установлено. EVCC может использовать время от поля EVSETimeStamp, посылаемое от SECC через указанное соединение, для синхронизации своего внутреннего генератора синхроимпульсов, однако реализующий должен тщательно взвесить последствия в отношении безопасности такого решения.

[V2G2-887] SECC должен обеспечивать наличие для себя в любой момент времени сертификата со сроком действия не менее чем на один час больше.

7.3.3 Число корневых сертификатов и срок их действия, глубина и размер сертификата [V2G2-008} Каждый EVCC должен поддерживать не менее одного корневого сертификата V2G. [V2G2-877J Каждый SECC должен поддерживать хранение не менее чем 10 корневых сертифи-

катов V2G.

Примечание 1 — Ввиду наложения сроков действия могут существовать до 10 одновременно действительных сертификатов (см. (V2G2-012)}.

Примечание 2 — Настоятельно рекомендуется число корневых сертификатов V2G. равное 5. При этом только один является обязательным. Наличие меньше пяти или только одного сертификата связано с риском для изготовителя. Наличие только одного корневого сертификате V2G позволяет осуществлять зарядку транспортного средства только в одном регионе. Изготовитель должен будет указать в руководстве и во время предложения транспортного средства потребителям, что зарядка транспортного средства возможна только в «домашнем» регионе. Если изготовитель опасается, что пяти корневых сертификатов V2G недостаточно для покрытия «радиуса использования» его транспортных средств, он может обеспечтть больше мест хранения корневых сертификатов.

Примечание 3 — Предполагается, что корневые сертификаты V2G. применяемые на уровне 4 OSI. также используются на уровне 7 OS!. Предполагается также, что в Европе будет один удостоверяющий орган для корневых сертификатов, аналогичный доверительному центру, который был создан для EURO5/EU5, что другие регионы мира будут также иметь удостоверяющий орган для корневых сертификатов, охватывающих большее число субъектов. Это позволяет предположить, что пяти корневых сертификатов для пяти регионов мира достаточно. Если будет принято решение о дополнительном пространстве для сертификатов, то это не повлияет на совместимость. Для SECC. однако, является обязательным хранение большего числа сертификатов, поскольку может существовать 10 одновременно действующих корневых сертификатов для каждого региона мира.

(V2G2-009J Ограничение длины пути дерева сертификата PKI должно составлять 3.

Примечание 4 — Ограничение длины пути определяет число несамоподписных сертификатов в пути удостоверения, т. е. имеется до трех уровней сертификатов, производных от корневого сертификата.

[V2G2-0101 Размер сертификата в кодированной по DER форме должен быть не больше 800 байтов. Для передачи все сертификаты должны быть кодированными по DER.

[V2G2-011] Срок действия любых корневых сертификатов V2G должен быть 40 лет.

[V2G2-012] В любой момент времени должен быть в наличии корневой сертификат V2G. действительный для каждого СА корневых сертификатов V2G по крайней мере в течение последующих 35 лет.

Примечание 5 — Пояснения относительно срока действия сертификата, числа корневых сертификатов, глубины и размера сертификата приведены в С.1 (приложение С).

(V2G2-8781 Максимальное число одновременно действительных корневых сертификатов V2G для одного корневого СА никогда не должно быть больше 10.

[V2G2-867} Корень V2G не должен выдавать листовой сертификат.

Примечание 6 — Только Sub-CAмогут выдавать листовые сертификаты.

[V2G2-869J СА или Sub-CA не должен выпускать и подписывать сертификат, который действителен в течение срока действия, который больше, чем срок действия его самого как подписывающего субъекта.

[V2G2-911] Если используется только один уровень Sub-CA. т. е. Sub-CA. подписанный корневым СА. непосредственно подписывает листовые сертификаты, профиль Sub-CA 2 должен действовать для данного Sub-CA.

Следующие требования обеспечивают упрощенную обработку сертификатов в условиях частного пользования. Более подробное пояснение приведено в С.2 (приложение С).

[V2G2-882] Каждый EVCC должен быть способен хранить не менее одного корневого сертификата частного оператора, который должен быть заменяем владельцем транспортного средства.

[V2G2-927] EVCC должен рассматривать хранимые корневые сертификаты частного оператора как якоря доверия для проверки сертификатов SECC.

[V2G2-883] Сроки действия сертификатов SECC. имеющих надежный корневой сертификат частного оператора в качестве их якоря доверия, могут быть выбраны подписывающим сертификат на его усмотрение.

(V2G2-868J Для частной среды органы Sub-CA и ответы OCSP не поддерживаются.

Примечание 7 — Это означает, что корневой сертификат частного оператора напрямую подписывает листовой сертификат.

7.3.4 Поддержка и применение TLS

(V2G2-630J Поддержка TLS обязательна для EVCC для всех идентификационных режимов, кроме идентификационного режима EIM с набором сообщений зарядки переменным током с EIM и набором сообщений зарядки постоянным током с EIM. исключая в обоих слу-чаях набор сообщений дополнительных услуг (ДУ). как указано в 8.6.

(V2G2-631) Поддержка TLS обязательна для SECC для всех идентификационных режимов, кроме идентификационного режима EIM в безопасной среде с набором сообщений зарядки переменным током с EIM и набором сообщений зарядки постоянным током с EIM. исключая в обоих случаях набор сообщений ДУ. как указано в 8.6.

На базе установления TCP или TLS на транспортном уровне действуют следующие ограничения: [V2G2-632] Если используется сеанс связи без TLS, SECC должен только обеспечивать идентификационный режим EIM и наборы сообщений зарядки переменным током с EIM или зарядки постоянным током с EIM. указав «ExtemalPayment» в параметре

PaymentOptionList сообщения ServiceDiscoveryRes. как указано в 8.4.3.3.3.

[V2G2-6331 Если используется сеанс связи без TLS. EVCC должен принимать только идентификационный режим EIM с наборами сообщений зарядки переменным током с EIM или зарядки постоянным током с EIM независимо от предложения SECC также других идентификационных режимов и наборов сообщений.

[V2G2-634] Если используется ованс связи без TLS. SECC не должен выдавать наборы сообщений РпС. [V2G2-635] Если используется сеанс связи без TLS. EVCC не должен применять наборы сообще

ний РпС.

[V2G2-636) Если используется сеанс связи без TLS. SECC не должен выдавать набор сообщений ДУ. (V2G2-637) Если используется сеанс связи без TLS. EVCC не должен применять набор сообщений ДУ. [V2G2-638] Меры безопасности для дополнительных услуг, разрешаемых набором сообщений ДУ

(предлагаемых в ServiceDiscoveryRes), не рассматриваются в настоящем стандарте.

[V2G2-639] Если TLS не применяется, обе стороны должны обеспечить невозможность изменения в текущем сеансе зарядки идентификационного режима EIM на другой идентификационный режим и изменения набора сообщений зарядки переменным током с EIM или набора сообщений постоянным током с EIM на другой набор сообщений (чтобы избежать снижения безопасности сеанса в результате изменений).

[V2G2-640) Если применяется TLS. обе стороны должны обеспечить, чтобы выключение TLS приводило к завершению сеанса зарядки (чтобы избежать снижения безопасности сеанса в результате изменений).

Поддержка, использование и ограничения TLS приведены в таблицах 3 и 4.

Таблица 3 — Поддержка TLS для идентификационных режимов EIM

Друган среда (небезопасная)

Безопасная среда*

Разрешенные наборы сообщений4

Постоянный токе EIM

Переменный ток

с EIM

Постоянный ток с EIM, ДУ

Переменный ток с£»М. ДУ

Постоянный токе EIM

Переменный ток е EIM

Постоянный

tokcEIM.

ДУ

Переменный ток с Е1М.ДУ

EVCC

Поддержка

TLS

Факульта

тивно

Факульта

тивно

Обязатель

но

Обязатель

но

Факульта

тивно

Факульта

тивно

Обяза

тельно

Обяза

тельно

SECC

Поддержка

TLS

Обяза

тельно

Обяза

тельно

Обяза

тельно

Обяза

тельно

Факульта

тивно

Факульта

тивно

Обяза

тельно

Обяза

тельно

Согла

сование

использования TLS с помощью SOP*

EV решает. EVSE должно принять решение EV

EV решает. EVSE должно принять решение EV

EV должно использовать

TLS. EVSE должно отклонить, если EV не использует TLS

EV должно использовать

TLS,EVSE должно

отклонить, если EV не испогьзует TLS

См.

таблицу 4

См.

таблицу 4

EV должно использовать

TLS. EVSE должно отклонить, если EV не использует TLS

EV должно использовать

TLS. EVSE должно отклонить, если EV не использует TLS

Окончание таблицы 3

а Относится к сообщениям, описанным в настоящем стандарте. В случае ДУ. конечно, возможны другие соединения (которые, не входят в настоящий стандарт).

й Отклонение означает прекращение коммуникации. с См. определение в (1}.

Примечание 1 — Отсутствие поддержки TLS SECC может привести в общем случав к прекращению сеанса зарядки конкретных EV. поскольку за одобрение сеансов без TLS отвечает EV.

Таблица 4 — Подтверждение SDP при зарядке переменным и постоянным током с идентификационным режимом Е1М в безопасной среде

Поддержка TLS EVCC

Поддержка TLS SECC

Запрос SOP EVCC

Отеет SDP or SECC

EVCC имеет поддержку TLS

SECC имеет поддержку TLS

EVCC дает сигнал TLS

SECC должен ответить TLS

EVCC дает сигнал TCP

SECC должен ответить TCP

SECC не имеет поддержки TLS

EVCC дает сигнал TLS

SECC может показать, что он не поддерживает TLS. показав «0x10 = нет безопасности транспортного уровня» в его ответе SDP. EV может принять решение о своем желании установить TCP без TLS или прекратить установление связи

EVCC дает сигнал TCP

SECC должен ответить TCP

EVCC не имеет поддержки TLS

SECC имеет поддержку TLS

EVCC дает сигнал TCP

SECC должен ответить TCP

SECC не имеет поддержки TLS

EVCC дает сигнал TCP

SECC должен ответить TCP

Примечание 2 — Для набора сообщений кЕ1М АС» («зарядка переменным током с Е1М») и «Е1М ОС» («зарядка постоянным током с Е1М») EV отвечает за решение о неиспользовании TLS и принятие риска небезопасного соединения.

Примечание 3 — Если применяется TLS. то она всегда используется с односторонней аутентификацией (со стороны EVSE). Если TLS не применяется, аутентификация EV со стороны EVSE, а также дополнительная защита канала связи на транспортном уровне отсутствуют.

Примечание 4 — Меры в отношении каких-либо связанных с функциональной безопасностью рисков вследствие перенапряжений и перегрузок по току (случайных или преднамеренных) должны приниматься путем реализации соответствующих стандартов эпектробеэопасности (например. ГОСТ Р МЭК 61851-1. (8), (9).{10[).

Меры в отношении каких-либо связанных с функциональной безопасностью рисхов вследствие перенапряжений и перегрузок по току должны приниматься в соответствии с перечисленными ниже требованиями:

[V2G2-643] EVSE должно поддерживать меры безопасности, описанные в ГОСТ РМЭК 61851-1 и [8].

для защиты от перенапряжений и перегрузок по току при использовании идентификационного режима EIM для зарядки переменным током.

[V2G2-644] EVSE должно поддерживать меры безопасности, описанные в ГОСТ РМЭК61851-1 и [9].

для защиты от перенапряжений и перегрузок по току при использовании идентификационного режима EIM для зарядки постоянным током.

7.4 Состояния связи V2G и работа с каналом данных

Обмен сообщениями V2G на уровне приложения требует установления протоколов нижнего уровня для обеспечения обмена сообщениями V2G между EVCC и SECC. В настоящем стандарте рассматриваются упомянутые выше протоколы канального уровня. Канальный уровень описан в [1].

В данном подразделе описываются базовые требования для установления связи на уровне выше канального уровня. Настоящий стандарт не описывает какую-либо их реализацию. На рисунках данного подраздела показана только базовая последовательность для управления протокольным пакетом.

Значения таймеров, тайм-аута и времени исполнения, используемые в данном подразделе, описаны в 8.8. На рисунке 6 показан обзор коммуникационных состояний EVCC. К EVCC применяются следующие требования:

(V2G2-014) После установления соединения на канальном уровне {D-LINK_READY.

indication(DLINKSTATUS=Link established) EVCC должен инициировать механизм присваивания IP-адресов, как указано в 7.6.3.2 и 7.6.3.3.

[V2G2-016) EVCC должен отработать механизм присваивания IP-адресов, как указано в 7.6.3.2 и 7.6.3.3.

[V2G2-017J EVCC должен остановить механизм присваивания IP-адресов, как указано в 7.6.3.2 и 7.6.3.3. когда V2G_EVCC_CommunicationSetup_Timer равен или больше V2G_EVCC_ CommunicationSetup_Timeout.

[V2G2-018J После присвоения локального IP-адреса канала EVCC должен начать процесс обнаружения адреса SECC. как указано в 7.10.1.

(V2G2-019) EVCC должен запустить клиента SDP в соответствии с 7.10.1.

[V2G2-645] 8 зависимости от протокола безопасности и транспортного протокола, запрошенно

го в сообщении-запросе SDP. ожидаемого протокола безопасности и транспортного протокола, отправленного сервером SOP. EV должно принять решение о применении TLS.

[V2G2-020] EVCC должен остановить SDP. когда V2G_EVCC_CommunicationSetup_Timer равен или больше V2G_EVCC_CommunicaUonSetup_Timeout.

[V2G2-021] Если EV принимает решение о применении соединения с обеспечением безопасности. EVCC должен установить соединение TLS с SECC. как описано в 7.7.3. после обнаружения IP-адреса SECC. порта, имеющихся транспортного протокола и опций безопасности.

[V2G2-646] Если EV принимает решение о применении соединения без обеспечения безопасности. EVCC должен установить подключение TCP к SECC. как описано в 7.7.1, после обнаружения IP-адреса SECC. порта, имеющихся транспортного протокола и опций безопасности.

[V2G2-022] В зависимости от [V2G2-021] и (V2G2-646] EVCC должен попытаться установить соединение с TLS или TCP в соответствии с 7.7.3.

[V2G2-023] EVCC должен прекратить попытки установить соединение с TLS или TCP. когда V2G__EVCC_Communicat»onSetup_Timer равен или больше V2G_EVCC_ CommunicationSetup_Timeout.

[V2G2-024] После установления соединения с TLS или TCP EVCC должен инициировать сеанс связи V2G. как описано в разделе 8.

[V2G2-025] EVCC должен прекратить соединение с TLS или TCP после остановки сеанса связи V2G.

(V2G2-717) Если EVCC отправил сообщение SessionStopReq с параметром Charging Session, равным «Terminate», он должен прекратить Data-Link {D-LINK_TERMINATE.request0) после получения сообщения SessionStopRes.

[V2G2-718J Если EVCC отправил сообщение SessionStopReq с параметром ChargingSession. равным «Pause», он должен сделать паузу Data-Link (D-LINK_PAUSE.request()} после получения сообщения SessionStopRes и продолжить выполнение [V2G2-014).

[V2G2-719J Каждый раз. когда EVCC получает указание на отсутствие канала обмена данными (D-LINK_READY.indication (DLINKSTATUS=No link), он должен продолжить выполнение (V2G2-014].

[V2G2-720] Если EVCC определяет какую-либо ошибку, он должен указать на ошибку канала обмена данными (D-LINK_ERROR.request()) и продолжить выполнение (V2G2-014)

На рисунке 7 показан обзор состояний SECC во время сеанса коммуникации V2G.

К SECC применяются следующие требования:

[V2G2-721] После указания на успешное установление канала обмена данными (D-LINK_READY.

indication(DLINKSTATUS=Link established) SECC должен инициировать механизм присваивания адресов.

(V2G2-O26) SECC должен сконфигурировать IP-адрес (статический или динамический) с помощью любого надлежащего механизма.

Примечание 1 — Описание присвоения адреса SECC для его интеграции в различные коммуникационные инфраструктуры не рассматривается в настоящем стандарте. Это позволяет оператору самому назначить надлежащий механизм. Например, оператор может выбрать любой существующий механизм, дающий действительный IP-адрес. как. например, статический IP. или механизм, описанный е 7.6.3.2 и 7.6.3.3.

Примечание 2 — SECC должен быть сконфигурирован с действительным IP-адресом для обеспечения соединения с EVCC. Механизм присвоения IP-адресов для SECC не влияет на совместимость. В настоящем стандарте он не рассматривается.

(V2G2-027) После присвоения IP-адреса SECC допжен запустить сервер SDP. как указано в 7.10.1.

Примечание 3 — Не требуется, чтобы сервис обнаружения SECC реализовывался непосредственно в SECC. Возможно также наличие отдельного устройства, обеспечивающего сервис обнаружения SECC.

[V2G2-723] SECC должен остановить сервер SDP. когда SECC_CommunicabonSetup_Timer равен или больше V2G_SECC _CommunicaUonSetup_Performance_Time.

[V2G2-029] SECC должен остановить механизм присваивания IP-адресов, когда V2G_SECC_ CommunicationSetup_Timer равен или больше V2G_SECC_CommunicationSetup_ Performance_Time.

[V2G2-030] После того как сервер SDP успешно запущен, SECC должен ожидать инициализации соединения с TLS или TCP в зависимости сообщения-ответа SDP, как указано в 7.10.1.5.

[V2G2-031J SECC должен ожидать установления соединения с TLS или TCP.

[V2G2-032] SECC должен прекратить ожидание установления соединения cTLS, когда V2G_SECC_

CommunicationSetup_Timer равен или больше V2G_SECC_CommunicationSetup_ Performance/Time.

[V2G2-033) После установления соединения с TLS или TCP SECC должен ожидать инициализации сеанса связи V2G. как описано в разделе 8.

[V2G2-722J Если (V2G2-033] применимо, SECC может остановить сервер SDP после успешного установления соединения с TLS или TCP.

[V2G2-034] SECC должен прекратить соединение с TLS или TCP после остановки сеанса связи V2G.

[V2G2-724] Если SECC получил сообщение SessionStopReq с параметром ChargingSession.

равным «Terminate», он должен прекратить работу с каналом обмена данными (D-LINK_TERMINATE.request()} после отправления сообщения SessionStopRes.

[V2G2-725] Если SECC получил сообщение SessionStopReq с параметром ChargingSession.

равным «Pause», он должен сделать паузу в работе с каналом обмена данными (D-LINK_PAUSE.request()) после отправления сообщения SessionStopRes и продолжить выполнение [V2G2-721].

(V2G2-726) Каждый раз. когда SECC получает указание на отсутствие канала обмена данными (D-LINK_READY.indication (DLINKSTATUS=No link), он продолжает выполнение (V2G2-721],

[V2G2-727] Если SECC определяет какую-либо ошибку, он должен указать на ошибку канала обмена данными (D-LINK_ERROR.request()}H продолжить выполнение (V2G2-721).

7.5 Канальный уровень

Канальный уровень поддерживает транспорт пакетов IP. В ^/описаны необходимые дополнительные сведения о канальном уровне.

[V2G2-0351 Если EVCC осуществляет связь через PLC. EVCC должен соответствовать [1]. [V2G2-O36J Если SECC осуществляет связь через PLC. SECC должен соответствовать [1].

7.6 Сетевой уровень

7.6.1 Общие положения

Протокол, описанный в настоящем стандарте, базируется на интернет-протоколе, известном как IPv6 (см. [11]).

7.6.2 Применимые нормы RFC, ограничения и настройки параметров протокола

7.6.2.1 IPv6

[V2G2-037] Субъект V2G должен поддерживать IPv6 в соответствии с [11].

(V2G2-038J Хотя [11] описывает IPsec как обязательный, от субъекта V2G не требуется реализа

ция IPsec.

[V2G2-039] Ни от какого субъекта V2G не требуется реализации заголовка маршрутизации RH0. как указано в [12].

Примечание 1 — Указания по назначению для поля типа маршрутизации в заголовке маршрутизации IPv6 даны в [13]. Рекомендуется придерживаться этих указаний.

[V2G2-040] Субъект V2G должен реализовывать определение MTU в соответствии с [14). (V2G2-0411 Субъект V2G должен поддерживать обработку наложений фрагментов IP в соответ

ствии с [15).

Примечание 2 — Субъект V2G должен соответствовать спецификации [16]. которая дополняет специфи-кацюо в соответствии с [11].

(V2G2-042) При отправлении пакета IPv6 от EVCC к SECC или от SECC к EVCC 1Р-фрагментация не должна использоваться.

Примечание 3 — Связь между EVCC и вторичными субъектами не рассматривается в настоящем стандарте. Она может использовать или не использовать 1Р-фрагментацию.

7.6.2.2 Протокол динамического управления хостами (DHCPV6)

Требования к каналу обмена данными описаны в [1]. EVCC начинает присвоение адресов, запускаемое каналом обмена данными, когда канальное соединение установлено. Это выполняется в соответствии с 7.6.3.2 с использованием SLAAC. которое является обязательным в соответствии с настоящим стандартом. DHCPv6 может быть реализован как факультативный метод конфигурирования IP.

[V2G2-043] Если EVCC решает ввести в действие клиента DMCPv6. то он должен осуществлять это. как описано в [17].

[V2G2-044] Если инфраструктура, к которой подключено EV (EVSE). решает реализовать сервер DHCPv6. то она должна осуществлять это. как описано в [17].

7.6.2.3 Обнаружение соседних объектов (ОСО)

EVCC использует автоконфигурирование адресов без состояния для IPv6, чтобы генерировать адреса для его интерфейса. Все интерфейсы имеют локальный адрес канала. Для обеспечения уникальности адресов и для поддержки глобальных адресов используется протокол обнаружения соседних объектов.

[V2G2-045J EVCC должен реализовывать обнаружение соседних объектов в соответствии с [13].

(V2G2-046) EVCC должен соответствовать [19]. допуская присвоение IP-адресов до завершения определения адресов-дубликатов.

7.6.2.4 Протокол управления сообщениями в сети Интернет (ICMP)

Протокол управления сообщениями в сети Интернет (ICMP) используется для отправки сообщений об ошибках (например, запрашиваемый сервис отсутствует, хост не доступен и т. д.).

[V2G2-047] Каждый субъект V2G должен реализовывать ICMPv6. как описано в [20].

[V2G2-049] Каждый субъект V2G должен реализовывать нормы RFC. на которые даются ссылки в колонке «Ссылка* таблицы 5. описывающей детали реализации для соответствующих типов сообщений ICMP.

Таблица 5 — Обязательный набор сообщений протокола управления сообщениями в сети Интернет (ICMP)

Тип сообщения 1CMP

Имя сообщения ICMP

Ссылка

1

Пункт назначения недостижим

(20}

2

Пакет слишком велик

{20}

3

Превышено время

(20}

4

Проблема параметра

(20}

128

Эхо запроса

{20}

129

Эхо ответа

(20}

133

Запрос маршрутизатора

(18}

134

Объявление маршрутизатора

(18}

135

Запрос соседнего объекта

(18}

136

Объявление соседнего объекта

(18}

137

Перенаправление сообщения

(18}

141

Обратное сообщение с запросом об обнаружении соседнего объекта

(21}

142

Обратное сообщение с объявлением об обнаружении соседнего объекта

(21}

7.6.3 IP-адресация

7.6.3.1 Общие положения

В настоящем пункте описывается, как EVCC получает действительные IP-адреса для связи по сети на базе IP. Следующие адреса учитываются в настоящем стандарте:

– локальный IP-адрес канала EVCC:

– глобальный IP-адрес EVCC. если маршрутизатор присутствует в локальном канале;

– IP-адрес SECC.

Примечание — Хост IPv6 может иметь несколько IP-адресов, присвоенных одному физическому интерфейсу сети, например локальный адрес канала и глобальный адрес.

7.6.3.2 Автоконфигурирование адресов без состояния (SLAAC)

[V2G2-050J Каждый субъект V2G должен поддерживать конфигурацию индивидуального локального адреса канала IPv6, как указано в (22}.

[V2G2-051} Идентификатор интерфейса локального адреса канала субъекта V2G должен генерироваться из его 48-битового МАС-идентификатора IEEE в соответствии с [22}.

[V2G2-052] EVCC должен поддерживать автоконфигурирование адресов IP6. как описано в [23}. (V2G2-053) Если SECC выдает наборы сообщений установки сертификатов, обновления серти

фикатов или дополнительные услуги, как указано в 8.6.2. он должен поддерживать варианты объявления маршрутизатора IPv6 в соответствии с (24} для предоставления адреса сервера DNS.

7.6.3.3 Выбор адресов

[V2G2-054] Если поддерживаются несколько адресов IPv6, выбор адресов IPv6 по умолчанию должен выполняться в соответствии с {25}.

7.7 Транспортный уровень

7.7.1 Протокол управления передачей (TCP)

7.7.1.1 Обзор

Протокол управления передачей (TCP) позволяет приложениям субъектов V2G устанавливать надежное соединение для обмена данными с другими субъектами. Для надежного обмена и передачи данных от отправителя к получателю TCP дополнительно обеспечивает управление потоками и управление в условиях перегрузки, а также обеспечивает различные алгоритмы для осуществления контроля над перегрузкой и влиянием потоков.

7.7.1.2 Применимые RFC. ограничения и настройки параметров протокола (TCP)

(V2G2-055) Каждый субъект V2G должен осуществлять реализацию TCP, как указано в /26/.

7.7.1.3 Требования к производительности TCP и контрольной сумме

Следующие требования определяют подробности реализации TCP в отношении управления в условиях перегрузки, повторной передачи, хронирования, исходного размера окна и селективного подтверждения в целях улучшения эффективности работы TCP.

Рекомендуется использовать следующие алгоритмы повторной передачи дополнительно к стандартным методам TCP и управления в условиях перегрузки:

[V2G2-O57J Каждый субъект V2G должен реализовывать управление TCP в условиях перегрузки в соответствии с /27/.

[V2G2-058J Каждый субъект V2G должен реализовывать модификацию NewReno к алгоритму быстрого восстановления TCP в соответствии с /28/.

(V2G2-059) Каждый субъект V2G должен рассчитать для TCP таймер повторной передачи в соответствии с [29].

(V2G2-060] Для увеличения производительности TCP каждый субъект V2G должен реализовывать расширения TCP для повышения производительности в соответствии с /30/.

(V2G2-061] Каждый субъект V2G должен поддерживать опции избирательного подтверждения TCP в соответствии с /31/.

[V2G2-062) Каждый субъект V2G должен реализовывать опцию пользовательского тайм-аута в соответствии с [32].

[V2G2-063} Указатель срочности для TCP не должен использоваться каким-либо субъектом V2G.

Рекомендуется использовать следующий алгоритм контрольной суммы:

(V2G2-064) Поля контрольной суммы, требующиеся в заголовках TCP, должны реализовываться в соответствии с /33/.

7.7.2 Протокол пользовательских дейтаграмм (UDP)

7.7.2.1 Обзор

Протокол пользовательских дейтаграмм (UDP) является протоколом без установления соединения. UDP не обеспечивает надежность и гарантии упорядочения, которые обеспечивает TCP. Пакеты могут приходить неупорядоченно или могут быть потеряны без уведомления отправителя или получателя. Однако UDP быстрее и более эффективен для многих легких или чувствительных ко времени задач. UDP находится на транспортном уровне модели уровнееой архитектуры OSI.

Случаи использования UDP с механизмами безопасности описаны в ГОСТ Р 58122 (ИС015118-1:2013) (приложение В).

7.7.2.2 Применимые RFC. ограничения и настройки параметров протокола

(V2G2-065) Каждый субъект V2G должен осуществлять реализацию протокола пользовательских дейтаграмм в соответствии с /34/.

7.7.3 Безопасность транспортного уровня (TLS)

7.7.3.1 Обзор

Безопасность транспортного уровня обеспечивается путем применения TLS. Это позволяет установить аутентифицированный и криптографически защищенный (обеспечивающий защиту целостности и конфиденциальности) канал между EVCC и SECC. TLS обеспечивает одностороннюю или взаимную аутентификацию. Для данного подраздела настоящего стандарта было согласовано использование односторонней аутентификации (EVCC аутентифицирует SECC).

7.7.3.2 Применимые RFC

[V2G2-067] Односторонняя аутентификация с TLS версии 1.2 в соответствии с /35/ с расширениями в соответствии с /36/должна поддерживаться каждым субъектом V2G. EVCC аутентифицирует SECC путем проверки цепочки сертификатов SECC, передаваемой от SECC к EVCC.

EVCC аутентифицирует SECC в соответствии с [V2G2-067], что может быть также использовано для защиты циклического считывания показаний прибора учета между SECC и EVCC. Применение TLS с односторонней аутентификацией исключает необходимость дополнительной цифровой подписи показаний прибора со стороны SECC благодаря осуществлению безопасного сеанса.

Примечание 1 — В случав оплаты на SECC цикгычвское считывание показаний прибора учета на SECC прекращается и их не требуется посылать третьей стороне. Таким образом, отсутствует необходимость в последующей подписи данных, относящихся к расчету.

Применение односторонней аутентификации запрещает SECC проверять корректность EVCC. Поэтому SECC не может определить, является ли связывающийся EVCC аутентичным. Проверка кор* ректности EVCC может быть реализована на уровне приложения, как описано в 7.9.2.

7.7.3.3 Применение безопасности транспортного уровня

[V2G2-068} SECC должен всегда действовать как компонент сервера TLS.

[V2G2-070} Каждый EVCC должен проверять действительность сертификатов Sub-CA (в цепочке сертификатов SECC) через ответ OCSP в соответствии с /5/. когда используется TLS. Запросы OCSP должны транспортироваться как часть подтверждения TLS с использованием расширения, указанного в (37].

Примечание 1 — Не предусматривается, что EVCC запрашивает ответ OCSP для листового сертификата SECC во время подтверждения TLS.

«Режим сопряжения» поддерживает простое управление сертификатами в частной среде [см. С.2 (приложение С)].

[V2G2-870] «Режим сопряжения» EV может быть установлен с помощью фирменного механизма изготовителя. Данный «режим сопряжения» должен активироваться только определенным взаимодействием пользователя. Данный режим должен автоматически сбрасываться через 120 с.

Примечание 2 — «Режим сопряжения» может быть повторно активирован в любое время.

Примечание 3 — Изготовителю предлагается пояснить использование и риски «режима сопряжения», например, в руководстве пользователя.

[V2G2-649] SECC должен обновлять (помещать в кэш) ответ OCSP не реже чем раз в неделю.

Одним из решений для обновления может быть, например, онлайновое соединение.

[V2G2-876J Срок действия ответа OCSP для Sub-CA 1 и Sub-CA 2 должен быть не дольше четырех недель.

Примечание 4 — Это увязывается со сроком действия листового сертификата SECC.

[V2G2-650] Хотя срок действия на EVCC не является обязательным. EVCC должен реализовывать механизм исключения устаревших сертификатов от SECC.

Примечание 5 — Обработка ошибок не рассматривается в настоящем стандарте. Обработка таких ошибок осуществляется по усмотрению изготовителя.

[V2G2-651] EVCC должен отправить список корневых сертификатов V2G. которые он имеет, расширение типа *trusted_ca_keys» в (расширенном) приветствии клиента в соответствии с [36].

[V2G2-871] Если SECC развернут в среде, которая не является частной средой, он должен отправить свой собственный сертификат и цепочку до корня (исключая сам корневой сертификат), который должен быть одним из тех корней, на которые ранее указал EVCC как на присутствующие в EVCC. Если EVCC запросил ответы OCSP для каждого сертификата, которому сервер TLS отвечает, ответ OCSP должен быть отправлен EVCC в соответствии с /5/(пункт 4.2.1). SECC должен также направить сертификат отвечающего OCSP. если он не использует расширение в соответствии с [37]. Ответчик OCSP должен заполнить поле «certs* в структуре ответа OCSP (BasicOCSPResponse) соответствующим Sub-CA.

Примечание 6 — Ответчиком OCSP может быть сам Sub-CA или субъект, который непосредственно подписывается соответствующим Sub-CAc помощью пары ключей со специальным флагом расширенного использования ключа в сертификате.

[V2G2-923] Если SECC не может предоставить сертификат с цепочкой до одного из корней. на который указывал EVCC как на присутствующий в EVCC. SECC должен представить в составе подтверждения TLS действительный сертификат, включая цепочку до корневого сертификата (сам корневой сертификат не должен передаваться).

(V2G2-924] Если SECC выдал цепочку сертификатов, которая не прослеживается до корневого сертификата в списке надежных сертификатов. EVCC должен принять такой сертификат. только если он выполнил успешную валидацию цепочки сертификатов с помо-

щью механизма внешней валидации (например, протокол валидации сертификатов на базе сервера, простой протокол валидации сертификатов SCVP). Если валидация с помощью такого сервиса не выполняется, дает отрицательный результат или не удается (например, вследствие отсутствия соединения). EVCC должен рассматривать цепочку сертификатов как не прошедшую валидацию.

[V2G2-872] Если SECC развернут в частной среде, то он не должен отправлять ответ OCSP. а должен включить свой собственный частный корневой сертификат в цепочку сертификатов. которую он посылает.

Примечание 7 — Это поддерживает «режим сопряжения».

[V2G2-873] Если EVCC запросил ответ OCSP через «client hello» TLS и сервер TLS не отправил ответы OCSP в «server hello», EVCC должен выполнить следующее:

– если цепочка сертификатов сервера TLS содержит только один листовой сертификат и один корневой сертификат, который является одним из корневых сертификатов, который EV сохранил как частный корень. EVCC игнорирует тот факт, что сервер не отправил ответы OCSP:

– если цепочка сертификатов сервера TLS привязана к корню V2G. EVCC должен прервать соединение TLS.

[V2G2-874J Если режим сопряжения активирован. EVCC получает новый корневой сертификат от SECC во время подтверждения TLS и новый корневой сертификат выполняет требования для частного корневого сертификата (см. приложение В), то EVCC должен принять новый корневой сертификат, хранить его постоянно и обращаться с ним как с частным корневым сертификатом.

[V2G2-875] EVCC должен проверить сертификат SECC. полную цепочку сертификатов и все ответы OCSP (если применимо, включая действительность ответчика OCSP). EVCC должен также проверить, что сертификат SECC имеет компонент домена, установленный на «СРО». Если результат хотя бы одной из этих проверок будет отрицательным. EVCC должен прекратить процесс установления TLS и применить (V2G2-023).

[V2G2-810] SECC должен поддерживать согласование максимальной длины фрагмента в соответствии с [36].

[V2G2-811] SECC должен быть способен поддерживать максимальную длину фрагмента 2* байта, но не быть ограниченным этим числом, в соответствии с /36/.

7.7.3.4 Удостоверения транспортного уровня и наборы шифров безопасности

Для безопасности транспортного уровня EVCC аутентифицирует SECC с использованием серти

фиката SECC. Это достигается вследствие наличия у SECC закрытого ключа, который соответствует сертификату SECC, наличия у EVCC корневого сертификата V2G и проверки цепочки сертификатов от корневого сертификата V2G до сертификата SECC. Проверка действительности сертификата Sub-CA в цепочке сертификатов осуществляется через ответ OCSP. получаемый во время подтверждения TLS (подробности см. в /36/). Механизмы отзыва сертификатов SECC не требуются, но вместо этого требуются краткосрочные сертификаты.

SECC неизвестно, какой корневой сертификат V2G имеет EVCC из 10 действительных в настоящее время корневых сертификатов V2G для одного региона. Отсюда наличие 50 действительных в настоящее время корневых сертификатов V2G для всего мира. Поэтому необходимо, чтобы EVCC предоставил список корневых сертификатов V2G. которые он имеет, посредством подтверждения TLS. SECC выдает цепочку своего собственного сертификата SECC. корневой сертификат которого передается EVCC вместе с ответом OCSP для сертификатов Sub-CA в цепочке. Настоятельно рекомендуется обновлять ответ OCSP не реже чем раз в неделю.

Сообщение, передаваемое между EVCC и SECC. шифруется с помощью симметричного ключа (одностороннее согласование ключа), согласуемого во время этапа согласования ключа TLS. Поэтому сообщение не будет перехвачено, и EVCC и SECC могут быть уверены, что в течение сеанса партнер на самом деле тот же самый. (Перехвата сеанса не может быть.)

(V2G2-071) Каждый субъект V2G должен предоставлять удостоверения и информацию о безопасности. указанную в таблице 6. если используется TLS.

Таблица 6 — Аутентификация TLS

Аутентификация TLS

Требования к EVCC

Требования к SECC

Односторонняя (сторона сервера)

Наличие корневых сертификатов для проверки аутентичности сертификата SECC.

Функциональная поддержка обработки запросоа/ответов OCSP для проверки состояния валидации сертификата SECC во время подтверждения TLS

Ответ SECC е виде сертификата и соответствующего закрытого ключа OCSP для предоставления информации о состоянии валидации собственного сертификата SECC.

SECC должен помещать в кэш и сохранять внутри ответы OCSP для собственной цепочки сертификатов Sub-CA регулярно (не реже чем еженедельно)

[V2G2-602] SECC должен поддерживать все наборы шифров, указанные в таблице 7. если ис-пользуется TLS.

[V2G2-6031 EVCC должен поддерживать не менее одного набора шифров, указанного в таблице 7. если используется TLS.

Дополнительные наборы шифров могут поддерживаться любым субъектом V2G.

Примечание — Изготовитель может принять решение о наборе шифра, поддерживаемом EVCC. на основе предлагаемых в таблице 7. Одного набора достаточно для компактных реализаций. Для функциональной совместимости SECC должен поддерживать все наборы шифров, указанные в таблице 7.

Таблица 7 — Поддерживаемые наборы шифров

Набор шифров

RFC

TLS ECDH ECDSA WITH AES 128 CBC SHA256

138)

TLS ECDHE ECDSA WITH AES 128 CBC SHA256

138)

7.8 Коммуникационный протокол V2G

7.8.1 Общая информация

Коммуникационный протокол V2G (V2GTP) является компактным протоколом связи для передачи сообщений V2G между двумя субъектами V2GTP. Он в основном состоит из определения заголовка и полезных данных, что позволяет разделять и эффективно обрабатывать сообщения V2G. V2GTP является стандартным коммуникационным протоколом между EVCC и SECC. но может быть также ис-пользован для связи с другими субъектами V2G. которые поддерживают протокол V2GTP.

7.8.2 Поддерживаемые порты

V2GTP базируется на TLS+TCP. которые используют пару IP-адресов (адрес-источник и адрес назначения) и пару номеров портов (порт-источник и порт назначения) для установления и идентификации соединения. Соединение устанавливается от адреса-источника и порта-источника к адресу назначения и порту назначения. Порты, перечисленные в таблице 8. используются субъектами V2GTP. Таблица 8 — Поддерживаемые порты TLS для V2GTP

Имя

Протокол

Номер порта

Описание

V2G_SRC_TCP_DATA

TCP (с адресацией конкретному устройству)

Номер порта в диапазоне динамических портов (49152-65535). как описано 8 (39)

Порт-источник V2GTP первичного субъекта (например. EVCC). который реализует протокол V2GTP

V2G_DST_TC P.DATA

TCP (с адресацией конкретному устройству)

Номер порта субъекта V2GTP. предоставляющего номер порта назначения в диапазоне динамических портов (49152-65535). как описано в {39). Для SECC он присваивается динамически механизмом SOP (7.10.1)

Порт назначения V2GTP первичного субъекта (например. SECC)

Для субъектов V2GTP, реализующих V2GTP, действуют следующие общие требования: [V2G2-073] Субъект V2GTP, предоставляющий порт назначения, должен поддерживать не ме

нее одного соединения на локальном порте V2G_DST_TCP_DATA. как указано е таблице 8.

[V2G2-074) Субъект V2GTP. предоставляющий порт назначения, может поддерживать несколько одновременных соединений на локальном порте V2G_DST_TCP_DATA, как указано е таблице 8.

[V2G2-0751 Субъект V2GTP. использующий порт-источник, должен поддерживать не менее одного соединения на локальном порте V2G_SRC_TCP_DATA. как указано в таблице 8.

[V2G2-076] Субъект V2GTP. использующий порт-источник, может поддерживать несколько соединений на локальном порте V2G_SRC_TCP_DATA, как указано е таблице 8.

Для EVCC и SECC особо действуют следующие требования:

[V2G2-0771 EVCC должен использовать порт-источник V2G_SRC_TCP_DATA, как указано в таблице 8.

[V2G2-0781 SECC должен предоставлять порт назначения V2G_DST_TCP_DATA. как указано в таблице 8.

[V2G2-079] EVCC должен поддерживать не менее одного соединения для сеанса связи V2G на порте V2G_SRC_TCP_DATA.

(V2G2-080) SECC должен поддерживать не менее одного соединения для сеанса связи V2G на порте V2G_DST_TCP_DATA.

[V2G2-0811 EVCC должен использовать для соединения с SECC порт V2G_DST_TCP_DATA. выданный в последнем сообщении об обнаружении SECC (см. 7.10.1.5).

7.8.3 Блок протокольных данных

7.8.3.1 Структура POU V2GTP

POU V2GTP состоит из заголовка и основной части, или тепа, как показано на рисунке 8.

Заголовок

Полезные данные

(8 байт)

(0-4294967295 байт)

Рисунок 8 — Структура сообщения V2GTP

Полезные данные содержат данные приложения (например, сообщение V2G). Заголовок отделяет полезные данные (т. е. индивидуальные сообщения V2GTP) в потоке байтов и дает информацию для обработки полезных данных.

Структура заголовка сообщения V2GTP показана на рисунке 9 и описана в таблице 9. Поддерживаемые типы полезных данных описаны в таблице 10.

N» байта

Попе

заголовка

1

2

3

4

5

6

7

8

Версия

протокола

Обратная

версия

протокола

Тип полезных данных

Длина полезных данных

Рисунок 9 — Структура заголовка сообщения V2GTP

[V2G2-082) Субъект V2GTP должен использовать структуру заголовка, показанную на рисунке 9. [V2G2-083] Субъект V2GTP должен отправить 8 байтов заголовка V2GTP в порядке, показанном

на рисунке 9.

[V2G2-084J Байт с меньшим номером должен быть отправлен перед байтом с большим номером. Заголовок начинается с байта 1 и заканчивается байтом 8.

(V2G2-085) Субъект V2GTP должен отправлять поля «Тип полезных данных» и «Длина полезных данных» в формате с обратным порядком следования байтов: наиболее значимый байт передается первым, наименее значимый байт — последним.

Таблица 9 — Типовая структура заголовка V2GTP

Лоле заголовка

Описание поля заголовка

Значения поля заголовка

Версия

протоколе

Идентифицирует версию протокола сообщений V2GTP

0x01:

V2GTP версия 1

0x00, 0x02-0xFF:

зарезервировано

документом

Обратная

версия

протокола

Содержит обратное побитовое значение версии протокола и используется совместно с версией протокола V2GTP как схема проверки протокола, обеспечивающая получение правильно сформа-тированного сообщения V2GTP.

Эквивалентно функции: <Protocol Versxxr> XOR OxFF

OxFE: V2GTP версия 1

Тип полезных данных (GH PT)

Содержит информацию о том, как декодировать полезные данные, следующие после заголовка V2GTP

Полный перечень значений типе» полезных данных см. в таблице 10

Длина полезных

данных

(GH.PL)

Содержит длину полезных данных сообщения V2GTP в байтах (т. е. исключая байты типового заголовка V2GTP)

0…4294967296 (= <d>)

Таблица 10 — Обзор типов полезных данных V2GTP

Значение типа полезных данных

Иыя шла полезных данных

Описывается в пункте

0x0000

0x8000

Зарезервировано

Неприменимо

0x8001

EXI-кодированное сообщение V2G

7.9.1.2

0x8002

0X8FFF

Зарезервировано

Неприменимо

0x9000

Сообщение с запросом SDP

7.10.1.4

0x9001

Сообщение с ответом SOP

7.10.1.5

0x9002

0X9FFF

Зарезервировано

Неприменимо

ОхАООО

OxFFFF

Специфичное использование изготовителя

Неприменимо

[V2G2-086] Субъект V2GTP должен использовать структуру сообщения V2GTP. показанную на рисунке 8. для отправления сообщения V2G. как описано в разделе 8.

[V2G2-087] Субъект V2GTP должен использовать определения, как указано в таблицах 9 и 10.

[V2G2-088] Для ЕХЬкздированных сообщений V2G (полезные данные 0x8001) субъект V2GTP должен использовать отдельное сообщение V2GTP для каждого сообщения V2G.

Примечание — Из требования [V2G2-088] вытекает, что попе полезных данных не может включать ни часть сообщения, ни несколько сообщений.

7.8.3.2 Обработка заголовка

Для обработки полезных данных субъект V2GTP должен сначала обработать заголовок. Для этого субъект V2GTP. получивший сообщение V2GTP. проверяет поле заголовка шаг за шагом. Описанная ниже обработка заголовка проиллюстрирована на рисунке 10.

[V2G2-089] Субъект V2GTP должен обработать заголовок V2GTP. как указано в таблице 9. до обработки полезных данных, как определено в таблице 10.

[V2G2-090] Субъект V2GTP должен проверить поля версии протокола и обратной версии протокола (последовательность синхронизирующих импульсов) перед какими-либо другими полями заголовка.

[V2G2-092] Субъект V2GTP должен проверить тип полезных данных после успешной проверки поля версии и обратной версии протокола.

[V2G2-094} Субъект V2GTP должен проверить длину полезных данных после успешной проверки типа полезных данных.

[V2G2-0961 Если обработка заголовка была успешной, субъект V2GTP должен обрабатывать полезные данные.

(V2G2-800) Если заголовок V2GTP содержит неверные данные (например, не поддерживаемый ■ ил пилезных данных, неверную длину полезных данных или не поддерживаемую версию V2GTP). субъект V2GTP должен игнорировать это сообщение.

Нвшло лроирм авголмм

О

fltBMWO ямм ведом н обратной версия

р2в2МВД

Лроотровтяпв полом ыж донных

СЛО2-0ВЯ

Провал* ело ми соовийт

[V2Qz-oeeq

Остаимкя фовврт млтюол Рисунок 10—Обрвбопв типового «голмл V2GTF

7.9 Представительский уровень

7.9.1 XML и эффективный XML-обмен (EXI)

7.9.1.1 Обзор

Для описания набора сообщений V2G представительский уровень использует широко применяемое XML представление данных. 8 настоящем стандарте описаны сообщения (т. е. структуры данных и типы данных) на основе XML-схемы, что позволяет использовать XML с учетом типов и обеспечивает упрощенную оценку действительности сообщений, которые являются объектом обмена.

[V2G2-097] При передаче сообщений V2G. описанных в настоящем стандарте, с использованием XML все субъекты V2G должны использовать формат кодирования в соответствии с определениями в [40}.

7.9.1.2 Эффективный XML-обмен

Формат эффективного XML-обмена (EXI) позволяет использовать и обрабатывать сообщения на базе XML на уровне двоичных кодов. Таким образом, формат EXI увеличивает скорость обработки данных на базе XML. а также сокращает использование памяти. EXI является рекомендацией W3C. Формат EXI использует для кодирования относительно простой подход на основе грамматики, обеспечивающий очень эффективное кодирование для широкого ряда случаев применения. Нередко EXI-сообщения бывают до 100 раз меньше, чем эквивалентные XML-докумвнгы. Спецификация EXI описывает с помощью предопределенного процесса, как информация схемы должна трансформироваться в грамматику EXI. Основанием для этого является то. что грамматику ЕХ1 гораздо легче обрабатывать по сравнению с информацией XML-схемы. При этом грамматический раэбор может быть осуществлен так же точно, как и в XML.

Существуют разные виды механизма кодирования с EXI. Для удовлетворения требований настоящего стандарта в плане эффективности обработки, использования меньших ресурсов, размера сообщения и расширяемости сообщения должны быть выбраны настройки, учитывающие схему {см. требования к настройкам EXI для настоящего стандарта в 7.9.1.3).

EXI-потоки могут быть созданы очень эффективным способом, если вся кодированная информация (элементы/атрибуты) определена XML-схемой. Информация с отклонениями на основе знания XML-схемы кодируется более общим способом. Кодер EXI кодирует классифицированные имена (область имен и имя элемента/атрибута) неизвестной информации на базе операций со строками. Однако простые типы отклонений схемы могут по-прежнему кодироваться с учетом типа.

Декодеры EXI способны декодировать эффективные EXI-потоки, используя ту же лежащую в основе XML-схему, которая была использована для процесса кодирования. Отклонения от схемы определяются в потоке EXI. Данные отклонения (неизвестные элементы или атрибуты) могут быть обработаны или пропущены.

На рисунке 11 обобщается концепция эффективного XML-обмена для домена. Вследствие больших ограничений, связанных с лимитом ресурсов. EVCC может быть способен только обрабатывать данные на базе XML используя соответствующее представление структуры данных. Тахие структуры данных могут быть использованы для оереалиэации или десвреализации сообщений приложения. При этом SECC может быть способен обрабатывать данные как структуру данных и/или как требующую более интенсивной работы ресуроов объектную модель документов (ОМД) или как традиционный вариант простого текста XML

Совместно используемые значения

XML-cxeua

Рисунок 11 — Применение базовой концепции EXI к связи V2G

7.9.1.3 Настройки EXI для сообщений прикладного уровня Следующие настройки EXI используются для связи V2G на базе EXI:

[V2G2-098] XML-схема с областью имен «um:iso:15118:2:2013:msgDef», которая представляет собой версию ISO 15118 2.0 (основной номер версии «2». дополнительный — «0»), должна использоваться для кодирования и декодирования ЕХЬлотоков.

[V2G2-099J EXI-кодер для кодирования и декодирования коммуникации в соответствии с [1].

ГОСТ Р 58122 (ИСО 15118-1) и настоящим стандартом должен использовать опции кодирования EXI по умолчанию в соответствии с (40) (см. пункт <EXI Options»), за исключением опций, перечисленных в таблице 11.

Таблице 11 — Настройки опций EXI

Опция EXI

Описание

Значение

гос г р (исо г s j та- >

vaJueParttionCapacity

Указывает допустимый диапазон числа разделов в таблице строк

0

[V2G2-100J EXI-эаголовох (см. [40). пункт «Header») должен использоваться способом, отвечающим требованиям (1). ГОСТ Р 58122 (ИСО 15118-1) и настоящего стандарта. Это означает, что факультативный EXI Cookie-файл (SEXI) никогда не должен использоваться и бит присутствия для опций EXI должен быть всегда установлен е 0 (=false). Как следствие, факультативные опции EXI никогда не должны быть частью сообщения [1), ГОСТР 88122 (ИСО 15118-1) и настоящего стандарта. Каждая реализация EXI (на EVCC или SECC) должна отбрасывать сообщения, которые не соблюдают опции заголовка EXI [1). ГОСТ Р 58122 (ИСО 15118-1) и настоящего стандарта.

[У2С2-101)Элемект/атрибут. который не олределене области имен «um:iso:15118:2:2013:msgDef», должен кодироваться и декодироваться как случай отклонения схемы в соответствии с (40}(пункт «Adding Productions wtien Strict is False»).

[V2G2-600] EXI-кодер для кодирования и декодирования коммуникации по [1]. ГОСТ Р 58122 (ИСО 15118-1) и настоящему стандарту должен использовать настройки профиля EXI в соответствии с таблицей 12.

Примечание — Дополнительное описание профиля EXI см. в (42).

Таблица 12 — Настройки профиля EXI

Параметр профиля EXI

Описание

Значение по ГОСТ Р S6t22 (ИСО)5})д-}.20)3)

maximumNumberOfBuiltlnElementGrammars

Эта опция является максимальным числом встроенных грамматик элементов. для которых динамически были добавлены продукции, не являющиеся продукциями thAT(xsi:type)

0

maximumNumberOfBuiltlnProductions

Эта опция является максимальным числом продукций верхнего уровня. которые могут быть динамически вставлены во встроенные грамматики элементов, за исключением продукций AT(xsi:type)

0

[V2G2-102] Простой тип/эначение элемента/атрибута. который не определен в области имен «urn:iso:15118:2:2013:msgDef». должен кодироваться и декодироваться с учетом типа.

7.9.2 Безопасность сообщений

7.9.2.1 Обзор

XML-лодпись является рекомендацией [41). которая направлена на удовлетворение требований аутентичности некоторых фрагментов данных (например, информация об учете) V2G на базе XML. XML-лодпись определяет механизм, с помощью которого сообщения и части сообщений могут быть подписаны цифровой подписью для проведения аутентификации, обеспечения сохранности, исключения искажений. Для защиты конфиденциальности применяется схема гибридного шифрования на базе протокола Диффи — Хеллмана.

7.9.2.2 Удостоверения и наборы шифров безопасности прикладного уровня

Удостоверения, применяемые на уровне приложения, должны быть нацелены на безопасность

XML. XML-подпись выбрана для защиты информации, относящейся к расчетам между EVCC. SECC и/или SA. Двоичное шифрование обеспечивает способ предоставления закрытого ключа EVCC с защитой конфиденциальности и без доступа посредников к данному закрытому ключу. Оба подхода требуют ассиметричного материала ключей. Удостоверения для подписания EVCC обеспечиваются сертификатом контракта, удостоверения для получения EVCC зашифрованных данных обеспечиваются обменом ключей ECDH. как описано в приложении О.

(V2G2-103J Максимальный срок действия сертификата контракта должен быть не более двух лет.

(V2G2-104J Минимальный срок действия сертификата, используемого для XML-подписи и обеспечения механизма для шифрования, должен быть четыре недели. Если срок действия контракта меньше, срок действия сертификата должен быть адаптирован к сроку действия контракта.

Примечание 1 — Пояснения относительно срока действия сертификата см. в С.1 (приложение С).

Примечание 2 — Если сертификат не используется для зарядки, он может быть использован для сервиса. Сервисный сертификат изготовителя позволяет EVCC запросить действительный сертификат контракта для режима РпС.

Примечание 3 — Закрытые ключи сертификата контракта и сервисного сертификата изготовителя являются денными, требующими защиты. После того как закрытый ключ взломан, ему нельзя больше доверять и поэтому им больше нельзя пользоваться. Если один из этих закрытых ключей может быть прочтен злоумышленником, то злоумышленник может выдать себя за исходный EVCC и получить электроэнергию за счет настоящего владельца транспортного средства. В качестве контрмеры EVCC гложет применить дополнительную защиту указанных ключей. Это может варьироваться от простых мер безопасности, таких как настройка предохранигегъных битое защиты от считывания в микроконтроллере EVCC. до более продвинутой защиты за счет средств защищенной загрузки, защиты при доступе для отладки и встроенных аппаратных модулей безопасности (АМБ). Последние обеспечивают высокий уровень безопасности, включая защиту против физических атак. Надлежащий АМБ обеспечивает безопасную среду для операций с закрытым ключом. Он предлагает интерфейсам использовать закрытый ключ, но обеспечивает невозможность считывания или манипулирования кгьочом даже для программы, которая работает s EVCC. Специализированный АМБ может даже допускать ввод зашифрованного закрытого ключа сертификата контракта с тем. чтобы закрытый ключ никогда не был доступен вне АМБ в простой незашифрованной форме. Такой АМБ может быть интегрирован в EVCC как отдельный физический модуль или как расширение кристалла микроконтроллера.

Примечание 4 — Для сокращения числа требующихся запросов об обновлении сертификата для EV оператору услуг для EV. выдающему сертификаты контрактов на зарядку, предлагается выбирать более длительные сроки действия (до максимальных) сертификата, если это имеет смысл в плане срока действия контракта и периода аннуляции.

7.9.2.3 Сертификаты контракта как удостоверения XML-подписи

Сертификат контракта привязан к EMAID и используется в XML-подписи для авторизации зарядки транспортного средства. Сертификат контракта может быть проверен, даже если SECC находится в режиме офлайн. Связывание контракта осуществляется следующим образом:

(V2G2-108) EMAID должен кодироваться в предмете сертификата.

7.3.2.4 Специфика безопасности XML для набора(ое) сообщений РпС

7.9.2.4.1 Структуры XML-данных для безопасности прикладного уровня

Безопасность на уровне приложения обеспечивается с помощью подписи и шифрования сообщений. Обмен информацией, предназначаемой для сервисов SA. осуществляется с использованием структур данных XML. Поэтому эта информация может быть целиком защищена с помощью средств безопасности XML.

Типичная информация, которой обмениваются EVCC и SECC, это согласование подписанных показаний прибора учета от транспортного средства, используемых для онлайновых и полуонлай-новых соединений. Показания прибора учета от SECC отправляются через защищенный канал TLS. Они могут включать подпись счетчика электроэнергии, обеспечивающую аутентификацию источника для дополнительной защиты. Транспортное средство, в свою очередь, подписывает показания прибора учета для поддержки процесса расчета, если местные правила это допускают. Такой подход позволяет экономить подписи показаний прибора учета со стороны SECC. Показания прибора учета накапливаются, поэтому самое последнее показание прибора учета служит основой для расчета. Используются XML-подписи. которые обеспечивают защиту сохранности информации. давая возможность всем промежуточным и участвующим субъектам полагаться на эту информацию.

7.Э.2.4.2 Механизм XML-подписи

В данном пункте описан механизм XML-подписи.

Примечание 1 — Обзор XML-подписейсм. также в приложении Е.

XML-подписи, которые соответствуют синтаксису и версии обработки 1.1 XML-подписи {41}. могут быть применены к произвольному цифровому содержанию (объектам данных) так же. как и при расчете цифровых подписей. При применении цифровой подписи к объектам данных они сначала обрабатываются (хешируются), и результат затем подписывается с помощью асимметричного алгоритма, такого как RSA (алгоритм цифровой подписи Ривеста — Шамира — Адельмана) или ECOSA. В случае XML свертка помещается в XML-элемент вместе с дополнительной информацией. Этот элемент затем хешируется и криптографически подписывается. В настоящем стандарте используются обособленные XML-подписи. которые соответствуют синтаксису и версии обработки 1.1 XML-подписи (см. {41}). Это означает, что подпись и данные могут быть в отдельном (внешне обособленные) или в одном и том же XML-документе (внутренне обособленные) как родственные элементы одного уровня. Подпись может охватывать только часть XML-документа, на который ссылается ObjectID.

На рисунке 12 показана диаграмма схемы элемента XML-подписи. включенного в заголовок сообщения V2G.

dtSignalureType

■— Щ attributes

— г— pdaiSignBcHfifo ф-г

ds^ignedlnfoTyp» !— Oetotoutes

I— ^d»£at>onlc«ta«tk>nM>thod ф

^d»£lgn«tur»MBthod^

>— авЛГвгвпе*

f —**

1..«

— »d«:S>flnaturtV«lu» ф “diiiyinfo Э

О.а

Рисунок 12 —Диаграмма — XML-подпись

На рисунке 13 показана диаграмма элемента Reference, включенного в элемент Signedlnfo. который является частью XML-подписи, показанной на рисунке 12.

с(вЯ»Гвг«псвТур»

Рисунок 13 — Диаграмма — Элемент Reference, включенный в элемент Signedlnfo

dcTransform* Q »d»:Plfl4tMathod ф — ^da^OgeetValueJ

Примечание 2 — Значения прибора учета от SECC могут быть уже подписанными. Это значение подписи рассматривается как информационный элемент и требуется для процесса измерений. Подпись может также включать идентификатор прибора учета.

(V2G2-117] Каждый субъект V2G должен поддерживать обособленные XML-подписи.

(V2G2-119) Для операций XML-лодписей подписываемые данные должны быть EXI-представле-нием этих данных.

(V2G2-764) Как метод канонизации должен использоваться EXI с грамматикой фрагмента, учитывающей схему.

[V2G2-765] Каждое сообщение, требующее структуры XML-подписи. должно использовать значение «http://www.w3.org/TR/canonical-exi/» в качестве атрибута алгоритма в элементе Canon icalizationMethod.

[V2G2-766] Каждое сообщение, требующее структуры XML-подписи. должно использовать значение «http://www.w3.org/TR/canonical-exiZ» в качестве атрибута алгоритма в элементе Transform.

[V2G2-767] Максимальное число алгоритмов Transform ограничивается одним (1) (т. е. на один элемент, на который делается ссылка и для которого передается подпись, может быть указан только один алгоритм Transform).

[V2G2-768J Части, которые должны быть подписаны в сообщениях на базе XML. должны кодироваться как фрагмент, учитывающий EXI-схему.

[V2G2-769J Каждое сообщение, требующее структуры XML-подписи. должно использовать значение «http://www.w3.Org/2001/04/xmldsig-more#ECDSA-sha256» в качестве атрибута алгоритма в элементе SignatureMethod.

(V2G2-770) Каждое сообщение, требующее структуры XML-подписи. должно использовать значение «http://www.w3.Org/2001/04/xmtenc#sha256» в качестве атрибута алгоритма в элементе DigestMethod.

[V2G2-771J Следующие элементы сообщений со структурой XML-подписи не должны использоваться при передаче подписей в заголовке сообщения V2G:

– Id (attribute in Signedlnfo);

« ##any in Signedlnfo — CanonicalizationMethod:

– HMACOutputLength in Signedlnfo — SignatureMethod;

– ##other in Signedlnfo — SignatureMethod;

« Type (attribute in Signedlnfo-Reference):

• ##other in Signedlnfo — Reference — Transforms — Transform;

– XPath in Signedlnfo — Reference — Transforms — Transform;

– ##other in Signedlnfo — Reference — DigestMethod:

– Id (attribute in SignatureValue);

– Object (in Signature):

• Keylnfo.

[V2G2-909J Подпись не должна относиться к более чем четырем подписываемым элементам. Примечание 3 — Это позволяет определить верхнюю границу для размера заголовка подписи.

Для применения XMLDstg любой элемент, который должен быть подписан, должен быть адресуемым. В настоящем стандарте это обеспечивается ссылкой универсального индикатора ресурсов (URI) на идентификационный атрибут такого элемента. Таким образом, любой подписанный элемент сообщения несет идентификационный атрибут. Если конкретный элемент должен подписываться во всех случаях использования, то идентификационный атрибут обязательно помечается в XSD. Однако если он подписывается только в некоторых случаях использования, то идентификационный атрибут помечается как факультативный и может быть опущен, когда он не требуется.

Примечание 4 — Присутствие идентификационного атрибута не обязательно означает, что подпись используется. т. е. если подпись не используется, идентификатор может тем не менее присутствовать.

7.9.2.4.3 Механизм шифрования

Закрытые ключи, принадлежащие сертификатам контрактов, требуют защиты (т. е. шифрования) при передаче от SAk EVCC. Более подробные пояснения приведены в приложении D.

[V2G2-121] EVCC должен поддерживать расчет секретной функции и функции установления ключа ECDH для расшифровки зашифрованной информации, такой как закрытые ключи.

[V2G2-122] Каждый субъект V2G должен иметь механизмы для выполнения обмена ключами ECDH. Открытые параметры являются производными от открытых параметров ECDSA.

[V2G2-814] Закрытый ключ, соответствующий сертификату контракта, должен передаваться только в зашифрованном формате в сообщениях CertificatelnstallationRes и CertificatellpdateRes — в составе ContractSignatureEncryptedPrivateKey.

[V2G2-815] Закрытый ключ, соответствующий сертификату контракта, должен шифроваться отправителем (SA) с использованием ключа сеанса, полученного в протоколе ECDH (см. (V2G2-818J). и алгоритма AES-CBC-128 в соответствии с (43]. Вектор инициализации IV должен случайно генерироваться перед шифрованием, иметь длину 128 бит и никогда повторно не использоваться. Вектор инициализации IV должен передаваться в 16 старших байтах поля ContractSignatureEncryptedPnvateKey.

Примечание 1 — Подразумевается, что надлежащее случайное генерирование векторов инициализации IV обеспечивает исключение их повторного использования с чрезвычайно высокой вероятностью, эквивалентной достоверности для криптографических требований.

[V2G2-816] Порядок байтов закрытого ключа должен быть обратным, включая ведущие нули.

Примечание 2 — Поскольку используется ECOSA с кривой secp256r1. закрытый ключ имеет длину 256 бит.

Примечание 3 — Дополнение нешифрованного текста (закрытый ключ) не требуется, поскольку его длина кратна размеру блока используемого алгоритма шифрования.

(V2G2-817] Закрытый ключ, соответствующий сертификату контракта, должен декодироваться получателем (EVCC) с помощью ключа сеанса, полученного е протоколе ECDH (см. [V2G2-818]). с применением алгоритма AES-CBC-128 в соответствии с [43]. Вектор инициализации IV должен считываться из 16 старших байтов поля ContractSignatureEncryptedPrivateKey.

[V2G2-818] Для согласования ключа сеанса должен использоваться эфемерно-статический протокол публикации [44]. KDF должен быть «конканатенационным KDF», е котором функция хеширования должна быть SHA256. SA должен действовать как сторона U (в соответствии с [44]). и EVCC должен действовать как сторона V. Протокол должен использовать эллиптические кривые, как указано в приложении В. Идентификатор алгоритма должен быть обозначен одним символом 0x01. Имя отправителя IDU должно быть обозначено одним символом «и» = 0x55. имя получателя IDV — одним символом «V» – 0x56. Должен быть получен симметричный ключ шифрования — точно 128 бит.

Примечание 4 —Аутентичность передачи обеспечивается окружающей подписью. Проверка аутентичности обязательна для безопасности протокола ECDH.

[V2G2-819] Эфемерные открытые ключи должны кодироваться как «Subject Public Key» в соответствии с {45} и содержаться в XML-элементе «DHpublickey». Должна использоваться исключительно несжатая форма.

Примечание 5 — XML-эпеменг oDHpubhckey* имеег длину 65 байтов. Первый байг имеет фиксированное значение 0x04. что указывает на несжатую форму.

[V2G2-820] в сообщении CertificatelnstallatronRes открытый ключ получателя QV должен быть открытым ключом, содержащимся в существующем сервисном сертификате изготовителя.

[V2G2-821} В сообщении CertificatellpdateRes открытый ключ получателя QV должен быть открытым ключом, содержащимся в существующем сертификате контракта.

[V2G2-822] Сертификат, пара ключей которого используется для ECDH. должен иметь установленные в единицу флаги использования ключей keyAgreement. Это требование действует для всех сертификатов контракта и всех сервисных сертификатов изготовителя и должно выполняться всеми участвующими сторонами.

[V2G2-8231 После получения сертификата контракта EVCC должен убедиться в том. что закрытый ключ, полученный с сертификатом, является действительным закрытым ключом для этого сертифик